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

On 15-08-01 08:57 AM, Hugh Cayless wrote:

...

On Jul 31, 2015, at 17:07 , Martin Holmes wrote:

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

What are the actual release dependencies on SF? Other than uploading release files, and presumably an svn update, what role does Sourceforge play? We could switch earlier, and just do the svn up from GitHub...

All sorts of scripts depend on SF, including Guidelines build scripts. There's a lot of work to do there.

...

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.

It seems to me that the main issue is not having people committing to the GitHub and Sourceforge repos simultaneously, though even if we did, I think any potential conflicts wouldn’t be hard to resolve. Personally, I’d like to get folks working with Git/GitHub as soon as possible. If we wait until after the next release, we’ll be risking leaving a mess for the next round of Council members to clean up.

Good point. Perhaps there isn't actually a need for a release in the near future? Instead of a release, we could make this transition the priority, to be accomplished by the end of the year?

Remember that we may have as many as six new members in January (something I’d like to mark for later discussion, btw).

Yes. But the continuing group is extremely competent. :-)

...

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.

This seems like potentially doing double the work, with the foreknowledge that we’re going to be throwing half that work away. Why not just figure out how to do the release on GitHub? We might need to do a "dry-run" release first.

Makes sense. Dry-runs are difficult to do when things like using the GitHub API are involved, though; you can't test properly without doing it for real.

...

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.

+1

...

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

I think the thing to do is have a wiki page, probably on the Guidelines repo, that has links to the release downloads, wherever they are. That way there’s still one place for people to go.

Not sure about a wiki page; that means virtually anyone can edit it and change links. That seems a bit risky. Cheers, Martin

What do you all think?