Gentoo Archives: gentoo-project

From: Daniel Campbell <zlg@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14
Date: Thu, 04 Aug 2016 21:30:28
Message-Id: 14962950-29f6-e7b4-19ba-9cdea15642a2@gentoo.org
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 by William Hubbs
1 On 08/04/2016 09:24 AM, William Hubbs wrote:
2 > On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote:
3 >> Dear all,
4 >>
5 >> the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC
6 >> in #gentoo-council on FreeNode.
7 >>
8 >> Please reply to this message on the gentoo-project list with any items
9 >> the council should put on its agenda to discuss or vote on.
10 >
11 > I feel that our stable tree is so far behind on all
12 > architectures that we are doing our stable users a disservice, so I
13 > would like to open up a discussion here, and maybe some policy changes
14 > at the next meeting.
15 >
16 > Ultimately, I think we need some form of automated stabilization, e.g.
17 > if a package version sits in ~ for 30 days and there are no blockers at
18 > that point, the new version should go automatically to stable on all
19 > architectures where there is a previous stable version.
20 >
21 > I realize that automation is going to take a lot of work, so in the
22 > meantime, I would like to discuss changes to our stabilization policies
23 > that will get new versions of packages to stable faster.
24 >
25 > The first issue is maintainers not filing stable requests for new
26 > versions of packages in a timely manor. I'm not sure how to get around
27 > this, but I feel that once a version of a package is stable, we are
28 > doing a disservice to our stable users by not keeping stable as current
29 > as possible. I am as bad as anyone; it is easy to forget to file
30 > stable requests until someone pings me or files the request
31 > themselves.
32 >
33 > I have heard other maintainers say specifically that they do not file
34 > stable requests unless a user asks them to, but Again, I do not feel
35 > comfortable with this arrangement if there is an old version of the
36 > package in stable. Users shouldn't have to ask for newer versions to be
37 > stabilized; this should be driven by the maintainers.
38 >
39 > The second issue is slow arch teams. Again, by not moving packages from
40 > ~ to stable, we are doing a disservice to our stable users.
41 >
42 > I can think of two ways we can improve our situation.
43 >
44 > We can allow maintainers to stabilize new versions of certain types of
45 > packages on all arches where there is a previous version of the package stable
46 > without filing stable requests. This would take a significant load off
47 > of the arch teams.
48 >
49 > For packages that do not fit the first group, we could require stable
50 > requests, but allow maintainers to stabilize the new versions after a
51 > timeout (I would propose 30 days).
52 >
53 > What do folks think?
54 >
55 > William
56 >
57 I can understand where you're coming from on this. Perhaps a more
58 comprehensive, approachable guide could be written for newer maintainers
59 like myself so we can learn a few of the skills the arch teams use to
60 stabilize packages. Proposed testing environments and setups (for
61 example, a VM dedicated to stabilization that runs on stable rather than
62 using the dev's main machine) would be super helpful.
63
64 Count me as one maintainer that'd love to learn how to do a better job
65 maintaining and getting newer versions stabilized. As it stands, I'm
66 almost afraid of pushing something to stable because I fear I'll miss
67 something or piss somebody off because I didn't perform the right ritual
68 beforehand or something.
69
70 Perhaps a good way to approach it is to adopt a sort of "every
71 maintainer is also an arch tester" ideology and get these skills passed
72 down/out to everyone to lessen the load of the arch teams.
73
74 --
75 Daniel Campbell - Gentoo Developer
76 OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
77 fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6

Attachments

File name MIME type
signature.asc application/pgp-signature