[Contrib: Evaluation System] Policy for managing merges to trunk

Jim Eng jimeng at umich.edu
Sat Jun 26 05:53:55 PDT 2010


+1. What Aaron said works for me.  I agree that a week or two is appropriate, given that we have people in many time zones and on different academic schedules. With less notice, people will be more likely to miss proposals that affect them.

Jim

 
On Jun 25, 2010, at 9:12 AM, Aaron Zeckoski wrote:

> Probably easiest to discuss this in a call but here is how I see it.
> 
> Bug fixes can go in without review as long as they are not
> masquerading as features.
> Minor features with no real impact can go in with just a notification
> sent to the list (easy to unmerge if needed).
> Major features should be discussed something like a week or two in
> advance of commit and agreed do before the actual commit.
> 
> We need to define what major features are but my assumption is changes
> to the data model or services functionality or substantial/additive UI
> changes count as major.
> 
> As long as everyone is communicating what they are doing or planning
> to do then things should be fine and no one will be blindsided. Really
> the goal here is to be good neighbors and to respect the other members
> of the community. Making up some complex process is not the goal but
> we can't really afford to have it as a free-for-all because that is
> too disruptive to schools that depend on this tool.
> 
> -AZ
> 
> 
> On Fri, Jun 25, 2010 at 11:30 AM, Jim Eng <jimeng at umich.edu> wrote:
>> Here's what I thought we were agreeing to in the BoF:
>> Before committing new features (or other code changes not needed to fix a
>> bug), developers should send a notification to the list describing the
>> change and allowing a chance for review before committing the change.  We
>> also created a committee.  The members of the committee should review
>> proposed changes, and they can veto changes that would cause problems for
>> other users.
>> A lot of things were unclear about that. I do not think we were saying that
>> nobody could merge changes to trunk without affirmative response from all
>> four members of that committee.  If that is what we agreed to, I would give
>> a blanket consent for changes provided adequate notice is given and provided
>> I do not specifically object to them.  I would hope that the other members
>> of the committee would see it the same way.
>> I think we *DO* need to agree on how much notice is needed. There are two
>> elements to that: 1) the specificity of the description of the changes and
>> their impact on behavior, and 2) the amount of time before the change will
>> be merged to trunk.
>> What we want is a process that protects against changes that will change
>> behavior in unexpected ways.  We want a chance for any interested party to
>> review proposed changes before they show up in trunk.  We want changes that
>> might impact other adopting institutions to be reviewed in detail and
>> delayed until the impacts are understood and mitigated.
>> Thoughts?
>> Jim
>> 
>> 
>> On Jun 24, 2010, at 11:22 AM, Adam Marshall wrote:
>> 
>> I agree with 1, 2 and 3 but am not sure about 4.
>> 
>> Can I reiterate our desire to help with the QA process. we're moving into
>> production v soon but are tagging it as a Beta release as there seem to be
>> lots of bugs. We have just moved to head so some of the issues may have been
>> fixed - we haven't had time to check yet.
>> 
>> adam
>> 
>> From: evaluation-bounces at collab.sakaiproject.org [mailto:evaluation-bounces at collab.sakaiproject.org] On
>> Behalf Of Matthew Jones
>> Sent: 23 June 2010 16:40
>> To: Jim Eng
>> Cc: evaluation at collab.sakaiproject.org
>> Subject: Re: [Contrib: Evaluation System] Notice: Merging EVALSYS-861 to
>> trunk?
>> 
>> 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"
>> 
>> 
>> _______________________________________________
>> 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