From: Fabian Groffen <grobian@gentoo.org>
To: gentoo-project@lists.gentoo.org
Subject: Re: [gentoo-project] ChangeLog generation: Edit generated Changelogs
Date: Mon, 19 Sep 2011 18:51:52 +0200 [thread overview]
Message-ID: <20110919165152.GD1168@gentoo.org> (raw)
In-Reply-To: <4E776DAC.8020500@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
next prev parent reply other threads:[~2011-09-19 16:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-16 14:08 [gentoo-project] ChangeLog generation: Edit generated Changelogs Markos Chandras
2011-09-16 21:32 ` "Paweł Hajdan, Jr."
2011-09-17 8:32 ` Markos Chandras
2011-09-17 9:07 ` Nirbheek Chauhan
2011-09-17 14:01 ` Rich Freeman
2011-09-19 13:26 ` Fabian Groffen
2011-09-19 13:44 ` Markos Chandras
2011-09-19 14:27 ` Fabian Groffen
2011-09-19 16:28 ` Markos Chandras
2011-09-19 16:51 ` Fabian Groffen [this message]
2011-09-19 16:58 ` Markos Chandras
2011-09-19 17:09 ` Fabian Groffen
2011-09-19 17:21 ` Markos Chandras
2011-09-19 17:53 ` Fabian Groffen
2011-09-19 21:39 ` Donnie Berkholz
2011-09-19 21:46 ` Michał Górny
2011-09-20 6:57 ` Fabian Groffen
2011-09-28 17:37 ` Fabian Groffen
2011-09-28 18:24 ` Mr. Aaron W. Swenson
2011-09-29 17:04 ` Markos Chandras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110919165152.GD1168@gentoo.org \
--to=grobian@gentoo.org \
--cc=gentoo-project@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox