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

[Beth Kirschner]

Sorry for being late on responding to this... I agree that backing out  
the change would be too risky this close to the release date, but  
given the number of issues with this feature, I don't think a property  
is the correct approach. Enabling/disabling via a property is best for  
complete features that might have concerns regarding usability or  
desirability, but not robustness.

But I do agree with Stephen's assessment regarding responsibility to  
issues which arise in code you've committed.

- Beth

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