[sakai2-tcc] [Building Sakai] Proposal: trunk is 2.9 from Sept-Jan until sakai-2.9.0-rc01 is ready for tagging

[Noah Botimer]

Point taken. I am only suggesting an "open door" policy of sorts. If a compelling reason to adjust course emerges (like broad performance or refactoring work), we should not respond by saying "The trunk is locked. Wait until 2.9 RCs are out.".

I grant that this is not a high probability scenario and that much feature work can happen efficiently in branches, but I prefer to have some known wiggle room in policy to encourage inclusive discussion rather than divergent effort -- all just in case.

Thanks,
-Noah

On Sep 19, 2011, at 12:15 PM, Anthony Whyte wrote:

> My thoughts on timing (e.g. from now to Dec.) are based on a consideration of certain work rhythms that exist in the community.
> 
> I count 102 calendar days between 20 September and 31 December.  Subtract weekends and the number drops to 74.  Subtract holidays and the number of days drops still further.  At UMich, subtract 3 holiday days plus an additional 4 season days.  That leaves 67 days.   Other schools holiday scheduling will no doubt vary but November and December are months were work is often set aside for family and friends.  
> 
> If you can stabilize CLE trunk in less than 67 work days and produce a relatively stable beta tag prior to the holiday season, go for it.  But I think it's more realistic to aim for a stable tag in mid-January 2012.
> 
> Cheers,
> 
> Anth
> 
> Example: UMich holidays, http://hr.umich.edu/holidays11.html
> 
> 
> 
> On Sep 19, 2011, at 11:35 AM, Noah Botimer wrote:
> 
>> I think that this is generally a very good plan but I do share Matthew B's concern that the term may be long (but we don't really know now, as it depends on interest/capacity for new work beyond or despite our urging to focus on 2.9).
>> 
>> I have also long been supportive of the labels alpha, beta, and release candidate having useful meaning and criteria. In (maybe only) my mind, beta tags should indicate a relative stability and completeness. Perhaps the alpha-beta transition is a sensible moment to switch over to a release branch.
>> 
>> In any case, I am supportive of this and encourage us to move forward while keeping a finger on the pulse. There may be an indication of the "right time" before January, but it's a good ballpark for now.
>> 
>> As this appears to be a proposal rather than a vote, I'll bend my personal guidelines and combine an editorial with a ballot.
>> 
>> +1
>> 
>> Thanks,
>> -Noah
>> 
>> On Sep 18, 2011, at 6:52 PM, Seth Theriault wrote:
>> 
>>> Anthony Whyte wrote:
>>> 
>>>> I propose that we reconsider this tradition and instead 
>>>> adopt the following approach:
>>>> 
>>>> Non-indie trunk branches remain 2.9-SNAPSHOT until we are 
>>>> ready to tag the first release candidate.  New work not 
>>>> intended for 2.9.0 is performed in branches and held there 
>>>> until we branch trunk for 2.9.  Indie projects also adopt 
>>>> the same approach; trunk stays 2.9-oriented while new work 
>>>> is performed in branches.  The release team cuts alpha/beta 
>>>> QA tags from trunk.
>>> 
>>> +1.
>>> 
>>> Seth
>> 
>> 
>> 
> 
> 
> Begin forwarded message:
> 
>> From: Matthew Buckett <matthew.buckett at oucs.ox.ac.uk>
>> Date: September 19, 2011 5:56:19 AM EDT
>> To: Anthony Whyte <arwhyte at umich.edu>
>> Cc: sakai2-tcc Committee <sakai2-tcc at collab.sakaiproject.org>
>> Subject: Re: [sakai2-tcc] Proposal: trunk is 2.9 from Sept-Jan until sakai-2.9.0-rc01 is ready for tagging
>> 
>> On Fri, Sep 16, 2011 at 11:01 PM, Anthony Whyte <arwhyte at umich.edu> wrote:
>>> Non-indie trunk branches remain 2.9-SNAPSHOT until we are ready to tag the first release candidate.  New work not intended for 2.9.0 is
>>> performed in branches and held there until we branch trunk for 2.9.  Indie projects also adopt the same approach; trunk stays 2.9-oriented while
>>> new work is performed in branches.  The release team cuts alpha/beta QA tags from trunk.
>> 
>> I think getting people to focus on fixing bug by stopping new features
>> going into trunk is the right thing todo, however I'm concerned that
>> doing this for 3 months may be a little long.
>> 
>> Sadly for me Sakai work come second to local development/deployments
>> so I have to fit any work around local upgrades. At the moment I'm
>> moving Oxford to 2.8, out of this come patches which are applicable
>> for trunk and if they sit in Jira for months they tend to get
>> ignored/forgotten and then they become out of date.
>> 
>> -- 
>>   Matthew Buckett
>>   VLE Developer, LTG, Oxford University Computing Services
>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20110919/69d38876/attachment-0001.html