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 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 Thursday 18 August 2005 09:13, 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. Actually, it says "SW". Instead of searching up what SW meant, I decided to look at the GLEP itself where I figured the status would be written in English. It does have a status listed but apparently it is incorrect. -- Jason Stubbs pgpKr6kzGieXL.pgp Description: PGP signature
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 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`
-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 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`
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. IMHO the best thing is to re-investigate GLEP 31 when the council is formed. (At least I am under the impression that the council will have the authority to make decisions like this, after appropriate discussion and objections are heard) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpVwwizwKe4K.pgp Description: PGP signature
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`
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. :) You are the weakest link, goodbye! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
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. :) -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wed, 2005-08-17 at 09:04 -0400, Mike Frysinger wrote: > it was part joke and part seriousness ... i already have my commits scripted > with echangelog/repoman, but that isnt the point Ok - a bit hard to tell that you were joking there... > i delete one version for being old, stabilize another ebuild, and add yet > another ebuild as a rev bump Those are three different things and should be treated as such - also when committing. > which does not matter if you commit individual files firest with different > messages before running your bash funcs Committing files without using repoman? > 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 Same goes for the ChangeLog: if you do multiple commits with your proposal, all commits get their own ChangeLog entry. > not everyone uses echangelog [snip] > it does, but not everyone uses echangelog Why not? > heaven forbid you get a joke and laugh once in a while Jokes and sarcasm doesn't work well in e-mails, sorry. ./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`
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`
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`
Ok. I'll elaborate some. I was not planning to do so, but it appears there is some misinterpretation here. It was not my intention to let you all know that I think cvs and Changelogs are databases. They most certainly are, but that is not the point here, and may be saved for another discussion. The whole point was that I like avoiding storing data double (redundant), if that can be done easily. As from Mike's initial post I had the impression this is "easy" to do. It appears people don't have much different to tell in the cvs commit logs, or even neglect to type them at all, so it looked as not a that strange thing to take away the ability to be creative with the two different places you are able to type into. 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" Diego 'Flameeyes' Pettenò wrote: On Wednesday 17 August 2005 14:36, Grobian wrote: 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. There's a big difference: a database is intended to be used by apps, changelogs and commit logs are intended to be used by humans. Example? When you go in a forum you don't see the foreign key referring to users, to forums, to replies ... you see the actual data. Same for webpages. I still find a natural ChangeLog simpler to look at instead of using cvs log. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 14:36, Grobian wrote: > 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. There's a big difference: a database is intended to be used by apps, changelogs and commit logs are intended to be used by humans. Example? When you go in a forum you don't see the foreign key referring to users, to forums, to replies ... you see the actual data. Same for webpages. I still find a natural ChangeLog simpler to look at instead of using cvs log. -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgplBESuk6lEF.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wed, 2005-08-17 at 14:36 +0200, Grobian wrote: > 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. A ChangeLog is not a database - nor is a CVS commit log. > 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. You can not keep CVS commit logs up-to-date, since you can not change a given entry. ./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 14:16, Henrik Brix Andersen wrote: > Can you give an example of why you would want to use different commit > messages in a single commit? By the way, repoman commit doesn't allow you to do so: as it commits "in block" and you must call it also to change a single file in $FILESDIR (else you break the manifest), it makes more sense to do different commits. In this case it makes more sense to change the changelog just at the end with a summary of the changes, instead of polluting the changelog with "Fix for this file" ... "fix for that file" ... "last fix for that file" ... -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpF56dl9EL8p.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 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`
On 8/16/05, Ciaran McCreesh <[EMAIL PROTECTED]> wrote: > GLEP 31 is withdrawn until Gentoo gets some means of removing commit > access from people who say "nyah nyah I don't feel like following the > rules and so I'll just carry on breaking stuff as I see fit". As it > stands I've been told by various people that they have no interest in > ensuring that their commits are UTF-8 safe (even if there's an > automated check that warns them when they're about to break something), > and I don't consider it fair to force lots of repoman warnings upon > other developers who *do* care about that kind of thing who just happen > to be the next person to touch a package that got broken. Seems to me that such people should have their developer status revoked. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tuesday 16 August 2005 09:52 pm, Ciaran McCreesh wrote: > On Wed, 17 Aug 2005 10:46:23 +0900 Jason Stubbs <[EMAIL PROTECTED]> > > wrote: > | On Wednesday 17 August 2005 08:38, Ciaran McCreesh wrote: > | > GLEP 31 is withdrawn until Gentoo gets some means of removing commit > | > access from people who say "nyah nyah I don't feel like following > | > the rules and so I'll just carry on breaking stuff as I see fit". > | > As it stands I've been told by various people that they have no > | > interest in ensuring that their commits are UTF-8 safe (even if > | > there's an automated check that warns them when they're about to > | > break something), and I don't consider it fair to force lots of > | > repoman warnings upon other developers who *do* care about that > | > kind of thing who just happen to be the next person to touch a > | > package that got broken. > | > | Repoman could check the commit message for being valid UTF-8 and > | simply not allow the commit if it isn't. :) > > Well, I have a tool already that checks that. But it doesn't help when > we have developers who don't use repoman, who forcibly override repoman > fatal errors and who just randomly remove anything they think is > causing errors... yes, but lets work with what we have ... besides, it'll be easy to pick out who used repoman and who didnt by checking who has broken UTF8 commit messages ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wed, 17 Aug 2005 10:46:23 +0900 Jason Stubbs <[EMAIL PROTECTED]> wrote: | On Wednesday 17 August 2005 08:38, Ciaran McCreesh wrote: | > GLEP 31 is withdrawn until Gentoo gets some means of removing commit | > access from people who say "nyah nyah I don't feel like following | > the rules and so I'll just carry on breaking stuff as I see fit". | > As it stands I've been told by various people that they have no | > interest in ensuring that their commits are UTF-8 safe (even if | > there's an automated check that warns them when they're about to | > break something), and I don't consider it fair to force lots of | > repoman warnings upon other developers who *do* care about that | > kind of thing who just happen to be the next person to touch a | > package that got broken. | | Repoman could check the commit message for being valid UTF-8 and | simply not allow the commit if it isn't. :) Well, I have a tool already that checks that. But it doesn't help when we have developers who don't use repoman, who forcibly override repoman fatal errors and who just randomly remove anything they think is causing errors... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpjJiB3xd2EH.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 08:38, Ciaran McCreesh wrote: > GLEP 31 is withdrawn until Gentoo gets some means of removing commit > access from people who say "nyah nyah I don't feel like following the > rules and so I'll just carry on breaking stuff as I see fit". As it > stands I've been told by various people that they have no interest in > ensuring that their commits are UTF-8 safe (even if there's an > automated check that warns them when they're about to break something), > and I don't consider it fair to force lots of repoman warnings upon > other developers who *do* care about that kind of thing who just happen > to be the next person to touch a package that got broken. Repoman could check the commit message for being valid UTF-8 and simply not allow the commit if it isn't. :) -- Jason Stubbs pgp2l17QeUQGd.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Wednesday 17 August 2005 07:18, Mike Frysinger wrote: > suggestion: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last of > commit messages. You stole my idea! I guess I better ack it then. ;) -- Jason Stubbs pgpkxElZpa6Zd.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 16 Aug 2005 21:03:21 -0400 Alec Warner <[EMAIL PROTECTED]> wrote: | 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. There is a standard. It's called "whatever echangelog generates". If everyone used echangelog, nearly all of Mike's original points would be invalid. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpgIA6I8hx3o.pgp Description: PGP signature
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 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
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 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`
Mike Frysinger wrote: > suggestion: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last of commit > messages. As I already use a bash function called ecommit which writes a ChangeLog entry before it runs repoman and finally commits with the same message, I'm obviously all for this. -- [EMAIL PROTECTED] [EMAIL PROTECTED] http://citizen428.net/http://dev.gentoo.org/~citizen428/ GnuPG key: 0x90CA09E3/4D21 916E DBCE 72B8 CDC5 BD87 DE2D 91A2 90CA 09E3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, 16 Aug 2005 19:18:21 -0400 Mike Frysinger <[EMAIL PROTECTED]> wrote: | On Tuesday 16 August 2005 07:03 pm, Robin H. Johnson wrote: | > On Tue, Aug 16, 2005 at 06:18:29PM -0400, Mike Frysinger wrote: | > > logic: | > Question: | > - are CVS commit messages UTF8 safe? | | GLEP 31 came to mind when i was writing the e-mail but i forgot to | mention it ... maybe ciaran can hop in here GLEP 31 is withdrawn until Gentoo gets some means of removing commit access from people who say "nyah nyah I don't feel like following the rules and so I'll just carry on breaking stuff as I see fit". As it stands I've been told by various people that they have no interest in ensuring that their commits are UTF-8 safe (even if there's an automated check that warns them when they're about to break something), and I don't consider it fair to force lots of repoman warnings upon other developers who *do* care about that kind of thing who just happen to be the next person to touch a package that got broken. *shrug* So, if you want to be nice and use UTF-8, please do so. CVS is fine with it. Chances are whoever writes the CVS -> changelog tool will get it wrong with text wrapping at least once, but it's easy enough to fix. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpEvO7qnt4ds.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tuesday 16 August 2005 07:03 pm, Robin H. Johnson wrote: > On Tue, Aug 16, 2005 at 06:18:29PM -0400, Mike Frysinger wrote: > > logic: > Question: > - are CVS commit messages UTF8 safe? GLEP 31 came to mind when i was writing the e-mail but i forgot to mention it ... maybe ciaran can hop in here -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Tue, Aug 16, 2005 at 06:18:29PM -0400, Mike Frysinger wrote: > stop keeping ChangeLog files in CVS and instead, let them be generated > automagically by the cvs server using the last 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'm in favour of this. As an upstream developer of phpMyAdmin, we've used this procedure for a long time, using cvs2cl for this purpose (see my name in the cvs2cl contributers list as well ;-). We'd need to add a bit of code to put in the new ebuild extra stuff, but other than that, it should work out of the box. > logic: Question: - are CVS commit messages UTF8 safe? -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] Home Page : http://www.orbis-terrarum.net/?l=people.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpdvjQkemmFv.pgp Description: PGP signature
Re: [gentoo-dev] generating ChangeLog files automatically from `cvs commit`
On Aug 16, 2005, at 5:18 PM, Mike Frysinger wrote: logic: - i'm lazy - 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 - shrinks ChangeLog size for packages which have been around a very long time - 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) - easily standardize ChangeLog format wrt to header, copyrights, licensing, message formatting, name/date format - generate dates in UTC down to the second rather than having devs hand type them in their local timezone for just the current day - maybe some other things i havent thought of - i'm lazy Me likey. --Kito -mike -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
