That’s it. I didn’t realize new element specs had to be included that way. I assumed they were picked up automatically. Thanks!

On May 31, 2015, at 17:56 , Lou Burnard wrote:

Where are you including this file in the build?

You need to xInclude it somewhere, presumably in the new section of TC-criticalapparatus.xml wherein you extol its virtues. Or in a standalone test ODD.

Take a look at e.g. line 660 of TC-CriticalApparatus.xml for enlightenment.

On 31/05/15 22:49, Hugh Cayless wrote:

...

Hello all,

Hope your trips home went well (or are going well). I’m having a hard time defining a new spec for <secl>. Does anybody know why https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... wouldn’t be picked up by any of the build processes I’m running? It’s as though the file is invisible. There’s clearly some incantation I’m not including, but I don’t know what it is…

Thanks, Hugh

/** * Hugh A. Cayless, Ph.D * hugh.cayless@duke.edu * Duke Collaboratory for Classics Computing (DC3) * http://blogs.library.duke.edu/dcthree/ **/

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

/blob/ is a GitHub thing, not a Git thing. It’s where you’d expect to find it, with all the other specs. Your and Lou’s diagnosis is correct though. Your confusion makes me wonder whether I ought not to do a Git tutorial at some point. It’s a different enough beast from svn that you can’t really extrapolate how it works from your knowledge of the latter. Would that help? Hugh

On May 31, 2015, at 18:22 , Syd Bauman wrote:

Can't tell, because I can't even find what you're doing. I cloned your repo[1]: $ git clone https://github.com/hcayless/TEI-Guidelines.git

But there was no blob/ directory, and no secl.xml. So I guess I'm not using the right approach to look for this.

But note that there needs to be something like

in a file that is included in the Guidelines, probably Source/Guidelines/en/PH-PrimarySources.xml in this case.

Notes ----- [1] If I understand correctlly, that's one real advantage of svn over git: I could have checked-out just the subdirectory I wanted from svn. I can't do that in git, can I?

...

Hope your trips home went well (or are going well). I’m having a hard time defining a new spec for <secl>. Does anybody know why https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... wouldn’t be picked up by any of the build processes I’m running? It’s as though the file is invisible. There’s clearly some incantation I’m not including, but I don’t know what it is… -- 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

Ok. I’m not 100% certain how we use rev numbers everywhere in the plumbing, so a list of some sort would be very helpful, but you can get an idea by looking at the footer of http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/index.html http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/index.html, my most recently generated copy of the Guidelines. The readme link is busted, because there is no readme, but the version number takes you to the latest commit in my GitHub repo. Basically, it’s just the first 7 digits of the commit hash.

On Jun 1, 2015, at 8:43 , Martin Holmes wrote:

+1 from me for a git/github tutorial, especially focused on how it would change our workflow with P5, and how we would replace the rev numbers that are so useful for us.

Cheers, Martin

On 15-06-01 04:31 AM, Hugh Cayless wrote:

...

/blob/ is a GitHub thing, not a Git thing. It’s where you’d expect to find it, with all the other specs. Your and Lou’s diagnosis is correct though.

Your confusion makes me wonder whether I ought not to do a Git tutorial at some point. It’s a different enough beast from svn that you can’t really extrapolate how it works from your knowledge of the latter. Would that help?

Hugh

...

On May 31, 2015, at 18:22 , Syd Bauman wrote:

Can't tell, because I can't even find what you're doing. I cloned your repo[1]: $ git clone https://github.com/hcayless/TEI-Guidelines.git

But there was no blob/ directory, and no secl.xml. So I guess I'm not using the right approach to look for this.

But note that there needs to be something like

in a file that is included in the Guidelines, probably Source/Guidelines/en/PH-PrimarySources.xml in this case.

Notes ----- [1] If I understand correctlly, that's one real advantage of svn over git: I could have checked-out just the subdirectory I wanted from svn. I can't do that in git, can I?

...

Hope your trips home went well (or are going well). I’m having a hard time defining a new spec for <secl>. Does anybody know why https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... wouldn’t be picked up by any of the build processes I’m running? It’s as though the file is invisible. There’s clearly some incantation I’m not including, but I don’t know what it is… -- 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

-- 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 know nothing about Sourceforge’s git offerings, but I imagine you can link to git commits in much the same way. Github’s issues allow you to do the same thing with projects hosted there. The difficulty would be in what to do if we moved repos, but kept bug/feature tracking in place. Sourceforge is long in the tooth. I don’t know whether, for example, we can expect any substantial upgrades in the future. I saw this http://blog.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fall... http://blog.gluster.org/2013/08/how-far-the-once-mighty-sourceforge-has-fall... and related commentary (including substantial rebuttal) on Hacker News recently (https://news.ycombinator.com/item?id=6262347 https://news.ycombinator.com/item?id=6262347). At the very least, I think we need to have an exit strategy for SF. Even the rebuttal on HN points out that it’s a money-loser for its parent company.

On Jun 1, 2015, at 12:11 , Martin Holmes wrote:

Hi Hugh,

That's excellent -- if we can link to the rev in github, we're half-way there. The other thing we do is track bug and FR fixes by rev number in our comments on tickets; our Guidelines might be updated to ask people to include the date and time of the commit, otherwise it's not easy to see the sequence of events.

Cheers, Martin

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

...

Ok. I’m not 100% certain how we use rev numbers everywhere in the plumbing, so a list of some sort would be very helpful, but you can get an idea by looking at the footer of http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/index.html http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/index.html <http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/index.html http://hcayless.github.io/TEI-Guidelines/Guidelines-web/en/html/index.html>, my most recently generated copy of the Guidelines. The readme link is busted, because there is no readme, but the version number takes you to the latest commit in my GitHub repo. Basically, it’s just the first 7 digits of the commit hash.

...

On Jun 1, 2015, at 8:43 , Martin Holmes wrote:

+1 from me for a git/github tutorial, especially focused on how it would change our workflow with P5, and how we would replace the rev numbers that are so useful for us.

Cheers, Martin

On 15-06-01 04:31 AM, Hugh Cayless wrote:

...

/blob/ is a GitHub thing, not a Git thing. It’s where you’d expect to find it, with all the other specs. Your and Lou’s diagnosis is correct though.

Your confusion makes me wonder whether I ought not to do a Git tutorial at some point. It’s a different enough beast from svn that you can’t really extrapolate how it works from your knowledge of the latter. Would that help?

Hugh

...

On May 31, 2015, at 18:22 , Syd Bauman wrote:

Can't tell, because I can't even find what you're doing. I cloned your repo[1]: $ git clone https://github.com/hcayless/TEI-Guidelines.git

