<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 04/16/2017 03:22 AM, Frederik “Freso” S. Olesen wrote:<br>
<blockquote
cite="mid:c28089ee-4f87-12f9-c78d-aa0d944c5f90@gmail.com"
type="cite">
<pre wrap="">Den 15-04-2017 kl. 22:58 skrev <a class="moz-txt-link-abbreviated" href="mailto:notify@aur.archlinux.org">notify@aur.archlinux.org</a>:
</pre>
<pre wrap="">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".)
</pre>
</blockquote>
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.<br>
<blockquote
cite="mid:c28089ee-4f87-12f9-c78d-aa0d944c5f90@gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
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.
<blockquote
cite="mid:c28089ee-4f87-12f9-c78d-aa0d944c5f90@gmail.com"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
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.<br>
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.<br>
<br>
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).<br>
<blockquote
cite="mid:c28089ee-4f87-12f9-c78d-aa0d944c5f90@gmail.com"
type="cite">
<pre wrap="">(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.</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Mathieu<br>
</body>
</html>