[tei-council] gearing up for release 2.6.0

[Martin Holmes]

I've been trying to figure out what actual changes should be made to 
tcw22 based on these discussions, and I've made a couple of changes, but 
I think what we have now is pretty much correct:

<http://www.tei-c.org/Activities/Council/Working/tcw22.xml>

Could those of you who know anything about this take a look? The only 
remaining points of disagreement seem to be:

  - In "What you will need before you start", the original instructions, 
step 7, suggest that you must copy the tei user's ssh key to the SF 
server so that when logged in to tei-c as tei, you can upload the 
release to the SourceForge server (as your sf user). Sebastian has 
suggested that the key setup is not necessary, and that you can simply 
provide your SF credentials when prompted. Is this true for regular 
users, or is it only true for admins on the SF site (such as Sebastian 
or me)?

  - Peter proposes below that item 2 (turn on shell access on SF) should 
be combined with items 3 and 7. I don't actually agree with this, 
because item 2 needs to be done by one of the SF admins, so you have to 
wait for him/her to complete it before you can do item 7; while item 3 
requires action by the tei-c sysadmin. Therefore I haven't changed those 
steps so far, but I'm happy to do so if people do think they should be 
treated as a single step.

  - Peter suggests adding this:

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.“ *

I think that should be added as the final step in "What you will 
need...". Does everyone agree?

Cheers,
Martin

On 14-01-19 04:52 AM, Peter Stadler wrote:
>
> 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
>
>
>