Re: [Emc-developers] git.linuxcnc.org vs github vs. agile development

[Ian M. <imc...@pr...>]

however it shakes out, there needs to be some clear direction on the best practices for managing development on branches and forks, how pull requests and merges should be done, who can and will review and merge them, etc.

I'm heavily in favor of using a service like github or bitbucket because I think their web tools make these practices obvious and easy to manage.  In my day job, we use bitbucket for everything, and the pull request model and the web merge gui has been the single easiest way to get more eyes on code.  People even review their OWN commits this way, and I've been amazed at how much more efficient it has made our work.

That said, I don't have any strong opposition to continuing to use the existing repository, but there needs to be a document written up that clearly explains for the less savvy folks exactly how to use command line git to work with our repositories in the way that we want them  to (how to branch, fork, submit PRs, etc).  I'd even suggest having instructions on how to do the more "advanced" things (like merge), even though the immediate audience may not be doing those things, because today's newbies may be tomorrow's release managers, and I think it's healthy to encourage an environment where people want to be more involved and get more responsibility.

I'm not saying we don't have that already, and Michael was quick to help me get set up to start contributing, but I think overall we might get more contributors if the process were more transparent.  Nobody wants to be the guy to say "I use git every day but I have no idea how to work with branches", but I suspect more people are in that boat than you might imagine :)


Ian (ssi)

On Jun 30, 2013, at 12:28 PM, Matt Shaver <ma...@ma...> wrote:

> On Sat, 29 Jun 2013 18:15:54 -0500
> Charles Steinkuehler <ch...@st...> wrote:
> 
>> So what do I think needs to change?  Well, let's start with what
>> exists now, which I see as:
>> 
>> Tier 1) Anointed LinuxCNC developers with push access to
>> git.linuxcnc.org.
> <...>
>> Tier 2) People who have pestered or persisted enough to get push
>> access to Michael Haberler's repository.
> <...>
>> Tier 3) Everyone else.
> 
> It wasn't always like this. Originally it was just me and Fred Proctor
> (and Will Shackleford), and Fred (and Will) did all the meaningful
> coding. Originally I couldn't even build binaries myself, so Fred sent
> them to me as archives (zips) of the directory structure complete with
> compiled output. Eventually there was a mailing list at NIST and I
> think some people sent code changes (as patches or some other general
> suggestion) to Fred and he would incorporate them where possible. Since
> this was Fred's nearly full time job, and there were a small number of
> interested people, this worked fine.
> 
> When the project moved to Sourceforge, commit access was given out to
> anyone who asked. The general rule was, "Make sure it compiles before
> you leave for the day". This worked surprisingly well and I think I gave
> commit access to a couple of people. Generally, everyone behaved well.
> 
> When we switched to git it was because the Sourceforge system was
> really slow and commits (that someone needed right away) would
> sometimes take a _long_ time to show up in a pull. There were other
> issues I've forgotten now... Anyway, a lot of folks who had commit
> access at Sourceforge never sent in an ssh key to get git access. Most
> had just drifted away from the project, some were students who had
> graduated I think.
> 
> I don't know why or when git commit access was restricted. I will say
> that I approve of the concept of "stable releases". Stable releases
> allow someone like Stuart Stevenson or the Smithy company to put a
> "known good" (or at least "thought to be good") version on machines
> that are not intended to be motion control experiments :) However, we
> shouldn't have to sacrifice the good will and enthusiasm of new
> developers to achieve stability. There _must be_ room for all levels of
> stability from "completely buttoned down" to "interesting chaos".
> Basically, we need to add the things Charles lists here to our current
> system:
> 
>> I just think the project as a whole will benefit from:
>> 
>> * Having new potential contributions in some form of git repository to
>> start with (makes push/pull/merge much easier than patches if and when
>> it's time to pull updates into the official source tree)
>> 
>> * Allowing officially sanctioned "free-form" development by anyone who
>> shows an interest
>> 
>> * An easy way for the free-form modifications to be shared with other
>> users
>> 
>> So...
>> 
>> Does this sound reasonable?
>> 
>> If so, what changes do we need to make it work?
> 
> Here are some suggestions:
> 
> 1. If a developer is _only_ comfortable with github, then we should
> have a procedure/mechanism to receive pull requests. Maybe that
> mechanism is to accept the pull requests through jepler's existing
> github mirror of git.linuxcnc.org. Another possibility would be a wiki
> page, to which developers could append their "pull request" in the
> form of a written notice. The important issues with respect to
> "external" development (like github or any other source code repository
> besides git.linuxcnc.org) are that developers must be told, explicitly,
> that it's 'OK' to clone git.linuxcnc.org, and that they can return
> changes to the main line by some "easy-to-do" process. New developers
> must not fear becoming involved with the project! They must be extended
> a hearty welcome and be made to feel "at home".
> 
> 2. I _do_ feel that the project should be able to accommodate _all_
> developers inside the project infrastructure itself, without depending
> upon external services like github unless a developer specifically
> _wants_ to use github, bitbucket, etc. This isn't about "control". I
> can't control this project and neither can anyone else; It goes where
> it goes. My feelings in this matter derive from my statement above that
> developers must be made to feel "at home". For this to be possible,
> there must _be_ a "home". That "home" is linuxcnc.org, and the
> associated e-mail lists at Sourceforge, and the IRC channels to a
> lesser extent.
> 
> It may be that we should open up commit access to any and all comers
> and then deal with the problems as (or if) they occur. In my
> experience, people are remarkably trustworthy. Since it _is_ a version
> control system, permanent, un-fixable damage should be impossible in any
> case :)
> 
> Thanks,
> Matt
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> Emc-developers mailing list
> Emc...@li...
> https://lists.sourceforge.net/lists/listinfo/emc-developers