[Contrib: Evaluation System] Notice: Merging EVALSYS-861 to trunk?

Aaron Zeckoski azeckoski at unicon.net
Wed Jun 23 10:02:53 PDT 2010 

I disagree on point 4 because of the difficulty in undoing a major
change. I think features need to be discussed. We have proven that we
need a gate in order to force discussion of major feature changes to
the system and I am not in favor of removing it less than a week after
it was setup.
I am fine with meeting every once in awhile to discuss things but if
that causes too many delays then I guess it is not a good idea. We can
try it.

The other points sound fine though they will all require effort and a
commitment from UM to dedicate someone's time to doing them.

-AZ


On Wed, Jun 23, 2010 at 4:39 PM, Matthew Jones <jonespm at umich.edu> wrote:
> In reading through this, I think we should consider taking a step back and
> getting the evaluation project setup like a mini Sakai-project. There
> appears to be enough distributed interest and necessity for this to happen.
> The biggest problem it seemed to me from the BOF is that there hasn't active
> release management (branching/tags) of evaluation done in over a year. So
> everyone is taking HEAD of trunk as being the best version of evaluation to
> run.
> So that's the first problem that needs to be addressed by this PMC. I will
> volunteer to assist with the release management if my project manager
> agrees.
> As a initial plan:
> 1) PMC should choose a revision of trunk to make as the initial 'stable'
> branch of evaluation. Perhaps the version that longsight is using (since
> this is the newest of all the versions on [1]) is a good one?
> 2) We will make a branch (1.3.x) and tag this as a RC (since people are
> running it already). QA will run through it and bug fixes will be
> made/merged. This can be setup as an independent release project so it's
> built on builds.sakaiproject and easier to include as well.
> 3) Only bug fixes will be made to the branch. Once QA is satisfied, a final
> tag will be made.
> 4) Meanwhile, features (and other active work like this) can still be made
> against trunk (without individual issue approval) in preparation for the
> next release. Nobody should be running because they can run the branch/tag.
> This will be tracked in jira. Developers like Jim shouldn't have to ask
> permission (48 hours or else), but they might have their item removed or
> changed in an final release.
> PMC can then meet to discuss (all at one time, every few weeks? once a
> month?) what should make it to the next release. Developers would either
> have to remove/hide items that are decided as not wanted or resolve
> them. This process has worked pretty well for the RM meetings, and it's
> unproductive to dwell over each issue one at a time.
> -Matthew
> [1] http://confluence.sakaiproject.org/display/EVALSYS/Adopters
>
> On Wed, Jun 23, 2010 at 10:46 AM, Jim Eng <jimeng at umich.edu> wrote:
>>
>> There is no hurry.
>>
>> Just a comment on process: I did understand that the members of this
>> committee would essentially have veto power, which I would interpret as
>> power to ask for refinements in proposed merges.  I did not understand that
>> it would take unanimous affirmative vote of the members of the committee to
>> get anything into trunk.
>>
>> This proposal has no impact other than the need for a database change. We
>> have SQL for creating new tables with the proposed change, but I haven't yet
>> written the SQL for adding the new column in all dialects.  So I will
>> withdraw this request.  I would rather experiment with process relative to
>> some change with actual impact that warrants that kind of consideration.
>>  I'll resubmit this once we get the process worked out.
>>
>> In the meantime, if Michigan goes to trunk, we'll have to apply a patch
>> each time we adopt a new version of evalsys.
>>
>> Thanks.
>>
>> Jim
>>
>>
>> On Jun 23, 2010, at 10:02 AM, Aaron Zeckoski wrote:
>>
>> > I think I would prefer we arrange a short meeting where Jim can take
>> > us through the impact. I can be pretty flexible on times this week but
>> > Lovemore might not be available (travel) so we might have to wait. I
>> > don't think there is a need to rush anything right?
>> > Does that seem ok?
>> > -AZ
>> >
>> >
>> > On Wed, Jun 23, 2010 at 2:39 PM, Sean DeMonner <demonner at umich.edu>
>> > wrote:
>> >> What else do we need to do?
>> >>
>> >> Jim,
>> >> Per our discussion in Denver, I think we need to get positive
>> >> confirmation
>> >> from at least the four members of new PMC (of which you are one) before
>> >> anyone checks in changes to trunk. I don't think a non-response within
>> >> 48
>> >> hours can or should be considered a green light for checking in
>> >> changes.
>> >> That said, I think the four members of that team need to be highly
>> >> responsive -- if only to say, "I need more time to assess this change."
>> >> If
>> >> we don't get reasonable response times (and I'd leave it to that team
>> >> to
>> >> define "reasonable") then we've essentially locked up development with
>> >> a
>> >> slow moving committee which isn't a good thing either.
>> >> I know we reviewed these changes in detail several months ago, and that
>> >> you're eager to get them checked in, but I'd like to give our new
>> >> process a
>> >> chance.
>> >>
>> >> So, what do Rick, Lovemore and Aaron think of Jim's proposal?
>> >> SMD.
>> >>
>> >>
>> >>
>> >> On Jun 22, 2010, at 10:41 PM, Jim Eng wrote:
>> >>
>> >> Based on Sean's response, I guess I don't understand what process was
>> >> approved.  I am submitting this change for approval even though we
>> >> agreed on
>> >> it a few months ago exactly because it was not merged at that time and
>> >> we
>> >> now have a more formal process.  So I am saying I would like to go
>> >> ahead
>> >> with the proposed change unless there are objections within 48 hours.
>> >>  I am
>> >> publishing it to the list as a notice of the proposed change and
>> >> invitation
>> >> for comment.  What else do we need to do?
>> >> BTW, Matthew Jones reminded me that there is also a ddl change in this
>> >> ticket.  I will provide sql for the database change.  The ticket
>> >> already
>> >> shows the changes in the sql for creation of the database tables.
>> >> Jim
>> >>
>> >>
>> >> On Jun 22, 2010, at 5:08 PM, Sean DeMonner wrote:
>> >>
>> >> Jim,
>> >> At the BoF in Denver last week we discussed a new process for merging
>> >> changes to trunk; excerpt from notes at http://typewith.me/rN96pc2gJ3 :
>> >> --------------
>> >> Proposal: Apache-style PMC for code changes to trunk (technical
>> >> leadership).
>> >> Members have veto power.
>> >> Nominations: Jim Eng (UM), Aaron (Unicon), Rick (UMD), Lovemore (UCT).
>> >> Output of the team: features that go in should be sent to the list as
>> >> individual emails. Preferably before but definitely when the feature
>> >> goes in
>> >> -------------
>> >> So let's follow our (new) process and see what that team has to say
>> >> with
>> >> regard to merging these changes.
>> >> SMD.
>> >>
>> >>
>> >> On Jun 22, 2010, at 4:54 PM, Jim Eng wrote:
>> >>
>> >> We discussed this several months ago with general agreement that it
>> >> would be
>> >> OK to merge some work done back in February to trunk.  The work is
>> >> described
>> >> here:
>> >>
>> >> http://jira.sakaiproject.org/browse/EVALSYS-861
>> >>
>> >> I thought I had merged it, but I just discovered it has not been
>> >> merged.
>> >>
>> >> To review, this adds a member variable named "localSelector" to the
>> >> EvalEvaluation class (along with a setter and getter) and it adds a
>> >> column
>> >> in the database for this property in the EVAL_EVALUATION table.  This
>> >> makes
>> >> it possible for institutions to set this column in some way (in a
>> >> provider,
>> >> for example, or in import code) and then use it to select evals and
>> >> other
>> >> entities for export later.  The rest of the EVALSYS codebase ignores
>> >> this
>> >> value.
>> >>
>> >> Michigan has had this change in production since February with no ill
>> >> effects.  The JIRA ticket indicates that Maryland would like to use
>> >> this as
>> >> well, and that Maryland is interested in providing a UI for setting
>> >> this
>> >> value when creating or modifying an evaluation, but that work has not
>> >> been
>> >> done and is not part of the current proposal.
>> >>
>> >> As I said, we had approval of this a few months ago, but since the
>> >> change
>> >> was not merged to trunk at that time, I thought it would be prudent to
>> >> announce it again and give 48 hours for comment before merging it to
>> >> trunk.
>> >>  So I will merge these changes to trunk unless there are objections
>> >> before 5
>> >> p.m. EDT Thursday.
>> >>
>> >> Thanks.
>> >>
>> >> Jim
>> >>
>> >>
>> >>
>> >> ==========================================================
>> >> Sean DeMonner, IT Senior Project Manager, CTools Implementation Group
>> >> Digital Media Commons @ The Duderstadt Center, U-M      (734) 615-9765
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> SMD.
>> >>
>> >> ==========================================================
>> >> Sean DeMonner, IT Senior Project Manager, CTools Implementation Group
>> >> Digital Media Commons @ The Duderstadt Center, U-M      (734) 615-9765
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> 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

More information about the evaluation mailing list