| 1 |
On Tue, 25 Jul 2017 09:22:08 +0200 |
| 2 |
Dirkjan Ochtman <djc@g.o> wrote: |
| 3 |
|
| 4 |
> Second, I believe a lot of the value in our stable tree comes *just* |
| 5 |
> from the requirement that stabilization is only requested after 30 |
| 6 |
> days without major bugs/changes in the unstable tree. Assuming there |
| 7 |
> are enough users of a package on unstable, that means important bugs |
| 8 |
> can be shaken out before a version hits stable. This could mean that |
| 9 |
> potentially, even if we inverted our entire model to say we |
| 10 |
> "automatically" stabilize after a 30-day period without major bugs, |
| 11 |
> we hit most of the value of the stable tree with again drastically |
| 12 |
> reduced pain/work. |
| 13 |
|
| 14 |
I’m a stable user when I can be. I use Gentoo for the configurability, |
| 15 |
not for instant access to the newest versions of things. |
| 16 |
|
| 17 |
I think this is a fairly reasonable proposal if stabilization is |
| 18 |
otherwise happening too slowly right now. If 30 days with no bugs plus |
| 19 |
an automated successful build against an otherwise-stable set of |
| 20 |
dependencies led to an automatic stabilization, I’d be fine with that. |
| 21 |
Some clarification would be needed on what bugs block stabilization, |
| 22 |
and of course there would need to be a flag that maintainers could add |
| 23 |
to specific ebuilds to indicate whether or not they’re stabilization |
| 24 |
candidates (though I wonder if it would be better to flag the ones that |
| 25 |
*aren’t* candidates, rather than the ones that *are*). |
| 26 |
-- |
| 27 |
Christopher Head |
Archives