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

[Adams, David]

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