But there was no blob/ directory, and no secl.xml. So I guess I'm not using the right approach to look for this.

But note that there needs to be something like

in a file that is included in the Guidelines, probably Source/Guidelines/en/PH-PrimarySources.xml in this case.

Notes ----- [1] If I understand correctlly, that's one real advantage of svn over git: I could have checked-out just the subdirectory I wanted from svn. I can't do that in git, can I?

...

Hope your trips home went well (or are going well). I’m having a hard time defining a new spec for <secl>. Does anybody know why https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... https://github.com/hcayless/TEI-Guidelines/blob/secl/P5/Source/Specs/secl.xm... wouldn’t be picked up by any of the build processes I’m running? It’s as though the file is invisible. There’s clearly some incantation I’m not including, but I don’t know what it is… -- 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

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

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

Reminder that the reimbursement form and instructions are here: http://www.tei-c.org/Admin/TEI_travel_form.pdf that the policies (still listed as in draft form??) are here: http://www.tei-c.org/Board/procedures.xml#body.1_div.8 and that the Federal per-diem meals-and-incidental-expenses (MIE) amount for Ann Arbor is $56, which means that individual meals (as opposed to 'group meals'), if not reimbursed by other means, may be reimbursed, if I understand this correctly, at a rate of $15.68 (28% of $56) for lunch and $17.92 (30% of $56) for dinner, without receipts required. The distinction between 'group' meals (to be charged at cost) and 'individual' meals (to be charged as per-diem expenses), remains a little doubtful to me, especially with regard to the lunches which were variously paid. pfs -- Paul Schaffner Digital Library Production Service PFSchaffner@umich.edu | http://www.umich.edu/~pfs/

On Jun 1, 2015, at 15:08 , Lou Burnard wrote:

On 01/06/15 17:37, Hugh Cayless wrote:

...

Sourceforge is long in the tooth. I don’t know whether, for example, we can expect any substantial upgrades in the future.

Being long in the tooth is not necessarily a bad thing. The TEI for example dates from quite a while back. Also I cannot see any grounds for your assertion that there won't be "substantial upgrades" in the future. I seem to remember quite major changes occurring roughly every two or three years over the last decade. Not all of them to my taste but again the same could be said of the TEI!

The TEI has not rested on its laurels. It’s been continuously updated during that time. Sourceforge’s development has essentially been outsourced to the Apache Allura project. I’m not encouraged by the clunkiness of the interface (even after the switch to Allura) that it’s in great shape.

...

At the very least, I think we need to have an exit strategy for SF. Even the rebuttal on HN points out that it’s a money-loser for its parent company.

We don't *need* an exit strategy for SF, any more than we need one for gitHub. We didn't have one for google code, but Mr Google gave us one anyway. No doubt if SF's owners suddenly decide that it's unable to continue for some reason, they too will propose one.

I can't help feeling that this github crusade is a bit of a side show. We do have quite a lot of more important things to be planning, which no-one else is going to help us with or determine.

Google is a bigger outfit and has policies for sunsetting projects. SF is owned by Dice.com http://dice.com/, best known for their jobs site and it is a cost center for them, therefore much less likely to get any love or attention. My worry is not so much that they may just turn the lights out one day, as that the site may gradually become unusable. I already see a lot more slowness and query timeouts than I used to. It’s starting to turn into a bad neighborhood. The Gimp certainly has a low opinion of it: http://www.gimp.org http://www.gimp.org/. I’m not arguing that it’s about to explode, but it’s clearly not on a sustainable path. Relying on any third party entails some level of risk. I’m constitutionally disposed not to ignore risk. No crusading here.

I know nothing about what it takes to manage an Allura site. There’s very little traffic on their Users list, which does not bode well. Github at least is profitable. They have a working business model, doing what they’re already doing. So their long-term sustainability looks better from where I’m sitting than Sourceforge’s. Martin is absolutely right though, it won’t last forever. Git’s sustainability picture is brighter too, because there would be many copies of the repository around.

On Jun 1, 2015, at 18:54 , Martin Holmes wrote:

All of this seems to suggest to me that we really should be considering migrating to an install of Allura on tei-c.org. Everything Hugh and others find worrying about SourceForge's current state will eventually come to pass with GitHub too; site like this inevitably rise and fall over time.

The issue of svn versus git is completely separate from SF versus GitHub, and we could perfectly well choose to use either svn or git in an Allura instance. We already have an svn repo set up on tei-c.org for jTEI materials.

Stability and uptime become a serious concern when you're running your own servers, though.

Cheers, Martin

On 15-06-01 01:36 PM, Hugh Cayless wrote:

...

...

On Jun 1, 2015, at 15:08 , Lou Burnard wrote:

On 01/06/15 17:37, Hugh Cayless wrote:

...

Sourceforge is long in the tooth. I don’t know whether, for example, we can expect any substantial upgrades in the future.

Being long in the tooth is not necessarily a bad thing. The TEI for example dates from quite a while back. Also I cannot see any grounds for your assertion that there won't be "substantial upgrades" in the future. I seem to remember quite major changes occurring roughly every two or three years over the last decade. Not all of them to my taste but again the same could be said of the TEI!

The TEI has not rested on its laurels. It’s been continuously updated during that time. Sourceforge’s development has essentially been outsourced to the Apache Allura project. I’m not encouraged by the clunkiness of the interface (even after the switch to Allura) that it’s in great shape.

...

...

At the very least, I think we need to have an exit strategy for SF. Even the rebuttal on HN points out that it’s a money-loser for its parent company.

We don't *need* an exit strategy for SF, any more than we need one for gitHub. We didn't have one for google code, but Mr Google gave us one anyway. No doubt if SF's owners suddenly decide that it's unable to continue for some reason, they too will propose one.

I can't help feeling that this github crusade is a bit of a side show. We do have quite a lot of more important things to be planning, which no-one else is going to help us with or determine.

Google is a bigger outfit and has policies for sunsetting projects. SF is owned by Dice.com http://dice.com/, best known for their jobs site and it is a cost center for them, therefore much less likely to get any love or attention. My worry is not so much that they may just turn the lights out one day, as that the site may gradually become unusable. I already see a lot more slowness and query timeouts than I used to. It’s starting to turn into a bad neighborhood. The Gimp certainly has a low opinion of it: http://www.gimp.org http://www.gimp.org/. I’m not arguing that it’s about to explode, but it’s clearly not on a sustainable path.

Relying on any third party entails some level of risk. I’m constitutionally disposed not to ignore risk. No crusading here.

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

Feature requests and bugs a back. See http://sourceforge.net/p/tei/feature-requests/ http://sourceforge.net/p/tei/feature-requests/ and http://sourceforge.net/p/tei/bugs/ http://sourceforge.net/p/tei/bugs/. Repos will be last apparently.

