[gentoo-dev] tentative x86 arch team glep

[gentoo-dev] tentative x86 arch team glep

[Grant Goodyear]

[-- Attachment #1.1: Type: text/plain, Size: 497 bytes --]

Dear all,
  Here's a GLEP that I'm thinking about right now.  It's not yet
official, since I'd like to get some feedback beforehand (which helps to
ensure that I'm not abusing my GLEP-editor powers).  If you have
additional arguments either pro or con, please send them my way so that
I may incorporate them.

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #1.2: glep-0040.txt --]
[-- Type: text/plain, Size: 4959 bytes --]

GLEP: 40
Title: Standardizing "arch" keywording across all archs.
Version: $Revision: 1.8 $
Last-Modified: $Date: 2005/01/09 16:12:40 $
Author: Grant Goodyear <g2boojum@gentoo.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 3-Sep-2005
Post-History: 6-Sep-2005

Credits
=======

This GLEP originated from a rather contentious discussion_ on gentoo-dev
about combining the x86 and amd64 keywords.  This GLEP attempts to get at the
heart of that discontent.  The proposed stable-keyword guidelines have been
lifted verbatim from `The Doc`_.

.. _discussion: http://tinyurl.com/bp859
.. _The Doc: http://dev.gentoo.org/~plasmaroo/devmanual

Abstract
========

It is time for x86 to no longer be an exception to the standard
keywording guidelines.  Thus, an x86 arch team should be responsible 
for moving packages from ~x86 to x86.

Motivation
==========

The original, informal x86 keywording policy, where almost any x86 dev (which
were the vast majority of devs) who used a package could mark it stable, arose
from a time when there were relatively few Gentoo devs.  Adding packages to
the tree was the principal concern, as opposed to maintaining existing
packages. QA considerations have since modified that policy slightly, and now
it is the package maintainers who should mark an x86 package stable.  Of
course, that policy presumes that package maintainers are generally x86 devs,
which is slowly becoming less and less true.

This policy for x86 is quite different from how every other arch marks
packages stable.  For the non-x86 archs, each arch has a specific "arch team"
which is responsible for moving packages from ``~arch`` to ``arch``.  This
approach has worked quite well for the non-x86 archs, and this GLEP asserts
that the same approach would benefit x86 as well.

Specification
=============

Stabling guidelines for all archs
---------------------------------

For a package to move to stable, the following guidelines must be met:

*  The package has spent a reasonable amount of time in ``~arch`` first.
   Thirty days is the usual figure, although this is clearly only a guideline.
   For critical packages, a much longer duration is expected.  For small
   packages which have only minor changes between versions, a shorter period
   is sometimes appropriate.
*  The package must not have any non-``arch`` dependencies.
*  The package must not have any severe outstanding bugs or issues.
*  The package must be widely tested.
*  If the package is a library, it should be known not to break any package
   which depends upon it.
*  The relevant ``arch`` team must agree to it.

x86 arch team
-------------

A robust x86 arch team needs to be created.  The x86@gentoo.org alias already
exists, and it merely needs to be used.  This team, with the aid of potential
non-dev ``arch testers``, has the responsibility of stabling all x86 packages.
Current x86 devs who wish to mark their own packages stable must therefore
either be members of or make individual arrangements with the x86 arch team.


Rationale
=========

There will be a considerable one-time cost involved in establishing a 
robust x86 arch team.  Certainly consistency between the various archs would
be a virtue, but is it worth the cost involved?  Here are the arguments
for enduring the pain involved:

*  Over time, x86 is likely to become a minority arch as 64-bit systems
   become the norm.  The implicit assumptions that underly the current
   system (that most devs, users, and package maintainers use x86)
   will become increasingly less valid.
*  Markedly improved QA for x86.  Assuming that the author's own  is
   behavior is representative, most x86 devs run ``~x86`` systems. 
   Thus, the assumption that devs are good ``x86`` testers is not really
   valid.  One obvious consequence is that packages tend to languish in
   ``~x86`` for a very long time, since x86 devs running ``~x86`` have little
   cause to notice that a package has not been marked stable.  The much larger
   effect, though, is that it is rare for ``x86`` packages to be stabled in
   the context of a full ``x86`` tree, so the big picture of a stable
   *system*, not just a stable package, is lost.  This approach of stabling
   in the context of a full stable ``arch`` tree, it has been argued_, is
   the fundamental reason why the non-x86 archs have notably better QA
   than does the x86 arch.

.. _argued: http://thread.gmane.org/gmane.linux.gentoo.devel/30369

Implementation
==============

Creation of a robust x86 team is already underway.  The more vital step 
is the official change in policy, along with a sustained effort to get
existing x86 devs to go along with it.


Backwards Compatibility
=======================

Not really an issue here.


Copyright
=========

This document has been placed in the public domain.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Mike Frysinger]

On Sunday 04 September 2005 10:37 am, Grant Goodyear wrote:
> This policy for x86 is quite different from how every other arch marks
> packages stable.  For the non-x86 archs, each arch has a specific "arch
> team" which is responsible for moving packages from ``~arch`` to ``arch``.
>  This approach has worked quite well for the non-x86 archs, and this GLEP
> asserts that the same approach would benefit x86 as well.

this isnt quite true ... non-x86 archs usually take their queues for when 
packages should be moved to stable from the maintainer of the package

in other words, arch teams generally defer to maintainers (and rightly so) as 
to when newer versions should go stable
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Sun, 4 Sep 2005 09:37:11 -0500 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| There will be a considerable one-time cost involved in establishing a 
| robust x86 arch team.

Justify this please. If there is a cost associated, the details of this
cost should be provided.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Grant Goodyear]

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

Ciaran McCreesh wrote: [Sun Sep 04 2005, 01:41:41PM CDT]
> On Sun, 4 Sep 2005 09:37:11 -0500 Grant Goodyear <g2boojum@gentoo.org>
> wrote:
> | There will be a considerable one-time cost involved in establishing a 
> | robust x86 arch team.
> 
> Justify this please. If there is a cost associated, the details of this
> cost should be provided.

Fair enough.  I'm rather hoping that's something those who will be
opposed to this idea will help we flesh out, but here's a couple of
obvious ones:

*  Although x86 arch recruitment is currently underway, I suspect that
   we will need notably more devs to be x86 arch devs than we currently
   have signed up.  (I don't know how many arch devs amd64 have, but I
   assume a similar number would be needed.)  I assume that the x86 will
   want non-dev arch-testers as well, and all of that will have to be
   set up.
*  Having bodies on x86@gentoo.org is just the starting point.  The 
   more difficult part will be convincing people that it is in their
   best interests to do things this way.  Similarly, what do we do with
   devs who refuse?  All of those issues still remain to be worked out.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

Hi Grant,

On Sun, 2005-09-04 at 09:37 -0500, Grant Goodyear wrote:
> Dear all,
>   Here's a GLEP that I'm thinking about right now.  It's not yet
> official, since I'd like to get some feedback beforehand (which helps to
> ensure that I'm not abusing my GLEP-editor powers).  If you have
> additional arguments either pro or con, please send them my way so that
> I may incorporate them.
> 
> Best,
> g2boojum

For better or for worse, x86 is the "maintainer arch" for a large amount
of our packages.  With the new x86 arch team being the only team allowed
to stabilise packages on the x86 arch, the concept of the "maintainer
arch" will finally be removed from the tree.  This leaves a problem -
how can package maintainers and arch maintainers work together to ensure
that arch teams only stabilise packages that the package maintainers
consider appropriate?

I can't claim credit for the following idea, but I can say that it's one
we've been using in the PHP Overlay in recent weeks, and it has made my
job easier as the PHP maintainer for the ppc arch.

Introduce a new arch keyword "maint", to turn the concept of the
"maintainer arch" from an intangible into something real.  Package
maintainers can then mark packages "~maint" or "maint" as required, and
leave the real arch keywords for the arch teams to handle.  This
approach ensures that arch maintainers have the metadata they need to
know which packages the package maintainers consider appropriate for
stabilising, and which ones they don't.  Any guesswork is removed.

I'd like to see this proposal in the final GLEP.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Sun, 04 Sep 2005 20:48:52 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| Introduce a new arch keyword "maint", to turn the concept of the
| "maintainer arch" from an intangible into something real.  Package
| maintainers can then mark packages "~maint" or "maint" as required,
| and leave the real arch keywords for the arch teams to handle.  This
| approach ensures that arch maintainers have the metadata they need to
| know which packages the package maintainers consider appropriate for
| stabilising, and which ones they don't.  Any guesswork is removed.

Workable for a certain category of packages so long as it's advisory
only. Arch teams need to be allowed to override maintainers where
appropriate, and in some places (eg toolchain, kernel) the concept of
maintainer arch is utterly irrelevant.

And "maint" as a name? Yick. "maintainer" or "owner" maybe.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 14:16 -0500, Grant Goodyear wrote:
> *  Having bodies on x86@gentoo.org is just the starting point.  The 
>    more difficult part will be convincing people that it is in their
>    best interests to do things this way.  Similarly, what do we do with
>    devs who refuse?  All of those issues still remain to be worked out.

Depends on how many refuse I guess ;-)  There doesn't seem to be much
sign of any opposition to the concept so far.  We have an elected
council now; if the council approves the plan, and devs refuse to follow
it, the devs should resign or be ejected.  Otherwise, what's the
point? :)

I'd be more worried about the impact on users.  From a user's point of
view, x86 is a fast-moving arch, where you can normally find an up to
date package, and where most of the major packages are actively and well
maintained by the package maintainers.  The introduction of the x86 arch
team will, at some point, turn the x86 arch team into a bottleneck (just
like all the other arch teams already are), and the experience for our
users will change.  Our challenge as a project is make sure that the
benefits of the x86 team outweigh the negatives in the right places, so
that we don't lose our users in the process.

If the introduction of an x86 arch team results in a lot of pain for our
users, it's going to hurt us as a project, and reduce our standing in
the wider community.

Your GLEP currently doesn't cover this risk, or provide a robust plan
for mitigating it :(

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 21:05 +0100, Ciaran McCreesh wrote:
> Workable for a certain category of packages so long as it's advisory
> only. 

Workable for the vast majority of packages in the tree I expect.

> Arch teams need to be allowed to override maintainers where
> appropriate, 

Why not talk to the package maintainers instead, and convince them that
you need a different version marking "maint" instead?  Why
"override" (which, tbh, smacks of "we arch teams know best, life would
be better without package maintainers") when you could work with people
instead?  You're *not* in competition with package maintainers.  We're
all supposed to be working towards the same thing :)

I've no personal problem with arch teams sometimes needing to do their
own thing, provided it's confined to a specific class of package.
Outside of the core packages required to boot & maintain a platform,
when is there ever a need for arch maintainers to decide that they know
better than package maintainers?

If this isn't confined - if arch maintainers are allowed to override
package maintainers wherever they want to - then arch teams need to take
on the support burden.  Fair's fair - if it's the arch team creating the
support, it's only fair that they support users in these cases.  It's
completely unfair - and unrealistic - to expect a package maintainer to
support a package he/she thinks isn't fit to be stable on an arch that
he/she probably doesn't use anyway.  In such a conflict of egos, the
real losers remain our users.

> And "maint" as a name? Yick. "maintainer" or "owner" maybe.

It's just a word.  Provided the concept is agreed on, the word isn't the
most important thing in the world.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Joshua Baergen]

Stuart Herbert wrote:

>
>The introduction of the x86 arch
>team will, at some point, turn the x86 arch team into a bottleneck (just
>like all the other arch teams already are)
>  
>
A possible way to alleviate this is proactivity on the maintainer's 
part.  Our current rule for going testing->stable is 30 days.  If we 
could alert the arch teams x number of days in advance they could test 
it before the end of the period minimizing delays.  Since all arch teams 
would need this alert a relevant script could be created/modified.

I realize this doesn't help if the arch teams are just plain too busy.  
Hopefully the 'fast arch' losing its speed will show people that we need 
more help in testing and bring more people on board.

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Grant Goodyear]

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

Vapier wrote: [Sun Sep 04 2005, 01:00:41PM CDT]
> this isnt quite true ... non-x86 archs usually take their queues for
> when packages should be moved to stable from the maintainer of the
> package

Perfectly reasonable.

> in other words, arch teams generally defer to maintainers (and rightly
> so) as to when newer versions should go stable

