[gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

I'm summarising this thread [0] for the upcoming council meeting.


Automatic ChangeLog generation

Some people have expressed disagreement with committing ChangeLog
updates for some changes.  Discussion on that lead to an updated policy
to document nearly all changes.  Some people still really disagree with
that and go as far to commit dummy placeholders just to make sure they
don't do what they deem is useless for everybody.

ChangeLog generation is often suggested as a solution to this by those
people who do not like to document their changes in the ChangeLog file.

Auto generation of ChangeLogs, implies changes, and also influences how
current ChangeLog information is to be handled.
What if auto-generation is done, what does it take?

- what messages to include (all?), what not to include (ignore some?)
-- ignore some messages, git: Commit Limiting ([trivial]) [1][3]
--- policy? what to ignore, what not? what does the current policy mean
    if commits can be made to be ignored?
-- only include messages for a time range, or relevant messages for
   current files (ebuilds) in the directory (package) [3]

= balance between hard policy effectuated by the generation and fuzzy
  control via keywords that is subject to the interpretation of the
  committer
= opening for new opportunities to safe space for and present more
  relevant information to our users

- inability to edit changelog entries (make corrections)
-- git: git notes --help -> append notes to commit msgs [1]
-- not a real issue [3]

= balance between either allowing it through complex scripting, or just
  ignoring the ability at all since it is rarely used and not done by
  others either ([3])

- history, ChangeLogs are often more useful than the CVS logs
-- retain existing ChangeLog and append? [1]
--- use setup with separate git repo for ChangeLogs [2]
--- auto-generate if non-existent (per maintainer pref) [3]
-- just forget it, it's old [3]

= balance between either retaining the original information, or
  forgetting about it completely since it is likely outdated information
  anyway -- note: this is only about differences in CVS log and
  ChangeLog
= balance between generating all ChangeLogs, or just those whose
  maintainer likes it


Generating ChangeLog opens opportunities (only commit, limit contents,
consistency), and can ease the life of developers.  However, the
currently existing ChangeLog files might differ from a generated one
from VCS logs significantly, if this is considered important, a strategy
for retaining the old messages has to be deployed (keep ChangeLog file,
store ChangeLog in separate repo, selectively retain ChangeLog files per
package).

If a ChangeLog is generated, are all commits to show up in them, or can
certain messages be ignored?  The latter requires specification of how,
but also when.  Updating a ChangeLog file is close to such situation
without policies.  Since commit messages cannot be changed, are methods
necessary to add notices to messages when they appear wrong/incorrect?

Should ChangeLogs be generated?
If yes
- should all commit message be included
- should commit messages be appended to/updated?
- should existing information in ChangeLog files be retained?


[0] http://archives.gentoo.org/gentoo-dev/msg_2ff02d6910d797045af3659fb21c712f.xml
[1] http://archives.gentoo.org/gentoo-dev/msg_934d783d619540a2e97725da7e767253.xml
[2] (not on archives.g.o and gmane) http://www.gossamer-threads.com/lists/gentoo/dev/231903?do=post_view_threaded 
[3] http://archives.gentoo.org/gentoo-dev/msg_3156112af9944a6c8736159247275ccb.xml



On 02-06-2011 11:13:38 +0200, Fabian Groffen wrote:
> Following up on the recent discussions about ChangeLogs, and what should
> be in there, versus what not, this email tries to describe the pros and
> cons of the frequently mentioned generation of ChangeLogs from the VCS
> we use.
> 
> I would like the council to discuss the generation of ChangeLogs from
> the VCS in the next meeting for which this message is in time.  I prefer
> the council to decide upon whether or not generation of ChangeLogs is
> desirable for Gentoo or not.  In this email, I will try to describe the
> pros and cons, but I invite anyone else to contribute/discuss ideas.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

On 22:16 Mon 01 Aug     , Fabian Groffen wrote:
> Auto generation of ChangeLogs, implies changes, and also influences 
> how current ChangeLog information is to be handled. What if 
> auto-generation is done, what does it take?

For the purposes of a council meeting, I think we should construct a 
small set of specific proposals to choose from so we don't get mired in 
endless discussions during the meeting.

I'd like to offer a couple of them for us to choose between.

1. Include all commits, don't retroactively change existing ChangeLog 
messages

2. Allow commit filtering, don't retroactively change existing ChangeLog 
messages

- Filters to allow: keywording, stabilization, removal of ebuilds. 
Whoever implements the code can decide on the format of said filters.


Do any council members feel strongly that we should include additional 
options, or is it good enough to just make a choice on these two?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 03-08-2011 10:43:10 -0700, Donnie Berkholz wrote:
> On 22:16 Mon 01 Aug     , Fabian Groffen wrote:
> > Auto generation of ChangeLogs, implies changes, and also influences 
> > how current ChangeLog information is to be handled. What if 
> > auto-generation is done, what does it take?
> 
> For the purposes of a council meeting, I think we should construct a 
> small set of specific proposals to choose from so we don't get mired in 
> endless discussions during the meeting.
> 
> I'd like to offer a couple of them for us to choose between.
> 
> 1. Include all commits, don't retroactively change existing ChangeLog 
> messages
> 
> 2. Allow commit filtering, don't retroactively change existing ChangeLog 
> messages
> 
> - Filters to allow: keywording, stabilization, removal of ebuilds. 
> Whoever implements the code can decide on the format of said filters.
> 
> 
> Do any council members feel strongly that we should include additional 
> options, or is it good enough to just make a choice on these two?

I listed the questions I think are relevant at the bottom of my mail.  I
feel you forgot the most important one: should ChangeLogs be
auto-generated at all?.  Only if yes,
- should all commit messages be included (sort of first part of your 1
  and 2)
- should commit messages be appended to/updated? (sort of last part of
  your 1 and 2)
- should existing information in ChangeLog files be retained?

I have the impression that any detail on how and what can only be dealt
with after it is clear what the majority of the council members lean
towards.  E.g. useless to list and discuss a big variety of filters if
there is no support for allowing them at all.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

On 19:56 Wed 03 Aug     , Fabian Groffen wrote:
> On 03-08-2011 10:43:10 -0700, Donnie Berkholz wrote:
> > On 22:16 Mon 01 Aug     , Fabian Groffen wrote:
> > > Auto generation of ChangeLogs, implies changes, and also influences 
> > > how current ChangeLog information is to be handled. What if 
> > > auto-generation is done, what does it take?
> > 
> > For the purposes of a council meeting, I think we should construct a 
> > small set of specific proposals to choose from so we don't get mired in 
> > endless discussions during the meeting.
> > 
> > I'd like to offer a couple of them for us to choose between.
> > 
> > 1. Include all commits, don't retroactively change existing ChangeLog 
> > messages
> > 
> > 2. Allow commit filtering, don't retroactively change existing ChangeLog 
> > messages
> > 
> > - Filters to allow: keywording, stabilization, removal of ebuilds. 
> > Whoever implements the code can decide on the format of said filters.
> > 
> > 
> > Do any council members feel strongly that we should include additional 
> > options, or is it good enough to just make a choice on these two?
> 
> I listed the questions I think are relevant at the bottom of my mail.  I
> feel you forgot the most important one: should ChangeLogs be
> auto-generated at all?.  Only if yes,

Yeah, that's already on my draft agenda [1]. =) But we should still have 
a small set of options to choose from if we do vote to automate, so we 
don't sit around for another month or discuss it aimlessly for hours. 
Being prepared is what I'm hoping we can do here.

> I have the impression that any detail on how and what can only be 
> dealt with after it is clear what the majority of the council members 
> lean towards.  E.g. useless to list and discuss a big variety of 
> filters if there is no support for allowing them at all.


1. http://dev.gentoo.org/~dberkholz/20110809_agenda.txt

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 08/03/2011 06:56 PM, Fabian Groffen wrote:
> On 03-08-2011 10:43:10 -0700, Donnie Berkholz wrote:
>> On 22:16 Mon 01 Aug     , Fabian Groffen wrote:
>>> Auto generation of ChangeLogs, implies changes, and also
>>> influences how current ChangeLog information is to be handled.
>>> What if auto-generation is done, what does it take?
>> 
>> For the purposes of a council meeting, I think we should construct
>> a small set of specific proposals to choose from so we don't get
>> mired in endless discussions during the meeting.
>> 
>> I'd like to offer a couple of them for us to choose between.
>> 
>> 1. Include all commits, don't retroactively change existing
>> ChangeLog messages
>> 
>> 2. Allow commit filtering, don't retroactively change existing
>> ChangeLog messages
>> 
>> - Filters to allow: keywording, stabilization, removal of ebuilds.
>>  Whoever implements the code can decide on the format of said
>> filters.
>> 
>> 
>> Do any council members feel strongly that we should include
>> additional options, or is it good enough to just make a choice on
>> these two?
> 
> I listed the questions I think are relevant at the bottom of my mail.
> I feel you forgot the most important one: should ChangeLogs be 
> auto-generated at all?.  Only if yes,

I am a bit confused. I though that the previous council had already
approved the automated changelog generation[1]

[1]: http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt


- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBCgAGBQJOOZBvAAoJEPqDWhW0r/LC7o8P/2QQKFm8RX+p0bd2O12UErKY
8v93pmjhflATLI7l6HCVjfu8GrLMWDcBq/CTRob/bZG3MjZ0rWKYV2KLHaQBssyD
zehdjVxzb6w4NopNs+ChxUgPaeOsJmHP+PzhErWZZYPS4Co4U8hrQ0YVaZsb2XC4
cHgCVCJPSmKdHjFp8GBi6vjIz70hAx731oY8i314jQH0B3VlB0BDzXqdX2pX4jp7
yl3pOhUJTzcU4hJQI3fSiYzsXuD7+rH1B4l62+/qiCQggLSG6NSxlKf8hxI8Go4Z
moIG/5lT8LR0jm/CLnnOrPKx3wt6VtK2Ysas0q39ixEn7i7Mi1+zF2iZg9+49E9U
K2Dlmsae5y1KGWKXeHbuaYkfrc+n7mGTXH1CSiL3YBjSeUvbL9Yx4htOtU+JkqKl
rSsQGyFUC2e1Qz+V/iIsxpChZtzcaNCPsd5JID2A93f+liiW0XBbeWa90DADDBUW
c3SStxHc1Kh7wAZvd7nVLYXwQGmV7l3lQ6oL43dNzQ2Sgv31Ry91e1+Ci2iqEnwS
hddZU9A6dqmnFG59p7WotPmT668adVH/L1UoHc2D6uq1HLHcBP6omtJWGHvxoJ8c
bTM2MTe9L5qQlvv1drwnly9RlQpZC5s9UdmcwnIsRIUn6mRoUC4GW54blXomefcT
F0NdrZsiDYI9QYrjk9IE
=iKn8
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 03-08-2011 19:16:15 +0100, Markos Chandras wrote:
> > I listed the questions I think are relevant at the bottom of my mail.
> > I feel you forgot the most important one: should ChangeLogs be 
> > auto-generated at all?.  Only if yes,
> 
> I am a bit confused. I though that the previous council had already
> approved the automated changelog generation[1]
> 
> [1]: http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt

The above link references the original thread on auto-generation of
ChangeLogs, but it doesn't decide on anything at all about it.  The
discussion was mainly focussed on policies and temporary workarounds.

The topic as it is presented in the original thread is about what
choices to make when generating, which greatly influences the efforts it
needs to be implemented.

I hope it will allow us to perhaps even start auto-generating ChangeLogs
today, that is, right now, and not just only when we switch to the next
VCS.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 03-08-2011 11:09:07 -0700, Donnie Berkholz wrote:
> > > 1. Include all commits, don't retroactively change existing ChangeLog 
> > > messages
> > > 
> > > 2. Allow commit filtering, don't retroactively change existing ChangeLog 
> > > messages
> > > 
> > > - Filters to allow: keywording, stabilization, removal of ebuilds. 
> > > Whoever implements the code can decide on the format of said filters.
> > > 
> > > 
> > > Do any council members feel strongly that we should include additional 
> > > options, or is it good enough to just make a choice on these two?
> > 
> > I listed the questions I think are relevant at the bottom of my mail.  I
> > feel you forgot the most important one: should ChangeLogs be
> > auto-generated at all?.  Only if yes,
> 
> Yeah, that's already on my draft agenda [1]. =) But we should still have 
> a small set of options to choose from if we do vote to automate, so we 
> don't sit around for another month or discuss it aimlessly for hours. 
> Being prepared is what I'm hoping we can do here.

Ok, then I suggest simply adding ", don't bother about changes between
CVS log and ChangeLog" to both of your options.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 08/03/2011 07:30 PM, Fabian Groffen wrote:
> On 03-08-2011 19:16:15 +0100, Markos Chandras wrote:
>>> I listed the questions I think are relevant at the bottom of my
>>> mail. I feel you forgot the most important one: should ChangeLogs
>>> be auto-generated at all?.  Only if yes,
>> 
>> I am a bit confused. I though that the previous council had
>> already approved the automated changelog generation[1]
>> 
>> [1]:
>> http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt
>
>> 
> The above link references the original thread on auto-generation of 
> ChangeLogs, but it doesn't decide on anything at all about it.  The 
> discussion was mainly focussed on policies and temporary
> workarounds.
> 
> The topic as it is presented in the original thread is about what 
> choices to make when generating, which greatly influences the efforts
> it needs to be implemented.
> 
What I meant was that the previous council already approved
auto-generation as a concept without providing a permanent solution.
Therefore, your implicit question "should ChangeLogs be auto-generated
at all?" confused me.

> I hope it will allow us to perhaps even start auto-generating
> ChangeLogs today, that is, right now, and not just only when we
> switch to the next VCS.
> 
Agreed. It is completely unacceptable to postpone this even further
until git arrives in 20XX ( 12<XX<99 )

- -- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)

