| 1 |
On Thu, Aug 29, 2013 at 09:16:03PM +0800, Ben de Groot wrote: |
| 2 |
> On 29 August 2013 14:09, Michael Weber <xmw@g.o> wrote: |
| 3 |
> > On 08/28/2013 01:15 PM, Markos Chandras wrote: |
| 4 |
> >> The feedback on the original question was mostly positive. |
| 5 |
> >> Most people agree that the long stabilization queues for these |
| 6 |
> >> architectures create problems |
| 7 |
> >> for maintainers wishing to drop old versions. |
| 8 |
> > Is this the only motivation? Drop all the effort that has been put into |
| 9 |
> > stabilization work on minor arches just for some impatient maintainers? |
| 10 |
> > |
| 11 |
> > Keywording/Stabilization is a process we all agreed on joining, so live |
| 12 |
> > with it. |
| 13 |
> |
| 14 |
> Minor arches holding up GLSAs and removal of vulnerable stable ebuilds |
| 15 |
> for 3 months or more is *not* acceptable, and not something I agreed |
| 16 |
> to when joining... |
| 17 |
> |
| 18 |
> If they can't even do security stabilizations in a reasonable |
| 19 |
> timeframe, they have no business being considered stable arches. |
| 20 |
|
| 21 |
I think this is a good point but again needs to be defined somewhere |
| 22 |
besides comments on a ML. If an ARCH is not able to respond to a GLSA |
| 23 |
within a reasonable timeframe due to lack of developer resources, then it |
| 24 |
shouldn't be offically supported by Gentoo Linux. |
| 25 |
|
| 26 |
The problem is that a "reasonable timeframe" is not defined AFAIK and |
| 27 |
what happens to an ARCH that fails here is not defined. Let's move away |
| 28 |
from peoples presonal idea on the matter and define a policy or GLEP. |
| 29 |
|
| 30 |
|
| 31 |
-- |
| 32 |
Jack Morgan |
| 33 |
Pub 4096R/761D8E0A 2010-09-13 Jack Morgan <jmorgan@g.o>> |
| 34 |
Fingerprint = DD42 EA48 D701 D520 C2CD 55BE BF53 C69B 761D 8E0A |
Archives