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

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?