| 1 |
On 11/17/2016 02:47 PM, Michael Palimaka wrote: |
| 2 |
> On 18/11/16 00:26, Kristian Fiskerstrand wrote: |
| 3 |
>> Strictly speaking GLEP 40 forbids it still, although some arch teams |
| 4 |
>> have made announcements to approve it, see e.g [1,2]. I wouldn't be |
| 5 |
>> surprised if one of the results of the stable WG is an updated GLEP 40 |
| 6 |
>> that (new GLEP replacing existing) that allows for MAINTAINER |
| 7 |
>> self-stabilization. Personally I don't like "any developer may perform" |
| 8 |
>> part of it. The maintainer is responsible, and should at least ack |
| 9 |
>> stabilization at all before anything is stabilized (for arch-team |
| 10 |
>> stabilization as well), and consequently individual stabilizations by |
| 11 |
>> developers, either the maintainer itself or someone with applicable |
| 12 |
>> hardware. |
| 13 |
> |
| 14 |
> Isn't it implied that any stabilisation is approved by the maintainer? |
| 15 |
> Has it ever been acceptable to go around stabilising random packages? |
| 16 |
> |
| 17 |
|
| 18 |
Explicit > Implicit when we're updating things anyways. |
| 19 |
|
| 20 |
There are scenarios where e.g Security is calling for stabilization , |
| 21 |
I'll add some info to the draft security GLEP with some requirements for |
| 22 |
when this can happen without maintainer involvement as well.. |
| 23 |
|
| 24 |
Ultimately maintainer is responsible for the state of the stable tree |
| 25 |
for the packages they maintain and should be taking proactive steps for |
| 26 |
this also for security bugs, it doesn't "always" happen like that..... |
| 27 |
|
| 28 |
-- |
| 29 |
Kristian Fiskerstrand |
| 30 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
| 31 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |
Archives