| 1 |
On Wed, Sep 17, 2014 at 5:56 AM, Ulrich Mueller <ulm@g.o> wrote: |
| 2 |
> |
| 3 |
> So the research that needs to be done first is to find out how often |
| 4 |
> our ChangeLog entries differ from the commit log. If it turns out that |
| 5 |
> they are identical in 99 % of all cases, then it obviously makes no |
| 6 |
> sense to maintain the same information in two places, and ChangeLogs |
| 7 |
> should be abandoned. (For my own commits, I would estimate that |
| 8 |
> messages are different for 20 % of commits.) |
| 9 |
|
| 10 |
When I do commits the commit message is scripted to be identical to |
| 11 |
the changelog message. I doubt I have a single commit where they |
| 12 |
differed, unless I went back to modify a changelog to fix a typo or |
| 13 |
something. They're all intended to be readable by anybody. |
| 14 |
|
| 15 |
> |
| 16 |
> Only when this has been answered, we should discuss how the |
| 17 |
> information should be formatted and how users should obtain it. |
| 18 |
|
| 19 |
So, this will be on the Council agenda. By all means go out and dig |
| 20 |
up whatever info you think will be useful for making a decision, but I |
| 21 |
don't want to put this off hoping that somebody else will do it. I |
| 22 |
don't think it is essential to determine whether changelog messages |
| 23 |
are different from commit messages in practice. If a majority of |
| 24 |
council members disagree we can defer the decision. |
| 25 |
|
| 26 |
> Some ideas: |
| 27 |
|
| 28 |
No objection to any of your ideas per se, but I don't want to make any |
| 29 |
of them blockers for a git migration. I think getting off of cvs is |
| 30 |
orthogonal to improving our documentation and communications. |
| 31 |
|
| 32 |
There are a million ways we could be spending our effort on Gentoo, |
| 33 |
but I don't think that making our commit messages more nicely |
| 34 |
formatted/etc is something worthy of a rule (ie something all devs are |
| 35 |
forced to contribute to). 95% of it is noise, so if there is a |
| 36 |
message that really needs to get out to users it should go into |
| 37 |
something like a news item that is distributed BEFORE the change is |
| 38 |
made. |
| 39 |
|
| 40 |
If documentation improvements are built into a new echangelog-like |
| 41 |
tool, I think that will greatly help adoption, but again I don't want |
| 42 |
to hold up the git migration for this. The git migration has been a |
| 43 |
moving target forever because there has always been just one more |
| 44 |
thing that needs to be done, and most who have gotten involved have |
| 45 |
gotten frustrated/bored/whatever and moved on. How many FOSS projects |
| 46 |
of our scale are still using cvs anyway? |
| 47 |
|
| 48 |
-- |
| 49 |
Rich |
Archives