[Contrib: Evaluation System] Evaluation Feature Requests Process

Jim Eng jimeng at umich.edu
Sat Jun 26 07:48:54 PDT 2010


Rick,

I think JIRA works well for documenting proposed changes.  It has the advantage of being able to track the changes that are committed to a branch and later to track what has been merged in to other branches or trunk.  Could you show an example of the kind of information you would want in confluence to supplement the information in JIRA?

Meanwhile, based on your comments and following up on Nicola's and Aaron's last couple posts on this, I propose the following (most of which is the norm for developers working in sakai core and kernel): 

If the JIRA ticket describes a bug fix or a feature/functionality change that makes no changes in database schema, APIs, or default behaviors (am I missing anything?), the change can be committed to trunk with an EVALSYS JIRA ticket cited in the commit message.  

If the JIRA ticket describes a bug fix or a feature/functionality change that makes changes in database schema, APIs, or default behaviors, it should be committed to a branch named for the JIRA ticket. For example, the complete fix for EVALSYS-861 would be committed to a branch at this location (with the ticket cited in the commit message so the commits can be seen from the ticket):

https://source.sakaiproject.org/contrib/evaluation/branches/EVALSYS-861/

That branch would be created with following svn command:

svn copy https://source.sakaiproject.org/contrib/evaluation/trunk https://source.sakaiproject.org/contrib/evaluation/branches/EVALSYS-811/

The JIRA ticket and the changes committed to that branch should give a complete description of the proposed changes to trunk.  A summary of the proposed change and its potential impacts could then be sent to the evalsys list with a request for it to be merged after some period of time.  (One week? 10 days? Two weeks?) If nobody objects, the developer could go ahead and merge the changes from the branch to trunk.  Of course, if trunk has changed in the meantime, the developer is responsible for resolving conflicts before committing). 

This description of the process would become part of the evalsys project's best practices. It does not change the project's standards for documentation, automated testing, etc. Indeed, the suggestion that a proposed change does not meet those standards should be enough to delay it being merged to trunk (or in the case of something that has been committed to trunk, to require that it be removed from trunk until it meets the standards).

I'm guessing the process of merging a change from trunk to an RC would be similar.

Jim
   


On Jun 25, 2010, at 3:49 PM, Richard C. Moyer II wrote:

> My thoughts on how new feature requests should be handled are as follows:
>  
> In addition to an email to the list, a proposed new feature should be added to the Contrib: Evaluation Confluence pages.  I would encourage earlier notification rather than later.  I’m sure there may be cases where two institutions have been working on the same feature without knowing what the other is doing and whoever commits first wins.
>  
> If the feature is to be included in trunk, then the EVALSYS jira is created.
>  
> I see several advantages to this:
>  
> By adding new features to evaluation confluence, the tool becomes self documenting as well as knowing what is included in each tag.
>  
> Also, when a feature is determined not to be included in trunk and remain in the local branch, it can always be revisited should that feature become needed by other schools.
>  
> If this is acceptable, I’ll modify the Contrib: Evaluation Confluence to include these.
>  
> Thoughts,
> Rick Moyer
> _______________________________________________
> 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/65f10d55/attachment.html 


More information about the evaluation mailing list