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
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 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 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 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 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 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
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 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
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
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 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 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 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 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
-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 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
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 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
-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 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 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
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
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
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
-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
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
pgpbPWn4KXVtk.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
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
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 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 Crte [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
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 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
[gentoo-dev] ekeyword and ordering
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 pgp0nPu192mu6.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
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
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
