geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: Geronimo 2.0
Date Sun, 08 Jan 2006 10:23:07 GMT

Even if we don't think about 2.0, there are two main ways in which we can handle a stable

branch in source control:

1) We can have a 1.0 branch and as new features and bug fixes are tried and tested
in the dev area(s), then these patches are moved to the 1.0 branch as patch sets via 
some QA process.  This will give us much better control and  stability of our released 
versions, but it needs effort to control the patches moving into the 1.0 branch.

If we look at the Linux kernel development style, they are very much in this style
with patches coming from multiple development areas and being QA's into the main
kernal branches.     

2.0 development would fit nicely in this as it would just be another source of
patches to be QA'd into branches.


2) We can continue development on a trunk and then every time we want to make a release
we copy the trunk to a branch and have a few weeks stabalizing it and then release it.
This is simpler for the developers, but the stability of final releases may suffer as
stuff that your really didn't want will make it's way into releases.   

This means that the trunk can never be more than a few weeks away from a release. It
also means that 2.0 cannot be developed in trunk as we can't just copy the whole
blob.

It also means that having multiple dev areas is difficult as there is no
single source to copy a branch from and no culture of merging.



We must decide which of these models we want to go with - regardless of 2.0
development.  I think that geronimo is of a size and complexity that we should
consider the overheads of approach 1).  Formal compliance issues also push
us towards good QA of all patches to stable releases.

But to do so, we need to develop a culture flowing patch sets through a 
QA process.  We will need multiple people responsible for controlling patches into
specific subsystems and giving assurances to the main build manager that they
have QA's the patches.  These will be tough thankless jobs - maybe we should 
see if Linus wants a change from all that C hacking?

cheers
















Mime
View raw message