| 1 |
On Mon, Jul 10, 2017 at 7:54 PM, Andrew Savchenko <bircoph@g.o> wrote: |
| 2 |
> On Mon, 10 Jul 2017 16:27:54 -0400 Rich Freeman wrote: |
| 3 |
>> On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt <m.j.everitt@×××.org> wrote: |
| 4 |
>> > This is why stabilisation, if not for individual package maintainers on |
| 5 |
>> > amd64, has become a joke, save for Ago's efforts, and recent efforts by |
| 6 |
>> > kensington to streamline the effort for the likes of ago with his bot, |
| 7 |
>> > and one or two other arch stabilisers (who I know exist, but not by name |
| 8 |
>> > or nick). |
| 9 |
>> |
| 10 |
>> Sure. If nobody is maintaining stable keywords on an arch, then there |
| 11 |
>> shouldn't be stable keywords on that arch, unless the stable keywords |
| 12 |
>> are used for a different purpose and maintainers are free to downgrade |
| 13 |
>> them at any time. |
| 14 |
> |
| 15 |
> I'm confused, again. I can't find any official policy regarding |
| 16 |
> dekeywording packages from stable to testing. |
| 17 |
|
| 18 |
I tried to find the best documented answers I could to your questions, |
| 19 |
but as has been mentioned our documentation around what really goes on |
| 20 |
with arch keywording today is poor. This was one of the drivers for |
| 21 |
the stable-wg. |
| 22 |
|
| 23 |
> |
| 24 |
> Can developers remove packages from stable on whim or only on |
| 25 |
> certain conditions? Under what conditions exactly? Should arch |
| 26 |
> teams be notified on such actions? Or even requested permissions |
| 27 |
> from? |
| 28 |
|
| 29 |
"If a maintainer has an open STABLEREQ, or a KEYWORDREQ blocking a |
| 30 |
pending STABLEREQ, for 90 days with archs CCed and otherwise ready |
| 31 |
to be stabilized, the maintainer can remove older versions of |
| 32 |
the package at their discretion. A package is considered ready to be |
| 33 |
stabilized if it has been in the tree for 30 days, and has no known |
| 34 |
major flaws on arches that upstream considers supported." [1] |
| 35 |
|
| 36 |
Note that this only pertains to stable arches. For a non-stable arch |
| 37 |
there are no restrictions on the removal of the last stable version as |
| 38 |
far as I'm aware. |
| 39 |
|
| 40 |
> |
| 41 |
> IMO a valid reason to remove from stable is arch team failure to |
| 42 |
> stabilize this package for a long time. But how long? Month, two, |
| 43 |
> half a year? |
| 44 |
|
| 45 |
90 days, per the above. |
| 46 |
|
| 47 |
> |
| 48 |
> What to do with reverse dependencies? Should they be dropped to |
| 49 |
> ~arch altogether with the package in question? Or should their |
| 50 |
> maintainers be given a warning before? How long to wait after? |
| 51 |
> One more month or two, another half a year? |
| 52 |
|
| 53 |
They need to be dropped to ~arch as well, at the same time the stable |
| 54 |
version is removed. In practice this is painful and this was one of |
| 55 |
the drivers for the stable-wg. The 90 day relief the Council provided |
| 56 |
did not completely solve this problem. |
| 57 |
|
| 58 |
> |
| 59 |
> A well established arch -> ~arch policy should help to keep number |
| 60 |
> of stable packages sane and manageable for arch teams. A well |
| 61 |
> established policy of doing ~arch -> arch by devs themselves will |
| 62 |
> help to lower load on arch teams as well. So for everyone be happy |
| 63 |
> (arch teams by keeping them stable and manageable, devs by solving |
| 64 |
> stabilization requests in a sane time) we need good policies! |
| 65 |
> |
| 66 |
|
| 67 |
A big problem historically is that it is much easier to go from |
| 68 |
~arch->arch than it is to go from arch->~arch. I think well-meaning |
| 69 |
users of minor arches enthusiastically deal with STABLEREQ bugs so |
| 70 |
that there are more stable packages available on the arch. However, |
| 71 |
once whatever itch they had was scratched they don't necessarily keep |
| 72 |
up with future requests on the same package, causing the package to |
| 73 |
become stale. |
| 74 |
|
| 75 |
The intent of the 90 day policy was to make it easier to drop keywords |
| 76 |
back. However, without scripts/etc to make this simple for |
| 77 |
maintainers most don't actually take advantage of this opportunity. |
| 78 |
|
| 79 |
It has also been rightly pointed out that this is a bit of a chaotic |
| 80 |
solution to the problem. If the minor arch doesn't keep up with |
| 81 |
stable keywords on a core dependency somebody running one of these |
| 82 |
scripts might remove almost all the stable keywords for that arch in |
| 83 |
the entire tree. The counter argument is that these core dependencies |
| 84 |
are the ones the arch team should be paying the most attention to, and |
| 85 |
if they spent more time stabilizing boring libraries and less time |
| 86 |
stabilizing applications maybe the problem wouldn't exist. |
| 87 |
|
| 88 |
GLEP 40 has been mentioned and this is an interesting policy and the |
| 89 |
way it is being mentioned makes it moreso. At the time it was written |
| 90 |
everything contained within was already being done on all the arches |
| 91 |
EXCEPT x86, where maintainers were doing their own stabilizations. |
| 92 |
Since the amd64 team was viewed as a model of best practice at the |
| 93 |
time the purpose of the GLEP was to make x86 the same as the other |
| 94 |
arches. Since then manpower and interests have changed, and amd64 |
| 95 |
initially just gave individual maintainers a go-ahead to do their own |
| 96 |
stabilizations and then eventually a blanket authorization for anybody |
| 97 |
to do so. Ironically this makes x86 the only arch with a documented |
| 98 |
arch testing policy in a GLEP. |
| 99 |
|
| 100 |
I can't find any documentation of the amd64 exception. I think it |
| 101 |
goes all the way back to kingtaco. |
| 102 |
|
| 103 |
|
| 104 |
1 - https://projects.gentoo.org/council/meeting-logs/20131119-summary.txt |
| 105 |
|
| 106 |
-- |
| 107 |
Rich |
Archives