On Jul 20, 2015, at 16:18 , Majewski Stefan wrote:

If I had to make the decision on hosting a code repo, ci and bug-tracking and project maintenance service, I'd probably go for gitlab.com community edition, which appears to be free and rich in features and the choice of several currently quite successful institutitions and uses git as the foundation.

cheers, Stefan

Am 02.06.2015 um 14:04 schrieb Hugh Cayless:

...

I know nothing about what it takes to manage an Allura site. There’s very little traffic on their Users list, which does not bode well. Github at least is profitable. They have a working business model, doing what they’re already doing. So their long-term sustainability looks better from where I’m sitting than Sourceforge’s. Martin is absolutely right though, it won’t last forever. Git’s sustainability picture is brighter too, because there would be many copies of the repository around.

...

On Jun 1, 2015, at 18:54 , Martin Holmes wrote:

All of this seems to suggest to me that we really should be considering migrating to an install of Allura on tei-c.org. Everything Hugh and others find worrying about SourceForge's current state will eventually come to pass with GitHub too; site like this inevitably rise and fall over time.

The issue of svn versus git is completely separate from SF versus GitHub, and we could perfectly well choose to use either svn or git in an Allura instance. We already have an svn repo set up on tei-c.org for jTEI materials.

Stability and uptime become a serious concern when you're running your own servers, though.

Cheers, Martin

On 15-06-01 01:36 PM, Hugh Cayless wrote:

...

...

On Jun 1, 2015, at 15:08 , Lou Burnard wrote:

On 01/06/15 17:37, Hugh Cayless wrote:

...

Sourceforge is long in the tooth. I don’t know whether, for example, we can expect any substantial upgrades in the future. Being long in the tooth is not necessarily a bad thing. The TEI for example dates from quite a while back. Also I cannot see any grounds for your assertion that there won't be "substantial upgrades" in the future. I seem to remember quite major changes occurring roughly every two or three years over the last decade. Not all of them to my taste but again the same could be said of the TEI!

The TEI has not rested on its laurels. It’s been continuously updated during that time. Sourceforge’s development has essentially been outsourced to the Apache Allura project. I’m not encouraged by the clunkiness of the interface (even after the switch to Allura) that it’s in great shape.

...

...

At the very least, I think we need to have an exit strategy for SF. Even the rebuttal on HN points out that it’s a money-loser for its parent company. We don't *need* an exit strategy for SF, any more than we need one for gitHub. We didn't have one for google code, but Mr Google gave us one anyway. No doubt if SF's owners suddenly decide that it's unable to continue for some reason, they too will propose one.

I can't help feeling that this github crusade is a bit of a side show. We do have quite a lot of more important things to be planning, which no-one else is going to help us with or determine.

Google is a bigger outfit and has policies for sunsetting projects. SF is owned by Dice.com http://dice.com/, best known for their jobs site and it is a cost center for them, therefore much less likely to get any love or attention. My worry is not so much that they may just turn the lights out one day, as that the site may gradually become unusable. I already see a lot more slowness and query timeouts than I used to. It’s starting to turn into a bad neighborhood. The Gimp certainly has a low opinion of it: http://www.gimp.org http://www.gimp.org/. I’m not arguing that it’s about to explode, but it’s clearly not on a sustainable path.

Relying on any third party entails some level of risk. I’m constitutionally disposed not to ignore risk. No crusading here.

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

-- Mag. Stefan Majewski Projektmanager Abteilung Forschung und Entwicklung Österreichische Nationalbibliothek

Josefsplatz 1, 1015 Wien Tel.: (+43 1) 534 10-434 E-Mail: stefan.majewski@onb.ac.at Skype: stefan.majewski.onb.ac.at

-- 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 Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes wrote:

All of this seems to suggest to me that we really should be considering migrating to an install of Allura on tei-c.org. Everything Hugh and others find worrying about SourceForge's current state will eventually come to pass with GitHub too; site like this inevitably rise and fall over time.

This is not a valid reason to dismiss GitHub. It's true for everything, including the TEI and its servers. GitHub is incredibly usable and useful. It makes it simple to discuss tickets in the context of the code (unlike a mailing list), it's well integrated with other useful systems around the web, and some of us already use it daily and have other projects on it. I frankly don't understand this suspicion of GitHub that seems solely based on its popularity. We can only benefit from moving TEI development there.

The issue of svn versus git is completely separate from SF versus GitHub, and we could perfectly well choose to use either svn or git in an Allura instance. We already have an svn repo set up on tei-c.org for jTEI materials.

Stability and uptime become a serious concern when you're running your own servers, though.

Cheers, Martin

On 15-06-01 01:36 PM, Hugh Cayless wrote:

...

On Jun 1, 2015, at 15:08 , Lou Burnard

...

wrote:

On 01/06/15 17:37, Hugh Cayless wrote:

...

Sourceforge is long in the tooth. I don’t know whether, for example, we can expect any substantial upgrades in the future.

Being long in the tooth is not necessarily a bad thing. The TEI for example dates from quite a while back. Also I cannot see any grounds for your assertion that there won't be "substantial upgrades" in the future. I seem to remember quite major changes occurring roughly every two or three years over the last decade. Not all of them to my taste but again the same could be said of the TEI!

The TEI has not rested on its laurels. It’s been continuously updated during that time. Sourceforge’s development has essentially been outsourced to the Apache Allura project. I’m not encouraged by the clunkiness of the interface (even after the switch to Allura) that it’s in great shape.

...

At the very least, I think we need to have an exit strategy for

...

SF. Even the rebuttal on HN points out that it’s a money-loser for its parent company.

We don't *need* an exit strategy for SF, any more than we need one for gitHub. We didn't have one for google code, but Mr Google gave us one anyway. No doubt if SF's owners suddenly decide that it's unable to continue for some reason, they too will propose one.

I can't help feeling that this github crusade is a bit of a side show. We do have quite a lot of more important things to be planning, which no-one else is going to help us with or determine.

Google is a bigger outfit and has policies for sunsetting projects. SF is owned by Dice.com http://dice.com/, best known for their jobs site and it is a cost center for them, therefore much less likely to get any love or attention. My worry is not so much that they may just turn the lights out one day, as that the site may gradually become unusable. I already see a lot more slowness and query timeouts than I used to. It’s starting to turn into a bad neighborhood. The Gimp certainly has a low opinion of it: http://www.gimp.org http://www.gimp.org/. I’m not arguing that it’s about to explode, but it’s clearly not on a sustainable path.

Relying on any third party entails some level of risk. I’m constitutionally disposed not to ignore risk. No crusading here.

