On 01/10/2014 06:39 PM, Chris Morley wrote: > I get the idea you see master as a very stable almost-could-be-released-now > branch. > I see master as a testing branch, bringing a feature into a larger user base. > useable, but can have bugs and breakage at any time. > > I wonder what other people think. We probably all think of it a little > different. > If you want a super stable master branch all the time then we probably do > need a third 'testing' branch. > > Feature branches are great to build and work on within a limited user base, > but to really flesh out the details requires lots of people to use it. > At the moment master is that branch and I think that is mostly because > its available as binaries on the buildbot.
All branches that are pushed to git.linuxcnc.org are built by the buildbot. The debian packages are sorted by the branch they were built from, into different components of the deb archive: debs from master go in master-rt and master-sim debs from v2.5_branch go in v2.5_branch-rt and -sim debs from v2.4_branch go in v2.4_branch-rt and -sim debs from all other branches go in scratch-rt and -sim The documentation for this is hidden on the buildbot dev page, http://buildbot.linuxcnc.org/dev.html, under "Sorting of packages and other build results". It's not on the front page because i think it's mostly of interest to developers and I don't think most users will want to see it. But i may be wrong on that... >> Robert Ellenberg's circular arc blend branch is a wonderful example of >> this workflow. Unfortunately master is currently frozen for the 2.6 >> release, so Robert's work has to wait for the creation of the 2.6 branch >> before it can move ahead. > > When did 2.6 get frozen? I don't remember any announcement. > If 2.6 is frozen then why is there not a 2.6 branch for stabilization now > and then master can be open for development again. > I don't understand why we would ever freeze master. Since we're all focusing on getting 2.6 releasable now (we're all focusing on that, right guys?), we shouldn't be adding other things to master that will interfere with that. That's what I meant by "frozen", which is probably not the most accurate use of that word. This release cycle is obviously not going in an ideal way, for reasons we've talked about. Normally the freeze would happen on the release branch as soon as the release branch is created, and master would remain open. As RM i've decided not to do it that way, hoping that it will spur people to help on the release instead of developing new features, but i'm not sure it's had the desired effect... :-/ > If it is frozen does that mean UB3 and ja are not being merged in 2.6? > Is that official now? No, it does not necessarily mean that. I'm still hoping that ubc3 can make it into master before the 2.6 release branch is made, and thus into the 2.6 release. There are significant problems with this branch still (listed on the Todo-2.6 wiki page, http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-2.6), i'm working on it, and i welcome all your continued help with these and other release-blocking tasks. I'm much less excited about delaying 2.6 for joints_axes. I'm currently leaning towards holding off on joints_axes until next release. Unless someone steps up and validates ja, it's probably not going into 2.6. -- 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
