Re: [tei-council] Test GLs repo on GitHub

What happens with open tickets on SF? Presumably as a final comment on the ticket we need to look up a link to the new github 'issue' and mention that discussion has been closed there and this ticket is now being discussed at [link]. Then we can shut the ticket to further comments (without resolving it or changing its status? Not sure what the right thing to do is.) I am thinking about what happens when people follow links in our old release notes or emails to a ticket that was having ongoing discussion in SF. They need to be redirected to GitHub _and_ prevented from adding comments at the old location. -James On 31/07/15 22:07, Martin Holmes wrote:

On 15-07-31 11:55 AM, Hugh Cayless wrote:

...

I’d say in the event that you wanted any or all of us to be able to review what you’d done before it was merged to master, or really if you just wanted to—you might want to be able to share branches between multiple computers of your own. There’s no harm in it. I’d say if you want to push a branch, we should make sure there’s a decent descriptive naming system in place so that others will know what it is. Maybe nickname_issue-number? How does that sound?

That makes perfect sense.

Assuming Raff's experiments with the ticket transfer are trouble-free, our only remaining problem is how to handle releases (i.e. file downloads). I think we're looking at traffic of about 380 GB per year on the SF account. The GitHub release process does allow the inclusion of binary files as part of a release, and admin can create a release using the GH api:

https://developer.github.com/v3/repos/releases/#create-a-release

This allows for raw binaries to be uploaded. So our release script would have to be rewritten so that it uses something like curl to create a release and push the newly-created distro up. This is obviously going to take some work and some careful testing.

I wonder if we could stage our conversion to GitHub like this:

1. Do the next release in the normal way, all on SF.

2. Move the repo and tickets over to GitHub, freeze the SF repo and make tickets there read-only, with a notice that dev and ticket work is now happening on GH; meanwhile, we leave our releases/downloads still on SF, so all existing links etc. still work.

3. Rewrite the release scripts to work with GitHub and test them USING THE RELEASE WE JUST CREATED, until we're sure they'll work properly.

4. Once we're happy, change all our download pointers to point to the GitHub release instead of the SF release.

This will have to be done with P5, Roma and oxygen-tei; the others haven't had releases for a long time, so I would suggest that we simply archive those in the Vault on tei-c.

All four key projects (P5, oxygen-tei, Stylesheets and Roma) will then have their own Git repos, and those repos will presumably each have their own release packages. This is going to be more confusing for the user than simply looking at this:

https://sourceforge.net/projects/tei/files/?source=navbar

(which is already confusing enough), so we should probably find some way of aggregating all the release links in a single location. It's possible that we could write a web page to run on tei-c that uses JavaScript to query GitHub and build a table of all the latest releases for TEI-C projects.

Cheers, Martin

...

...

On Jul 31, 2015, at 14:18 , Martin Holmes wrote:

Under what circumstances would it make sense to push a branch to the server so others can see and contribute to it?

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford