[gentoo-dev] ekeyword and ordering

[gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Hi guys,

As some of you have noticed, I made a change recently in ekeyword that
causes ekeyword to alphabetize the keywords.  I've realized I should
have brought it up for discussion before making the change to the
program.  On that note, I apologize for unilaterally making that
change without consulting the developer body for opinions.

Here is the the fuzzy history of keywording in a nutshell.  Please
bear in mind that these bullet points happened over a period of years.

    - Daniel originally wanted them alphabetized.

    - A few people, myself included, pointed out that there's some
      valuable information available when keywords are always added to
      the end rather than being alphabetized.  In particular, the
      concept of a "maintainer arch" is possible, in which the first
      arch in the list is supposed to indicate general stability of
      the ebuild, a leader for other arches to follow.

    - Some people disagreed with the "maintainer arch" concept.  They
      felt that the arch teams do a better job of testing than some
      maintainers, and there's no point waiting for a maintainer to
      decide something is stable.

    - Some developers recently mentioned to me that alphabetizing
      would probably be fine.  At this point I felt that the tree was
      diluted enough that there was no point resisting, so I went
      ahead and made the change silently.

    - My action was questioned privately on IRC, and I realized
      I made the decision without proper discussion.  So I'm writing
      this email.

Honestly, the arguments aren't very strong in either direction.
I think everybody understands this, but nonetheless people have their
preferences.  Here are some of the basic arguments:

    alpha
    -----------------------------
    - looks nicer (subjective)
    - easier to tell at a glance if a given keyword is in the list

    append
    -----------------------------
    - slightly less cvs/rsync traffic
    - allows "maintainer arch" to continue until another solution is
      produced, for those who still depend on that method
    - some developers are accustomed to the "append" method and don't want
      things to change, at least not without discussion

I am willing to revert the ekeyword change if that is what devs would
prefer, but I won't make the change without a discussion on -dev,
which was my mistake last time.  Your thoughts?

If the thread isn't obviously unified one direction or the other,
I guess we'll eventually put this up to a developer or manager vote
(I'm not sure which is appropriate)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Mike Frysinger]

On Monday 06 June 2005 06:26 pm, Aron Griffis wrote:
>     alpha

i'm all for alpha (as many know seeing as how they've cursed me profusely when 
i first started doing it) ... seeing as how i tend to mark for 4 or 5 arches, 
alpha is a huge help since i know about where to look in the list

also, the concept of 'maintainer arch' is a bit dated considering we have 
metadata now to indicate 'real' maintainers whom you should be able to 
contact if you have a question as to what is the best version for marking 
stable on your arch
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Stephen P. Becker]

Mike Frysinger wrote:
> On Monday 06 June 2005 06:26 pm, Aron Griffis wrote:
> 
>>    alpha
> 
> 
> i'm all for alpha (as many know seeing as how they've cursed me profusely when 
> i first started doing it) ... seeing as how i tend to mark for 4 or 5 arches, 
> alpha is a huge help since i know about where to look in the list
> 
> also, the concept of 'maintainer arch' is a bit dated considering we have 
> metadata now to indicate 'real' maintainers whom you should be able to 
> contact if you have a question as to what is the best version for marking 
> stable on your arch
> -mike

alpha++
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Luca Barbato]

Stephen P. Becker wrote:
> alpha++

alpha++

-- 

Luca Barbato

Gentoo/linux Developer		Gentoo/PPC Operational Leader
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Danny van Dyk]

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

Luca Barbato schrieb:
> Stephen P. Becker wrote:
> 
>>alpha++
> 
> 
> alpha++
> 
once again, alpha++

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

iD8DBQFCpgpyaVNL8NrtU6IRAgCjAJ0ds9iJ7giXVE1OzLaKT48tK0HfTwCgon+/
MM+jJGYxmgZw/cLCQoiOI0o=
=d0W/
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Tue, 2005-06-07 at 22:58 +0200, Danny van Dyk wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Luca Barbato schrieb:
> > Stephen P. Becker wrote:
> > 
> >>alpha++
> > 
> > 
> > alpha++
> > 
> once again, alpha++

It's not a vote, it's a discussion. You guys--.

As vapier indicates he's the whole reason this ever became a problem. He
was the one who started arbitrarily ordering keywords around creating a
keywords mess for people who did depend on order to perform tasks. I
guess the lesson here is if you just do things 'your way' (wr/l)ong
enough, people pick it up and it spreads.

The point is that with his reordering implicit information was lost for
no particular purpose. There was no added value in ordering keywords,
there's was no reason whatsoever to make the ordering inconsistent
within packages, it was an utterly pointless exercise in creating more
traffic on the servers.

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Lars Weiler]

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

* foser <foser@gentoo.org> [05/06/09 15:19 +0200]:
> The point is that with his reordering implicit information was lost for
> no particular purpose.

If you store implicit information in the keywords, then make
them explicit.  That involves, find another way to store the
data (like in metadata), or discuss here about another way
to store that data in the keywords.

Could you give an example about the implicit data you store
in the keywords?  So we can think about a solution.

Regards, Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Gentoo Linux PowerPC    : Developer and Release Engineer
Gentoo Infrastructure   : CVS Administrator
Gentoo Foundation       : Trustee

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

[gentoo-dev] Re: ekeyword and ordering

[Duncan]

Lars Weiler posted
<20050609133722.GN10291@celeborn.wh-og.hs-niederrhein.de>, excerpted
below,  on Thu, 09 Jun 2005 15:37:22 +0200:

> * foser <foser@gentoo.org> [05/06/09 15:19 +0200]:
>> The point is that with his reordering implicit information was lost for
>> no particular purpose.
> 
> If you store implicit information in the keywords, then make them
> explicit.  That involves, find another way to store the data (like in
> metadata), or discuss here about another way to store that data in the
> keywords.
> 
> Could you give an example about the implicit data you store in the
> keywords?  So we can think about a solution.

Um... I expect foser considered that understood from the thread context.
The "implicit data" under discussion is maintainer's arch and to a lessor
degree order of arch adoption of the package.  Maintainer arch was
/traditionally/ listed first, with archs added left to right, so the
newest arch added was always to the right.

However, as the many arguments and examples in this thread demonstrate,
that was never a reliable method for conveying the information in the
first place, thus we have the proposal to make it alphabetical ordering,
and to put maintainer's arch info in the metadata.xml file.  So far, the
change seems to be favored.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Danny van Dyk]

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

Hi foser,

>>>alpha++
>>once again, alpha++
> It's not a vote, it's a discussion. You guys--.
^^^Yeah, this proofs your ability to discuss very well...

> As vapier indicates he's the whole reason this ever became a problem. He
> was the one who started arbitrarily ordering keywords around creating a
> keywords mess for people who did depend on order to perform tasks. I
> guess the lesson here is if you just do things 'your way' (wr/l)ong
> enough, people pick it up and it spreads.
Chris pointed out that there are developer who switched their arch at
least once,
and other who don't have access to the same arch all the time (x86 on
work, $arch at home). So the point is: even without alpha ordering, you
_cannot rely_ on the precious 'implicit information' you want to store
in keyword ordering. And to quote on of my teachers: unreliable
information is worse than no information at all.

> The point is that with his reordering implicit information was lost for
> no particular purpose. There was no added value in ordering keywords,
No, you're wrong here: you couldn't rely on it from the beginning, so
nothing was lost...

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

iD8DBQFCqGBxaVNL8NrtU6IRAq9HAJ9cTSPI1q4ld8xWSIJjQkkhWWmjWgCfcw3S
YtOcIeTW9ERUwa7k++ct8UA=
=quF1
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Stephen P. Becker]

