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

[Clay Fenlason]

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