[Contrib: Evaluation System] QA Effort for the Evaluation System

[Aaron Zeckoski]

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