* [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