I agree that the arch teams shouldn't be marking packages stable in
advance of when the the maintainer thinks it's ready.  At the same time,
it's the respective arch teams, as "owners" of their entire stable tree,
who (in my opinion) should have the final "okay" on a package going
stable, since they're the ones with experience of the entire stable
tree.  Does that make a bit more sense?

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Simon Stelling]

Stuart Herbert wrote:
> I've no personal problem with arch teams sometimes needing to do their
> own thing, provided it's confined to a specific class of package.
> Outside of the core packages required to boot & maintain a platform,
> when is there ever a need for arch maintainers to decide that they know
> better than package maintainers?

I assume you're talking of the case where arch team and maintainer's arch are 
the same. I think normally package maintainers can decide better whether their 
package should go stable on their arch than an arch team, as they get all the 
bugs for it. On the other hand, we can't define a "maintainer arch" in many 
cases, so either we leave the authority to the arch team or we'll just have an 
x86 arch team without the expected effects.

> If this isn't confined - if arch maintainers are allowed to override
> package maintainers wherever they want to - then arch teams need to take
> on the support burden.  Fair's fair - if it's the arch team creating the
> support, it's only fair that they support users in these cases.  It's
> completely unfair - and unrealistic - to expect a package maintainer to
> support a package he/she thinks isn't fit to be stable on an arch that
> he/she probably doesn't use anyway.  In such a conflict of egos, the
> real losers remain our users.

That'd mean that you normally have assigned to the maintainer and x86@ in CC or 
vice versa, right? For that you need a huuuge x86 arch team...

> It's just a word.  Provided the concept is agreed on, the word isn't the
> most important thing in the world.

I'd prefer machamalahalabad ;)

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Grant Goodyear]

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

Stuart Herbert wrote: [Sun Sep 04 2005, 03:26:37PM CDT]
> I've no personal problem with arch teams sometimes needing to do their
> own thing, provided it's confined to a specific class of package.
> Outside of the core packages required to boot & maintain a platform,
> when is there ever a need for arch maintainers to decide that they know
> better than package maintainers?

I'm still thinking about the concept of a "maint" option.  This
question I can answer, however.  It's not unheard of for a package with
a lot of dependencies to be marked stable when one of the dependencies
has not yet been so marked.  In that sort of tree-breaking case, the
arch teams actually do know better, since they maintain ``arch`` systems
(or chroots) for testing.

> If this isn't confined - if arch maintainers are allowed to override
> package maintainers wherever they want to - then arch teams need to take
> on the support burden.  Fair's fair - if it's the arch team creating the
> support, it's only fair that they support users in these cases.  It's
> completely unfair - and unrealistic - to expect a package maintainer to
> support a package he/she thinks isn't fit to be stable on an arch that
> he/she probably doesn't use anyway.  In such a conflict of egos, the
> real losers remain our users.

I tend to think that's fair.  At least in my view, the goal is not to
minimize the importance of package maintainers, but simply to separate
package maintainance from tree maintainance.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Sun, 04 Sep 2005 21:11:03 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| Depends on how many refuse I guess ;-)  There doesn't seem to be much
| sign of any opposition to the concept so far.

Yeah, foser's on holiday. Good time to push the GLEP through.

| We have an elected council now; if the council approves the plan, and
| devs refuse to follow it, the devs should resign or be ejected.
| Otherwise, what's the point? :)

Good. Does this mean I can start pushing for UTF-8 again?

| I'd be more worried about the impact on users.  From a user's point of
| view, x86 is a fast-moving arch, where you can normally find an up to
| date package, and where most of the major packages are actively and
| well maintained by the package maintainers.  The introduction of the
| x86 arch team will, at some point, turn the x86 arch team into a
| bottleneck (just like all the other arch teams already are)

The only reason certain arch teams are considered a bottleneck is
because they do real testing. As opposed to x86 or ppc, where packages
which won't even unpack get marked stable...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| > Arch teams need to be allowed to override maintainers where
| > appropriate, 
| 
| Why not talk to the package maintainers instead, and convince them
| that you need a different version marking "maint" instead?  Why
| "override" (which, tbh, smacks of "we arch teams know best, life would
| be better without package maintainers") when you could work with
| people instead?  You're *not* in competition with package
| maintainers.  We're all supposed to be working towards the same
| thing :)

Sure, we do that anyway. However, sometimes package maintainers are
outright wrong.

| I've no personal problem with arch teams sometimes needing to do their
| own thing, provided it's confined to a specific class of package.
| Outside of the core packages required to boot & maintain a platform,
| when is there ever a need for arch maintainers to decide that they
| know better than package maintainers?

Pretty regularly. A significant number of package maintainers have a
very shoddy attitude towards QA, and a significant number of upstreams
have no clue what portability is.

| If this isn't confined - if arch maintainers are allowed to override
| package maintainers wherever they want to - then arch teams need to
| take on the support burden.  Fair's fair - if it's the arch team
| creating the support, it's only fair that they support users in these
| cases.  It's completely unfair - and unrealistic - to expect a
| package maintainer to support a package he/she thinks isn't fit to be
| stable on an arch that he/she probably doesn't use anyway.  In such a
| conflict of egos, the real losers remain our users.

If it isn't fit to be marked stable, it shouldn't be out of
package.mask. ~arch means "candidate for going stable after more
testing", not "might work".

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Sun, 4 Sep 2005 15:53:07 -0500 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| I'm still thinking about the concept of a "maint" option.  This
| question I can answer, however.  It's not unheard of for a package
| with a lot of dependencies to be marked stable when one of the
| dependencies has not yet been so marked.  In that sort of
| tree-breaking case, the arch teams actually do know better, since
| they maintain ``arch`` systems (or chroots) for testing.

Anyone doing that needs to have their commit access revoked. repoman has
checked for this properly for about eighteen months now.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Homer Parker]

On Sun, 2005-09-04 at 14:40 -0600, Joshua Baergen wrote:
> A possible way to alleviate this is proactivity on the maintainer's 
> part.  Our current rule for going testing->stable is 30 days.  If we 
> could alert the arch teams x number of days in advance they could
> test 
> it before the end of the period minimizing delays.  Since all arch
> teams 
> would need this alert a relevant script could be created/modified.

	That's where having some devs/ATs running stable, and others running
testing really helps.. That and chroots for core packages going from
package.masked to testing. It's worked well for amd64 that way.

-- 
Homer Parker
Gentoo/AMD64 Arch Tester Strategic Lead
hparker@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Diego 'Flameeyes' Pettenò]

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

On Sunday 04 September 2005 22:53, Grant Goodyear wrote:
> I tend to think that's fair.  At least in my view, the goal is not to
> minimize the importance of package maintainers, but simply to separate
> package maintainance from tree maintainance.
That's right. I think this is good, as a maintainer.
What we actually lack now is a way to "suggest" a "candidate stable".
For example, maintaining libtorrent, I found a point where libtorrent/rtorrent 
worked fine on am64 and ppc, but crashed in some situation on x86, because of 
a conjunction of -fomit-frame-pointer and exception handling.
I refrained from editing the ebuild stable on amd64... so I just added the 
filter-flag on another version and considered that as possible x86 stable at 
that point.

the ~x86 ebuilds were working, without tinkering with them, but not "stable 
enough" for the stable tree anyway.

Giving an advice on what to marking stable is probably useful.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Jason Wever]

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

On Sun, 4 Sep 2005 15:43:11 -0500
Grant Goodyear <g2boojum@gentoo.org> wrote:

> I agree that the arch teams shouldn't be marking packages stable in
> advance of when the the maintainer thinks it's ready.  At the same
> time, it's the respective arch teams, as "owners" of their entire
> stable tree, who (in my opinion) should have the final "okay" on a
> package going stable, since they're the ones with experience of the
> entire stable tree.  Does that make a bit more sense?

For the most part, this makes sense,  However we do have times where a
particular arch team may need to stabilize a package sooner in the case
where earlier versions are broken.

This is not entirely uncommon to see packages that used to compile with
stable keywords no longer compile after a period of time.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

Hi Grant,

On Sun, 2005-09-04 at 15:53 -0500, Grant Goodyear wrote:
> I'm still thinking about the concept of a "maint" option.  This
> question I can answer, however.  It's not unheard of for a package with
> a lot of dependencies to be marked stable when one of the dependencies
> has not yet been so marked.  In that sort of tree-breaking case, the
> arch teams actually do know better, since they maintain ``arch`` systems
> (or chroots) for testing.

Yes, but if package maintainers aren't allowed to mark packages as
stable on anything but the "maintainer arch" (unless they are also a
member of an arch team), this problem shouldn't happen.

At the moment, the only way for a package maintainer to mark a package
stable is to mark it stable on a "real" arch.  Creating the "maintainer"
arch solves this very problem.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote:
> Yeah, foser's on holiday. Good time to push the GLEP through.

How typical of you to try and drag this discussion down into something
personal :(  If you keep feeling the need to do this, do everyone a
favour and keep your mouth shut instead.  It detracts from otherwise
insightful and useful comments.

> The only reason certain arch teams are considered a bottleneck is
> because they do real testing. As opposed to x86 or ppc, where packages
> which won't even unpack get marked stable...

You can't help yourself, can you?  You have to have a pop at someone :(

I didn't mean "considered", I meant "are".  It wasn't a criticism, it's
just a statement of fact.

It's impossible for an arch team to keep pace with the rate of change in
the tree and do adequate testing too.  No arch team is currently big
enough.  Arch teams are always going to lag behind what package
maintainers do.  It's a simple numbers game.

There are only two arch teams with 20 or more members (amd64 and ppc),
as of 22:30 BST today.  They have to deal with the output of approx 155
herds, plus countless changes that don't go through herds in the first
place.  The numbers speak for themselves.  Arch teams are bottlenecks.
Until the numbers change, that won't change.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Diego 'Flameeyes' Pettenò]

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

On Sunday 04 September 2005 23:35, Jason Wever wrote:
> For the most part, this makes sense,  However we do have times where a
> particular arch team may need to stabilize a package sooner in the case
> where earlier versions are broken.
Why this remembers me xine-lib on sparc? :))

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Jason Wever]

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

On Sun, 04 Sep 2005 22:39:44 +0100
Stuart Herbert <stuart@gentoo.org> wrote:

> Yes, but if package maintainers aren't allowed to mark packages as
> stable on anything but the "maintainer arch" (unless they are also a
> member of an arch team), this problem shouldn't happen.

This is the current policy, though it gets violated quite often.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote:
> If it isn't fit to be marked stable, it shouldn't be out of
> package.mask. ~arch means "candidate for going stable after more
> testing", not "might work".

Agreed, but we both know that it's just not how many devs work atm.
Perhaps that is a problem that also needs to be solved?

There's also the issue that many users are happy running ~arch packages,
but are reluctant to test masked packages (making it difficult to get
enough feedback to move the package to ~arch anyway).  This is a bit of
a chicken and egg situation - one that the maintainer arch may provide a
new solution to.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 15:45 -0600, Jason Wever wrote:
> This is the current policy, though it gets violated quite often.

Maybe the answer is to have separate trees for arches and general
packages then?  That would be one solution.

(Although not one that I'd personally prefer.  I'd rather the package
maintainers learned to work within the rules instead.)

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Jason Wever]

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

On Sun, 04 Sep 2005 22:54:02 +0100
Stuart Herbert <stuart@gentoo.org> wrote:

> Maybe the answer is to have separate trees for arches and general
> packages then?  That would be one solution.
> 
> (Although not one that I'd personally prefer.  I'd rather the package
> maintainers learned to work within the rules instead.)

I agree, I'd rather keep things as they are (and supposed to be) rather
than do weird things like have arch specific trees.

