Mailing-List: contact flex-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: flex-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAMFKFRgp0GS_ALfej6w+BFkUoMeqmSn60DRv04uZDnyywXiFTg@mail.gmail.com>
References: <CC501E41.4489B%aharui@adobe.com>
	<CAEWfVJ=yS_J-dSG99bEEK_829-SjraoQtejY_PvOfgtYq+Ar6Q@mail.gmail.com>
	<CAMFKFRifChT1VfY-PHJKhSyya-zkVgo6vzawmM4hHYOAUJriBA@mail.gmail.com>
	<CAEWfVJnVuNqhAM9H2XzEZoj-w4HBWejWR=mDQK8i0GKw2YwqTw@mail.gmail.com>
	<CAMFKFRgp0GS_ALfej6w+BFkUoMeqmSn60DRv04uZDnyywXiFTg@mail.gmail.com>
Date: Wed, 15 Aug 2012 12:17:42 +0200
Message-ID: 
 <CAEWfVJ=wrU2FW9B2EzVMHVsA7NUL1tVxDrzDJ=LF-YrQg=hobA@mail.gmail.com>
Subject: Re: [MENTORS] Current Branching Strategy Vote Results
From: Bertrand Delacretaz <bdelacretaz@apache.org>
To: flex-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 15, 2012 at 12:03 PM, Carlos Rovira
<carlos.rovira@codeoscopic.com> wrote:
> ...In our case we have a core piece called UIComponent composed over 14-15k
> lines of code that are "flex" itself.
>
> If we plan to refactor and rethink that core piece we will do over several
> weeks until it was done. People doing it can't made in whiteboards and it's
> not a one-man-task.
>
> This kind of task need to be done in team and with a SCM prepared for that....

I don't know the details of that issue, so I might be off-base but in
general here's how I would tackle such a job:

1. Fork/branch the code and create a proof of concept prototype, to
see more clearly what needs to change. Maybe several prototypes if
people have different ideas. Make sure to concentrate on the core
problem.

2. Review the differences between the prototype and trunk to see the impact

3. Discuss the best strategy for implementing the actual change, based
on the proof of concept

4. Make sure the changed areas are covered by automated tests

5. Implement the changes, over a relatively short period of time as
the proof of concept has shown how to do that, and hopefully its code
can partially be reused.

In this scenario 5. is where the bulk of the merging/refactoring
happens in trunk - if it has big impact it might need some
coordination to make sure enough manpower is available to make it
happen with minimal disruption.

I don't think using Git or svn makes much of a difference in such a
scenario - 5. is going to be somewhat painful anyway.

-Bertrand