FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-01-2011, 03:27 PM
Samuli Suominen
 
Default RFC: better policy for ChageLogs

On 06/01/2011 06:15 PM, Markos Chandras wrote:
> On 01/06/2011 04:08 ¼¼, Peter Volkov wrote:
>>  =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
 
Old 06-01-2011, 03:30 PM
Nathan Phillip Brink
 
Default RFC: better policy for ChageLogs

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!
 
Old 06-01-2011, 03:34 PM
Ciaran McCreesh
 
Default RFC: better policy for ChageLogs

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
 
Old 06-01-2011, 03:39 PM
"Andreas K. Huettel"
 
Default RFC: better policy for ChageLogs

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/
 
Old 06-01-2011, 04:02 PM
Nirbheek Chauhan
 
Default RFC: better policy for ChageLogs

On Wed, Jun 1, 2011 at 9:09 PM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> 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...
>

So we come back to the problem being *CVS* not ChangeLog rules.

All this is such a massive waste of time. Can't we just expend this
energy on the move to git?


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team
 
Old 06-01-2011, 04:24 PM
"Andreas K. Huettel"
 
Default RFC: better policy for ChageLogs

> 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/
 
Old 06-01-2011, 04:44 PM
Duncan
 
Default RFC: better policy for ChageLogs

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
 
Old 06-01-2011, 07:50 PM
Nirbheek Chauhan
 
Default RFC: better policy for ChageLogs

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
 
Old 06-01-2011, 10:59 PM
Rich Freeman
 
Default RFC: better policy for ChageLogs

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
 
Old 06-01-2011, 11:21 PM
Diego Elio Pettenò
 
Default RFC: better policy for ChageLogs

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/
 

Thread Tools




All times are GMT. The time now is 07:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org