gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

On 09/11/2010 01:39 AM, Arfrever Frehtes Taifersar Arahesis (arfrever)
wrote:
> arfrever 10/09/10 22:39:27
>
> Modified: ChangeLog
> Added: hachoir-parser-1.3.4.ebuild
> Log:
> Version bump.
>
> (Portage version: 2.2_rc79_p5/cvs/Linux x86_64)
>
> Revision Changes Path
> 1.8 dev-python/hachoir-parser/ChangeLog
>
> file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/hachoir-parser/ChangeLog?rev=1.8&view=markup
> plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/hachoir-parser/ChangeLog?rev=1.8&content-type=text/plain
> diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-python/hachoir-parser/ChangeLog?r1=1.7&r2=1.8
>
> Index: ChangeLog
> ================================================== =================
> RCS file: /var/cvsroot/gentoo-x86/dev-python/hachoir-parser/ChangeLog,v
> retrieving revision 1.7
> retrieving revision 1.8
> diff -u -r1.7 -r1.8
> --- ChangeLog 17 Apr 2010 21:32:00 -0000 1.7
> +++ ChangeLog 10 Sep 2010 22:39:27 -0000 1.8
> @@ -1,6 +1,12 @@
> # ChangeLog for dev-python/hachoir-parser
> # Copyright 1999-2010 Gentoo Foundation; Distributed under the GPL v2
> -# $Header: /var/cvsroot/gentoo-x86/dev-python/hachoir-parser/ChangeLog,v 1.7 2010/04/17 21:32:00 arfrever Exp $
> +# $Header: /var/cvsroot/gentoo-x86/dev-python/hachoir-parser/ChangeLog,v 1.8 2010/09/10 22:39:27 arfrever Exp $
> +
> +*hachoir-parser-1.3.4 (10 Sep 2010)
> +
> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis <arfrever@gentoo.org>
> + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
> + Version bump.
>

Deleting an older version is relevant so it should also be mentioned in
the ChangeLog message.

gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

On Sat, 11 Sep 2010 22:10:51 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:

> > +
> > +*hachoir-parser-1.3.4 (10 Sep 2010)
> > +
> > + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis <arfrever@gentoo.org>
> > + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
> > + Version bump.
> >
>
> Deleting an older version is relevant so it should also be mentioned in
> the ChangeLog message.

It says -hachoir-parser-1.3.3.ebuild. What exactly do you think would be
gained by adding "Remove old" in this case?

The only time it's really necessary IMO is when it's the only change you're
making.


--
fonts, gcc-porting, we hold our breath, we spin around the world
toolchain, wxwidgets you and me cling to the outside of the earth
@ gentoo.org EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

On 09/11/2010 11:14 PM, Ryan Hill wrote:
> On Sat, 11 Sep 2010 22:10:51 +0300
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>
>>> +
>>> +*hachoir-parser-1.3.4 (10 Sep 2010)
>>> +
>>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis <arfrever@gentoo.org>
>>> + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
>>> + Version bump.
>>>
>>
>> Deleting an older version is relevant so it should also be mentioned in
>> the ChangeLog message.
>
> It says -hachoir-parser-1.3.3.ebuild. What exactly do you think would be
> gained by adding "Remove old" in this case?
>

