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
> 2. Allow commit filtering, don't retroactively change existing ChangeLog
> - 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
- 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.
Gentoo on a different level