[aur-requests] [PRQ#7932] Deletion Request for lutris-git

Mathieu Comandon strider at strycore.com
Tue Apr 18 00:21:08 UTC 2017

On 04/16/2017 03:22 AM, Frederik “Freso” S. Olesen wrote:
> Den 15-04-2017 kl. 22:58 skrevnotify at 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 
the current dev version.
> 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 
the 0.4.8 release.
> 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 
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 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.archlinux.org/pipermail/aur-requests/attachments/20170417/576ae457/attachment-0001.html>

More information about the aur-requests mailing list