iQIcBAEBCgAGBQJOOZXpAAoJEPqDWhW0r/LCcYEP/ihdsQwMhJj6MI3Ui/T5/6LI
Utg609vwazIQhvtTFHCRZPfuCaGQLl5+7B4Sh2tyRMw94tYtQFo0q3Yx7XmGpoOW
VwPY9mWmgXfpQn8HuYcB8X4h8DsNzcDyAt+uHf8l57uHep9C1cHap+S2+73ZZqeD
eSNzIEHRYD18FuheHr/BM47nXM1bStIkiPUWOVMJRFcPUrDHNrNPBY+x/K9sGJmF
/YjtZSlbP8VStFepMA66Mrw/e3a3RXYgW8CGe8/8DllBPPdyY640mRwtXCUuHLnr
Sa8MN4J/OQAJHHNkhUkk5AydrzBdIcRosfsw/iHwgXf64BvkE6dq8WGAwkFBcQi4
7YooCe61Ry1QjBs27yhwEKCZY3QYXDj9fdL2nltSMmef/z9ElfKAJ9hMkgc7SVmH
5Bxxjfw7nQP26B2d4gzUduiaRxszT4Sbh/QU0/dQfHUzwt4j3GJ7v4sd1b9IkM8K
d/0Vfn7noKKv4M7pSHGisbIPwiwOjorkHlOEN0pc57Vjb/Qzi8G3Om8c+ohbsz2D
nj5ITbhT4wg370GzxN8ozpN7bJpZeOJIGDEKq4YInZGUr6ctROoMy/3gmhimF6dB
uPlZOCUuY1ACGECPsx4MV2MsciQtP+wZmE7zcQZWku5EDLFiO1lmJ/V4TCZsckTq
HdbOVn7tAhnM4KCNDBa3
=IZk2
-----END PGP SIGNATURE-----

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 03-08-2011 19:39:38 +0100, Markos Chandras wrote:
> What I meant was that the previous council already approved
> auto-generation as a concept without providing a permanent solution.
> Therefore, your implicit question "should ChangeLogs be auto-generated
> at all?" confused me.

