public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] [Summary] tentative x86 arch team glep
@ 2005-09-06 10:03 Chris White
  2005-09-06 12:35 ` Mike Doty
  2005-09-06 17:03 ` Ed W
  0 siblings, 2 replies; 9+ messages in thread
From: Chris White @ 2005-09-06 10:03 UTC (permalink / raw
  To: gentoo-dev

Yet another thread that's getting horrificly long, here comes your summary 
folks:

Introduction

An email was sent by Grant Goodyear containing a GLEP for the official x86 
arch team establishment [1]. 

Discussions

Ciaran McCreesh requested more information on exactly what the line:

There will be a considerable one-time cost involved in establishing a 
robust x86 arch team.

Stated.  Grant stated the following:

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

Stuart Herbert states the glep really addresses what problems it will be to 
developers, but in actually it is what problems occur to the users.

Joshua Baergen states that maintainers need to notify arch teams about going 
stable before a package meets its 30 day minimum stable requirement (without 
any outstanding bugs).  

Homer Parker states that some devs should have stable only system, some 
testing, and some with chroots for package.mask testing.

bit o flames here

Jason Stubbs recommends that an overlay for ebuild devs to work on be created, 
and arch team stuff goes to the main tree.  Users could use gensync in order 
to decide how fast paced they want their software model to go.

Mike Frysinger states that arch teams need contact with the maintainers before 
going stable.

Grant Goodyear states that while this is true, arch teams need the final say, 
because they know deal with the architecture aspect (ie. while maintainers 
know the software, arch teams know the system).

Jason Wever states that while this is true, arch teams may need to stablize 
something sooner if previous versions were broken.

Stuart Herbert recommends that a main keyword be created to mark packages as 
ready for arch testing.  This would increase communication between 
maintainers and arch teams.

Ciaran McCreesh states that while it's a good idea for some packages, others 
need arch maintainers to override (toolchain, kernel).

Stuart Herbert asks as to why maintainers need to be overrided instead of 
communicated to directly.

Simon Stelling states that maintainers can vouch for their own arch, but it's 
hard to tell another arch team how to handle their own system.

Grant Goodyear states that the arch teams need to intervine because they deal 
with the entire tree and how packages relate to each other, rather than the 
maintainer who deals with their own package.  He also states the point of 
this whole discussion was to seperate arch teams from package maintainers.

Diego Pettenò states that maintainers still need a way to suggest things be 
marked stable.

Stuart Herbert states that the maint keyword is still needed for maintainers 
to suggest something be marked for stable.  He also agrees with something 
similiar to what jstubbs requested regarding seperate packages and arch 
trees.

Jason Wever states that he likes to keep the tree the way it is, but mentions 
that arch maintainers stating that something (such as a scripting language) 
may seem cross platform, but certain core elements of the language may have 
broken architecture dependant code that causes it to crash.  This is the 
instance where arch maintainers would "know better".

Ciaran McCreesh states that some package maintainers violate QA policies and 
need to be overriden by arch teams.  He also brings up that candidates for 
stable are already marked ~arch and that something that shouldn't be 
considered for stable should be in package.mask.

Stuart Herbert states that package.mask is generally diffult to get supported 
(ie. users won't readily file bug reports).

Daniel Goller asks if this means we're dumping untested work onto our users.

Stuart Herbert replies that this is not the case, and that users are the only 
resource we really have for testing (ie. we lack test guidelines and tools).  
He mentions PHP5 package.mask and seperate overlays, and that the seperate 
overlays got more feedback than did package.mask-ing (as with things such as 
Gentopia).

R Hill confirms this and states that package.mask seems to bring an unwanted 
"we won't support this unless you provide patches" sort of approach, while 
overlays are specifically made for the purpose and welcome any sort of 
reporting.

Kevin F. Quinn states a list of things that the x86 arch team should compose 
of (listed here [2] to keep this email shorter).

Ciaran McCreesh states that the ebuild quiz (point in [2]) is not difficult 
and should still be kept that way. 

Kevin F. Quinn states that the ebuild quiz is mainly oriented towards 
developers as the audience, and is not recommended for users that are simply 
told to "test a package and note the USE flag configuration, seeing what 
happens".

Nathan L. Adams states that users need to work with both an ebuild quiz and a 
qa testing quiz

Homer Parker states that an arch testing quiz is a good idea and mentions the 
amd64 one centralized for QA and troubleshooting.  He also notes that while 
some arch testers become devs, some are simply content with arch testing.

Tom Martin mentions that the maintainer arch is valid, and that the current 
policy is that no arch team should go past a maintainer in stable marking.  
He also states that some packages are taken up by non-x86 maintainers and 
don't have x86 keywording because of that.  He also mentions that the x86 
team should be small considering the number of packages that will be changed 
as a result.

Nathan L. Adams states a policy should be created whereas maintainers have a 
maint keyword, arch teams don't go past that, and they can optionally deal 
with their own maintainer arch.

Ciaran McCreesh and Stuart Herbert agree that the x86 team needs to be 
coordinated and a full arch team.

Daniel Goller mentions that if arch teams could not override some overly picky 
package maitnainers, their powers would be very limited.

Stuart Herbert also states that arch maintainers can be somewhat overly picky 
as well and that the problem comes from both sides.  He then goes to state 
that arch teams that override package maintainers should take on the burden 
of support.

Ciaran McCreesh states that ~arch keywording is just for that purpose, and 
that a maintainer shouldn't put something in ~arch if it's not stable 
capable.

Some more discussion follows asking that ~arch be used as the stable ready 
marker.  It also is stated that ~arch is not about testing for a package 
readiness, but more ebuild readiness.

[1] http://article.gmane.org/gmane.linux.gentoo.devel/31060
[2] http://article.gmane.org/gmane.linux.gentoo.devel/31100

Chris White

-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-06 10:03 [gentoo-dev] [Summary] tentative x86 arch team glep Chris White
@ 2005-09-06 12:35 ` Mike Doty
  2005-09-06 17:03 ` Ed W
  1 sibling, 0 replies; 9+ messages in thread
From: Mike Doty @ 2005-09-06 12:35 UTC (permalink / raw
  To: gentoo-dev

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

Chris White wrote:
[snip]
| *  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.

We have 30 devs listed in the herd, of which ~19 have been active in the
past month.  We have 12 ATs listed, of which ~8 have been active in the
past month.

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

iD8DBQFDHY0l0K3RJaeXx6cRApp/AKCfxaxN6jN+2XwN80vUJ5AUExhuJwCcCtZn
giwJxALPpEa/pooOuFBHW70=
=AESt
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-06 10:03 [gentoo-dev] [Summary] tentative x86 arch team glep Chris White
  2005-09-06 12:35 ` Mike Doty
@ 2005-09-06 17:03 ` Ed W
  2005-09-06 17:21   ` Ciaran McCreesh
  1 sibling, 1 reply; 9+ messages in thread
From: Ed W @ 2005-09-06 17:03 UTC (permalink / raw
  To: gentoo-dev

As an "outsider" reading that summary the message *I* read is that there 
is some strain over fitting the development model into "stable", "~", 
and "package.mask".  I think I see people basically saying that they 
have differing views over what qualifies for each level?

Perhaps part of the solution is to review the current list of "levels" 
of stability?  Debian for example use several levels with something 
like: stable, unstable, testing, development (or whatever they are 
called).  Perhaps something more like that would be useful for gentoo?

I do know as a user it can be quite frustrating trying to find the 
ebuild for a package and having to dig around bugs.gentoo, and some 
other website, then patch up a dodgy ebuild found on some website, etc, 
etc.  Perhaps it would be more useful to have "development quality" 
ebuilds straight from portage (labelled as dangerous and unstable of 
course) and then I could more easily file back patches to fix problems 
that I find, and development would be more centralised...?

Also, as someone who has submitted a few patches and some ebuilds and 
then seen nothing happen to them and my offers to act as maintainer have 
gone unresponded I also wonder if there is some way to make better use 
of casual contributors like me? (I'm not bitter, it's just that I feel I 
could contribute more, but don't know how to?)


Good luck.  I'm a big gentoo fan.  I hope this extends gentoos lead even 
further!

All the best

Ed W
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-06 17:03 ` Ed W
@ 2005-09-06 17:21   ` Ciaran McCreesh
  2005-09-06 20:07     ` Alec Joseph Warner
  2005-09-11 23:53     ` Ed W
  0 siblings, 2 replies; 9+ messages in thread
From: Ciaran McCreesh @ 2005-09-06 17:21 UTC (permalink / raw
  To: gentoo-dev

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

On Tue, 06 Sep 2005 18:03:37 +0100 Ed W <lists@wildgooses.com> wrote:
| As an "outsider" reading that summary the message *I* read is that
| there is some strain over fitting the development model into
| "stable", "~", and "package.mask".  I think I see people basically
| saying that they have differing views over what qualifies for each
| level?

The system basically works. The problems are:

* It's not always used correctly.
* It's not entirely understood by some users.
* Some users think it should be easier to unmask a group of related
packages.

The third one's invalid, they just need to learn how to use sed...

| Also, as someone who has submitted a few patches and some ebuilds and 
| then seen nothing happen to them and my offers to act as maintainer
| have gone unresponded I also wonder if there is some way to make
| better use of casual contributors like me? (I'm not bitter, it's just
| that I feel I could contribute more, but don't know how to?)

The problem is... Getting someone ready to be able to commit to the
main tree is expensive in terms of existing developer time. The
solution isn't lowering the standards for commit access, because that
just leads to even more wasted developer time. There's the two tier
system that gets proposed every now and again, but that would a)
require svn rather than cvs and b) require that certain people who
currently have main tree access be moved to branch access only.

A bigger tree is all well and good, but the tree we have right now is
only half maintained...

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-06 17:21   ` Ciaran McCreesh
@ 2005-09-06 20:07     ` Alec Joseph Warner
  2005-09-11 23:53     ` Ed W
  1 sibling, 0 replies; 9+ messages in thread
From: Alec Joseph Warner @ 2005-09-06 20:07 UTC (permalink / raw
  To: gentoo-dev



Ciaran McCreesh wrote:
> On Tue, 06 Sep 2005 18:03:37 +0100 Ed W <lists@wildgooses.com> wrote:
> | As an "outsider" reading that summary the message *I* read is that
> | there is some strain over fitting the development model into
> | "stable", "~", and "package.mask".  I think I see people basically
> | saying that they have differing views over what qualifies for each
> | level?
> 
> The system basically works. The problems are:
> 
> * It's not always used correctly.
> * It's not entirely understood by some users.
> * Some users think it should be easier to unmask a group of related
> packages.
> 
> The third one's invalid, they just need to learn how to use sed...
> 
This is a lack of tools, not everyone needs to learn sed.  Just 1 person 
needs to write the tool to do the job ;)

No, I'm not volunteering.

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



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-06 17:21   ` Ciaran McCreesh
  2005-09-06 20:07     ` Alec Joseph Warner
@ 2005-09-11 23:53     ` Ed W
  2005-09-12  0:03       ` Ciaran McCreesh
  1 sibling, 1 reply; 9+ messages in thread
From: Ed W @ 2005-09-11 23:53 UTC (permalink / raw
  To: gentoo-dev

Ciaran McCreesh wrote:

>On Tue, 06 Sep 2005 18:03:37 +0100 Ed W <lists@wildgooses.com> wrote:
>| As an "outsider" reading that summary the message *I* read is that
>| there is some strain over fitting the development model into
>| "stable", "~", and "package.mask".  I think I see people basically
>| saying that they have differing views over what qualifies for each
>| level?
>
>The system basically works. The problems are:
>
>* It's not always used correctly.
>* It's not entirely understood by some users.
>* Some users think it should be easier to unmask a group of related
>packages.
>  
>

Might there be an option 4 which is that a slightly different system 
might stop everyone bitching over the current one and hence avoid 
wasting some time?  Nope, no idea what that would be, but the thought 
does occur when you see some time being wasted on trivial issues...


>| Also, as someone who has submitted a few patches and some ebuilds and 
>| then seen nothing happen to them and my offers to act as maintainer
>| have gone unresponded I also wonder if there is some way to make
>| better use of casual contributors like me? (I'm not bitter, it's just
>| that I feel I could contribute more, but don't know how to?)
>
>The problem is... Getting someone ready to be able to commit to the
>main tree is expensive in terms of existing developer time. The
>solution isn't lowering the standards for commit access, because that
>just leads to even more wasted developer time. There's the two tier
>system that gets proposed every now and again, but that would a)
>require svn rather than cvs and b) require that certain people who
>currently have main tree access be moved to branch access only.
>
>A bigger tree is all well and good, but the tree we have right now is
>only half maintained...
>  
>

Is there any possibility that easier low quality contribution makes the 
high quality contributions easier?

Look at wikipedia - it's amazing that such high quality work (in 
general) can come from lightly peer review material with low barriers to 
entry.

Clearly not an appropriate model here, but I can't help wondering if 
there is not another way...

I did read the FAQ here and I take your point though:
http://dev.gentoo.org/~ciaranm/docs/mw-faq/maintainer.txt

Thanks for listening

Ed W
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-11 23:53     ` Ed W
@ 2005-09-12  0:03       ` Ciaran McCreesh
  2005-09-12 17:04         ` Ed W
  0 siblings, 1 reply; 9+ messages in thread
From: Ciaran McCreesh @ 2005-09-12  0:03 UTC (permalink / raw
  To: gentoo-dev

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

On Mon, 12 Sep 2005 00:53:03 +0100 Ed W <lists@wildgooses.com> wrote:
| Might there be an option 4 which is that a slightly different system 
| might stop everyone bitching over the current one and hence avoid 
| wasting some time?  Nope, no idea what that would be, but the thought 
| does occur when you see some time being wasted on trivial issues...

Hrm. Any change would involve adding more complexity. It would probably
also involve lots of fixup work on existing code. It's likely not worth
the cost.

| Is there any possibility that easier low quality contribution makes
| the high quality contributions easier?

Only to the extent that they get me to write better documentation :)

| Look at wikipedia - it's amazing that such high quality work (in 
| general) can come from lightly peer review material with low barriers
| to entry.
|
| Clearly not an appropriate model here, but I can't help wondering if 
| there is not another way...

Well... Sometimes maintainer-wanted ebuilds are worked upon by multiple
people. It happens, but not very often.

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

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-12  0:03       ` Ciaran McCreesh
@ 2005-09-12 17:04         ` Ed W
  2005-09-12 17:19           ` Michael Kohl
  0 siblings, 1 reply; 9+ messages in thread
From: Ed W @ 2005-09-12 17:04 UTC (permalink / raw
  To: gentoo-dev


>| Is there any possibility that easier low quality contribution makes
>| the high quality contributions easier?
>
>Only to the extent that they get me to write better documentation :)
>
>| Look at wikipedia - it's amazing that such high quality work (in 
>| general) can come from lightly peer review material with low barriers
>| to entry.
>|
>| Clearly not an appropriate model here, but I can't help wondering if 
>| there is not another way...
>
>Well... Sometimes maintainer-wanted ebuilds are worked upon by multiple
>people. It happens, but not very often.
>  
>

I was pondering this last night.

Whilst there is clearly no substitute for a high quality standard for 
"x86", etc, it seems to me that we are missing a trick with all the 
"maintainer wanted" ebuilds which tend to be scattered around the web. 

It seems to me that perhaps it would be useful to have a centralised 
development area where stuff can "gestate" before making it into the 
testing pool that we have today.  It could be argued that this exists 
and is called bugzilla, but I wonder if we can do better?

What about adding another layer (or two) to the flags so that 
development ebuilds can be developed centrally to gentoo and hence 
available in portage, but lowering the barrier to entry.  At the 
simplest this could be used to allow a non core developer to bump an 
ebuild to a new version in response to some release.  It goes into the 
"highly unstable" section which shouldn't be seen by any normal person, 
yet at the same time makes it available to the kiddies who like to test 
the latest and greatest.

Now, the follow on to this idea is as follows: It seems to me to be a 
little arbitrary when something goes stable and I find myself with a 
number of "~" flags set on an otherwise fairly stable system (I dare say 
you have a different opinion, but remember I am looking from the outside 
in).

Now, at one point in the past there was a gentoo package which phoned 
home and reported which version of every package you were using.  Could 
these statistics not be used to help direct development time to the most 
useful areas?  I'm thinking along the lines of noticing that 90% of the 
userbase is running a version of xmltv which is 5 versions newer than 
the stable one, hence it's probably fairly stable, and in need up being 
marked as stable...

These statistics could also be used as a first line quality check for 
any ebuilds in the proposed "development" ebuild area.  So for example, 
if there is a hard-core of users using my "pmwiki" ebuild (which is 
currently marked as "maintainer wanted"), then this is a clue that it 
must be fairly stable and popular and worth including (since it will 
probably require minimal effort).

It seems like this would go some way towards easing the "easy 
development" bits and giving everyone more time to work on the important 
stuff, whilst also making use of the distributed testing effort of some 
of the more adventurous users...

Workable?

Ed W
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [gentoo-dev] [Summary] tentative x86 arch team glep
  2005-09-12 17:04         ` Ed W
@ 2005-09-12 17:19           ` Michael Kohl
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Kohl @ 2005-09-12 17:19 UTC (permalink / raw
  To: gentoo-dev

On Mon, 12 Sep 2005 18:04:52 +0100
Ed W <lists@wildgooses.com> wrote:

> At the  simplest this could be used to allow a non core developer to
> bump an ebuild to a new version in response to some release.  It goes
> into the "highly unstable" section which shouldn't be seen by any
> normal person, yet at the same time makes it available to the kiddies
> who like to test the latest and greatest.

Isn't this what Break My Gentoo already provides?

http://www.breakmygentoo.net/

Personally I don't want to have to mess around with bugs for the
"highly unstable" section you mentioned, and I have a feeling that a
quite a lot of people share this sentiment. 

-- 
web@citizen428.net                                 citizen428@gentoo.org
http://citizen428.net/                http://dev.gentoo.org/~citizen428/
GnuPG key: 0x90CA09E3/4D21 916E DBCE 72B8 CDC5  BD87 DE2D 91A2 90CA 09E3
-- 
gentoo-dev@gentoo.org mailing list



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2005-09-12 17:24 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-06 10:03 [gentoo-dev] [Summary] tentative x86 arch team glep Chris White
2005-09-06 12:35 ` Mike Doty
2005-09-06 17:03 ` Ed W
2005-09-06 17:21   ` Ciaran McCreesh
2005-09-06 20:07     ` Alec Joseph Warner
2005-09-11 23:53     ` Ed W
2005-09-12  0:03       ` Ciaran McCreesh
2005-09-12 17:04         ` Ed W
2005-09-12 17:19           ` Michael Kohl

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox