Den 15-04-2017 kl. 22:58 skrevnotify@aur.archlinux.org: That's still up to 2 weeks where the -git package would be ahead of the last release. (And there was recently more than a month between two releases, after the 2 week release schedule had been "enacted".) 2 weeks of development is not a lot so users of the lutris are likely to get a fresh experience without having to deal with the instabilities for

How much extra burden is this? I see two mentions of "lutris-git" at the forums[1]. The latter of which, from March, only used the -git package to test whether something had been fixed between "master" and the latest release. I haven't seen a lot of people saying "it's broken!~1!" on IRC. I tried to look over GitHub issues mentioning "lutris-git", and the couple I looked at also only used lutris-git to check whether a bug had been fixed in git since the latest release (except for one[2]), and not encountering the bug using -git first. I decided to request the removal of the package after a user on Discord mentioned that script installations did not work, which they won't be until I finish transitioning to the REST API and will only be ready for

Based on the examples I found (and I admit I didn't go fully in depth), it rather shows that it *was* helpful for users to be able to easily switch to the latest -git to verify whether a bug was still present or not, or to temporarily work around an issue that's been fixed since the last release but hasn't been released proper yet. I don't see why users can't install the regular Lutris package and also have a local copy of the source code checked out with git. With a local copy, I can easily suggest fixes to the source code which is not as easily done when they need to modify files in /usr with root

On 04/16/2017 03:22 AM, Frederik “Freso” S. Olesen wrote: the current dev version. the 0.4.8 release. permissions. I do expect from git users to get their hands dirty at least a little bit. The lutris-git provides a way to access unstable development versions as a "read-only" package which is the total opposite of what I'm trying to achieve. Contrary to a lot of projects, I made sure Lutris is very easy to run from its source tree. Doing it this way also act as some kind of filter where the development version is only used by users familiar with git and to an extent with Python, maybe. This might mean less bug reports but it also means better ones. We do also push out patch releases when a serious issue is found in the stable release (such as the 0.4.7.1 release).

(Also, is it better to get bug reports on "stable" releases where the bug might be 2+ weeks old rather than within a couple of days of a feature being introduced and the code still being in fresh memory? I know that I have previously found bugs running from git that hadn't otherwise been uncovered yet and might well have made it to the "stable" release.)

By the reasoning given for this removal, the AUR should remove/disallow almost all VCS packages. Few projects have a release cycle of 2 weeks, for projects with a longer release cycle it makes sense to have those packages. It also makes sense when the build process is complex, which is not the case with Lutris.

One issue related to this is how branches are handled in the project right now. The next branch is currently occupied by the 0.5.0 version with GOG support and all the current development happens on master. Once 0.5.0 is released, I will adopt a more sane way of handling branches by going back to the next branch for the future release and creating feature branches when needed. Once this is the case, the code will be merged in master once every 2 weeks, which means that the lutris-git would be useless since it would only contain the code of the latest stable release. Mathieu