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

Responses inline below...

On Aug 1, 2015, at 13:15 , Martin Holmes wrote:

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

...

...

On Jul 31, 2015, at 17:07 , Martin Holmes mailto:mholmes@uvic.ca> 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.

Right, but in what way? If we’re talking svn updates in various places, we could use GitHub’s svn interface. It would just be a matter of changing the URLs...

...

...

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?

Maybe we ought to prioritize the switchover. I think we can still have a release, but maybe it’ll have to be later than usual.

...

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

That’s as may be :-), but there’s the potential for a lot of work having to be done on getting new folks up to speed, so I think we really want them to be learning just one system.

...

...

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.

We can do it on the TEST repo without penalty though, and then just nuke that when we’re happy with the results.

...

...

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

You can restrict wiki editing to collaborators only, which I think we should probably do.

Cheers, Martin

...

What do you all think?

-- tei-council mailing list tei-council@lists.tei-c.org mailto:tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived