В Сбт, 30/04/2011 в 12:02 +0300, Samuli Suominen пишет:
> On 04/30/2011 11:46 AM, Petteri Räty wrote:
> > I propose a simple new text: "Every commit should have an entry in
> > ChangeLog."

Nonfunctional commits should not be recored in ChangeLog. Personally I
quite frequently add URLs of upstream bug reports in ChangeLog. I don't
think this addition should be recorded in ChangeLog.

> > If we eventually autogenerate them from git logs this would
> > happen any way (unless some kind of filtering system is in the middle)
> > so we could already start now.

Without filtering system ChangeLogs are useless. Also I need some way to
edit ChangeLogs manually.

> "Every new file, and modification to existing file should have an entry
> in ChangeLog." to skip the proper ChangeLog-less removals.

Removal is quite functional change so it should be recored.

--
Peter.

Il giorno sab, 30/04/2011 alle 11.07 +0200, Ulrich Mueller ha scritto:
>
> I won't clutter ChangeLogs with useless entries for whitespace changes
> or spelling fixes in comments, for example. They already account for a
> considerable (too large?) percentage of the portage tree [1], and we
> shouldn't blow them up further by adding useless information.

If you read the last paragraph in my suggestion was to cycle the logs...

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote:
> If you read the last paragraph in my suggestion was to cycle the logs...
Maybe this would be better together with a mechanism (automatic?) to keep the
complete ChangeLogs (as they are now) somewhere (but not in the main
tree). Sometimes, full history/ChangeLog can be useful, eg. when you
want to see quickly how old a package in the tree is, or find bug numbers of
fixes you may want to recheck etc etc.

--
Panagiotis Christopoulos ( pchrist )
( Gentoo Lisp Project )

On Sat, Apr 30, 2011 at 12:02:35PM +0300, Samuli Suominen wrote:
> On 04/30/2011 11:46 AM, Petteri Räty wrote:
> > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
> >
> > There doesn't seem to be a common opinion on what the policy for
> > ChangeLog entries is. See:
> >
> > http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml
> >
> > I propose a simple new text: "Every commit should have an entry in
> > ChangeLog." If we eventually autogenerate them from git logs this would
> > happen any way (unless some kind of filtering system is in the middle)
> > so we could already start now. I think it's better to have more than
> > less information available to users.
> >
> > Regards,
> > Petteri
> >
>
> "Every new file, and modification to existing file should have an entry
> in ChangeLog." to skip the proper ChangeLog-less removals.
>
I am actually with Samuli on this. Unless there is a particular reason
for removing a package, I don't see any point of documenting this change anywhere.
What difference would it make to you if you see an entry " -foo-1.0
old". It makes absolutely no sense.

Regards,
--
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

On 4/30/11 3:05 PM, Panagiotis Christopoulos wrote:
> On 14:28 Sat 30 Apr , Diego Elio Pettenò wrote:
>> If you read the last paragraph in my suggestion was to cycle the logs...
> Maybe this would be better together with a mechanism (automatic?) to keep the
> complete ChangeLogs (as they are now) somewhere (but not in the main
> tree). Sometimes, full history/ChangeLog can be useful, eg. when you
> want to see quickly how old a package in the tree is, or find bug numbers of
> fixes you may want to recheck etc etc.

Seconded. I sometimes read entire ChangeLogs, for example for abandoned
packages or packages I suspect to be abandoned, sometimes I read them
for fun, and so on.

I'm fine with shipping a trimmed down versions to users, but I think the
full version must be easy to access.

A possible solution would be to truncate the logs in the cvs->rsync
migration.

On Sat, Apr 30, 2011 at 9:44 AM, "Paweł Hajdan, Jr."
<phajdan.jr@gentoo.org> wrote:
> I'm fine with shipping a trimmed down versions to users, but I think the
> full version must be easy to access.

If the changelogs were accessible via a predicable URL then a simple
command-line tool or portage option might display them on request.
echangeinfo cat/pkg is probably no harder for the average end-user to
type than less /usr/portage/cat/pkg/ChangeLog.

Rich

