The Sakai K1 Kernel will be in our svn pretty soon! This is a great milestone for Sakai – it moves us toward a much more manageable source tree given the kinds of resources we have available in the community.
For me this is a welcome move back toward a “do-ocracy” – at least for this very technical bit of the code. Do-ocracy and dem-ocracy have their places – and in particular for Sakai – with a large,complex user interface that end-users touch daily – it is important to not be a pure do-ocracy. But for the deepest bits of our code – the kernel – pretty much Apache Rules need to apply here with no grey area.
Ian recently posted the following vote to the dev list – lots of folks want comfortable grey areas like we have had in the past out of necessity. As folk might expect from me – I prefer grey only when there is a reason for grey.
Here is Ian’s question:
Going forwards I would like to adopt a more Apache like policy to kernel modifications in K1… namely
1. non kernel committers have to submit patches to Jira for review
2. commits < 10 lines that dont change functionality can be committed by kernel comitters
3. all commits > 10 line that change functionality have to be submitted as patches to Jira for review, review is light weight and commit is relatively fast afterwards.
If some one wants a branch, thats fine, but the above practice still stands, they need to create a patch and submit that patch to jira.
Please vote.
Ian
Here is my answer – pretty much grey-less as you might expect :)