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

[csev]

I am also of two minds on this proposal - tending generally in in favor of delaying the moment of branch.

In a sense the branches were a way to help us enforce the freeze on ourselves at the cost of extra work for everything post-freeze.  The need to hard-fork was particularly important when parts of the source tree were in varying levels of completeness and some pieces really were evolving quickly before during, and well after code freeze.  Forcing a branch was a way to pick at least one moment of these fast moving projects to start QA.

We are somewhat out of that phase.  Of course we all do a little bit of last minute heroics right around the freeze, but in general we all can be respectful of the rules.  Frankly we all win when QA starts to look at our stuff and it behooves us not to create a moving target for QA or they will not be as much help to us as they could be.

We would need to feel confident that everyone in the tree was following the rules.  If that were the case and trunk just slowed down and folks who really wanted to do crazy stuff in the Fall did so in a branch - (i.e. make branching the exception rather than the rule) - we would save a lot of effort.

I think that waiting for RC's might be a little late in the process.

Also with so many Indies, in effect the whole "freeze thing" is a little less hard-and-fast.  We already trust that the indies are branching themselves properly and providing artifacts to the core in a responsible manner.

Also, I suggest we might want to treat kernel quite differently and branch it right now.  Lets put *that* line in the sand.

Also I suggest we think more about string freeze and how to manage that in a way that lets translation start early and yet allows small improvements post freeze.

Perhaps we need a way to specially record any change to strings post-freeze - kind of like a "property change" flag in JIRA - it would be a string change flag and while it might not be completely critical during major open development periods (i.e. Jan-Sept), during this "slow trunk" phase we would need to be *VERY CAREFUL* to limit string changes and then when we do so - make sure to precisely mark them in JIRA to help manage the "delta" translations.  This would give more time to translate and at the same time let little things get fixed even if a few new strings were needed.

TTFN.

/Chuck

On Sep 21, 2011, at 2:17 PM, Beth Kirschner wrote:

> I'd like to give the newly formed CLE Release Team the freedom & authority to develop the release process that we'll be using for Sakai 2.9. It sounds like there's a lot of support for maintaining trunk as a 2.9 "alpha" staging ground, with some reservations as to how long before we branch (I share this concern).
> 
> Someone needs to post an announcement to the sakai-dev list to introduce this new process to the whole Sakai developer community (or at least the ground rules as they stand). This could be me or perhaps Sam -- thoughts>?
> 
> - Beth
> 
> On Sep 19, 2011, at 2:51 PM, Matthew Jones wrote:
> 
>> I agree that patches shouldn't hang out on issues as those do get hard to merge. It would be better if svn branches were made if significant work was planned, as those are commits already in subversion are generally easier to merge and deal with than patches attached to jira. We'll still need to go through those and make sure to get them back into trunk though. The system isn't as good as something like git where you can flag a bunch of pull requests. Perhaps if the jira is flagged as "Feature Request" and the fix version is "2.10" then we'll be able to find them easier when the time comes. 
>> 
>> On Mon, Sep 19, 2011 at 5:56 AM, Matthew Buckett <matthew.buckett at oucs.ox.ac.uk> wrote:
>> 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.
>> _______________________________________________
>> sakai2-tcc mailing list
>> sakai2-tcc at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
> _______________________________________________
> sakai2-tcc mailing list
> sakai2-tcc at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai2-tcc
> 
>