--

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

Another +1 from me for GitHub. Eventually we’ll have to move on from GitHub someday … but that one-time move is probably less painful than maintaining all those services (repo, ticketing, wiki, …) ourself for several years. Cheers Peter

Am 21.07.2015 um 16:22 schrieb Majewski Stefan :

Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti:

...

On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes wrote:

...

...

All of this seems to suggest to me that we really should be considering migrating to an install of Allura on tei-c.org. Everything Hugh and others find worrying about SourceForge's current state will eventually come to pass with GitHub too; site like this inevitably rise and fall over time.

This is not a valid reason to dismiss GitHub. It's true for everything, including the TEI and its servers.

That's indeed true. We should also not underestimate the effort that we would need to put into maintaining allura, gitlab or any of the other platforms. An effort that would be better spent at different areas. So, going with something that is available for free, and having a sensible way to move forward in case of desaster would be great. Given the distributed nature of git, people could continue working/contributing while the servers are down and while the project tries to find new hosting options.

...

GitHub is incredibly usable and useful. It makes it simple to discuss tickets in the context of the code (unlike a mailing list), it's well integrated with other useful systems around the web, and some of us already use it daily and have other projects on it.

Fair point. Really, I think the ease of use and the tight integration of working with code and ticketing saves much time we cold well use for other things.

...

I frankly don't understand this suspicion of GitHub that seems solely based on its popularity. We can only benefit from moving TEI development there.

And, we could benefit from popularity. I don't know if github is really the place where the smart kids are hanging out, but I am pretty confident that sf has ceased to be in that position.

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

It sounds like we're moving to GitHub, then. I presume that also means we're moving to git, so we'll have to get a little group of people together to update all the documentation that talks about svn and SourceForge. We should try to get all that done before the next intake of new Council members, otherwise they'll be severely confused. The first stage is planning. Can we maintain all the ticket history as well as the SVN history? It would be a shame to lose all that stuff. I have another small SVN project (CodeSharing) that I could migrate in advance as a test case. Would that help? Cheers, Martin On 2015-07-21 09:27 AM, Lou Burnard wrote:

I certainly agree that attempting to duplicate ticketing, repository, wiki etc etc services for ourselves would be ill advised.

On 21/07/15 16:41, Peter Stadler wrote:

...

Another +1 from me for GitHub. Eventually we’ll have to move on from GitHub someday … but that one-time move is probably less painful than maintaining all those services (repo, ticketing, wiki, …) ourself for several years.

Cheers Peter

...

Am 21.07.2015 um 16:22 schrieb Majewski Stefan :

...

On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes wrote:

...

...

All of this seems to suggest to me that we really should be considering migrating to an install of Allura on tei-c.org. Everything Hugh and others find worrying about SourceForge's current state will eventually come to pass with GitHub too; site like this inevitably rise and fall over time.

This is not a valid reason to dismiss GitHub. It's true for everything, including the TEI and its servers. That's indeed true. We should also not underestimate the effort that we would need to put into maintaining allura, gitlab or any of the other platforms. An effort that would be better spent at different areas. So, going with something that is available for free, and having a sensible way to move forward in case of desaster would be great. Given the distributed nature of git, people could continue working/contributing while the servers are down and while the project

Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti: tries to find new hosting options.

...

GitHub is incredibly usable and useful. It makes it simple to discuss tickets in the context of the code (unlike a mailing list), it's well integrated with other useful systems around the web, and some of us already use it daily and have other projects on it. Fair point. Really, I think the ease of use and the tight integration of working with code and ticketing saves much time we cold well use for other things.

...

I frankly don't understand this suspicion of GitHub that seems solely based on its popularity. We can only benefit from moving TEI development there. And, we could benefit from popularity. I don't know if github is really the place where the smart kids are hanging out, but I am pretty confident that sf has ceased to be in that position.

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

Sounds like it's a discussion for the next call? I'm happy to research and report on tools for migrating from SF to GitHub while keeping bugs. FRs, and SVN history. On Tue, Jul 21, 2015 at 1:24 PM, Lou Burnard wrote:

err I am not sure that we have agreed to do that have we?

Sent from Samsung Mobile

-------- Original message -------- From: Martin Holmes Date: 21/07/2015 17:44 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] ODD question

It sounds like we're moving to GitHub, then. I presume that also means we're moving to git, so we'll have to get a little group of people together to update all the documentation that talks about svn and SourceForge. We should try to get all that done before the next intake of new Council members, otherwise they'll be severely confused.

The first stage is planning. Can we maintain all the ticket history as well as the SVN history? It would be a shame to lose all that stuff.

I have another small SVN project (CodeSharing) that I could migrate in advance as a test case. Would that help?

Cheers, Martin

On 2015-07-21 09:27 AM, Lou Burnard wrote:

...

I certainly agree that attempting to duplicate ticketing, repository, wiki etc etc services for ourselves would be ill advised.

On 21/07/15 16:41, Peter Stadler wrote:

...

Another +1 from me for GitHub. Eventually we’ll have to move on from GitHub someday … but that one-time move is probably less painful than maintaining all those services (repo, ticketing, wiki, …) ourself for several years.

Cheers Peter

...

Am 21.07.2015 um 16:22 schrieb Majewski Stefan :

...

On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes wrote:

...

> All of this seems to suggest to me that we really should be > considering > migrating to an install of Allura on tei-c.org. Everything Hugh and > others find worrying about SourceForge's current state will > eventually come > to pass with GitHub too; site like this inevitably rise and fall > over time. > > This is not a valid reason to dismiss GitHub. It's true for everything, including the TEI and its servers. That's indeed true. We should also not underestimate the effort that we would need to put into maintaining allura, gitlab or any of the other platforms. An effort that would be better spent at different areas. So, going with something that is available for free, and having a sensible way to move forward in case of desaster would be great. Given the distributed nature of git, people could continue working/contributing while the servers are down and while the project

Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti: tries to find new hosting options.

...

GitHub is incredibly usable and useful. It makes it simple to discuss tickets in the context of the code (unlike a mailing list), it's well integrated with other useful systems around the web, and some of us already use it daily and have other projects on it. Fair point. Really, I think the ease of use and the tight integration of working with code and ticketing saves much time we cold well use for other things.

...

I frankly don't understand this suspicion of GitHub that seems solely based on its popularity. We can only benefit from moving TEI development there. And, we could benefit from popularity. I don't know if github is really the place where the smart kids are hanging out, but I am pretty confident that sf has ceased to be in that position.

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

