1 |
I want to elaborate a bit more on this. |
2 |
|
3 |
On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote: |
4 |
> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote: |
5 |
> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote: |
6 |
> > > On 08/15/2016 04:19 PM, William Hubbs wrote: |
7 |
> > >> I'm very much for this as well. Themaintainer should be able to |
8 |
> > >> stabilize on all arches after the timeout. That would solve the primary |
9 |
> > >> concern I have about the stable tree lagging. |
10 |
> > > |
11 |
> > > It depends on the context, if it is not security related or fixing a |
12 |
> > > known bug, it can cause regression for stable users without much gain. |
13 |
|
14 |
The maintainer of the package is going to have the most intimate knowledge about |
15 |
these types of issues in the package, so I would rather have the maintainer |
16 |
make these types of decisions instead of restricting him with some global policy. |
17 |
|
18 |
> > |
19 |
> > Elaborating on this, if we're talking about maintainer stabilizing it |
20 |
> > after testing it properly there is no issue, but there shouldn't be a |
21 |
> > policy to auto-mark stable |
22 |
> |
23 |
> As a maintainer, if there is an old version of a package in stable for |
24 |
> some arch and I have a stable request open for a newer version and the |
25 |
> arch team doesn't respond to the stable request within a reasonable |
26 |
> amount of time, I want to do one of two things: |
27 |
> |
28 |
> - destabilize all versions of the package on this arch. That would allow |
29 |
> me to move on and take the worry about stabilizing this package off of |
30 |
> the arch team in the future. or |
31 |
> - if there are no blockers, stabilize the new version and deal with the |
32 |
> fallout myself if there is any. |
33 |
> |
34 |
> If there is not an old version of the package marked stable, closing the |
35 |
> stablereq and moving on is probably what I would do after a certain |
36 |
> amount of time. |
37 |
> |
38 |
> Maintaining a viable stable tree is a team effort between the |
39 |
> maintainers and the arch teams. If the arch teams are so overwhelmed |
40 |
> with stable requests that they can't keep things current, the |
41 |
> maintainers should be able to stabilize the newer versions and deal with |
42 |
> the fallout as a last resort, or decide that they don't want their |
43 |
> packages stable on those arches until the arch teams can keep up. |
44 |
> |
45 |
> William |
46 |
> |