Re: [tei-council] ODD question

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