[Framework-Team] Re: getting rid of goldegg branch

Kapil Thangavelu kapil at cignex.com
Wed Oct 5 00:44:44 UTC 2005


Alec Mitchell wrote:
> On Monday 03 October 2005 04:46 pm, Michel Pelletier wrote:
> 
>>Kapil Thangavelu wrote:
>>
>>>i'd like to get rid of it, since it doesn't really to serve any useful
>>>purpose having this work separate from the trunk, outside of potentially
>>>making merging headaches latter. right now outside of goldegg all the
>>>development work is being done on the 2.1 branch, so its seems alot
>>>easier to just do the work directly on trunk. i'd suggest we merge plone
>>>goldegg branch to trunk, and start merging selected items back from the
>>>2.1 branch to trunk.
>>>
>>>kapil
>>
>>I'm +1 on this after talking about to Sidnei who is also for it.  Kapil,
>>are you willing to do the merging?  I'm woefully ignorant of these things.
>>
>>Thunderbird rocks.
> 
> 
> I think that trunk may be out of date.  I was under the impression that the 
> policy for plone's trunk was that it contains a snapshot of the last released 
> version, rather than being a place for active development.  Perhaps it would 
> be better to copy 2.1 branch or trunk into a 2.2 branch and merge the goldegg 
> stuff in there.  I'm all for this, as long as the goldegg stuff is currently 
> in a working state with all tests passing.  In general, I think we should 
> avoid developing new features directly on the main release branch; instead, 
> we should be developing new functionality on dedicated branches and merging 
> it into the main branch when it becomes stable.  However, this is all policy 
> stuff to be determined by the 2.2 release manager, whoever he/she is.
> 
> Alec

till right now, the plone project has never really done two major
concurrent development branches, afaicr. the trunk policy typically is
that after a release branch is finalized, its merged back to trunk and
dev work continues there for a while till a new release branch is cut
and stabilization work ensues. reality is that new development continues
on the release branch, but thats never been a goal, imho. and its never
been a policy to treat the trunk as tag archive of a release branch.

with regards to feature development branches, long lived branches with
major changes are always a signifigant risk, that should be avoided. the
work on views would be such a branch, in that even though its fairly
repetitive work of a known difficulty, there is alot of to be done, but
that work can be done on a incremental basis without disturbing the
overall state of the system, which is why i feel its appropriate for
merging to the trunk.

regardless any concurrent development, needs to constantly (and
carefully ;-) ) be merging from the 2.1 branch where alot of bug fixes
are currently directed.

i agree though that in general developing new features on the branches
is a good idea, and i'm going to branch for the cmf-2.0 integration
work, i've got sitting up my laptop, but in the case of views, i think
its more beneficial in light of the amount of low risk work, and the
merging requirements, to remove the development barrier.

we're still a few months out i think from being able to branch 2.2 and
start work on release stabilization and migrations. on a separate note,
i'd like to target a 6 month release schedule in line with zope, which
would aim towards next april as a release date, with release branching
end of january/february.

cheers,

kapil








More information about the Framework-Team mailing list