From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is it time to drop ChangeLogs? Date: Wed, 09 Mar 2016 17:53:06 +0200 Message-ID: <83lh5rps0t.fsf@gnu.org> References: <56BE7E37.3090708@cs.ucla.edu> <4hd1rw1ubr.fsf@fencepost.gnu.org> <83vb50wxhv.fsf@gnu.org> <87y49vz4cg.fsf@acer.localhost.com> <64a52598-ad53-498c-993c-67d7827dbdfc@default> <838u1uuuau.fsf@gnu.org> <878u1um2xl.fsf@thinkpad.rath.org> <87fuw090k7.fsf@wanadoo.es> <83y49spuxt.fsf@gnu.org> <87pov4achc.fsf@acer.localhost.com> <83r3fkpb3u.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1457538911 10047 80.91.229.3 (9 Mar 2016 15:55:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Mar 2016 15:55:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: "John Wiegley" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 09 16:55:04 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1adgRz-0002Jf-Cz for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 16:55:03 +0100 Original-Received: from localhost ([::1]:42274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adgRy-0001fA-UZ for ged-emacs-devel@m.gmane.org; Wed, 09 Mar 2016 10:55:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33910) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adgRq-0001f1-Ob for emacs-devel@gnu.org; Wed, 09 Mar 2016 10:54:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1adgRm-0001cX-W3 for emacs-devel@gnu.org; Wed, 09 Mar 2016 10:54:54 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40329) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1adgRi-0001cG-Bs; Wed, 09 Mar 2016 10:54:46 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3655 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1adgPu-0007Nt-Lo; Wed, 09 Mar 2016 10:54:45 -0500 In-reply-to: (message from John Wiegley on Tue, 08 Mar 2016 22:41:49 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201247 Archived-At: > From: John Wiegley > Cc: Ingo Lohmar , ofv@wanadoo.es, emacs-devel@gnu.org > Date: Tue, 08 Mar 2016 22:41:49 -0800 > > Keeping ChangeLog style in the commit entry is not terribly > useful either, since the diff output of log -p lets you know which function or > variable is being modified. "git log -p" cannot do the job for changes in many types of files. For example, try it on Lisp or Texinfo files. More generally, there's no way Git could replace ChangeLog style entries, because they frequently include information that is not in the diffs. To say nothing of the fact that understanding the change from reading Diff hunks is much harder, and therefore much less efficient, than from reading a log entry which describes the change in plain English. > I've never missed not having that ChangeLog data in other projects, > of any size. Maybe you rarely need to do any forensics. Me, I do it all the time in Emacs, and ChangeLog files are a valuable tool in the chest. ====================================================================== (Why is this topic cross-posted to bug-gnu-Emacs??) > In my short experience, Change Logs has generally been useful both when > reading and composing them. When writing them it helps me structure > large changes in logical commits that are modelled by the Change Log > format. Finally It helps me being precise in my wordings which is not > trivial for non-native english speakers. > > On a more spiritual side, I think they belong to the zen of contributing > to a GNU project. :) I agree completely. Writing a log entry in ChangeLog format is an excellent opportunity for reflecting on the changeset, for summarizing its intent and final shape, and for making sure nothing was left out. Writing those entries teaches one discipline, the ability to describe your changes in just enough detail, and facilitates communications between members of the development team. And in loose teams such as ours, good communications are everything. As told many times in past discussions, ChangeLog files are also an excellent first tool for forensics, easy to search with many available tools. It is invaluable when you don't have access to the repository, and a good asset even if you do: traversing the history of a complex Git repo without losing commits on branches is not a trivial task, it requires using non-default switches and some rarely used commands and options. Even when you do use Git tools, ChangeLog frequently provides additional important evidence. So removing ChangeLog files will be a bad blow to our ability to easily and conveniently research the past, something that is extremely important in a project with such a rich history, where it's all too easy to reintroduce a bug if you don't look hard enough at the history of some code fragment. People are saying it's an extra barrier to contributing. That is true, but so is understanding the Emacs internals, code conventions, organization of the documentation system, its auxiliary files (like CONTRIBUTE, NEWS, DEBUG, PROBLEMS, etc.), the release process, and a few more things. Having to write ChangeLog entries is an insignificant addition to the body of knowledge a contributor needs to master, there's no way around that. Nor should there be: without knowing this stuff, you cannot be a useful contributor anyway, as your contributions will need too much attention from the veterans, who then will be unable to make more significant contributions due to lack of time. We need here contributors who know enough to work on their own with minimal guidance, who can be trusted to do a good job that doesn't need to be reviewed too deeply, whose design can be trusted to be in line with the Emacsy way of doing things. How can one raise to this position without learning a lot of project-specific stuff? You can't. Writing ChangeLog entries is just one small part of that. It's no accident that people who don't want ChangeLog files more often than not don't want to write detailed commit log messages, either, and many times don't know how to write good documentation. Do we want to dispense with these as well? If we drop the ChangeLog files, there's no way we can explain why we ask for commit log messages in ChangeLog format, so the next logical step is to drop that as well, and we will then lose valuable information. We already are firmly on that path. Other prominent GNU projects that maintain ChangeLog files in the repository include GCC, Binutils, GDB, glibc, and Texinfo. XEmacs also has it. Why should Emacs be the first one to plunge into this adventure? Why not let others try that first, and then we could learn from their mistakes? Let's reinstate the ChangeLog files. Maintaining them is a negligible cost; many other projects do that and don't have any trouble. Unlike what some people say, merge conflicts in ChangeLog files are very rare, once you install git-merge-changelog. We have some important infrastructure based on ChangeLog files that will become extinct without them, something that people tend to forget. We tried to live without these files for a year; that experiment failed miserably. It's time to admit that, and fix the mistake we made. ====================================================================== > > On a more spiritual side, I think they belong to the zen of contributing > > to a GNU project. :) > > Dear Goddess, I hope you're joking. Actually, I'm sure he isn't. Maybe you are. > Speaking as a very, *very* long-time GNU contributor (I'm pretty sure > my earliest Emacs patches predated the formation of the FSF), I > consider ChangeLogs a relic of a bygone era. You are entitled to your opinions; others are entitled to theirs. IMO, active involvement in Emacs development during the recent years brings more weight to an opinion about the current subject than contributions made 30 years ago. > Changelogs made some sense as a way of grouping together what we now > call a changeset back in the days of file-oriented version-control > systems. Nowadays, set against the actual changeset comments in > version-control histories, Changelogs are a pointless and duplicative > ritual. They are not duplications. They are work-tree expressions of the VCS log, exactly like any source file is the work-tree expression of the VCS repo objects which hold that file's data. You won't lobby for removing the source files, and use the likes of "git show :foo.c" instead, would you? It should go without saying that having a file is more convenient than having to regenerate it every time from the repository. And please note that many people who want to drop Changelogs also want to drop the policy of making detailed commit log messages. We are experiencing the adverse effects of that for the past year. If we continue on that disastrous path, things will keep deteriorating, and we will lose important information that cannot be restored. > I think we should have dispensed with this practice during the CVS-to-bzr > transition. As it is, the sooner gone the better. You are a year late to the party, I think: we already did what you describe. We no longer maintain Changelogs directly, we produce them from Git logs. The result is problematic even when there's only one active branch of development; when there are 2 branches, as we have now, the result is an unimaginable mess, with _more_ merge conflicts and more work to fix the fallout, not less. I cannot even imagine what will happen if we will ever want to start a 3rd branch. >From this past year's experience, it is clear to me that having ChangeLog files as we did before is a fraction of the price we had to pay for removing them. Removing them is also a serious impediment on our way to more complex workflows, so it's actually a regression, not progress. It's high time we recognized the mistake and fixed it. ====================================================================== > I respect that Richard may use them in a constructive way, but he's no longer > doing the majority of the work on Emacs Neither are some of those who expressed their views here. Unlike Richard, those others cannot present a history of contributions and of leading the development that is anywhere near what Richard has on his record. > I want to choose the path that works for the core developers, and > will make Emacs more welcoming to new contributors. It is IMO a grave mistake to remove parts of our development process just because they need to be learned by new contributors. The result will be increased burden on the shoulders of those who review the submissions, due to the need to coach them, catch their mistakes, ask for re-submissions, etc. It will eventually be a net loss, because those contributors will not enjoy the need to produce several versions of the patch before it is admitted, and the reviewers will not enjoy the extra burden. We should consider each part of the development process on its own merit, first and foremost. If a part is useful, and its removal will make the quality of the code or the documentation lower, then it should not be removed, and new contributors will have to learn it and to live by it. There's no useful way into Emacs development that doesn't require negotiating a few barriers. No free lunch here (or anywhere). We should recognize this fact instead of trying to bury our head in the sand. ====================================================================== > > At this point, I give up, since it seems fairly clear that maintaining > > an accurate ChangeLog just isn't of interest. Even the bare minimum > > legally relevant mistakes (missing "tiny change") don't seem to be being > > corrected. > > In concrete terms, what is the problem with these mistakes? The mistakes are not being corrected. Experience shows that correcting them is enough of an annoyance to discourage people. > Where is the master record of this information now? In the Git commit messages. > Is it being maintained correctly there? When a mistake is made there, it cannot be corrected, because Git commit log is immutable. Corrections must be made manually to a ChangeLog file produced from the Git log by a script. That proved not to work well, see above. It also proved to be a non-trivial problem when merging changes from the release branch to master -- for this latter issue we still don't have any idea for how to solve it reliably and without requiring a lot of manual labor. > Probably just deleting it from the repo would be more honest. > > What exactly are you proposing as the new practice > for handling ChangeLog files? There are 3 possibilities: . Keep the current system, where ChangeLog is produced from Git log and mistakes made in Git log should be corrected manually after producing ChangeLog . Give up on having ChangeLog files, either produced from Git log or maintained in the repository -- meaning a tarball will not include any ChangeLog at all . Go back to previous practice where we maintained ChangeLog files in the repository, and Git log messages were just copies of the ChangeLog entries ====================================================================== > No, what we do currently is different: we auto-generate the ChangeLog > and then commit it into the Git. What I think we should do is to never > commit it into the Git, and only auto-generate it into the tarball. > Like what we do for GNU ELPA packages (where the log is extracted via > "git log" when building the package and added to the package's content). > > That makes "fixing" ChangeLog entries harder/impossible. But it gets us > rid of the merge-mess once and for all. This would mean we don't care at all about what's in the ChangeLog. You already said you didn't care, so it's not really surprising you'd consider this as a viable option. But for someone like me, who does care, this is not really a solution at all. ====================================================================== > If we could switch to a system where every patch is reviewed before > commit, that'd be great. My own impression is that it will kill the > development pace because too few people are willing to spend the > corresponding efforts. Agreed. For my part, I can say that I simply don't have enough free time to review more patches than I do (which is an abysmal little). > That's why I've followed a practice of giving out write access very > liberally, with "post-commit spot-check reviews" instead. Indeed, it > means that errors in commit messages can't be fixed (we can fix them in > the ChangeLog files, admittedly, but since I don't use them it doesn't > help me). Post-commit reviews also take time. Do you have an estimation of how much time per day this takes? > Maybe we could have a half-way system, where commits are pushed to > a branch that is "not fast-forward-only", and this branch is then > auto-merged to the real (fast-forward-only) master branch after a delay > (one day, maybe?) to give time to fix mess ups before they're cast > in stone. A day is nowhere near enough. IME, a bad commit pushed to master takes up to a week to be discovered. More generally, the problem with such a branch is that it won't be much different from pushing to master, except in rare cases that it breaks the build, and even that can only be avoided if we set up some kind of CI system that continuously builds that branch on the main supported platforms. ====================================================================== > 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. To do what? 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 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. ====================================================================== > 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! > > Only when merging between branches. It doesn't work very well even on a single branch. With two branches, it completely breaks down. We do want to work on multiple branches, don't we? We discussed how to make more frequent releases, and perhaps have 3 branches for even more flexible development and release schedule. All of that would be impossible because of this tiny but annoying PITA. Do we really want to continue wasting energy on fixing something that wasn't such a big problem to begin with? > Other than that, only a select group of people needs to bother: those who make mistakes, and those who feel a general need to clean up. See, that's the crux of the issue: do we or don't we care about the need to clean up our ChangeLogs? If we don't, then why bother maintaining them? You (and some others) say the format and the content in the log messages are important, and I agree. But if we do care about them, how can we NOT clean them up? Having them in their current state means they cannot be trusted, which is worse than not having them at all. > As a relatively careful committer, I've only had to correct the entries a few times, and I've been enjoying the lack of collisions quite a bit. Yes, a few of us don't need any corrections. But enough of us do, and that's where the problem lies. It is that problem that we need to fix. Leaving it unfixed makes your accurate work unreliable as well. > But ChangeLog mistakes can be easily fixed. > > In the current approach, as well. Only on a single branch, and even there this is not done enough. We all relied on Glenn to do that behind the scenes. Now Glenn gave up in despair, so things will degrade from now on. > We don't know how, and we don't have anyone who is motivated enough to > do that. And even if and when we do have some solution, it is likely > to be inconvenient and unreliable. > > I think we should wait and see until the work really transitions back to master. The motivation must rise. The release branch will remain active for quite some time: we have just started a new major version. And if we want more frequent releases, we should strive to have an active release branch at all times. So I don't think we can wait; waiting will not solve anything, it will just make the current problems bigger and harder to solve. > Let other projects invent those schemes and test-drive them. Enough > with these experiments! They draw the last drops of energy from us, > and they avert the few last veteran contributors we have left. > > Has the current experiment really sucked too much energy from anyone, aside from the implementors? Why do you think Glenn gave up? > That's not a bad thing in itself. The point is, these procedures > work, and all those projects are alive and kicking, and actually make > more frequent releases than we do. > > For all we know, they might be thriving despite this practice. Nothing wrong with that. > 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 either. I've still had collisions, and even when git-merge-changelog resolved them, it often put my entry in the middle of the file, whereas I usually needed it to be at the top. Leading to extra manual labor. That extra manual labor is very small, and it's still a rare case to have that. A small price to pay for a clean and reliable solution. > requiring git-merge-changelog means that many contributors would > have to worry about installing and configuring git-merge-changelog, > which would be more of a hassle for recruiting contributors. > > It's a 5-sec configuration, let's not make a mountain out of a > molehill. > > It was longer for me. But either way, it's more hassle for a random contributor than the current system. The current system is much more hassle for non-random contributors, so much so that we risk losing them, something we cannot afford. > If it can be fixed, Someone should. Let that Someone step forward, then, and speak up. We have been waiting for that for the past year, so I'm not holding my breath now. ====================================================================== > >> Introduce code reviews. Don't give commit access to the "golden" > >> branches to everyone, just to a few top contributors and reviewers. > > > > We don't have manpower for that. > > I find perplexing that we have manpower for reviewing ChangeLogs but not > for reviewing commit logs *instead*. Log messages are much shorter than code diffs, and much simpler to read and understand. It takes a few seconds to read them; reading a code patch takes much more, typically needs to consult the surrounding and related code, etc. So code review takes orders of magnitude more time than reviewing the corresponding log entries. > And is it so super-important to have typo-free commit logs? Typos is the least of our problems. But yes, it's important: if you start by forgiving typos, you end with unhelpful and uninformative log messages. > We are not even using `git notes'. No one came up with a detailed procedure for doing that. If you can propose something that works, please do. ====================================================================== > >> Another option for correcting errors on commit logs is `git notes', but > >> I don't know about its implications. > > > > Nobody does. We shouldn't consider any more experiments in this area > > until someone else uses these methods and proves they are viable in > > our case. > > How could *someone else* prove the viability of something in *our* case? By coming up with a procedure which we can study and decide whether it fits us. > You always can argue that his project is not Emacs... I can, but why would I want to? The opinions are not pre-determined, they are based on study and in this case also on a year-long experience of actually using a procedure. > `git notes' is a documented feature available since a long time ago. It > can turn the immutability of the commit log into a non-issue if you wish > to produce a proofread ChangeLog to include in the tarball. We need a more detailed proposal than this, TIA. David says "git notes" is not a solution; if notes don't support merging, then I tend to think he is right. ====================================================================== > > The reasons exist, and has been described. You may not agree with > > them, perhaps due to different experience, but that doesn't mean they > > aren't valid. > > Yeah, but what exactly is your point here? I was pointing out that this > practice is astonishing for new contributors. You didn't understand why, > so I explained that it's astonishing because to a new contributor it > seems pointless. Now you assert that there are good reasons for it, but > that really doesn't change that, to new contributors, it appears > pointless and is astonishing. My point is that the initial surprise will subside with time, by way of getting used to it. It is even possible that you will come to value this, as someone else who reported here. > Sorry, I still don't follow your reasoning. I still consider myself a > potential contributor (I didn't contribute much beyond that first little > foray), and not requiring me to copy my commit message into the > ChangeLog is not going to affect the quality of the commit measures in > any way. The only "message" that I get from this is "Great, sending > patches for Emacs doesn't require me to do a copy & paste anymore". As long as you don't have write access to the repository, you are not required to provide the log entries more than once, and so this issue doesn't really affect you. This issue is only relevant to those who actually push changes, because they might need to copy/paste into the ChangeLog file. ====================================================================== > > I think if we care at all about having ChangeLog in the releases, we > > should simply reinstate the file and maintain it in the repository. > > FWIW, that's not what I was hoping would come from this, and I think > that would be a retrograde step. Can you tell why? It solves all the problems you mention in your mail, at negligible costs. So it seems to be a clear winner. > For 1) and 2), experience shows that few people will bother to make > corrections. Is it an important drawback that few people bother to make corrections? If it is, then any solution that involves such corrections is not what we want. Also, is the situation with corrections worse or better than what it was when we maintained ChangeLog files in the repository? > PS For the record, to explain the actual merging issue as I see it: > > Suppose emacs-25 and master are synced at revision aaa and ChangeLog.2 > is up-to-date. emacs-25 advances to rev xxx, and independently master to > rev xxx'. emacs-25 gets ChangeLog.2 updated, and merged to master. Now > the footer of master ChangeLog.2 reports that it is up-to-date to rev > xxx. What does this mean for the changes on master between aaa and xxx'? > Because xxx on master is "after" xxx', I suspect it means they end up > missing from ChangeLog.2 forever, which is bad. No, they don't end up missing. They will in general be in the "wrong" order, time-wise, though. But what is the "right" order for this situation, where changes are made in parallel on several branches? Do we want them interwoven, in strict order of their commit times? Or do we want all the entries of a merge from the branch be kept together with the time stamp of the merge? If we want to continue keeping a single generated ChangeLog file on master and on the branch, we need to decide what is the desired result. > But maybe there's no such issue, or it is fixable with some git > trivia. The only "git trivia" that's possible is a custom merge driver (which AFAIK doesn't exist). Git itself is not aware of the special meaning of the time stamps in ChangeLog entries. We could also have some Lisp rearranging the entries in whatever order we decide we want it, after git-merge-changelog puts them in the order it thinks is right. > I don't know. That's why I made this bug report. AFAICS, the adopted > "solution" was simply to ignore the issue, which means > master/ChangeLog.2 is (probably) messed up at the moment. It is not messed, but it isn't in chronological order, either. And it looks like no one ran "make change-history" on master for several moons, so problems might become worse when they do. ====================================================================== > Giving people different permissions on different branches seems to make > sense. Overtime, people move toward master/emacs-25. AFAIK, Git (or is it Savannah?) doesn't support such granularity. > > Maybe we could have a half-way system, where commits are pushed to > > a branch that is "not fast-forward-only", and this branch is then > > auto-merged to the real (fast-forward-only) master branch after a delay > > (one day, maybe?) to give time to fix mess ups before they're cast > > in stone. > > I think that this would require some considerable co-ordination. If I > push a broken commit to devel branch, and then you fix this commit > through rebase, my copy of the branch (and everyone elses) is now > broken. Stefan was talking about merging, not rebasing. ====================================================================== > > Find a better and more reliable way of dealing with the problems described > > here, and I'll be the first to agree not to reintroduce ChangeLogs. > > As far as I understand so far, we have only a few needs. If I've understood > incorrectly, please let me know, as this thread has wandered in a few places. > > 1. We need a way to ensure quality commit messages from contributors. > 2. We'd like to be able to correct commit messages after the fact. > 3. We need a convenient way to both create and access this information. > 4. We want to publish the history of these commit messages in the tarball. > > The ChangeLog file and its format are one implementation of these needs that > has worked over the years. Are you saying that if we move to something else, > and it fulfills these criteria, you'd be just as happy with it? Yes. However, putting on my system engineer hat, let me make sure the list of requirements covers all the aspects: 5. The "history of commit messages" produced in 4 above should resemble a ChangeLog file (ideally, it should use the same format). 6. The solution should allow manual generation of the "history" file mentioned in 4, on demand, in reasonably short time, even if the repo clone does not include a built Emacs. (It is okay to use the installed Emacs binary, if necessary.) 7. The solution should support Git workflows we allow: merging between branches, rebasing local changes on upstream, cherry-picking from another branch, reverting a commit, tagging a commit, and amending an unpushed commit. "Support" here means that the solution should not impose limitations on these workflows, and the steps for updating whatever databases the solution will use should not require additional manual work as result of using these workflows. (I'm not saying these additions are something non-obvious, I just want to make sure we have everything covered.)