Re: Assigning keyword/stable bugs to arch teams (WAS: [gentoo-dev] dropping redundant stable keywords)

[Pacho Ramos <pacho@gentoo.org>]

El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió:
> On Sun, 16 Feb 2014 15:18:42 +0100
> Pacho Ramos <pacho@gentoo.org> wrote:
> 
> > I think that, if they delete del old version without breaking the tree
> > (and, then, moving the package to testing for that arch), the
> > situation is improved. But, if the bug is assigned to the same team
> > that cannot handle its stabilization, I doubt they will move it to
> > testing either.
> 
> And when you do break the tree when you threaten to effectively remove
> an arch keyword, then you may need to dig deeper and remove more
> keywords elsewhere until you've found an "unstable" solution. As long
> as you communicate the solution to that team, and maybe prod someone on
> IRC until they make the time to look at it and (reluctantly) agree,
> there should be no problem in dropping stable for them.

Yeah, I know that problem of "chain reaction" will appear (I am thinking
in Gnome stuff for example :S), but I can't think on any better
alternative. Will be a lot of work but will save time in the future :|

> 
> > But, I guess there are two major cases:
> > - Versions that cannot be stabilized due they not working on that arch
> > any longer
> 
> It's probably a good idea to package.mask the affected versions on the
> arch profile(s) (with references to bug reports, and so on) so all users
> of that profile get to see it. Treat it like a "last rites" process.
> Currently that's the only way for users to find out when and why a
> package becomes unsupported on a given profile, and it should work
> well enough. Give them thirty days to respond or become arch team
> members or ATs or just give the nod to an arch developer to say "it
> works" - it may even lead to actual stabilisation of a newer ebuild.

Looks interesting, maybe that would indeed help to get more people
involved on that arch teams :O

> 
> > - Versions that are not stabilized because arch team doesn't have the
> > man power to do that.
> 
> As above, package.mask would be a good intermediate solution,
> communicating the problem to the arch users for, say, thirty days. Of
> course it may just delay solving the problem when a new set of
> stabilisations is due and again no one responds.

I disagree in this case as the package can still be in "testing", not
like the above case that, if the package is broken, it shouldn't be
neither in testing tree.

> 
> > I am referring to the second case that is also really common. This
> > also raises again the question about being enough to do build tests
> > for that arches or not.
> 
> No, "compile only" is never enough to call something "stable".
> 
> > If that is the case, would be nice if maintainers could have access
> > to that machines to let us help them :) (if I would build them on
> > that arches, I would try to help for sure)
> 
> http://wiki.gentoo.org/wiki/Project:Infrastructure/Developer_Machines
> 
> 
>      jer
> 

Thanks for the link :D, but I don't think I could do much more than
building+running the tests of the packages while doing that in most
cases (I am thinking in "graphical" stuff). If that would be enough,
nice, if not... :S