On 19-09-2011 19:28:28 +0300, Markos Chandras wrote:
> On 09/19/11 17:27, Fabian Groffen wrote:
> > On 19-09-2011 16:44:51 +0300, Markos Chandras wrote:
> >> On 09/19/11 16:26, Fabian Groffen wrote:
> >>> I would prefer going this route myself.  Generate all
> >>> ChangeLogs from commit messages only.  This is easy to
> >>> implement (POC is running for Prefix), but has a little issue
> >>> with ChangeLog being in Manifest file. I think we should just
> >>> omit it, or (better) allow the Manifest to have multiple signed
> >>> parts, such that the ebuilds, dists and files are signed by the
> >>> committing developer, and the ChangeLog is signed by the
> >>> generation process (like snapshots are).
> >> If you generate Changelogs from commit messages then you dont
> >> need to place the to $VCS unless you want to edit them ( see
> >> below )
> > 
> > I can't parse/don't understand this sentence.  Could you 
> > explain/elaborate?
> Yeah it is obvious that I can't type. What I meant was that if we use
> the commit logs to generate the ChangeLogs then we can do that on
> server side (just before populating the portage tree to rsync
> mirrors). In this case we do not need to store the Changelog files on
> $VCS.

Yeah, so what's your point?

> > Sorry, I recalled the details wrong.  The effect is the same
> > though, a file needs to exist:
> > 
> > [quote from [1]] - Vote: Retroactively change existing entries, yes
> > or no. - We will append to changelogs and retain all existing
> > changelog messages. [/quote from [1]]
> > 
> 
> Yes a file is needed but like I said before, this file can be
> generated on a post-commit server just before populating portage to
> rsync servers

What's the advantage of that?  We just end up with a different location
for the information that's now in a file called ChangeLog.  People want
to be able to edit that stuff (yeah, no vote yet, but the tendency
seemed going that way) so why not keep it local to the ebuild?

> > An additional advantage of keeping the file is that we can easily
> > fix all entries that people wrote/committed ugly and helpless
> > messages for, like "^" and so on.
> > 
> In this case you need smart filtering tools to avoid duplicate
> messages ( one from $commit_message and the one you wrote yourself to
> fix that message ). However, this will be the case if we decide to
> allow edits on ChangeLogs.

Ehm.  Are we talking about the same thing here?  ChangeLog commits don't
end up in ChangeLogs, do they?  Unless you run echangelog for it, of
course.


-- 
Fabian Groffen
Gentoo on a different level