...
- All kernel development should happen in branches
- Branches should be created for anyone who asks
- Branch creation should be timely (ideally within one day)
- 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
- Branches should be created for anyone who asks
- 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
Code Change Process Example
- This is an example of the process (as suggested by the rest of this document) that would allow for higher quality code, control over added features, stability in trunk, and code reviews
- Developer(s) publicly mention an idea to the team and community (optional but highly recommended)
- Discussed ideas are unlikely to be rejected so it is prudent to discuss ideas before working on them
- Developer(s) request a code branch from the branch manager to implement/work on their idea (all requests are granted and should be granted in a timely manner)
- Developer(s) with commit access may create their own branches but should not skip the first step (discussion)
- Developer(s) write the code in a branch until they are done
- They may have to merge in other changes to the code they are working on if merges take place while they are developing, it should not be the responsibility of the branch manager to resolve conflicts, instructions should be provided which explain how the merges are done
- Developer(s) announce they want to have their branch merged in (this should be public but it is probably a good idea to copy svn@collab.sakaiproject.org)
- Branch manager asks the kernel team to please look at the branch (before it is merged)
- Kernel team evaluates the branch (code review) and approves or suggests ways to fix the code
- This may include rejection of the merge if it was not discussed publicly before work began and/or does not fit the goals of the community
- The kernel team may help correct the code if they have time and the Developer(s) grant them permission
- This cycle continues until the branch is acceptable to the team
- Kernel team may suggest QA testing is required before merging thus it may go to QA at this point
- Branch manager receives approval from the team (or QA) and merges the branch into trunk
- NOTE: Developer defined - anyone including a member of the team or the main committer for kernel code
- NOTE: JIRA should probably be used to track this process and it might even be worth creating a workflow
Kernel commit access and ownership
...