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. > 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. > - 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 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
