[RMs plz review] very rough notes on how to tag/roll mod_fcgid
1. Tagging
a. pre-tag edits
fcgid_conf.h
MODFCGID_VERSION_{MAJOR,MINOR,SUBVER} should already be correct
MODFCGID_VERSION_DEV should be 1
change MODFCGID_VERSION_DEV to 0
CHANGES-FCGID - just make sure version at top is correct
STATUS-FCGID - add new NEXTVERSION : in development line
fix date of last tag
commit; use rev as XX below
b. tag
svn copy -rXX https://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk \
https://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
c. post-tag edits
fcgid_conf.h
increase MODFCGID_VERSION_SUBVER by 1 and set MODFCGID_VERSION_DEV
to 1
CHANGES-FCGID - add new Changes with mod_fcgid NEXTVERSION to the top
commit
2. Rolling
a. create appropriate roll.sh
start with /httpd/site/trunk/dist/tools/roll.sh
remove these lines from script:
find ... autom4te*
cd ... ./buildconf
find ... autom4te
touches of generated mod_ssl files
fix line that removes STATUS to remove STATUS-FCGID instead
keep the lines to remove manual source files
zap the separate_deps logic
commit to mod_fcgid/build/roll.sh after successful use
(need releasecheck.sh in same directory)
*or*
commit to /httpd/site/trunk/dist/tools/roll-fcgid.sh
b. export the source
umask 022
svn export
http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
\
mod_fcgid-MAJOR.MINOR.SUBVER
c. run the roll script
d. test signatures
3. make available
a. on people.apache.org:
umask 002
move tarballs and signature files to /www/httpd.apache.org/dev/dist
b. after rsync, announce testing to d...@httpd.a.o and test...@httpd.a.o
Re: [RMs plz review] very rough notes on how to tag/roll mod_fcgid
Jeff Trawick wrote
1. Tagging
a. pre-tag edits
fcgid_conf.h
MODFCGID_VERSION_{MAJOR,MINOR,SUBVER} should already be correct
MODFCGID_VERSION_DEV should be 1
change MODFCGID_VERSION_DEV to 0
CHANGES-FCGID - just make sure version at top is correct
STATUS-FCGID - add new NEXTVERSION : in development line
fix date of last tag
commit; use rev as XX below
I'd not commit the MODFCGID_VERSION_DEV earlier, rather commit the above
to trunk, then change the MODFCGID_VERSION_DEV and copy your WC to the tag
b. tag
svn copy -rXX https://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk \
https://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
See above, copy tage from wc for release-only stuff
c. post-tag edits
fcgid_conf.h
increase MODFCGID_VERSION_SUBVER by 1 and set MODFCGID_VERSION_DEV
to 1
(no need to change MODFCGID_VERSION_DEV
Issac
Re: [RMs plz review] very rough notes on how to tag/roll mod_fcgid
On 1/21/2010 9:33 AM, Jeff Trawick wrote:
1. Tagging
a. pre-tag edits
fcgid_conf.h
MODFCGID_VERSION_{MAJOR,MINOR,SUBVER} should already be correct
MODFCGID_VERSION_DEV should be 1
change MODFCGID_VERSION_DEV to 0
CHANGES-FCGID - just make sure version at top is correct
STATUS-FCGID - add new NEXTVERSION : in development line
fix date of last tag
commit; use rev as XX below
Looks right.
b. tag
svn copy -rXX https://svn.apache.org/repos/asf/httpd/mod_fcgid/trunk \
https://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
c. post-tag edits
fcgid_conf.h
increase MODFCGID_VERSION_SUBVER by 1 and set MODFCGID_VERSION_DEV
to 1
CHANGES-FCGID - add new Changes with mod_fcgid NEXTVERSION to the top
commit
Yup, it's that straightforward.
2. Rolling
a. create appropriate roll.sh
start with /httpd/site/trunk/dist/tools/roll.sh
remove these lines from script:
find ... autom4te*
cd ... ./buildconf
find ... autom4te
touches of generated mod_ssl files
fix line that removes STATUS to remove STATUS-FCGID instead
keep the lines to remove manual source files
zap the separate_deps logic
commit to mod_fcgid/build/roll.sh after successful use
(need releasecheck.sh in same directory)
*or*
commit to /httpd/site/trunk/dist/tools/roll-fcgid.sh
I saw roll.sh as being overly complex for mod_ftp/mod_fcgid work, since
the tarball is simply the contents of the repository. But I'm happy to
review that, and svn.a.o/httpd/site/trunk/dist/tools/roll-fcgid.sh sounds
like a good place to put it. I had included STATUS-FCGID in previous
source tarballs but have no objection to it going away as it does with
httpd tarballs.
We should probably move some of the implements rfc notes from STATUS
over to some README-FCGID document, instead, that doesn't disappear :)
b. export the source
umask 022
svn export
http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER
\
mod_fcgid-MAJOR.MINOR.SUBVER
roll.sh should do the export, no? But the above is correct, and there is
a simple svn flag to export the same as '-crlf' flavor sources to be zipped.
c. run the roll script
d. test signatures
3. make available
This is entirely changed; there is a new repository for you to grab; check
out the following;
svn co https://dist.apache.org/repos/dist/dev/httpd/mod_fcgid fcgid-dev
svn co https://dist.apache.org/repos/dist/release/httpd/mod_fcgid fcgid-dist
Initially, svn add all the artifacts to the fcgid-dev repository for testing.
Once the vote has passed, you can literally do an svn mv between the two
locations to take it from httpd.a.o/dev/dist/ to www.a.o/dist/http/
Thanks to pquerna, svnpubsub magic will automagically update the files on the
site without further intervention.
https://svn.apache.org/repos/asf/httpd/site/trunk/ still needs to be touched
and then rebuilt and resynced. Depending on the visibility of release, you
might want to touch doap.rdf, xdocs/index.xml, and xdocs/download.xml to point
to the new release (and add a note of your key to download.xml).
Re: [RMs plz review] very rough notes on how to tag/roll mod_fcgid
On Thu, Jan 21, 2010 at 1:58 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote: On 1/21/2010 9:33 AM, Jeff Trawick wrote: 2. Rolling a. create appropriate roll.sh start with /httpd/site/trunk/dist/tools/roll.sh remove these lines from script: find ... autom4te* cd ... ./buildconf find ... autom4te touches of generated mod_ssl files fix line that removes STATUS to remove STATUS-FCGID instead keep the lines to remove manual source files zap the separate_deps logic commit to mod_fcgid/build/roll.sh after successful use (need releasecheck.sh in same directory) *or* commit to /httpd/site/trunk/dist/tools/roll-fcgid.sh I saw roll.sh as being overly complex for mod_ftp/mod_fcgid work, since the tarball is simply the contents of the repository. But I'm happy to review that, and svn.a.o/httpd/site/trunk/dist/tools/roll-fcgid.sh sounds like a good place to put it. I had included STATUS-FCGID in previous source tarballs but have no objection to it going away as it does with httpd tarballs. We should probably move some of the implements rfc notes from STATUS over to some README-FCGID document, instead, that doesn't disappear :) I kept STATUS-FCGID for now for consistency with previous tarball. b. export the source umask 022 svn export http://svn.apache.org/repos/asf/httpd/mod_fcgid/tags/MAJOR.MINOR.SUBVER \ mod_fcgid-MAJOR.MINOR.SUBVER roll.sh should do the export, no? But the above is correct, and there is a simple svn flag to export the same as '-crlf' flavor sources to be zipped. release.sh does the export, but unfortunately it has even more httpd-specific logic I see that svn has --native-eol CRLF in some docs... works for me... that crlf export and zip -r was run on Linux... c. run the roll script d. test signatures 3. make available This is entirely changed; there is a new repository for you to grab; check out the following; svn co https://dist.apache.org/repos/dist/dev/httpd/mod_fcgid fcgid-dev ahh :) I had just gotten to that point... now to see which user/pass will make that checkout work :( svn co https://dist.apache.org/repos/dist/release/httpd/mod_fcgid fcgid-dist Initially, svn add all the artifacts to the fcgid-dev repository for testing. Once the vote has passed, you can literally do an svn mv between the two locations to take it from httpd.a.o/dev/dist/ to www.a.o/dist/http/ Thanks to pquerna, svnpubsub magic will automagically update the files on the site without further intervention. https://svn.apache.org/repos/asf/httpd/site/trunk/ still needs to be touched and then rebuilt and resynced. Depending on the visibility of release, you might want to touch doap.rdf, xdocs/index.xml, and xdocs/download.xml to point to the new release (and add a note of your key to download.xml). speaking of key, the KEYS file at http://www.apache.org/dist/httpd/KEYS doesn't have the most recently committed contents... I guess we copy that from httpd/site/dist/KEYS to /dist/release/httpd/KEYS... thanks!
