Re: [gentoo-dev] New Working Group established to evaluate the stable tree

[Pacho Ramos]

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!