On Monday 24 of February 2014 08:29:40 Darrell wrote:
> On Mon February 24 2014 12:55:02 am Michele Calgaro wrote:
> > Actually, during the weekend I was considering the question "should we
> > create a branch R14.0.0-alpha" ? The reason for that is to establish a
> > "base" to work on for moving towards R14 release, with an eye in
> > preventing new bugs to enter R14.0.0 code.
>
> I support that idea. I will have to create an R14-alpha partition or VM,
> but that is doable.
>
> We would have to work on backporting patches from the main trunk when they
> apply to directly R14-alpha (almost exclusively bug fixes only), but we've
> been through this before with 3.5.13.2. Conversely, any patch directly
> applicable to R14-alpha gets concurrently merged into trunk.
>
> Fortunately, there will be no renaming patches backported that we have to
> reverse before merging into R14-alpha. All renaming patches stay in main
> trunk.
>
> Two branches will help us focus on not introducing new bugs into R14.0.0.
> Frankly, I'm getting pretty beat up with all the bug reports I keep filing.
> I don't mind filing the reports, but we need to get our heads back above
> the water with respect to R14.0.0.
>
> When ready we simply declare the R14-alpha branch to be the R14-RC1 branch,
> then RC2, etc.

I have nothing against establishing a new branch.
But I'm not sure that now is the right time.

We want to establish a new branch in order to integrate new applications? We 
want to establish a new branch in order to "do new things"? On both I say 
unambiguous: not now. We need to devote all effort to pushing R14.0.0 out the 
door. We are too few of us to split our efforts. If we now begin to address 
new applications or new things, it will have a negative consequence on time 
to release R14.0.0.

I suggest at this point to completely stop the debate on new applications and 
pursue exclusively the tasks necessary for R14.0.0. Let them be filled bug 
reports for new applications and we will pursue them after the release 
R14.0.0. Keep in mind that our team is small, and that for us was a great 
luxury to divide our efforts at this time.

-- 
Slavek