[WG: Sakai QA] [Building Sakai] Release Management Call, Thurs 11 March 2010 (recommending cancellation for this week)

[David Haines]

We are in agreement except that I don't think it is safe to have any code in the release that doesn't have someone identified as being responsible for fixes.  It's really unhealthy for a release to contain code that everybody thinks is someone else's responsibility to fix.  I expect that most of the time there would be volunteers to deal with issues during depreciation.  Perhaps this is covered by the charter of the Maintenance Team. But if nobody bears responsibility then the code just shouldn't be in the release.

- Dave 

David Haines
CTools Developer
Digital Media Commons
University of Michigan 
dlhaines at umich.edu



On Mar 12, 2010, at 4:03 AM, Clay Fenlason wrote:

> On Thu, Mar 11, 2010 at 10:55 AM, David Haines <dlhaines at umich.edu> wrote:
>> Snip ...
>>>  One involves the issue of two tools in trunk/2.7.x that
>>> have largely been abandoned from a support perspective: reports and
>>> warehouse.  I asked Alan to surface the issues on the dev and production
>>> lists since it has been suggested that these projects be dropped from the
>>> build and perhaps even removed to contrib.  This is an issue that impinges
>>> directly on RM and I am interested in people's opinions on this issue.
>> 
>> If there aren't developers willing to take responsibility for the code and
>> the Maintenance Team has reviewed the situation and don't feel they can take
>> on the additional work then the tools should go out of the release and off
>> to contrib.  Tools without someone to fix them shouldn't be allowed to
>> complicate releasing maintained and popular tools.
> 
> Agreed in principle, but I also think that we want a measured
> deprecation process. In discussions in the past we've had a couple
> rules of thumb:
> 
> a) new tools/services that had blockers without resource to fix them
> could be summarily removed during QA, because the impact from one
> release to the next would be nil
> b) tools with waning support would be first stealthed in one release
> (with deprecation announced and spelled out clearly in release docs),
> and then in the next release removed to provide ample warning and room
> for migration strategies
> 
> It might be the case that a stealthed tool could still be a blocker
> for the release even while hidden, but that doesn't seem to be the
> issue in this instance, and so it looks to me like a situation of (b).
> 
> I notice the maintenance team is already compiling a list of
> deprecation recommendations [1], which I was assuming could be handled
> with that two-release deprecation process. It seems clear to me that
> Reports and Warehouse should at least go on that list. Is there a
> reason to move more aggressively than that?
> 
> The only reason I see atm is that Reports has a blocker, such that no
> one can even really unstealth and use it. But even then the
> two-release deprecation seems advisable in providing more time for
> community resource to come forward and fix the bug(s), and if the tool
> is off in contrib this will be more difficult to reverse down the road
> (say, for 2.7.1 or 2.7.2). It does in fact seem that some community
> members have come to rely on the Reports tool, even if they are
> struggling now to provide the maintenance resource, and I think that
> obliges us to move slowly if we can.
> 
> ~Clay
> 
> [1] http://confluence.sakaiproject.org//x/KRUQB
> _______________________________________________
> sakai-qa mailing list
> sakai-qa at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-qa
> 
> TO UNSUBSCRIBE: send email to sakai-qa-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20100312/7e9f1ef6/attachment.html