1 |
On Mon, Aug 15, 2016 at 02:33:52PM -0400, Rich Freeman wrote: |
2 |
> I'm fine with maintainers de-keywording packages on their own |
3 |
> initiative. However, if a maintainer hasn't even built a package on |
4 |
> an arch, they shouldn't be stabilizing it on that arch. That would |
5 |
> make the concept of stable meaningless. If it is just ~arch plus a |
6 |
> time delay, then we should just get rid of the stable keywords and |
7 |
> instead have portage just filter packages by the date they were |
8 |
> committed to ~arch. |
9 |
|
10 |
ok, this makes sense. |
11 |
|
12 |
> I'd rather see maintainers just yank the last stable package and break |
13 |
> the depgraph and let the arch teams deal with the cleanup than have |
14 |
> them mark stuff stable without any testing at all. Or build a script |
15 |
> that does the keyword cleanup for them. De-keywording late stable |
16 |
> requests is a solution that is self-correcting. As packages are |
17 |
> reduced from the stable set then there are fewer stable requests and |
18 |
> the arch team is better able to focus on the ones they deem important. |
19 |
> Throwing more packages in stable that aren't actually stable just |
20 |
> makes that problem worse, and destroys whatever value the stable |
21 |
> keyword had on the arch. For small arch teams they really should be |
22 |
> focusing their time on core packages. |
23 |
|
24 |
Rich, This was my original thinking about this issue. It turned out to |
25 |
be more controversial than I originally thought -- folks told me that |
26 |
stable tree users expect stability above all, so breaking the depgraph |
27 |
is unacceptable, so I'm just trying to find something that is more |
28 |
palletable. |
29 |
|
30 |
I have a few bugs right now where I haven't done this because I know it |
31 |
is going to require "repoman commit --force" to work, and set of our ci |
32 |
alarms etc. Should I not care about that and just let the arch teams |
33 |
clean it up? |
34 |
|
35 |
William |