Gentoo Archives: gentoo-project

From: Brian Dolbec <dolsen@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 17:09:51
Message-Id: 20160804100938.0ac24bdc.dolsen@gentoo.org
In Reply to: Re: [gentoo-project] Call for agenda items - Council meeting 2016-08-14 by William Hubbs
1 On Thu, 4 Aug 2016 11:24:43 -0500
2 William Hubbs <williamh@g.o> wrote:
3
4 > On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote:
5 > > Dear all,
6 > >
7 > > the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC
8 > > in #gentoo-council on FreeNode.
9 > >
10 > > Please reply to this message on the gentoo-project list with any
11 > > items the council should put on its agenda to discuss or vote on.
12 >
13 > I feel that our stable tree is so far behind on all
14 > architectures that we are doing our stable users a disservice, so I
15 > would like to open up a discussion here, and maybe some policy changes
16 > at the next meeting.
17 >
18 > Ultimately, I think we need some form of automated stabilization, e.g.
19 > if a package version sits in ~ for 30 days and there are no blockers
20 > at that point, the new version should go automatically to stable on
21 > all architectures where there is a previous stable version.
22 >
23 > I realize that automation is going to take a lot of work, so in the
24 > meantime, I would like to discuss changes to our stabilization
25 > policies that will get new versions of packages to stable faster.
26 >
27 > The first issue is maintainers not filing stable requests for new
28 > versions of packages in a timely manor. I'm not sure how to get around
29 > this, but I feel that once a version of a package is stable, we are
30 > doing a disservice to our stable users by not keeping stable as
31 > current as possible. I am as bad as anyone; it is easy to forget to
32 > file stable requests until someone pings me or files the request
33 > themselves.
34 >
35 > I have heard other maintainers say specifically that they do not file
36 > stable requests unless a user asks them to, but Again, I do not feel
37 > comfortable with this arrangement if there is an old version of the
38 > package in stable. Users shouldn't have to ask for newer versions to
39 > be stabilized; this should be driven by the maintainers.
40 >
41 > The second issue is slow arch teams. Again, by not moving packages
42 > from ~ to stable, we are doing a disservice to our stable users.
43 >
44 > I can think of two ways we can improve our situation.
45 >
46 > We can allow maintainers to stabilize new versions of certain types of
47 > packages on all arches where there is a previous version of the
48 > package stable without filing stable requests. This would take a
49 > significant load off of the arch teams.
50 >
51 > For packages that do not fit the first group, we could require stable
52 > requests, but allow maintainers to stabilize the new versions after a
53 > timeout (I would propose 30 days).
54 >
55 > What do folks think?
56 >
57 > William
58 >
59
60 William, there is a GSOC project underway that is creating an automated
61 testing system as a helper and auto-stabilization system. You should
62 read over the gentoo-soc list and/or talk to the mentors and student
63 doing the project.
64
65 student: Pallav Agarwal <pallavagarwal07@×××××.com>
66 Mentors: Sébastien Fabbro <bicatali@g.o>
67 Nitin Agarwal <nitinagarwal3006@×××××.com>
68
69 --
70 Brian Dolbec <dolsen>

Replies