foser wrote:
> On Tue, 2005-06-07 at 22:58 +0200, Danny van Dyk wrote:
> 
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Luca Barbato schrieb:
>>
>>>Stephen P. Becker wrote:
>>>
>>>
>>>>alpha++
>>>
>>>
>>>alpha++
>>>
>>
>>once again, alpha++
> 
> 
> It's not a vote, it's a discussion. You guys--.

Whoever said we were voting?  I was just showing my support for
alphabetical keyword ordering.  Remember, alphabetical keywording is
*already* implemented in ekeyword, and we are discussing whether or not
to revert it.  foser--

> 
> As vapier indicates he's the whole reason this ever became a problem. He
> was the one who started arbitrarily ordering keywords around creating a
> keywords mess for people who did depend on order to perform tasks. I
> guess the lesson here is if you just do things 'your way' (wr/l)ong
> enough, people pick it up and it spreads.

If everyone starts using ekeyword now with the alphabetical ordering
built in, everything will be consistent, and there shouldn't be a problem.

> 
> The point is that with his reordering implicit information was lost for
> no particular purpose. There was no added value in ordering keywords,
> there's was no reason whatsoever to make the ordering inconsistent
> within packages, it was an utterly pointless exercise in creating more
> traffic on the servers.

I guess by "creating more traffic" you mean the one time when updating
the ebuilds with the new ordering during rsync for each user.  Even if
this is significant over the whole tree, once everything is updated with
keyword ordering and everyone has done an emerge sync, there won't be
any more trouble, and we can just stay happy with the consistent
alphabetical ordering enforced by ekeyword.

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

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Thu, 2005-06-09 at 11:50 -0400, Stephen P. Becker wrote:
> Whoever said we were voting?  I was just showing my support for
> alphabetical keyword ordering.  Remember, alphabetical keywording is
> *already* implemented in ekeyword, and we are discussing whether or not
> to revert it. 

As the threadstarter indicated, this was done without discussing it and
in the knowledge that there was no agreement on this issue. As said
before, the fact that something gets done some way, doesn't mean it's
right to do it that way.

>  foser--

In the response to that particular expression -especially by the 'guys'
implied- you can see at least you try to defend your position now,
that's more discussion like.

> If everyone starts using ekeyword now with the alphabetical ordering
> built in, everything will be consistent, and there shouldn't be a problem.

See earlier replies : unneeded arbitrarily introduced inconsistency. I
don't know why people are defending that move, even vapier indicates
that there really is no reason to do it alphabetically, except maybe
that he now knows to look in the keywords string, which is of course a
bit far fetched with all arch keywords not being set for all different
packs (so he still has to look at different points in different packs)
and was not brought up as a defence of his particular move at the time
he started doing this.

> I guess by "creating more traffic" you mean the one time when updating
> the ebuilds with the new ordering during rsync for each user.  Even if
> this is significant over the whole tree, once everything is updated with
> keyword ordering and everyone has done an emerge sync, there won't be
> any more trouble, and we can just stay happy with the consistent
> alphabetical ordering enforced by ekeyword.

Oh no doubt, I'm concerned about the inconsistency mostly. The
maintainers arch is a concept that I do not necessarily associate with
the keywords ordering anymore (although it may have been a reasonable
indicator in the past), it actually really makes this discussion fuzzier
than it has to be. My point is more about how this got 'introduced' as a
mindset and that such unguided behaviour gets reinforced by this
discussion, now up to IUSE ordering changes and next we'll tackle
inheritance order.

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Mike Frysinger]

On Friday 10 June 2005 10:55 am, foser wrote:
> > If everyone starts using ekeyword now with the alphabetical ordering
> > built in, everything will be consistent, and there shouldn't be a
> > problem.
>
> even vapier indicates
> that there really is no reason to do it alphabetically, except maybe 
> that he now knows to look in the keywords string, which is of course a
> bit far fetched with all arch keywords not being set for all different
> packs (so he still has to look at different points in different packs)
> and was not brought up as a defence of his particular move at the time
> he started doing this.

not quite sure where you're pulling this out of but you're always full of 
suprises like this

consistency is one advantage (which i'm sure you'll say is pointless)

as for the rest of the ramble you posted here it's really quite wrong ... you 
must have missed the class where they teach you the ins & outs of 
alphabetical sorting because it really does allow you to quickly scan a list 
and figure out if the item you're looking for is there or not

if you ever had to do arch-specific KEYWORDing on a frequent basis (and i'm 
99% sure you have nfc we support other arches than x86 if we use 
arch-specific breakage in GNOME depends as any sort of track record), you'd 
know that scattered KEYWORDS is a pita to deal with ... i've seen cases where 
a specific arch was duplicated in KEYWORDS; once near the beginning and once 
near the end ... normally it wasnt anything bad, but there was a case where 
one KEYWORD was stable while the other was unstable
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Fri, 2005-06-10 at 12:33 -0400, Mike Frysinger wrote:
> consistency is one advantage (which i'm sure you'll say is pointless)

I've been the one talking consistency, something you've knowingly broken
for a long time here.

> as for the rest of the ramble you posted here it's really quite wrong ... you 
> must have missed the class where they teach you the ins & outs of 
> alphabetical sorting because it really does allow you to quickly scan a list 
> and figure out if the item you're looking for is there or not

First of all this is speculative and may not apply to this particular
situation to begin with. Arch keywords are concepts and as such may not
primarily be dealt as a an alphabetical list but as words in a sentence,
there is no abc order in sentences. If you have to search, you'll have
to scan anyway, exact position is not a guarantee for certainty because
not every pack is available on every arch, it's not like you can go
without scanning. Last, this only holds to some extent true for people
in countries with alphabetic scripts, outside that limited part of the
globe people are not as proficient in ordering alphabetically.
	I think you are just going out of your way to justify something you've
done for ages for no other reason than your own preference. But I must
grant you, you come with better arguments now than you've ever done in
the past concerning this issue. Of course you had a lot of time to think
about it.

> if you ever had to do arch-specific KEYWORDing on a frequent basis (and i'm 
> 99% sure you have nfc we support other arches than x86 if we use 
> arch-specific breakage in GNOME depends as any sort of track record),

If there was ever arch specific breakage -this btw is a baseless claim,
so it shouldn't have been put up here, but I guess that's what populism
is about-, then it is most likely because someone screwed up the
ordering inside one package dir, making it inconsistent and as such a
pain to deal with.
	Now for my list of 3 letter IRC abbreviations to make a point : wtf,
wth, imo, lol, nfw, fyi, otw. Keep it clean.

>  you'd 
> know that scattered KEYWORDS is a pita to deal with ... i've seen cases where 
> a specific arch was duplicated in KEYWORDS; once near the beginning and once 
> near the end ... normally it wasnt anything bad, but there was a case where 
> one KEYWORD was stable while the other was unstable

Again something I'd only expect to happen in cases where someone is
reordering keywords at will inside a package.

A certain amount of uncertainty in order actually might prove to be
effective in having everyone who deals with keywords actually really
check all keywords and not depend on assumptions, which both 'error'
cases you mention seem to be caused by.

Anyway, my feud is with the inconsistency within packages and how it got
introduced, not with whatever order is preferred by some. Now tell me
how this happened again?

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Jason Stubbs]

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

On Saturday 11 June 2005 17:15, foser wrote:
> Anyway, my feud is with the inconsistency within packages and how it got
> introduced, not with whatever order is preferred by some. Now tell me
> how this happened again?

By lack of policy?

Regards,
Jason Stubbs

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

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Sat, 2005-06-11 at 17:28 +0900, Jason Stubbs wrote:
> By lack of policy?

Well I'm sort of concerned by the fact that I have to state the obvious,
but really by people reordering them for no reason.

It's not the lack of policy that is the problem here, it's the use of
some self defined not uniform policy. There was no need for policy or
regulation until some people set their own rules to play by, I really
don't understand why that move gets defended by anyone.

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Joshua Baergen]

