El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió: > During the latest Council meeting it was determined to set up a new > Working Group to come up with recommendations for improving the state > of > the stable tree at a later Council meeting. > > Some initial items it was suggested the WG look into is > * The b.g.o workflow, bugs should not be considered fixed until the > fix has reached the stable tree. Today the InVCS keyword exists > for > this purpose, but it is used to varying degree amongst developers. > Will a workflow change to introduce a new status, e.g RESOLVED > NeedsStable (name for illustration purpose only) incentivize > developers to not close bugs before it is fixed? >
Yes. For example, currently, most gnome bugs are not major enough to need a fast stabilization and, then, we wait for the next round of stabilizations instead of filling one new bug per package. We, of course, do exceptions when the bug is major enough. Then, the old workflow of allowing to close the bugs even when only fixed in testing was working fine for us, and also allows us to have a more "tidy" bug list (as our bug list is huge sometimes) and focus on the really remaining bug reports. There are also many cases of long standing bugs that we want, on purpose, to be fixed in testing and wait for the full period (for example, I remember a last change in glib that we wanted it to wait for a full "major version bump" period, then, keeping the bug opened until that new version is stabilized with all the other related packages is not useful at all). Also, another drawback is that I would need to manually check, again, all the opened bug reports assigned to us and *related to many different packages* once the stabilization finishes (sometimes many months later)... and that is adding ever more work without any clear advantage to me. Another issues that comes to my mind is that, if I don't misremember, there were in the past some scripts that allowed us to fill automatic stabilization for reports to help maintainers to remember to stabilize things. That scripts were filling the bugs only when no bug report was opened for the relevant packages... then, they will break, and since they were the only thing "near automatic" for trying to remember to stabilize things... paradoxically this change will cause the stabilizations to be even more "manual" and, hence, probably even slower, as they will depend on the maintainer being active enough. I am not sure if, maybe, it would be feasible to add a button to bugzilla to create a stabilization bug from another one. I am thinking in something similar of our "Clone bug" feature. Maybe that would be adapted to create a new bug report based on existing one for taking the package name for the summary, appending the STABLEREQ keyword and... That way, we could still close the bug report when fixed (even in testing) while having the stable bug report around to allow us to remember that is still pending. > * Are there ways to reduce the stabilization lag of packages > - looking into the effectiveness of ALLARCHES and its use > - possibility for maintainer to stabilize packages themselves > for > architectures they have access to (including whether there > might > be a need for changes to gentoo infrastructure to facilitate > this) Thinking about the way I think most stabilization teams are handling the bunch stabilizations, I think the best think to do is that the maintainer itself goes ahead stabilizing on remaining arches as soon as the first one does the job. > - Tinderboxing / Automatic tools build test packages and reverse > dependencies in order to assist in stabilization Well, Toralf is really doing a nice job helping us with tinderbox, but I am unsure if that process is automatic enough to allow like one tinderbox per stabilization bug and if he has the resources to make it fast enough :/ > > Other suggestions are up to the WG to come up with and write up a > final > report to the council with the summary of these discussions. > > I've volunteered to chair such as working group. If you want to > participate in it please respond to this thread. Additionally I've > set > up #gentoo-wg-stable as a place of coordination. > I am not sure if one suggestion I did a few days ago was included (as the thread was already really long when I was able to reply sorry), if that is not the case, it was: My suggestion, for now would be to modify a bit the current policy: if I don't misremember, we can drop stable keywords for arches that are not stabilizing the package in 90 days. The problem is that it currently cannot be done in most of the times because it's not feasible for the maintainer to drop the keyword and *also* all the stable keywords of reverse deps. Hence, I would suggest to, apart of allowing the maintainers to drop the keywords, to also allow them to stabilize that packages on that arches when this timeout has expired Thanks!
