On 8/6/12 4:54 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
> Hi,
>
>> Imagine if we really get going and have lots of new stuff coming in. I
>> can't see how we could keep trunk stable enough.
> Not mater where you put it that always going to be the issue. With CI
> (especially if we can get Mustella running off check ins) it's less of an
> issue.
At Adobe, around release time, you had to get additional approval to check a
fix into the branch getting released. That's because, in my experience,
some number of fixes still have downstream issues that aren't caught yet by
CI simply because we don't have tests for everything. So for the short
term, I don't see CI as a guarantee of stability.
>
>> Plus, I'm not sure how many non-committers are going to pull from trunk;
> No many but once we get nightly builds up and running they might. (BTW we do
> currently have a basic nighty build via Jenkins.)
>
>> I think they would use official releases. And I'm not sure if they'd spend
>> much time with stuff
>> labelled experimental.
> Perhaps not but I think some would and at the very least it provide a clue to
> what might be merged into the other namespaces.
When something first lands, it could cause discussion where folks want to
change the name, etc. I'd rather not have that kind of churn in trunk.
>
>> I still like the 3-tier approach. Really experimental stuff goes in the
>> whiteboard.
> No issue with that. However users of the SDK are likely to ignore anything
> that is here. It will take considerable effort on there part to be able to use
> it.
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. Then it would go in trunk once
we feel better about it.
>
>> We would ask the committers and other interested folks to generally work out
>> of the unstable
>> branch.
> For work in progress I assume you mean?
I think we have to trust folks to judge what goes in whiteboard and what
goes in unstable and even what goes in trunk. But I would err on the side
of caution.
On my bug fix days, I would be doing it in the unstable branch. We might
land some changes for Maven in unstable. The Flex 5 components landed in
Carol's whiteboard and eventually she will move them to unstable where more
of us will use it and then decide when it is ready for trunk.
>
>> That would be where I would be fixing bugs
> Why shouldn't bug fixes be put into trunk were they would be most useful?
Because the bug fix might have downstream issues. We also don't have CI set
up to catch performance regressions at this time.
>
>> I probably wouldn't spend time syncing trunk until some release manager says
>> they want
>> to cut a release.
> Having worked on many large SVN projects over the years I would strongly
> recommend against that approach.
>
> In my experience:
> 1. Tend to cause large number of merge issues
> 2. Merging branches is SVN is sometimes problematic
> 3. Integration issues - just before a release everyone tries to merge with
> trunk and lots ends up broken.
> 4. Continuous integration works best if all changes are checked into trunk
> (IMO).
>
> IMO check into trunk often as you can work best. Yes occasionally the build
> may be broken/trunk not in a fit state but with a CI system we'll know about
> it and be able to fix or revert as required.
>
In your experience did you make a branch or otherwise limit access just
before a release? We did that in a branch and left trunk open. But now I'm
thinking we should leave trunk as limited and leave a branch open mainly
because we are now delivering source, not binaries, and also because that
left us with tons of branches hanging around.
I don't see CI being good enough given our testing infrastructure, and I
hope we release often enough that there are fewer merge issues because the
two branches don't stray that far apart.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