On 6/11/05, foser <foser@gentoo.org> wrote:
> On Sat, 2005-06-11 at 17:28 +0900, Jason Stubbs wrote:
> > By lack of policy?
> 
> Well I'm sort of concerned by the fact that I have to state the obvious,
> but really by people reordering them for no reason.
> 
> It's not the lack of policy that is the problem here, it's the use of
> some self defined not uniform policy. There was no need for policy or
> regulation until some people set their own rules to play by, I really
> don't understand why that move gets defended by anyone.
> 
> - foser
> 
> 
> BodyID:123219267.2.n.logpart (stored separately)
> 
> 
But if the policy doesn't exist there is no reason for new developers
to play by the current rules.  The mentor certainly doesn't have to
mention it because it's not policy, it's not stated anywhere on the
devrel guide (unless I missed that section - it's certainly not within
the variable description section of the ebuild guide).

My point is that unless it's made policy there is no reason to expect
that everyone's going to follow what even a group of people consider
logical order.  Personally, if I'm looking through keywords, I don't
care what order they're in.  It's not like there are 100 keywords or
something, it should take a person paying attention long to look
through them and pick out any errors.  Therefore, I would not really
care what order I put the keywords in unless someone told me, "This is
the order to put them in."

I don't think people "set their own rules to play by" in spite of the
rules, but rather because they didn't know there were any.

-- 
Joshua Baergen

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Diego 'Flameeyes' Pettenò]

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

On Saturday 11 June 2005 17:21, Joshua Baergen wrote:
> I don't
> care what order they're in.  It's not like there are 100 keywords or
> something,
Wait until ppc-od, x86-fbsd and amd64-fbsd keywords make their way into the 
tree... the problem there is worst, and the alphabetical order is really 
simpler to manage.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


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

Re: [gentoo-dev] ekeyword and ordering

[Joshua Baergen]

On 6/11/05, Diego 'Flameeyes' Pettenò <flameeyes@gentoo.org> wrote:
> On Saturday 11 June 2005 17:21, Joshua Baergen wrote:
> > I don't
> > care what order they're in. It's not like there are 100 keywords or
> > something,
> Wait until ppc-od, x86-fbsd and amd64-fbsd keywords make their way into the
> tree... the problem there is worst, and the alphabetical order is really
> simpler to manage.
> 
> --
> Diego "Flameeyes" Pettenò
> Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)
> 
> http://dev.gentoo.org/~flameeyes/
> 
> 
> 
> 
Point taken :P  I knew that was coming, but I didn't think about it
when I wrote that.

Personally, I would support any policy as to avoid different people
putting different meanings into the orders, especially if there are
groups of people who believe that everyone should do it their way
(maybe everyone should).  I also think things like information
pertaining to developer platforms shouldn't be put into variable
ordering.  When I write software I don't expect people to understand
intricacies of my design decisions and requirements from the order I
call functions or the order I give to my parameter assignments,
despite some rule of thumb I or others believe is the right way.  Not
everyone thinks like me, and that's what comments and external
documentation are for.

-- 
Joshua Baergen

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Bryan Oestergaard]

On Sat, Jun 11, 2005 at 10:15:22AM +0200, foser wrote:
> On Fri, 2005-06-10 at 12:33 -0400, Mike Frysinger wrote:
> >  you'd 
> > know that scattered KEYWORDS is a pita to deal with ... i've seen cases where 
> > a specific arch was duplicated in KEYWORDS; once near the beginning and once 
> > near the end ... normally it wasnt anything bad, but there was a case where 
> > one KEYWORD was stable while the other was unstable
> 
> Again something I'd only expect to happen in cases where someone is
> reordering keywords at will inside a package.
> 
> A certain amount of uncertainty in order actually might prove to be
> effective in having everyone who deals with keywords actually really
> check all keywords and not depend on assumptions, which both 'error'
> cases you mention seem to be caused by.
> 
Sorry foser but there's just no way that making it *harder* to find
keywords in ebuilds is going to cause less mistakes. Alphabetical
keyword ordering is a big help for arch maintainers and as such has my
full support.

And in those cases where I'm in doubt whether the package maintainer
thinks some version is stable I'd rather ask the maintainer than rely on
some arbitrary keyword ordering which doesn't mean much anyway as
maintainers change archs all the time.

Regards,
Bryan Østergaard

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

foser wrote:	[Sat Jun 11 2005, 04:15:22AM EDT]
> Arch keywords are concepts and as such may not primarily be dealt as
> a an alphabetical list but as words in a sentence, there is no abc
> order in sentences.

Foser, no offense intended, but you started out in this thread making
a couple good points.  However this is completely off the wall.  The
KEYWORDS list isn't a sentence.

> If you have to search, you'll have
> to scan anyway, exact position is not a guarantee for certainty because
> not every pack is available on every arch, it's not like you can go
> without scanning.

Doesn't change the point that scanning in alpha order is easier than
scanning append order.

> Last, this only holds to some extent true for people
> in countries with alphabetic scripts, outside that limited part of the
> globe people are not as proficient in ordering alphabetically.

AFAIK, all Gentoo developers are fluent English speakers, even if for
some it isn't their first language.

> A certain amount of uncertainty in order actually might prove to be
> effective in having everyone who deals with keywords actually really
> check all keywords and not depend on assumptions, which both 'error'
> cases you mention seem to be caused by.

Maintaining a behavior that encourages mistakes, in hopes that the
extra effort required will prevent those mistakes?  This cannot
possibly be a good approach...

IMHO the discussion in this thread has brought at least two things to
light, though I'm still open to rebuttal of course:

    1. Potentially controversial tool changes that affect a large
       number of developers should be discussed on -dev before
       deployment.  This is something I intend to do in the future.

    2. In the case at hand, most developers prefer alpha order, and
       there is not good reason for reverting the ekeyword change.
       I still don't have the right to make this decision
       unilaterally, though, so if foser or anybody else wants to take
       this before the managers and request a vote, that is cool.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Sat, 2005-06-11 at 14:46 -0400, Aron Griffis wrote:
> foser wrote:	[Sat Jun 11 2005, 04:15:22AM EDT]
> > Arch keywords are concepts and as such may not primarily be dealt as
> > a an alphabetical list but as words in a sentence, there is no abc
> > order in sentences.
> 
> Foser, no offense intended, but you started out in this thread making
> a couple good points.  However this is completely off the wall.  The
> KEYWORDS list isn't a sentence.

The post I replied to was full of far-fetched reasoning, I just made a
similar post.

> > If you have to search, you'll have
> > to scan anyway, exact position is not a guarantee for certainty because
> > not every pack is available on every arch, it's not like you can go
> > without scanning.
> 
> Doesn't change the point that scanning in alpha order is easier than
> scanning append order.
> 
> > Last, this only holds to some extent true for people
> > in countries with alphabetic scripts, outside that limited part of the
> > globe people are not as proficient in ordering alphabetically.
> 
> AFAIK, all Gentoo developers are fluent English speakers, even if for
> some it isn't their first language.

Fluent, right. Try some of the cjk people. Not really. Anyway, it
doesn't matter, if you didn't grown up with the alphabet, you really
don't know the ordering by heart like western people do. In spoken
language it doesn't matter what the order is, it is totally arbitrary.
Also, realistically it's probably only 1st language for maybe half of
the devs these days.

> > A certain amount of uncertainty in order actually might prove to be
> > effective in having everyone who deals with keywords actually really
> > check all keywords and not depend on assumptions, which both 'error'
> > cases you mention seem to be caused by.
> 
> Maintaining a behavior that encourages mistakes, in hopes that the
> extra effort required will prevent those mistakes?  This cannot
> possibly be a good approach...