I see.  I misunderstood your question, sorry.  We seem to agree then :)


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On 20:33 Wed 03 Aug     , Fabian Groffen wrote:
> On 03-08-2011 11:09:07 -0700, Donnie Berkholz wrote:
> > > > 1. Include all commits, don't retroactively change existing ChangeLog 
> > > > messages
> > > > 
> > > > 2. Allow commit filtering, don't retroactively change existing ChangeLog 
> > > > messages
> > > > 
> > > > - Filters to allow: keywording, stabilization, removal of ebuilds. 
> > > > Whoever implements the code can decide on the format of said filters.
> > > > 
> > > > 
> > > > Do any council members feel strongly that we should include additional 
> > > > options, or is it good enough to just make a choice on these two?
> > > 
> > > I listed the questions I think are relevant at the bottom of my mail.  I
> > > feel you forgot the most important one: should ChangeLogs be
> > > auto-generated at all?.  Only if yes,
> > 
> > Yeah, that's already on my draft agenda [1]. =) But we should still have 
> > a small set of options to choose from if we do vote to automate, so we 
> > don't sit around for another month or discuss it aimlessly for hours. 
> > Being prepared is what I'm hoping we can do here.
> 
> Ok, then I suggest simply adding ", don't bother about changes between
> CVS log and ChangeLog" to both of your options.

