| 1 |
On Mon, Aug 15, 2016 at 1:31 PM, William Hubbs <williamh@g.o> wrote: |
| 2 |
> I want to elaborate a bit more on this. |
| 3 |
> |
| 4 |
> On Mon, Aug 15, 2016 at 11:12:41AM -0500, William Hubbs wrote: |
| 5 |
>> On Mon, Aug 15, 2016 at 04:50:38PM +0200, Kristian Fiskerstrand wrote: |
| 6 |
>> > On 08/15/2016 04:49 PM, Kristian Fiskerstrand wrote: |
| 7 |
>> > > On 08/15/2016 04:19 PM, William Hubbs wrote: |
| 8 |
>> > >> I'm very much for this as well. Themaintainer should be able to |
| 9 |
>> > >> stabilize on all arches after the timeout. That would solve the primary |
| 10 |
>> > >> concern I have about the stable tree lagging. |
| 11 |
>> > > |
| 12 |
>> > > It depends on the context, if it is not security related or fixing a |
| 13 |
>> > > known bug, it can cause regression for stable users without much gain. |
| 14 |
> |
| 15 |
> The maintainer of the package is going to have the most intimate knowledge about |
| 16 |
> these types of issues in the package, so I would rather have the maintainer |
| 17 |
> make these types of decisions instead of restricting him with some global policy. |
| 18 |
> |
| 19 |
|
| 20 |
I'm fine with maintainers de-keywording packages on their own |
| 21 |
initiative. However, if a maintainer hasn't even built a package on |
| 22 |
an arch, they shouldn't be stabilizing it on that arch. That would |
| 23 |
make the concept of stable meaningless. If it is just ~arch plus a |
| 24 |
time delay, then we should just get rid of the stable keywords and |
| 25 |
instead have portage just filter packages by the date they were |
| 26 |
committed to ~arch. |
| 27 |
|
| 28 |
I'd rather see maintainers just yank the last stable package and break |
| 29 |
the depgraph and let the arch teams deal with the cleanup than have |
| 30 |
them mark stuff stable without any testing at all. Or build a script |
| 31 |
that does the keyword cleanup for them. De-keywording late stable |
| 32 |
requests is a solution that is self-correcting. As packages are |
| 33 |
reduced from the stable set then there are fewer stable requests and |
| 34 |
the arch team is better able to focus on the ones they deem important. |
| 35 |
Throwing more packages in stable that aren't actually stable just |
| 36 |
makes that problem worse, and destroys whatever value the stable |
| 37 |
keyword had on the arch. For small arch teams they really should be |
| 38 |
focusing their time on core packages. |
| 39 |
|
| 40 |
-- |
| 41 |
Rich |
Archives