You assume here suddenly that it encourages mistakes, there is no such
evidence presented here or ever was, there is however evidence to the
contrary where the continues shifting of orders (within packages) caused
problems (the thing I disliked about this whole situation to begin
with). I actually suggest that the opposite might be true, a certain
degree of uncertainty (between packages) prompts caution and might prove
to be more error-free. Sure it's all a bit far fetched, but so was the
post that suggested that there was some grand ergonomic idea behind this
arbitrary change.

I did not in this thread challenge the ordering (who made that up?), I
challenged the way it got 'introduced'. I just got ticked off by the
'scientific basis' that suddenly was presented as the big reason behind
it.

To recap, it was the arbitrary /ordering change/ of a select group of
individuals that created problems within packages, not the one or the
other /order/.

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Catching up on your inbox, foser? ;-)

foser wrote:	[Mon Aug 01 2005, 01:06:10PM EDT]
> On Sat, 2005-06-11 at 14:46 -0400, Aron Griffis wrote:
> > foser wrote:	[Sat Jun 11 2005, 04:15:22AM EDT]
> > > Arch keywords are concepts and as such may not primarily be dealt as
> > > a an alphabetical list but as words in a sentence, there is no abc
> > > order in sentences.
> > 
> > Foser, no offense intended, but you started out in this thread making
> > a couple good points.  However this is completely off the wall.  The
> > KEYWORDS list isn't a sentence.
> 
> The post I replied to was full of far-fetched reasoning, I just made a
> similar post.

Actually, later I thought maybe I understood your sentence parallel.
Your point was that when the KEYWORDS list is scrambled from its
original order, it loses information, similar to when the words in
a sentence are scrambled.  Sorry, I should have been more open-minded
in my first reading.

> > > If you have to search, you'll have
> > > to scan anyway, exact position is not a guarantee for certainty because
> > > not every pack is available on every arch, it's not like you can go
> > > without scanning.
> > 
> > Doesn't change the point that scanning in alpha order is easier than
> > scanning append order.
> > 
> > > Last, this only holds to some extent true for people
> > > in countries with alphabetic scripts, outside that limited part of the
> > > globe people are not as proficient in ordering alphabetically.
> > 
> > AFAIK, all Gentoo developers are fluent English speakers, even if for
> > some it isn't their first language.
> 
> Fluent, right. Try some of the cjk people. Not really. Anyway, it
> doesn't matter, if you didn't grown up with the alphabet, you really
> don't know the ordering by heart like western people do. In spoken
> language it doesn't matter what the order is, it is totally
> arbitrary.  Also, realistically it's probably only 1st language for
> maybe half of the devs these days.

IMHO (and I do mean humble, because I could be wrong) the majority of
portage tree commits are coming from people who are fluent in
a Western tongue.  For many people the alpha ordering makes things
easier, and most of the others don't care.

> > > A certain amount of uncertainty in order actually might prove to be
> > > effective in having everyone who deals with keywords actually really
> > > check all keywords and not depend on assumptions, which both 'error'
> > > cases you mention seem to be caused by.
> > 
> > Maintaining a behavior that encourages mistakes, in hopes that the
> > extra effort required will prevent those mistakes?  This cannot
> > possibly be a good approach...
> 
> You assume here suddenly that it encourages mistakes, there is no
> such evidence presented here or ever was, there is however evidence
> to the contrary where the continues shifting of orders (within
> packages) caused problems (the thing I disliked about this whole
> situation to begin with). I actually suggest that the opposite might
> be true, a certain degree of uncertainty (between packages) prompts
> caution and might prove to be more error-free. Sure it's all a bit
> far fetched, but so was the post that suggested that there was some
> grand ergonomic idea behind this arbitrary change.

You're right, I don't have evidence to present.  My suspicion is that
uncertainty doesn't lead to caution in this case.  I didn't intend to
make any more assumptions than you were making.

> I did not in this thread challenge the ordering (who made that up?),
> I challenged the way it got 'introduced'. I just got ticked off by
> the 'scientific basis' that suddenly was presented as the big reason
> behind it.
> 
> To recap, it was the arbitrary /ordering change/ of a select group
> of individuals that created problems within packages, not the one or
> the other /order/.

Oh, I thought for sure that you were arguing that one order was better
than the other.  If you weren't, why have you talked so much about it?
It seems like if you don't care about the ultimate ordering, then it
would be better to ignore that part of this thread, wouldn't it?

Regarding the way the change was made, I apologized at the beginning
of this thread and stated that I would not make a future change like
that without going through a discussion first.  As the maintainer of
ekeyword, I made the change unilaterally without taking into account
how controversial it would be.  It seems like the thread could have
ended there, eh?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Mike Frysinger]

On Saturday 11 June 2005 04:15 am, foser wrote:
> > if you ever had to do arch-specific KEYWORDing on a frequent basis (and
> > i'm 99% sure you have nfc we support other arches than x86 if we use
> > arch-specific breakage in GNOME depends as any sort of track record),
>
> If there was ever arch specific breakage -this btw is a baseless claim,
> so it shouldn't have been put up here, but I guess that's what populism
> is about-, then it is most likely because someone screwed up the
> ordering inside one package dir, making it inconsistent and as such a
> pain to deal with.

baseless ?  talk to any hppa/sparc/ia64 (and maybe mips) dev and they should 
be able to remember a time where a GNOME version bump had missing KEYWORDS in 
new dependencies ... evolution-data-server comes to mind

> >  you'd
> > know that scattered KEYWORDS is a pita to deal with ... i've seen cases
> > where a specific arch was duplicated in KEYWORDS; once near the beginning
> > and once near the end ... normally it wasnt anything bad, but there was a
> > case where one KEYWORD was stable while the other was unstable
>
> Again something I'd only expect to happen in cases where someone is
> reordering keywords at will inside a package.

you can expect all you want, i found these cases BEFORE i started 
alphabetizing KEYWORDS
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

foser wrote:	[Fri Jun 10 2005, 10:55:17AM EDT]
> As the threadstarter indicated, this was done without discussing it
> and in the knowledge that there was no agreement on this issue. As
> said before, the fact that something gets done some way, doesn't
> mean it's right to do it that way.

Not to dilute your point, which is well taken, but I'm curious how
much discretion the tool author has to make decisions independently?

> See earlier replies : unneeded arbitrarily introduced inconsistency. I
> don't know why people are defending that move, even vapier indicates
> that there really is no reason to do it alphabetically, except maybe
> that he now knows to look in the keywords string, which is of course a
> bit far fetched with all arch keywords not being set for all different
> packs (so he still has to look at different points in different packs)
> and was not brought up as a defence of his particular move at the time
> he started doing this.

If all the keywords in the tree were alphabetical, would that have any
impact on the compressibility of the tree?

> Oh no doubt, I'm concerned about the inconsistency mostly. The
> maintainers arch is a concept that I do not necessarily associate
> with the keywords ordering anymore (although it may have been
> a reasonable indicator in the past), it actually really makes this
> discussion fuzzier than it has to be. 

Sorry, I didn't mean to confuse the issue by bringing that up.

> My point is more about how this got 'introduced' as a mindset and
> that such unguided behaviour gets reinforced by this discussion, now
> up to IUSE ordering changes and next we'll tackle inheritance order.

Agreed, it was a bad decision on my part to make the change without
discussing on this ML.  That's something I will try to not repeat in
the future.

Btw, here's an interesting statistic which really doesn't add to (or
detract from, I hope) this discussion...

grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
    s/[^[:lower:]\s]//; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S"; 
    END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'

49% of ebuilds are sorted (9435/19174)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Georgi Georgiev]

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

