Rather than relying on each developer to come up with an ecommit script to run echangelog and repoman interwinded, it would be nice if repoman handled it all by itself. It would also solve a problem that to me has been a bit annoying (having the ChangeLog out of date when calling echangelog). Thanks, Diego
Do we want to have separate notions of "commit message" and "ChangeLog message". If so, fine. If not, it seems like it makes more sense to do away with ChangeLog or generate it from the commit log if desired for things like the rsync tree.
Main reason is that even out of a CVS checkout it's easier to check the ChangeLog than asking CVS for it… Yes it should all go away in GIT, yadda yadda yadda but until then we're bound with CVS and the workaround that is ChangeLog :(
So, the plan is to generate a ChangeLog entry from the repoman commit message, and to write it to the ChangeLog immediately before performing the actual commit. When in --pretend mode, the ChangeLog will not be modified but a hypothetical ChangeLog entry will be displayed on stdout. Maybe we should add a --ask option so that you can preview the generate ChangeLog entry before allowing the commit to proceed?
If the ChangeLog already has uncommitted changes when repoman is invoked, should repoman assume that it doesn't need to generate a ChangeLog entry?
Before anything is done...why don't we bring this up on g-dev so it can be discussed...instead of just doing something and everyone else finding out about it later.
(In reply to comment #5) > Before anything is done...why don't we bring this up on g-dev so it can be > discussed...instead of just doing something and everyone else finding out about > it later. > Yeah good idea but I don't think anyone will object to that. One less command -> faster commits. I don't know about you but I use the same message in changelogs and CVS commits so this modification makes so much sense to me
(In reply to comment #6) > > Yeah good idea but I don't think anyone will object to that. One less command > -> faster commits. I don't know about you but I use the same message in > changelogs and CVS commits so this modification makes so much sense to me > And with git the same message will be forced so it makes sense to start the transition now. I agree this should get a spin on gentoo-dev. I will start a thread.
(In reply to comment #2) > Main reason is that even out of a CVS checkout it's easier to check the > ChangeLog than asking CVS for it… > > Yes it should all go away in GIT, yadda yadda yadda but until then we're bound > with CVS and the workaround that is ChangeLog :( With cvsps, a cache and cvs -NS Manifest rsync0 could generate ChangeLog files with some scripting IMO. However, if you do that, then what's the use of that file? Commits not necessarily reflect actual changes that is interesting for a user. See for more information e.g. the bottom of many ChangeLog files (e.g. mutt's one), and also read skel.ChangeLog. It explicitly mentions: "Any details about what exactly changed in the code should be added as a message when the changes are committed to cvs, not in this file."
During previous discussion on -dev I already asked this, so now I'll bring my concern here. 1. Once a month I need to update ChangeLog separately to add credits. What we do with autogenerated ChangeLog in such case? Empty commit message (with some whitespace change) to append credits, separate credits file or what (yea bad idea)? 2. Also I really think that fixing typos and whitespaces mr_bones_ does should be absent in ChangeLog. Taking 1. and 2. into account it looks like there are advantages of separate ChangeLog. I don't see any disadvantages (in case repoman will generate it automagically by default). So why generated ChangeLog?
*** Bug 327085 has been marked as a duplicate of this bug. ***
*** Bug 177290 has been marked as a duplicate of this bug. ***
*** Bug 365361 has been marked as a duplicate of this bug. ***
Hi, The council decided on the 2011-10-11 meeting to force the autogenerated changelogs The simplest solution would be make repoman call echangelog directly. Moreover, the ChangeLogs may be editable, hence repoman should take care of that, i.e if the only file that was edited is ChangeLog then repoman must not write the changelog upon commit. If you have questions regarding the policy, please say so and we will discuss it
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f03e9dbd874e6731683c0050d827318bd14360fb
(In reply to comment #14) > This is fixed in git: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f03e9dbd874e6731683c0050d827318bd14360fb Excellent. Thanks Zac. I presume this will be available to the next portage release (in both 2.1 and 2.2 branches right?) @Council. I believe we need to communicate this to developers. We probably need change to documents and a -dev-announce e-mail
The current implementation just calls echangelog. However, since repoman already collected all information about which files are changed etc from VCS, I'm looking into creating a patch that just makes repoman itself write the new ChangeLog entry, that is, doing it from Python straight.
(In reply to comment #15) > I presume this will be available to the next portage > release (in both 2.1 and 2.2 branches right?) Yes, it will be in portage-2.1.10.28 and 2.2.0_alpha68.
Created attachment 289939 [details, diff] echangelog functionality in repoman Please review and comment on this patch. I'm aware it probably needs some unicode tricking with the open calls, but I didn't yet manage to fully understand how that works. I've tested this patch, and made this commit with it: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/gdb-apple/ChangeLog?r1=1.15&r2=1.16&view=patch It supports new ebuilds as well.
(In reply to comment #18) > # if the ChangeLog was just created, add it to vcs > if new_changelog: > if not myautoadd: > print(red("!!! %s needs to be added to the master tree." % (changelog_path))) > sys.exit(1) The "if not myautoadd:" condition looks wrong. I don't think the myautoadd variable means what you think it means, and shouldn't we add the ChangeLog unconditionally as longs as --echangelog=y is enabled?
(In reply to comment #19) If we're not calling echangelog anymore, then we can remove these lines: if 'commit' == options.mode and \ options.echangelog == 'y' and \ find_binary('echangelog') is None: logging.error("echangelog not found, and --echangelog is enabled") sys.exit(1)
This thing was indeed a question mark when I wrote it. Now I rechecked, I see it makes probably more sense to append to the myautoadd list, and perform the "Auto-Adding missing ...." bit after the changelog update, such that it can add both Manifest and ChangeLog in one go.
Created attachment 290001 [details, diff] echangelog functionality in repoman v2 Ok, I addressed your two points. It reduces redundancy, so I like it a lot.
(In reply to comment #22) > Created attachment 290001 [details, diff] > echangelog functionality in repoman v2 Thanks, this is in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f757cd2a4dd2d3634743c207a4aadb3f217bfce1 Also, I've optimized it and added unicode support: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b655137b7b5f87c11a7e742b7ef0e028a1139677
--echangelog=force allows forced ChangeLog generation even when the vcs has detected that the ChangeLog has already been modified. http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=17a76f21f811e7e5741fa259ef5a635fddfdb75a
This is fixed in 2.1.10.28 and 2.2.0_alpha68.