However, package maintainers (particularly in the scripting herds) need
to be disabused of the notion of making assumptions about "my language
is portable so I can mark this stable".  While the script itself may be
"portable", there may be core elements of said scripting language that
don't work quite right and aren't noticed until some particular script
package triggers it.  This includes shells as well as regular
programming languages.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Sun, 04 Sep 2005 22:43:20 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| On Sun, 2005-09-04 at 21:57 +0100, Ciaran McCreesh wrote:
| > Yeah, foser's on holiday. Good time to push the GLEP through.
| 
| How typical of you to try and drag this discussion down into something
| personal :(  If you keep feeling the need to do this, do everyone a
| favour and keep your mouth shut instead.  It detracts from otherwise
| insightful and useful comments.

What, weren't you around for all the previous attempts at this proposal?

| > The only reason certain arch teams are considered a bottleneck is
| > because they do real testing. As opposed to x86 or ppc, where
| > packages which won't even unpack get marked stable...
| 
| You can't help yourself, can you?  You have to have a pop at
| someone :(

It's the truth, it's a problem and it needs fixing.

| It's impossible for an arch team to keep pace with the rate of change
| in the tree and do adequate testing too.  No arch team is currently
| big enough.  Arch teams are always going to lag behind what package
| maintainers do.  It's a simple numbers game.
|
| There are only two arch teams with 20 or more members (amd64 and ppc),
| as of 22:30 BST today.  They have to deal with the output of approx
| 155 herds, plus countless changes that don't go through herds in the
| first place.  The numbers speak for themselves.  Arch teams are
| bottlenecks. Until the numbers change, that won't change.

You want numbers?

A total of 31 ebuilds seems outdated on sparc
A total of 72 ebuilds seems outdated on x86

A total of 3634 packages are keyworded on sparc
A total of 7793 packages are keyworded on x86

Real numbers. Not guesswork based upon misconceptions.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Kevin F. Quinn]

We seem to be heading towards a situation where the x86 arch
team do all marking of stuff stable on x86.  This I like.
Some observations - these may be phrased in the affirmative
but please take them as observations/suggestions :)

1) The x86 arch team will need to be large(ish) to keep pace.
   Herds could nominate one of their members to join the
   team; that'd get a fair amount of tree coverage quickly.

2) The job of the x86 arch team members should be to arrange,
   collect and collate testing results, not to do the actual
   testing themselves.  Note this means being a member of the
   x86 arch team is a management role rather than a development
   or test role.
   
3) All packages need to be assigned an x86 arch team member
   responsible.  I'd suggest not putting _any_ rules about
   timeliness in tihs case - if people want a package to
   go stable more quickly, then they need to do somthing
   about it; either become an x86 arch team member (in the
   case of a Dev who wants control) or do some arch testing
   (in the case of a user, or a dev who just wants up push
   things along).

4) It'll need a pool of arch testers - this is a great
   opportunity to include some regular users directly in
   Gentoo. Some kind of recognition system needs to be
   in place - I'm thinking of peer qudos type stuff, for
   example listing arch testers responsible for a package
   being marked stable against that package somewhere; perhaps
   the online package database, or perhaps on a credits
   page on the main web site.  We shouldn't underestimate
   the value of testing work - it may not be as technically
   involved as actual dev work, but it's a big (boring!) job
   with high value if done right.

5) Releng's job will be a lot easier as stable x86 will
   become much more stable...

6) I notice the amd64 team requre their arch testers to
   take the ebuild quiz; I think this is a bit harsh, as
   arch testers are regular users without commit access to
   CVS etc.  A simpler quiz targetted at ensuring the arch
   testers know what is expected of them would lower the
   bar and should encourage more users to join in.  Using
   the ebuild quiz means you get people who quickly become
   devs in their own right...

7) (6) aside, take as many cues as possible from the amd64
   team who've been at this for a while!

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
wrote:
| 3) All packages need to be assigned an x86 arch team member
|    responsible.

Why?

| 6) I notice the amd64 team requre their arch testers to
|    take the ebuild quiz; I think this is a bit harsh, as
|    arch testers are regular users without commit access to
|    CVS etc.  A simpler quiz targetted at ensuring the arch
|    testers know what is expected of them would lower the
|    bar and should encourage more users to join in.  Using
|    the ebuild quiz means you get people who quickly become
|    devs in their own right...

The ebuild quiz isn't particularly difficult... If the proposed "write
an ebuild for equizapp" question goes through then maybe they could be
exempt from that until they need cvs access, but the main ebuild quiz
just tests basic understanding.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Homer Parker]

On Mon, 2005-09-05 at 01:12 +0200, Kevin F. Quinn wrote:
> 6) I notice the amd64 team requre their arch testers to
>    take the ebuild quiz; I think this is a bit harsh, as
>    arch testers are regular users without commit access to
>    CVS etc.  A simpler quiz targetted at ensuring the arch
>    testers know what is expected of them would lower the
>    bar and should encourage more users to join in.  Using
>    the ebuild quiz means you get people who quickly become
>    devs in their own right...

	Just until we get finished with the AT quiz, which is working out to be
more QA/troubleshooting oriented. The ebuid.quiz was handy, and is a
good way to check if the prospect has at least read the docs enough to
get the questions answered. It also helps ensure they really want it,
rather then having a high turnover rate. The ppc ATs took the test as
well, which I reviewed, and gave pointers where there was a problem.
JoseJX seems to have liked the help he's gotten so far from them. 

	As for making dev.. hehe.. Yeah, it's a start, and there for awhile we
had like 2 ATs because they'd all made dev ;) It does give you a pool of
dev prospects as well, which works out nicely. Several of the amd64 ATs
submit patches with their bug reports which helps the devs out as well.
We now have several ATs that have no interest in making dev, content
with helping out as an AT. Got a little longer then I wanted, but wanted
to give a decent explanation of our experiences so far.

-- 
Homer Parker
Gentoo/AMD64 Arch Tester Strategic Lead
hparker@gentoo.org

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Daniel Goller]

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

On Sunday 04 September 2005 03:59 pm, Ciaran McCreesh wrote:
> On Sun, 04 Sep 2005 21:26:37 +0100 Stuart Herbert <stuart@gentoo.org>
>
> wrote:
> | > Arch teams need to be allowed to override maintainers where
> | > appropriate,
> |
> | Why not talk to the package maintainers instead, and convince them
> | that you need a different version marking "maint" instead?  Why
> | "override" (which, tbh, smacks of "we arch teams know best, life would
> | be better without package maintainers") when you could work with
> | people instead?  You're *not* in competition with package
> | maintainers.  We're all supposed to be working towards the same
> | thing :)
>
> Sure, we do that anyway. However, sometimes package maintainers are
> outright wrong.
>

agreed talk/communcation is fine, if the maintainer is only trying to flex 
muscles and does not have a good reason, the arch team ought to be able to do 
what is best for gentoo and not be shot down by a (hm) stubborn(?) 
maintainer, if the maintaner could do that, the arch team would be quite 
limited in its effectiveness

> | I've no personal problem with arch teams sometimes needing to do their
> | own thing, provided it's confined to a specific class of package.
> | Outside of the core packages required to boot & maintain a platform,
> | when is there ever a need for arch maintainers to decide that they
> | know better than package maintainers?
>
> Pretty regularly. A significant number of package maintainers have a
> very shoddy attitude towards QA, and a significant number of upstreams
> have no clue what portability is.
>
> | If this isn't confined - if arch maintainers are allowed to override
> | package maintainers wherever they want to - then arch teams need to
> | take on the support burden.  Fair's fair - if it's the arch team
> | creating the support, it's only fair that they support users in these
> | cases.  It's completely unfair - and unrealistic - to expect a
> | package maintainer to support a package he/she thinks isn't fit to be
> | stable on an arch that he/she probably doesn't use anyway.  In such a
> | conflict of egos, the real losers remain our users.
>
> If it isn't fit to be marked stable, it shouldn't be out of
> package.mask. ~arch means "candidate for going stable after more
> testing", not "might work".

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Daniel Goller]

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

On Sunday 04 September 2005 04:52 pm, Stuart Herbert wrote:
> On Sun, 2005-09-04 at 21:59 +0100, Ciaran McCreesh wrote:
> > If it isn't fit to be marked stable, it shouldn't be out of
> > package.mask. ~arch means "candidate for going stable after more
> > testing", not "might work".
>
> Agreed, but we both know that it's just not how many devs work atm.
> Perhaps that is a problem that also needs to be solved?
>
> There's also the issue that many users are happy running ~arch packages,
> but are reluctant to test masked packages (making it difficult to get
> enough feedback to move the package to ~arch anyway).  This is a bit of
> a chicken and egg situation - one that the maintainer arch may provide a
> new solution to.

sounds like you suggest to trick ~arch users into testing "unripe" 
ebuilds/bumps/versions by sending it into ~arch to get the testing done while 
someone in a chroot would be much better equipped for doing the testing with?
>
> Best regards,
> Stu

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Kevin F. Quinn]

On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
> On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
> wrote:
> | 3) All packages need to be assigned an x86 arch team member
> |    responsible.
> 
> Why?

Because if only the x86 arch team can mark stuff stable, anything
without representation on the x86 arch team will stay unstable forever.
Maybe rather than one specific arch team member, several would
undertake to manage otherwise unassigned packages.

> | 6) I notice the amd64 team requre their arch testers to
> |    take the ebuild quiz; I think this is a bit harsh, as
> |    arch testers are regular users without commit access to
> |    CVS etc.  A simpler quiz targetted at ensuring the arch
> |    testers know what is expected of them would lower the
> |    bar and should encourage more users to join in.  Using
> |    the ebuild quiz means you get people who quickly become
> |    devs in their own right...
> 
> The ebuild quiz isn't particularly difficult... If the proposed "write
> an ebuild for equizapp" question goes through then maybe they could be
> exempt from that until they need cvs access, but the main ebuild quiz
> just tests basic understanding.

Well, it strikes me that most if not all of the organisational questions
are not relevant to a tester; the only technical question that is
relevant is 9 (keyword marking), and even that would be reworded for the
tester perspective.  The main point being that a tester can be a willing
user, with no dev capabilities at all; the ebuild quiz is written for a
different target group.  In fact, it's useful if testers are not developers,
as devs often make assumptions without realising it.

I guess it comes down to what you want a tester to do. In my mind, the
task of a tester is to emerge the package normally, record the use flag
configuration, and exercise the application as much as possible.  Possibly
repeating with other use flag configurations.  If you want testers to do
ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's
a good idea..

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Martin Schlemmer]

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

On Sun, 2005-09-04 at 23:19 +0100, Ciaran McCreesh wrote:
> On Sun, 04 Sep 2005 22:43:20 +0100 Stuart Herbert <stuart@gentoo.org>
> wrote:
> | > The only reason certain arch teams are considered a bottleneck is
> | > because they do real testing. As opposed to x86 or ppc, where
> | > packages which won't even unpack get marked stable...
> | 
> | You can't help yourself, can you?  You have to have a pop at
> | someone :(
> 
> It's the truth, it's a problem and it needs fixing.
> 

And I am sure everybody know why it was not a problem before, but is
now.  You have you wish, we are working on it, and you had your chance
at trolling, but for the love of all, stop it if its not something
constructive that needs adding.

> | It's impossible for an arch team to keep pace with the rate of change
> | in the tree and do adequate testing too.  No arch team is currently
> | big enough.  Arch teams are always going to lag behind what package
> | maintainers do.  It's a simple numbers game.
> |
> | There are only two arch teams with 20 or more members (amd64 and ppc),
> | as of 22:30 BST today.  They have to deal with the output of approx
> | 155 herds, plus countless changes that don't go through herds in the
> | first place.  The numbers speak for themselves.  Arch teams are
> | bottlenecks. Until the numbers change, that won't change.
> 
> You want numbers?
> 
> A total of 31 ebuilds seems outdated on sparc
> A total of 72 ebuilds seems outdated on x86
> 
> A total of 3634 packages are keyworded on sparc
> A total of 7793 packages are keyworded on x86
> 
> Real numbers. Not guesswork based upon misconceptions.
> 

Which is about two times more outdated packages on x86 than sparc, and
with the amount keyworded on x86 being about twice that of sparc, it
really seems to me like the ratio is fairly the same, and both are in
the same boat with regards to whatever the numbers had to prove?


-- 
Martin Schlemmer


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

Re: [gentoo-dev] tentative x86 arch team glep

[Paul de Vrieze]

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

On Sunday 04 September 2005 23:39, Stuart Herbert wrote:
> Hi Grant,
>
> On Sun, 2005-09-04 at 15:53 -0500, Grant Goodyear wrote:
> > I'm still thinking about the concept of a "maint" option.  This
> > question I can answer, however.  It's not unheard of for a package
> > with a lot of dependencies to be marked stable when one of the
> > dependencies has not yet been so marked.  In that sort of
> > tree-breaking case, the arch teams actually do know better, since
> > they maintain ``arch`` systems (or chroots) for testing.
>
> Yes, but if package maintainers aren't allowed to mark packages as
> stable on anything but the "maintainer arch" (unless they are also a
> member of an arch team), this problem shouldn't happen.
>
> At the moment, the only way for a package maintainer to mark a package
> stable is to mark it stable on a "real" arch.  Creating the
> "maintainer" arch solves this very problem.

I agree with this. It should also be a simple, backwards compatible 
solution. Just don't call it maintainer, but maint or something like 
that ;-)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: tentative x86 arch team glep

[R Hill]

On Sun, 04 Sep 2005 21:26:37 +0100, Stuart Herbert wrote:

> Why not talk to the package maintainers instead, and convince them that
> you need a different version marking "maint" instead?  Why "override"
> (which, tbh, smacks of "we arch teams know best, life would be better
> without package maintainers") when you could work with people instead? 
> You're *not* in competition with package maintainers.  We're all supposed
> to be working towards the same thing :)

How about the ATs cc the maintainer on the bug they
file to get the pkg bumped to stable, and giving them a period of time
(48 hours? a week?) in which to raise any objections.  Of course the AT's
would still have the power to go over the maintainers head in case of
an emergency - but only if the maintainer can't be reached, or can't do it
themselves for whatever reason, or is just being a big dink.

--de



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Tom Martin]

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

On Mon, Sep 05, 2005 at 01:12:54AM +0200, "Kevin F. Quinn" <kevquinn@gentoo.org> wrote:
> We seem to be heading towards a situation where the x86 arch
> team do all marking of stuff stable on x86.  This I like.
> Some observations - these may be phrased in the affirmative
> but please take them as observations/suggestions :)
> 
> 1) The x86 arch team will need to be large(ish) to keep pace.
>    Herds could nominate one of their members to join the
>    team; that'd get a fair amount of tree coverage quickly.
> 
> 2) The job of the x86 arch team members should be to arrange,
>    collect and collate testing results, not to do the actual
>    testing themselves.  Note this means being a member of the
>    x86 arch team is a management role rather than a development
>    or test role.

I'm not sure I like this. I think it would be too slow. I'd rather have
a concept of maintainer arch (the reason I still like the old keyword
ordering, because there was at least *some* idea of maintainer arch. In
fact, I used to fiddle the keywords every now and again when I took over
a package and the maintainer arch changed). Policy, for a long time, has
been that no arch team should go stable ahead of a package maintainer
without his approval. This works fine. Now, some packages are going into
Portage without the x86 keyword (for example, viewglob, which I recently
committed. I don't have an x86 machine) and a non-x86 maintainer. All
that we need is an x86 arch team to do the same jobs as other
architectures:

a) Test packages that aren't yet keyworded.
b) Keep keywords up-to-date -- imlate. Although imlate currently
	compares against x86 by default, scanning x86 against a few other archs
	isn't a major bottleneck.
c) Keep up with security bugs, with a proper security contact. Tester, I
	believe you're filling this role at the moment?
d) Possibly arch testers.

Maybe I'm seeing this all wrong, but the fact is, the number of packages
that need x86 arch team lovin' are pretty small, despite the number of
overall keyworded packages being large. I don't think the x86 arch team
needs to be very large: I think ten developers is plenty. I just don't
know what they'd be doing if there were more.

Thoughts?

-- 
Tom Martin, http://dev.gentoo.org/~slarti
AMD64, net-mail, shell-tools, vim, recruiters
Gentoo Linux

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Danny van Dyk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul de Vrieze schrieb:
| I agree with this. It should also be a simple, backwards compatible
| solution. Just don't call it maintainer, but maint or something like
| that ;-)
In case this should really be done, please call it 'stable'...

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHCJhaVNL8NrtU6IRAqQBAJ9cb4LfD+IISwOALjaEtgpOrddCJgCfY3Me
kESQog3kqXykRdedvsGs9ZU=
=pHup
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Jason Stubbs]

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

On Monday 05 September 2005 05:11, Stuart Herbert wrote:
> I'd be more worried about the impact on users.  From a user's point of
> view, x86 is a fast-moving arch, where you can normally find an up to
> date package, and where most of the major packages are actively and well
> maintained by the package maintainers.  The introduction of the x86 arch
> team will, at some point, turn the x86 arch team into a bottleneck (just
> like all the other arch teams already are), and the experience for our
> users will change.  Our challenge as a project is make sure that the
> benefits of the x86 team outweigh the negatives in the right places, so
> that we don't lose our users in the process.

Somewhere in the previous thread, I read the (seemingly sarcastic) 
suggestion that all non-arch devs start working in overlays. This would 
seem to be a very good idea if the overlays could be made easily available 
via gensync.

Having general ebuild devs work in overlays (perhaps shared overlays per 
herd?) rather the main tree would seem to be better for at least two 
reasons:

* "Proper" arch testing by arch-devs (Dunno if this is valid, but other's   
  are bringing it up in this thread, so... ;)
* Users would select what areas in which the pace should be fast. This has
  the added benefit that mix of arch/~arch bugs that slip through a all 
  ~arch system would be picked up a lot more.

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Simon Stelling]

Danny van Dyk wrote:
> Paul de Vrieze schrieb:
> | I agree with this. It should also be a simple, backwards compatible
> | solution. Just don't call it maintainer, but maint or something like
> | that ;-)
> In case this should really be done, please call it 'stable'...

so we get ~stable? ;)

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Simon Stelling]

Ciaran McCreesh wrote:
> If it isn't fit to be marked stable, it shouldn't be out of
> package.mask. ~arch means "candidate for going stable after more
> testing", not "might work".

It's a bit of both. When you put a package into ~arch, it's in "testing", so 
that says it needs further "testing" since there still could be a not yet 
discovered bug, right?

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Jason Stubbs]

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

On Monday 05 September 2005 20:21, Simon Stelling wrote:
> Ciaran McCreesh wrote:
> > If it isn't fit to be marked stable, it shouldn't be out of
> > package.mask. ~arch means "candidate for going stable after more
> > testing", not "might work".
>
> It's a bit of both. When you put a package into ~arch, it's in "testing",
> so that says it needs further "testing" since there still could be a not
> yet discovered bug, right?

Testing of the ebuild rather than of the package, though. This is the point 
where people sometimes get confused.

-- 
Jason Stubbs

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Kevin F. Quinn]

On 5/9/2005 13:41:54, Jason Stubbs (jstubbs@gentoo.org) wrote:
> On Monday 05 September 2005 20:21, Simon Stelling wrote:
> > Ciaran McCreesh wrote:
> > > If it isn't fit to be marked stable, it shouldn't be out of
> > > package.mask. ~arch means "candidate for going stable after more
> > > testing", not "might work".
> >
> > It's a bit of both. When you put a package into ~arch, it's in 
> > "testing", so that says it needs further "testing" since there still 
> > could be a not yet discovered bug, right?
> 
> Testing of the ebuild rather than of the package, though. This is the 
> point  where people sometimes get confused.

That'd be me then :)

So we're talking about correctness of ebuilds (correct dependencies,
use flag logic etc) and not whether the package actually works in depth.
The latter is what caused me to suggest drawing together a large team of
user-testers managed by arch-team devs.  Correctness of ebuilds takes
us back to a dev role and the ebuild quiz, since it's necessary to
understand ebuilds to criticise them.

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin F. Quinn wrote:
> Well, it strikes me that most if not all of the organisational questions
> are not relevant to a tester; the only technical question that is
> relevant is 9 (keyword marking), and even that would be reworded for the
> tester perspective.  The main point being that a tester can be a willing
> user, with no dev capabilities at all; the ebuild quiz is written for a
> different target group.  In fact, it's useful if testers are not developers,
> as devs often make assumptions without realising it.
> 
> I guess it comes down to what you want a tester to do. In my mind, the
> task of a tester is to emerge the package normally, record the use flag
> configuration, and exercise the application as much as possible.  Possibly
> repeating with other use flag configurations.  If you want testers to do
> ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's
> a good idea..

In my professional work, the pecking order is like this:

developer --> integration/test --> system design --> management

Of course, some of the developers I work with may disagree. ;)

But the point is that the integration/test team knows about development;
it just makes sense. The integration/test team needs to know a good deal
about development *and* the overall system design to be affective.

So I would say have all arch-testers take both the ebuild quiz and the
newer QA/testing quiz. I suppose you could be more lax about scoring if
you're really worried about not getting a large enough pool of testers.
And I'm not arguing that an arch tester has to become a developer first;
I'm just making the point that a good tester has the ability to switch
back and forth between the 'big picture' and the 'bit level'.

If you want fancy terminology, the testers need to know how to test the
interfaces (in this case the portage API, probably by code walk
throughs), and functional threads (you gave a great example, 'emerge the
package normally, record the use flag configuration, and exercise the
application').

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHF2E2QTTR4CNEQARArbJAKCEZ7K6HiTFKpVy9mEVkaTU9TFUvQCeLlLE
l8v1xMYUtLLa4cvF5meZyJo=
=W6Sq
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Martin wrote:
> I'm not sure I like this. I think it would be too slow. I'd rather have
> a concept of maintainer arch (the reason I still like the old keyword
> ordering, because there was at least *some* idea of maintainer arch. In
> fact, I used to fiddle the keywords every now and again when I took over
> a package and the maintainer arch changed). Policy, for a long time, has
> been that no arch team should go stable ahead of a package maintainer
> without his approval. This works fine. Now, some packages are going into
> Portage without the x86 keyword (for example, viewglob, which I recently
> committed. I don't have an x86 machine) and a non-x86 maintainer. All
> that we need is an x86 arch team to do the same jobs as other
> architectures:
> 
> a) Test packages that aren't yet keyworded.
> b) Keep keywords up-to-date -- imlate. Although imlate currently
> 	compares against x86 by default, scanning x86 against a few other archs
> 	isn't a major bottleneck.
> c) Keep up with security bugs, with a proper security contact. Tester, I
> 	believe you're filling this role at the moment?
> d) Possibly arch testers.
> 
> Maybe I'm seeing this all wrong, but the fact is, the number of packages
> that need x86 arch team lovin' are pretty small, despite the number of
> overall keyworded packages being large. I don't think the x86 arch team
> needs to be very large: I think ten developers is plenty. I just don't
> know what they'd be doing if there were more.
> 
> Thoughts?
> 

I took Kevin's 2) to mean that the arch team *developers* wouldn't do
the actual testing; the arch team testers (a sub-group of the arch team)
would do the testing. Is that correct?

b) You could have imlate compare against the new -maint ~maint maint
keywords (or whatever gets settled on).

Having the 'maint' keyword would help with the 'no arch team should go
stable ahead of a package maintainer without his approval' policy.

I would structure it like this:

i. Package maintainers control the 'maint' keyword.

ii. Arch teams control their respective 'arch' keywords, but do not go
stable before 'maint'.

iii. Package maintainers could optionally keyword their packages as
~arch for their 'native platform'.

That should keep the responsibilities clear and things moving, correct?
Rule iii would also give you the same functionality as the maintainer
arch without having the cludge keyword ordering.

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHF/A2QTTR4CNEQARAkqkAJ9/zn7Sa/Bj+H5ZKuWSyVl6RNeiVwCfQa+0
oH0hUWT025XDS8aEhrc9Cvg=
=bSCC
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin F. Quinn wrote:
> On 5/9/2005 13:41:54, Jason Stubbs (jstubbs@gentoo.org) wrote:
> 
>>On Monday 05 September 2005 20:21, Simon Stelling wrote:
>>
>>>Ciaran McCreesh wrote:
>>>
>>>>If it isn't fit to be marked stable, it shouldn't be out of
>>>>package.mask. ~arch means "candidate for going stable after more
>>>>testing", not "might work".
>>>
>>>It's a bit of both. When you put a package into ~arch, it's in 
>>>"testing", so that says it needs further "testing" since there still 
>>>could be a not yet discovered bug, right?
>>
>>Testing of the ebuild rather than of the package, though. This is the 
>>point  where people sometimes get confused.
> 
> 
> That'd be me then :)
> 
> So we're talking about correctness of ebuilds (correct dependencies,
> use flag logic etc) and not whether the package actually works in depth.
> The latter is what caused me to suggest drawing together a large team of
> user-testers managed by arch-team devs.  Correctness of ebuilds takes
> us back to a dev role and the ebuild quiz, since it's necessary to
> understand ebuilds to criticise them.
> 

After a rather heated discussion a while back, I came up with this
definition:

- -arch :: the end-user software is/might be flakey
~arch :: the ebuild is/might be flakey but the software is good
 arch :: its all good :)

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHGCN2QTTR4CNEQARAiVdAJ9wVLt5CPyW//qxmuSC3GlZSOaI+QCeLqEl
78TX1Xtvbx7E4lBEdwnxMus=
=T6ZT
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 5 Sep 2005 11:21:03 +0100 Tom Martin <slarti@gentoo.org> wrote:
| Maybe I'm seeing this all wrong, but the fact is, the number of
| packages that need x86 arch team lovin' are pretty small, despite the
| number of overall keyworded packages being large. I don't think the
| x86 arch team needs to be very large: I think ten developers is
| plenty. I just don't know what they'd be doing if there were more.

Doesn't solve the coordination problem.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 5 Sep 2005 9:44:41 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
wrote:
| On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
| > On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn"
| > <kevquinn@gentoo.org>
| > wrote:
| > | 3) All packages need to be assigned an x86 arch team member
| > |    responsible.
| > 
| > Why?
| 
| Because if only the x86 arch team can mark stuff stable, anything
| without representation on the x86 arch team will stay unstable
| forever. Maybe rather than one specific arch team member, several
| would undertake to manage otherwise unassigned packages.

There are currently ~700 packages which are not visible to x86 or ~x86
users. Do these need an x86 arch team member? Is it the aim of the x86
arch team to cover the entire tree, or only things which are useful to
x86 users?

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 5 Sep 2005 20:41:54 +0900 Jason Stubbs <jstubbs@gentoo.org>
wrote:
| Testing of the ebuild rather than of the package, though. This is the
| point where people sometimes get confused.

You can't consider an ebuild stable unless the code it installs is also
reasonably stable.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Luis F. Araujo]

Kevin F. Quinn wrote:

>On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
>  
>
>>On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
>>wrote:
>>| 3) All packages need to be assigned an x86 arch team member
>>|    responsible.
>>
>>Why?
>>    
>>
>
>Because if only the x86 arch team can mark stuff stable, anything
>without representation on the x86 arch team will stay unstable forever.
>Maybe rather than one specific arch team member, several would
>undertake to manage otherwise unassigned packages.
>  
>
Well, but, assigning each ebuild an x86 arch member is not the same than
to have the package mantainer taking care of that? , i think the idea 
with the arch team
is to centralize QA.

>  
>
>>| 6) I notice the amd64 team requre their arch testers to
>>|    take the ebuild quiz; I think this is a bit harsh, as
>>|    arch testers are regular users without commit access to
>>|    CVS etc.  A simpler quiz targetted at ensuring the arch
>>|    testers know what is expected of them would lower the
>>|    bar and should encourage more users to join in.  Using
>>|    the ebuild quiz means you get people who quickly become
>>|    devs in their own right...
>>
>>The ebuild quiz isn't particularly difficult... If the proposed "write
>>an ebuild for equizapp" question goes through then maybe they could be
>>exempt from that until they need cvs access, but the main ebuild quiz
>>just tests basic understanding.
>>    
>>
>
>I guess it comes down to what you want a tester to do. In my mind, the
>task of a tester is to emerge the package normally, record the use flag
>configuration, and exercise the application as much as possible.  Possibly
>repeating with other use flag configurations.  If you want testers to do
>ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's
>a good idea..
>
>
>  
>
We could write a basic 'arch team' quiz?. It might be a slightly 
modified version
of the ebuild quiz.If the arch team menber wanna be a Gentoo dev with 
commit access he could
just take the ebuild quiz later.

And if for example someone takes the ebuild quiz , he could be both a 
dev and a arch team
member of course, in other words, the arch team quiz would be a sub-set of
the ebuild quiz targeted for arch teams.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: tentative x86 arch team glep

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R Hill wrote:
[snip]
| How about the ATs cc the maintainer on the bug they
| file to get the pkg bumped to stable, and giving them a period of time
| (48 hours? a week?) in which to raise any objections.  Of course the AT's
| would still have the power to go over the maintainers head in case of
| an emergency - but only if the maintainer can't be reached, or can't do it
| themselves for whatever reason, or is just being a big dink.
You are missing the whole point of an AT.  ATs have no inherit power,
they arn't even officialy gentoo people(yet).  All an AT can do is
comment on the particular piece of software in question.

An arch team(not AT) could disregard the package maintainers thoughts
and move said package to stable before the maintainer does on his arch.
~ However, this should be the exception, and not the rule.

Realisticly, if people stop being asses and work together, then a
consensus should allways be possible.  Only when people don't work
together does a situation like this arise.

The formation of a x86 arch team should be viewed as additional help to
maintainers who use x86, as well as act as the group that keywords for
x86 for those devs who don't use x86 as their arch.

- --
=======================================================
Mike Doty                           kingtaco@gentoo.org
Gentoo/AMD64 Strategic Lead         PGP Key: 0xA797C7A7
Gentoo Developer Relations
~                 ===GPG Fingerprint===
~   0094 7F06 913E 78D6 F1BB  06BA D0AD D125 A797 C7A7
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHHoK0K3RJaeXx6cRAppYAJ4pOihol4L6PEG4FOLF9d3uXjfJdACfRYH8
oVVySxBKfND2PBp450TiMAs=
=qm7h
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Mike Doty]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luis F. Araujo wrote:
| Kevin F. Quinn wrote:
|
|> On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
|>
|>
|>> On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
|>> wrote:
|>> | 3) All packages need to be assigned an x86 arch team member
|>> |    responsible.
|>>
|>> Why?
|>>
|>
|>
|> Because if only the x86 arch team can mark stuff stable, anything
|> without representation on the x86 arch team will stay unstable forever.
|> Maybe rather than one specific arch team member, several would
|> undertake to manage otherwise unassigned packages.
|>
|>
| Well, but, assigning each ebuild an x86 arch member is not the same than
| to have the package mantainer taking care of that? , i think the idea
| with the arch team
| is to centralize QA.
|
|>
|>
|>> | 6) I notice the amd64 team requre their arch testers to
|>> |    take the ebuild quiz; I think this is a bit harsh, as
|>> |    arch testers are regular users without commit access to
|>> |    CVS etc.  A simpler quiz targetted at ensuring the arch
|>> |    testers know what is expected of them would lower the
|>> |    bar and should encourage more users to join in.  Using
|>> |    the ebuild quiz means you get people who quickly become
|>> |    devs in their own right...
|>>
|>> The ebuild quiz isn't particularly difficult... If the proposed "write
|>> an ebuild for equizapp" question goes through then maybe they could be
|>> exempt from that until they need cvs access, but the main ebuild quiz
|>> just tests basic understanding.
|>>
|>
|>
|> I guess it comes down to what you want a tester to do. In my mind, the
|> task of a tester is to emerge the package normally, record the use flag
|> configuration, and exercise the application as much as possible.
|> Possibly
|> repeating with other use flag configurations.  If you want testers to do
|> ebuild QA, then the ebuild quiz becomes relevant, but I don't think it's
|> a good idea..
|>
|>
|>
|>
| We could write a basic 'arch team' quiz?. It might be a slightly
| modified version
| of the ebuild quiz.If the arch team menber wanna be a Gentoo dev with
| commit access he could
| just take the ebuild quiz later.
|
| And if for example someone takes the ebuild quiz , he could be both a
| dev and a arch team
| member of course, in other words, the arch team quiz would be a sub-set of
| the ebuild quiz targeted for arch teams.

another example of confusion of what AT means.  AT == archtester, not
arch team.

- --
=======================================================
Mike Doty                           kingtaco@gentoo.org
Gentoo/AMD64 Strategic Lead         PGP Key: 0xA797C7A7
Gentoo Developer Relations
~                 ===GPG Fingerprint===
~   0094 7F06 913E 78D6 F1BB  06BA D0AD D125 A797 C7A7
=======================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDHHs40K3RJaeXx6cRAghfAJ9Tri5VEUJEB42mw8kgWkDPK4diJwCffaZl
iLAux+XlgcZpo+9S3jB9/bM=
=E20M
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Luis F. Araujo]

Mike Doty wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Luis F. Araujo wrote:
> | Kevin F. Quinn wrote:
> |
> |> On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
> |>
> |>
> |>> On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn" 
> <kevquinn@gentoo.org>
> |>> wrote:
> |>> | 3) All packages need to be assigned an x86 arch team member
> |>> |    responsible.
> |>>
> |>> Why?
> |>>
> |>
> |>
> |> Because if only the x86 arch team can mark stuff stable, anything
> |> without representation on the x86 arch team will stay unstable 
> forever.
> |> Maybe rather than one specific arch team member, several would
> |> undertake to manage otherwise unassigned packages.
> |>
> |>
> | Well, but, assigning each ebuild an x86 arch member is not the same 
> than
> | to have the package mantainer taking care of that? , i think the idea
> | with the arch team
> | is to centralize QA.
> |
> |>
> |>
> |>> | 6) I notice the amd64 team requre their arch testers to
> |>> |    take the ebuild quiz; I think this is a bit harsh, as
> |>> |    arch testers are regular users without commit access to
> |>> |    CVS etc.  A simpler quiz targetted at ensuring the arch
> |>> |    testers know what is expected of them would lower the
> |>> |    bar and should encourage more users to join in.  Using
> |>> |    the ebuild quiz means you get people who quickly become
> |>> |    devs in their own right...
> |>>
> |>> The ebuild quiz isn't particularly difficult... If the proposed 
> "write
> |>> an ebuild for equizapp" question goes through then maybe they 
> could be
> |>> exempt from that until they need cvs access, but the main ebuild quiz
> |>> just tests basic understanding.
> |>>
> |>
> |>
> |> I guess it comes down to what you want a tester to do. In my mind, the
> |> task of a tester is to emerge the package normally, record the use 
> flag
> |> configuration, and exercise the application as much as possible.
> |> Possibly
> |> repeating with other use flag configurations.  If you want testers 
> to do
> |> ebuild QA, then the ebuild quiz becomes relevant, but I don't think 
> it's
> |> a good idea..
> |>
> |>
> |>
> |>
> | We could write a basic 'arch team' quiz?. It might be a slightly
> | modified version
> | of the ebuild quiz.If the arch team menber wanna be a Gentoo dev with
> | commit access he could
> | just take the ebuild quiz later.
> |
> | And if for example someone takes the ebuild quiz , he could be both a
> | dev and a arch team
> | member of course, in other words, the arch team quiz would be a 
> sub-set of
> | the ebuild quiz targeted for arch teams.
>
> another example of confusion of what AT means.  AT == archtester, not
> arch team.
>
>
Oh , i thought we were discussing about get an x86 arch team here.

But yes, the same would apply for the arch testers term too.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Mon, 2005-09-05 at 17:01 +0100, Ciaran McCreesh wrote:
> Doesn't solve the coordination problem.

Agreed.  If there's going to be an x86 team, it needs to be a full arch
team, and not some /dev/null that pretends to be one.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 20:09 -0500, Daniel Goller wrote:
> agreed talk/communcation is fine, if the maintainer is only trying to flex 
> muscles and does not have a good reason, the arch team ought to be able to do 
> what is best for gentoo and not be shot down by a (hm) stubborn(?) 
> maintainer, if the maintaner could do that, the arch team would be quite 
> limited in its effectiveness

That's a good example - one I hope doesn't occur too often ;-)  Equally,
there'll be times when the roles are reversed, and it's the arch team
member flexing muscle.  We're all human after all :)

Still, it'd only be fair for the arch team to assume the support burden
for the package version if they do this w/out the support of the package
maintainer.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 05 Sep 2005 20:20:28 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| Still, it'd only be fair for the arch team to assume the support
| burden for the package version if they do this w/out the support of
| the package maintainer.

If the package maintainer doesn't think their package is ready, it
should be in package.mask.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Sun, 2005-09-04 at 20:12 -0500, Daniel Goller wrote:
> sounds like you suggest to trick ~arch users into testing "unripe" 
> ebuilds/bumps/versions by sending it into ~arch to get the testing done while 
> someone in a chroot would be much better equipped for doing the testing with?

No.  

You've got to look at it in the context of the environment we work in.

The vast majority of our packages do not come with test strategies,
comprehensive test scripts, automated test cases that provide a large
coverage of the code base, or any other QA tools that a career software
QA person would expect / desire.  We don't have activities in place to
fill this gap - it's probably beyond our very limited resources anyhow.
We don't require (and don't cover in the quizzes) devs to have any
training or experience of deterministic software testing, or of
regression testing.  It is not our policy to require devs to write
regression tests for every valid bug posted in Bugzilla (or for any bug
at all, for that matter).

A package maintainer does what testing he can, and there are times when
we'd all wish the maintainer had done more :)  But there will always be
the need for a wider audience to be encouraged to test the package.  A
good rule of thumb is that a QA budget should be 40% of the development
budget.  We don't have the manpower to come anywhere near that.

