Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Mike Frysinger wrote: suggestion: stop keeping ChangeLog files in CVS and instead, let them be generated automagically by the cvs server using the last arbitrary number of commit messages. if you really want to keep a commit message out of the changelog, then we come up with a simple policy of prefixing the message with a period (to keep it hidden :P). Just a little question: Would this work if somebody makes a CVS branch of something and then merges that branch back into the main trunk. The last commit would be the commit of the merge which hopefully only have the changes made on the branch. Thus gives double Changelog entries with the same meaning... or... no I think I got it... the period thing... to keep the merge commit hidden... guess I should have kept my mouth shut... *me goes back into lurk mode* /Andreas -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: suggestion: stop keeping ChangeLog files in CVS and instead, let them be generated automagically by the cvs server using the last arbitrary number of commit messages. if you really want to keep a commit message out of the changelog, then we come up with a simple policy of prefixing the message with a period (to keep it hidden :P). This would remove the possibility of correcting an entry in the ChangeLog in case of a typo or wrong assumption etc. logic: - i'm lazy That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. - i hate typing the samething twice (yes, bash scripting with echangelog can kind of take care of this) ... it doesnt handle if you want to use different commit messages for different files Can you give an example of why you would want to use different commit messages in a single commit? - shrinks ChangeLog size for packages which have been around a very long time This is the only real advantage I see from the above proposal - but I don't think that warrants the change. I doubt the saved space would be that significant. - forces cvs log messages to actually be worthwhile to read and makes browsing cvs history much nicer (it's very easy to look at the differences between two files and match up a good commit message rather than trying to figure out what message in the ChangeLog goes with it, assuming there is one) See my first answer (bash function). - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format Already done by echangelog. - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day I thought echangelog already did this based on TZ? - maybe some other things i havent thought of - i'm lazy See my first answer (bash function). Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Extracted from what Henrik Brix Andersen wrote: That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. See my first answer (bash function). See my first answer (bash function). From a database point of view, it is evil to duplicate values in an automated manner, just use a foreign key for such purposes. In other words, avoid duplication. If such bash function is a common tool then -- apart from wondering why it isn't part of the default suite -- this anti-duplication constraint is being broken massively. I like Mike's idea, because it deals with data redundancy and basically uses this 'foreign key' for the changelog. In other words: centralise the administration, don't make yourself having to keep multiple copies up-to-date, you're doomed to make errors with that. Just my two cents. -- Fabian Groffen eBuild Porting Gentoo for Mac OS X -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 15:14, Grobian wrote: The whole point was that I like avoiding storing data double (redundant), if that can be done easily. It has its own pro and cons as quite everything. You can avoid storing data double but makes more difficult to access it by the priority end users (devs; while users use changelogs, too, devs are the ones who really need to access them). As for the forum example: it wouldn't be a foreign key if there wasn't a left outer join to look up the respective value for the column. And so that left outer join is here to generate the Changelog to be backwards compatible The problem is where this is going to be generated. If this is going to be generated in the staging box before going in rsync, every dev that doesn't use rsync should use cvs log command to get the data, and this is quite unpractical (and requires bandwidth and adds load to the cvs server). So we should balance redundancy and load... I still think that a little redundancy of the changelogs saves us from having to add load to the staging or cvs box... -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpmkOpYnGABO.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 08:16 am, Henrik Brix Andersen wrote: On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: logic: - i'm lazy That's not a valid argument - you can use a bash function for calling echangelog and repoman as shown numerous times on this list. it was part joke and part seriousness ... i already have my commits scripted with echangelog/repoman, but that isnt the point - i hate typing the samething twice (yes, bash scripting with echangelog can kind of take care of this) ... it doesnt handle if you want to use different commit messages for different files Can you give an example of why you would want to use different commit messages in a single commit? i delete one version for being old, stabilize another ebuild, and add yet another ebuild as a rev bump - forces cvs log messages to actually be worthwhile to read and makes browsing cvs history much nicer (it's very easy to look at the differences between two files and match up a good commit message rather than trying to figure out what message in the ChangeLog goes with it, assuming there is one) See my first answer (bash function). which does not matter if you commit individual files firest with different messages before running your bash funcs it also pollutes the cvs log history for files ... if i make different fixes to different files but only commit with one message, you easily get a lot of noise - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format Already done by echangelog. not everyone uses echangelog - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day I thought echangelog already did this based on TZ? it does, but not everyone uses echangelog - maybe some other things i havent thought of - i'm lazy See my first answer (bash function). heaven forbid you get a joke and laugh once in a while -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Jon Portnoy wrote: On Wed, Aug 17, 2005 at 03:45:49PM +0200, Henrik Brix Andersen wrote: not everyone uses echangelog [snip] it does, but not everyone uses echangelog Why not? Because I don't want to. :) badjokeYou are the weakest link, goodbye!/badjoke -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: On Wed, Aug 17, 2005 at 03:45:49PM +0200, Henrik Brix Andersen wrote: not everyone uses echangelog [snip] it does, but not everyone uses echangelog Why not? Because I don't want to. :) I have no problem with people not using echangelog as long they write correctly formatted entries. It annoys the hell out of me when I come upon someone's hand-edited ChangeLog entry that lies (a missing '+' is the most common error). - -- QOTD: You want me to put *holes* in my ears and hang things from them? How... tribal. Aaron Walker [EMAIL PROTECTED] [ BSD | commonbox | cron | cvs-utils | mips | netmon | shell-tools | vim ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDA7cDC3poscuANHARAsV0AKDa+KehsJAk4J8C3UoDLUXq1FBbYQCfcdWL 8Q5Q8ZfmGsHWC6n56lfkXnw= =HfbF -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Thursday 18 August 2005 08:39, Aron Griffis wrote: Jason Stubbs wrote: [Tue Aug 16 2005, 09:46:23PM EDT] Repoman could check the commit message for being valid UTF-8 and simply not allow the commit if it isn't. :) Be careful, this steps over the line of creating policy by way of tools. This is similar to when I changed ekeyword to sort KEYWORDS. I don't quite get you here. GLEP 31 has been approved, no? That would make it seem to me that the above suggestion is just making the QA tool help enforce existing policy. If there's a flaw in that line of thinking, please point it out in case I fall into the same trap in some other instance. -- Jason Stubbs pgpna04UTQlmE.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: | I don't quite get you here. GLEP 31 has been approved, no? That would make | it seem to me that the above suggestion is just making the QA tool help | enforce existing policy. If there's a flaw in that line of thinking, please | point it out in case I fall into the same trap in some other instance. OK, here's your flaw. glep.gentoo.org says it's withdrawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDA9K6XVaO67S1rtsRAgr/AJ9rcYfnNs+2Lq1R15+YCVKmpV6bZwCgsWK0 cGOBwYM7LW/Owfu10CmqErA= =cWiz -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 08:13 pm, Donnie Berkholz wrote: Jason Stubbs wrote: | I don't quite get you here. GLEP 31 has been approved, no? That would make | it seem to me that the above suggestion is just making the QA tool help | enforce existing policy. If there's a flaw in that line of thinking, please | point it out in case I fall into the same trap in some other instance. OK, here's your flaw. glep.gentoo.org says it's withdrawn. it was withdrawn for the time being because it was felt that there isnt any real way to enforce it atm -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
Jason Stubbs wrote: [Wed Aug 17 2005, 08:09:39PM EDT] I don't quite get you here. GLEP 31 has been approved, no? That would make it seem to me that the above suggestion is just making the QA tool help enforce existing policy. If there's a flaw in that line of thinking, please point it out in case I fall into the same trap in some other instance. You might be right. I wasn't aware that GLEP 31 was approved before it was withdrawn. Regards, Aron -- Aron Griffis Gentoo Linux Developer pgp2qJCbzyyD7.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: suggestion: stop keeping ChangeLog files in CVS and instead, let them be generated automagically by the cvs server using the last arbitrary number of commit messages. if you really want to keep a commit message out of the changelog, then we come up with a simple policy of prefixing the message with a period (to keep it hidden :P). I like the idea. This should force people to actually make their cvs commit statements worth something. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Huddleston wrote: On Tue, 2005-08-16 at 18:18 -0400, Mike Frysinger wrote: suggestion: stop keeping ChangeLog files in CVS and instead, let them be generated automagically by the cvs server using the last arbitrary number of commit messages. if you really want to keep a commit message out of the changelog, then we come up with a simple policy of prefixing the message with a period (to keep it hidden :P). I like the idea. This should force people to actually make their cvs commit statements worth something. Also forcing a Changelog syntax makes portage's -l feature useful, since it attempts to parse the Changelog to provide sane entries...but some Changelogs don't seem to be in the correct syntax that the -l functionality requires. With a changelog standard this tool will be much more useful. - -Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQwKM2GzglR5RwbyYAQIWDw//WqWVf7BUhU++4RjHUYeLd95xxpPo7fmk EEebEFF7XMjIij9YYticJvOfDKsjzndU1Vkd/F27WHdDe/NCTGJQcCmTGjJfuKKa JRlD2U5Em5QF/j93dOeRJzOIBCbNRbxQevze4fU8SBfDdB1MRb0g3Y5fd0An991h 4GiO9UtCrNmSV51R6KFCBW76YbaV7pWFhDNJRjsWLhfQZh/sCKfugduv4boJVOih e2GIyiP4C0dUJnXlpbfsJuNsdxA783inKfSyy4p9+iuCdDd11rSvua2mz2HdZIVB 3BvWatoWTDflNpcxrmpHnmTj1MN9usC4van1Yq9KPogSBcwkIjyCmA7YVB5stFxs e2sBGDftmBXzC3ZOCa0IiWkE3Kr4gC5eCSHkDDJ7lW+u8FojSCxUm2my5RO4rSAr Wm0cB+LojvANZV93bz4qfF90B4IBr6w8fE6vCfC4WsoeW9G/EVtsjYvIHjvv20YZ cLQAgWDPsOT9bxfsHgJXAKqot3erKmVksBbV6cwWvxRkjwp0k09IpbEytxxFUs+3 CtC2TOERPk2NWdsfRimRSZz0zUUBOMzSUX1+88W4L7GASG7DuuXK7TpaZvMOwxEy UaBXhH+oAwk3lePXx/3HvQpC0T2oSUwGGr7CBR3z7VRhwAcO04AiHVt7tQie8dvO G5eWBwF0UCE= =Yj6C -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
