2.8.0 Inclusion Voting Tally and Comments

Proposed Additions voting

ROLL CALL VOTES

There are currently 15 active TCC members so there must be 10 YES votes to override.

"non-controversial"/consensus additions for 2.8

Comments/ Discussion

• Matt Jones comments:
  • +1 Including optional CKEditor:    Commentary: I support Noah in this inclusion and also with code if he requested. There's no rollback needed as it the FCKEditor isn't being removed, just a newly added to reference. This is an optional feature that you'd have to enable globally with the property "wysiwyg.editor=ckeditor". Unfortunately, SAK-7857 hasn't been implemented yet, so users can't change the editor on a per-user preference level. This would probably just be between ckeditor/fckeditor/no editor. So 'most likely' the default wouldn't change but it would be an available option for those who want the CKEditor features (better accessibility, better paste from word, integration with afterthedeadline, etc). Perhaps the preference can be surfaced for 2.8.1 or at LEAST targeted by 2.9.
  • +1 Inclusion on all of the localization stuff. I really like this change and would like to see this included. I see this as a first step into getting other things (possibly) more easily changed dynamically for 2.9.
  • +0 Quartz : Don't know enough about changes, we really don't run much stuff through quartz at Michigan (often opting to run jobs outside of a live instance). It seems that Quartz is only used by a few places and not completely understood. As long as they don't break anything I don't see a problem.
  • +0 Account validation: No opinion on this. Most installations are hopefully integrating with a single signon provider and managing users/passwords. If it's already completed work that seems fine.

• Jean-Francois:
  • CK Editor: not sure about rollback and if anyone other than Noah working on this.
  • Localization: not mature enough, its own i18n is incomplete. Can accept the KNL changes if the Kernel Team is confident about the safety and the lack of effect (is the default OFF really OFF?) of including it without using it.
  • Quartz Job Scheduler: need a abstract
  • Account Validation: Is anyone else than UCT using it?

S3/Nakamura Hybrid

Comments/ Discussion

• Jean-François Lévêque:  -1 unless removing it from the build is documented.   I really want to learn how to build a lean Sakai without all the code that is off and I don't need when it's possible. And it seems possible in this case.
  • Lance Speelmon: http://collab.sakaiproject.org/pipermail/sakai2-tcc/2010-September/000479.html
• AZ: -1.   The REST endpoints are not visible in the standard place in Sakai and use a separate mechanism. While this is acceptable for something distributed separately, this duplication is not OK for a core part of the product as it increases maint costs. The REST access should use EB as the other core REST services do.
  • Lance Speelmon: The argument "it is not EB" is difficult. However, I might push back on the maintenance cost issue. The two servlets are pretty darn simple, servlets are taught in every Java 101 class. I believe that anyone who has ever taken a java class could maintain this code. Simpler should translate into lower maintenance costs.
• John Lewis: +0 at this point. Can someone make the case for how commonly we think this functionality will be used with a relatively stock 2.8 distribution? Or is it really only going to be used by bleeding-edge school that customize the heck out their codebase anyway and wouldn't have any problem adding this in as a contrib module?
  • Lance Speelmon: Presumably, it will become more common as institutions begin introducing S3 locally. From a product management perspective, a conversation like "if you have 2.8 then you have the hybrid bits" is much easier than go get a collection of bits and install them in your production instance... My hope is that hybrid be as simple a proposition as possible.  Thanks.
• Megan: 0 - I need to defer to others expertise on this one. 
  • Lance Speelmon: IMHO, this is more of a product management decision than a technical decision.  You might reconsider... Also see this response: http://collab.sakaiproject.org/pipermail/sakai2-tcc/2010-October/000521.html
• Seth: 0. Others are more familiar with the technical underpinnings.
  • Lance Speelmon: IMHO, this is more of a product management decision than a technical decision.  You might reconsider...
• Anthony: + 0 (for the moment) Questions
  • Can we get a commitment from a second developer to support the code?
    • Lance Speelmon: http://collab.sakaiproject.org/pipermail/sakai2-tcc/2010-October/000491.html
  • What institutional support is there for this module?  I am assuming IU but is there another school/organization willing to support it if we include it in 2.8.0?
    • Lance Speelmon: http://collab.sakaiproject.org/pipermail/sakai2-tcc/2010-October/000491.html
  • would TCC members object to leaving in place the hybrid patches added to login and providers?  Assuming the patches do no harm (they are off by default) they should stay in 2.8 in order to simplify adding hybrid (an indie) to their build if it is not included in the release.  SAK-17222 / SAK-17223
    • Lance Speelmon: while this is better than nothing, it would be a half step with little value.  Including the hybrid webapp would be preferred.  Thanks.
• Chuck: +0
  • I think there is little value in a large, independent, unused artifact being carried along in the 2.8 distribution "in case" someone running 2.8 might want to run hybrid mode. I also do not want dependencies on this code introduced elsewhere without solid review. If a school is going to run hybrid mode, they have a lot of things to do to both their S3 and S2 instances - dropping in a war file into their 2.8 is likely to be the least challenging of their technical details needed to implement hybrid mode.
    • Lance Speelmon: Large? Two servlets and a few utility classes?  The dependency graph is also quite clean right now.  But, maybe you are right - it could be a good opportunity for commercial partners to install hybrid.
  • I am strongly supportive of keeping the patches in 2.8 (as described below) to make it easy to drop the nakumura war into a Sakai to enable hybrid mode.
    • Lance Speelmon: IMHO the TCC has been very focused on the two servlets.  Frankly, the UDP and login code should be under more scrutiny than the webapp.
  • I am strongly supportive of keeping everything in the SVN and evolving it there.
  • I am strongly supportive of keeping nakumura in trunk+experimental so Lance always has a nightly server to play with and to insure that changes either to the rest of Sakai or the Nakumura artifact do not result in incompatibilities in terms of the build ability of Sakai+the nakumura webapp.
    • Lance Speelmon: Maybe this has value to others, but has no value to me personally (i.e. if hybrid does not make 2.8, then this is little reconciliation).
  • But I don't think there is a case to be made to include the binary and source artifacts for the nakumura webapp in every Sakai 2.8 distribution at this time.
    • Lance Speelmon: I do not agree; see above comments re: easy conversations and product management.  Thanks.

