Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: "gentoo-dev@l.g.o" <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] New Working Group established to evaluate the stable tree
Date: Mon, 15 Aug 2016 08:00:38
In Reply to: [gentoo-dev] New Working Group established to evaluate the stable tree by Kristian Fiskerstrand
1 El dom, 14-08-2016 a las 23:35 +0200, Kristian Fiskerstrand escribió:
2 > During the latest Council meeting it was determined to set up a new
3 > Working Group to come up with recommendations for improving the state
4 > of
5 > the stable tree at a later Council meeting.
6 >
7 > Some initial items it was suggested the WG look into is
8 >  * The b.g.o workflow, bugs should not be considered fixed until the
9 >    fix has reached the stable tree. Today the InVCS keyword exists
10 > for
11 >    this purpose, but it is used to varying degree amongst developers.
12 >    Will a workflow change to introduce a new status, e.g RESOLVED
13 >    NeedsStable (name for illustration purpose only) incentivize
14 >    developers to not close bugs before it is fixed?
15 >
17 Yes. For example, currently, most gnome bugs are not major enough to
18 need a fast stabilization and, then, we wait for the next round of
19 stabilizations instead of filling one new bug per package. We, of
20 course, do exceptions when the bug is major enough.
22 Then, the old workflow of allowing to close the bugs even when only
23 fixed in testing was working fine for us, and also allows us to have a
24 more "tidy" bug list (as our bug list is huge sometimes) and focus on
25 the really remaining bug reports.
27 There are also many cases of long standing bugs that we want, on
28 purpose, to be fixed in testing and wait for the full period (for
29 example, I remember a last change in glib that we wanted it to wait for
30 a full "major version bump" period, then, keeping the bug opened until
31 that new version is stabilized with all the other related packages is
32 not useful at all).
34 Also, another drawback is that I would need to manually check, again,
35 all the opened bug reports assigned to us and *related to many
36 different packages* once the stabilization finishes (sometimes many
37 months later)... and that is adding ever more work without any clear
38 advantage to me.
40 Another issues that comes to my mind is that, if I don't misremember,
41 there were in the past some scripts that allowed us to fill automatic
42 stabilization for reports to help maintainers to remember to stabilize
43 things. That scripts were filling the bugs only when no bug report was
44 opened for the relevant packages... then, they will break, and since
45 they were the only thing "near automatic" for trying to remember to
46 stabilize things... paradoxically this change will cause the
47 stabilizations to be even more "manual" and, hence, probably even
48 slower, as they will depend on the maintainer being active enough.
50 I am not sure if, maybe, it would be feasible to add a button to
51 bugzilla to create a stabilization bug from another one. I am thinking
52 in something similar of our "Clone bug" feature. Maybe that would be
53 adapted to create a new bug report based on existing one for taking the
54 package name for the summary, appending the STABLEREQ keyword and... 
56 That way, we could still close the bug report when fixed (even in
57 testing) while having the stable bug report around to allow us to
58 remember that is still pending.
61 >  * Are there ways to reduce the stabilization lag of packages
62 >      - looking into the effectiveness of ALLARCHES and its use
63 >      - possibility for maintainer to stabilize packages themselves
64 > for
65 >        architectures they have access to (including whether there
66 > might
67 >        be a need for changes to gentoo infrastructure to facilitate
68 >        this)
70 Thinking about the way I think most stabilization teams are handling
71 the bunch stabilizations, I think the best think to do is that the
72 maintainer itself goes ahead stabilizing on remaining arches as soon as
73 the first one does the job. 
76 >      - Tinderboxing / Automatic tools build test packages and reverse
77 >        dependencies in order to assist in stabilization
79 Well, Toralf is really doing a nice job helping us with tinderbox, but
80 I am unsure if that process is automatic enough to allow like one
81 tinderbox per stabilization bug and if he has the resources to make it
82 fast enough :/ 
84 >
85 > Other suggestions are up to the WG to come up with and write up a
86 > final
87 > report to the council with the summary of these discussions.
88 >
89 > I've volunteered to chair such as working group. If you want to
90 > participate in it please respond to this thread. Additionally I've
91 > set
92 > up #gentoo-wg-stable as a place of coordination.
93 >
95 I am not sure if one suggestion I did a few days ago was included (as
96 the thread was already really long when I was able to reply sorry), if
97 that is not the case, it was:
98 My suggestion, for now would be to modify a bit the current policy: if
99 I don't misremember, we can drop stable keywords for arches that are
100 not stabilizing the package in 90 days. The problem is that it
101 currently cannot be done in most of the times because it's not feasible
102 for the maintainer to drop the keyword and *also* all the stable
103 keywords of reverse deps.
105 Hence, I would suggest to, apart of allowing the maintainers to drop
106 the keywords, to also allow them to stabilize that packages on that
107 arches when this timeout has expired 
109 Thanks!