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 :)

+1
I would say that it depends on who the kernel commit group is and how much change is needed in kernel and how responsive the kernel commit group is to patches.
Historically, patches have a pretty high