[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we restore manually maintained ChangeLogs
From: |
Eli Zaretskii |
Subject: |
Re: Should we restore manually maintained ChangeLogs |
Date: |
Tue, 08 Mar 2016 17:50:29 +0200 |
> Cc: address@hidden, address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Mon, 7 Mar 2016 15:31:54 -0800
>
> On 03/07/2016 01:06 PM, Eli Zaretskii wrote:
>
> Maintaining ChangeLog files by hand with each commit makes it harder
> to merge changes due to the inevitable collisions with ChangeLog
> files.
>
> Incorrect! And the current situation creates _more_ collisions, not
> less!
>
> My own experience is otherwise. For the kinds of development I do, I rarely
> see ChangeLog screwups now, whereas I used to see them routinely.
With or without git-merge-changelog?
If you have git-merge-changelog installed, what kind of screwups did
you see with ChangeLogs? (I didn't see even one, in all the years I
use Git.)
> I far prefer the current approach. Of course our approach can be improved
> (in particular merging from emacs-25 to master doesn't work well now), but
> let's not throw out the baby with the bathwater.
The current approach completely breaks down when more than one branch
is active. So there's no baby in that bathwater.
> We don't have to be better than the other prominent GNU projects.
>
> I'd be happy if we were merely as good as the other prominent GNU projects
> that generate ChangeLog entries automatically. As things stand, due to our
> attempt to cater to all sides of this disagreement, we have an approach that
> satisfies nobody.
Not sure what you mean here. What alternatives that don't "cater to
all sides" would you suggest? The only one I see is to stop producing
ChangeLog files for the releases.
> ChangeLog mistakes can be easily fixed.
>
> That's true under both the old and the new regimes.
No, it isn't. Definitely not with two branches.
> Let other projects invent those schemes and test-drive them. Enough with
> these experiments!
>
> I'd rather just do what coreutils, grep, tar, etc. use.
Don't know what hides behind "etc", but the rest are much smaller
projects, which are all in maintenance mode, and have a very small
number of active committers (of which you personally are a significant
fraction ;-). They also don't use branches, at least not as much as
we do. So I don't see how the experience of these projects is more
relevant to us than that of GCC, GDB, Binutils, and glibc.
> I could fairly easily change the master branch to do that.
Please describe the details of your proposal. Also, please tell what
do you suggest doing on the release branches.
> Even simpler would be to do what Guile does: it dispenses with ChangeLogs
> entirely. With Guile if you want something like a ChangeLog you run "git log".
As I said, tossing ChangeLog files entirely would indeed solve the
problems, but it's a sure path to further deterioration in the quality
of log messages. It is easy to keep the quality in a project that has
a small number of committers who are veteran GNU developers (Guile has
1 frequent committer on master, and 3 on stable). That's not our
case.
> If neither of the above two approaches suffice, we can always fall back on my
> previous email's proposal. It's not that experiemental, as it says to use the
> new produre on master and the old procedure on emacs-25. The new procedure
> works well enough within a single master branch.
Any suggested approach should support not only the current emacs-25
branch, but also the future release branches, i.e. it should continue
working when we cut the emacs-26 branch in the future. It should also
be reliable, and not require manual labor for fixing mistakes in the
log messages, beyond the fix itself.
> these procedures work, and all those projects are alive and kicking, and
> actually make more frequent releases than we do.
>
> XEmacs is not really alive and kicking.
XEmacs is not that different from Grep or Sed. Sed, for example, saw
just 30 commits during all of the last year.
> Projects like GCC and glibc have more resources than we do, and can afford to
> insist on more-expert contributions that involve harder-to-generate patch
> formats. We do not have that luxury.
It's the other way around, actually: the current situation requires
more labor from us to get it right, so our lack of resources should
lead us to the opposite conclusion.
> I often ran into problems. Yes, git-merge-changelog should reduce the
> number of merge conflicts, but it doesn't eliminate them
>
> Oh, yes, it does.
>
> Not in my experience, or in Dmitry's. It's a fine program, but it sometimes
> makes mistakes and they can be a pain to fix.
Fixing its mistakes involves moving an entry to a different place,
that's all. Easy done, and even if not done, it's not a disaster, as
the information is there anyway.
- Re: Should we restore manually maintained ChangeLogs, (continued)
- Re: Should we restore manually maintained ChangeLogs, Paul Eggert, 2016/03/07
- Re: Should we restore manually maintained ChangeLogs, Mathieu Lirzin, 2016/03/08
- Re: Should we restore manually maintained ChangeLogs, Stefan Monnier, 2016/03/08
- Re: Should we restore manually maintained ChangeLogs, Eli Zaretskii, 2016/03/08
- Re: Should we restore manually maintained ChangeLogs, Stefan Monnier, 2016/03/08
- Re: Should we restore manually maintained ChangeLogs, Eli Zaretskii, 2016/03/08
- Re: Should we restore manually maintained ChangeLogs,
Eli Zaretskii <=
- Re: Should we restore manually maintained ChangeLogs, Paul Eggert, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Stefan Monnier, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Dmitry Gutov, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Stefan Monnier, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Dmitry Gutov, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Paul Eggert, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Eli Zaretskii, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Alan Mackenzie, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Stefan Monnier, 2016/03/09
- Re: Should we restore manually maintained ChangeLogs, Alan Mackenzie, 2016/03/09