1 |
On 19-09-2011 19:28:28 +0300, Markos Chandras wrote: |
2 |
> On 09/19/11 17:27, Fabian Groffen wrote: |
3 |
> > On 19-09-2011 16:44:51 +0300, Markos Chandras wrote: |
4 |
> >> On 09/19/11 16:26, Fabian Groffen wrote: |
5 |
> >>> I would prefer going this route myself. Generate all |
6 |
> >>> ChangeLogs from commit messages only. This is easy to |
7 |
> >>> implement (POC is running for Prefix), but has a little issue |
8 |
> >>> with ChangeLog being in Manifest file. I think we should just |
9 |
> >>> omit it, or (better) allow the Manifest to have multiple signed |
10 |
> >>> parts, such that the ebuilds, dists and files are signed by the |
11 |
> >>> committing developer, and the ChangeLog is signed by the |
12 |
> >>> generation process (like snapshots are). |
13 |
> >> If you generate Changelogs from commit messages then you dont |
14 |
> >> need to place the to $VCS unless you want to edit them ( see |
15 |
> >> below ) |
16 |
> > |
17 |
> > I can't parse/don't understand this sentence. Could you |
18 |
> > explain/elaborate? |
19 |
> Yeah it is obvious that I can't type. What I meant was that if we use |
20 |
> the commit logs to generate the ChangeLogs then we can do that on |
21 |
> server side (just before populating the portage tree to rsync |
22 |
> mirrors). In this case we do not need to store the Changelog files on |
23 |
> $VCS. |
24 |
|
25 |
Yeah, so what's your point? |
26 |
|
27 |
> > Sorry, I recalled the details wrong. The effect is the same |
28 |
> > though, a file needs to exist: |
29 |
> > |
30 |
> > [quote from [1]] - Vote: Retroactively change existing entries, yes |
31 |
> > or no. - We will append to changelogs and retain all existing |
32 |
> > changelog messages. [/quote from [1]] |
33 |
> > |
34 |
> |
35 |
> Yes a file is needed but like I said before, this file can be |
36 |
> generated on a post-commit server just before populating portage to |
37 |
> rsync servers |
38 |
|
39 |
What's the advantage of that? We just end up with a different location |
40 |
for the information that's now in a file called ChangeLog. People want |
41 |
to be able to edit that stuff (yeah, no vote yet, but the tendency |
42 |
seemed going that way) so why not keep it local to the ebuild? |
43 |
|
44 |
> > An additional advantage of keeping the file is that we can easily |
45 |
> > fix all entries that people wrote/committed ugly and helpless |
46 |
> > messages for, like "^" and so on. |
47 |
> > |
48 |
> In this case you need smart filtering tools to avoid duplicate |
49 |
> messages ( one from $commit_message and the one you wrote yourself to |
50 |
> fix that message ). However, this will be the case if we decide to |
51 |
> allow edits on ChangeLogs. |
52 |
|
53 |
Ehm. Are we talking about the same thing here? ChangeLog commits don't |
54 |
end up in ChangeLogs, do they? Unless you run echangelog for it, of |
55 |
course. |
56 |
|
57 |
|
58 |
-- |
59 |
Fabian Groffen |
60 |
Gentoo on a different level |