On Mon, Jul 10, 2017 at 7:54 PM, Andrew Savchenko <birc...@gentoo.org> wrote: > On Mon, 10 Jul 2017 16:27:54 -0400 Rich Freeman wrote: >> On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: >> > This is why stabilisation, if not for individual package maintainers on >> > amd64, has become a joke, save for Ago's efforts, and recent efforts by >> > kensington to streamline the effort for the likes of ago with his bot, >> > and one or two other arch stabilisers (who I know exist, but not by name >> > or nick). >> >> Sure. If nobody is maintaining stable keywords on an arch, then there >> shouldn't be stable keywords on that arch, unless the stable keywords >> are used for a different purpose and maintainers are free to downgrade >> them at any time. > > I'm confused, again. I can't find any official policy regarding > dekeywording packages from stable to testing.
I tried to find the best documented answers I could to your questions, but as has been mentioned our documentation around what really goes on with arch keywording today is poor. This was one of the drivers for the stable-wg. > > Can developers remove packages from stable on whim or only on > certain conditions? Under what conditions exactly? Should arch > teams be notified on such actions? Or even requested permissions > from? "If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a pending STABLEREQ, for 90 days with archs CCed and otherwise ready to be stabilized, the maintainer can remove older versions of the package at their discretion. A package is considered ready to be stabilized if it has been in the tree for 30 days, and has no known major flaws on arches that upstream considers supported." [1] Note that this only pertains to stable arches. For a non-stable arch there are no restrictions on the removal of the last stable version as far as I'm aware. > > IMO a valid reason to remove from stable is arch team failure to > stabilize this package for a long time. But how long? Month, two, > half a year? 90 days, per the above. > > What to do with reverse dependencies? Should they be dropped to > ~arch altogether with the package in question? Or should their > maintainers be given a warning before? How long to wait after? > One more month or two, another half a year? They need to be dropped to ~arch as well, at the same time the stable version is removed. In practice this is painful and this was one of the drivers for the stable-wg. The 90 day relief the Council provided did not completely solve this problem. > > A well established arch -> ~arch policy should help to keep number > of stable packages sane and manageable for arch teams. A well > established policy of doing ~arch -> arch by devs themselves will > help to lower load on arch teams as well. So for everyone be happy > (arch teams by keeping them stable and manageable, devs by solving > stabilization requests in a sane time) we need good policies! > A big problem historically is that it is much easier to go from ~arch->arch than it is to go from arch->~arch. I think well-meaning users of minor arches enthusiastically deal with STABLEREQ bugs so that there are more stable packages available on the arch. However, once whatever itch they had was scratched they don't necessarily keep up with future requests on the same package, causing the package to become stale. The intent of the 90 day policy was to make it easier to drop keywords back. However, without scripts/etc to make this simple for maintainers most don't actually take advantage of this opportunity. It has also been rightly pointed out that this is a bit of a chaotic solution to the problem. If the minor arch doesn't keep up with stable keywords on a core dependency somebody running one of these scripts might remove almost all the stable keywords for that arch in the entire tree. The counter argument is that these core dependencies are the ones the arch team should be paying the most attention to, and if they spent more time stabilizing boring libraries and less time stabilizing applications maybe the problem wouldn't exist. GLEP 40 has been mentioned and this is an interesting policy and the way it is being mentioned makes it moreso. At the time it was written everything contained within was already being done on all the arches EXCEPT x86, where maintainers were doing their own stabilizations. Since the amd64 team was viewed as a model of best practice at the time the purpose of the GLEP was to make x86 the same as the other arches. Since then manpower and interests have changed, and amd64 initially just gave individual maintainers a go-ahead to do their own stabilizations and then eventually a blanket authorization for anybody to do so. Ironically this makes x86 the only arch with a documented arch testing policy in a GLEP. I can't find any documentation of the amd64 exception. I think it goes all the way back to kingtaco. 1 - https://projects.gentoo.org/council/meeting-logs/20131119-summary.txt -- Rich
