harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [general] M3 schedule
Date Fri, 14 Sep 2007 09:34:59 GMT
Stepan Mishura wrote:
> On 9/13/07, Tim Ellison wrote:
 >> Can BTI and other scripts cope ok with switching to the code on a branch
>> rather than dealing with HEAD?
> Well, it seems that I hurried up a bit with the proposing to branch
> the trunk for M3. I think now that testing ifra is not ready to
> provide testing for the branch. I'd like to mention that we use many
> machines (up to 30) to run a set of scenarios on 4 platforms. All
> these CC instances will have to be reconfigured to test the branch.
> Reconfiguration is not a problem itself - CC is stopped, svn urls are
> updated to point to the branch and CC is started again ... but taking
> into account the number of machines it won't be 2 minutes switch (and
> after M3 we have to switch them back).
> Also CC reconfiguration will mean that the trunk testing will be
> stopped (IMO this is not good).

That was my concern.

We could consider branching the opposite way round, i.e. create an
UNSTABLE branch for ongoing development and then freeze and stabilize HEAD.

That would allow people who want to continue working on the very latest
code to proceed on the UNSTABLE branch without disrupting the BTI farm
for M3.

I would add, however, that it's good to have a number of people involved
in the stability drive for M3.  Better to have a few off on UNSTABLE
with the majority closing out M3 rather than the other way around IMHO.

> Having said that I'd propose to follow the same procedure as we did
> for M2 - the trunk is frozen and no more commits without agreement
> from two committers on the dev list during code freeze.

Once we get code freeze, then yes I agree that procedure seems to work
quite well (even if we do forget to do it a few times <g>)

> Sorry, for making a disturbance with the branch proposal.

It's not dead :-)  If there is a need for continuing on a branch then I
think we should figure out how to accommodate it.


>> Once the M3 branch is created then I assume that the HEAD is opened once
>> again for code and feature changes, but changes to the stable M3 branch
>> require our established `review then commit` style.
>>> - Septemer 29 :release date - M3-branch is merged with the trunk.
>> Though there is no reason why we would not merge the M3 branch into HEAD
>> during the M3-shut-down period either, right?  At the end of Sept we do
>> the final merge, then delete the M3 branch.
>>> Objections?
>> No, I'm keen that we get another stable build published.
>> Regards,
>> Tim

View raw message