RE: git

[<dav...@di...>]

It's true areaDetector gained momentum by moving to GitHub, but most of the gains were from moving to a web-based repository service with a distributed version control system, rather the specific choice of GitHub/Git over the alternatives.

As V4 is already using a web-based repository service (SourceForge) with a distributed version control system (Mercurial), I wouldn't expect the same momentum gain by moving V4 to GitHub.

Also GitHub doesn't seem to offer the same facilities as SourceForge in terms of websites or mailing lists. Although the code is on GitHub the documentation is still published through the University of Chicago website and we use a SourceForge mailing list. 

One alternative would be to use Git on SourceForge. That would allow us to keep on using the website and mailing lists, but gain any Git-related benefits.

That said I would strongly vote against making any move, either to Git on SourceForge or GitHub in the immediate future. (In case anyone is suggesting doing this). We've had a constant stream of changes in V4 already. I really don't want another at the moment. The merge 8 months was particularly disruptive.  Frankly I don't see we would "gain any momentum", and in fact we would probably lose all momentum for weeks or months with the change. Is there anything we can't do at the moment with the existing tools that we could with GitHub and Git? I realise that casual users it may like to see V4 on GitHub, but you need to consider the impact on V4 developers. 

A change further down the line might make more sense. When we move V4 code into base would be a good time to consider where and how we host the base code. In fact given that we want to move V4 into base at some point I don't think it would make sense to move V4 before this.

Longer term I'm broadly pro-Git. My experience of using Git and Mercurial is that Git is more powerful and perhaps more logical, but slightly harder to use. It's also becoming the popular choice of VCS. Mercurial is adequate, especially for a relatively small number of developers and certainly better than Subversion. Regarding SourceForge versus GitHub, GitHub doesn't strike me as substantially better than SourceForge and doesn't have some of the latter's features, but if we're considering the decision of where to host base from scratch, GitHub might make sense.

Regards,

Dave



-----Original Message-----
From: Ebner Simon Gregor (PSI) [mailto:sim...@ps...] 
Sent: 23 January 2015 15:15
To: EPICS V4 Developers
Subject: Re: git

Hi Andrew, Greg, et al.

Not that it matters, and that I have a actual vote ... ... however if I would have a vote ... I would really like to see the Epics4 code on github!

I guess AreaDetector is a very good example that successfully moved to github and gained momentum by that.

Cheers
Simon


> On 21 Jan 2015, at 06:19, White, Greg <gr...@sl...> wrote:
> 
> Hi Andrew,
> 
> Could you take the lead on decision making for an SCM move? Is base 
> thinking also of such a move? Could we use this move to merge?
> 
> And that developer guide for the hard of thinking - that is necessary 
> - even if it's just a text file with a bunch of command examples.
> 
> Cheers
> Greg
> 
> On Jan 20, 2015, at 8:02 AM, Ralph Lange <Ral...@gm...> wrote:
> 
>> Ha, nice serve!
>> 
>> On 20/01/2015 16:41, Michael Davidsaver wrote:
>>> [...]
>>> 
>>> I'm putting these changes up on github instead of SF for several reasons.
>>> 
>>> 1. Its easier for me
>>> 2. It looks nicer (easier for you to read) 3. To highlight that 
>>> conversion from hg to git is painless
>> 
>> We all know that. Plus the tracker would actually be usable, etc. etc.
>> 
>> But, remember Greg's mail on 16-Dec...
>>> But the port doesn't mean just export from Mercurial and import into git. It also means:
>>> 
>>> - update jenkins
>>> - update sf SCM association (eg see [1]
>>> - update docs like gettingStarted which refer to git
>>> - and yea, a real user guide. Not just a link to git documents on the web
>>>   but how we in EPICS v4 do our specific jobs. What we specifically would do for
>>>   a release with real cut and paste examples. Nob-level as Ralph derisively called it.
>>>   Just a reminder, Marty complained for months that we didn't have a checklist
>>>   for how to work Hg and how to do a release. QED. So it's true, in my experience running
>>>   dev groups the thing I see over and over - what gets stuff done - is no-brainer
>>>   checklists. I know it's dull and I know engineers roll their eyes. But it's just true.
>>> 
>>> Now, absolutely, I'd love us to move to Git, and have been assuming 
>>> for some time that we will. Just want us to be realistic about the 
>>> work necessary to make it good, and realistic about opportunity cost 
>>> of that work compared to other possible work. Any volunteers for the drudge work?
>> 
>> Here's where it's getting less painless. The issues are not technical.
>> I won't be fighting that battle.
>> 
>> But a clandestine parallel structure on GitHub sounds like an 
>> interesting option. "Dark EPICS"..... ;-)
>> 
>> ~Ralph
>> 
>> 


-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom