[cle-release-team] Lessons new version

[Steve Swinsburg]

Hi Chuck,

> I'll certainly put significant fixes back in, i.e things that affect security, reliability, or correctness of operation. But most of the reports right before release were basically suggestions for improvements in UI. I can't guarantee to do those in a release once trunk has diverged. I believe that's true of other tools as well.

UI improvements aren't that much of a concern unless they are bugs. Bug fixes are what we want to see in maintenance branches.

> I'd like to see the newest Lesson Builder put in a release in the Spring. It would have this and (if I can get Eric for a few weeks over the holiday, as seems likely) inline questions.

Ok well we can vote on that when the time comes. It may be possible to take the released version of Lessons at the time and drop it in. This is where indies are useful.

cheers,
Steve


On 26/11/2012, at 11:17 AM, Hedrick Charles <hedrick at rutgers.edu> wrote:

> 
> On Nov 25, 2012, at 5:46:22 PM, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
> 
>> Hi Chuck,
>> 
>> Database changes are generally ok, and would be included in the next conversion script, ie 2.9.0-2.9.1 or 2.9.1-2.9.2 depending on what version this was ready for. This is true in the case of bugfixes that require db changes. 
>> 
>> However the fact that it is a new feature going to a maintenance branch generally means no, however there have been exceptions.
>> 
>> What should happen is you commit the feature to trunk and let it sit for a while and be tested, then make a request to the TCC or it to be merged back. We will then assess in accordance with the Maintenance Branch Merge Policy: https://confluence.sakaiproject.org/display/TCC/Maintenance+Branch+Merge+Policy
>> 
>> So as you mention, this might be best for 2.9.2 or even 2.9.3 next year, after it's had considerable testing.
>> 
>> A couple of things that concern me:
>> It alarms me that you describe the feature as dangerous.
>> Lack of maintenance of the tool overall. This tool is obviously under active development but now that Lessons is a core tool, it needs to be done in a way that fixes can be backported and maintenance continues. 
> 
> I'll certainly put significant fixes back in, i.e things that affect security, reliability, or correctness of operation. But most of the reports right before release were basically suggestions for improvements in UI. I can't guarantee to do those in a release once trunk has diverged. I believe that's true of other tools as well.
> 
> As to danger. The design is quite straightforward. It doesn't involve reorganization of any code. It's just that there are lots of special cases, and it's possible that I've missed one.
> 
> I'm willing to try parallel maintenance. Because the change is fairly localized, it may be that most maintenance won't be affected. We'll see. I have to run in that mode for a while anyway. I don't think this would be appropriate for 2.9.1. I'd like it to get some runtime at Rutgers, which I can't do until January. But the last time we diverged I found it hard to move patches between the two.
> 
> We had this same discussion about 6 months ago, and the community pretty much all told me not to diverge, but keep putting new stuff in 2.9. Of course now that 2.9 has released things change, but if 2.10 isn't going to release in the Spring as is traditional, I'd like to see the newest Lesson Builder put in a release in the Spring. It would have this and (if I can get Eric for a few weeks over the holiday, as seems likely) inline questions.
> 
> 
>> 
>> cheers,
>> Steve
>> 
>> 
>> 
>> On 25/11/2012, at 11:18 PM, Hedrick Charles <hedrick at rutgers.edu> wrote:
>> 
>>> Later today I'm going to put out for testing a version of Lessons that lets you designate student content pages as owned by groups rather than individuals. If you grade a page, the grade goes to every member in the group, and anyone in the group can edit the page.
>>> 
>>> This is one of the two major features I'm hoping to do for Spring. The other is inline questions. We see regular need for both. (The inline questions depends upon my getting a few weeks from the original developer, which it looks like will probably happen.)
>>> 
>>> Both of these things are going to require database changes. The group-based student content is probably the more dangerous of the two.
>>> 
>>> What is your feeling about putting this in 2.9.x? Is there a rule against database changes in dot releases? My concern, as always, is that I'm not going to be able to do very active maintenance of two versions. Once Rutgers moves to a new version, as we will for the Spring, my best testing also moves. So allowing 2.9.x to fall behind has costs. However I would want significant testing before putting any of this in 2.9.x, probably in production at Rutgers. I think that means not 2.9.1, even though it will be ready, though you may have other thoughts.
>>> 
>>> 
>>> _______________________________________________
>>> 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/20121126/38937558/attachment-0006.html