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

Anthony Whyte arwhyte at umich.edu
Mon Apr 20 09:16:39 PDT 2009


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

-------------- 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/311492b2/attachment.bin 


More information about the sakai-qa mailing list