El dom, 16-02-2014 a las 15:46 +0100, Jeroen Roovers escribió: > On Sun, 16 Feb 2014 15:18:42 +0100 > Pacho Ramos <[email protected]> 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