-- 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 -- 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 agree that some people have that point of view, but it's not one I share myself. Every computer system ever built has either failed already, or will do so at some point in its future. There's no evidence to think that moving systems solely on that basis is a good idea. I agree however that a rational assessment of the cost of migration would be useful. But let's not do it out of panic or prejudice. On 21/07/15 21:37, Martin Holmes wrote:

My sense of the discussion is that we have so little faith in SF at this point that if it does come back up again completely, we should take the opportunity to move before another failure happens.

But it will help any discussion of whether to move or not if we have a good sense of how much work is involved and what might not be able to be migrated.

Cheers, Martin

On 2015-07-21 10:24 AM, Lou Burnard wrote:

...

err I am not sure that we have agreed to do that have we?

Sent from Samsung Mobile

-------- Original message -------- From: Martin Holmes Date: 21/07/2015 17:44 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] ODD question

It sounds like we're moving to GitHub, then. I presume that also means we're moving to git, so we'll have to get a little group of people together to update all the documentation that talks about svn and SourceForge. We should try to get all that done before the next intake of new Council members, otherwise they'll be severely confused.

The first stage is planning. Can we maintain all the ticket history as well as the SVN history? It would be a shame to lose all that stuff.

I have another small SVN project (CodeSharing) that I could migrate in advance as a test case. Would that help?

Cheers, Martin

On 2015-07-21 09:27 AM, Lou Burnard wrote:

...

I certainly agree that attempting to duplicate ticketing, repository, wiki etc etc services for ourselves would be ill advised.

On 21/07/15 16:41, Peter Stadler wrote:

...

Another +1 from me for GitHub. Eventually we’ll have to move on from GitHub someday … but that one-time move is probably less painful than maintaining all those services (repo, ticketing, wiki, …) ourself for several years.

Cheers Peter

...

Am 21.07.2015 um 16:22 schrieb Majewski Stefan :

...

On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes wrote:

>> All of this seems to suggest to me that we really should be >> considering >> migrating to an install of Allura on tei-c.org. Everything Hugh >> and >> others find worrying about SourceForge's current state will >> eventually come >> to pass with GitHub too; site like this inevitably rise and fall >> over time. >> >> This is not a valid reason to dismiss GitHub. It's true for everything, including the TEI and its servers. That's indeed true. We should also not underestimate the effort that we would need to put into maintaining allura, gitlab or any of the other platforms. An effort that would be better spent at different areas. So, going with something that is available for free, and having a sensible way to move forward in case of desaster would be great. Given the distributed nature of git, people could continue working/contributing while the servers are down and while the project

Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti: tries to find new hosting options.

...

GitHub is incredibly usable and useful. It makes it simple to discuss tickets in the context of the code (unlike a mailing list), it's well integrated with other useful systems around the web, and some of us already use it daily and have other projects on it. Fair point. Really, I think the ease of use and the tight integration of working with code and ticketing saves much time we cold well use for other things.

...

I frankly don't understand this suspicion of GitHub that seems solely based on its popularity. We can only benefit from moving TEI development there. And, we could benefit from popularity. I don't know if github is really the place where the smart kids are hanging out, but I am pretty confident that sf has ceased to be in that position.

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

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

Dear council, I'm too busy until Saturday to really look at this but I still resist moving to github for our trackers (to use sourceforge terminology). The feature request system at sf is *just* user friendly enough that Martin Mueller's archetypical humanities professor can submit a feature request. At github I do not believe that is the case. It is much more difficult for someone not used to developing code. Also github is built around issue tracking for bits of code not discussion of general requests in the abstract. If said prof arrived at our github pages and wanted to put in a feature request for a new element where and how would they do so? It is mostly set up in my experience for bug reports on existing code. We need to severely lower barriers to community involvement not increase them. If someone says 'they'll just find the most appropriate bit of the guidelines and add it as an issue there' then that is just wrong. They shouldn't need to master the underlying structure of the guidelines to say they need this element. If you say 'they'll add it as an issue to the repository add a whole' then this also doesn't work as they won't think about it as reporting an issue and terminologies really do matter here. I'm not against moving guidelines *development* from sourceforge to github but don't believe it has an appropriate ticketing system for our needs. Going back to his summer school now, James -- Dr James Cummings, Academic IT, University of Oxford -----Original Message----- From: Martin Holmes [mholmes@uvic.ca] Received: Tuesday, 21 Jul 2015, 22:48 To: tei-council@lists.tei-c.org [tei-council@lists.tei-c.org] Subject: Re: [tei-council] ODD question I share your caution, Lou, but I really don't like the look of SF these days. An outage of this length and severity is more than most projects will tolerate -- and imagine if this had happened to us in the middle of a release process. I fear this will cause a huge number of other projects to migrate as soon as they can, and that in itself will be enough to kill the service. Pros for moving to git[hub]: - Better prospects for stability. - Stylesheets and Simple are already there. - Better forking/merging. - Slightly better integration of ticketing and commits. - Cool factor (but see below). Cons: - Migration process. - Possible loss of important history. - Slightly higher learning curve for new users. - Need to rewrite/update a ton of documentation and links. - Loss of helpful sequential rev numbers. - Cool factor (but see above). One question for GitHub experts: I see the travis-ci service seems to be integrated with GitHub; does it seem likely that we could use that instead of (or in addition to) our own build servers? Cheers, Martin On 2015-07-21 01:59 PM, Lou Burnard wrote:

I agree that some people have that point of view, but it's not one I share myself. Every computer system ever built has either failed already, or will do so at some point in its future. There's no evidence to think that moving systems solely on that basis is a good idea. I agree however that a rational assessment of the cost of migration would be useful. But let's not do it out of panic or prejudice.

On 21/07/15 21:37, Martin Holmes wrote:

...

My sense of the discussion is that we have so little faith in SF at this point that if it does come back up again completely, we should take the opportunity to move before another failure happens.

But it will help any discussion of whether to move or not if we have a good sense of how much work is involved and what might not be able to be migrated.

Cheers, Martin

On 2015-07-21 10:24 AM, Lou Burnard wrote:

...

err I am not sure that we have agreed to do that have we?

Sent from Samsung Mobile

-------- Original message -------- From: Martin Holmes Date: 21/07/2015 17:44 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] ODD question

It sounds like we're moving to GitHub, then. I presume that also means we're moving to git, so we'll have to get a little group of people together to update all the documentation that talks about svn and SourceForge. We should try to get all that done before the next intake of new Council members, otherwise they'll be severely confused.

The first stage is planning. Can we maintain all the ticket history as well as the SVN history? It would be a shame to lose all that stuff.

I have another small SVN project (CodeSharing) that I could migrate in advance as a test case. Would that help?

Cheers, Martin

On 2015-07-21 09:27 AM, Lou Burnard wrote:

...

