On Sunday 12 January 2014 15:12:45 Sebastian Kuzminsky did opine: > On 01/11/2014 04:23 AM, Charles Steinkuehler wrote: > > On 1/11/2014 5:08 AM, EBo wrote: > >> On Jan 11 2014 3:42 AM, Chris Morley wrote: > >>> if this testing branch is on the buildbot then a wider > >>> audience can / will test. If we can't get people to actual try > >>> the testing branch then it doesn't really help us. > >> > >> Setting it up on the buildbot is an interesting idea. That would > >> imply that each test branch needs a champion to setup the > >> buildbot, and thwack the code. It would be a little extra work > >> for them, but would save Seb some time if it is agreed that after > >> testing and the pull request comes that the test branch is as > >> close to the current tip of the master as possible (so very few > >> changes necessary). > > > > Again, I go back to my initial comment that LinuxCNC needs a "Sid" > > branch, which would get buildbot builds and allow the truly brave > > to experiment. > > > > A Sid or unstable branch provides a place to drop the non-trivial > > patches and integrate feature branches for wider testing without > > breaking the release (stable) and master (testing) branches folks > > expect to be able to use for real work. > > I'm not opposed to this, but i want to caution against a common > pitfall with this model. > > Let's assume someone volunteers to manage an "integration-test" > branch, based on master, into which they merge some subset of > outstanding experimental feature branches. They'd push this to > git.linuxcnc.org, the buildbot would build it and test it and make > debs, and the debs would be available to users. Great, right? > > (Note, the above behavior works today. The only thing missing is the > branch manager.) > > Now, the advise i'd have for this hypothetical integration-test > manager is: > > 1. only make merge commits in this branch, and > > 2. throw it away often > > Any fixes (non-merge commits) should go in the affected feature > branch, *not* in the integration-test branch. That way, the feature > branch can be merged into master and include that fix, without having > to merge the whole integration-test branch (which would presumably > contain other features which are not merge-ready yet). > > By "throw away the integration test branch" i mean: delete the branch > and create it anew from the new origin/master branch, and re-merge all > the features you want to include in it. This emphasizes its temporary > integration-test nature and reinforces the "fixes go on the feature > branch, not the integration-test branch" point from above.
That sounds like a great way to do it Seb. But we'll need something that gives us a link to the "test" buildbots output when it has been put in place. Fortunately I don't have anything going on in the shop, so I can wait for the next 2.5.3 which will hopefully fix the problem others have found today. 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) Genes Web page <http://geneslinuxbox.net:6309/gene> Faith goes out through the window when beauty comes in at the door. A pen in the hand of this president is far more dangerous than 200 million guns in the hands of law-abiding citizens. ------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
