[Building Sakai] [Management] Question About Release ManagementProcess for Sakai 2.7

[Stephen Marquard]

Also I would say that release timing considerations should not hold up new development in trunk.

If it's desireable to keep the scope of changes limited for a specific release, that can be managed through appropriate branch & merge strategies, rather than keeping new development out of trunk because of a forthcoming release.

Regards
Stephen

 
>>> Clay Fenlason <clay.fenlason at et.gatech.edu> 8/12/2009 9:56 PM >>> 
Thanks for the willingness to repost your question publicly, Jackie. I
can recommend a practice, but the important thing is for a community
consensus to build around it or an alternative proposal, and so it
needs the peer review of the open list.

I want to say first of all that a single institution "owning" a
particular tool is something that emerged in our history, but is not I
think in many people's view preferred practice, nor is it the
direction the community is moving in future.  I also think your
question is best answered not in terms of a relationship between
schools, but rather in terms of a project lead or maintainer and their
disposition toward contributed patches.  As they say in many open
source communities: patches are welcome :)

Stanford is clearly in a role of project leadership wrt Samigo's
development. It is in a unique position to review patches and merge
them in where they seem advisable. It would also be my hope that this
could be seen as an opportunity for mentoring where the contributed
patches did not seem advisable, for whatever reason.  You might point
out issues or raise concerns, and ask the contributing developers to
see them addressed before Stanford could merge them in.  You might
even ask them to contact you on sakai-dev rather than directly, so
that other members of the community with an interest and a sharp eye
could follow along or offer their own insights.

Then during a stage of release planning we will be looking to the
project leads to supply the sort of information outlined at
http://confluence.sakaiproject.org/x/6ATtAw, as you suggest (but note
that this is a list we're still discussing in release planning
meetings, so it's a WIP). So one check on whether you think the
submitted patches are advisable might involve getting your own answers
to these questions, or also asking that Rice commit its support to
bug-fixing during the QA process.

So that's what I'd propose for Stanford's role, and that next steps
would involve treating the contributions from Rice in this way
(creating JIRAs is a good start), and that the items that do get
merged in be added to the list here:
http://confluence.sakaiproject.org/x/j4LgAw

~Clay

On Wed, Aug 12, 2009 at 2:57 PM, Jacqueline Mai<jamai at stanford.edu> wrote:
> Hi,
> I had originally sent the following questions to to Clay Fenlanson but was
> asked to re-post for wider community discussion.
> I'm a member of the CourseWork team at Stanford and I have a question about
> the process for schools wishing to contribute new features to the upcoming
> Sakai 2.7 release. Rice University has 4 new SAMIgo (Tests & Quizzes)
> features that they would like to be considered for 2.7.  I've asked them to
> file JIRA requests and attach documentation to make clear what it is that
> they are proposing. However I don't know what the next step is and they
> appear to be looking at Stanford to provide answers as to what the next step
> should be.
> What is the role of the school who 'owns' a particular Sakai tool? Should
> Stanford tell fellow Sakai schools who wish to contribute new SAMigo
> features for 2.7 to follow the steps as outlined under:
> http://confluence.sakaiproject.org/display/MGT/New+Feature+Documentation
> What comes after that?
> Does the same process apply if Stanford has local fixes to SAMigo that we
> wish to contribute back to Sakai?
> Thanks for any clarification you can provide,
> Jackie
> Jackie Mai
> User Experience Specialist, CourseWork
> Academic Computing
> Stanford University
> _______________________________________________
> management mailing list
> management at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to management-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>
_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"