Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <6C0F35C5-22A3-4B43-BFAE-49C5B2DA60DE@classsoftware.com>
References: <CC45AC25.4401F%aharui@adobe.com>
	<6C0F35C5-22A3-4B43-BFAE-49C5B2DA60DE@classsoftware.com>
Date: Tue, 7 Aug 2012 07:18:52 -0400
Message-ID: 
 <CALorpXf_T5YpTKUBjKeH-uoM=2P0NjK0VHXiNeV4x9J790HRjg@mail.gmail.com>
Subject: Re: svn commit: r1369773 - in
 /incubator/flex/trunk/frameworks/projects/experimental
From: Nicholas Kwiatkowski <nicholas@spoon.as>
To: flex-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=0015173fe4acc6564704c6ab28e9

--0015173fe4acc6564704c6ab28e9
Content-Type: text/plain; charset=ISO-8859-1

Justin,

I personally think that it should be trunk -> unstable -> whiteboard.   I
don't see others being skittish in helping out in the whiteboard area, and
this gives us an area to play with so that we can prepare stuff for the
trunk.  From there it goes into unstable which should get much more
testing, and once people are happy with it, it gets merged into the trunk.

I feel like this was discussed quite a few times on this list already..

-Nick

On Mon, Aug 6, 2012 at 8:43 PM, Justin Mclean <justin@classsoftware.com>wrote:

> Hi,
>
> > At Adobe, around release time, you had to get additional approval to
> check a
> > fix into the branch getting released.
> This is no longer an Adobe project. We can make releases far quicker (in
> theory) to fix any issues that arise if we need to.
>
> > That's correct.  Maybe I haven't fully absorbed the Apache Way on this,
> but
> > in my mind, the dev list folks are the first line of defense for our
> regular
> > users.  That's why I would have us working out of unstable until we
> think it
> > is stable enough for less adventurous users.
> How does working in another branch achieve that? As far as I can see it's
> exactly the same (but with added complexity).  If most of the work is going
> on in a branch not trunk then the adventurous user will most likely use
> that branch not trunk. Remember everything is public.
>
> > On my bug fix days, I would be doing it in the unstable branch.
> So you would delay on purpose needed fixes going into trunk? Am I missing
> something here?
>
> > The Flex 5 components landed in Carol's whiteboard and eventually she
> will move them to unstable
> Personally I would of put the completed components straight into the
> unstable branch. You are more likely to get other committers to review and
> help out there.
>
> > Because the bug fix might have downstream issues.
> It may have, but most often not having the fix is worse. Any issue can be
> fixed or reverted if needed there's no need to be commit shy. We are not
> building a product that only get released once every year :-)
>
> > In your experience did you make a branch or otherwise limit access just
> > before a release?
> I've done both and also continued working in trunk. In my experience "code
> freezes" or "branch freezes" meant more bugs get into production not fewer.
> Continue working in trunk has caused the least number of issues for me.
>
> > I don't see CI being good enough given our testing infrastructure
> Which can be improved especially now we have the full set of Mustella
> tests.
>
> >  and I hope we release often enough that there are fewer merge issues
> because the
> > two branches don't stray that far apart.
> I'm an experienced SVN user and I had several issues trying to merge the
> changes from the patches branch back into trunk. I know quite a few
> committers here don't have extensive experience with SVN and in particular
> branching.
>
> Thanks,
> Justin

--0015173fe4acc6564704c6ab28e9--