On 1/10/14 02:04 , Chris Morley wrote: > I agree to lots of what you are saying there. > But I am not sure not having a lcnc_sig branch is the major problem either. > If a non-push access developer can't get their patch put in fairly easy, then > we are in the same boat. > eg UB3 (the closest to a linuxcnc SID) is on the linuxcnc repo but still has > limited access. > I think Michael updates it from time to time from others work. > > In fact master was the unstable branch. It just that the releases are > somewhat slow, to the > point it's being used a fair amount in production machines (based on > forum/maillist questions) > > It almost to the point of considering stopping development in 2.6 and open > 2.7 for unstable work. > To destabilize 2.6 now seems a waste of months that people have spend using > it and reporting > / fixing issues.
I'm glad we're having this conversation. There are definitely problems with how things are going and I appreciate everyone's thoughts on how to make things better. I agree with Chris Morley that the master branch *is* supposed to be our unstable/development branch. Our release cycle should look something like this: 1. New features should be developed in feature branches, tested and stabilized and reviewed there. 2. When we figure out what features should be in the next release we work on getting them all merged into master, and we hold off on merging other features that are not part of the release. 3. When the final "next-release" feature is merged into master, we make a release branch to stabilize things, and open master for merging the *next* next-release features again. I think the above release cycle is very typical of open source projects. 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. Two things went wrong in the 2.6 release cycle: 1. There was a long period after the 2.5 release when there was no 2.6 release manager, simply because no one volunteered to do the job. So the 2.6 cycle became much longer than it should have been. There are several useful things in the master branch that could have warranted a release a year ago. 2. The main remaining feature slated for merge into master before the 2.6 branch point is ubc3, and it's a humongous change, perhaps 10x or 100x as many commits as a normal feature branch. It introduces deep changes in how linuxcnc works, how it builds, and how it's packaged. Chris M's comment above that UBC3 is our "sid" branch is right on: ubc3 is not a feature branch with a great new feature, it's an integration branch with many different feature branches merged together. I hope we can all pull together on recovering from this situation and getting 2.6 ready for release, and learn from our mistakes for the next release cycle. I appreciate everyone's continued help with the 2.6 todo items: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Todo-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
