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

Jim Eng jimeng at umich.edu
Wed Jun 23 08:31:38 PDT 2010 

Agreed, Nicola. The ideal situation would be to have several schools using the same tag that is very close to the head of trunk that has has QA done on recent changes.  I think Sean's point is that some schools have been using trunk directly at a particular revision number, and that's probably not a good idea either for those schools or for the community.  

Jim    


On Jun 23, 2010, at 11:26 AM, Nicola Monat-Jacobs wrote:

> For those institutions that have made a lot of local modifications to the tool in the past, using your own branch is probably not a bad idea. However, I don't think it's something everyone should be required to do in order to have a smooth experience using the eval sys tool. 
> 
> I do think there was some discussion of cutting an RC tag asap to give people something to work off that's not trunk. 
> 
> Nicola
> 
> On Jun 23, 2010, at  8:19 AM, Sean DeMonner wrote:
> 
>> I agree that the idea is not to prevent changes to trunk. The idea is to prevent changes to trunk that break others' instances. 
>> 
>> So if a proposed change is of concern to a particular institution I think it is incumbent upon this team to figure out a way to accommodate the change in such a way that it doesn't break things for someone else (e.g. making mutually exclusive UI elements or backend processes configurable with a property that is set off by default).
>> 
>> That said, another practice that we discussed and agree upon in Denver (which should help with this situation), is that the institutions running in Production (and probably those in Pilot as well) should create and move to their own branch if they have not already done so. Running a Production instance from the trunk is a risky move because trunk is not always going to work perfectly (occasionally it won't even build...). If we all get on our own branches and periodically snap back to trunk when new tags are cut, QAed, and released, then the pressure level on our new PMC team will drop significantly because they won't need to ensure that any change is perfect before it gets checked in. They should be able to do a quick review for glaring problems and then give the go-ahead if there are no obvious issues. The schools running in Production shouldn't have to do a full QA cycle with each proposed change to trunk because they're not running from trunk.
>> 
>> Frankly, if we don't take this step, then I think the PMC will be effectively paralyzed and we'll be having another discussion in Berlin about how we really need to bring the changes from our various branches back in to trunk...
>> 
>> SMD.
>> 
>> 
>> On Jun 23, 2010, at 10:46 AM, Jim Eng 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
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 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"
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/evaluation/attachments/20100623/46f436d1/attachment-0001.html

More information about the evaluation mailing list