1 |
On Thu, Jun 2, 2011 at 2:43 PM, Fabian Groffen <grobian@g.o> wrote: |
2 |
> I start from the assumption that generation of ChangeLogs is NOT limited |
3 |
> to any VCS. |
4 |
|
5 |
This assumption is incorrect, but I guess it's a close enough |
6 |
approximation for the current discussion. |
7 |
|
8 |
> Simple pros I see mentioned: |
9 |
> - no more need for echangelog + repoman commit (identical message) |
10 |
|
11 |
This can be done without autogeneration as well. We can make repoman |
12 |
commit run echangelog before cvs commit. The main advantage is that |
13 |
there's no duplication of information, which would result in a less |
14 |
bloated repository. |
15 |
|
16 |
> - no discussion on what to include or not (everything is in there) |
17 |
|
18 |
In git, we can make git log skip commit messages while generating the |
19 |
ChangeLog, so this is incorrect. See section "Commit Limiting" in git |
20 |
log --help. |
21 |
|
22 |
> Simple cons I see mentioned: |
23 |
> - useless information on removals of ebuilds/files |
24 |
> - useless information on whitespace changes |
25 |
|
26 |
None of these are valid with Commit Limiting and a tag such as |
27 |
'[trivial]' in the commit message subject. |
28 |
|
29 |
> - inability to edit ChangeLog entries (typos, bug refs, etc.) |
30 |
> |
31 |
|
32 |
See "git notes --help". It allows you to append notes to commit |
33 |
messages without editing them. |
34 |
|
35 |
> 1) it appears echangelog messages more than just a couple of times |
36 |
> differ from the repoman commit messages; sometimes useful information |
37 |
> is lost when just using the VCS logs |
38 |
> 2) typo fixing on VCS-generated logs is sometimes necessary, but |
39 |
> probably impossible |
40 |
> 3) dates and new ebuilds generated from VCS are always correct, |
41 |
> ChangeLog editting/echangelog -> commit delays can cause |
42 |
> inconsitencies |
43 |
> 4) package moves might lose all history for essentially the same files |
44 |
> 5) entries for all commits show up, including those that weren't |
45 |
> originally tracked in ChangeLog for some reason |
46 |
> |
47 |
|
48 |
All these problems are fixed if we don't re-generate the *existing* |
49 |
ChangeLogs. We should simply archive the existing ChangeLog, and |
50 |
append to it after the move to git. |
51 |
|
52 |
Since the beginning, we've been working with the assumption that |
53 |
ChangeLogs can be edited. This has caused a *lot* of quirks to appear |
54 |
as you've demonstrated. |
55 |
|
56 |
Infact, if you do the same experiment on the openrc ChangeLog, you'll |
57 |
see that it's too much work to regenerate the current ChangeLog |
58 |
because a few commits managed to change the encoding of names in the |
59 |
file, and a reverse-patch had to be applied to fix it. A number of |
60 |
developers have made this mistake, and it shows up across the tree. |
61 |
|
62 |
> If a move to VCS-generated ChangeLogs is to be made, it appears the |
63 |
> council has to decide that the following is desirable: |
64 |
> - a commit message is supposed to be always right/correct |
65 |
> - since the commit message is right, either |
66 |
> - repoman commit runs echangelog, or |
67 |
> - ChangeLogs are generated on current CVS as well |
68 |
> - any typos and incorrect refs, bugs, messages, etc. are accepted as |
69 |
> drawback of the system that does not compare to its advantages |
70 |
|
71 |
We can append to existing commit messages using git-notes. Typos are |
72 |
hard to fix, but using git-notes to include sed commands, we can hack |
73 |
up a solution if there's a *pressing* need for it. |
74 |
|
75 |
As a result, commit messages are supposed to be double-checked with |
76 |
git log -p before pushing; but if you make a mistake, that can be |
77 |
fixed as well. |
78 |
|
79 |
> - it is accepted that all current information in the ChangeLogs gets |
80 |
> lost in favour of the VCS commit messages |
81 |
|
82 |
This is not an issue if we archive and re-use the current ChangeLogs. |
83 |
|
84 |
> - there is no point in discussing what should be in or out of a |
85 |
> ChangeLog, since by definition, "everything" is in (and tools should |
86 |
> effectuate so ASAP) |
87 |
> |
88 |
|
89 |
This issue will come up again if we implement commit-message limiting |
90 |
using a [trivial] tag. |
91 |
|
92 |
> If the council deems a separate ChangeLog file useful, they decide that: |
93 |
> - ChangeLog messages can (and sometimes should) be different from commit |
94 |
> messages, as they are intended as information for users |
95 |
|
96 |
In git, there's no harm with making commit messages verbose, so we |
97 |
should give as much information as possible. However, if some |
98 |
developers *really* don't want some lines to show up in the ChangeLog, |
99 |
they can prepend it with a '#omit' (or similar), and the |
100 |
ChangeLog-generating script will skip those lines. |
101 |
|
102 |
> - editting ChangeLog messages is necessary to emit the most correct |
103 |
> information to our users at all times |
104 |
|
105 |
Once again, git-notes. |
106 |
|
107 |
> - a clear policy is necessary on what is going in the ChangeLog and what |
108 |
> not (like the current "common sense" discussions going on and the |
109 |
> updated devmanual) |
110 |
|
111 |
However, with git the issue is simplified because then developers will |
112 |
stop relying on ChangeLogs for information, and ChangeLogs will be |
113 |
used entirely to convey information to users. |
114 |
|
115 |
> - basically nothing changes, and the whole idea of generating ChangeLogs |
116 |
> from VCS is no longer a point of discussion |
117 |
> |
118 |
|
119 |
I'm not sure I understand this. |
120 |
|
121 |
-- |
122 |
~Nirbheek Chauhan |
123 |
|
124 |
Gentoo GNOME+Mozilla Team |