[Building Sakai] [Deploying Sakai] MT deprecationrecommendations for 2.7 (fwd)

[Berg, Alan]

Hi,

I agree with Johns points, with the boundary condition that for a synchronised well QA'ed deployment of 2.8 I would expect feature decisions (promotion, demotion, UX, import/export, Web services etc) to be made and enacted before 2.8 goes to beta. We should learn the lessons from the 2.7 cycle and tweak the process. I like very much that that I know the exact day for the deployment of the next beta tag and what conditions are necessary to move to Release Candidate. The more certain we are about what happens when in the cycle the easier it is to plan resources and holidays.

Alan

Alan Berg
Interim QA Director - The Sakai Foundation

Senior Developer / Quality Assurance
Group Education and Research Services
Central Computer Services
University of Amsterdam

http://home.uva.nl/a.m.berg




-----Original Message-----
From: sakai-dev-bounces at collab.sakaiproject.org on behalf of John Norman
Sent: Sat 3/13/2010 10:03
To: Stephen Marquard
Cc: production at collab.sakaiproject.org; sakai-dev at collab.sakaiproject.org
Subject: Re: [Building Sakai] [Deploying Sakai] MT deprecationrecommendations for 2.7	 (fwd)
 

On 12 Mar 2010, at 17:53, Stephen Marquard wrote:
[...]
> Also I'm assuming that the MT is only making these recommendations now because of its relative newness, but for future release cycles, these decisions should really be made around the same time as the tool promotion decisions. Every tool or feature removed from the release potentially represents additional work for migrating sites to keep that functionality if they need to.

Personally, I see it as a valuable function of the MT to 'tidy up' the code base. I am not sure I care when a decision is made so long as (a) it is properly discussed and consulted on and (b) all decisions that affect a release are reviewed at the same time. So I can view this as early opening of the consultation (good) and potentially a process that allows decisions to be reviewed carefully without rushing (also good). So, while I accept Stephen's point, I think I might advocate that we don't wait to consider such issues, but we do insist that they be recommendations and if acted upon (e.g. for testing dependencies) they should be reversible until the tool promotion decision point.

It feels like the PM and/or Product Council should be able to help here.

In general, I applaud the initiative without offering any immediate comment on the specific recommendations.

John
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100313/4275cd77/attachment.html