[cle-release-team] lesson builder for 2.9

[Charles Hedrick]

It's really just UI consistency. The reason for wanting it in 2.9 is simply that I would prefer for the community to be using code as close to what is running at Rutgers as possible, to minimize maintenance issues.


On Nov 30, 2011, at 1:50 PM, May, Megan Marie wrote:

> I’d like to see this group be methodical about making decisions that break practices used in the past.     There’s a reason that new features have rarely been introduced after code freeze and it’s because we’ve been burnt.
>  
> I’d personally like to better understand why this is desirable.  Is it aesthetics?   Does it address usability concerns, ect?
>  
> Megan
>  
>  
> From: Noah Botimer [mailto:botimer at umich.edu] 
> Sent: Wednesday, November 30, 2011 1:39 PM
> To: Charles Hedrick
> Cc: May, Megan Marie; cle-release-team at collab.sakaiproject.org
> Subject: Re: [cle-release-team] lesson builder for 2.9
>  
> To be practical, I think that the LB 2.9 code is getting the most functional and technical QA of just about anything slated for the 2.9 release. I'm unaware of anything else in production anywhere that is a light modification of what will be released. Rather, folks are running some 2.7 or 2.8 version with modifications layered on top. I could be missing something but, in general, I believe this to be true. (Maybe some portal chat or profile 2 stuff, to be fair?)
>  
> When we have someone committed to this kind of running before release, the quality of testing is improved significantly. I would also remind everyone that Rutgers and UCT have done this kind of pre-release recon for us multiple times at a cost and we have benefitted greatly, especially as the legacy early adopters like U-M and IU have had to slow down (please note that both are on 2.7.x while Rutgers was early to the fold in 2.8).
> 
> 
> I'm also not saying that we should be taking every feature until February. But if Rutgers QA finds a bug or major usability issue and prepares and runs a fix in production, all before we reach beta, I think it behooves us to listen up. 
> 
> Thanks,
> -Noah
> 
> On Nov 30, 2011, at 1:21 PM, Charles Hedrick <hedrick at rutgers.edu> wrote:
> 
> I'll do whatever you like, but while local testing may not be enough, we all know that for most tools local testing is probably the biggest piece of what happens. I'm not worried about the reliability of LB 2.9. The differences from what is in production at Rutgers are minor, and we've tested the 2.9 trunk quite carefully. I had a student run through all combinations of the various features in trunk. He was quite thorough. 
>  
> However we're probably going to use the newest code at Rutgers for the Spring. In principle it's not a wonderful idea for the community to be using a version that has never been used at Rutgers. There's virtually no chance of a bug in 2.9 that won't also show in our copy, since all we're doing is moving the same output into a popup. But the split does complicate support for me. The likely cost is not continuing to do fixes to 1.3. It is being used at a number of institutions. It's gotten all the fixes based on our student's testing, so it's probably not going to have any major problems, but still, it's not the approach I would prefer.
>  
>  
> On Nov 30, 2011, at 1:03 PM, May, Megan Marie wrote:
> 
> 
> IMHO, local testing isn't enough.
>  
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/cle-release-team/attachments/20111130/720874aa/attachment-0006.html