I certainly agree that attempting to duplicate ticketing, repository, wiki etc etc services for ourselves would be ill advised.

On 21/07/15 16:41, Peter Stadler wrote:

...

Another +1 from me for GitHub. Eventually we’ll have to move on from GitHub someday … but that one-time move is probably less painful than maintaining all those services (repo, ticketing, wiki, …) ourself for several years.

Cheers Peter

...

Am 21.07.2015 um 16:22 schrieb Majewski Stefan :

Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti: > On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes > wrote: > >>> All of this seems to suggest to me that we really should be >>> considering >>> migrating to an install of Allura on tei-c.org. Everything Hugh >>> and >>> others find worrying about SourceForge's current state will >>> eventually come >>> to pass with GitHub too; site like this inevitably rise and fall >>> over time. >>> >>> > This is not a valid reason to dismiss GitHub. It's true for > everything, > including the TEI and its servers. That's indeed true. We should also not underestimate the effort that we would need to put into maintaining allura, gitlab or any of the other platforms. An effort that would be better spent at different areas. So, going with something that is available for free, and having a sensible way to move forward in case of desaster would be great. Given the distributed nature of git, people could continue working/contributing while the servers are down and while the project tries to find new hosting options.

> GitHub is incredibly usable and useful. > It makes it simple to discuss tickets in the context of the code > (unlike a > mailing list), it's well integrated with other useful systems around > the > web, and some of us already use it daily and have other projects > on it. Fair point. Really, I think the ease of use and the tight integration of working with code and ticketing saves much time we cold well use for other things.

> I > frankly don't understand this suspicion of GitHub that seems solely > based > on its popularity. We can only benefit from moving TEI development > there. And, we could benefit from popularity. I don't know if github is really the place where the smart kids are hanging out, but I am pretty confident that sf has ceased to be in that position.

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

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

-- 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 agree. Generally, I find the GitHub page much more clutter-free and user friendly. Additionally, I guess the "archetypical humanities professor“ will raise her issue on the mailing list or in a conversation rather than entering anything in a ticket system. Admittedly, GitHub issues aren’t very elaborate, e.g. there are no private issues or sub issues. So, maybe we’d need to look for some other ticket system? But first, we’d need to sum up our activities at SourceForge and what services need to be migrated. E.g. are we using mailing lists there (E.g. SIG ontologies), Discussions, News, etc? We’ll need to move the release binaries, as well. I don’t expect much trouble migrating the repo (and its history) itself but with all the other stuff … There is no need to panic but I’d say we need an exit strategy now. Anyone volunteering to be the „migration officer“? ;) Cheers Peter

Am 22.07.2015 um 11:39 schrieb Hugh Cayless :

Just briefly because I’m in a meeting all day. I don’t understand this objection. It doesn’t square at all with how I understand GitHub Issues to work. Issues can be anything at all. They are linked to a repo, but a repo can be anything at all too. I don’t agree that creating them is any more complicated than creating sourceforge tickets!

That said, there’s certainly not 1::1 feature/functionality parity between GH and SF tickets and work would have to be done to come up with a new, equivalent way of doing things on GitHub.

...

On Jul 22, 2015, at 7:34 , James Cummings wrote:

Dear council,

I'm too busy until Saturday to really look at this but I still resist moving to github for our trackers (to use sourceforge terminology).

The feature request system at sf is *just* user friendly enough that Martin Mueller's archetypical humanities professor can submit a feature request. At github I do not believe that is the case. It is much more difficult for someone not used to developing code.

Also github is built around issue tracking for bits of code not discussion of general requests in the abstract. If said prof arrived at our github pages and wanted to put in a feature request for a new element where and how would they do so? It is mostly set up in my experience for bug reports on existing code. We need to severely lower barriers to community involvement not increase them.

If someone says 'they'll just find the most appropriate bit of the guidelines and add it as an issue there' then that is just wrong. They shouldn't need to master the underlying structure of the guidelines to say they need this element. If you say 'they'll add it as an issue to the repository add a whole' then this also doesn't work as they won't think about it as reporting an issue and terminologies really do matter here.

I'm not against moving guidelines *development* from sourceforge to github but don't believe it has an appropriate ticketing system for our needs.

Going back to his summer school now, James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Martin Holmes [mholmes@uvic.ca] Received: Tuesday, 21 Jul 2015, 22:48 To: tei-council@lists.tei-c.org [tei-council@lists.tei-c.org] Subject: Re: [tei-council] ODD question

I share your caution, Lou, but I really don't like the look of SF these days. An outage of this length and severity is more than most projects will tolerate -- and imagine if this had happened to us in the middle of a release process. I fear this will cause a huge number of other projects to migrate as soon as they can, and that in itself will be enough to kill the service.

Pros for moving to git[hub]:

- Better prospects for stability.

- Stylesheets and Simple are already there.

- Better forking/merging.

- Slightly better integration of ticketing and commits.

- Cool factor (but see below).

Cons:

- Migration process.

- Possible loss of important history.

- Slightly higher learning curve for new users.

- Need to rewrite/update a ton of documentation and links.

- Loss of helpful sequential rev numbers.

- Cool factor (but see above).

One question for GitHub experts: I see the travis-ci service seems to be integrated with GitHub; does it seem likely that we could use that instead of (or in addition to) our own build servers?

Cheers, Martin

On 2015-07-21 01:59 PM, Lou Burnard wrote:

...

I agree that some people have that point of view, but it's not one I share myself. Every computer system ever built has either failed already, or will do so at some point in its future. There's no evidence to think that moving systems solely on that basis is a good idea. I agree however that a rational assessment of the cost of migration would be useful. But let's not do it out of panic or prejudice.

On 21/07/15 21:37, Martin Holmes wrote:

...

My sense of the discussion is that we have so little faith in SF at this point that if it does come back up again completely, we should take the opportunity to move before another failure happens.

But it will help any discussion of whether to move or not if we have a good sense of how much work is involved and what might not be able to be migrated.

Cheers, Martin

On 2015-07-21 10:24 AM, Lou Burnard wrote:

...

err I am not sure that we have agreed to do that have we?

Sent from Samsung Mobile

-------- Original message -------- From: Martin Holmes Date: 21/07/2015 17:44 (GMT+00:00) To: tei-council@lists.tei-c.org Subject: Re: [tei-council] ODD question

It sounds like we're moving to GitHub, then. I presume that also means we're moving to git, so we'll have to get a little group of people together to update all the documentation that talks about svn and SourceForge. We should try to get all that done before the next intake of new Council members, otherwise they'll be severely confused.

The first stage is planning. Can we maintain all the ticket history as well as the SVN history? It would be a shame to lose all that stuff.

I have another small SVN project (CodeSharing) that I could migrate in advance as a test case. Would that help?

Cheers, Martin

On 2015-07-21 09:27 AM, Lou Burnard wrote:

...

I certainly agree that attempting to duplicate ticketing, repository, wiki etc etc services for ourselves would be ill advised.

On 21/07/15 16:41, Peter Stadler wrote: > Another +1 from me for GitHub. > Eventually we’ll have to move on from GitHub someday … but that > one-time move is probably less painful than maintaining all those > services (repo, ticketing, wiki, …) ourself for several years. > > Cheers > Peter > >> Am 21.07.2015 um 16:22 schrieb Majewski Stefan >> : >> >> Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti: >>> On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes >>> wrote: >>> >>>>> All of this seems to suggest to me that we really should be >>>>> considering >>>>> migrating to an install of Allura on tei-c.org. Everything Hugh >>>>> and >>>>> others find worrying about SourceForge's current state will >>>>> eventually come >>>>> to pass with GitHub too; site like this inevitably rise and fall >>>>> over time. >>>>> >>>>> >>> This is not a valid reason to dismiss GitHub. It's true for >>> everything, >>> including the TEI and its servers. >> That's indeed true. We should also not underestimate the effort that >> we would need to put into maintaining allura, gitlab or any of the >> other platforms. An effort that would be better spent at different >> areas. So, going with something that is available for free, and >> having a sensible way to move forward in case of desaster would be >> great. Given the distributed nature of git, people could continue >> working/contributing while the servers are down and while the project >> tries to find new hosting options. >> >>> GitHub is incredibly usable and useful. >>> It makes it simple to discuss tickets in the context of the code >>> (unlike a >>> mailing list), it's well integrated with other useful systems around >>> the >>> web, and some of us already use it daily and have other projects >>> on it. >> Fair point. Really, I think the ease of use and the tight integration >> of working with code and ticketing saves much time we cold well use >> for other things. >> >> >>> I >>> frankly don't understand this suspicion of GitHub that seems solely >>> based >>> on its popularity. We can only benefit from moving TEI development >>> there. >> And, we could benefit from popularity. I don't know if github is >> really the place where the smart kids are hanging out, but I am >> pretty confident that sf has ceased to be in that position. >> >> >> -- >> 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 > >

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

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

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

James, If you switch the issue tracker on (it is off by default IIRC), issues can be written by anyone who is logged in to GitHub, just like in SourceForge. In fact, the form is easier and fewer steps are required to get to where you need to be. You can also comment directly on code, like you say, but that will be more useful to us than others. If we're crazy and want to allow non-registered users to submit issues, we can even do that (with an external tool): https://gitreports.com/ We can create a structure of "labels" to reproduce the same categories that we have in SF: Bug vs. Feature Request; Red, Orange, and Green levels. Labels can be added by default, such as "red". The one annoying thing is that only repository owners can add labels, so users won't be able to decide whether they're reporting a bug of sending a feature request themselves. We will be able to close and solve issues with one commit just by including the number; all will be tracked and made publicly accessible on the platform with plenty of cross-references. Commits are hierarchical, which makes sequential numbers as meaningful as non-random xml:ids... :-) Peter makes a good point about other services currently on SF. GitHub releases can include binary files, so that's no problem. The news haven't been updated since 2007, we could just archive those on the TEI wiki. The forum has only 9 questions, we could archive it and close it since TEI-L is the place where the all but these nine questions are asked. The mailing lists will have to be migrated to tei-c.org and that sadly will take work, but it will be more consistent with the other active lists that we already maintain. If after more discussion we agree that GitHub is TEI's next home, I'd be happy to volunteer as "migration officer", but will likely need help from those who unlike me know SourceForce inside out, and from other GitHub users in the group. Raff On Wed, Jul 22, 2015 at 7:06 AM, Hugh Cayless wrote:

The repo itself is probably sort of already done, because I’ve been maintaining a copy on GitHub anyway that’s synced hourly. I haven’t checked, but it probably has the last copy of the repo before it went offline.

...

On Jul 22, 2015, at 11:01 , Peter Stadler wrote:

I agree. Generally, I find the GitHub page much more clutter-free and user friendly. Additionally, I guess the "archetypical humanities professor“ will raise her issue on the mailing list or in a conversation rather than entering anything in a ticket system.

Admittedly, GitHub issues aren’t very elaborate, e.g. there are no private issues or sub issues. So, maybe we’d need to look for some other ticket system? But first, we’d need to sum up our activities at SourceForge and what services need to be migrated. E.g. are we using mailing lists there (E.g. SIG ontologies), Discussions, News, etc? We’ll need to move the release binaries, as well. I don’t expect much trouble migrating the repo (and its history) itself but with all the other stuff … There is no need to panic but I’d say we need an exit strategy now. Anyone volunteering to be the „migration officer“? ;)

Cheers Peter

...

Am 22.07.2015 um 11:39 schrieb Hugh Cayless :

Just briefly because I’m in a meeting all day. I don’t understand this objection. It doesn’t square at all with how I understand GitHub Issues to work. Issues can be anything at all. They are linked to a repo, but a repo can be anything at all too. I don’t agree that creating them is any more complicated than creating sourceforge tickets!

That said, there’s certainly not 1::1 feature/functionality parity between GH and SF tickets and work would have to be done to come up with a new, equivalent way of doing things on GitHub.

...

On Jul 22, 2015, at 7:34 , James Cummings wrote:

Dear council,

I'm too busy until Saturday to really look at this but I still resist moving to github for our trackers (to use sourceforge terminology).

The feature request system at sf is *just* user friendly enough that Martin Mueller's archetypical humanities professor can submit a feature request. At github I do not believe that is the case. It is much more difficult for someone not used to developing code.

Also github is built around issue tracking for bits of code not discussion of general requests in the abstract. If said prof arrived at our github pages and wanted to put in a feature request for a new element where and how would they do so? It is mostly set up in my experience for bug reports on existing code. We need to severely lower barriers to community involvement not increase them.

If someone says 'they'll just find the most appropriate bit of the guidelines and add it as an issue there' then that is just wrong. They shouldn't need to master the underlying structure of the guidelines to say they need this element. If you say 'they'll add it as an issue to the repository add a whole' then this also doesn't work as they won't think about it as reporting an issue and terminologies really do matter here.

I'm not against moving guidelines *development* from sourceforge to github but don't believe it has an appropriate ticketing system for our needs.

Going back to his summer school now, James

-- Dr James Cummings, Academic IT, University of Oxford

-----Original Message----- From: Martin Holmes [mholmes@uvic.ca] Received: Tuesday, 21 Jul 2015, 22:48 To: tei-council@lists.tei-c.org [tei-council@lists.tei-c.org] Subject: Re: [tei-council] ODD question

