Page Comparison

Information

This documents the best practices for udpates to the kernel (core of framework). Code is currently managed using SVN so many of the practices will revolve around description of that. This will also document some of the higher level development practices that are agreed upon by the technical community.
These practices are important because user needs define the designs that are created by the UX community for Sakai. The UX community defines the tools that Sakai should include. Tool creation by developers brings needed functionality to the overall system. Updates to the framework are important/required to allow improvements to be made which support the tool developers.

...

• All kernel development should happen in branches
  • Branches should be created for anyone who asks
    • Branch creation should be timely (ideally within one day)
    • Team branches should be encouraged to reduce conflicts and increase collaborative overview
  • This does not have to apply to simple fixes (like pom/classpath fixes), that would just cause clutter and slow down everyone needlessly
    • The kernel team should be allowed to decide on a case by case basis what fixes are too simple to require a branch
• Large scale changes which require access to many projects in Sakai should be managed with a branch as well. The large scale changes should be merged and tested outside of the main svn. Once the changes are shown to be safe, they should be merged in with a single commit action by a branch manager
  • An example of this would be a change to an interface which will no longer be supported (i.e. deprecated). This change would require access to many projects to fix the calls to the interface so they are using the supported method
• Branch merges should be approved by the owners of that project and should include the kernel team
  • Approval should require some percentage of members (70%?) to agree
  • Dissention and reasons should be noted in the svn merge commit message
  • Owners are responsible for responding to a merge request in a resonable amount of time (1 week?)
    • If the owner does not respond within the reasonable amount of time then the merge decision is made by the framework team
• All branches which are being merged should be mentioned to the community before they are merged (via the dev list probably)
  • This is not a community vote but is more of a way to let people know what is happening and keep a public record
  • Community member objections should be considered before the kernel changes are committed but they do not have to be addressed

...