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

Matthew Jones jonespm at umich.edu
Sat Jun 26 08:55:33 PDT 2010


Agreed, tag whats there now that appears to bind against 2.5.4. We should
get profiles that make it build against 2.6 and 2.7 later as is being
discussed before the final release. Will take a little bit of work though.

*To get to 2.6: *
The 2.6 patch I'd created and applied at from [1] which we applied to the
ctools branch about a year ago. [2] Rename the id's to the agreed upon ideas
from the thread.

<https://source.sakaiproject.org/viewsvn?view=revision&root=contrib&revision=62073>
*To get to 2.7: *
I believe this involves going to a "org.sakaiproject.purepoms" parent and
some other dependency changes. This should be the default released version.
Then this would get the project at a place where it's possible to
make independently releasable binaries.

I wouldn't put these as a blocker for an RC but think they would for a final
release. Then we'll put something simple in there to reversion the parent.
Since so many people seem to be depending on 2.5, it should compile
2.5->2.7.

Evaluation was one of the projects that got me to send out that email. [3]

[1]
https://source.sakaiproject.org/svn/msub/umich.edu/ctools/builds/trunk/patches/2.6/evaluation26.patch

[2]
https://source.sakaiproject.org/viewsvn?view=revision&root=contrib&revision=62073
[3]
http://old.nabble.com/-Building-Sakai--Dependencies,-Indie-Projects-and-Contrib-td28993698.html

-Matthew

On Sat, Jun 26, 2010 at 11:39 AM, Nicola Monat-Jacobs
<nicola at longsight.com>wrote:

> I would say, tag what's there now, and then part of the QA effort can also
> include bringing it up to date.
>
> Thanks!
>
> N
>
> On Jun 26, 2010, at  8:37 AM, Jim Eng wrote:
>
> > I would be glad to make the 1.3.0-RC branch and the 1.3.0-RC01 tag right
> away.  And I think Matthew Jones made a similar offer yesterday.  But I have
> a question first.  What version of sakai should the branch and tag depend
> on?
> >
> > 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).
> >
> > There's no great answer.  The same issue is being discussed on sakai dev,
> but we should answer it here also, possibly with a different decision than
> is reached on sakai-dev.
> >
> > Thoughts?
> >
> > Jim
> >
> >
> > 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"
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20100626/e2cb08e8/attachment.html 


More information about the evaluation mailing list