* [gentoo-dev] Council May Summary: Changes to ChangeLog handling @ 2011-05-17 10:32 Petteri Räty 2011-05-20 10:19 ` Mart Raudsepp 0 siblings, 1 reply; 34+ messages in thread From: Petteri Räty @ 2011-05-17 10:32 UTC (permalink / raw To: gentoo-dev-announce; +Cc: Gentoo Development [-- Attachment #1: Type: text/plain, Size: 417 bytes --] http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt Please note that you must now update ChangeLog with each commit. For more information please see the meeting log and the preceding mailing list thread: http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml On behalf of the council, Petteri [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 900 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling 2011-05-17 10:32 [gentoo-dev] Council May Summary: Changes to ChangeLog handling Petteri Räty @ 2011-05-20 10:19 ` Mart Raudsepp 2011-05-30 12:03 ` Peter Volkov 0 siblings, 1 reply; 34+ messages in thread From: Mart Raudsepp @ 2011-05-20 10:19 UTC (permalink / raw To: gentoo-dev Hello, On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote: > http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt > > Please note that you must now update ChangeLog with each commit. For > more information please see the meeting log and the preceding mailing > list thread: > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt > http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml While I always was, and still am quite a strong proponent for ChangeLogging removals, does this mean I need to spam the ChangeLog for small or negligible affect mistakes and fix it probably even before any rsync master updates have gone by, while said fix is more or less covered by the previously committed ChangeLog entry of the same date? To make it more clear, here's an example from the past: I didn't have scripts for gstreamer split bumps before, and it was an unwritten rule back then that for one of them I forget to edit the required gst-plugins-base version in the ebuild to its new requirement before repoman committing, and notice it within 5 minutes of committing. Then I would just fix it up, and commit without a ChangeLog update (as it's just noise to curious users), as the correction to the required version is part of the "Version bump" work; plus the nature of the packages is as such, that almost completely surely the new enough gst-plugins-base version will be on the users system anyway, as other new versions of the (more widely used) splits got it correctly earlier on the first commit. So am I required to ChangeLog such trivialities too now? There seems to have been a slight discussion about typos and whitespaces during the meeting, but I didn't see any conclusion on a cursory reading and then it was just voted "strict". As a separate note, I'm also a strong proponent of writing in ChangeLogs a bit about what has changed upstream for a version bump, so that users can see the important things BEFORE upgrading (and having /usr/share/doc/${PF}/NEWS* readily available); of course until that doesn't significantly delay the version bumps themselves due to potentially increased work for the maintainer. -- Mart Raudsepp ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling 2011-05-20 10:19 ` Mart Raudsepp @ 2011-05-30 12:03 ` Peter Volkov 2011-05-30 12:23 ` Ulrich Mueller ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Peter Volkov @ 2011-05-30 12:03 UTC (permalink / raw To: gentoo-dev В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет: > On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote: > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt > > > > Please note that you must now update ChangeLog with each commit. For > > more information please see the meeting log and the preceding mailing > > list thread: > > > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt > > http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml So, I just realized that we have to update Changelogs for everything, whitespaces and comments included. Even after reading meeting logs I still wonder, why council have decided to vote policy change that was not supported even by minority of developers? The whole idea after human editable ChangeLogs was to avoid whitespace changes and changes in comments. In the current state it is possible to generate them on rsync servers and avoid this burden. I would like council to update policy to allow exclude whitespace changes and changes in comments. -- Peter. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling 2011-05-30 12:03 ` Peter Volkov @ 2011-05-30 12:23 ` Ulrich Mueller 2011-05-30 18:07 ` William Hubbs 2011-05-30 17:52 ` Michał Górny 2011-05-30 21:55 ` Brian Harring 2 siblings, 1 reply; 34+ messages in thread From: Ulrich Mueller @ 2011-05-30 12:23 UTC (permalink / raw To: gentoo-dev >>>>> On Mon, 30 May 2011, Peter Volkov wrote: > So, I just realized that we have to update Changelogs for > everything, whitespaces and comments included. Even after reading > meeting logs I still wonder, why council have decided to vote policy > change that was not supported even by minority of developers? The > whole idea after human editable ChangeLogs was to avoid whitespace > changes and changes in comments. In the current state it is possible > to generate them on rsync servers and avoid this burden. > I would like council to update policy to allow exclude whitespace > changes and changes in comments. I second this. The council should also clarify how to treat the ChangeLog in case of package removals. The devmanual requires that it is updated even in this case, whereas the handbook says that all files should be removed. Ulrich ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling 2011-05-30 12:23 ` Ulrich Mueller @ 2011-05-30 18:07 ` William Hubbs 0 siblings, 0 replies; 34+ messages in thread From: William Hubbs @ 2011-05-30 18:07 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 408 bytes --] On Mon, May 30, 2011 at 02:23:09PM +0200, Ulrich Mueller wrote: > The council should also clarify how to treat the ChangeLog in case of > package removals. The devmanual requires that it is updated even in > this case, whereas the handbook says that all files should be removed. IMHO this is a case of common sense. When you completely remove a package, the ChangeLog gets removed. End of story. William [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling 2011-05-30 12:03 ` Peter Volkov 2011-05-30 12:23 ` Ulrich Mueller @ 2011-05-30 17:52 ` Michał Górny 2011-05-30 21:55 ` Brian Harring 2 siblings, 0 replies; 34+ messages in thread From: Michał Górny @ 2011-05-30 17:52 UTC (permalink / raw To: gentoo-dev; +Cc: pva [-- Attachment #1: Type: text/plain, Size: 1374 bytes --] On Mon, 30 May 2011 16:03:42 +0400 Peter Volkov <pva@gentoo.org> wrote: > В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет: > > On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote: > > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt > > > > > > Please note that you must now update ChangeLog with each commit. > > > For more information please see the meeting log and the preceding > > > mailing list thread: > > > > > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt > > > http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml > > So, I just realized that we have to update Changelogs for everything, > whitespaces and comments included. Even after reading meeting logs I > still wonder, why council have decided to vote policy change that was > not supported even by minority of developers? The whole idea after > human editable ChangeLogs was to avoid whitespace changes and changes > in comments. In the current state it is possible to generate them on > rsync servers and avoid this burden. So we're one step closer to getting rid of the whole separate log burden and thus closer to clear git migration. And generating changelogs on rsync servers is possible; egencache is capable of doing that, though for git only. -- Best regards, Michał Górny [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 316 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling 2011-05-30 12:03 ` Peter Volkov 2011-05-30 12:23 ` Ulrich Mueller 2011-05-30 17:52 ` Michał Górny @ 2011-05-30 21:55 ` Brian Harring 2011-05-30 22:05 ` Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) Andreas K. Huettel 2011-06-01 15:08 ` RFC: better policy for ChageLogs (was: Re: [gentoo-dev] " Peter Volkov 2 siblings, 2 replies; 34+ messages in thread From: Brian Harring @ 2011-05-30 21:55 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 3465 bytes --] On Mon, May 30, 2011 at 04:03:42PM +0400, Peter Volkov wrote: > В Птн, 20/05/2011 в 13:19 +0300, Mart Raudsepp пишет: > > On T, 2011-05-17 at 13:32 +0300, Petteri Räty wrote: > > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt > > > > > > Please note that you must now update ChangeLog with each commit. For > > > more information please see the meeting log and the preceding mailing > > > list thread: > > > > > > http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt > > > http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml > > So, I just realized that we have to update Changelogs for everything, > whitespaces and comments included. Even after reading meeting logs I > still wonder, why council have decided to vote policy change that was > not supported even by minority of developers? The majority support changelog maintenance for non-trivial changes; meaning removals, additions, eclass/eapi changes, changing logic, fixing build issues, etc. That's not really arguable, and for those who don't support it- they're bluntly, wrong, the ChangeLog isn't for devs (we have vcs logs after all)- it's for users, and that's the sort of thing they need to see. The problem is, that's a *fuzzy* definition. Quoting myself from the meeting: 19:37 <@ferringb> Arfrever: the kicker is, in certain cases, you're partally right. 19:37 <@ferringb> Arfrever: the reality is, people will just adhere to the letter of the law rather than the intent 19:37 <@ferringb> we already had that occur with removal 19:38 <@ferringb> stupid that we have to essentially legislate common sense, but that's what it is right now ;) 19:39 < NeddySeagoon> ferringb, common sense is much rarer that you might think :) 19:39 <@ferringb> NeddySeagoon: well aware If someone has a definition that is commonsense, then propose it- the current "you must log everything" is very, very heavy handed and basically was a forced situation since QA cannot make folks behave when the rules are reliant on common sense. We cannot have situations where devs adhere to the exact wording of the rules but violate the spirit, which is exactly what got us into this mess in the first place. Proposals to refine changelog maintenance I'm definitely open to- I very much hate that the situation basically forced us to go heavy handed, but the reality is, w/out the rules QA can't do anything about misbehaving folks- if they try, the argument becomes "I've not violated any rules!". If QA is able to make decisions/actions on their own without mapping directly back to rules, offenders start claiming "the cabal is after me, I've not done anything wrong!". Basically, it's being stuck between a rock and hard place. Not sure there is a solution there either. As said, come up w/ a proposal for that, closing the loopholes and I'm very much interested; however you'll have a hell of a time trying to define "non-trivial" in a manner that blocks people pulling shenanigans. > The whole idea after human > editable ChangeLogs was to avoid whitespace changes and changes in > comments. In the current state it is possible to generate them on rsync > servers and avoid this burden. > > I would like council to update policy to allow exclude whitespace > changes and changes in comments. It'll be on the schedule. ~harring [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) 2011-05-30 21:55 ` Brian Harring @ 2011-05-30 22:05 ` Andreas K. Huettel 2011-05-30 22:14 ` [gentoo-dev] Re: Common sense in " Diego Elio Pettenò 2011-05-30 23:38 ` Common sense in [gentoo-dev] " Brian Harring 2011-06-01 15:08 ` RFC: better policy for ChageLogs (was: Re: [gentoo-dev] " Peter Volkov 1 sibling, 2 replies; 34+ messages in thread From: Andreas K. Huettel @ 2011-05-30 22:05 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: Text/Plain, Size: 816 bytes --] Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring: > If someone has a definition that is commonsense, then propose it- the > current "you must log everything" is very, very heavy handed and > basically was a forced situation since QA cannot make folks behave > when the rules are reliant on common sense. Well how about "any change that can influence the behaviour of (portage|your favourite package manager) in any way or present the user with different output"? Clearly rules out whitespace changes. Small typos in text messages might be seen as a (harmless) borderline case. Removal of an ebuild definitely can influence portage behaviour, as can f.ex. an EAPI bump. Thoughts? -- Andreas K. Huettel Gentoo Linux developer dilfridge@gentoo.org http://www.akhuettel.de/ [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* [gentoo-dev] Re: Common sense in (was Council May Summary: Changes to ChangeLog handling) 2011-05-30 22:05 ` Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) Andreas K. Huettel @ 2011-05-30 22:14 ` Diego Elio Pettenò 2011-05-30 23:38 ` Common sense in [gentoo-dev] " Brian Harring 1 sibling, 0 replies; 34+ messages in thread From: Diego Elio Pettenò @ 2011-05-30 22:14 UTC (permalink / raw To: gentoo-dev Il giorno mar, 31/05/2011 alle 00.05 +0200, Andreas K. Huettel ha scritto: > > Thoughts? LGTM -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) 2011-05-30 22:05 ` Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) Andreas K. Huettel 2011-05-30 22:14 ` [gentoo-dev] Re: Common sense in " Diego Elio Pettenò @ 2011-05-30 23:38 ` Brian Harring 2011-05-31 0:01 ` Ângelo Arrifano 1 sibling, 1 reply; 34+ messages in thread From: Brian Harring @ 2011-05-30 23:38 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1450 bytes --] On Tue, May 31, 2011 at 12:05:03AM +0200, Andreas K. Huettel wrote: > Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring: > > If someone has a definition that is commonsense, then propose it- the > > current "you must log everything" is very, very heavy handed and > > basically was a forced situation since QA cannot make folks behave > > when the rules are reliant on common sense. > > Well how about "any change that can influence the behaviour of (portage|your > favourite package manager) in any way or present the user with different > output"? Mostly correct, although the problem there is 'influence'; consider: src_unpack() { bunch of code } being changed into new_func() { bunch of code } src_unpack() { invoke new_func } That should have no influence, thus not being ChangeLog'd. The problem is when the dev screws up, and it *has* an influence but no ChangeLog. A more real world example is people abusing eval and other things (python eclass for example)- folks can/do argue that it has no influence, but the complexity means it may have unexpected affect. That's the crux of the issue, and it comes down to common sense. Come up w/ a sane policy for things like that and I'll owe you some beer. Either way, for the rest of it, as Diego said, LGTM. I'm just nitpicking here to make it absolutely clear to people where we start running into policy issues. ~brian [-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) 2011-05-30 23:38 ` Common sense in [gentoo-dev] " Brian Harring @ 2011-05-31 0:01 ` Ângelo Arrifano 0 siblings, 0 replies; 34+ messages in thread From: Ângelo Arrifano @ 2011-05-31 0:01 UTC (permalink / raw To: gentoo-dev On Tuesday 31 May 2011 00:38:34 Brian Harring wrote: > On Tue, May 31, 2011 at 12:05:03AM +0200, Andreas K. Huettel wrote: > > Am Montag 30 Mai 2011, 23:55:52 schrieb Brian Harring: > > > If someone has a definition that is commonsense, then propose it- the > > > current "you must log everything" is very, very heavy handed and > > > basically was a forced situation since QA cannot make folks behave > > > when the rules are reliant on common sense. > > > > Well how about "any change that can influence the behaviour of > > (portage|your favourite package manager) in any way or present the user > > with different output"? > > Mostly correct, although the problem there is 'influence'; consider: > > src_unpack() { > bunch of code > } > > being changed into > > new_func() { > bunch of code > } > src_unpack() { > invoke new_func > } > > That should have no influence, thus not being ChangeLog'd. The > problem is when the dev screws up, and it *has* an influence but no > ChangeLog. > > A more real world example is people abusing eval and other things > (python eclass for example)- folks can/do argue that it has no > influence, but the complexity means it may have unexpected affect. > > That's the crux of the issue, and it comes down to common sense. > Come up w/ a sane policy for things like that and I'll owe you some > beer. > > Either way, for the rest of it, as Diego said, LGTM. I'm just > nitpicking here to make it absolutely clear to people where we start > running into policy issues. > > ~brian Not disagreeing at all with what was said, I'm just going to add that adding conditionals or exceptions to the rules makes them harder to remember. It is easier to remember - you shall not pass - than - you shall not pass if you make a change wich does not affect X - . Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded developer GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com ^ permalink raw reply [flat|nested] 34+ messages in thread
* RFC: better policy for ChageLogs (was: Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling) 2011-05-30 21:55 ` Brian Harring 2011-05-30 22:05 ` Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) Andreas K. Huettel @ 2011-06-01 15:08 ` Peter Volkov 2011-06-01 15:15 ` [gentoo-dev] Re: RFC: better policy for ChageLogs Markos Chandras 1 sibling, 1 reply; 34+ messages in thread From: Peter Volkov @ 2011-06-01 15:08 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 571 bytes --] В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет: > The problem is, that's a *fuzzy* definition. Ok, let's start with something and then we'll add more items if required. Currently I'd like to propose following text: The ChangeLog must be updated with each commit. The only possible relaxations for this rule are: 1. Nonfunctional whitespace changes 2. Changes in comments (lines starting with # in ebuild, or leading text in patches) 3. Manifest updates 4. Changes in ChageLog itself ;) Something unclear? Anything else? -- Peter. [-- Attachment #2: text.xml.patch --] [-- Type: text/x-patch, Size: 1056 bytes --] diff --git a/ebuild-writing/misc-files/changelog/text.xml b/ebuild-writing/misc-files/changelog/text.xml index d92bbf4..eea927e 100644 --- a/ebuild-writing/misc-files/changelog/text.xml +++ b/ebuild-writing/misc-files/changelog/text.xml @@ -5,10 +5,21 @@ <body> <p> -The <c>ChangeLog</c> must be updated with each commit. The -echangelog tool should be used to create <c>ChangeLog</c> entries; -the format of a <c>ChangeLog</c> is now defined as "whatever -<c>echangelog</c> creates". +The <c>ChangeLog</c> must be updated with each commit. The only possible +relaxations for this rule are: +</p> + +<ul> + <li><b>1.</b> Nonfunctional whitespace changes</li> + <li><b>2.</b> Changes in comments (lines starting with # in ebuild, or leading text in patches)</li> + <li><b>3.</b> Manifest updates</li> + <li><b>4.</b> Changes in <c>ChageLog</c> itself ;)</li> +</ul> + +<p> +The echangelog tool should be used to create <c>ChangeLog</c> entries; the +format of a <c>ChangeLog</c> is now defined as "whatever <c>echangelog</c> +creates". </p> <p> ^ permalink raw reply related [flat|nested] 34+ messages in thread
* [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:08 ` RFC: better policy for ChageLogs (was: Re: [gentoo-dev] " Peter Volkov @ 2011-06-01 15:15 ` Markos Chandras 2011-06-01 15:27 ` Samuli Suominen 2011-06-01 15:30 ` Nathan Phillip Brink 0 siblings, 2 replies; 34+ messages in thread From: Markos Chandras @ 2011-06-01 15:15 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/06/2011 04:08 μμ, Peter Volkov wrote: > В Пнд, 30/05/2011 в 14:55 -0700, Brian Harring пишет: >> The problem is, that's a *fuzzy* definition. > > Ok, let's start with something and then we'll add more items if > required. Currently I'd like to propose following text: > > The ChangeLog must be updated with each commit. The only possible > relaxations for this rule are: > > 1. Nonfunctional whitespace changes > 2. Changes in comments (lines starting with # in ebuild, or leading text > in patches) > 3. Manifest updates > 4. Changes in ChageLog itself ;) > > Something unclear? Anything else? > > -- > Peter. Maybe typos in e{log,warn,info} messages and/or typos in general ( variables, functions etc ) - -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAEBCgAGBQJN5leTAAoJEPqDWhW0r/LCztAP/2GIXm1yllZX1r1IBErUoLGG aO+8RGSgFrdT5SskyqA5Gbah+5XMzCyVEidebxst5JNSbpnKlRFPAvSJQUgHnJiD +mQXizqqjJpbDBs0ktXFQIepXpUZ3vKUKAw8BG2fJ2thblBFA+A8V02cTF4mE5iV HwiR2+0LGFVfR3HB2Q1Udbz24GIXxIFjhCzHW34f273VhBMWoUfaYxLAlFIPsnEn TCvLwgdgSZqRIOH7+QyZHTVwvexVqHTu0mUWRTkCFoDX58PLfE4UolpRZGY/g/4n MUDwmTvMaC7q90JhskCCCBcORgLnQpv4pqaTD6XV8x7Dnk96oT1BgDY7j5tu2Ezj dp3ZPsPlf36xjYO9SGxu24KJvbb0DSeCxqN27EYa0p4yE/zAWyve2TsPX5lTdiVF jZIrzoCBpBAu8/ggUBIDZOwgXMbHj2xTu2b1QFo2XOI+xSl57V+O5u2cuhEtQYYR 6kcK44cIYjKEUjroaxcn5CaIpOzmEuGq1O+1cNM+s7jXqPSQswa9EnJ5NyXs2IHw EAOpqOpuQdNnk0cPqYv2zKhvTiP7Y6mR7aFA7zMOKPOD2Eh3E1BksPHk7hIKIjoS nsVQ0f2sBntBUUmcc21QlPe5iSIuRrtj9hc3xiS2B4GygjiAflp443VL46ytjlH5 vlm5PBCN8ZZx0AvPc6n/ =Hnq4 -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:15 ` [gentoo-dev] Re: RFC: better policy for ChageLogs Markos Chandras @ 2011-06-01 15:27 ` Samuli Suominen 2011-06-01 15:34 ` Ciaran McCreesh 2011-06-01 15:39 ` Andreas K. Huettel 2011-06-01 15:30 ` Nathan Phillip Brink 1 sibling, 2 replies; 34+ messages in thread From: Samuli Suominen @ 2011-06-01 15:27 UTC (permalink / raw To: gentoo-dev On 06/01/2011 06:15 PM, Markos Chandras wrote: > On 01/06/2011 04:08 ¼¼, Peter Volkov wrote: >> \x12 \x1f=4, 30/05/2011 2 14:55 -0700, Brian Harring ?8H5B: >>> The problem is, that's a *fuzzy* definition. > >> Ok, let's start with something and then we'll add more items if >> required. Currently I'd like to propose following text: > >> The ChangeLog must be updated with each commit. The only possible >> relaxations for this rule are: > >> 1. Nonfunctional whitespace changes >> 2. Changes in comments (lines starting with # in ebuild, or leading text >> in patches) >> 3. Manifest updates >> 4. Changes in ChageLog itself ;) > >> Something unclear? Anything else? > >> -- >> Peter. > Maybe typos in e{log,warn,info} messages and/or typos in general ( > variables, functions etc ) > And the list will grow... If we don't want to start monitoring also the context of ChangeLog entries, Like if someone adds a epatch line to fix a real bug in a ebuild but while at it fixes ebuild Coding Style for repoman/pcheck/and so forth, fails to mention it in the log. How is that different from committing just the Coding Style fix and then leaving it out of ChangeLog? Wouldn't it be better to just trust devs to use common sense in what gets into ChangeLogs, and actually be grateful about if they take the time to sensor the crap out from it, and scrap the whole topic? (I honestly can't remember being involved in anything this useless...) - Samuli ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:27 ` Samuli Suominen @ 2011-06-01 15:34 ` Ciaran McCreesh 2011-06-02 11:21 ` Jorge Manuel B. S. Vicetto 2011-06-01 15:39 ` Andreas K. Huettel 1 sibling, 1 reply; 34+ messages in thread From: Ciaran McCreesh @ 2011-06-01 15:34 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 598 bytes --] On Wed, 01 Jun 2011 18:27:04 +0300 Samuli Suominen <ssuominen@gentoo.org> wrote: > Wouldn't it be better to just trust devs to use common sense in what > gets into ChangeLogs, and actually be grateful about if they take the > time to sensor the crap out from it, and scrap the whole topic? This whole thing came about because a select few developers repeatedly refused to use common sense, even after having been told to do so on numerous occasions. Unfortunately, common sense for some developers is running round the room whilst waving their wangs at everyone. -- Ciaran McCreesh [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:34 ` Ciaran McCreesh @ 2011-06-02 11:21 ` Jorge Manuel B. S. Vicetto 0 siblings, 0 replies; 34+ messages in thread From: Jorge Manuel B. S. Vicetto @ 2011-06-02 11:21 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01-06-2011 15:34, Ciaran McCreesh wrote: > On Wed, 01 Jun 2011 18:27:04 +0300 > Samuli Suominen <ssuominen@gentoo.org> wrote: >> Wouldn't it be better to just trust devs to use common sense in what >> gets into ChangeLogs, and actually be grateful about if they take the >> time to sensor the crap out from it, and scrap the whole topic? > > This whole thing came about because a select few developers repeatedly > refused to use common sense, even after having been told to do so on > numerous occasions. Unfortunately, common sense for some developers > is running round the room whilst waving their wangs at everyone. I had meant to send a reply to this message yesterday, saying I agree with Ciaran on this. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN53JUAAoJEC8ZTXQF1qEPr7MQALJKKNmx6McM93T9c5IepKGJ k/AGcpbz6V1JRxzLToZigl6ChoRCfp1jIIE0kb8sr9l4R5BpYaIkHyO/o5+uDq/F cg49IJc9A/syfacD8dcf+5ueLHQXJcZjgreok5gKGjjnrdayntc6ZHFgH569BtuG 8feC+iSa/5AQ9XBQ7JjTNlgblHCyXC9h6YTHOkYCENJT8zMhH0urTZqkrv3oNNVl RuqsATeyop5aodht2XSlPoNnvJyZOjTo+ZTBfH+pe9q3Cx2XIR8MkPglqBoRucDn RvPwTjBZLhDX4WyznDjZAZjk4SRU32TvSdxRH0TAnoTmEl/bBeUPB09fWuw6Go6j cIbp4zAURYBE4QfxjKHG7J5Zzkk9A9YDX/2eDAHPepSnJKr0cpSU7O/lH/SMLpqo 4Cgdo9b83ElyK36madmXYB92S0tMycwWhjJaK8LNODKToLaPvjy3D3dI0iUIKBvn Sj8WRG/zP4wNwoN25EPSPfArBoVsXnPrl8kIJNpdX3lHzBz7CHdDzFd95dzC4opH sEVqNEIpyAHfgaXioVOmLgeJyuK9Hr9M5kH5QQpZCuKM7z4AkiVJaRJW8LdpgEMp 8P2CBTKyL8KrFDFw73SRsdt7rCAM28Ukt+HZLbsIOvwGkiRZB9JLy+TzGvvwpJTf MwnHIigHpPdjbuknKO97 =x5eY -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:27 ` Samuli Suominen 2011-06-01 15:34 ` Ciaran McCreesh @ 2011-06-01 15:39 ` Andreas K. Huettel [not found] ` <BANLkTimgHYKnfbeQJpq829YBeE-5Yz=aEg@mail.gmail.com> 1 sibling, 1 reply; 34+ messages in thread From: Andreas K. Huettel @ 2011-06-01 15:39 UTC (permalink / raw To: gentoo-dev Am Mittwoch 01 Juni 2011, 17:27:04 schrieb Samuli Suominen: > Wouldn't it be better to just trust devs to use common sense in what > gets into ChangeLogs, and actually be grateful about if they take the > time to sensor the crap out from it, and scrap the whole topic? The problem is, not everyone has the same notion of common sense. I hate fumbling around with cvs, and see it as an absolutely great convenience if the changelog clearly indicates when exactly an ebuild has been removed... -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfridge@gentoo.org http://www.akhuettel.de/ ^ permalink raw reply [flat|nested] 34+ messages in thread
[parent not found: <BANLkTimgHYKnfbeQJpq829YBeE-5Yz=aEg@mail.gmail.com>]
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs [not found] ` <BANLkTimgHYKnfbeQJpq829YBeE-5Yz=aEg@mail.gmail.com> @ 2011-06-01 16:24 ` Andreas K. Huettel 2011-06-01 19:50 ` Nirbheek Chauhan 0 siblings, 1 reply; 34+ messages in thread From: Andreas K. Huettel @ 2011-06-01 16:24 UTC (permalink / raw To: gentoo-dev > So we come back to the problem being *CVS* not ChangeLog rules. Well of course we can just tell everyone "go look it up on sources.gentoo.org". However, this is a different discussion. > All this is such a massive waste of time. Can't we just expend this > energy on the move to git? Ack, this is an idea that I can very much support. But please please then have the changelog autogenerated from the git commit log, as otherwise the entire discussion will just continue. (/me is waiting for the next flamewar.) And again, this is also a different discussion. We're not talking about future plans here but about the current situation. And about how to deal with it. End of message from the department of redundancy department. -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfridge@gentoo.org http://www.akhuettel.de/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 16:24 ` Andreas K. Huettel @ 2011-06-01 19:50 ` Nirbheek Chauhan 2011-06-01 23:29 ` Jorge Manuel B. S. Vicetto 0 siblings, 1 reply; 34+ messages in thread From: Nirbheek Chauhan @ 2011-06-01 19:50 UTC (permalink / raw To: gentoo-dev On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote: > >> So we come back to the problem being *CVS* not ChangeLog rules. > > Well of course we can just tell everyone "go look it up on sources.gentoo.org". > However, this is a different discussion. > sources.gentoo.org is a much worse (and slower) solution than cvs log. The main advantage of a ChangeLog (and of git) is that it allows you to check the history locally, without needing access to the network. >> All this is such a massive waste of time. Can't we just expend this >> energy on the move to git? > [snip] > We're not talking about future plans here but about the current situation. > And about how to deal with it. > The current situation is: (a) Not dire. (b) Not urgent. And if we decide, hey, let's move to git instead of having this discussion, the current situation is also: (c) A waste of everyone's time. So no, future plans are not independent of the current situation, and a move to git *is* a way to deal with the current situation. In effect, we kill (at least) two birds with one stone and prevent a lot of argument and bad blood. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 19:50 ` Nirbheek Chauhan @ 2011-06-01 23:29 ` Jorge Manuel B. S. Vicetto 2011-06-01 23:37 ` Matt Turner 2011-06-02 11:05 ` Nirbheek Chauhan 0 siblings, 2 replies; 34+ messages in thread From: Jorge Manuel B. S. Vicetto @ 2011-06-01 23:29 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01-06-2011 19:50, Nirbheek Chauhan wrote: > On Wed, Jun 1, 2011 at 9:54 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote: >> >>> So we come back to the problem being *CVS* not ChangeLog rules. >> >> Well of course we can just tell everyone "go look it up on sources.gentoo.org". >> However, this is a different discussion. >> > sources.gentoo.org is a much worse (and slower) solution than cvs log. > The main advantage of a ChangeLog (and of git) is that it allows you > to check the history locally, without needing access to the network. > >>> All this is such a massive waste of time. Can't we just expend this >>> energy on the move to git? >> > [snip] >> We're not talking about future plans here but about the current situation. >> And about how to deal with it. >> > > The current situation is: > > (a) Not dire. > (b) Not urgent. (c) has irked enough developers and users that people pushed council to update the policy about the use of ChangeLogs. > And if we decide, hey, let's move to git instead of having this > discussion, the current situation is also: > > (c) A waste of everyone's time. > > So no, future plans are not independent of the current situation, and > a move to git *is* a way to deal with the current situation. > > In effect, we kill (at least) two birds with one stone and prevent a > lot of argument and bad blood. To be clear I support the goal to move our tree to git. However, I'd like to point out that simply moving to git will leave us in the same state. Assuming everyone agrees that git is far more useful than cvs to check for changes in the tree, a simple but important issue remains: the plan is to move the "development tree" to git, but to keep the rsync mirrors for users. So the "move to git" doesn't fix the issue for users or developers using an rsync tree. One solution that has been proposed before and that was raised again in this thread is to generate ChangeLogs directly from scm commit messages. That is already a solution with cvs, so moving to git won't help here. The same objections that have been raised about doing it for cvs, not being able to use different messages for the commit message and in ChangeLog (something I understand but admit have hardly used before), are also valid if we move to git. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5stWAAoJEC8ZTXQF1qEPIPMQAJOBJxGkWJZ3saNdQvAjbR7l KQdLHbO3IdUTBixqSqnmBXop4d6XFBd6lZyjiLu29x9xBn68wE4gm7rlpulITs6R Yqh4ASyLkUF88qezmqdkBaIy/TUGpGS7ZQWMu7ViarhPtLpcyrVWIh8U0T7oJZBh offLYHiQK9dDajLro83aIGLfRlLEYTB9MhjHegv8sDTUCr+ti23OuKjO0CoI7LFx yYdnzkA1YQWA1MGj6iEAVHzcy+RsaGK1QfVn26qAyly3Mg4mPkbKjtIHUEleIV0X TiWPQfNOvPbbNNyuaJ2cBZoGSTLtTstwUKMccYspQawCpDz0h2yNxNLtVS5ws5AO HBvfuWROKtWQ90hSiHb5dy13KXhRYR0CZzGPPLMs316YzdsFtKRL5AG3ywzLT2Bu Dj/wiUoRIRhoPuBTRskCxmXBd04nE/MtDZM/MRn0OZE9zHeYvZYIqCtWVXaGejtZ uID3LxOdGvJn07+TeH7/i8ap4zchRvwZaW6H9LBFr5bIHzKEFPUAfL3NqquGj66d HOHsh/RdPG25gKAZy5/zJ92lsRbFyZlxZFNYoTBTSFg89z7YldPMMxPPpNMWro+n ZzhyourKYprtt2+ZI05gPB/f24KMBhZY8kALoORSeNpUxBwTQ/aanpbKKqjFcfuv j0asDqRgkHAvpF3aTmaI =cSzK -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 23:29 ` Jorge Manuel B. S. Vicetto @ 2011-06-01 23:37 ` Matt Turner 2011-06-02 5:09 ` Peter Volkov 2011-06-02 11:05 ` Nirbheek Chauhan 1 sibling, 1 reply; 34+ messages in thread From: Matt Turner @ 2011-06-01 23:37 UTC (permalink / raw To: gentoo-dev On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> wrote: > To be clear I support the goal to move our tree to git. > However, I'd like to point out that simply moving to git will leave us > in the same state. Assuming everyone agrees that git is far more useful > than cvs to check for changes in the tree, a simple but important issue > remains: the plan is to move the "development tree" to git, but to keep > the rsync mirrors for users. So the "move to git" doesn't fix the issue > for users or developers using an rsync tree. Temporarily or permanently? One of the huge benefits in using git would be really fast emerge --syncs. Not having some kind of system for migrating users to git seems like a lot of the benefits are lost. Matt ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 23:37 ` Matt Turner @ 2011-06-02 5:09 ` Peter Volkov 2011-06-02 7:29 ` Duncan 2011-06-02 7:40 ` Eray Aslan 0 siblings, 2 replies; 34+ messages in thread From: Peter Volkov @ 2011-06-02 5:09 UTC (permalink / raw To: gentoo-dev В Срд, 01/06/2011 в 19:37 -0400, Matt Turner пишет: > On Wed, Jun 1, 2011 at 7:29 PM, Jorge Manuel B. S. Vicetto > <jmbsvicetto@gentoo.org> wrote: > > To be clear I support the goal to move our tree to git. > > However, I'd like to point out that simply moving to git will leave us > > in the same state. ++ ChangeLog files are text to be distributed to our users so they are completely independent of vcs we use. > > Assuming everyone agrees that git is far more useful > > than cvs to check for changes in the tree, a simple but important issue > > remains: the plan is to move the "development tree" to git, but to keep > > the rsync mirrors for users. So the "move to git" doesn't fix the issue > > for users or developers using an rsync tree. > > Temporarily or permanently? > > One of the huge benefits in using git would be really fast emerge > --syncs. Not having some kind of system for migrating users to git > seems like a lot of the benefits are lost. Is git faster then rsync? I've never done any checks but it'll be surprising if it will. Another useful feature of rsync is --exclude that allows some categories to be excluded (for size and speed efficiency), e.g. my servers don't need kde-* and games-*. Also taking into account that we use portage tree on embedded devices where again both size and speed really matters it looks like the answer on your question is "permanently". -- Peter. ^ permalink raw reply [flat|nested] 34+ messages in thread
* [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-02 5:09 ` Peter Volkov @ 2011-06-02 7:29 ` Duncan 2011-06-02 7:40 ` Eray Aslan 1 sibling, 0 replies; 34+ messages in thread From: Duncan @ 2011-06-02 7:29 UTC (permalink / raw To: gentoo-dev Peter Volkov posted on Thu, 02 Jun 2011 09:09:04 +0400 as excerpted: >> One of the huge benefits in using git would be really fast emerge >> --syncs. Not having some kind of system for migrating users to git >> seems like a lot of the benefits are lost. > > Is git faster then rsync? I've never done any checks but it'll be > surprising if it will. That's a question that has come up before. I don't know the answer... > Another useful feature of rsync is --exclude that > allows some categories to be excluded (for size and speed efficiency), > e.g. my servers don't need kde-* and games-*. Git has similar options in the form of the .git/info/exclude file at the (local) repository level, and .gitignore files at the subdir level (these are normally synced with the repo but of course can be excluded locally by the above repository level file, if desired). Patterns similar to those used by rsync --exclude are even supported. =:^) See also the git config core.excludefile command (git-config (1) manpage) and the gitignore (5) manpage. > Also taking into account > that we use portage tree on embedded devices where again both size and > speed really matters it looks like the answer on your question is > "permanently". With shallow checkouts, the size aspect is somewhat mitigated. However, it may be that there'd be three user sync options, adding git, to the current two (rsync and webrsync). IMO it'd be a real shame to not make the git sync option available to the user, as a number of projects have already discovered that real community involvement at the GOOD bug report and above level can increase dramatically after a switch to git, due to the vastly increased accessibility and ease of use of tools such as git bisect. But the *REAL* decison on whether git is ultimately made available at the user level or not will probably be infra's to make, based not on the above, but on the very practical question of whether Gentoo's mirror infrastructure can actually handle the git-pull load. After all, that's said to be the reason the CVS tree isn't made directly available to ordinary users today. Git should be better than CVS in that regard, but will it be good /enough/ as compared to the resources demanded by rsync, or not? That I don't know, tho I suspect infra and/or the git upgrade project already has a reasonably educated opinion on the matter. Of course, someone like Google donating enough hardware and bandwidth to "make it happen", based on, say, their use of Gentoo as a basis for ChromeOS, thus making a healthy Gentoo good for them too, might help infra with its decision. One can hope. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-02 5:09 ` Peter Volkov 2011-06-02 7:29 ` Duncan @ 2011-06-02 7:40 ` Eray Aslan 2011-06-02 11:20 ` Patrick Lauer 1 sibling, 1 reply; 34+ messages in thread From: Eray Aslan @ 2011-06-02 7:40 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 925 bytes --] On 2011-06-02 8:09 AM, Peter Volkov wrote: > ChangeLog files are text to be distributed to our users so they are > completely independent of vcs we use. Just ditch the Changelogs and be done with it. The only objection I know is that changelogs act as a NEWS file. Well, it is not a good enough reason in my humble opionion. Find another way to present NEWS if it is deemed necessary. > Is git faster then rsync? I've never done any checks but it'll be > surprising if it will. Git usually is faster - except the initial clone. Basically, rsync protocol scales with the project size not with change size. And lastly, while I don't really care either way, I think at least some of the push back is the result of unfamiliarity with git. And my impression is that unless a dev with enough political capital spearheads the move, this issue will continue to come up for a long time yet. -- Eray [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 898 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-02 7:40 ` Eray Aslan @ 2011-06-02 11:20 ` Patrick Lauer 0 siblings, 0 replies; 34+ messages in thread From: Patrick Lauer @ 2011-06-02 11:20 UTC (permalink / raw To: gentoo-dev On 06/02/11 09:40, Eray Aslan wrote: >> Is git faster then rsync? I've never done any checks but it'll be >> surprising if it will. > > Git usually is faster - except the initial clone. Basically, rsync > protocol scales with the project size not with change size. We're discussing performance of something that takes less than a minute. I see times of ~30-45 seconds for emerge --sync vs. ~30 seconds for git pull on the kde overlay. And then portage takes so much longer to calculate deps anyway ... why are we discussing the performance of the fastest operation? ;) > And lastly, while I don't really care either way, I think at least some > of the push back is the result of unfamiliarity with git. And my > impression is that unless a dev with enough political capital spearheads > the move, this issue will continue to come up for a long time yet. > More the complexity of git making simple things an hour-long oddysey through IRC, trying to find someone who has a clue how to get the HEAD back ... it's a complex thing that usually gets in the way when I use more than add, commit and push (and even push is aargh nooo why so complimacated?!) But I guess people prefer having to write wrapper scripts around wrappers to get things done, so I'll just stay out of the way and reserve the right to point and laugh when funny misbehaviour happens. -- Patrick Lauer http://service.gentooexperimental.org Gentoo Council Member and Evangelist Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 23:29 ` Jorge Manuel B. S. Vicetto 2011-06-01 23:37 ` Matt Turner @ 2011-06-02 11:05 ` Nirbheek Chauhan 2011-06-02 11:10 ` Ciaran McCreesh 2011-06-02 14:43 ` Rich Freeman 1 sibling, 2 replies; 34+ messages in thread From: Nirbheek Chauhan @ 2011-06-02 11:05 UTC (permalink / raw To: gentoo-dev On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> wrote: > On 01-06-2011 19:50, Nirbheek Chauhan wrote: >> The current situation is: >> >> (a) Not dire. >> (b) Not urgent. > > (c) has irked enough developers and users that people pushed council to > update the policy about the use of ChangeLogs. Yes, and I'm surprised that these same developers pushed towards a negative solution (kick productive people out) rather than a positive solution (move to git). >> And if we decide, hey, let's move to git instead of having this >> discussion, the current situation is also: >> >> (c) A waste of everyone's time. >> >> So no, future plans are not independent of the current situation, and >> a move to git *is* a way to deal with the current situation. >> >> In effect, we kill (at least) two birds with one stone and prevent a >> lot of argument and bad blood. > > To be clear I support the goal to move our tree to git. > However, I'd like to point out that simply moving to git will leave us > in the same state. Assuming everyone agrees that git is far more useful > than cvs to check for changes in the tree, a simple but important issue > remains: the plan is to move the "development tree" to git, but to keep > the rsync mirrors for users. So the "move to git" doesn't fix the issue > for users or developers using an rsync tree. Arguably, if developers want to know the history they should use the copy of the git tree that they're supposed to be having. Relying on ChangeLogs for history is just silly if you have the complete history at your fingertips with git. > One solution that has been proposed before and that was raised again in > this thread is to generate ChangeLogs directly from scm commit messages. > That is already a solution with cvs, so moving to git won't help here. This is not true. One of the main problems of generating ChangeLog messages from cvs/svn is that you don't have much control over the `cvs log` output, cvs itself is extremely slow, and cvs maintains log information *per-file*. Hence ChangeLog generation in the format we want would be slow/impractical. There's tens of thousands of packages. How long do you think it'll take to generate ChangeLogs from cvs for all of them? Notice how every project that did a move to git from cvs/svn started auto-generating ChangeLogs[1]. One reason was that ChangeLogs will *always* cause merge conflicts, and they're duplicate information, so there's no point keeping them in the local tree. The other reason is that with git it takes a fraction of a second to generate a ChangeLog from the commit messages. 1. https://live.gnome.org/Git/ChangeLog > The same objections that have been raised about doing it for cvs, not > being able to use different messages for the commit message and in > ChangeLog (something I understand but admit have hardly used before), > are also valid if we move to git. > Not really. This problem has been raised and the solution is to add a '[trivial]' or '#trivial' etc tag to the commit message (either subject of body), and it won't be included in the auto-generated ChangeLog. The main issue that people have with not writing ChangeLog messages for removals is that developers can't figure out when, why, and by whom an ebuild was removed; because there's no ChangeLog entry, and cvs log/cvs diff is too painful to use. This makes it hard to fix breakage. There's a fringe issue of users wanting to know why an 'old' ebuild was removed while they're offline in a train or something (and don't want to keep a cloned git repo around), but that's not reason enough to kick our second-most-hardworking developer. In essence, the most basic issue here is *not* users who want to have all information offline, but the fact that /developers/ rely on ChangeLog for information because cvs log/diff suck. Note that the developer in question always wrote proper commit messages, so `git log` WOULD solve all our problems. Cheers, -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-02 11:05 ` Nirbheek Chauhan @ 2011-06-02 11:10 ` Ciaran McCreesh 2011-06-02 14:43 ` Rich Freeman 1 sibling, 0 replies; 34+ messages in thread From: Ciaran McCreesh @ 2011-06-02 11:10 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 611 bytes --] On Thu, 2 Jun 2011 16:35:24 +0530 Nirbheek Chauhan <nirbheek@gentoo.org> wrote: > > (c) has irked enough developers and users that people pushed > > council to update the policy about the use of ChangeLogs. > > Yes, and I'm surprised that these same developers pushed towards a > negative solution (kick productive people out) rather than a positive > solution (move to git). Those developers have been pushing for a move to git for years. There comes a point where it becomes necessary to accept that the perfect solution is only the best solution if it will ever happen. -- Ciaran McCreesh [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 198 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-02 11:05 ` Nirbheek Chauhan 2011-06-02 11:10 ` Ciaran McCreesh @ 2011-06-02 14:43 ` Rich Freeman 1 sibling, 0 replies; 34+ messages in thread From: Rich Freeman @ 2011-06-02 14:43 UTC (permalink / raw To: gentoo-dev On Thu, Jun 2, 2011 at 7:05 AM, Nirbheek Chauhan <nirbheek@gentoo.org> wrote: > On Thu, Jun 2, 2011 at 4:59 AM, Jorge Manuel B. S. Vicetto > <jmbsvicetto@gentoo.org> wrote: >> (c) has irked enough developers and users that people pushed council to >> update the policy about the use of ChangeLogs. > > > Yes, and I'm surprised that these same developers pushed towards a > negative solution (kick productive people out) rather than a positive > solution (move to git). Getting developers to follow policy and common sense is a people problem. Git won't fix that - at best it might help with this particular issue but not the next 14 that will come up. I'd highly recommend listening to Donnie's "Assholes are killing your project" talk. I think we've come a long way from some of the problems in the past. I think that speaking up on lists when you don't like a policy is healthy for the distro. However, until policy is changed it must be followed - especially for something as trivial as this. The second-to-last thing I want to see is productive developers quitting Gentoo over policy frustrations. The last thing I want to see is a culture where anybody just does whatever they want to. Such a culture turns off far more potential future developers than it keeps around. Gentoo is already a very hands-off distro - just about any dev can do just about whatever they want to improve things and we all tend to go along with it as long as they're making a positive contribution. OpenRC is stable, some people are talking about getting systemd working and others swear that they'll never run it, others spend time making Gentoo work on everything from Win32 to BSD to Plan9, and others look to improve the hardened/selinux experience. The number of rules that I'd consider "restrictive" in Gentoo is very small compared to more top-down organizations - we all do what we want and the users get to choose with some basic safeguards to preserve the mainstream experience. There really is no reason to pitch a fit over the few rules we have in the big scheme of things. Rich ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:15 ` [gentoo-dev] Re: RFC: better policy for ChageLogs Markos Chandras 2011-06-01 15:27 ` Samuli Suominen @ 2011-06-01 15:30 ` Nathan Phillip Brink 2011-06-01 16:44 ` Duncan 1 sibling, 1 reply; 34+ messages in thread From: Nathan Phillip Brink @ 2011-06-01 15:30 UTC (permalink / raw To: Markos Chandras; +Cc: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1279 bytes --] On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote: > On 01/06/2011 04:08 ????, Peter Volkov wrote: > > ?? ??????, 30/05/2011 ?? 14:55 -0700, Brian Harring ??????????: > >> The problem is, that's a *fuzzy* definition. > > > > Ok, let's start with something and then we'll add more items if > > required. Currently I'd like to propose following text: > > > > The ChangeLog must be updated with each commit. The only possible > > relaxations for this rule are: > > > > 1. Nonfunctional whitespace changes > > 2. Changes in comments (lines starting with # in ebuild, or leading text > > in patches) > > 3. Manifest updates > > 4. Changes in ChageLog itself ;) > > > > Something unclear? Anything else? I think these are reasonable. > > -- > > Peter. > Maybe typos in e{log,warn,info} messages and/or typos in general ( > variables, functions etc ) But typos in variables and functions (which in most cases _imply_ functional changes) are generally bugs which should be mentioned in the ChangeLog. Typos in informational messages (e{log,warn,info}) might also affect the user and thus be `functional' indirectly. I think that the 4-item list is complete enough ;-). -- binki Look out for missing or extraneous apostrophes! [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 34+ messages in thread
* [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 15:30 ` Nathan Phillip Brink @ 2011-06-01 16:44 ` Duncan 2011-06-01 22:59 ` Rich Freeman 0 siblings, 1 reply; 34+ messages in thread From: Duncan @ 2011-06-01 16:44 UTC (permalink / raw To: gentoo-dev Nathan Phillip Brink posted on Wed, 01 Jun 2011 11:30:21 -0400 as excerpted: > On Wed, Jun 01, 2011 at 04:15:31PM +0100, Markos Chandras wrote: >> On 01/06/2011 04:08 ????, Peter Volkov wrote: >> > ?? ??????, 30/05/2011 ?? 14:55 -0700, Brian Harring ??????????: >> >> The problem is, that's a *fuzzy* definition. >> > >> > Ok, let's start with something and then we'll add more items if >> > required. Currently I'd like to propose following text: >> > >> > The ChangeLog must be updated with each commit. The only possible >> > relaxations for this rule are: >> > >> > 1. Nonfunctional whitespace changes >> > 2. Changes in comments (lines starting with # in ebuild, >> > or leading text in patches) >> > 3. Manifest updates >> > 4. Changes in ChageLog itself ;) >> > >> > Something unclear? Anything else? > > I think these are reasonable. Agreed with one exception: Under #2, changes in comment lines, please be specific that commenting a previously uncommented line is NOT a simple comment change and thus not a valid reason to apply this exception. Otherwise we'll (unfortunately) likely be having round #3 of the debate over someone arguing that commenting an epatch line is simply changing a comment... Perhaps (tho better wording is likely possible): 2. Changes in comments (lines starting with # in ebuild, or leading text in patches, except that...) 2a. Commenting an existing line is considered more than a comment change and thus must be changelogged. >> Maybe typos in e{log,warn,info} messages and/or typos in general >> ( variables, functions etc ) > > But typos in variables and functions (which in most cases _imply_ > functional changes) are generally bugs which should be mentioned in the > ChangeLog. Typos in informational messages (e{log,warn,info}) might also > affect the user and thus be `functional' indirectly. I think that the > 4-item list is complete enough ;-). Exactly. Plus... The current "every change" policy goes overboard, I doubt anyone disagrees, but it's worth repeating the point someone else made already, every added exception makes the rule harder to remember. The four numbered exceptions (plus my proposed exception to the exception) above are IMO a reasonable compromise between practicality and simplicity, but getting much more complicated than that and... IMO it's better to stay simple. And in practice I believe it's impossible to define typos to the level it unfortunately appears is now necessary, without either leaving holes big enough to fly a jumbo-jet thru which no doubt someone will then attempt, or complicating the rule beyond the point of simple effectiveness. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 16:44 ` Duncan @ 2011-06-01 22:59 ` Rich Freeman 2011-06-01 23:21 ` [gentoo-dev] " Diego Elio Pettenò ` (2 more replies) 0 siblings, 3 replies; 34+ messages in thread From: Rich Freeman @ 2011-06-01 22:59 UTC (permalink / raw To: gentoo-dev On Wed, Jun 1, 2011 at 12:44 PM, Duncan <1i5t5.duncan@cox.net> wrote: > The current "every change" policy goes overboard, I doubt anyone > disagrees, but it's worth repeating the point someone else made already, > every added exception makes the rule harder to remember. The four > numbered exceptions (plus my proposed exception to the exception) above > are IMO a reasonable compromise between practicality and simplicity, but > getting much more complicated than that and... IMO it's better to stay > simple. I think that we need a simple policy like: Write up Changelogs for any change that impacts what gets installed on our user's computers. Then we can write up some guidelines about how to apply this policy in practice. I think the problem is that we're getting a bit legalistic here. I have no idea why we even needed the policy change. IMHO what should happen is: 1. Dev does something significant and doesn't update a Changelog. 2. QA or another dev calls them on it. Tells them not to do it again. 3. Dev does it again. 4. QA or another dev escalates to devrel. Devrel deals with the issue, resulting in either a dev who takes the rules more seriously or one less dev. What it almost sounds like to me is that step 4 is breaking down. Perhaps somebody is arguing "well, it isn't clear in the rules so you can't do anything to me." To that my only answer is "sure we can!" When it comes to money and taxes we need to have pretty clear rules for legal reasons, but when it comes down to expecting devs to be mature and team players, I don't think that we really need 14 appeals and a team of lawyers to eliminate every loophole in our policies. If a misunderstanding is genuine then everybody should get past it quickly and maybe we update the policy to be more clear. When policies are flaunted despite explanation, and the authority of devrel or QA or whatever and ultimately the council (on appeal) is questioned, then we're not playing like a team. It is amazing what intelligent people can fail to understand when getting something they want depends on it. More rules will never save an organization. Sometimes you need rules, but I think that for a group like Gentoo to work well we need to keep them to a minimum. "Well, that's not written in black and white so I won't cooperate until it is" is no reason for anybody to pause even a moment before escalating. Unclear policies are a reason to assume good intentions - not a reason to overlook obvious bad intentions. You can't solve a people problem with a better algorithm. Just my two cents... That, and in the big scheme of things this is a bit of a tempest in a teapot but I do share concerns that QA is an attitude and small problems today just lead to big ones tomorrow. Rich ^ permalink raw reply [flat|nested] 34+ messages in thread
* [gentoo-dev] Re: Re: RFC: better policy for ChageLogs 2011-06-01 22:59 ` Rich Freeman @ 2011-06-01 23:21 ` Diego Elio Pettenò 2011-06-01 23:29 ` [gentoo-dev] " Dale 2011-06-01 23:40 ` Jorge Manuel B. S. Vicetto 2 siblings, 0 replies; 34+ messages in thread From: Diego Elio Pettenò @ 2011-06-01 23:21 UTC (permalink / raw To: gentoo-dev Il giorno mer, 01/06/2011 alle 18.59 -0400, Rich Freeman ha scritto: > Write up Changelogs for any change that impacts what gets installed on > our user's computers. > This is not really a good approach; Peter's approach is more reliable on this. Let me explain: an EAPI bump _should not_ impact what gets installed. On the other hand, I'd argue it _should_ be in the ChangeLog: a) it is a functional change: it changes _a lot_ the way the package manager sees the ebuild — even though one argues that if the package manager is perfectly compliant the result wouldn't change, it might very well expose a bug in the package manager; b) we can't assume nobody makes mistakes: "it's such a minimal change I cannot have made a mistake" is no way to argue a policy; mistakes are possible by anyone, and any change that is not strictly trivial (whitespace, comments) should be treated as a possible entrypoint for a mistake. -- Diego Elio Pettenò — Flameeyes http://blog.flameeyes.eu/ ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 22:59 ` Rich Freeman 2011-06-01 23:21 ` [gentoo-dev] " Diego Elio Pettenò @ 2011-06-01 23:29 ` Dale 2011-06-01 23:40 ` Jorge Manuel B. S. Vicetto 2 siblings, 0 replies; 34+ messages in thread From: Dale @ 2011-06-01 23:29 UTC (permalink / raw To: gentoo-dev Rich Freeman wrote: > > I think that we need a simple policy like: > Write up Changelogs for any change that impacts what gets installed on > our user's computers. > > Then we can write up some guidelines about how to apply this policy in practice. > > I think the problem is that we're getting a bit legalistic here. I > have no idea why we even needed the policy change. IMHO what should > happen is: > > 1. Dev does something significant and doesn't update a Changelog. > 2. QA or another dev calls them on it. Tells them not to do it again. > 3. Dev does it again. > 4. QA or another dev escalates to devrel. Devrel deals with the > issue, resulting in either a dev who takes the rules more seriously or > one less dev. > > What it almost sounds like to me is that step 4 is breaking down. > Perhaps somebody is arguing "well, it isn't clear in the rules so you > can't do anything to me." To that my only answer is "sure we can!" > When it comes to money and taxes we need to have pretty clear rules > for legal reasons, but when it comes down to expecting devs to be > mature and team players, I don't think that we really need 14 appeals > and a team of lawyers to eliminate every loophole in our policies. If > a misunderstanding is genuine then everybody should get past it > quickly and maybe we update the policy to be more clear. When > policies are flaunted despite explanation, and the authority of devrel > or QA or whatever and ultimately the council (on appeal) is > questioned, then we're not playing like a team. It is amazing what > intelligent people can fail to understand when getting something they > want depends on it. > > More rules will never save an organization. Sometimes you need rules, > but I think that for a group like Gentoo to work well we need to keep > them to a minimum. "Well, that's not written in black and white so I > won't cooperate until it is" is no reason for anybody to pause even a > moment before escalating. Unclear policies are a reason to assume > good intentions - not a reason to overlook obvious bad intentions. > You can't solve a people problem with a better algorithm. > > Just my two cents... That, and in the big scheme of things this is a > bit of a tempest in a teapot but I do share concerns that QA is an > attitude and small problems today just lead to big ones tomorrow. > > Rich > > I'm not a dev, just a user but I do follow this list and read most things posted here. The point of the discussion is this. Someone didn't log something that should have been logged. Even after it was posted that the change is supposed to be logged, the person that didn't think he should log it said the rules didn't say he had to log it. So, it appears that #1, #2 happened but the rules wasn't clear enough so it was changed. I think the point of the discussion is this. The rules wasn't clear enough so they were changed to be much clearer. From my understanding, the NEW rules say if you touch it, log it. Thing is, that seemed to have went to far. So, round two is to smooth out the edges and get it back to what it was except in writing this time. That way, if this happens again, another dev, user, devrel or whatever can point to the rules and settle the argument quickly. It would be nice if when this originally started, the reply would have been "sorry, I didn't realize. It won't happen again". That could have been the end of it and it would have ended loooooong ago. :-) I do agree with your post tho. Sometimes you etch something in stone then realize you misspelled the thing. Dale :-) :-) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: [gentoo-dev] Re: RFC: better policy for ChageLogs 2011-06-01 22:59 ` Rich Freeman 2011-06-01 23:21 ` [gentoo-dev] " Diego Elio Pettenò 2011-06-01 23:29 ` [gentoo-dev] " Dale @ 2011-06-01 23:40 ` Jorge Manuel B. S. Vicetto 2 siblings, 0 replies; 34+ messages in thread From: Jorge Manuel B. S. Vicetto @ 2011-06-01 23:40 UTC (permalink / raw To: gentoo-dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01-06-2011 22:59, Rich Freeman wrote: <snip> > I think the problem is that we're getting a bit legalistic here. I > have no idea why we even needed the policy change. IMHO what should > happen is: > > 1. Dev does something significant and doesn't update a Changelog. > 2. QA or another dev calls them on it. Tells them not to do it again. > 3. Dev does it again. > 4. QA or another dev escalates to devrel. Devrel deals with the > issue, resulting in either a dev who takes the rules more seriously or > one less dev. > > What it almost sounds like to me is that step 4 is breaking down. > Perhaps somebody is arguing "well, it isn't clear in the rules so you > can't do anything to me." To that my only answer is "sure we can!" Rich, besides a disagreement on how to deal with policy issues (as you can read in my proposal to update GLEP48), the issue here is *exactly* that whenever developers or QA warned *repeatedly* the people that don't update ChangeLogs (a very restrict minority of developers), they've always tried to find loopholes in the policy and argued others had no support for their request. About step 4 breaking down, the DevRel process would face the same hurdle as the above, but then there's another important point that people really need to think about: Do we really want to take all technical issues to DevRel and in the limit fire people "only" for that? I'm not saying that technical issues aren't relevant for DevRel or that people can't get "fired" because of them, but in my experience the role of DevRel is more to evaluate the ability and willingness of developers to work in the team than to fire someone because they failed to apply a policy here or there - to be clear, I'm talking here about mistakes and ignorance, not about defiance and disregard for others and policy - which in my view constitute the sort of behaviour patterns that DevRel is meant to evaluate, help fixing and, when everything else fails, to remove. > When it comes to money and taxes we need to have pretty clear rules > for legal reasons, but when it comes down to expecting devs to be > mature and team players, I don't think that we really need 14 appeals > and a team of lawyers to eliminate every loophole in our policies. If > a misunderstanding is genuine then everybody should get past it > quickly and maybe we update the policy to be more clear. When > policies are flaunted despite explanation, and the authority of devrel > or QA or whatever and ultimately the council (on appeal) is > questioned, then we're not playing like a team. It is amazing what > intelligent people can fail to understand when getting something they > want depends on it. The sad fact is that increasingly it seems our developer base, or a significant part of it, is losing all "common sense". > Just my two cents... That, and in the big scheme of things this is a > bit of a tempest in a teapot but I do share concerns that QA is an > attitude and small problems today just lead to big ones tomorrow. > > Rich - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN5s33AAoJEC8ZTXQF1qEPFEcP/2tLhDBXR24AF/GunN5BHKQy +fganpXgO1OqZcFX6tEG7h+j6fjbSFwTPaNG9CiSyrz/NsYseuL7wzkxXZawfUax ftiaFuOuKvLd56AizO0y0YNfrvIVxp2rTPas17yg+Noqgm3Hd5voh2J9FkN3x8X9 PPd8yA8f4DXA4ptdihGS694edtDtT2WwMVGbPuGl6I3U0tlLYlPyGoQDRaAhvQoB LnOzqrYxFxDxcEUWyae25dp3DI1rhqWw8cUc1We6lOZENOtGxiLuxToIorVB8lAs b3SB326WI5XJRyHWgWtcPkF9OrQvpsDXgO9YEqBbsXn3w6vsj2rD8IeswMGNt66R h4cmHEwXEyZ9iQPEPwJKi/UI6MZHTM5ezYJDAbBxBuLt5dPuR7RQBspHkyjSSFe8 /RPLDYy0UYnh0uUw1Rq7DCB5rhLf9acnGhT247q+5PNMcfdN3aBYPIK2ruqTQGKD SfNefj0tKJCXd/TsQUSn7GP7SLjiBNh7Ym+qy8Q5TFQs49vhYprbqRn6RdsMpPe6 eeHNiNzSw9Cfi6n/ZidHlvOXUM7g2yVOLzJ9ChzZRhftxABMWMJCzYvQfjE6Eqey +pVX372nI2G9e9UErS8/Zfxxxw/+vOE7DLLYKe9HSXeM3XdNwEzotdcN+Xxth3f/ R5tVPjMUL3TACOcqA/zr =vsto -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2011-06-02 15:04 UTC | newest] Thread overview: 34+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-17 10:32 [gentoo-dev] Council May Summary: Changes to ChangeLog handling Petteri Räty 2011-05-20 10:19 ` Mart Raudsepp 2011-05-30 12:03 ` Peter Volkov 2011-05-30 12:23 ` Ulrich Mueller 2011-05-30 18:07 ` William Hubbs 2011-05-30 17:52 ` Michał Górny 2011-05-30 21:55 ` Brian Harring 2011-05-30 22:05 ` Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling) Andreas K. Huettel 2011-05-30 22:14 ` [gentoo-dev] Re: Common sense in " Diego Elio Pettenò 2011-05-30 23:38 ` Common sense in [gentoo-dev] " Brian Harring 2011-05-31 0:01 ` Ângelo Arrifano 2011-06-01 15:08 ` RFC: better policy for ChageLogs (was: Re: [gentoo-dev] " Peter Volkov 2011-06-01 15:15 ` [gentoo-dev] Re: RFC: better policy for ChageLogs Markos Chandras 2011-06-01 15:27 ` Samuli Suominen 2011-06-01 15:34 ` Ciaran McCreesh 2011-06-02 11:21 ` Jorge Manuel B. S. Vicetto 2011-06-01 15:39 ` Andreas K. Huettel [not found] ` <BANLkTimgHYKnfbeQJpq829YBeE-5Yz=aEg@mail.gmail.com> 2011-06-01 16:24 ` Andreas K. Huettel 2011-06-01 19:50 ` Nirbheek Chauhan 2011-06-01 23:29 ` Jorge Manuel B. S. Vicetto 2011-06-01 23:37 ` Matt Turner 2011-06-02 5:09 ` Peter Volkov 2011-06-02 7:29 ` Duncan 2011-06-02 7:40 ` Eray Aslan 2011-06-02 11:20 ` Patrick Lauer 2011-06-02 11:05 ` Nirbheek Chauhan 2011-06-02 11:10 ` Ciaran McCreesh 2011-06-02 14:43 ` Rich Freeman 2011-06-01 15:30 ` Nathan Phillip Brink 2011-06-01 16:44 ` Duncan 2011-06-01 22:59 ` Rich Freeman 2011-06-01 23:21 ` [gentoo-dev] " Diego Elio Pettenò 2011-06-01 23:29 ` [gentoo-dev] " Dale 2011-06-01 23:40 ` Jorge Manuel B. S. Vicetto
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox