[gentoo-dev] [RFC] Improve policy of stabilizations

[gentoo-dev] [RFC] Improve policy of stabilizations

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 526 bytes --]

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.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [RFC] Improve policy of stabilizations

[Mart Raudsepp]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

On Sun, 2009-11-01 at 17:36 +0100, Arfrever Frehtes Taifersar Arahesis
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 am not aware of there being a 30 day policy, and have always
considered it as a guideline, not policy. If the maintainer sees that 10
days is good for the package sometimes, I see no problem with it. Arch
teams might kindly request explanations of why the quicker
stabilization, but I don't represent any myself, but in case of quicker
stabilization of package I maintain myself I try to state in the
STABLEREQ bug why the quicker stabilization.

Is it stated in any documentation that 30 days is a policy?

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] [RFC] Improve policy of stabilizations

[Richard Freeman]

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.

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.

We don't need to be Debian stable, but if the only reason for 
stabilizing a package is that upstream has already moved on, then I 
think we're making a mistake.  In fact, if upstream abandoned a release 
after only two weeks that would be a good reason NOT to stabilize it.

End users can always run ~arch if they need to - at least this way they 
know in advance what they're getting into.

Re: [gentoo-dev] [RFC] Improve policy of stabilizations

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Markos Chandras]

[-- Attachment #1: Type: Text/Plain, Size: 1234 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 790 bytes --]

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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Ben de Groot]

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)
______________________________________________________

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

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/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Tobias Klausmann]

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.

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Nirbheek Chauhan]

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

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Joseph Jezak]

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

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On Wed, 04 Nov 2009 16:02:16 -0500
Joseph Jezak <josejx@gentoo.org> wrote:

> 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.

Is there any interest in allowing certain packages to be stabilized by the
maintainer without going through the arch teams?  I always feel guilty when i
file stabilization bugs for app-doc pkgs.


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Tobias Klausmann]

Hi! 

On Wed, 04 Nov 2009, Ryan Hill wrote:
> Is there any interest in allowing certain packages to be stabilized by the
> maintainer without going through the arch teams?  I always feel guilty when i
> file stabilization bugs for app-doc pkgs.

I think for bugs which only install passive files (i.e. stuff
that doesn't "power" anything else), Keywording can be done by the
maintainer. Pure doc files (like selfhtml) are in that category.

Naturally, if a new version needs a new doc processing toolchain,
things are a bit different.

But as far as alpha is concerned: go ahead.

Regards,
Tobias

PS: I considered allowing the doc processing stuff, too, but it's
astoundingly easy to break some fairly important stuff just my
messing up DTDs.

-- 
printk("Pretending it's a 3/80, but very afraid...\n");
	linux-2.6.19/arch/m68k/sun3x/prom.c

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Duncan]

Ryan Hill posted on Wed, 04 Nov 2009 21:48:23 -0600 as excerpted:

> Is there any interest in allowing certain packages to be stabilized by
> the maintainer without going through the arch teams?  I always feel
> guilty when i file stabilization bugs for app-doc pkgs.

Weren't there already arrangements for this in some cases?  I distinctly 
recall a thread on it some time ago, with the conclusion being that 
various maintainers can get permission from the arch teams to keyword 
their own packages.

Now that was in the /general/ context of having access to the arch either 
directly/personally or thru available testing resource machines, but (as 
klausman accounts for in his post) that really doesn't apply to (for 
example) docs packages that don't require fancy build-chains or (with 
some sanity margin) where the build chain dependencies have been long 
stable, so "required testing resources" are virtually zero.

Thus, I'd say it's probably an extension of the previous arrangement -- 
but of course that does still require an initial one-time permission 
grant per arch, either per-package, or depending on arch/pkg-maintainer 
trust level, possible per category or similar.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Tobias Klausmann wrote:
> Hi! 
> 
> On Wed, 04 Nov 2009, Ryan Hill wrote:
>> Is there any interest in allowing certain packages to be stabilized by the
>> maintainer without going through the arch teams?  I always feel guilty when i
>> file stabilization bugs for app-doc pkgs.
> 
> I think for bugs which only install passive files (i.e. stuff
> that doesn't "power" anything else), Keywording can be done by the
> maintainer. Pure doc files (like selfhtml) are in that category.
> 

In the past when smaller arches were not that active we used to mark
Java packages stable after testing by at least one arch team. The
probability to find arch specific issues in something like Java is not
so high so I think arrangements like this are acceptable when the arch
teams have problems keeping up.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Joseph Jezak]

> In the past when smaller arches were not that active we used to mark
> Java packages stable after testing by at least one arch team. The
> probability to find arch specific issues in something like Java is not
> so high so I think arrangements like this are acceptable when the arch
> teams have problems keeping up.
>   
I do know that for Java stuff, I certainly wouldn't mind if the Java
team marked for ppc/ppc64. The only thing that I'd need to know is that
it was tested with the IBM JVM since there certainly are differences
between that and the Sun one most people use on x86/amd64 and we've seen
issues in the past.

-Joe

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Nirbheek Chauhan]

On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> In the past when smaller arches were not that active we used to mark
> Java packages stable after testing by at least one arch team. The
> probability to find arch specific issues in something like Java is not
> so high so I think arrangements like this are acceptable when the arch
> teams have problems keeping up.
>

I think the same should be extended to other languages such as Perl
and Python (unless they have portions which are C/C++)


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Fabian Groffen]

On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> > In the past when smaller arches were not that active we used to mark
> > Java packages stable after testing by at least one arch team. The
> > probability to find arch specific issues in something like Java is not
> > so high so I think arrangements like this are acceptable when the arch
> > teams have problems keeping up.
> 
> I think the same should be extended to other languages such as Perl
> and Python (unless they have portions which are C/C++)

Sounds like we could benefit from the "noarch" approach known in the RPM
world, such that all these packages can also be immediately keyworded
and stabilised for all arches.  Would greatly simplify things for a
great deal of packages, maybe?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Sat, Nov 7, 2009 at 3:18 AM, Nirbheek Chauhan <nirbheek@gentoo.org>wrote:

> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org>
> wrote:
> > In the past when smaller arches were not that active we used to mark
> > Java packages stable after testing by at least one arch team. The
> > probability to find arch specific issues in something like Java is not
> > so high so I think arrangements like this are acceptable when the arch
> > teams have problems keeping up.
> >
>
> I think the same should be extended to other languages such as Perl
> and Python (unless they have portions which are C/C++)
>
>
You can't really, although Perl has a vm of sorts,  the per-arch differences
that occur as a side effect of endianness, different floating point/integer
math ( 32bit vs 64bit ) , and all those differences impact code.

and XS modules of course, they're prone to everything C is prone to.

-- 
Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 )
for ( 9,8,0,7,1,6,5,4,3,2 );"

http://kent-fredric.fox.geek.nz

[-- Attachment #2: Type: text/html, Size: 1600 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Nirbheek Chauhan]

On Fri, Nov 6, 2009 at 9:30 PM, Kent Fredric <kentfredric@gmail.com> wrote:
> On Sat, Nov 7, 2009 at 3:18 AM, Nirbheek Chauhan <nirbheek@gentoo.org>
>> I think the same should be extended to other languages such as Perl
>> and Python (unless they have portions which are C/C++)
>>
>
> You can't really, although Perl has a vm of sorts,  the per-arch differences
> that occur as a side effect of endianness, different floating point/integer
> math ( 32bit vs 64bit ) , and all those differences impact code.
>

What kind of modules are affected by such differences? Mostly
math-heavy ones? This is something that the herd should be able to
judge.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Nirbheek Chauhan]

On Fri, Nov 6, 2009 at 8:15 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> Sounds like we could benefit from the "noarch" approach known in the RPM
> world, such that all these packages can also be immediately keyworded
> and stabilised for all arches.  Would greatly simplify things for a
> great deal of packages, maybe?
>

This is a good idea; themes, wallpapers, fonts, game-data (stuff that
mostly installs into /usr/share) could easily fall in this category. A
lot of python modules are arch-independant as well (upstream has been
thinking of splitting the install structure to put such things in
/usr/share/python2.6/<etc>).

Examples of packages:
gnome-extra/gnome-games-extra-data
x11-themes/gnome-icon-theme
kde-base/kdebase-wallpapers
games-fps/quake3-data
app-text/poppler-data
media-fonts/dejavu

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Nirbheek Chauhan]

On Fri, Nov 6, 2009 at 10:36 PM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> On Fri, Nov 6, 2009 at 8:15 PM, Fabian Groffen <grobian@gentoo.org> wrote:
>> Sounds like we could benefit from the "noarch" approach known in the RPM
>> world, such that all these packages can also be immediately keyworded
>> and stabilised for all arches.  Would greatly simplify things for a
>> great deal of packages, maybe?
>>
>
> This is a good idea; themes, wallpapers, fonts, game-data (stuff that
> mostly installs into /usr/share) could easily fall in this category. A
> lot of python modules are arch-independant as well (upstream has been
> thinking of splitting the install structure to put such things in
> /usr/share/python2.6/<etc>).
>

One exception: we cannot be sure such things will install/work on
x86-fbsd and prefix archs since the differences are more than just
"architecture".

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

Hi,

Joseph Jezak <josejx@gentoo.org>:
> 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.

 Maybe using the priority field should be forced, filtering Bugzilla
queries is then easier.

V-Li

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 608 bytes --]

Hi,

Ryan Hill <dirtyepic@gentoo.org>:
> Is there any interest in allowing certain packages to be stabilized
> by the maintainer without going through the arch teams?  I always
> feel guilty when i file stabilization bugs for app-doc pkgs.

 I will not put any obstacles in the way, if you just do it for
packages with no processing.  Honestly, I do it for
x11-themes/claws-mail-themes because it only installs some graphic
files.

V-Li

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Zac Medico]

Fabian Groffen wrote:
> On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
>> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
>>> In the past when smaller arches were not that active we used to mark
>>> Java packages stable after testing by at least one arch team. The
>>> probability to find arch specific issues in something like Java is not
>>> so high so I think arrangements like this are acceptable when the arch
>>> teams have problems keeping up.
>> I think the same should be extended to other languages such as Perl
>> and Python (unless they have portions which are C/C++)
> 
> Sounds like we could benefit from the "noarch" approach known in the RPM
> world, such that all these packages can also be immediately keyworded
> and stabilised for all arches.  Would greatly simplify things for a
> great deal of packages, maybe?

We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
the default ACCEPT_KEYWORDS setting for all profiles, and instruct
unstable users to add "~noarch" to ACCEPT_KEYWORDS.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Rémi Cardona]

Le 06/11/2009 15:45, Fabian Groffen a écrit :
> Sounds like we could benefit from the "noarch" approach known in the RPM
> world, such that all these packages can also be immediately keyworded
> and stabilised for all arches.  Would greatly simplify things for a
> great deal of packages, maybe?

While this is probably a good idea in theory, I can't help but think it 
won't really help us.

