Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Improve policy of stabilizations (http://www.linux-archive.org/gentoo-development/272949-improve-policy-stabilizations.html)

Petteri Räty 11-01-2009 07:21 PM

Improve policy of stabilizations
 
Richard Freeman wrote:
> Mart Raudsepp wrote:
>>
>> Is it stated in any documentation that 30 days is a policy?
>>
>
> Not that I'm aware of - it is a guideline as you indicate. However,
> don't expect anybody to actually take action on a STABLEREQ if there
> isn't some kind of rationale for going stable so quickly.
>

Yes it's a guideline that you should follow unless you can give reasons
to deviate.

>
> The whole point of stable is that they provide some sanity to the
> release process - if upstream releases a new version every other week
> then perhaps we should either:
>
> 1. Question whether it should go stable at all.
> 2. Pick a version once in a while and target it for stabilization,
> backporting fixes as needed.
>

Yeah one can question if adding every release is really important for users.

Regards,
Petteri

Ryan Hill 11-01-2009 08:16 PM

Improve policy of stabilizations
 
On Sun, 1 Nov 2009 17:36:30 +0100
Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org> wrote:

> Some packages have new releases more than once a month and sometimes it's reasonable
> to not skip stabilization of any version. Given version of a package is usually no
> longer tested by users after release of a newer version, so I suggest the following
> change to the policy of stabilizations:
> Stabilization of given version of a package can be requested if this version has been
> in the tree for at least 10 days and a newer version of this package has been added
> to the tree.

I thought the arch teams were already overworked. Why do you need every last
version stable?


--
fonts, Character is what you are in the dark.
gcc-porting,
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

Christian Faulhammer 11-02-2009 01:17 PM

Improve policy of stabilizations
 
Hi,

Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org>:

> Some packages have new releases more than once a month and sometimes
> it's reasonable to not skip stabilization of any version. Given
> version of a package is usually no longer tested by users after
> release of a newer version, so I suggest the following change to the
> policy of stabilizations: Stabilization of given version of a package
> can be requested if this version has been in the tree for at least 10
> days and a newer version of this package has been added to the tree.

If you do that, you will see arch teams skip those stabilisations in a
daily rhythm. Honestly, who should do that work? Having every minor
release stable is a big nuisance for arch workers.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

Markos Chandras 11-02-2009 02:23 PM

Improve policy of stabilizations
 
On Monday 02 November 2009 16:17:07 Christian Faulhammer wrote:
> Hi,
>
> Arfrever Frehtes Taifersar Arahesis <Arfrever@gentoo.org>:
> > Some packages have new releases more than once a month and sometimes
> > it's reasonable to not skip stabilization of any version. Given
> > version of a package is usually no longer tested by users after
> > release of a newer version, so I suggest the following change to the
> > policy of stabilizations: Stabilization of given version of a package
> > can be requested if this version has been in the tree for at least 10
> > days and a newer version of this package has been added to the tree.
>
> If you do that, you will see arch teams skip those stabilisations in a
> daily rhythm. Honestly, who should do that work? Having every minor
> release stable is a big nuisance for arch workers.
>
> V-Li
>
This is way I keep asking for a complete report of manpower at least for amd64
and x86 arch teams ( and update the project pages as well ). We need real
numbers so we adjust respectively the number of stabilization bugs we assign
to them.
--
Markos Chandras (hwoarang)
Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
Web: http://hwoarang.silverarrow.org

Christian Faulhammer 11-03-2009 05:10 PM

Improve policy of stabilizations
 
Hi,

Markos Chandras <hwoarang@gentoo.org>:
> This is way I keep asking for a complete report of manpower at least
> for amd64 and x86 arch teams ( and update the project pages as
> well ). We need real numbers so we adjust respectively the number of
> stabilization bugs we assign to them.

x86 is at the moment three people active (maekke doing the biggest
load, armin76 and myself). In the past I asked current members to
state if they want to stay on the team or if they leave...I won't throw
out anyone.
amd64 is ssuominen, darkside and maekke, then some people doing
occasional work like chainsaw.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

Ben de Groot 11-04-2009 11:36 AM

Improve policy of stabilizations
 
What about ppc64? They are MONTHS behind on stabilization,
even for security bugs (see bug 281821 for example). The Qt team
feels this is no longer acceptable. We propose that any arch that
can't keep up will be demoted to experimental status.

--
Ben de Groot
Gentoo Linux developer (qt, media, lxde, desktop-misc)
__________________________________________________ ____

Christian Faulhammer 11-04-2009 11:50 AM

Improve policy of stabilizations
 
Hi,

Ben de Groot <yngwin@gentoo.org>:

> What about ppc64? They are MONTHS behind on stabilization,
> even for security bugs (see bug 281821 for example). The Qt team
> feels this is no longer acceptable. We propose that any arch that
> can't keep up will be demoted to experimental status.

I surely subscribe to that. At the moment Brent (ranger) is
definitely alone on that arch.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

Tobias Klausmann 11-04-2009 05:01 PM

Improve policy of stabilizations
 
Hi!

On Wed, 04 Nov 2009, Christian Faulhammer wrote:
> Ben de Groot <yngwin@gentoo.org>:
> > What about ppc64? They are MONTHS behind on stabilization,
> > even for security bugs (see bug 281821 for example). The Qt team
> > feels this is no longer acceptable. We propose that any arch that
> > can't keep up will be demoted to experimental status.
>
> I surely subscribe to that. At the moment Brent (ranger) is
> definitely alone on that arch.

So am I on alpha.[0] It is doable, but it wears you thin - and
it's extra bad because it means I have hardly any free time to
mentor anybody.

That said, I hope whoever feels the need comes to me /before/ they
file a bug for "Let's make alpha experimental".

Regards,
Tobias


[0] Yes, armin76 helps, but he does so for many arches (and
around of applause for that), but the majority of bugs for alpha
are on my plate.

Nirbheek Chauhan 11-04-2009 07:49 PM

Improve policy of stabilizations
 
On Wed, Nov 4, 2009 at 11:31 PM, Tobias Klausmann <klausman@gentoo.org> wrote:
> [0] Yes, armin76 helps, but he does so for many arches (and
> around of applause for that), but the majority of bugs for alpha
> are on my plate.
>

+++, armin76 does an awesome job of keywording/stabilizing. I really
love how he comes down and destroys bugs with one fell swoop saying
"alpha/arm/ia64/m68k/sh/sparc done" :D

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Joseph Jezak 11-04-2009 08:02 PM

Improve policy of stabilizations
 
Ben de Groot wrote:
> What about ppc64? They are MONTHS behind on stabilization,
> even for security bugs (see bug 281821 for example). The Qt team
> feels this is no longer acceptable. We propose that any arch that
> can't keep up will be demoted to experimental status.
>
>
ppc is also fairly far behind (much thanks to nixnut for keeping us
going!). Part of the problem is that when I do get time to catch up,
we're so buried in bugs, it's time consuming just to triage and figure
out what to do next, and even to remember where I left off last.

I would really help if there were better communication about what bugs
absolutely need to be done ASAP and what can slide by for now.

That said, please be a bit more patient with us, we just don't have the
manpower to fix every single keywording bug immediately.

-Joe


All times are GMT. The time now is 04:27 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.