maillog: 10/06/2005-13:19:30(-0400): Aron Griffis types
> Btw, here's an interesting statistic which really doesn't add to (or
> detract from, I hope) this discussion...
> 
> grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
>     s/[^[:lower:]\s]//; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S"; 
>     END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'
> 
> 49% of ebuilds are sorted (9435/19174)

Your statistic seems to be flawed on a number of occasions. Assume
KEYWORDS="x86 ppc"

s/[^[:lower:]\s]//;

The above would only remove the "K" from "KEYWORDS" so you're left with
"EYWORDS="x86 ppc";

@F = split;

and you get an array of elements like:

$F[0] = 'EYWORDS="x86';
$F[1] = 'ppc"';

The sorted @S, would always have the capital "E" (and the first keyword)
as first element, because it's a capital letter.

Keywords that start with "~" will be grouped together after the stable
keywords, and I am guessing the idea is to have "~ppc" before "x86".

The above three statements do not depend on your locale, as perl does
not use locales by default:

$ echo 'a b A B ~a ~b ~A ~B' | LC_ALL=en_US perl -ne '@s = sort split; print "@s\n"'
A B a b ~A ~B ~a ~b

$ echo 'a b A B ~a ~b ~A ~B' | LC_ALL=en_US perl -ne 'use locale; @s = sort split; print "@s\n"'
a ~a A ~A b ~b B ~B

-- 
|    Georgi Georgiev   |  NT 5.0 so vaporous it's in danger of being   |
|     chutz@gg3.net    |  added to the periodic table as a noble       |
|   +81(90)2877-8845   |  gas. -- From Slashdot.org                    |

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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Georgi Georgiev wrote:	[Fri Jun 10 2005, 08:04:25PM EDT]
> maillog: 10/06/2005-13:19:30(-0400): Aron Griffis types
> > Btw, here's an interesting statistic which really doesn't add to (or
> > detract from, I hope) this discussion...
> > 
> > grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
> >     s/[^[:lower:]\s]//; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S"; 
> >     END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'
> > 
> > 49% of ebuilds are sorted (9435/19174)
> 
> Your statistic seems to be flawed on a number of occasions. Assume
> KEYWORDS="x86 ppc"
> 
> s/[^[:lower:]\s]//;

You wrote a long email to tell me that I forgot /g, I think. ;-)

grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
    s/[^[:lower:]\s]//g; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S"; 
    END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'

31% of ebuilds are sorted (6028/19185)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Georgi Georgiev]

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

maillog: 11/06/2005-08:48:17(-0400): Aron Griffis types
> Georgi Georgiev wrote:	[Fri Jun 10 2005, 08:04:25PM EDT]
> > maillog: 10/06/2005-13:19:30(-0400): Aron Griffis types
> > > Btw, here's an interesting statistic which really doesn't add to (or
> > > detract from, I hope) this discussion...
> > > 
> > > grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
> > >     s/[^[:lower:]\s]//; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S"; 
> > >     END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'
> > > 
> > > 49% of ebuilds are sorted (9435/19174)
> > 
> > Your statistic seems to be flawed on a number of occasions. Assume
> > KEYWORDS="x86 ppc"
> > 
> > s/[^[:lower:]\s]//;
> 
> You wrote a long email to tell me that I forgot /g, I think. ;-)
> 
> grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
>     s/[^[:lower:]\s]//g; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S"; 
>     END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'
> 
> 31% of ebuilds are sorted (6028/19185)

Oh. That would still not find the case when ppc64 comes before ppc, but
I agree it was a quick fix.

-- 
-*   Georgi Georgiev   -* I wish I was a sex-starved manicurist        -*
*-    chutz@gg3.net    *- found dead in the Bronx!!                    *-
-*  +81(90)2877-8845   -*                                              -*

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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Georgi Georgiev wrote:	[Sat Jun 11 2005, 08:39:41PM EDT]
> Oh. That would still not find the case when ppc64 comes before ppc, but
> I agree it was a quick fix.

You're right (of course).  Here's yet another try:

grep -hr --include=\*.ebuild '^KEYWORDS=' /usr/portage | perl -ne '
    s/[^[:lower:]\s\d]//g; @F = split; @S = sort @F; $sorted++ if "@F" eq "@S";
    END { printf "%d%% of ebuilds are sorted (%d/%d)\n", 100*$sorted/$., $sorted, $. }'

32% of ebuilds are sorted (6196/19185)

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

[gentoo-dev] Re: ekeyword and ordering

[Michael Sterrett -Mr. Bones.-]

On Mon, 6 Jun 2005, Aron Griffis wrote:

> As some of you have noticed, I made a change recently in ekeyword that
> causes ekeyword to alphabetize the keywords.  I've realized I should

The games team has been alphabetizing keywords for some time.  Just an
added datapoint.

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: ekeyword and ordering

[foser]

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

On Mon, 2005-06-06 at 18:43 -0400, Michael Sterrett -Mr. Bones.- wrote:
> The games team has been alphabetizing keywords for some time.  Just an
> added datapoint.

The fact that several developers have been doing things the 'alpha way'
for no particular reason is no reason in itself to adopt this as policy.

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Lars Weiler]

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

* Aron Griffis <agriffis@gentoo.org> [05/06/06 18:26 -0400]:
>     alpha
>     -----------------------------
>     - looks nicer (subjective)
>     - easier to tell at a glance if a given keyword is in the list

I'm for this. You can easily compare two ebuilds' KEYWORDS,
when you have the same order.

maintainer's arch should be stored in the metadata, if there
is a need for.

Regards, Lars

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

Re: [gentoo-dev] ekeyword and ordering

[Aaron Walker]

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

Lars Weiler wrote:
> * Aron Griffis <agriffis@gentoo.org> [05/06/06 18:26 -0400]:
> 
>>    alpha
>>    -----------------------------
>>    - looks nicer (subjective)
>>    - easier to tell at a glance if a given keyword is in the list
> 
> 
> I'm for this. You can easily compare two ebuilds' KEYWORDS,
> when you have the same order.
> 
> maintainer's arch should be stored in the metadata, if there
> is a need for.
> 
> Regards, Lars

I agree with Lars (particulary about adding maintaining arch to metdata if it's
necessary).  Another alpha++.

- --
Beam me up, Scotty!  It ate my phaser!

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpRIyC3poscuANHARAqLyAJ9JGbKI5UA6Up7t3IGjGJTOt6LAaQCgwcEB
kSkVPX2IXTyi9d+UK4lZ68s=
=hqdR
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Donnie Berkholz]

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

Aaron Walker wrote:
> I agree with Lars (particulary about adding maintaining arch to metdata if it's
> necessary).  Another alpha++.

So, let's get a way to do this. That way most concerns will be
addressed.

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

iD8DBQFCpejdXVaO67S1rtsRAuv+AJ9YHx2Yo+lss6ozxF/sYpVyW6wxYACfZLPZ
lhTjd0DmjcUnta0La6y1iDs=
=+rsM
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Tue, 2005-06-07 at 00:47 +0200, Lars Weiler wrote:
> * Aron Griffis <agriffis@gentoo.org> [05/06/06 18:26 -0400]:
> >     alpha
> >     -----------------------------
> >     - looks nicer (subjective)
> >     - easier to tell at a glance if a given keyword is in the list
> 
> I'm for this. You can easily compare two ebuilds' KEYWORDS,
> when you have the same order.

I assume you mean comparison between versions, what happens a lot when
doing ebuild updates. In that case order doesn't matter as long as it
stays consistent. What happens right now is that order is far from
consistent with some developers applying their own devised alpha
ordering whenever they touch a package. So the problem is not so much
what ordering is preferable, but that people change order without
discussing it.

> maintainer's arch should be stored in the metadata, if there
> is a need for.

Maintainer's arch could be ebuild/slot specific. I'm not yet convinced
metadata is the right place.

- foser

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

Re: [gentoo-dev] ekeyword and ordering

[Maurice van der Pot]

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

On Thu, Jun 09, 2005 at 03:10:31PM +0200, foser wrote:
> Maintainer's arch could be ebuild/slot specific. I'm not yet convinced
> metadata is the right place.

But are you convinced the keyword order is not the right place?
In case you are, stop reading =]

In case you are not, I would argue that maintainer's arch is an entirely
different item of information from the list of keywords. There is little
correlation, if any, between changes in maintainer arch and changes in 
the list of keywords.

For this reason I would not encode the maintainer's arch in the list of 
keywords.

This means that I have no strong preference for any particular ordering
and I would be inclined to go for anything that has a small advantage
over the others, such as being able to find keywords at a glance. 
It might even be too small an advantage to make policy out of it.

Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


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

Re: [gentoo-dev] ekeyword and ordering

[Simon Stelling]

Hi,

Aron Griffis wrote:
>     - A few people, myself included, pointed out that there's some
>       valuable information available when keywords are always added to
>       the end rather than being alphabetized.  In particular, the
>       concept of a "maintainer arch" is possible, in which the first
>       arch in the list is supposed to indicate general stability of
>       the ebuild, a leader for other arches to follow.
> 
>     - Some people disagreed with the "maintainer arch" concept.  They
>       felt that the arch teams do a better job of testing than some
>       maintainers, and there's no point waiting for a maintainer to
>       decide something is stable.

>From [1]:
|When a package version has proved stable for sufficient time and the
|Gentoo maintainer of the package is confident that the upgrade will not
|break a regular Gentoo user's machine, then it can be moved from ~ARCH
|to ARCH. An indication of the package's stability would be no verified
|or unresolved bug report for a month after the version's introduction.

If that policy is dropped, I'd prefer alpha, otherways append.

Greetings,

blubb

[1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=3&chap=1
-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Simon Stelling wrote:[Tue Jun 07 2005, 07:23:57AM EDT]
> From [1]:
> |When a package version has proved stable for sufficient time and the
> |Gentoo maintainer of the package is confident that the upgrade will not
> |break a regular Gentoo user's machine, then it can be moved from ~ARCH
> |to ARCH. An indication of the package's stability would be no verified
> |or unresolved bug report for a month after the version's introduction.
> 
> If that policy is dropped, I'd prefer alpha, otherways append.

Could you explain why that policy needs to be dropped for alpha to be
preferred?  It's not obvious to me how that policy requires append.
If all arch teams were to follow that policy, then it would work
smoothly like this:

    1. all keywords are ~arch

    2. maintainer marks their arch(es) stable

    3. arch maintainers see the stable marking (it could be any
       keyword in the list) and follow the leader

In other words, you can implement "maintainer arch" with either alpha
or append.  The idea of putting the maintainer's arch first is purely
cosmetic.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 07 June 2005 16:04, Aron Griffis wrote:
> Could you explain why that policy needs to be dropped for alpha to be
> preferred?  It's not obvious to me how that policy requires append.
You can't assume that maintainer arch would be x86, and with alphabetic order, 
you must ask to the maintainer which is his arch (and there's no way to learn 
all them by heart).
Maybe we can add this to metadata?

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Diego 'Flameeyes' Pettenò wrote:[Tue Jun 07 2005, 10:20:51AM EDT]
> You can't assume that maintainer arch would be x86, and with
> alphabetic order, you must ask to the maintainer which is his arch
> (and there's no way to learn all them by heart).

or look at the ChangeLog

> Maybe we can add this to metadata?

That would be better for tools to help determining which are
candidates for stable marking.  But for humans it's not really
different from looking at the ChangeLog, is it?

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Diego 'Flameeyes' Pettenò]

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

On Tuesday 07 June 2005 17:15, Aron Griffis wrote:
> That would be better for tools to help determining which are
> candidates for stable marking.  But for humans it's not really
> different from looking at the ChangeLog, is it?
It should be possible using ChangeLog if we are sure that ChangeLog is 
updated, and that the stable change is not hidden by a lot of other entries.
Also some changelogs are really really long...

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


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

Re: [gentoo-dev] ekeyword and ordering

[Chris Gianelloni]

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

On Tue, 2005-06-07 at 17:30 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 07 June 2005 17:15, Aron Griffis wrote:
> > That would be better for tools to help determining which are
> > candidates for stable marking.  But for humans it's not really
> > different from looking at the ChangeLog, is it?
> It should be possible using ChangeLog if we are sure that ChangeLog is 
> updated, and that the stable change is not hidden by a lot of other entries.
> Also some changelogs are really really long...

That's why new entries go to the top.  ;]

-- 
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] ekeyword and ordering

[Michael Cummings]

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