We have only a fraction of the resources of Debian or RedHat - there
comes a point where we have to make up the difference *somehow*.  For
better or for worse, historically in Gentoo we've done it by turning to
our users.

Many *users* look on package.masked packages as being dangerous to
install, but are much more willing to run ~arch packages.  If you mask a
version of a popular package, you'll get a lot of correspondence asking
you when you'll unmask it, but you won't get much testing feedback to go
with it.  Once the package moves to ~arch, the amount of feedback
improves substantially.

If a package maintainer believes that a package WORKSFORME *after due
diligence*, then he's not only entitled to move it to ~arch, but he's
got no reason not to.

I've been through this first hand over the last 14 months with PHP 5.
It's a big package, one that I use all day every working day, and a
topic I co-wrote the official certification study guide for.  It's fair
to say that it's a package I know a lot about, and that others in the
community recognise I know well.  But, with over 100 separate features
to enable and disable, even over 14 months there are large parts of the
package that I won't have tested in depth, and there will always be
features that I'll never touch.

I kept PHP5 masked for those 14 months, and (as Jakub and others can
confirm) most of the feedback has been limited to "unmask that
puppy" (sometimes put in stronger terms ;-)  There were some bugs from
users who had found issues, but not many.

Rather than unmask the packages before they were read, I changed to
another approach.  I moved the work out of Portage into an overlay
instead.  This worked well.  It has attracted a bunch of regulars to
#gentoo-apache who have spent the last few months finding the bugs that
existed, and making sure that they're fixed and stay fixed.  It looks
likely that we'll get some new devs out of that too :)

Overlays are easy for larger pieces of work like PHP, Java,
Gnome/Gentopia, but they'll always be small packages where an overlay
feel like too much effort.  They may not be the answer to everything.

If we'd seen through the policy that every package has to belong to a
herd, then we could organise overlays by herd - and maybe leave it up to
the arch teams to import "stable" packages from the overlays into the
Portage tree proper.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Mon, 2005-09-05 at 20:37 +0100, Ciaran McCreesh wrote:
> If the package maintainer doesn't think their package is ready, it
> should be in package.mask.

I'm not arguing against that.  I agree with it.  Please stop trying to
hijack this and divert attention away from my point.  I'm asking
nicely :)

I'm asking that you assume any support burden that you create.  It only
seems fair.

If you're in an arch team, the package maintainer doesn't agree that the
package should be stable, and you're not willing to take on the support
for that package either, don't stabilise it.  We shouldn't stabilise
packages where no-one's willing to support it.

That's all I'm asking for, to go into the GLEP.  It's no big deal.  If
the arch team believe that know better than the package maintainer, then
they must know enough to be able to support it, no? ;-)

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 05 Sep 2005 21:16:37 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| On Mon, 2005-09-05 at 20:37 +0100, Ciaran McCreesh wrote:
| > If the package maintainer doesn't think their package is ready, it
| > should be in package.mask.
| 
| I'm not arguing against that.  I agree with it.  Please stop trying to
| hijack this and divert attention away from my point.  I'm asking
| nicely :)
| 
| I'm asking that you assume any support burden that you create.  It
| only seems fair.

Stabling a package which is not in packahe.mask is only a support
burden if package maintainers are abusing ~arch.

| If you're in an arch team, the package maintainer doesn't agree that
| the package should be stable, and you're not willing to take on the
| support for that package either, don't stabilise it.  We shouldn't
| stabilise packages where no-one's willing to support it.

If you don't agree that it should be stable, don't move it out out of
package.mask. ~arch is for stable candidates, and by sticking a package
you maintain in ~arch you are implicitly asking for it to be tested
with the aim of marking it stable.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Simon Stelling]

Ciaran McCreesh wrote:
> | I'm asking that you assume any support burden that you create.  It
> | only seems fair.
> 
> Stabling a package which is not in packahe.mask is only a support
> burden if package maintainers are abusing ~arch.

I absolutely agree with you, the only point is:

People are abusing ~arch in the real world, and we're not yet living in an ideal 
world.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Herbert]

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

On Mon, 2005-09-05 at 21:34 +0100, Ciaran McCreesh wrote:
> Stabling a package which is not in packahe.mask is only a support
> burden if package maintainers are abusing ~arch.
>
> If you don't agree that it should be stable, don't move it out out of
> package.mask. ~arch is for stable candidates, and by sticking a package
> you maintain in ~arch you are implicitly asking for it to be tested
> with the aim of marking it stable.

Which part of "I agree with you" didn't you understand? :(

However, it still comes across like you're trying to change the subject,
even after being asked not to :(

I've put my point across, but you're determined not to address it
directly.  I guess there's nothing else to say on this topic.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                              http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Mon, 05 Sep 2005 21:52:56 +0100 Stuart Herbert <stuart@gentoo.org>
wrote:
| I've put my point across, but you're determined not to address it
| directly.  I guess there's nothing else to say on this topic.

Bah, I'm not changing the subject at all. It's the same issue. Marking
something as stable only creates more of a support burden than marking
it ~arch if package maintainers are misusing keywords. And if they are,
this will give them even more of an incentive to stop.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: Re: tentative x86 arch team glep

[R Hill]

On Mon, 05 Sep 2005 12:02:02 -0500, Mike Doty wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> R Hill wrote:
> [snip]
> | How about the ATs cc the maintainer on the bug they file to get the pkg
> | bumped to stable, and giving them a period of time (48 hours? a week?)
> | in which to raise any objections.  Of course the AT's would still have
> | the power to go over the maintainers head in case of an emergency - but
> | only if the maintainer can't be reached, or can't do it themselves for
> | whatever reason, or is just being a big dink.
> You are missing the whole point of an AT.  ATs have no inherit power, they
> arn't even officialy gentoo people(yet).  All an AT can do is comment on
> the particular piece of software in question.
> 
> An arch team(not AT) could disregard the package maintainers thoughts and
> move said package to stable before the maintainer does on his arch. ~
> However, this should be the exception, and not the rule.

Okay, that's what i originally thought.  But after seeing all the
controversy this is causing, i figured i must have been mistaken and AT's
must be tiny gods or something. Now i'm just confused and a little hungry.

Either way, i'm just saying whoever is doing the bumping could drop a
quick note to the pkg maintainer before the fact.  It's only polite.

--de.


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: tentative x86 arch team glep

[R Hill]

On Mon, 05 Sep 2005 21:09:28 +0100, Stuart Herbert wrote:

> Many *users* look on package.masked packages as being dangerous to
> install, but are much more willing to run ~arch packages.  If you mask a
> version of a popular package, you'll get a lot of correspondence asking
> you when you'll unmask it, but you won't get much testing feedback to go
> with it.  Once the package moves to ~arch, the amount of feedback
> improves substantially.

It's not so much the case that no-one dares try pmasked pkgs.  Taking a
quick trip through the forum will turn up many examples of people who do.
 But the longstanding policy with masked pkgs is 'this is unsupported - if
 it breaks, don't come to us - use at your own risk'.  Right now there are
 plenty of people using the Gnome 2.12 RC or xorg 6.8.99 or gcc 4 or the
 masked utopia stack, but they know better than to file bugs because it
 will just be closed as invalid.  Personally, the only time i'll file a
 bug against a masked package is when i have a patch.

> Rather than unmask the packages before they were read, I changed to
> another approach.  I moved the work out of Portage into an overlay
> instead.  This worked well.  It has attracted a bunch of regulars to
> #gentoo-apache who have spent the last few months finding the bugs that
> existed, and making sure that they're fixed and stay fixed.  It looks
> likely that we'll get some new devs out of that too :)
> 
> Overlays are easy for larger pieces of work like PHP, Java,
> Gnome/Gentopia, but they'll always be small packages where an overlay
> feel like too much effort.  They may not be the answer to everything.

I'd like to see a lot more of this.  I haven't used the PHP overlay, but
Halcy0n's GCC4 overlay helped centralize a group of testers that ended up
getting a lot of major bugs fixed pre-release.  The Gentopia overlay takes
it a step farther with it's own bug tracker.  See, now here is something
you know was created specifically for experimenting and testing, and you
know that your feedback is wanted and welcomed.

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Luis Medinas]

On Mon, 2005-09-05 at 22:42 +0200, Simon Stelling wrote:
> Ciaran McCreesh wrote:
> > | I'm asking that you assume any support burden that you create.  It
> > | only seems fair.
> > 
> > Stabling a package which is not in packahe.mask is only a support
> > burden if package maintainers are abusing ~arch.
> 
> I absolutely agree with you, the only point is:
> 
> People are abusing ~arch in the real world, and we're not yet living in an ideal 
> world.

Yes it's true probably we should introduce another keyword for
maintainers that is completly unstable. Then the Archs Teams keyword the
packages.
Most of the people don't understand that ~arch is a testing keyword and
it's not stable. Fortunatly most of the bugs we get are from ~arch and
not from stable arch.
-- 
Luis Medinas <metalgod@gentoo.org>
http://dev.gentoo.org/~metalgod
Gentoo Linux Developer: AMD64,Printing,Media-Optical

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [OT] Meaning of p.mask

[Simon Stelling]

> It's not so much the case that no-one dares try pmasked pkgs.  Taking a
> quick trip through the forum will turn up many examples of people who do.
>  But the longstanding policy with masked pkgs is 'this is unsupported - if
>  it breaks, don't come to us - use at your own risk'.  Right now there are
>  plenty of people using the Gnome 2.12 RC or xorg 6.8.99 or gcc 4 or the
>  masked utopia stack, but they know better than to file bugs because it
>  will just be closed as invalid.  Personally, the only time i'll file a
>  bug against a masked package is when i have a patch.

I think you have to distinguish between packages beeing in p.mask because they 
really need a lot of testing and should only be tested by users that are able to 
  fix their system themselves and packages that are in p.mask because they're 
horribly broken. I filed 4 bugs about gnome 2.12 without adding a single patch, 
3 of them got closed a day later.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] tentative x86 arch team glep

[Jakub Moc]

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


5.9.2005, 22:09:28, Stuart Herbert wrote:

> I kept PHP5 masked for those 14 months, and (as Jakub and others can
> confirm) most of the feedback has been limited to "unmask that
> puppy" (sometimes put in stronger terms ;-)  There were some bugs from
> users who had found issues, but not many.

Well, yeah - and the same goes for e.g. MySQL-4.1; the only thing you get from
p.masking popular packages is a be-weekly bug like "WTH is this still masked,
upstream says it's stable and best version released yet which everyone should
upgrade to" ;p

Real testing from users comes when it goes to ~arch, then they start screaming
"hell, it broke my box, why isn't this p.masked, it's so buggy!" :)

So, unless we have a *lot more* devs to do thorough testing of p.masked ebuilds
(totally unfeasible to test all the PHP5 features e.g., if you have some 3
people in php herd), then it's largely up to users to do the testing in ~arch.
p.mask ebuilds will be tested by really *few* users, so most of the bugs will
stay unnoticed until this is moved to ~arch.


> Rather than unmask the packages before they were read, I changed to
> another approach.  I moved the work out of Portage into an overlay
> instead.  This worked well.  It has attracted a bunch of regulars to
> #gentoo-apache who have spent the last few months finding the bugs that
> existed, and making sure that they're fixed and stay fixed.  It looks
> likely that we'll get some new devs out of that too :)

Absolutely. The overlay made the whole thing get into portage *much* faster
then all those months in p.mask.


--
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

[-- Attachment #2: Type: application/pgp-signature, Size: 183 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Chris Gianelloni]

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

On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
> Stuart Herbert wrote:
> > I've no personal problem with arch teams sometimes needing to do their
> > own thing, provided it's confined to a specific class of package.
> > Outside of the core packages required to boot & maintain a platform,
> > when is there ever a need for arch maintainers to decide that they know
> > better than package maintainers?
> 
> I assume you're talking of the case where arch team and maintainer's arch are 
> the same. I think normally package maintainers can decide better whether their 
> package should go stable on their arch than an arch team, as they get all the 
> bugs for it. On the other hand, we can't define a "maintainer arch" in many 
> cases, so either we leave the authority to the arch team or we'll just have an 
> x86 arch team without the expected effects.

I still think that the concept of a "maintainer arch" is completely
broken anyway.  I like the idea of adding something like a "maint"
KEYWORD, or something similar to mark that the ebuild is considered
"stable" material by the maintainer.  We can't rely on the maintainer
using *any* arch as their main architecture.  Take myself, as an
example.  The architecture I use when doing maintenance and adding new
packages is just whatever machine I happen to be using.  It could be
x86, amd64, ppc, hppa, sparc, or mips, and there's no rhyme nor reason
to which I am using at any point in time.  This is becoming a more
common occurrence that our developers have machines across many
architectures.  Personally, I don't think this should be an added
KEYWORD, so much as a variable within the ebuild.  I'd hate to start
seeing users filing bugs using "maint" as their "arch" or adding maint
to their USE flags.  Just remember that if it is possible, somebody will
do it... ;]

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] tentative x86 arch team glep