I guess I don't understand something here. If we aren't retroactively 
changing existing ChangeLogs, and we're autogenerating things in the 
future, where would these changes come from?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 09-08-2011 12:32:57 -0500, Donnie Berkholz wrote:
> > > Yeah, that's already on my draft agenda [1]. =) But we should still have 
> > > a small set of options to choose from if we do vote to automate, so we 
> > > don't sit around for another month or discuss it aimlessly for hours. 
> > > Being prepared is what I'm hoping we can do here.
> > 
> > Ok, then I suggest simply adding ", don't bother about changes between
> > CVS log and ChangeLog" to both of your options.
> 
> I guess I don't understand something here. If we aren't retroactively 
> changing existing ChangeLogs, and we're autogenerating things in the 
> future, where would these changes come from?

so you want to retain all existing ChangeLogs?


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

On 19:42 Tue 09 Aug     , Fabian Groffen wrote:
> On 09-08-2011 12:32:57 -0500, Donnie Berkholz wrote:
> > > > Yeah, that's already on my draft agenda [1]. =) But we should still have 
> > > > a small set of options to choose from if we do vote to automate, so we 
> > > > don't sit around for another month or discuss it aimlessly for hours. 
> > > > Being prepared is what I'm hoping we can do here.
> > > 
> > > Ok, then I suggest simply adding ", don't bother about changes between
> > > CVS log and ChangeLog" to both of your options.
> > 
> > I guess I don't understand something here. If we aren't retroactively 
> > changing existing ChangeLogs, and we're autogenerating things in the 
> > future, where would these changes come from?
> 
> so you want to retain all existing ChangeLogs?

Seems like a better idea to me, although it's not originally mine. Old 
commit messages weren't written with the knowledge or intent that anyone 
would be reading them, except maybe a dev or two, so we might lose a lot 
of information.

If/when we switch to git, we might want to reconsider that, since all 
the handwritten messages will be old, largely irrelevant history by 
then.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 09-08-2011 13:15:01 -0500, Donnie Berkholz wrote:
> > > I guess I don't understand something here. If we aren't retroactively 
> > > changing existing ChangeLogs, and we're autogenerating things in the 
> > > future, where would these changes come from?
> > 
> > so you want to retain all existing ChangeLogs?
> 
> Seems like a better idea to me, although it's not originally mine. Old 
> commit messages weren't written with the knowledge or intent that anyone 
> would be reading them, except maybe a dev or two, so we might lose a lot 
> of information.

For your information: the Prefix tree [1] has ChangeLogs regenerated
from CVS commit logs for all packages that are included from the CVS
tree gentoo-x86 [2].  You can easily compare them against the original
logs from a regular gentoo-x86 [3].

> If/when we switch to git, we might want to reconsider that, since all 
> the handwritten messages will be old, largely irrelevant history by 
> then.

I don't follow your reasoning here.  All messages that are old today,
are also old when we switch to git.


[1] http://prefix.gentooexperimental.org/gentoo-portage-prefix/
[2] http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/whitelist.txt
[3] http://prefix.gentooexperimental.org/gentoo-portage-x86/


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Samuli Suominen]

On 08/09/2011 09:15 PM, Donnie Berkholz wrote:
> On 19:42 Tue 09 Aug     , Fabian Groffen wrote:
>> On 09-08-2011 12:32:57 -0500, Donnie Berkholz wrote:
>>>>> Yeah, that's already on my draft agenda [1]. =) But we should still have 
>>>>> a small set of options to choose from if we do vote to automate, so we 
>>>>> don't sit around for another month or discuss it aimlessly for hours. 
>>>>> Being prepared is what I'm hoping we can do here.
>>>>
>>>> Ok, then I suggest simply adding ", don't bother about changes between
>>>> CVS log and ChangeLog" to both of your options.
>>>
>>> I guess I don't understand something here. If we aren't retroactively 
>>> changing existing ChangeLogs, and we're autogenerating things in the 
>>> future, where would these changes come from?
>>
>> so you want to retain all existing ChangeLogs?
> 
> Seems like a better idea to me, although it's not originally mine. Old 
> commit messages weren't written with the knowledge or intent that anyone 
> would be reading them, except maybe a dev or two, so we might lose a lot 
> of information.

Quite the opposite, as commit messages have always been targeted for
developers as notes
Where as ChangeLog has been NEWS to users
So I would assume commit messages contain the more important information
to keep the package maintaince going

> 
> If/when we switch to git, we might want to reconsider that, since all 
> the handwritten messages will be old, largely irrelevant history by 
> then.
> 

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On 20:22 Tue 09 Aug     , Fabian Groffen wrote:
> On 09-08-2011 13:15:01 -0500, Donnie Berkholz wrote:
> > If/when we switch to git, we might want to reconsider that, since 
> > all the handwritten messages will be old, largely irrelevant history 
> > by then.
> 
> I don't follow your reasoning here.  All messages that are old today, 
> are also old when we switch to git.

Right. But the messages written last week are the ones I'm talking 
about. They aren't old yet, but (almost) nobody's gonna care about them 
six months from now.

--
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer
Gentoo Linux
Blog: http://dberkholz.com

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-project] Re: [gentoo-dev] ChangeLog generation - pros and cons (council discussion request)

[Fabian Groffen]

On 09-08-2011 15:20:59 -0500, Donnie Berkholz wrote:
> On 20:22 Tue 09 Aug     , Fabian Groffen wrote:
> > On 09-08-2011 13:15:01 -0500, Donnie Berkholz wrote:
> > > If/when we switch to git, we might want to reconsider that, since 
> > > all the handwritten messages will be old, largely irrelevant history 
> > > by then.
> > 
> > I don't follow your reasoning here.  All messages that are old today, 
> > are also old when we switch to git.
> 
> Right. But the messages written last week are the ones I'm talking 
> about. They aren't old yet, but (almost) nobody's gonna care about them 
> six months from now.

ok, the starting point was that we can generate ChangeLogs using CVS
today, we don't need to wait for git.


-- 
Fabian Groffen
Gentoo on a different level