flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <jus...@classsoftware.com>
Subject Re: svn commit: r1369773 - in /incubator/flex/trunk/frameworks/projects/experimental
Date Mon, 06 Aug 2012 23:54:57 GMT

> 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.

>  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.

> 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.

> 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?

> That would be where I would be fixing bugs
Why shouldn't bug fixes be put into trunk were they would be most useful?

> 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


View raw message