All, I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like. Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard. Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future. GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository. (i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.) -James On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
I've added a README to https://github.com/TEIC/Guidelines-TEST with some basic "getting started" advice. Feedback, additions, and corrections gratefully accepted. We'll have to establish a workflow policy. Personally, I think that we should reserve the pull request approach for people outside the committers list. For big changes that we want reviewed before they are merged into the master branch I think we should just use branches. What I'd like to do is try to get people up to speed on using GitHub so that we're all in a position to comment and then we can establish a workflow. It sounds like James and I are in agreement about the basics. On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <James.Cummings@it.ox.ac.uk
wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
I just tested the following, and everything worked: - cloned the repo - created a no-pantor branch and switched to it - made changes in that branch and committed them - switched back to the master branch - merged the no-pantor branch - pushed master to GitHub - deleted the no-pantor branch I did all this locally. Under what circumstances would it make sense to push a branch to the server so others can see and contribute to it? Cheers, Martin On 15-07-30 07:17 AM, Hugh Cayless wrote:
I've added a README to https://github.com/TEIC/Guidelines-TEST with some basic "getting started" advice. Feedback, additions, and corrections gratefully accepted.
We'll have to establish a workflow policy. Personally, I think that we should reserve the pull request approach for people outside the committers list. For big changes that we want reviewed before they are merged into the master branch I think we should just use branches. What I'd like to do is try to get people up to speed on using GitHub so that we're all in a position to comment and then we can establish a workflow. It sounds like James and I are in agreement about the basics.
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <James.Cummings@it.ox.ac.uk
wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
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?
On Jul 31, 2015, at 14:18 , Martin Holmes <mholmes@uvic.ca> wrote:
Under what circumstances would it make sense to push a branch to the server so others can see and contribute to it?
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 <mholmes@uvic.ca> wrote:
Under what circumstances would it make sense to push a branch to the server so others can see and contribute to it?
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 <mholmes@uvic.ca> 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
On Jul 31, 2015, at 17:07 , Martin Holmes <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...
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. Remember that we may have as many as six new members in January (something I’d like to mark for later discussion, btw).
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.
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. What do you all think?
On 15-08-01 08:57 AM, Hugh Cayless wrote:
On Jul 31, 2015, at 17:07 , Martin Holmes <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.
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?
Responses inline below...
On Aug 1, 2015, at 13:15 , Martin Holmes <mholmes@uvic.ca> wrote:
On 15-08-01 08:57 AM, Hugh Cayless wrote:
On Jul 31, 2015, at 17:07 , Martin Holmes <mholmes@uvic.ca <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
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 <mholmes@uvic.ca> wrote:
On 15-08-01 08:57 AM, Hugh Cayless wrote:
On Jul 31, 2015, at 17:07 , Martin Holmes <mholmes@uvic.ca <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
On Aug 2, 2015, at 12:39 , Martin Holmes <mholmes@uvic.ca> wrote:
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.
I think the svn interface has some limitations, but yes, you should be able to do exactly that.
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).
Things like that and the uploads would indeed need to change. Getting the rev number is straightforward, but we would need to come up with a new process for uploading releases, as you note below.
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 <mailto: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.
Is it possible to have a single repo on GitHub, and simultaneously access it through git and svn? That seems very unlikely.
Likely or not, that's what I currently do with the Stylesheets repo. And several others. As I remarked several days ago.
On 15-08-02 02:12 PM, Lou Burnard wrote:
Is it possible to have a single repo on GitHub, and simultaneously access it through git and svn? That seems very unlikely.
Likely or not, that's what I currently do with the Stylesheets repo. And several others. As I remarked several days ago.
Ah, I didn't realize. So if I commit through the svn interface, and you commit through git, it's just handled automatically? In that case, what happens in the case where you do several commits in git, but then do a single push? Is that one commit to the svn interface, or are they all separate? It's conceivable that commits from git that predate commits in svn would be pushed up after the svn commits. If that all works nicely, though, then we don't have to make a decision about svn or git at all; people who like svn can use that, and people who like git can use that. The svn rev numbers will presumably still be sequential, so we can use that feature of svn rather than the git hashes for things like footers in the Guidelines, and we can mostly get by just by changing URLs. Nice. Cheers, Martin
Yeah, I think the svn interface is just a view of the git repo, so commits are commits, whether they came in from svn or git. My assumption is that with the svn interface, you're checking out from a single branch (e.g. master), and that each svn commit is equivalent to a git commit + push. Commits are going to come in the order they come in, and svn will see them in that order. Commit date is less important in git because each commit links explicitly to its parent(s). We could use the svn rev numbers, but I don't think that's as good, because we'll need to link to the commit referenced by that rev, and I'm not at all sure you can do that with the svn rev numbers. In any case, the Guidelines rev link is a solved problem—I fixed it months ago so that I could build my own copy of the Guidelines out of my git-svn copy. If you're building out of git, it should just work (with the proviso that my own copy of the repo is hard-coded right now—we'll have to change that of course). On Sun, Aug 2, 2015 at 10:40 PM, Martin Holmes <mholmes@uvic.ca> wrote:
On 15-08-02 02:12 PM, Lou Burnard wrote:
Is it possible to have a single repo on GitHub, and simultaneously
access it through git and svn? That seems very unlikely.
Likely or not, that's what I currently do with the Stylesheets repo. And several others. As I remarked several days ago.
Ah, I didn't realize. So if I commit through the svn interface, and you commit through git, it's just handled automatically?
In that case, what happens in the case where you do several commits in git, but then do a single push? Is that one commit to the svn interface, or are they all separate? It's conceivable that commits from git that predate commits in svn would be pushed up after the svn commits.
If that all works nicely, though, then we don't have to make a decision about svn or git at all; people who like svn can use that, and people who like git can use that. The svn rev numbers will presumably still be sequential, so we can use that feature of svn rather than the git hashes for things like footers in the Guidelines, and we can mostly get by just by changing URLs. Nice.
Cheers, Martin
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
Hi James, Your description of the two possible workflows are correct. Let's call the first one "distributed" (any one can hold a copy and send pull requests) and the second "centralized" (authorized committers can push to the repository under the TEIC account). If we follow the centralized system, we'd be replicating what we do on SVN, but with the extra step of pushing after committing. This is fine by me if we want to keep things simple. But if we (as council members) adopt the distributed system (ie you fix the bug you're assigned to in your copy, then send a pull request), there is a chance not just for human review (which might be superfluous at that point), but also for automated testing. If an error occurs, fix it, push again and it will get tested automatically etc. I think this is useful. Regardless of what process we adopt, anyone will still be able to send pull requests and that's a good thing. More tech-savvy users (such as former members of the council, among others) could send a feature request or a but *and* a patch at the same time, saving us time and focusing our work on review and approval. Raff On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <James.Cummings@it.ox.ac.uk
wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
On 30/07/15 15:21, Raffaele Viglianti wrote:
Hi James,
Your description of the two possible workflows are correct. Let's call the first one "distributed" (any one can hold a copy and send pull requests) and the second "centralized" (authorized committers can push to the repository under the TEIC account). Hurrah. I seem to understand the basics of version control. Quick, let me add it to my linkedIn profile. ;-)
If we follow the centralized system, we'd be replicating what we do on SVN, but with the extra step of pushing after committing. This is fine by me if we want to keep things simple. Good. I like simple. (Not just TEI Simple...)
But if we (as council members) adopt the distributed system (ie you fix the bug you're assigned to in your copy, then send a pull request), there is a chance not just for human review (which might be superfluous at that point), but also for automated testing. If an error occurs, fix it, push again and it will get tested automatically etc. I think this is useful. If we have a continuous integration environment set up (whether external like Jenkins or in-built like whatever it was called), then wouldn't that happen on any git push? Regardless of what process we adopt, anyone will still be able to send pull requests and that's a good thing. More tech-savvy users (such as former members of the council, among others) could send a feature request or a but *and* a patch at the same time, saving us time and focusing our work on review and approval.
That sounds idea and the combined form that Hugh suggests seems to make most sense to me. While you're on council (or some list of approved committers working on a particular thing) then you can push directly. For large but discrete changes that are likely to break a lot of things we use branches for ease of review. For members of the public, they can either submit issues directly, or as part of a pull request on a forked copy of the repository. -James
Raff
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk>> wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> Academic IT Services, University of Oxford
-- 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
PLEASE NOTE: postings to this list are publicly archived
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
Personally I have been using svn (rather than learning the rebarbative git syntax) in the same way as I always have on two or three github repos, with no discernible ill effects so far. Does that affect the issue? On 30/07/15 16:06, James Cummings wrote:
On 30/07/15 15:21, Raffaele Viglianti wrote:
Hi James,
Your description of the two possible workflows are correct. Let's call the first one "distributed" (any one can hold a copy and send pull requests) and the second "centralized" (authorized committers can push to the repository under the TEIC account). Hurrah. I seem to understand the basics of version control. Quick, let me add it to my linkedIn profile. ;-)
If we follow the centralized system, we'd be replicating what we do on SVN, but with the extra step of pushing after committing. This is fine by me if we want to keep things simple. Good. I like simple. (Not just TEI Simple...)
But if we (as council members) adopt the distributed system (ie you fix the bug you're assigned to in your copy, then send a pull request), there is a chance not just for human review (which might be superfluous at that point), but also for automated testing. If an error occurs, fix it, push again and it will get tested automatically etc. I think this is useful. If we have a continuous integration environment set up (whether external like Jenkins or in-built like whatever it was called), then wouldn't that happen on any git push? Regardless of what process we adopt, anyone will still be able to send pull requests and that's a good thing. More tech-savvy users (such as former members of the council, among others) could send a feature request or a but *and* a patch at the same time, saving us time and focusing our work on review and approval.
That sounds idea and the combined form that Hugh suggests seems to make most sense to me. While you're on council (or some list of approved committers working on a particular thing) then you can push directly. For large but discrete changes that are likely to break a lot of things we use branches for ease of review. For members of the public, they can either submit issues directly, or as part of a pull request on a forked copy of the repository.
-James
Raff
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk>> wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> Academic IT Services, University of Oxford
-- 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
PLEASE NOTE: postings to this list are publicly archived
On Thu, Jul 30, 2015 at 11:06 AM, James Cummings <James.Cummings@it.ox.ac.uk
wrote:
But if we (as council members) adopt the distributed system (ie you fix
the bug you're assigned to in your copy, then send a pull request), there is a chance not just for human review (which might be superfluous at that point), but also for automated testing. If an error occurs, fix it, push again and it will get tested automatically etc. I think this is useful.
If we have a continuous integration environment set up (whether external like Jenkins or in-built like whatever it was called), then wouldn't that happen on any git push?
Sure, it just would keep the repository "clean" until the error is fixed. Raff
Regardless of what process we adopt, anyone will still be able to send
pull requests and that's a good thing. More tech-savvy users (such as former members of the council, among others) could send a feature request or a but *and* a patch at the same time, saving us time and focusing our work on review and approval.
That sounds idea and the combined form that Hugh suggests seems to make most sense to me. While you're on council (or some list of approved committers working on a particular thing) then you can push directly. For large but discrete changes that are likely to break a lot of things we use branches for ease of review. For members of the public, they can either submit issues directly, or as part of a pull request on a forked copy of the repository.
-James
Raff
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings < James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk>> wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> Academic IT Services, University of Oxford
-- 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
PLEASE NOTE: postings to this list are publicly archived
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
On 30/07/15 16:18, Raffaele Viglianti wrote:
Sure, it just would keep the repository "clean" until the error is fixed.
I'm under no illusions that the TEI Repositories (both on SVN and Github) are in any way 'clean' at the moment. ;-) Ok, I can understand that as an approach, but for new members on council it would seem an awful barrier to fixing some small prose errors. That makes sense for some large or complex changes though. I think it best to have all the options at our disposal and choose when to use what. -James
Raff
Regardless of what process we adopt, anyone will still be able to send pull requests and that's a good thing. More tech-savvy users (such as former members of the council, among others) could send a feature request or a but *and* a patch at the same time, saving us time and focusing our work on review and approval.
That sounds idea and the combined form that Hugh suggests seems to make most sense to me. While you're on council (or some list of approved committers working on a particular thing) then you can push directly. For large but discrete changes that are likely to break a lot of things we use branches for ease of review. For members of the public, they can either submit issues directly, or as part of a pull request on a forked copy of the repository.
-James
Raff
On Thu, Jul 30, 2015 at 10:08 AM, James Cummings <James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> <mailto:James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk>>> wrote:
Can I ask what the policy for workflow will be on this? In SVN we all have a copy of the repository, make changes and commit them back directly. I'm told that the "right" way to do this in git is for us each to fork the master repository, set this up as a named upstream branch, before working pull from upstream, do our work, commit back to our repository, push this to our repository, and then issue a pull request back to the main TEI-C repository for review before it gets added. Or, if we have rights to do so, could we just push directly back into the TEI-C repository.
(i.e. I find the latter so much easier than the former, though understand why the former might be technically better if I was doing a huge set of changes. However, usually we aren't all touching the same set of files at the same times if my svn notifications are to be believed.)
-James
On 29/07/15 17:23, Hugh Cayless wrote:
All,
I've pushed up a copy of the my own synced git-svn copy of the Guidelines at https://github.com/TEIC/Guidelines-TEST. It's got issues and a wiki enabled, so we can try those out as we like.
Commits to SF should be synced periodically by my server, but changes you push here will not automatically be sent back to SourceForge (so you can try it out, with the foreknowledge that they'll probably be deleted). Currently in-use branches have been copied, but I've not bothered to create the old ones (the history is there, but they're not visible as branches). I've also not bothered to create any tags. This may be something that has to be done manually, as git tags are not branches, unlike svn tags. I bet there's a script for it somewhere. If not, I don't think writing one would be hard.
Request for everyone: can you try out cloning and messing with this? In particular I'd like to know what *doesn't* seem to work, and what the pain points are. All of them. We will obviously need to develop new tutorials/documentation for this, so I very much want to know what's confusing, up to and including "I don't even know where to start with this git thing". Please don't be shy or embarrassed—you will not be judged. This is a new thing to many of us and will be to new members of Council in the future.
GUI clients for those who prefer them are available at https://windows.github.com and https://mac.github.com. I've zero experience with them, but they may be nicer to work with if you're less comfortable in the command line.
-- Dr James Cummings, James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> <mailto:James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk>> Academic IT Services, University of Oxford
-- tei-council mailing list tei-council@lists.tei-c.org <mailto:tei-council@lists.tei-c.org> <mailto:tei-council@lists.tei-c.org <mailto:tei-council@lists.tei-c.org>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council
PLEASE NOTE: postings to this list are publicly archived
-- Dr James Cummings, James.Cummings@it.ox.ac.uk <mailto:James.Cummings@it.ox.ac.uk> Academic IT Services, University of Oxford
-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford
participants (5)
-
Hugh Cayless -
James Cummings -
Lou Burnard -
Martin Holmes -
Raffaele Viglianti