[Cosmo-dev] Cosmo release frequency

[Mikeal Rogers]

I already know this is going to upset some people but....

It sounds like we're letting our tools dictate our process rather  
than our process dictate our tools.

Lot's of merging and branches is pain with subversion but there are  
some other SCMs where it isn't a problem at all.

If lots of branching/merging becomes a necessity for what we want to  
do with our process then we can explore a change in tools, nothing is  
set in stone.

-Mikeal

On Oct 8, 2007, at 3:48 PM, Ted Leung wrote:

> Not so fast -- I'm not looking to shove 2 week cycles down anyone's  
> throat here.  I wanted to make sure that we are all working off the  
> same information, and understand what the problem space looks  
> like.   I'm perfectly willing to explore radical alternatives like  
> breaking up the code base into pieces that release on different  
> cycles.
>
> Let's have some more discussion around things that we could do.
>
> On Oct 8, 2007, at 3:13 PM, Brian Moseley wrote:
>
>> On 10/8/07, Ted Leung <twl at osafoundation.org> wrote:
>>
>>> 4. I'm not sure I understand the stress level argument.   With the
>>> time based releases, we are not asking people to promise to  
>>> deliver a
>>> feature by a specific release.   When the feature is done and
>>> suitably tested, it goes in the next release - we neither push
>>> forward or push back release dates based on the completeness of
>>> features.
>>
>> managing all of those branches is sure going to be stressful. but
>> fine. if you want to try two week cycles, i'll play along. we will
>> definitely find out where our processes will break.
>> _______________________________________________
>> cosmo-dev mailing list
>> cosmo-dev at lists.osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev
>
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev