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