Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14

[Daniel Campbell <zlg@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 3673 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]