[Python-checkins] python/nondist/peps pep-0102.txt,1.4,1.5
fdrake@sourceforge.net
fdrake@sourceforge.net
Thu, 11 Apr 2002 07:11:30 -0700
Update of /cvsroot/python/python/nondist/peps
In directory usw-pr-cvs1:/tmp/cvs-serv3907
Modified Files:
pep-0102.txt
Log Message:
Excise SourceForge file releases from the release process.
Index: pep-0102.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0102.txt,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** pep-0102.txt 8 Apr 2002 20:46:24 -0000 1.4
--- pep-0102.txt 11 Apr 2002 14:11:27 -0000 1.5
***************
*** 126,149 ****
___ Tim Peters grabs the HTML and uses this to build the Windows
! installer. Tim then creates a new "release" named X.YaZ on the
! SourceForge file release manager. (Although, if you get there
! first, you should create the new release.)
!
! (Diversion: SF's file manager has "packages" and "releases". We
! use packages to name major upcoming releases, e.g. python-2.2 or
! python-2.1.1. Inside each package are a number of "releases"
! for each new actual release -- i.e. the thing you're building.
! An example of a release name is 2.2a3. Once created, packages
! and releases are never deleted, but old ones are hidden to
! reduce confusion. More on this below.)
!
! If this is the first release for this major Python version, Tim
! will create a new package containing the major Python version
! number.
___ Tim performs his Windows magic, generating an installer
! executable. He uploads this file to SourceForge under the
! release he just created. He then sends the RM a notice which
! includes the MD5 checksum of the Windows executable.
Note that Tim's creation of the Windows executable may generate
--- 126,135 ----
___ Tim Peters grabs the HTML and uses this to build the Windows
! installer.
___ Tim performs his Windows magic, generating an installer
! executable. He uploads this file to python.org. He then sends
! the RM a notice which includes the location and MD5 checksum of
! the Windows executable.
Note that Tim's creation of the Windows executable may generate
***************
*** 209,245 ****
figure out what the problem is.
! ___ Start your upload to SF. You need to get Python-2.1.2.tgz into
! SourceForge. This can take a while both because of the time it
! takes to upload such a huge file, /and/ because SF has a 30
! minute delay built into the file release process. The next few
! steps can be taken in parallel, so it's best to start the upload
! now and keep an eye on its progress.
!
! I've found that the `ncftpput' program is a great tool to use if
! you have it available. You can execute the following command to
! do the upload:
! % ncftpput upload.sf.net incoming Python-2.1.2.tgz
!
! If you don't have ncftpput around, you can use whatever ftp
! client you're comfortable with. Just be sure that you're
! uploading this to the "incoming" directory on upload.sf.net.
!
! ___ You also need to upload the tgz file to creosote.python.org.
! Usually Tim will have already uploaded the exe file to creosote,
! but if not, you'll need to do that too. These steps can take a
! long time depending on your network bandwidth. You have two
! choices:
!
! 1) Upload them to SF first, then wget them from creosote. Pros:
! easy to do; much friendlier to your own personal bandwidth.
! Cons: can take even longer because you're subject to the 30
! minute SF file upload delay, and the upload rate from
! SF->creosote never seems to get above 20 KB/sec.
!
! 2) scp both files from your own machine to creosote. Pros: you
! avoid the 30 minute SF delay. Cons: you don't get much else
! done if you're on a small pipe.
!
! I usually opt for #2.
___ While you're waiting, you can start twiddling the web pages to
--- 195,203 ----
figure out what the problem is.
! ___ You need to upload the tgz file to creosote.python.org. Tim
! will have already uploaded the exe file to creosote, but if not,
! you'll need to do that too. These steps can take a long time
! depending on your network bandwidth. scp both files from your
! own machine to creosote.
___ While you're waiting, you can start twiddling the web pages to
***************
*** 275,357 ****
above. Do NOT do a "make install" yet!
! ___ Now we're waiting for the ncftpput command, and the scp to
! creosote to finish. Da de da, da de dum, hmm, hmm, dum de dum.
!
! ___ Do the SourceForge file release dance.
!
! ___ Go to the Python project and click on "Admin"
! ___ Click on "Edit/Release Files"
! ___ Since Tim has usually by now created the package and release
! we're going to use, scroll down and click on "Edit Releases"
! for the package we're releasing into.
! ___ Find the release named X.YaZ and click on "Edit This Release"
!
! You should now perform Step 1 of the file release dance...
!
! ___ The "Status" field should be "Active" not "Hidden"
! ___ In the text box that says "Paste The Notes In", paste in all
! the "What's New" entries from the Misc/NEWS file that describe
! this major version of Python, /not/ just the ones for this
! particular release. E.g. If we're releasing Python 2.2a3,
! we'd include the "What's New" sections for Python 2.2a3,
! 2.2a2, and 2.2a1.
! ___ Leave the "Paste The Change Log In" section blank, but click
! on "Preserve my pre-formatted text".
! ___ Hit the Submit/Refresh button for Step 1.
!
! This will bring you back to the file release page. DO NOT do
! the following step until your ftp upload is complete! Once it
! is, you can perform Step 2 of the file release dance...
!
! ___ Click on the checkbox next to the file Python-X.YaZ.tgz. Be
! sure no other box is checked! Then click on the "Add Files
! and/or Refresh View" button for Step 2.
!
! And now, Step 3...
!
! ___ There should be exactly two files listed here, one is the tgz
! file you just added, and the other is the exe file that Tim
! added earlier.
! ___ For the tgz file, be sure that the "Processor" field says
! "Any" and the "File Type" field says "Source .gz".
! ___ Click on "Update/Refresh" for the .tgz file.
! ___ For the exe file, make sure that the "Processor" field says
! "i386" and the "File Type" field says "Other". Tim usually
! gets this right <wink>, but if not, make any necessary changes
! and click on "Update/Refresh" for the exe file.
!
! Step 4...
!
! DO NOT DO STEP 4 NOW. Wait until after you send out the email
! announcement to send the SF email notice.
!
! ___ Still on SF, click on the "Files" button at the top of the
! page. Find the release you've just made and click on it -- not
! on the tgz or exe file, but on the release link under the
! package name. E.g. package named python-2.2, click on the
! "2.2a3" link.
!
! This should be a page that says "Release Name: X.YaZ" and it
! should contain the "What's New" sections you pasted in earlier.
! Note the url of this page. Copy and paste it into the
! pydotorg/X.Y/new-index.ht file you created above. This is the
! "shownotes" link mentioned earlier.
!
! ___ Now click on the "Summary" link at the top of the page and
! scroll down to the "Latest File Releases" section. Find the
! package you just made a release for (the Version should be
! X.YaZ, and the Date should be today's date). Click on the
! "Download" link.
!
! Your new release should be highlighted in pink. Note the url
! for this page. Copy and paste it into the
! pydotorg/X.Y/new-index.ht file from above. This is the
! "showfiles" link mentioned earlier.
! ___ Now you need to go to creosote.python.org and move all the files
! in place over there. Our policy is that every Python version
! gets its own directory, but each directory may contain several
! releases. We keep all old releases, moving them into a "prev"
! subdirectory when we have a new release.
So, there's a directory called "2.2" which contains
--- 233,244 ----
above. Do NOT do a "make install" yet!
! ___ Now we're waiting for the scp to creosote to finish. Da de da,
! da de dum, hmm, hmm, dum de dum.
! ___ Once that's done you need to go to creosote.python.org and move
! all the files in place over there. Our policy is that every
! Python version gets its own directory, but each directory may
! contain several releases. We keep all old releases, moving them
! into a "prev" subdirectory when we have a new release.
So, there's a directory called "2.2" which contains
***************
*** 400,406 ****
python-dev@python.org
- ___ Go back to the file releases page on SF and complete Step 4,
- sending out the email notification.
-
___ Send a SourceForge News Item about the release. From the
project's "menu bar", select the "News" link; once in News,
--- 287,290 ----
***************
*** 415,424 ****
Now it's time to do some cleanup. These steps are very important!
- ___ Go back to SF, Admin->Edit/Release Files. Click on "Edit
- Releases" for the package you just added to. For each old
- release, click on "Edit This Release" and under Step 1, change
- the "Status" to "Hidden". Click on the Step 1 Submit/Refresh
- button.
-
___ Edit the file Include/patchlevel.h so that the PY_VERSION
string says something like "X.YaZ+". Note the trailing `+'
--- 299,302 ----
***************
*** 432,437 ****
___ For the extra paranoid, do a completely clean test of the
! release. This includes downloading the tarball from either
! SourceForge or www.python.org.
___ Make sure the md5 checksums match. Then unpack the tarball,
--- 310,315 ----
___ For the extra paranoid, do a completely clean test of the
! release. This includes downloading the tarball from
! www.python.org.
___ Make sure the md5 checksums match. Then unpack the tarball,
***************
*** 448,457 ****
Verify! This can be interleaved with Step 4. Pretend you're a
! user: download the files from python.org *and* SourceForge, and make
! Pythons from them. This step is too easy to overlook, and on
! several occasions we've had useless release files. Once a general
! server problem caused mysterious corruption of all files; once the
! source tarball got built incorrectly; more than once the file upload
! process on SF truncated files; and so on.
--- 326,335 ----
Verify! This can be interleaved with Step 4. Pretend you're a
! user: download the files from python.org, and make Python from
! it. This step is too easy to overlook, and on several occasions
! we've had useless release files. Once a general server problem
! caused mysterious corruption of all files; once the source tarball
! got built incorrectly; more than once the file upload process on
! SF truncated files; and so on.
***************
*** 468,475 ****
use this to build the MacOS versions. He may send you information
about the Mac release that should be merged into the informational
! pages on SourceForge or www.python.org. When he's done, he'll
! tag the branch something like "rX.YaZ-mac". He'll also be
! responsible for merging any Mac-related changes back into the
! trunk.
--- 346,352 ----
use this to build the MacOS versions. He may send you information
about the Mac release that should be merged into the informational
! pages on www.python.org. When he's done, he'll tag the branch
! something like "rX.YaZ-mac". He'll also be responsible for
! merging any Mac-related changes back into the trunk.