[Sven Vermeulen]

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

On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote:
> At the moment, the only way for a package maintainer to mark a package
> stable is to mark it stable on a "real" arch.  Creating the "maintainer"
> arch solves this very problem.

Yes, but please don't call it the "maintainer" arch. This will confuse our
users and it'll be quite difficult to document. I would rather vote for a
MAINTENANCE keyword, like the following example:

  MAINTENANCE="~x86"  # Maintainer uses x86, package not deemed stable

This provides two (wanted) inputs: stability and maintenance architecture.

And it keeps backwards compatibility.

Wkr,
      Sven Vermeulen

-- 
  Documentation project leader - Gentoo Foundation Trustee

  The Gentoo Project   <<< http://www.gentoo.org >>>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Luis F. Araujo]

Chris Gianelloni wrote:

>On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
>  
>
>>Stuart Herbert wrote:
>>    
>>
>>>I've no personal problem with arch teams sometimes needing to do their
>>>own thing, provided it's confined to a specific class of package.
>>>Outside of the core packages required to boot & maintain a platform,
>>>when is there ever a need for arch maintainers to decide that they know
>>>better than package maintainers?
>>>      
>>>
>>I assume you're talking of the case where arch team and maintainer's arch are 
>>the same. I think normally package maintainers can decide better whether their 
>>package should go stable on their arch than an arch team, as they get all the 
>>bugs for it. On the other hand, we can't define a "maintainer arch" in many 
>>cases, so either we leave the authority to the arch team or we'll just have an 
>>x86 arch team without the expected effects.
>>    
>>
>
>I still think that the concept of a "maintainer arch" is completely
>broken anyway.  I like the idea of adding something like a "maint"
>KEYWORD, or something similar to mark that the ebuild is considered
>"stable" material by the maintainer.  
>

This keyword would be independent of any arch right?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Tue, 6 Sep 2005 17:22:09 +0200 Sven Vermeulen <swift@gentoo.org>
wrote:
| On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote:
| > At the moment, the only way for a package maintainer to mark a
| > package stable is to mark it stable on a "real" arch.  Creating the
| > "maintainer" arch solves this very problem.
| 
| Yes, but please don't call it the "maintainer" arch. This will
| confuse our users and it'll be quite difficult to document.

The users will never see it. Tell them "it's for developers only".

|   MAINTENANCE="~x86"  # Maintainer uses x86, package not deemed stable

Yick. We can't use ekeyword then.

| And it keeps backwards compatibility.

Sticking extra entries in KEYWORDS is backwards compatible.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Joshua Baergen]

Sven Vermeulen wrote:

>
>  MAINTENANCE="~x86"  # Maintainer uses x86, package not deemed stable
>
>  
>
I would even suggest not indicating maintainer arch at all.  If ATs are 
going to be responsible for keywording we should blackbox the process to 
ward off assumptions and laziness.   Whether the maintainer thinks it's 
stable or not on x86 should not affect the AMD64 AT, or even the x86 AT 
for that matter.

We could even boil it down to M_STABLE="yes"|"no" at that point 
(suggestions for variable name welcome).

--
Joshua Baergen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Paul de Vrieze]

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

On Tuesday 06 September 2005 16:28, Chris Gianelloni wrote:
> I still think that the concept of a "maintainer arch" is completely
> broken anyway.  I like the idea of adding something like a "maint"
> KEYWORD, or something similar to mark that the ebuild is considered
> "stable" material by the maintainer.  We can't rely on the maintainer
> using *any* arch as their main architecture.  Take myself, as an
> example.  The architecture I use when doing maintenance and adding new
> packages is just whatever machine I happen to be using.  It could be
> x86, amd64, ppc, hppa, sparc, or mips, and there's no rhyme nor reason
> to which I am using at any point in time.  This is becoming a more
> common occurrence that our developers have machines across many
> architectures.  Personally, I don't think this should be an added
> KEYWORD, so much as a variable within the ebuild.  I'd hate to start
> seeing users filing bugs using "maint" as their "arch" or adding maint
> to their USE flags.  Just remember that if it is possible, somebody will
> do it... ;]

I think those silly users could be handled similarly as those who use 
ACCEPT_KEYWORDS="*" or similar.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Paul de Vrieze]

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

On Tuesday 06 September 2005 19:11, Joshua Baergen wrote:
> Sven Vermeulen wrote:
> >  MAINTENANCE="~x86"  # Maintainer uses x86, package not deemed stable
>
> I would even suggest not indicating maintainer arch at all.  If ATs are
> going to be responsible for keywording we should blackbox the process to
> ward off assumptions and laziness.   Whether the maintainer thinks it's
> stable or not on x86 should not affect the AMD64 AT, or even the x86 AT
> for that matter.
>
> We could even boil it down to M_STABLE="yes"|"no" at that point
> (suggestions for variable name welcome).

In this case just adding a new keyword would be easier. It also would mean 
that current tools like imlate would be usable without (significant) change.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Chris Gianelloni]

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

On Tue, 2005-09-06 at 12:25 -0400, Luis F. Araujo wrote:
> Chris Gianelloni wrote:
> 
> >On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
> >  
> >
> >>Stuart Herbert wrote:
> >>    
> >>
> >>>I've no personal problem with arch teams sometimes needing to do their
> >>>own thing, provided it's confined to a specific class of package.
> >>>Outside of the core packages required to boot & maintain a platform,
> >>>when is there ever a need for arch maintainers to decide that they know
> >>>better than package maintainers?
> >>>      
> >>>
> >>I assume you're talking of the case where arch team and maintainer's arch are 
> >>the same. I think normally package maintainers can decide better whether their 
> >>package should go stable on their arch than an arch team, as they get all the 
> >>bugs for it. On the other hand, we can't define a "maintainer arch" in many 
> >>cases, so either we leave the authority to the arch team or we'll just have an 
> >>x86 arch team without the expected effects.
> >>    
> >>
> >
> >I still think that the concept of a "maintainer arch" is completely
> >broken anyway.  I like the idea of adding something like a "maint"
> >KEYWORD, or something similar to mark that the ebuild is considered
> >"stable" material by the maintainer.  
> >
> 
> This keyword would be independent of any arch right?

Correct.

It would be a KEYWORD or some other variable that says "I'm the
maintainer, and I say it is ready to go stable" without relying on any
particular architecture to be an indicator of stability.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] tentative x86 arch team glep

[Chris Gianelloni]

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

On Tue, 2005-09-06 at 17:22 +0200, Sven Vermeulen wrote:
> On Sun, Sep 04, 2005 at 10:39:44PM +0100, Stuart Herbert wrote:
> > At the moment, the only way for a package maintainer to mark a package
> > stable is to mark it stable on a "real" arch.  Creating the "maintainer"
> > arch solves this very problem.
> 
> Yes, but please don't call it the "maintainer" arch. This will confuse our
> users and it'll be quite difficult to document. I would rather vote for a
> MAINTENANCE keyword, like the following example:
> 
>   MAINTENANCE="~x86"  # Maintainer uses x86, package not deemed stable
> 
> This provides two (wanted) inputs: stability and maintenance architecture.

You'd have a really long list of maintenance architectures for me.  Like
I said, I don't use a single machine.  The idea of *any* architecture
being my "primary" one just doesn't really fit.  There's also the simple
fact that it doesn't matter *at all* what the maintainer runs it on,
only whether or not (s)he considers it stable.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] tentative x86 arch team glep

[Donnie Berkholz]

Chris Gianelloni wrote:
> You'd have a really long list of maintenance architectures for me.  Like
> I said, I don't use a single machine.  The idea of *any* architecture
> being my "primary" one just doesn't really fit.  There's also the simple
> fact that it doesn't matter *at all* what the maintainer runs it on,
> only whether or not (s)he considers it stable.

There have been many cases where I've considered a package stable on one 
architecture but not on another. How would I indicate this?

Thanks,
Donnie
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Luis F. Araujo]

Chris Gianelloni wrote:

>On Tue, 2005-09-06 at 12:25 -0400, Luis F. Araujo wrote:
>  
>
>>Chris Gianelloni wrote:
>>
>>    
>>
>>>On Sun, 2005-09-04 at 22:46 +0200, Simon Stelling wrote:
>>> 
>>>
>>>      
>>>
>>>>Stuart Herbert wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>I've no personal problem with arch teams sometimes needing to do their
>>>>>own thing, provided it's confined to a specific class of package.
>>>>>Outside of the core packages required to boot & maintain a platform,
>>>>>when is there ever a need for arch maintainers to decide that they know
>>>>>better than package maintainers?
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I assume you're talking of the case where arch team and maintainer's arch are 
>>>>the same. I think normally package maintainers can decide better whether their 
>>>>package should go stable on their arch than an arch team, as they get all the 
>>>>bugs for it. On the other hand, we can't define a "maintainer arch" in many 
>>>>cases, so either we leave the authority to the arch team or we'll just have an 
>>>>x86 arch team without the expected effects.
>>>>   
>>>>
>>>>        
>>>>
>>>I still think that the concept of a "maintainer arch" is completely
>>>broken anyway.  I like the idea of adding something like a "maint"
>>>KEYWORD, or something similar to mark that the ebuild is considered
>>>"stable" material by the maintainer.  
>>>
>>>      
>>>
>>This keyword would be independent of any arch right?
>>    
>>
>
>Correct.
>
>It would be a KEYWORD or some other variable that says "I'm the
>maintainer, and I say it is ready to go stable" without relying on any
>particular architecture to be an indicator of stability.
>
>  
>
Perfect, i _highly_ agree with the idea then.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Tue, 06 Sep 2005 12:35:31 -0700 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| Chris Gianelloni wrote:
| > You'd have a really long list of maintenance architectures for me.
| > Like I said, I don't use a single machine.  The idea of *any*
| > architecture being my "primary" one just doesn't really fit.
| > There's also the simple fact that it doesn't matter *at all* what
| > the maintainer runs it on, only whether or not (s)he considers it
| > stable.
| 
| There have been many cases where I've considered a package stable on
| one architecture but not on another. How would I indicate this?

This would be one of the cases where a maintainer / stable keyword
would be inappropriate. I suspect there are a lot more of these than
some people think...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Martin Schlemmer]

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

On Tue, 2005-09-06 at 20:47 +0100, Ciaran McCreesh wrote:
> On Tue, 06 Sep 2005 12:35:31 -0700 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | Chris Gianelloni wrote:
> | > You'd have a really long list of maintenance architectures for me.
> | > Like I said, I don't use a single machine.  The idea of *any*
> | > architecture being my "primary" one just doesn't really fit.
> | > There's also the simple fact that it doesn't matter *at all* what
> | > the maintainer runs it on, only whether or not (s)he considers it
> | > stable.
> | 
> | There have been many cases where I've considered a package stable on
> | one architecture but not on another. How would I indicate this?
> 
> This would be one of the cases where a maintainer / stable keyword
> would be inappropriate. I suspect there are a lot more of these than
> some people think...
> 

We already have:

arch  - in theory stable
~arch - in theory should work, but needs testing
-arch - do not work at all

What about !arch or something (to connect with the one reply to the
summary thread) to really indicate unstable on that arch?  Should cover
those things that sorda work on the arch, but you rather want developers
or experienced users that can patch bugs to look at it ...

Sure it will still leave some holes, but will be a bit more flexible
than a single maintainer keyword.


-- 
Martin Schlemmer


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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer <azarah@gentoo.org>
wrote:
| What about !arch or something (to connect with the one reply to the
| summary thread) to really indicate unstable on that arch?  Should
| cover those things that sorda work on the arch, but you rather want
| developers or experienced users that can patch bugs to look at it ...

Those go in per-profile package.masks. It's more flexible than a
keyword.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[warnera6]