I share your caution, Lou, but I really don't like the look of SF these days. An outage of this length and severity is more than most projects will tolerate -- and imagine if this had happened to us in the middle of a release process. I fear this will cause a huge number of other projects to migrate as soon as they can, and that in itself will be enough to kill the service.

Pros for moving to git[hub]:

- Better prospects for stability.

- Stylesheets and Simple are already there.

- Better forking/merging.

- Slightly better integration of ticketing and commits.

- Cool factor (but see below).

Cons:

- Migration process.

- Possible loss of important history.

- Slightly higher learning curve for new users.

- Need to rewrite/update a ton of documentation and links.

- Loss of helpful sequential rev numbers.

- Cool factor (but see above).

One question for GitHub experts: I see the travis-ci service seems to be integrated with GitHub; does it seem likely that we could use that instead of (or in addition to) our own build servers?

Cheers, Martin

...

I agree that some people have that point of view, but it's not one I share myself. Every computer system ever built has either failed already, or will do so at some point in its future. There's no evidence to think that moving systems solely on that basis is a good idea. I agree however that a rational assessment of the cost of migration would be useful. But let's not do it out of panic or prejudice.

On 21/07/15 21:37, Martin Holmes wrote:

...

My sense of the discussion is that we have so little faith in SF at this point that if it does come back up again completely, we should take the opportunity to move before another failure happens.

But it will help any discussion of whether to move or not if we have a good sense of how much work is involved and what might not be able to be migrated.

Cheers, Martin

On 2015-07-21 10:24 AM, Lou Burnard wrote: > err I am not sure that we have agreed to do that have we? > > > Sent from Samsung Mobile > > > > -------- Original message -------- > From: Martin Holmes > Date: 21/07/2015 17:44 (GMT+00:00) > To: tei-council@lists.tei-c.org > Subject: Re: [tei-council] ODD question > > > It sounds like we're moving to GitHub, then. I presume that also means > we're moving to git, so we'll have to get a little group of people > together to update all the documentation that talks about svn and > SourceForge. We should try to get all that done before the next intake > of new Council members, otherwise they'll be severely confused. > > The first stage is planning. Can we maintain all the ticket history as > well as the SVN history? It would be a shame to lose all that stuff. > > I have another small SVN project (CodeSharing) that I could migrate in > advance as a test case. Would that help? > > Cheers, > Martin > > On 2015-07-21 09:27 AM, Lou Burnard wrote: >> I certainly agree that attempting to duplicate ticketing, repository, >> wiki etc etc services for ourselves would be ill advised. >> >> >> >> On 21/07/15 16:41, Peter Stadler wrote: >>> Another +1 from me for GitHub. >>> Eventually we’ll have to move on from GitHub someday … but that >>> one-time move is probably less painful than maintaining all those >>> services (repo, ticketing, wiki, …) ourself for several years. >>> >>> Cheers >>> Peter >>> >>>> Am 21.07.2015 um 16:22 schrieb Majewski Stefan >>>> : >>>> >>>> Am 21.07.2015 um 15:40 schrieb Raffaele Viglianti: >>>>> On Mon, Jun 1, 2015 at 6:54 PM, Martin Holmes >>>>> wrote: >>>>> >>>>>>> All of this seems to suggest to me that we really should be >>>>>>> considering >>>>>>> migrating to an install of Allura on tei-c.org. Everything Hugh >>>>>>> and >>>>>>> others find worrying about SourceForge's current state will >>>>>>> eventually come >>>>>>> to pass with GitHub too; site like this inevitably rise and fall >>>>>>> over time. >>>>>>> >>>>>>> >>>>> This is not a valid reason to dismiss GitHub. It's true for >>>>> everything, >>>>> including the TEI and its servers. >>>> That's indeed true. We should also not underestimate the effort

...

...

>>>> we would need to put into maintaining allura, gitlab or any of

...

...

>>>> other platforms. An effort that would be better spent at different >>>> areas. So, going with something that is available for free, and >>>> having a sensible way to move forward in case of desaster would be >>>> great. Given the distributed nature of git, people could continue >>>> working/contributing while the servers are down and while the

On 2015-07-21 01:59 PM, Lou Burnard wrote: that the project

...

...

>>>> tries to find new hosting options. >>>> >>>>> GitHub is incredibly usable and useful. >>>>> It makes it simple to discuss tickets in the context of the code >>>>> (unlike a >>>>> mailing list), it's well integrated with other useful systems around >>>>> the >>>>> web, and some of us already use it daily and have other projects >>>>> on it. >>>> Fair point. Really, I think the ease of use and the tight integration >>>> of working with code and ticketing saves much time we cold well use >>>> for other things. >>>> >>>> >>>>> I >>>>> frankly don't understand this suspicion of GitHub that seems solely >>>>> based >>>>> on its popularity. We can only benefit from moving TEI development >>>>> there. >>>> And, we could benefit from popularity. I don't know if github is >>>> really the place where the smart kids are hanging out, but I am >>>> pretty confident that sf has ceased to be in that position. >>>> >>>> >>>> -- >>>> 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 >>> >>> >> > -- > 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 >

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

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

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

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

See also http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restorati... On 18/07/15 23:29, Hugh Cayless wrote:

Sourceforge has been down for a couple of days, no ETA (see https://www.reddit.com/r/sysadmin/comments/3do9k0/sourceforge_is_down_due_to... https://www.reddit.com/r/sysadmin/comments/3do9k0/sourceforge_is_down_due_to... for some interesting commentary). So *now* do we need an exit strategy? Or is it too late?

Hugh

...

On Jun 1, 2015, at 20:08 , Lou Burnard wrote:

On 01/06/15 17:37, Hugh Cayless wrote:

...

Sourceforge is long in the tooth. I don’t know whether, for example, we can expect any substantial upgrades in the future. Being long in the tooth is not necessarily a bad thing. The TEI for example dates from quite a while back. Also I cannot see any grounds for your assertion that there won't be "substantial upgrades" in the future. I seem to remember quite major changes occurring roughly every two or three years over the last decade. Not all of them to my taste but again the same could be said of the TEI!

...

At the very least, I think we need to have an exit strategy for SF. Even the rebuttal on HN points out that it’s a money-loser for its parent company. We don't *need* an exit strategy for SF, any more than we need one for gitHub. We didn't have one for google code, but Mr Google gave us one anyway. No doubt if SF's owners suddenly decide that it's unable to continue for some reason, they too will propose one.

I can't help feeling that this github crusade is a bit of a side show. We do have quite a lot of more important things to be planning, which no-one else is going to help us with or determine.

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