[tei-council] gearing up for release 2.6.0

[Peter Stadler]

Am 19.01.2014 um 00:27 schrieb Martin Holmes:
>> ** I do not find
>> a bin directory and svnUp.sh. What I do find is the TEI svn subtree
>> „P5“ at /var/www/vhosts/tei-c.org/private/P5. Question 2: Is a simple
>> ‚svn up‘ on that directory enough? * tei-database-rebuild.sh: I think
>> the hostname case switch must be adjusted
> 
> This looks like a major change from the original server setup. When you 
> log in as tei, where do you find yourself? (pwd)
/var/www/vhosts/tei-c.org

>> Some proposed changes to tcw22.xml so far: * "What you will need
>> before you start“, item 2 (Shell access on the TEI SourceForge
>> project) I propose to join this item with with 3 and 7 (well, not in
>> one item but to have these in a sequence) and to add a line to the
>> last one (or even a new item): Test it by trying to log in via ‚ssh
>> sfuser,tei at frs.sourceforge.net‘ *from* the tei server. That should
>> *not* prompt for a password while echoing „Welcome! This is a
>> restricted Shell Account. You can only copy files to/from here.“ *
> 
> Is "tei" a user on SourceForge? I didn't think so. I thought you had to 
> use your own SourceForge credentials there, hence the instruction to set 
> up ssh access.
Admittedly I just copied the "sfuser,tei at frs.sourceforge.net" from the script tei-install.sh and do not know what this comma actually does. The relevant line reads:
${ECHO} rsync -e ssh ${pname}-${version}.zip ${SFUSER},tei at frs.sourceforge.net:/home/frs/project/t/te/tei/${SFNAME}/${pname}-${version}.zip

Anyway I just tested 'ssh stadlerpeter at frs.sourceforge.net‘ from the TEI server and it works as well (without prompting for a password).

> 
>> "Step-by-step instructions“, item 1 ("Ensure that
>> P5/ReleaseNotes/readme-X.X.X.xml has been written“). The next line
>> declares this to be an uncommon procedure since the TEI Council chair
>> should have already create that file.
> 
> You should definitely look at that file one last time and make sure it's 
> OK. At least twice in the last few years the release process has had to 
> be repeated because of typos or omissions in that file. :-)
Yes, you are right — and I will do so three times ;-)

>> So, it seems to me the actual
>> issue for the release technician is to simply remove the „beta“ from
>> the version number which can easily be forgotten when you are not
>> looking closely at the following paragraph.
> 
> That seems correct in the instructions to me. It has its own complete step:
> 
> <quote>
> Edit the P5/VERSION file to the correct number
> This file consists only of the bare version number, followed by "alpha" 
> or "beta":
> 2.8.2beta
> For the release process, you need to remove the letters from the end, 
> leaving a pure version number:
> 2.8.2
> This changes the release from beta (or possibly alpha) to the actual 
> release version number. After the release process has been completed, 
> the number should be incremented appropriately, and "alpha" added to the 
> end of it:
> 2.8.3alpha
> signifying that the versions built subsequent to the release are now in 
> the alpha stage.
> </quote>
True. That one is clear.
But I was thinking of the version number within P5/ReleaseNotes/readme-2.6.0.xml

>> I propose to change the
>> heading to "remove „beta“ from P5/ReleaseNotes/readme-X.X.X.xml
>> version number“ and emphasize this procedure in the first
>> paragraph.
> 
> If you think that's clearer, we can certainly do that.
Well, now I think the main issue is to alter the version information in *two* places *and* to check P5/ReleaseNotes/readme-X.X.X.xml  for errors and missing items. If that’s consensus than I think the structure of the check list should reflect this.

>> The edge case of creating that file can be discussed
>> subsequently.
> 
> Rather than checking that it's there, the step should be to check that 
> it's correct and complete.
Yes, you are right.

Best
Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.village.Virginia.EDU/pipermail/tei-council/attachments/20140119/2049b0e5/attachment.bin