>
> 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, keeping communication open and moving keeps everyone close
to the same page. which I think is often a problem.
> 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.
>
This is not strictly how it has worked in the past.
There is usually little (offical) discussion on what gets put in.
Not saying good or bad about that - just saying.
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.
> 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.
>
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.
If it is frozen does that mean UB3 and ja are not being merged in 2.6?
Is that official now?
> 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
>
Cheers
Chris M
------------------------------------------------------------------------------
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