For example, in other distros, X11 protocols headers (x11-proto/*) are 
marked as "noarch" [1]. With the recent mess that happened in X 
libs/protos, "noarch" is something we'll never be able to use for those 
packages because the stabilization of "noarch" and "arch" packages need 
to happen all at the same time. Other distros don't have different 
package versions across arches. We do...

So as far as I'm concerned, "noarch" will be of very limited use to us, 
maybe a few X cursor themes, that's about it. It's not the kind of 
packages that get a frequent releases anyway.

I just don't see how "noarch" will help the portage tree.

However, I would like to see the council get in touch with "problematic" 
arch teams *more* *often* to see what their status is, and maybe be more 
proactive when it comes to putting an arch to the dev status.

Cheers,

Rémi

[1] 
http://cvs.fedoraproject.org/viewvc/rpms/xorg-x11-proto-devel/devel/xorg-x11-proto-devel.spec?view=markup

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 1301 bytes --]

2009-11-06 23:07:58 Zac Medico napisał(a):
> Fabian Groffen wrote:
> > On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> >> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>> In the past when smaller arches were not that active we used to mark
> >>> Java packages stable after testing by at least one arch team. The
> >>> probability to find arch specific issues in something like Java is not
> >>> so high so I think arrangements like this are acceptable when the arch
> >>> teams have problems keeping up.
> >> I think the same should be extended to other languages such as Perl
> >> and Python (unless they have portions which are C/C++)
> > 
> > Sounds like we could benefit from the "noarch" approach known in the RPM
> > world, such that all these packages can also be immediately keyworded
> > and stabilised for all arches.  Would greatly simplify things for a
> > great deal of packages, maybe?
> 
> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> unstable users to add "~noarch" to ACCEPT_KEYWORDS.

It seems to be a good idea, but I would prefer to use words "universal"
and "~universal" :) .

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Fri, 6 Nov 2009 22:36:05 +0530
Nirbheek Chauhan <nirbheek@gentoo.org> wrote:

> On Fri, Nov 6, 2009 at 8:15 PM, Fabian Groffen <grobian@gentoo.org> wrote:
> > Sounds like we could benefit from the "noarch" approach known in the RPM
> > world, such that all these packages can also be immediately keyworded
> > and stabilised for all arches.  Would greatly simplify things for a
> > great deal of packages, maybe?
> >
> 
> This is a good idea; themes, wallpapers, fonts, game-data (stuff that
> mostly installs into /usr/share) could easily fall in this category. A
> lot of python modules are arch-independant as well (upstream has been
> thinking of splitting the install structure to put such things in
> /usr/share/python2.6/<etc>).
> 
> Examples of packages:
> gnome-extra/gnome-games-extra-data
> x11-themes/gnome-icon-theme
> kde-base/kdebase-wallpapers
> games-fps/quake3-data
> app-text/poppler-data
> media-fonts/dejavu

dejavu isn't a good example as it's (optionally) built with fontforge.  but
other fonts that are basically unpack and install are.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Fri, 2009-11-06 at 23:52 +0100, Rémi Cardona wrote:

> I just don't see how "noarch" will help the portage tree.

I would propose to use it for the 100+ app-xemacs packages, all of which
run within the virtual machine that is xemacs. Obviously
app-editors/xemacs, the editor itself, will still be keyworded for each
arch, but the chance of running into arch-specific issues with the
packages is very small, and they are released independently from the
editor.

The same thing may apply to a number of dev-ruby/* packages (those
installing only ruby code), but that would need per-package
investigation.

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Tobias Klausmann]

Hi! 

On Thu, 05 Nov 2009, Petteri Räty wrote:
> In the past when smaller arches were not that active we used to
> mark Java packages stable after testing by at least one arch
> team. The probability to find arch specific issues in something
> like Java is not so high so I think arrangements like this are
> acceptable when the arch teams have problems keeping up.

For alpha, the java keywording policy is easy: don't.

We currently don't have any working JVM/JRE/JDK, so there's no
point in adding Java packages.

We *do* have dev-java/java-config keyworded, though the reason
escapes me at the moment :)

Regards,
Tobias

-- 
printk("NONONONOO!!!!\n");
        linux-2.6.6/drivers/atm/zatm.c

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Peter Volkov]

В Птн, 06/11/2009 в 14:07 -0800, Zac Medico пишет:
> Fabian Groffen wrote:
> > On 06-11-2009 19:48:16 +0530, Nirbheek Chauhan wrote:
> >> On Fri, Nov 6, 2009 at 1:42 AM, Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>> In the past when smaller arches were not that active we used to mark
> >>> Java packages stable after testing by at least one arch team. The
> >>> probability to find arch specific issues in something like Java is not
> >>> so high so I think arrangements like this are acceptable when the arch
> >>> teams have problems keeping up.
> >> I think the same should be extended to other languages such as Perl
> >> and Python (unless they have portions which are C/C++)
> > 
> > Sounds like we could benefit from the "noarch" approach known in the RPM
> > world, such that all these packages can also be immediately keyworded
> > and stabilised for all arches.  Would greatly simplify things for a
> > great deal of packages, maybe?
> 
> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> unstable users to add "~noarch" to ACCEPT_KEYWORDS.

Looks like this will not work for all noarch packages. Stardict
dictionary itself is noarch, but it RDEPENDS on stardict package which
is keyworded only on some archs. So we'll be forced either to keyword
stardict on all archs or we need to introduce some new way to work with
such situations.


-- 
Peter.

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Zac Medico]

Peter Volkov wrote:
>> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
>> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
>> unstable users to add "~noarch" to ACCEPT_KEYWORDS.
> 
> Looks like this will not work for all noarch packages. Stardict
> dictionary itself is noarch, but it RDEPENDS on stardict package which
> is keyworded only on some archs. So we'll be forced either to keyword
> stardict on all archs or we need to introduce some new way to work with
> such situations.

Keywording stardict on all archs doesn't sound reasonable, so I
guess we just need to make sure that repoman will allow the noarch
keyword even though the dependencies aren't keyworded on all
architectures.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Nirbheek Chauhan]

On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico <zmedico@gentoo.org> wrote:
> Peter Volkov wrote:
>> Looks like this will not work for all noarch packages. Stardict
>> dictionary itself is noarch, but it RDEPENDS on stardict package which
>> is keyworded only on some archs. So we'll be forced either to keyword
>> stardict on all archs or we need to introduce some new way to work with
>> such situations.
>
> Keywording stardict on all archs doesn't sound reasonable, so I
> guess we just need to make sure that repoman will allow the noarch
> keyword even though the dependencies aren't keyworded on all
> architectures.

I think we're going a little far trying to solve a management problem
with technology. If a herd thinks that a particular package can be
safely keyworded (or stabilized) other arches (it just dumps data, is
a simple python module, etc); they should make the call and just do
it.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Fabian Groffen]

On 07-11-2009 17:54:25 +0300, Peter Volkov wrote:
> > > Sounds like we could benefit from the "noarch" approach known in the RPM
> > > world, such that all these packages can also be immediately keyworded
> > > and stabilised for all arches.  Would greatly simplify things for a
> > > great deal of packages, maybe?
> > 
> > We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> > the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> > unstable users to add "~noarch" to ACCEPT_KEYWORDS.
> 
> Looks like this will not work for all noarch packages. Stardict
> dictionary itself is noarch, but it RDEPENDS on stardict package which
> is keyworded only on some archs. So we'll be forced either to keyword
> stardict on all archs or we need to introduce some new way to work with
> such situations.

Would it be reasonable to just mask in such case?  Resolution would
eventually just hit the masked stardict dictionary and display the
reason why it's masked (stardict doesn't compile, not yet looked into
keywording: please try, etc.)


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Petteri Räty]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Nirbheek Chauhan wrote:
> On Sun, Nov 8, 2009 at 2:19 AM, Zac Medico <zmedico@gentoo.org> wrote:
>> Peter Volkov wrote:
>>> Looks like this will not work for all noarch packages. Stardict
>>> dictionary itself is noarch, but it RDEPENDS on stardict package which
>>> is keyworded only on some archs. So we'll be forced either to keyword
>>> stardict on all archs or we need to introduce some new way to work with
>>> such situations.
>> Keywording stardict on all archs doesn't sound reasonable, so I
>> guess we just need to make sure that repoman will allow the noarch
>> keyword even though the dependencies aren't keyworded on all
>> architectures.
> 
> I think we're going a little far trying to solve a management problem
> with technology. If a herd thinks that a particular package can be
> safely keyworded (or stabilized) other arches (it just dumps data, is
> a simple python module, etc); they should make the call and just do
> it.
> 

But we should still have a way to express this in package metadata in
some way so it's clear that this is that kind of a package. What zmedico
suggested does this nicely but other ways can be used too.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Peter Volkov]

В Вск, 08/11/2009 в 10:05 +0100, Fabian Groffen пишет:
> On 07-11-2009 17:54:25 +0300, Peter Volkov wrote:
> > > We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> > > the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> > > unstable users to add "~noarch" to ACCEPT_KEYWORDS.
> > 
> > Looks like this will not work for all noarch packages. Stardict
> > dictionary itself is noarch, but it RDEPENDS on stardict package which
> > is keyworded only on some archs. So we'll be forced either to keyword
> > stardict on all archs or we need to introduce some new way to work with
> > such situations.
> 
> Would it be reasonable to just mask in such case?  Resolution would
> eventually just hit the masked stardict dictionary and display the
> reason why it's masked (stardict doesn't compile, not yet looked into
> keywording: please try, etc.)

As I understand: absense of ~arch keyword means package is masked on
~arch since nobody yet looked at this package.

I was asking here: since noarch is allowed on all archs, how this noarch
over arch KEYWORD stacking may work?

-- 
Peter.

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Peter Volkov]

В Сбт, 07/11/2009 в 12:49 -0800, Zac Medico пишет:
> Peter Volkov wrote:
> >> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
> >> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
> >> unstable users to add "~noarch" to ACCEPT_KEYWORDS.
> > 
> > Looks like this will not work for all noarch packages. Stardict
> > dictionary itself is noarch, but it RDEPENDS on stardict package which
> > is keyworded only on some archs. So we'll be forced either to keyword
> > stardict on all archs or we need to introduce some new way to work with
> > such situations.
> 
> Keywording stardict on all archs doesn't sound reasonable, so I
> guess we just need to make sure that repoman will allow the noarch
> keyword even though the dependencies aren't keyworded on all
> architectures.

But how will portage handle such situations? Will it allow installation
of noarch package and pull in *DEPEND only if possible, or will it
prohibit installation of noarch pkgs with unsatisfied deps? The latter
will make life harder for tools like eix, I guess.

-- 
Peter.

Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations

[Zac Medico]

Peter Volkov wrote:
> В Сбт, 07/11/2009 в 12:49 -0800, Zac Medico пишет:
>> Peter Volkov wrote:
>>>> We could introduce "noarch" and "~noarch" KEYWORDS, add "noarch" to
>>>> the default ACCEPT_KEYWORDS setting for all profiles, and instruct
>>>> unstable users to add "~noarch" to ACCEPT_KEYWORDS.
>>> Looks like this will not work for all noarch packages. Stardict
>>> dictionary itself is noarch, but it RDEPENDS on stardict package which
>>> is keyworded only on some archs. So we'll be forced either to keyword
>>> stardict on all archs or we need to introduce some new way to work with
>>> such situations.
>> Keywording stardict on all archs doesn't sound reasonable, so I
>> guess we just need to make sure that repoman will allow the noarch
>> keyword even though the dependencies aren't keyworded on all
>> architectures.
> 
> But how will portage handle such situations? Will it allow installation
> of noarch package and pull in *DEPEND only if possible, or will it
> prohibit installation of noarch pkgs with unsatisfied deps? The latter
> will make life harder for tools like eix, I guess.

It should prohibit installation if there are unsatisfied deps. If
you want "optional" dependencies then that will require a syntax
extension with an EAPI bump.
-- 
Thanks,
Zac