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

Anthony Whyte arwhyte at umich.edu
Mon Apr 20 14:30:07 PDT 2009 

I've polled the K1 committers with binding votes (Ian Boston, Stephan  
Marquard, David Horwitz, Beth Kirschner, Seth Theriault, Ray Davis  
and myself) and the majority opinion (with two dissents and one did  
not vote) is to leave in place the property setting I implemented in  
order to hide the archive compress/decompress option that is added to  
a hashmap in the kernel (K1) before being passed to the resources  
tool as options in an action dropdown list.

Yet there exists a good deal of discomfort about this approach  
amongst those in the Community who have voiced their opinions on the  
list.  I think it important to take account of this advice.  So I am  
going to comment out the property "fix" in kernel /content and remove  
the property added to /config *.sakai.properties.  While I think the  
property wrapper a workable temporary solution to a challenge we have  
regarding 2.6.0 the lack of overall Community consensus renders the  
fix less than ideal in my mind.  In addition, I received suggestions  
that the property be left undocumented in order to further mask the  
option of enabling the zip compress/decompress feature.  I think this  
is a bad idea.  When people start talking about hiding properties  
implemented to hide code (experimental or challenged) then it's time  
to jettison the overall idea (and implementation) and opt for a  
different approach.

Commenting out this code is a temporary solution (as was wrapping it  
in a property).  It is not a replacement for either fixing it or  
removing it and relocating it to a branch where the issues associated  
with it can be addressed.   Sophisticated users can hack the code  
themselves although it means they will have to modify both the kernel  
and Sakai to enable the functionality.

It's been an interesting thread and I hope we discuss at least some  
of the issues raised on list or at Boston.  Several themes come to  
mind:  patch/merge management, tracking and support of committed  
features; and sakai.properties strategies.

Cheers,

Anth


On Apr 20, 2009, at 12:44 PM, Adams, David wrote:

> The problem with properties like these is that they never quite  
> tend to
> go away, or if they do disappear from the code, they hang out in the
> production properties file where no one wants to make a change that
> isn't well understood.  The stealth tools list is a little  
> different, in
> that it can be used to hide tools that may be production-ready, but
> aren't something we want users to be able to add themselves.
>
> Back to the point: IMO, properties that toggle features should be  
> clear
> and specific in their naming and those names should stay stable across
> versions of Sakai. Further, the right way to deploy "experimental"
> features (in other words, not well-tested) is to deploy a different
> build of the tool with those features. "Experimental" code should  
> not be
> in the release. If it's too difficult to back this one out before  
> 2.6.0
> final, then I think there should be a plan for either completing or
> removing the relevant code for 2.6.1. Leaving in something half- 
> complete
> is just begging for trouble and confusion later.
>
> David Adams
>
>
>> -----Original Message-----
>> From: sakai-qa-bounces at collab.sakaiproject.org [mailto:sakai-qa-
>> bounces at collab.sakaiproject.org] On Behalf Of Anthony Whyte
>> Sent: Monday, April 20, 2009 12:17 PM
>> To: Adam Marshall
>> Cc: 'Sakai QA'
>> Subject: Re: [WG: Sakai QA] [Building Sakai]KNL-155/SAK-16036/SAK-
>> 800:Resources archive filehandling issues
>>
>> Yes, although I cannot speak for the intent that lay behind the
>> inclusion of the property wiki.experimental.
>>
>> Wiki
>>
>> wiki.experimental
>> #Controls whether experimental wiki features are available in the
>> wiki tool
>>
>> wiki.experimental = false
>>
>> If wiki.experimental is set to true, experimental features of the
>> wiki tool will be available.
>>
>> Source: J. Leasia, "Sakai Properties" doc.
>>
>> There is also the stealth property, the intent of which was to make
>> availability new Sakai capabilities that a lacked sufficient
>> production track record to have them enabled by default.
>>
>> Cheers,
>>
>> Anth
>>
>>
>>
>>
>>
>>
>> On Apr 20, 2009, at 11:58 AM, Adam Marshall wrote:
>>
>>> Could the property have the work 'experimental' in it - that
>>> approach has
>>> been used before hasn't it?
>>>
>>> Adam
>>>
>>> | -----Original Message-----
>>> | From: Beth Kirschner [mailto:bkirschn at umich.edu]
>>> | Sent: 20 April 2009 14:46
>>> | To: Stephen Marquard
>>> | Cc: Whyte Anthony; David Haines; Sakai QA; Adam Marshall
>>> | Subject: Re: [WG: Sakai QA] [Building Sakai]
> KNL-155/SAK-16036/SAK-
>>> | 800:Resources archive filehandling issues
>>> |
>>> | 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"
>>> | >
>>> | >
>>>
>>>
>>>
>>>
>
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090420/77eca560/attachment.bin

More information about the sakai-qa mailing list