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> |