Ciaran McCreesh wrote:
> On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer <azarah@gentoo.org>
> wrote:
> | What about !arch or something (to connect with the one reply to the
> | summary thread) to really indicate unstable on that arch?  Should
> | cover those things that sorda work on the arch, but you rather want
> | developers or experienced users that can patch bugs to look at it ...
> 
> Those go in per-profile package.masks. It's more flexible than a
> keyword.
> 
Speaking of flexabilty, are there tools out there to perform look-ups 
into p.masks to figure out why things are masked?  There seems to be a 
standard format to the file although the part at the beginning kind of 
throws off a simpler regex.  Flexability is good sure, but I would think 
a developer needs to easily determine why something is pmasked ( broken, 
"testing", security, removal, etc... ) and keywords do that a lot faster 
than searching through a pmask file.  If the searching is sped up via a 
better format and a searching tool then all the better, yes?

The other thing being a keyword is right in the ebuild where pmask 
status is in package.mask.  I am not for putting pmask status in the 
ebuild though, as that is not necessary, once again a tool problem :/
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Stephen P. Becker]

Ciaran McCreesh wrote:
> On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer <azarah@gentoo.org>
> wrote:
> | What about !arch or something (to connect with the one reply to the
> | summary thread) to really indicate unstable on that arch?  Should
> | cover those things that sorda work on the arch, but you rather want
> | developers or experienced users that can patch bugs to look at it ...
> 
> Those go in per-profile package.masks. It's more flexible than a
> keyword.

This is true, however it requires users to possibly make a gazillion 
entries in their /etc/portage/package.unmask if they want to use a lot 
of what are considered truly unstable packages.  You might say they 
could just symlink their profile package.mask to 
/etc/portage/package.unmask, but then, maybe somebody doesn't want to 
unmask *everything* in there.  You can argue that the extra effort 
required ensures that only competent and persistent users are testing 
this software, but I'm not sure that is the case (note that I don't have 
any good way to justify this statement...just speculation).

Anyway, getting to my point, I think small arches such as mips would 
benefit from reducing the barriers required to test this sort of stuff. 
  I know I've probably abused ~arch by the strictest definitions on 
several occasions.  Otherwise, I would be practically the *only* person 
testing things, and that is not a good way to uncover bugs.  Only 
widespread use of the packages will really bring these out, which I 
think could be better achieved with the addition of a truly "unstable" 
keyword like az is suggesting.  Just my 2 cents...

-Steve

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Martin Schlemmer]

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

On Tue, 2005-09-06 at 22:31 +0100, Ciaran McCreesh wrote:
> On Tue, 06 Sep 2005 23:19:43 +0200 Martin Schlemmer <azarah@gentoo.org>
> wrote:
> | What about !arch or something (to connect with the one reply to the
> | summary thread) to really indicate unstable on that arch?  Should
> | cover those things that sorda work on the arch, but you rather want
> | developers or experienced users that can patch bugs to look at it ...
> 
> Those go in per-profile package.masks. It's more flexible than a
> keyword.
> 

I would have said a keyword is more flexible (and less work) than
package.masks, but I do not put that much value in the idea - was more
just to have something more to kick around.


-- 
Martin Schlemmer


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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Tue, 06 Sep 2005 17:41:35 -0400 warnera6 <warnera6@egr.msu.edu>
wrote:
| Speaking of flexabilty, are there tools out there to perform look-ups 
| into p.masks to figure out why things are masked?

emerge -pv

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Tue, 06 Sep 2005 17:46:40 -0400 "Stephen P. Becker"
<geoman@gentoo.org> wrote:
| This is true, however it requires users to possibly make a gazillion 
| entries in their /etc/portage/package.unmask if they want to use a
| lot of what are considered truly unstable packages.

There are dozens of scripts floating around that will automatically
create the relevant package.mask and package.keywords entries for a
given package and its dependencies. Maybe it would be worth someone
cleaning one of them up and sticking it somewhere sensible...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[warnera6]

Ciaran McCreesh wrote:
> On Tue, 06 Sep 2005 17:41:35 -0400 warnera6 <warnera6@egr.msu.edu>
> wrote:
> | Speaking of flexabilty, are there tools out there to perform look-ups 
> | into p.masks to figure out why things are masked?
> 
> emerge -pv
> 

emerge -pv would be a cludge for what many are after.  If I want to say, 
figure out how many mediawiki versions are pmasked; emerge -pv is a 
crappy way to go about it.  I will look into taking that code and put it 
in another, more flexable script ;)

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Dave Shanker]

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

On 9/6/05, Martin Schlemmer <azarah@gentoo.org> wrote:
> 
> arch - in theory stable
> ~arch - in theory should work, but needs testing
> -arch - do not work at all



Just out of curiosity, why are there know broken packages in portage? 
Wouldn't -arch packages best be handled outside of the official portage tree 
such as a developers overlay? Couldn't the same be said for pmasked also? If 
we were to remove pmasked and -arch packages from portage and and handle 
them via overlays, the portage tree would contain only working versions of 
programs and testing versions of the same program which would be ~arch'd. 
This should should suffice for most users; but If they want to run the 
"broken" programs, they'd download the overlay and install it again. No need 
to add lines to both package.unmask and package.keywors either. Once broken 
package is fixed, it should be moved into portage for testing and then 
finally unarched.

And I apologize in advance if this was brought up before or is just plain 
stupid.. I'm fairly new to Gentoo development list and this is my first 
reply :).

Regards,

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

Re: [gentoo-dev] tentative x86 arch team glep

[Ciaran McCreesh]

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

On Tue, 6 Sep 2005 18:51:51 -0400 Dave Shanker <dshanker@gmail.com>
wrote:
| Just out of curiosity, why are there know broken packages in portage? 

a) Convenience.
b) Sadly, unlike some other distributions we don't refuse to package
things which won't work on all our tier one archs.

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] tentative x86 arch team glep

[Stephen P. Becker]

Dave Shanker wrote:
> On 9/6/05, *Martin Schlemmer* <azarah@gentoo.org 
> <mailto:azarah@gentoo.org>> wrote:
> 
>     arch  - in theory stable
>     ~arch - in theory should work, but needs testing
>     -arch - do not work at all
> 
> 
> 
> Just out of curiosity, why are there know broken packages in portage?

What works perfectly on one arch may be horribly broken on another. 
Remember, Gentoo runs on far more than just linux/x86.

> Wouldn't -arch packages best be handled outside of the official portage 
> tree such as a developers overlay?

No, see above.

> Couldn't the same be said for pmasked 
> also? 

Again, see above.

> If we were to remove pmasked and -arch packages from portage and  
> and handle them via overlays, the portage tree would contain only 
> working versions of programs and testing versions of the same program 
> which would be ~arch'd. This should should suffice for most users; but 
> If they want to run the "broken" programs, they'd download the overlay 
> and install it again. No need to add lines to both package.unmask and 
> package.keywors either. Once broken package is fixed, it should be moved 
> into portage for testing and then finally unarched.

Same song, new verse...

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Stuart Longland]

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

Ciaran McCreesh wrote:
> On Mon, 5 Sep 2005 9:44:41 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
> wrote:
> | On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
> | > On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn"
> | > <kevquinn@gentoo.org>
> | > wrote:
> | > | 3) All packages need to be assigned an x86 arch team member
> | > |    responsible.
> | > 
> | > Why?
> | 
> | Because if only the x86 arch team can mark stuff stable, anything
> | without representation on the x86 arch team will stay unstable
> | forever. Maybe rather than one specific arch team member, several
> | would undertake to manage otherwise unassigned packages.
> 
> There are currently ~700 packages which are not visible to x86 or ~x86
> users. Do these need an x86 arch team member? Is it the aim of the x86
> arch team to cover the entire tree, or only things which are useful to
> x86 users?

This is a good point...

If nobody on x86 is using a given package, is there a need to worry
about marking it ~x86/x86?

This is how we handle things on the mips team -- that is, unless a user
comes to us saying "Package foobar works on mips, can you please add
~mips for me", we normally don't worry about it.

Maintaining keywords on _every_ package in the tree, IMHO would be a
waste of effort unless there are a significant number of users actually
using _every_ package in the tree.
-- 
 ____                   _             Stuart Longland (a.k.a Redhatter)
/  _ \   ___    ___  __| |__  __   __ Gentoo Linux/MIPS Cobalt and Docs
- (_) \ /   \  ;   \(__   __)/  \ /  \                        Developer
 \    //  O _| / /\ \  | |  | /\ | /\ |
 /   / \   /__| /  \ \ | |  | \/ | \/ |
(___/   \____/|_;  |_| \_/   \__/ \__/ http://dev.gentoo.org/~redhatter

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

Re: [gentoo-dev] tentative x86 arch team glep

[Kevin F. Quinn]

On 7/9/2005 3:10:12, Stuart Longland (redhatter@gentoo.org) wrote:
> Ciaran McCreesh wrote:
> > On Mon, 5 Sep 2005 9:44:41 +0200 "Kevin F. Quinn" <kevquinn@gentoo.org>
> > wrote:
> > | On 5/9/2005 1:29:57, Ciaran McCreesh (ciaranm@gentoo.org) wrote:
> > | > On Mon, 5 Sep 2005 1:12:54 +0200 "Kevin F. Quinn"
> > | > <kevquinn@gentoo.org>
> > | > wrote:
> > | > | 3) All packages need to be assigned an x86 arch team member
> > | > |    responsible.
> > | > 
> > | > Why?
> > | 
> > | Because if only the x86 arch team can mark stuff stable, anything
> > | without representation on the x86 arch team will stay unstable
> > | forever. Maybe rather than one specific arch team member, several
> > | would undertake to manage otherwise unassigned packages.
> > 
> > There are currently ~700 packages which are not visible to x86 or ~x86
> > users. Do these need an x86 arch team member? Is it the aim of the x86
> > arch team to cover the entire tree, or only things which are useful to
> > x86 users?
> 
> If nobody on x86 is using a given package, is there a need to worry
> about marking it ~x86/x86?

When I said 'All', I didn't mean to include stuff that's not in x86.
What I was trying to get at, was the idea that if the x86 arch team
is responsible for stable marking x86, then all packages that want
to go x86 need representation on the x86 arch team.

Kev.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] tentative x86 arch team glep

[Chris Gianelloni]

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

On Wed, 2005-09-07 at 00:03 +0100, Ciaran McCreesh wrote:
> a) Convenience.

Testing.

Some times we want to get user testing on a specific package or two, and
it is easier to distribute it via the normal portage tree than not.
Another reason for masking packages is for security reasons.  This
especially happens when there is no patch or fixed version upstream.  It
allows the user to decide if they wish to continue running a vulnerable
package or not, without forcing the removal of the package from the
tree.

> b) Sadly, unlike some other distributions we don't refuse to package
> things which won't work on all our tier one archs.

This is both a pro and a con.  There are many packages that we include
that will *never* run on architectures but x86/amd64.  These are mostly
binary applications and games, but from the feedback that I have gotten,
our users seem to enjoy that we have these packages in our tree.  It is
definitely a disadvantage when a source-based package does not work on
all architectures, but with the volunteer team that we have, I think we
do pretty well.  The arch teams also do an excellent job of making sure
things either work or don't on their architecture.  The only way we
could enforce source-based packages working on all of our tier-one
architectures would be to have *much* larger arch teams.  It would also
slow down our productivity greatly.  After all, if package foo doesn't
work on sparc, they just don't have to keyword it.  I find this requires
much less manpower than forcing the package to either be removed, no
matter how useful it is, or forcing the sparc team to come up with a
patch so it can work on that architecture.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] tentative x86 arch team glep

[Chris Gianelloni]

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

On Wed, 2005-09-07 at 08:46 +0200, Kevin F. Quinn wrote:
> If nobody on x86 is using a given package, is there a need to worry
> > about marking it ~x86/x86?
> 
> When I said 'All', I didn't mean to include stuff that's not in x86.
> What I was trying to get at, was the idea that if the x86 arch team
> is responsible for stable marking x86, then all packages that want
> to go x86 need representation on the x86 arch team.

No, they don't.  That's the idea of an arch team.  You don't section off
everything *again* as we already have herds for that.  Instead, if
you're on the x86 arch team (or sparc, or mips or anything, really) than
you are responsible for the x86 keyword.  All of it.  Every package.
Now, while there might be some internal "Hey, I use this all the time,
so I'll keep up with it" types of things, there's also the "I don't use
this package but can test it when needed" area that needs to be kept
track of.  While fundamentally different, I would say the games team
works similarly to this.  We have *lots* of packages that we personally
don't use, but we maintain.  The arch teams do the same thing.  They
test what is requested of them, and determine if it is ready for
stabilization, or even just ~arch keywording.  Sometimes, they determine
a patch is needed, and add it or send it to the package maintainer for
inclusion.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

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