On Sat, Apr 30, 2011 at 02:42:08PM +0100, Markos Chandras wrote:
> I am actually with Samuli on this. Unless there is a particular reason
> for removing a package, I don't see any point of documenting this change anywhere.
> What difference would it make to you if you see an entry " -foo-1.0
> old". It makes absolutely no sense.

Removing versions has implications for the depgraph which make having
it documented locally fairly required. Broken dependencies is the
usual example, (consider developmental profiles), but it gets nastier
than that; consider a pkg depping on
|| ( =foo-1.0 !block-some-other-crap )

Yes that's a screwed up dep, but people come up with some weird
stuff- the point either way is that removal of 1.0 can have
implications beyond just the perceived cleanup. Usage of --force in
conjunction with it makes it worse.

Not opposed to pruning the logs (every few years we seem to go cleanup
the offenders), but removals *matter* for the depgraph, thus
have been required to be documented long term.

~harrng

On Sat, Apr 30, 2011 at 02:42:08PM +0100, Markos Chandras wrote:
> On Sat, Apr 30, 2011 at 12:02:35PM +0300, Samuli Suominen wrote:
> > On 04/30/2011 11:46 AM, Petteri Räty wrote:
> > > http://devmanual.gentoo.org/ebuild-writing/misc-files/changelog/index.html
> > >
> > > There doesn't seem to be a common opinion on what the policy for
> > > ChangeLog entries is. See:
> > >
> > > http://archives.gentoo.org/gentoo-dev/msg_f829da2375f1ceab766a800913cc4998.xml
> > >
> > > I propose a simple new text: "Every commit should have an entry in
> > > ChangeLog." If we eventually autogenerate them from git logs this would
> > > happen any way (unless some kind of filtering system is in the middle)
> > > so we could already start now. I think it's better to have more than
> > > less information available to users.
> > >
> > > Regards,
> > > Petteri
> > >
> >
> > "Every new file, and modification to existing file should have an entry
> > in ChangeLog." to skip the proper ChangeLog-less removals.
> >
> I am actually with Samuli on this. Unless there is a particular reason
> for removing a package, I don't see any point of documenting this change anywhere.
> What difference would it make to you if you see an entry " -foo-1.0
> old". It makes absolutely no sense.

There are times when you need to know where a version went. That alone
is enough to warrant updating the ChangeLog.

Having to check a second place through a slow interface sucks

--
Alex Alexander | wired
+ Gentoo Linux Developer
++ www.linuxized.com

On 12:02 Sat 30 Apr , Samuli Suominen wrote:
>
> "Every new file, and modification to existing file should have an entry
> in ChangeLog." to skip the proper ChangeLog-less removals.

There is something I can't undestand reading all the previous
discussions. You disagree with logging removals only because you don't
like the idea (you think it's useless information) or also because if
this becomes a policy, it will increase more the size of ChangeLogs? You
(and others) would still be negative if the problem with sizes etc. was
solved somehow?

--
Panagiotis Christopoulos ( pchrist )
( Gentoo Lisp Project )

On 04/30/2011 11:39 PM, Panagiotis Christopoulos wrote:
> On 12:02 Sat 30 Apr , Samuli Suominen wrote:
>>
>> "Every new file, and modification to existing file should have an entry
>> in ChangeLog." to skip the proper ChangeLog-less removals.
>
> There is something I can't undestand reading all the previous
> discussions. You disagree with logging removals only because you don't
> like the idea (you think it's useless information) or also because if
> this becomes a policy, it will increase more the size of ChangeLogs? You
> (and others) would still be negative if the problem with sizes etc. was
> solved somehow?
>

No, but because of the quantity of commits[1] as a result of maintaining
subset of issues tree wide at once (like libpng, jpeg, libnotify, *kit,
u{disks,power}, lcms, fixing missing includes due to toolchain changes,
adding some consts, imagine the rest ...)

... the time alone if you have to stop on each package to wait for
echangelog to get done just doubles the amount of time you have to put
into committing them. That's just not worth the effort.

So not only they are rather useless, and information you can easily get
from sources.gentoo.org, they take your time as well.