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 05-17-2011, 10:32 AM
Petteri Rty
 
Default Council May Summary: Changes to ChangeLog handling

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
 
Old 05-20-2011, 10:19 AM
Mart Raudsepp
 
Default Council May Summary: Changes to ChangeLog handling

Hello,

On T, 2011-05-17 at 13:32 +0300, Petteri Rty 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
 
Old 05-30-2011, 12:03 PM
Peter Volkov
 
Default Council May Summary: Changes to ChangeLog handling

В Птн, 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.
 
Old 05-30-2011, 12:23 PM
Ulrich Mueller
 
Default Council May Summary: Changes to ChangeLog handling

>>>>> 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
 
Old 05-30-2011, 05:52 PM
Michał Górny
 
Default Council May Summary: Changes to ChangeLog handling

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
 
Old 05-30-2011, 06:07 PM
William Hubbs
 
Default Council May Summary: Changes to ChangeLog handling

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
 
Old 05-30-2011, 09:55 PM
Brian Harring
 
Default Council May Summary: Changes to ChangeLog handling

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
 

Thread Tools




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

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