Following your logic we should not write "Version bump" either (as
that's what happens by default when you add a new ebuild).

Regards,
Petteri

gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

On Saturday 11 of September 2010 22:18:32 Petteri Räty wrote:
> On 09/11/2010 11:14 PM, Ryan Hill wrote:
> > On Sat, 11 Sep 2010 22:10:51 +0300
> >
> > Petteri Räty <betelgeuse@gentoo.org> wrote:
> >>> +
> >>> +*hachoir-parser-1.3.4 (10 Sep 2010)
> >>> +
> >>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
> >>> <arfrever@gentoo.org> + -hachoir-parser-1.3.3.ebuild,
> >>> +hachoir-parser-1.3.4.ebuild: + Version bump.
> >>
> >> Deleting an older version is relevant so it should also be mentioned in
> >> the ChangeLog message.
> >
> > It says -hachoir-parser-1.3.3.ebuild. What exactly do you think would be
> > gained by adding "Remove old" in this case?
>
> Following your logic we should not write "Version bump" either (as
> that's what happens by default when you add a new ebuild).

Considering the fact, that ChangeLogs are files that contribute to rsync/cvs
fetch the most, it's not that bad idea...

--
regards
MM

gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

On 09/11/2010 11:20 PM, Maciej Mrozowski wrote:
> On Saturday 11 of September 2010 22:18:32 Petteri Räty wrote:
>> On 09/11/2010 11:14 PM, Ryan Hill wrote:
>>> On Sat, 11 Sep 2010 22:10:51 +0300
>>>
>>> Petteri Räty <betelgeuse@gentoo.org> wrote:
>>>>> +
>>>>> +*hachoir-parser-1.3.4 (10 Sep 2010)
>>>>> +
>>>>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
>>>>> <arfrever@gentoo.org> + -hachoir-parser-1.3.3.ebuild,
>>>>> +hachoir-parser-1.3.4.ebuild: + Version bump.
>>>>
>>>> Deleting an older version is relevant so it should also be mentioned in
>>>> the ChangeLog message.
>>>
>>> It says -hachoir-parser-1.3.3.ebuild. What exactly do you think would be
>>> gained by adding "Remove old" in this case?
>>
>> Following your logic we should not write "Version bump" either (as
>> that's what happens by default when you add a new ebuild).
>
> Considering the fact, that ChangeLogs are files that contribute to rsync/cvs
> fetch the most, it's not that bad idea...
>

ChangeLog not changing at all would probably save traffic there but even
without no custom message there's still the echangelog generated part
about changed files.

Regards,
Petteri

gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

Petteri Räty posted on Sat, 11 Sep 2010 23:18:32 +0300 as excerpted:

> On 09/11/2010 11:14 PM, Ryan Hill wrote:
>> On Sat, 11 Sep 2010 22:10:51 +0300
>> Petteri Räty <betelgeuse@gentoo.org> wrote:
>>
>>>> +
>>>> +*hachoir-parser-1.3.4 (10 Sep 2010)
>>>> +
>>>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis
>>>> <arfrever@gentoo.org>
>>>> + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
>>>> + Version bump.
>>>>
>>> Deleting an older version is relevant so it should also be mentioned
>>> in the ChangeLog message.
>>
>> It says -hachoir-parser-1.3.3.ebuild. What exactly do you think would
>> be gained by adding "Remove old" in this case?
>>
> Following your logic we should not write "Version bump" either (as
> that's what happens by default when you add a new ebuild).

You omitted the exception bit of the quote. Let me re-add it:

>> The only time it's really necessary IMO is when it's the only change
>> you're making.

So if there's other logged changes, yeah, omit "Version bump" as well.
It's redundant. But if it's the only change, by his logic, which as a
regular changelog reader I agree with, either "Version bump" or "Remove
old" should remain so there's at least some human entered message.

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

gentoo-x86 commit in dev-python/hachoir-parser: ChangeLog hachoir-parser-1.3.4.ebuild
 

В В�к, 12/09/2010 в 17:01 +0300, Mart Raudsepp пишет:
> On L, 2010-09-11 at 23:18 +0300, Petteri Räty wrote:
> > On 09/11/2010 11:14 PM, Ryan Hill wrote:
> > > On Sat, 11 Sep 2010 22:10:51 +0300
> > > Petteri Räty <betelgeuse@gentoo.org> wrote:
> > >
> > >>> +
> > >>> +*hachoir-parser-1.3.4 (10 Sep 2010)
> > >>> +
> > >>> + 10 Sep 2010; Arfrever Frehtes Taifersar Arahesis <arfrever@gentoo.org>
> > >>> + -hachoir-parser-1.3.3.ebuild, +hachoir-parser-1.3.4.ebuild:
> > >>> + Version bump.

> That's why I tend to spend the time to briefly summarize what the
> version bump actually improves for users by upstream (see my gstreamer
> bumps for example). I spend the time once, thousands of users get the
> information handily with emerge --changelog and the like, without
> digging into /usr/share/doc/*/NEWS* _after_ upgrading and already having
> had to do the work to decide if its important upgrade for them or not
> (in case of conservative upgrading).

This ether should became common practice or it'll stay useless and even
harmful. It's hard to anticipate upstream NEWS in our ChangeLogs since
very few packages do this and as I see logic behind our ChangeLogs they
are intended for changes in our package (ebuilds), not for upstream
changes. At the same time this additional information makes our
ChangeLogs harder to read and find out what was changed in ebuild and
why. That said I think it's really useful to have this information with
rsync but it's better come with different solution instead of utilizing
package's ChangeLogs...

--
Peter.