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 |