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 probability of being ignored - but also historically we have very shallow coverage of commtted commiters with time to spare on much of the source tree. Many chunks of our code base do not really even have a "lead committer" - there are folks who work on stuff when their is something like a bug, etc.
This is not bad - it is just the nature of a million lines of code and <10 people who work >10 hours per week on the "problems of the commons". Lots of people do lots of work in lots of places - here I am only speaking of those people who work on the problems that are not their local priority. We are spread thin - too thin.
For me the point of the kernel is to change this pattern - at least in the kernel itself. Hopefully we will have 2-3 lead/solid kernel committers who can be counted on to "tend" the kernel giving, say 30 hours per week total available maintenance time on the kernel. It should not take 30 hours *every week* - but we need folks with long -term spare resources available on short notice to work on the kernel when things arise.
We will have a Kernel classification in JIRA - so there is one "input queue" for this kind of issue / problem so we can have folks like Peter actively work with the lead committers on the kernel - to work through the queue.
For me a pre-requisite for being a kernel committer is a willingness to be responsible for reviewing and applying patches, etc. Folks should not ask for Kernel commit just because it is convenient for them or because they have been around a long time or because they have strong opinions about the kernel. Commit should mean commitment to doing the work needed - not just the work that is interesting or locally important.
By the way - if I apply the above criteria to myself - I would not give myself kernel commit - at least not from September through April when my time is 100% committed to being a professor.
I will be honest here - if someone is on the kernel commit team and they do not show the necessary "commitment", they should be removed as committers - they become committer emeritus - with great honor but not write access to the source tree. Per Apache the emeritus thing happens after a while - but it is something the active commit team manages like anything else. And folks can come off emeritus really easy if the active commit team so deems.
By being really Apache-like on this will make it so that whoever the active committers are, their jobs are easier. They can meet, talk, use IRC, (of course do things in the open for transparency) whatever and get things done efficiently. If there are only two people - going to do the work - then let those two get to it and don't make them drag a bunch of people who are "honorary committers" along.
Yes, this is a bit elitist - but we need some real commitment to reach the quality of product we need to get to - In particular part of K1 is to learn how to do K2 - K2 is when we will have a real kernel - but then this all should be second nature for us.
/Chuck
Posted by csev at July 29, 2008 01:30 PM