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

2 Aug 2015

      Hi Hugh,

More responses inline:

On 15-08-02 07:53 AM, Hugh Cayless wrote:
...
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...
This brings up something I don't adequately understand:

Is it possible to have a single repo on GitHub, and simultaneously 
access it through git and svn? That seems very unlikely. Assuming that's 
not the case -- or assuming it's inadvisable because it would result in 
all sorts of confusion -- then we could consider first moving everything 
to GitHub but staying with svn, and then later transitioning to git. 
That would be much easier initially, and it would also enable us to move 
rather quickly in answer to the perceived fragility of SourceForge 
without having to immediately undertake the more complex transition to git.

There are lots of script calls that depend on svn (getting the svn 
revision number, for instance). But there are also commands which upload 
packages to SourceForge directly, with dependence on SSH keys and the 
like -- this from tei-install.sh is an example:

upload()
{
     echo upload ${pname}-${version}.zip to Sourceforge ${SFNAME} as 
user ${SFUSER}
     ${ECHO} rsync -e ssh ${pname}-${version}.zip 
${SFUSER},tei@frs.sourceforge.net:/home/frs/project/t/te/tei/${SFNAME}/${pname}-${version}.zip
}

My all-too-cursory reading of the GitHub docs suggests that the 
equivalent would have to be achieved as part of a release using curl 
against the GitHub API; I don't think you can simply rsync a file up to 
GitHub and have it appear as a release. So while switching to GH with 
svn rather than git would definitely simplify a lot of things, doing an 
actual release would not be simply a matter of changing 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.
We don't have an explicit policy of two releases a year, do we? I think 
it's just a convention we fell into.
...
...
...
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.
New folks often don't really come fully online until after the first 
FtF, so I think it would be reasonable to make that a target for having 
a complete transition done, with all the documentation updated.
...
...
...
...
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.
Good point. As long as we avoid steps like making announcements and 
updating RSS feeds. :-)
...
...
...
...
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.
True, but I still think a wiki page seems semi-official compared with a 
page on the actual tei-c site.

Cheers,
Martin
...
...
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