On Tuesday 07 June 2005 11:15 am, Aron Griffis wrote:
> Diego 'Flameeyes' Pettenò wrote:[Tue Jun 07 2005, 10:20:51AM EDT]
>
> > You can't assume that maintainer arch would be x86, and with
> > alphabetic order, you must ask to the maintainer which is his arch
> > (and there's no way to learn all them by heart).
>
> or look at the ChangeLog

HA! Oh man, I needed a good chuckle. cvs log is about the only nearly reliable 
thing I have found sometimes - seems folks that don't like to use 
metadata.xml when commiting a random package also avoid using ChangeLogs. Go 
figure.

-- 

-----o()o---------------------------------------------
Michael Cummings   |    #gentoo-dev, #gentoo-perl
Gentoo Perl Dev    |    on irc.freenode.net 
-----o()o---------------------------------------------

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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Michael Cummings wrote:[Tue Jun 07 2005, 12:49:21PM EDT]
> HA! Oh man, I needed a good chuckle. cvs log is about the only
> nearly reliable thing I have found sometimes - seems folks that
> don't like to use metadata.xml when commiting a random package also
> avoid using ChangeLogs. Go figure.

I guess I haven't run into as much of that as you have.  I have
a couple of functions that make this easy for me.  Here is the usage
if anybody is interested:

    ek - short for ekeyword

    er - run echangelog, then call rc automatically

    rc - repoman commit with the most recent message pulled from the
         ChangeLog

So in general I do something like this:

    $ ek alpha ia64 blah.ebuild
    $ er "stable on alpha, ia64"

If repoman doesn't allow me to commit for one reason or another, I'll
fix the problem, then simply run "rc" to retry the commit with the
same message.

Here are the function definitions:

  # ek: ekeyword
  alias ek=ekeyword

  # echangelog and repoman combined
  er() {
    echangelog ${1:+"$*"} || return 1
    rc
  }

  # repoman commit with the message from the ChangeLog
  rc() { 
    declare msg out

    if [[ -n $* ]]; then
      msg="$*"
      echo "Using msg from command-line" >&2
    else
      msg=$(perl <ChangeLog -0777 -pe \
        's/^.*?\n  \d{2} \w{3} \d{4};.*?:\n//s || exit 1; # trim top
         s/\n(?:\*|  \d{2} \w{3} \d{4};).*//s;            # trim bottom
         s/^\s*//; s/\s*$//; s/^(?:  |\t)//gm;            # fix spacing
        ')
      if [[ $? != 0 || -z $msg ]]; then
        echo "couldn't parse message from ChangeLog" >&2
        return 1
      fi
      echo "Parsed msg from ChangeLog" >&2
    fi

    echo "----------" >&2
    echo "$msg" >&2
    echo "----------" >&2

    repoman commit -m "$msg" || return 1

    if [[ -x /usr/bin/eviewcvs ]]; then
      local f entry=$(perl -00ne '/^  \d/ and print, last' ChangeLog)
      entry=${entry%%:*}
      entry=${entry##*>}
      entry=${entry//,/ }
      for f in $entry; do
        [[ $f == -* ]] && continue
        echo "${f#+}"
      done | xargs eviewcvs
    fi
  }

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Chris Gianelloni]

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

On Tue, 2005-06-07 at 16:20 +0200, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 07 June 2005 16:04, Aron Griffis wrote:
> > Could you explain why that policy needs to be dropped for alpha to be
> > preferred?  It's not obvious to me how that policy requires append.
> You can't assume that maintainer arch would be x86, and with alphabetic order, 
> you must ask to the maintainer which is his arch (and there's no way to learn 
> all them by heart).
> Maybe we can add this to metadata?

You can't assume the maintainer's arch is x86 anyway, even if it is
listed first.  As a good example, my main box is an amd64.  However,
when I started with Gentoo, I only had an x86.  This means all of my
packages probably have x86 listed first.  Do you think I actually
changed them when I got an amd64?  What about when I got my sparc?  My
ppc?  Do I change them depending on which machine I'm using at the time?
What about times when I am at work and can only test on x86, but not on
any of the other architectures that I happen to own?

Can you start to see where the idea of a maintainer arch really can be a
PITA?

While I would probably venture a guess that *most* of our packages are
maintained by people with x86 machines, that isn't a guarantee.  The
simplest way to maintain the "maintainer arch" is to simply see which
arch the maintainer changed the KEYWORDS on when he marked it stable.
If none are stable, then don't mark it stable.  If the maintainer marks
it stable on one or many arches, then you can change KEYWORDS.

Does that make sense?

-- 
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] ekeyword and ordering

[Diego 'Flameeyes' Pettenò]

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

On Wednesday 08 June 2005 00:31, Chris Gianelloni wrote:
> Does that make sense?
It does.. but still makes the things way harder :)
Well I actually don't mark anything stable that I don't maintain myself.. so 
that's not a problem too much for me anyway.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/


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

Re: [gentoo-dev] ekeyword and ordering

[Marcus D. Hanwell]

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

On Monday 06 June 2005 23:26, Aron Griffis wrote:
>
> I am willing to revert the ekeyword change if that is what devs would
> prefer, but I won't make the change without a discussion on -dev,
> which was my mistake last time.  Your thoughts?
>
I also vote for alpha. I would like to see some indication of maintainer arch 
in metadata too, but in general agree with the policy of if one arch 
stabilises then we can assume that is the maintainer arch.

Thanks,

Marcus

-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Marcus D. Hanwell wrote:[Tue Jun 07 2005, 05:32:31PM EDT]
> I also vote for alpha. I would like to see some indication of
> maintainer arch in metadata too, but in general agree with the
> policy of if one arch stabilises then we can assume that is the
> maintainer arch.

Whoa, careful there.  It's not a policy and it's not even
a recommendation.  I believe there are arch teams that will
automatically stable a package after it has been ~arch for a period of
time.  They will break your assumption.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[Olivier Crete]

On Tue, 2005-07-06 at 17:44 -0400, Aron Griffis wrote:
> Marcus D. Hanwell wrote:[Tue Jun 07 2005, 05:32:31PM EDT]
> > I also vote for alpha. I would like to see some indication of
> > maintainer arch in metadata too, but in general agree with the
> > policy of if one arch stabilises then we can assume that is the
> > maintainer arch.
> 
> Whoa, careful there.  It's not a policy and it's not even
> a recommendation.  I believe there are arch teams that will
> automatically stable a package after it has been ~arch for a period of
> time.  They will break your assumption.

This would be very evil. Are you sure its not a policy? Because it
should be and it has been discussed before. Arch teams should NOT get
ahead of the maintainer without his permission... or if they really
really know what they are doing. Maintainers normally know their
package/ebuilds and often have very good reasons to keep a package ~arch
for more than 30 days..  This is almost as evil as keywording on
architectures on which you can't test.. 

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer
x86 Security Liaison


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Marcus D. Hanwell]

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

On Tuesday 07 June 2005 22:56, Olivier Crete wrote:
> On Tue, 2005-07-06 at 17:44 -0400, Aron Griffis wrote:
> > Marcus D. Hanwell wrote:[Tue Jun 07 2005, 05:32:31PM EDT]
> >
> > > I also vote for alpha. I would like to see some indication of
> > > maintainer arch in metadata too, but in general agree with the
> > > policy of if one arch stabilises then we can assume that is the
> > > maintainer arch.
> >
> > Whoa, careful there.  It's not a policy and it's not even
> > a recommendation.  I believe there are arch teams that will
> > automatically stable a package after it has been ~arch for a period of
> > time.  They will break your assumption.
>
> This would be very evil. Are you sure its not a policy? Because it
> should be and it has been discussed before. Arch teams should NOT get
> ahead of the maintainer without his permission... or if they really
> really know what they are doing. Maintainers normally know their
> package/ebuilds and often have very good reasons to keep a package ~arch
> for more than 30 days..  This is almost as evil as keywording on
> architectures on which you can't test..
>
I have always managed to spot (I think) the ones that looked like they skipped 
ahead of the maintainer, but it is another reason why having a maintainer 
arch set would be nice. I thought it was policy/a suggestion, or at least 
polite and so I always try to check with the maintainer if a package isn't 
stable and we need it for some reason.

It would be nice to receive clarification on this issue, as there are times 
when new packages fix issues the maintainer is not aware of or does not 
encounter on his/her arch. I think every maintainer I have talked to has been 
helpful and we sorted it out between ourselves.

Thanks,

Marcus
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

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

Re: [gentoo-dev] ekeyword and ordering

[Lars Weiler]

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

* Marcus D. Hanwell <cryos@gentoo.org> [05/06/07 23:11 +0100]:
> I have always managed to spot (I think) the ones that looked like they skipped 
> ahead of the maintainer, but it is another reason why having a maintainer 
> arch set would be nice.

And sometimes (or even quite often) the maintainer owns more
than one arch ;-)  That's something you can't do with
KEYWORDS, but with metadata.  I for example can test on ppc,
x86 and sparc and so I do for the packages I maintain.

Regards, Lars

-- 
Lars Weiler  <pylon@gentoo.org>  +49-171-1963258
Gentoo Linux PowerPC    : Developer and Release Engineer
Gentoo Infrastructure   : CVS Administrator
Gentoo Foundation       : Trustee

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

Re: [gentoo-dev] ekeyword and ordering

[Aron Griffis]

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

Olivier Crete wrote:[Tue Jun 07 2005, 05:56:35PM EDT]
> Are you sure its not a policy? 

Fairly certain.  It's been discussed around in circles in the past.

> Because it should be and it has been
> discussed before. Arch teams should NOT get ahead of the maintainer
> without his permission... or if they really really know what they
> are doing. Maintainers normally know their package/ebuilds and often
> have very good reasons to keep a package ~arch for more than 30
> days..

Ciaran would have something to say about this, along the lines of some
packages sitting idle in ~arch state because the maintainer isn't
really paying attention.  In that case, who can really blame an arch
team for moving ahead on their own?

Your statements make a lot of sense, and yes, it's how one would
assume things work.  But perspective can change when you're working on
an architecture and losing patience with package maintainers.

In practice, arch maintainers gradually learn what packages are
well-maintained and what packages they stabilize without prior
maintainer approval.  A good example is foser's shepherding of
gnome... in general the arches wait for his lead before stabilizing.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


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

Re: [gentoo-dev] ekeyword and ordering

[foser]

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

On Tue, 2005-06-07 at 18:18 -0400, Aron Griffis wrote:
> Ciaran would have something to say about this, along the lines of some
> packages sitting idle in ~arch state because the maintainer isn't
> really paying attention.  In that case, who can really blame an arch
> team for moving ahead on their own?

