Re: [gentoo-dev] ekeyword and ordering
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 pgpqkmKaXzqbk.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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
pgpaUelTDxvTj.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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-*
*-[EMAIL PROTECTED]*- found dead in the Bronx!!*-
-* +81(90)2877-8845 -* -*
pgpVg1uTILx0w.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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
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 pgpbgFRkLvcon.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
On 6/11/05, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> 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
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
pgpZ6ZSh63rtv.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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/ pgpQEvYJ0JgNQ.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
On 6/11/05, foser <[EMAIL PROTECTED]> 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
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
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 pgp16vjho2Xm4.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 |
| [EMAIL PROTECTED]| added to the periodic table as a noble |
| +81(90)2877-8845 | gas. -- From Slashdot.org|
pgpcjhbScd7mP.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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
pgpj6bi999Fhg.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgp05TheWuBp1.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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
-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 <[EMAIL PROTECTED]> 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
* foser <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> +49-171-1963258 Gentoo Linux PowerPC: Developer and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgpq6J38vFk1x.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
On Tue, 2005-06-07 at 00:47 +0200, Lars Weiler wrote: > * Aron Griffis <[EMAIL PROTECTED]> [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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 pgpPBJHZzBGYT.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
-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
-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
-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
On Tue, 2005-06-07 at 23:07 +, 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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
-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
* Marcus D. Hanwell <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> +49-171-1963258 Gentoo Linux PowerPC: Developer and Release Engineer Gentoo Infrastructure : CVS Administrator Gentoo Foundation : Trustee pgpE0B4Zttu3l.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
-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) <[EMAIL PROTECTED]> 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
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/ pgpFzvhwIrQrq.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ekeyword and ordering
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 pgpYXfku3HAzi.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 pgpsNntWxFEOQ.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ekeyword and ordering
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 pgpZTG9cfvzFC.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 pgpj8gJntwPjX.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luca Barbato schrieb: > Stephen P. Becker wrote: > >>alpha++ > > > alpha++ > once again, alpha++ - -- Danny van Dyk <[EMAIL PROTECTED]> 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
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 &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
pgpbPWn4KXVtk.pgp
Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
-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
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- pgp23b7fJuajm.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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/ pgpnWSdOh15ID.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 pgpWT6VwZb99b.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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/ pgprAimOChZEJ.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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 pgpOuTenZxxQ7.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Weiler wrote: > * Aron Griffis <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> [ 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
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
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 [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ekeyword and ordering
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
* Aron Griffis <[EMAIL PROTECTED]> [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 pgpm0SplUdpGX.pgp Description: PGP signature
Re: [gentoo-dev] ekeyword and ordering
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
