On Sun, 2013-06-30 at 12:28 -0400, Matt Shaver wrote: > On Sat, 29 Jun 2013 18:15:54 -0500 > Charles Steinkuehler <[email protected]> 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
I liked the idea of being able to automagically or otherwise submit changes to the buildbot. Dave > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