Arch teams still have no reason to move ahead if they did not try to
contact the maintainer(s). Sure, some packages may get 'lost' in large
herds at times, but then the arches who do notice that particular pack
have an extra responsibility to make the maintainer aware of it's state.
Then if the maintainer still remains unresponsive there is sufficient
reason for the arch to act on their own.
In short, arches have to be able to strongly defend their actions if
they are to interfere with the maintainers responsibilities.

- foser



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

Re: [gentoo-dev] ekeyword and ordering

[Jason Wever]

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

On Tue, 7 Jun 2005, Aron Griffis wrote:

> Marcus D. Hanwell wrote:[Tue Jun 07 2005, 05:32:31PM EDT]
>> I also vote for alpha. I would like to see some indication of
>> maintainer arch in metadata too, but in general agree with the
>> policy of if one arch stabilises then we can assume that is the
>> maintainer arch.
>
> Whoa, careful there.  It's not a policy and it's not even
> a recommendation.  I believe there are arch teams that will
> automatically stable a package after it has been ~arch for a period of
> time.  They will break your assumption.

Agreed, the PPC team is very good at arbitrarily marking things stable 
whenever they feel like it, and often times before the maintainer does.

Cheers,
- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpwQ6dKvgdVioq28RAkWIAKC2EgL3Kw4VxUmjPrSDh6TwHIMqrgCfcL9e
4nXZ+A/KSwTcRnWVONy4K8I=
=bxSK
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Joseph Jezak]

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

> Agreed, the PPC team is very good at arbitrarily marking things stable
> whenever they feel like it, and often times before the maintainer does.

This is not usually our policy.  However, because we moved GCC-3.4 to
stable before many arches, there were a number of packages that needed
to be marked stable for PPC in order for the stable version to even
compile.  What should we have done in this case then?

- -Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCpxEbwGq7BLLARfoRAogWAJ0XBbZ6v+iBB2U2t60f/cXjXo+zPgCcDOd8
wniWOuMxUOcqAZqKcksgRBo=
=IC/Y
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Marcus D. Hanwell]

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

On Wednesday 08 June 2005 16:39, Joseph Jezak wrote:
> > Agreed, the PPC team is very good at arbitrarily marking things stable
> > whenever they feel like it, and often times before the maintainer does.
>
> This is not usually our policy.  However, because we moved GCC-3.4 to
> stable before many arches, there were a number of packages that needed
> to be marked stable for PPC in order for the stable version to even
> compile.  What should we have done in this case then?
>
If memory serves this is where amd64 had issues, we stabilised GCC 3.4 first I 
believe as it works much better than GCC 3.3, and so many apps needed 
patching/unstable versions. Some maintainers were not happy about this. 
Didn't happen to me as I became a dev after there were some issues raised, 
and I have always try to contact the maintainer to discuss it first in the 
rare circumstances where it is needed.

It would probably be helpful to have a ChangeLog entry saying stabilised ppc 
to fix GCC 3.4 compile problem or words to that effect, but I would expect 
that most apps have been fixed by us for our stable tree. I did think it had 
been decided that the maintainer should at least be contacted before 
stabilising before him/her.
-- 
Gentoo Linux Developer
Scientific Applications | AMD64 | KDE | net-proxy

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

Re: [gentoo-dev] ekeyword and ordering

[Jason Wever]

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

On Wed, 8 Jun 2005, Joseph Jezak wrote:

>> Agreed, the PPC team is very good at arbitrarily marking things stable
>> whenever they feel like it, and often times before the maintainer does.
>
> This is not usually our policy.  However, because we moved GCC-3.4 to
> stable before many arches, there were a number of packages that needed
> to be marked stable for PPC in order for the stable version to even
> compile.  What should we have done in this case then?

Assuming there wasn't a very compelling, "stuff is horribly broken in 
gcc-3.3.x" type reason, wait for the maintainer arch.

- -- 
Jason Wever
Gentoo/Sparc Co-Team Lead
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpxtqdKvgdVioq28RAjm7AJ9psRHMb8LYB6KqAhdi/jAzKj2j8ACglq3s
s8L6J7Ims/ZPt6upqMrgtlU=
=M1Z0
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Ferris McCormick]

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

On Tue, 7 Jun 2005, Marcus D. Hanwell wrote:

> On Monday 06 June 2005 23:26, Aron Griffis wrote:
>>
>> I am willing to revert the ekeyword change if that is what devs would
>> prefer, but I won't make the change without a discussion on -dev,
>> which was my mistake last time.  Your thoughts?
>>
> I also vote for alpha. I would like to see some indication of maintainer arch
> in metadata too, but in general agree with the policy of if one arch
> stabilises then we can assume that is the maintainer arch.
>

I also like alpha, but that is not what I am responding to.  And I have to 
admit that I haven't followed this too closely.  But the "if one arch 
stabalises..." assumption can be misleading.  For example, xorg-x11 
maintainer arch is x86 (spyderous will correct me if I am wrong), but I 
know of at least once instance in which sparc (and a few other archs) were 
stable ahead of x86.

Granted, spyderous knew what was going on and why, but for a few days 
there, the "stabilises" rule of thumb with nothing more would have led the 
unsuspecting reader to believe that maintainer arch for xorg was sparc.

Of course, as a guide, this rule will generally be correct.  Just not all 
the time.

> Thanks,
>
> Marcus
>
> -- 
> Gentoo Linux Developer
> Scientific Applications | AMD64 | KDE | net-proxy
>

Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCpijLQa6M3+I///cRAncRAJoClQEQwcwz0Ge6LiasRHw+3fV98wCgiKv+
BCO59gjXoUvdFzeUJvoJ23A=
=5KRh
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Donnie Berkholz]

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

Ferris McCormick wrote:
> I also like alpha, but that is not what I am responding to.  And I have
> to admit that I haven't followed this too closely.  But the "if one arch
> stabalises..." assumption can be misleading.  For example, xorg-x11
> maintainer arch is x86 (spyderous will correct me if I am wrong), but I
> know of at least once instance in which sparc (and a few other archs)
> were stable ahead of x86.
> 
> Granted, spyderous knew what was going on and why, but for a few days
> there, the "stabilises" rule of thumb with nothing more would have led
> the unsuspecting reader to believe that maintainer arch for xorg was sparc.

And this is the key, as usual: communication makes for happier devs. =)

But if sparc had gone ahead and stabilized without discussing it with
me, I would've been very pissed. I often have plans to add more stuff
before it goes stable, and when that happens, I'm left with two options,
both of which suck:

* Yet another bump for the new stuff, requiring everybody on ~arch to
recompile for things that often don't even affect them
* Acting as if the ebuild were still in testing despite the other arch
ignoring me and stabling it

Thanks,
Donnie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCpjsLXVaO67S1rtsRAnGfAJ9TiSI3nAHnxL5WXNR44zyoXjOv7QCg7u4S
vJgTrfKMuwxm9LWlu00ZKkk=
=x8bR
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] ekeyword and ordering

[Chris Gianelloni]

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

On Tue, 2005-06-07 at 23:07 +0000, Ferris McCormick wrote:
> I also like alpha, but that is not what I am responding to.  And I have to 
> admit that I haven't followed this too closely.  But the "if one arch 
> stabalises..." assumption can be misleading.  For example, xorg-x11 
> maintainer arch is x86 (spyderous will correct me if I am wrong), but I 
> know of at least once instance in which sparc (and a few other archs) were 
> stable ahead of x86.
> 
> Granted, spyderous knew what was going on and why, but for a few days 
> there, the "stabilises" rule of thumb with nothing more would have led the 
> unsuspecting reader to believe that maintainer arch for xorg was sparc.

No, because spyderous didn't do it.

It should also be noted in the ChangeLog:

"Marking stable on sparc because of $blah, which needs to be addressed
quickly... got the OK from spyderous..."

Something like that...

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