[Contrib: Evaluation System] Running evals in 2.6

Mon Jun 28 13:23:46 PDT 2010

Just to throw in my 2 cents, I never had any problems building trunk with 2.6 or 2.7. I realize this was because I also happen to have 2.5.4 artifacts in my repo. Nevertheless, this has never yet caused a problem and I haven't run into the issue Stephen details. 

In the meantime, we should include a note about updating your poms in the install docs. On principal, I agree that trunk and the rc should work off of the latest current sakai version, which is 2.6, but we can coordinate this in a way so that schools on 2.5 are not negatively impacted.

How do the tools that are now on independent release solve this problem?

Thanks,
Nicola

On Jun 27, 2010, at  8:07 AM, Jim Eng wrote:

> I've had the trouble Stephen mentioned, and I think there are some additional problems related to course-management in 2.7.  
> 
> Plus, many people want to select source and build it together for various reasons.  I think it is a good idea to support that even if it's were compatible at the binary level.  Being able to build and deploy as a separate process is great, and if source compatibility was difficult, it wouldn't be worth it.  But having a way to do it is not difficult.  
> 
> Your points about remaining 2.5.4 compatible by default is good, but sakai is no longer supporting 2.5.x officially. Being easily compatible with the supported projects (2.6.x and 2.7.x) should be a goal.
> 
> Jim
> 
> 
> On Jun 27, 2010, at 3:40 AM, Stephen Marquard wrote:
> 
>> At some point we ran into difficulties with 
>> 
>> java.lang.ClassNotFoundException: org.sakaiproject.util.BaseResourcePropertiesEdit 
>> 
>> as a result of some packaging error related to evals referencing 2.5.4 but running it in 2.6.x. Specifically the tool was not including a jar that included BaseResourcePropertiesEdit which is in the sakai-kernel-util jar in 2.6.
>> 
>> I believe we had to resolve this by updating the poms in our evalsys 2.6.x branch to build against 2.6.x, but I could be wrong and will defer to David Horwitz on this as he did the actual fix (our UCT ref for this issue is VULA-749).
>> 
>> Regards
>> Stephen 
>> 
>>>>> Aaron Zeckoski <azeckoski at unicon.net> 6/27/2010 12:57 AM >>> 
>> On Sat, Jun 26, 2010 at 4:37 PM, Jim Eng <jimeng at umich.edu> wrote:
>>> Evalsys trunk depends on sakai version 2.5.4.  Is that where we want to stay for now?  That makes it easy to work with sakai 2.5.x but requires some carefull work to get it to build and deploy with sakai 2.6.x and even more careful work to get it to build with 2.7.x and beyond (or sakai trunk).
>> 
>> Yes it is for a variety of reasons but the big ones being that there
>> are schools running it which are not upgrading to Sakai 2.6 this year.
>> Also, being heavily involved in 2.7 development I don't see where it
>> actually differs much from 2.6 as far as integration from a tool
>> perspective. Very few of the APIs have changed and I see no reason to
>> even bother building against a version past 2.5 for now. The binaries
>> should work fine.
>> 
>> Can someone maybe explain why they feel a 2.6 or 2.7 specific build is
>> needed or even helpful?
>> 
>> -AZ
>> 
>> 
>> 
>> 
>>> On Jun 26, 2010, at 2:03 AM, Aaron Zeckoski wrote:
>>> 
>>>> This all sounds great to me.
>>>> I would suggest the following approach:
>>>> 
>>>> 1) Create a branch called 1.3.0-RC
>>>> 2) (not strictly needed) From that branch, create a tag: 1.3.0-RC1
>>>> 3) Merge changes into the branch from trunk
>>>> 4) At some point create a new RC# tag from the branch
>>>> 5) At some other point agree the RC tag is the release
>>>> 
>>>> -AZ
>>>> 
>>>> 
>>>> On Sat, Jun 26, 2010 at 12:07 AM, Nicola Monat-Jacobs
>>>> <nicola at longsight.com> wrote:
>>>>> This week I was given the go-ahead to spend a few hours each week on EvalSys QA coordination efforts, as I offered in Denver. I don't want to step on any toes, but I have some suggestions on how we might precede.
>>>>> 
>>>>> I've been following the thread on merging EVALSYS-861 into trunk with interest and I think the suggestions from Adam, Aaron and Jim all make sense and seem to be in line with our conversations from Denver.
>>>>> 
>>>>> The real sticking point relates back to whether or not developers can commit to trunk without approval (partial or unanimous) from the newly-anointed PMC, which ultimately relates back to, I think, QA.
>>>>> 
>>>>> As we all know, without some oversight, trunk can become hazardous to the health of institutions running EvalSys, but waiting for the 4 very busy people on the PMC to fully review something before check-in risks putting us back where we started: with no forward motion.
>>>>> 
>>>>> I'd like to propose the solution offered in Denver by (I think) Stephen M. Let's cut an RC tag right now - it doesn't have to be perfect (should build though :) ), but it will give institutions something to run that isn't trunk and can be the 'go to' check out for those looking to work with EvalSys. It almost doesn't matter which rev it is, waiting is worse at this point then picking the wrong rev, I think.
>>>>> 
>>>>> Then, I can work with those groups from Denver who were willing to do QA and develop processes, Test Plans and a repeatable approach for QA going forward.
>>>>> 
>>>>> I agree with Aaron that every change (to trunk or whatever) should have a JIRA going forward. I'd also like to request that whoever has the magic to hook our JIRA project up with SVN should perform that particular incantation, if possible.
>>>>> 
>>>>> Bug fixes will need to be committed to both trunk and the tag, just like Sakai and other mature projects. I'd like to to take those efforts as a model for ours, if possible. I do have some process questions though, since I'm not intimately familiar with the mechanics of the normal Sakai QA process:
>>>>> 
>>>>> Once an RC tag is cut, and patches need to be made, I assume those patches aren't made to the tag (since that sort of goes against the nature of a tag). Are they normally made against a corresponding branch? We don't want to hold up dev work in trunk, but I assume patches will need to be made to graduate from RC to actual release.
>>>>> 
>>>>> Additionally, I'm happy to cut the RC tag, if someone can give me permission to do so. I also have limited permissions in JIRA, will probably need to be able to edit versions and assign issues..... I should probably go to Anthony with this, right, unless anyone has any objections?
>>>>> 
>>>>> I also think Aaron's most recent email about what types of commits require what kind of communication is great and should be the model we follow, regardless of what form QA takes.
>>>>> 
>>>>> Please let me know your thoughts!
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Nicola Monat-Jacobs
>>>>> Senior Technical Manager
>>>>> The Longsight Group
>>>>> nicola at longsight.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> evaluation mailing list
>>>>> evaluation at collab.sakaiproject.org
>>>>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>>>>> 
>>>>> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>>>> _______________________________________________
>>>> evaluation mailing list
>>>> evaluation at collab.sakaiproject.org
>>>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>>>> 
>>>> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>> _______________________________________________
>> evaluation mailing list
>> evaluation at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>> 
>> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>> 
>> 
>> 
>> 
>> 
>> ###
>> UNIVERSITY OF CAPE TOWN 
>> 
>> This e-mail is subject to the UCT ICT policies and e-mail disclaimer published on our website at http://www.uct.ac.za/about/policies/emaildisclaimer/ or obtainable from +27 21 650 4500. This e-mail is intended only for the person(s) to whom it is addressed. If the e-mail has reached you in error, please notify the author. If you are not the intended recipient of the e-mail you may not use, disclose, copy, redirect or print the content. If this e-mail is not related to the business of UCT it is sent by the sender in the sender's individual capacity.
>> 
>> ###
>> 
>> 
>> 
> 
> _______________________________________________
> evaluation mailing list
> evaluation at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/evaluation
> 
> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"