On 08/04/2016 09:24 AM, William Hubbs wrote: > On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote: >> Dear all, >> >> the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC >> in #gentoo-council on FreeNode. >> >> Please reply to this message on the gentoo-project list with any items >> the council should put on its agenda to discuss or vote on. > > I feel that our stable tree is so far behind on all > architectures that we are doing our stable users a disservice, so I > would like to open up a discussion here, and maybe some policy changes > at the next meeting. > > Ultimately, I think we need some form of automated stabilization, e.g. > if a package version sits in ~ for 30 days and there are no blockers at > that point, the new version should go automatically to stable on all > architectures where there is a previous stable version. > > I realize that automation is going to take a lot of work, so in the > meantime, I would like to discuss changes to our stabilization policies > that will get new versions of packages to stable faster. > > The first issue is maintainers not filing stable requests for new > versions of packages in a timely manor. I'm not sure how to get around > this, but I feel that once a version of a package is stable, we are > doing a disservice to our stable users by not keeping stable as current > as possible. I am as bad as anyone; it is easy to forget to file > stable requests until someone pings me or files the request > themselves. > > I have heard other maintainers say specifically that they do not file > stable requests unless a user asks them to, but Again, I do not feel > comfortable with this arrangement if there is an old version of the > package in stable. Users shouldn't have to ask for newer versions to be > stabilized; this should be driven by the maintainers. > > The second issue is slow arch teams. Again, by not moving packages from > ~ to stable, we are doing a disservice to our stable users. > > I can think of two ways we can improve our situation. > > We can allow maintainers to stabilize new versions of certain types of > packages on all arches where there is a previous version of the package stable > without filing stable requests. This would take a significant load off > of the arch teams. > > For packages that do not fit the first group, we could require stable > requests, but allow maintainers to stabilize the new versions after a > timeout (I would propose 30 days). > > What do folks think? > > William > I can understand where you're coming from on this. Perhaps a more comprehensive, approachable guide could be written for newer maintainers like myself so we can learn a few of the skills the arch teams use to stabilize packages. Proposed testing environments and setups (for example, a VM dedicated to stabilization that runs on stable rather than using the dev's main machine) would be super helpful. Count me as one maintainer that'd love to learn how to do a better job maintaining and getting newer versions stabilized. As it stands, I'm almost afraid of pushing something to stable because I fear I'll miss something or piss somebody off because I didn't perform the right ritual beforehand or something. Perhaps a good way to approach it is to adopt a sort of "every maintainer is also an arch tester" ideology and get these skills passed down/out to everyone to lessen the load of the arch teams. -- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6