On Saturday 29 June 2013 20:58:56 Charles Steinkuehler did opine: > Per the IRC meeting this morning (my time), I'd like to discuss > possible changes to the LinuxCNC git management. > > Let me start by saying I do not wish to do away with git.linuxcnc.org, > nor do I have any particular desire to involve github in this whole > process. > > 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. These are the "real guys" with the power to break > everything and kill people. With great power comes great > responsibility. > > Tier 2) People who have pestered or persisted enough to get push > access to Michael Haberler's repository. I'm currently in this group, > and don't mind. I don't _want_ to be a "tier-1" developer and assume > the responsibility that comes with it. I just want to make my 3D > printer work well without re-inventing 90% of what LinuxCNC does out > of the box. > > Tier 3) Everyone else. It is currently difficult to "elegantly" share > any updates with others. I can very easily clone git.linuxcnc.org to > my box and make some changes, but then what? Do I post a patch to the > mailing list (ignored and/or easily lost)? Do I open my local git > repository to use by others (hard to setup, has security implications, > and assumes that in addition to crafting a fix/update for LinuxCNC I'm > also a network admin capable of safely running a public service on the > internet)? Do I push a clone of the LinuxCNC git repository to > somewhere like github, bitbucket, etc. and point folks to my changes > there (seems a bit presumptuous at the least)? > > Basically, I don't care what happens as long as it is clear (ie: > listed plainly wherever folks are pointed to git.linuxcnc.org to grab > the code) what someone should do if they wish to modify the source and > share their changes with others. This could be as simple as a > statement that it is OK to clone the git repo to github or bitbucket > or where-ever, a separate git area with open push access > (chaos.linuxcnc.org, or perhaps "here_be_dragons"!), or some other > option I haven't thought of. > > 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?
Git, like mercurial (hg), has tags & branches. I see no reason those with the tier one access couldn't setup a branch that has perms for the tier two folks to play in, a sandbox if you will. To me, that makes more sense than trying to keep a remote clone of it up to date with the tier one activity as I believe that could be made automatically. That might occasionally break some of the tier two toys, but then the tier two folks would quickly learn to make it compatible again. Git also keeps a history, and can recreate a release that is years old if its usage encompasses the date in question. If a breakage is discovered, the bisect technique can usually find the exact commit that broke things, usually in less than 8 build cycles. I've done 3 bisects of the kernel, and found the responsible commit in only 4 builds maximum. Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) My web page: <http://coyoteden.dyndns-free.com:85/gene> is up! My views <http://www.armchairpatriot.com/What%20Has%20America%20Become.shtml> To err is humor. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers