1 |
On Thu, Aug 04, 2016 at 04:15:14PM +0200, Kristian Fiskerstrand wrote: |
2 |
> Dear all, |
3 |
> |
4 |
> the Gentoo Council will meet again on Sunday, August 14 at 19:00 UTC |
5 |
> in #gentoo-council on FreeNode. |
6 |
> |
7 |
> Please reply to this message on the gentoo-project list with any items |
8 |
> the council should put on its agenda to discuss or vote on. |
9 |
|
10 |
I feel that our stable tree is so far behind on all |
11 |
architectures that we are doing our stable users a disservice, so I |
12 |
would like to open up a discussion here, and maybe some policy changes |
13 |
at the next meeting. |
14 |
|
15 |
Ultimately, I think we need some form of automated stabilization, e.g. |
16 |
if a package version sits in ~ for 30 days and there are no blockers at |
17 |
that point, the new version should go automatically to stable on all |
18 |
architectures where there is a previous stable version. |
19 |
|
20 |
I realize that automation is going to take a lot of work, so in the |
21 |
meantime, I would like to discuss changes to our stabilization policies |
22 |
that will get new versions of packages to stable faster. |
23 |
|
24 |
The first issue is maintainers not filing stable requests for new |
25 |
versions of packages in a timely manor. I'm not sure how to get around |
26 |
this, but I feel that once a version of a package is stable, we are |
27 |
doing a disservice to our stable users by not keeping stable as current |
28 |
as possible. I am as bad as anyone; it is easy to forget to file |
29 |
stable requests until someone pings me or files the request |
30 |
themselves. |
31 |
|
32 |
I have heard other maintainers say specifically that they do not file |
33 |
stable requests unless a user asks them to, but Again, I do not feel |
34 |
comfortable with this arrangement if there is an old version of the |
35 |
package in stable. Users shouldn't have to ask for newer versions to be |
36 |
stabilized; this should be driven by the maintainers. |
37 |
|
38 |
The second issue is slow arch teams. Again, by not moving packages from |
39 |
~ to stable, we are doing a disservice to our stable users. |
40 |
|
41 |
I can think of two ways we can improve our situation. |
42 |
|
43 |
We can allow maintainers to stabilize new versions of certain types of |
44 |
packages on all arches where there is a previous version of the package stable |
45 |
without filing stable requests. This would take a significant load off |
46 |
of the arch teams. |
47 |
|
48 |
For packages that do not fit the first group, we could require stable |
49 |
requests, but allow maintainers to stabilize the new versions after a |
50 |
timeout (I would propose 30 days). |
51 |
|
52 |
What do folks think? |
53 |
|
54 |
William |