[WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800:Resources archive filehandling issues

Knoop, Peter knoop at umich.edu
Mon Apr 20 05:15:26 PDT 2009


We are well past the original delivery date for 2.6.0 and are now seriously impacting people's plans for migration and deployment by not having a release ready.  Since the zip archive problems render the feature dangerous for most users, I think everyone is in agreement that it should be disabled out of the box, one way or another.  Work was already done to disable it via a property, and while that work still needs to be QA'ed and merged, the only other code put forward does the same thing - disables it in the interface - without a property.  While this solution is far from perfect in everyone's eyes, we just don't have the time left to figure out how to back the feature out at this point, and we need to move on to finishing up the remaining work on 2.6.0.

-peter

From: sakai-qa-bounces at collab.sakaiproject.org [mailto:sakai-qa-bounces at collab.sakaiproject.org] On Behalf Of Pete Peterson
Sent: Sunday, April 19, 2009 11:50 AM
To: Haines, David; Stephen Marquard
Cc: Sakai QA; Adam Marshall
Subject: Re: [WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800:Resources archive filehandling issues

Greetings,

I can see both sides of this discussion, but we also need to make a decision for the upcoming RC01 tag ASAP. From what I have seen thus far commenting out the code seems to have the most votes, so what I'll need to know is what this would entail and how much of a delay, if any, it would mean to RC01. Perhaps Anthony or Matthew could comment on this.

If the commenting the code out is complicated and would cause large delays, I might suggest releasing the RC01 tag as is with the properties settings fix and focus energy on getting a fix into an RC02 tag ASAP. I really would like to avoid delaying the release if at all possible.

I differ to the experts,

Pete

From: sakai-qa-bounces at collab.sakaiproject.org [mailto:sakai-qa-bounces at collab.sakaiproject.org] On Behalf Of David Haines
Sent: Saturday, April 18, 2009 11:35 AM
To: Stephen Marquard
Cc: Sakai QA; Adam Marshall
Subject: Re: [WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800:Resources archive filehandling issues

Stephen,

            I think you have put your finger on the underlying issue.  How does incomplete code get into and stay in the production release?   Pragmatically, commenting out the display of the zip feature in 2.6 would keep the questionable code away from wide use, while letting those who need it available get it back trivially.  The issue I have with using the property to suppress it is that someone naive will turn that property on, have it not work, and say that Sakai is buggy.

            For one feature it doesn't matter too much what solution is chosen but once you get a few of those unwelcome decisions frozen into the production code base it becomes hard to manage and scary to change.  Once code gets scary it gets abandoned.  The release folks shouldn't have to be in the situation to have to make these decisions.

- Dave


David Haines
CTools Developer
Digital Media Commons
University of Michigan
dlhaines at umich.edu<mailto:dlhaines at umich.edu>



On Apr 18, 2009, at 10:39 AM, Stephen Marquard wrote:

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<mailto: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<mailto: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"





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090420/69e6a0b8/attachment-0001.html 


More information about the sakai-qa mailing list