[WG: Sakai QA] [BuildingSakai] KNL-155/SAK-16036/SAK-800:Resources archivefilehandling issues

[Berg, A.M.]

I agree with Seth.

Alan

Alan -- Alan M Berg 

Available: Monday-Thursday 
Informatiseringscentrum 
Universiteit van Amsterdam



-----Original Message-----
From: sakai-qa-bounces at collab.sakaiproject.org on behalf of Stephen Marquard
Sent: Sat 18/04/2009 16:39
To: Whyte Anthony; David Haines
Cc: Sakai QA; Adam Marshall
Subject: Re: [WG: Sakai QA] [BuildingSakai]	KNL-155/SAK-16036/SAK-800:Resources archivefilehandling issues
 
In general, I would also agree, but pragmatically given the closeness to the release, the risk of backing it out is certainly higher than commenting it out or making it disabled by default.

And I think there are advantages in having a property for it that help developers & QA move it towards production-grade quality. There is lots of previous precedent for this for other "provisional" features that were introduced, disabled by default, and sometimes enabled by default on nightly servers to give them better testing exposure.

As far as this feature goes, I'd say it was problematic but not completely broken as such. We've had it in production in our 2-6-x build, and the only support issue that's come up is the Dropbox one.

I think the bigger issue here is how quite so many features additions destined for 2.6.0 (this one, rwiki, delayed notifications, etc.) came to be committed in a functionally incomplete state, and both the original developers and committers were not available to address the resulting problems. We need to set stronger expectations that if you contribute or commit code, you need to support it at least through to the release.

Regards
Stephen 
 
>>> David Haines <dlhaines at umich.edu> 04/18/09 1:22 PM >>> 
I have to completely agree with Seth on this.

- Dave


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



On Apr 17, 2009, at 10:06 PM, Seth Theriault wrote:

> Anthony Whyte wrote:
>
>> Using properties to mask or otherwise hide incomplete or
>> problematic code (see SAK-800) is not ideal.  However, given
>> that at least one institution, Oxford, is comfortable using
>> the code as is, renders problematic the simple and
>> straightforward expedient of commenting out the
>> functionality and forcing them into hack mode when
>> implementing 2.6.0 or 2.6.x.
>
> I think that the "properties" approach sets an extremely bad
> precedent. Broken and incomplete code should NEVER be
> knowingly released, plain and simple.
>
> Apologies to Oxford, but if they are "comfortable" with
> something that almost everyone is agreed is broken, they
> should continue to patch it in until it gets in workable
> condition and others start to adopt. That's what being on the
> bleeding edge is all about.
>
> Seth
>
> _______________________________________________
> 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"
>
>


_______________________________________________
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/20090418/506ea429/attachment.html