Captcha support

Comments/ Discussion

• Jean-Francois
  • -1 because we are past the code freeze/branching and this might slow down the process.
  • Are we sure all the code provided won't be used at all by default?
    • From AW: Look here: http://jira.sakaiproject.org/browse/SAK-12489?page=com.atlassian.jira.plugin.ext.subversion%3Asubversion-commits-tabpanel
  • Who in QA will test it? Is all else covered?
    • From AW: Alan Berg. "Is all else covered"-what's else? If you mean, does it have a test plan, looks like not yet. Have the new properties been added to default.sakai.properties in trunk-not yet.
  • Time will run out quickly, as far as I can remember from previous releases and their quality.
    • From AW: We want to time to run out quickly. As for quality, the 2.7 release cycle was shorter than the 2.6 release cycle with no apparent loss in quality. The goal for 2.8 is to shorten the release cycle still further, again with no loss in quality. I doubt adding captcha as a new feature will impair the timeline.
  • I know lots of things have been expected for a long time but this is not a criterion for me in the case of a late merge.
    • From AW: We should evaluate each proposed new feature on its merits, risk, etc. We missed this one. Is that sufficient justification to dismiss it for another year? I say no. If we can work a new feature into a release under known circumstances we should not fear to do it. Flexibility is regarded as a virtue; Inflexibility is not. The TCC should aim to be flexible.
  • Is more than one person in one institution outside the MT gonna support this for at least one year?
    • From AW: Overkill in my opinion. The criteria you cite was originally framed with regard to tool additions. This is a new feature of modest proportions added to an existing tool, one supported by the MT. For this particular commit (r82537) I'd argue it went into maintenance mode the second after it was committed.
  • I'm not withdrawing my -1 vote. This is mostly about the straw that broke the camel's back. Giving more work to the QA director and the MT is not what I want. I want other people to contribute if this feature is really wanted. If we're able to release 2.8 in March, we could be able to release 2.9 with it in September 2011 and it will be included in a year. We first have to prove we're able to produce a good 2.8 release in March. And I'm still not confident about our (TCC, QA, MT, indie and tool leads) capability to deliver on time with quality. From the production feedback I get, 2.7.0 was not a production release and I don't know yet about 2.7.1

• Beth
  • The problem is caught between the need to be disciplined about our process and also our need to be agile with new features. While I lean towards discipline, I'm willing to vote YES because (1) I reviewed the code and it seems low-risk, (2) I don't think our process fully serves the review and inclusion community contributions in a timely fashion (mostly due to lack of resources).
• Megan
  • Alan, I think you should find someone other than yourself to test this. (I hear there are some folks from Marist will to aid in this area ). My 2 cents is that the community outside of this group needs to become more engaged in testing for 2.8
• Steve Swinsburg
  • This one has been around for almost three years, and looks like it was originally targetted for 2.6 but lacked the resources to actually get it in.
  • Ok I've reviewed this and it looks good. I've attached an updated patch to the JIRA that works in trunk, as well as a screenshot. I would really like to see this in even though it slipped the documentation dates. It is disabled by default
• Seth
  • I must remind everyone that the deadline for documenting new things to be added for 2.8 was September 8, 2010. Based on previous experience, I think it would be a mistake to rush things into the release.
• Anthony
  • It's off by default which helps mitigate risk.
  • QA supports inclusion.
  • We have branched in mid-September, not mid-November; we have time before the XMas holidays to test it
  • It does not appear "rushed" to me.
• Noah
  • I agree with this and will add that we had a significant lack of clarity around 2.8 until near/after the conference. It was not an appropriately measured process throughout, so a bit of careful subjectivity will serve us well. This doesn't mean anything goes; just that we gathered to bring together good judgment and progressively add the structure that we saw lacking.
  • Feature identification, work, ramp down, and freeze were simply not on the calendar long or specifically enough for everything that we should ship to be handled 100%. If we see a very hard-nosed release in our future, now is the time to start that process with clear milestones - for some release beyond 2.8.

ShortenedUrlService

Comments/ Discussion

• JF:  0 for default off

Notification Preferences

Comments/ Discussion

• John Bush:  +1
  • There are a lot of tools that have their own preferences around this stuff, wiki, msgcntr, forums.  These could be modified to take advantage of this.  Anything that makes sakai play nicer with itself I'm in favor of. 
• Jean-Francois: -1
  • -1 unless I know enough tools that will be updated to use it in 2.9
• John Lewis
  • +0 at this point. Are there any other tools declaring interest in this function? Or only OSP Matrices? If we think this presents real value to other tools, then I can see including it, but otherwise making kernel changes to support this functionality for one tool seems extreme.
• Anthony Whyte
  • I will change my -1 to a +1 if there is a commitment to include one or more unit tests that test whether or not a given set of notification preferences are registered by the code 2. bulk up the APIs so that useful javadocs can be generated. A commitment exists here but no code commits yet.