[gentoo-dev] Council May Summary: Changes to ChangeLog handling

[gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Petteri Räty]

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

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Mart Raudsepp]

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

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Peter Volkov]

В Птн, 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.

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Ulrich Mueller]

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

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Michał Górny]

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

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[William Hubbs]

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

Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling

[Brian Harring]

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

Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling)

[Andreas K. Huettel]

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

[gentoo-dev] Re: Common sense in (was Council May Summary: Changes to ChangeLog handling)

[Diego Elio Pettenò]

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/

Re: Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling)

[Brian Harring]

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

Re: Common sense in [gentoo-dev] (was Council May Summary: Changes to ChangeLog handling)

[Ângelo Arrifano]

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

RFC: better policy for ChageLogs (was: Re: [gentoo-dev] Council May Summary: Changes to ChangeLog handling)

[Peter Volkov]

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

[gentoo-dev] Re: RFC: better policy for ChageLogs

[Markos Chandras]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Samuli Suominen]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Nathan Phillip Brink]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Ciaran McCreesh]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Andreas K. Huettel]

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/

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Andreas K. Huettel]

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

[gentoo-dev] Re: RFC: better policy for ChageLogs

[Duncan]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Nirbheek Chauhan]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Rich Freeman]

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

[gentoo-dev] Re: Re: RFC: better policy for ChageLogs

[Diego Elio Pettenò]

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/

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Dale]

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

:-)  :-)

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Jorge Manuel B. S. Vicetto]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Jorge Manuel B. S. Vicetto]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Peter Volkov]

В Срд, 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.

[gentoo-dev] Re: RFC: better policy for ChageLogs

[Duncan]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Eray Aslan]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Nirbheek Chauhan]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Ciaran McCreesh]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Patrick Lauer]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Jorge Manuel B. S. Vicetto]

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

Re: [gentoo-dev] Re: RFC: better policy for ChageLogs

[Rich Freeman]

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