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. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ 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
