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 . =) 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.
Council Member / Sr. Developer