[HACKERS] CVS commit messages and backpatching
FYI, in going through the release notes, I would like to remind committers that it is important to mention if the commit was backpatched to any earlier release. Not only is this valuable for making the release notes, but it also helps people looking at the commit message. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] CVS commit messages and backpatching
Bruce Momjian wrote: FYI, in going through the release notes, I would like to remind committers that it is important to mention if the commit was backpatched to any earlier release. Backpatches usually happen after the commit to the head branch has been made, so the information is not available at that time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] CVS commit messages and backpatching
Peter Eisentraut wrote: Bruce Momjian wrote: FYI, in going through the release notes, I would like to remind committers that it is important to mention if the commit was backpatched to any earlier release. Backpatches usually happen after the commit to the head branch has been made, so the information is not available at that time. Well, I have a script where I create a single commit message that I use to apply to multiple branches. Usually you know at the time of commit to HEAD that you are going to backpatch. And in such cases, it is helpful to mention it as part of the HEAD commit. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CVS commit messages and backpatching
Bruce Momjian [EMAIL PROTECTED] writes: FYI, in going through the release notes, I would like to remind committers that it is important to mention if the commit was backpatched to any earlier release. Not only is this valuable for making the release notes, but it also helps people looking at the commit message. With the standard output from cvs2cl, this is pretty obvious anyway, no? I see entries like 2006-08-29 09:39 teodor * contrib/tsearch2/: tsvector.c (REL8_1_STABLE), tsvector.c: Remove pos comparison in silly_cmp_tsvector(): it is not a semantically significant so it seems to me that explicit mention of back-patching is mostly redundant. (Of course, this requires the committer to commit all the branches at about the same time, which I make an effort to do precisely so that the cvs log looks nice. If some time elapses between patching and back-patching then a mention in the commit message is definitely needed.) regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS commit messages and backpatching
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: FYI, in going through the release notes, I would like to remind committers that it is important to mention if the commit was backpatched to any earlier release. Not only is this valuable for making the release notes, but it also helps people looking at the commit message. With the standard output from cvs2cl, this is pretty obvious anyway, no? I see entries like 2006-08-29 09:39 teodor * contrib/tsearch2/: tsvector.c (REL8_1_STABLE), tsvector.c: Remove pos comparison in silly_cmp_tsvector(): it is not a semantically significant so it seems to me that explicit mention of back-patching is mostly redundant. (Of course, this requires the committer to commit all the branches at about the same time, which I make an effort to do precisely so that the cvs log looks nice. If some time elapses between patching and back-patching then a mention in the commit message is definitely needed.) I pull activity only from HEAD, so I do not see that tag. In fact, I use our src/tools/pgcvslog rather than cvslog. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] CVS commit messages and backpatching
Bruce Momjian [EMAIL PROTECTED] writes: I pull activity only from HEAD, so I do not see that tag. In fact, I use our src/tools/pgcvslog rather than cvslog. Not sure why we are maintaining our own script when there are much better things out there: http://freshmeat.net/projects/cvs2cl.pl/ regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] CVS commit messages and backpatching
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I pull activity only from HEAD, so I do not see that tag. In fact, I use our src/tools/pgcvslog rather than cvslog. Not sure why we are maintaining our own script when there are much better things out there: http://freshmeat.net/projects/cvs2cl.pl/ Well, my script produces output that is closer to what I need to create the release notes. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CVS commit messages and backpatching
Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I pull activity only from HEAD, so I do not see that tag. In fact, I use our src/tools/pgcvslog rather than cvslog. Not sure why we are maintaining our own script when there are much better things out there: http://freshmeat.net/projects/cvs2cl.pl/ Well, my script produces output that is closer to what I need to create the release notes. If there are procedures, please document them. Nobody ever told me much when I was given committer status, and I just did what it looked like you guys did, and no doubt made some mistakes. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] CVS commit messages and backpatching
Andrew Dunstan wrote: Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I pull activity only from HEAD, so I do not see that tag. In fact, I use our src/tools/pgcvslog rather than cvslog. Not sure why we are maintaining our own script when there are much better things out there: http://freshmeat.net/projects/cvs2cl.pl/ Well, my script produces output that is closer to what I need to create the release notes. If there are procedures, please document them. Nobody ever told me much when I was given committer status, and I just did what it looked like you guys did, and no doubt made some mistakes. I guess the question is whether it is possible using cvs2cl to show only HEAD, and then show if the same commit message also appears in the most recent back branch. And will that always work reliably? -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] CVS commit messages and backpatching
Bruce Momjian [EMAIL PROTECTED] writes: I guess the question is whether it is possible using cvs2cl to show only HEAD, and then show if the same commit message also appears in the most recent back branch. It's so rare that we make a back-branch patch without a corresponding HEAD patch that I'm not clear why you are concerned about showing only HEAD for this purpose. I've always found that cvs2cl's behavior shows me exactly what I want to know for CVS log searching (and that includes release note making). If the output format isn't quite what you want, maybe you could turn on its XML-output option and then munge that into HTML. I've never had occasion to play with the XML-format option myself. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
