Openmoko kernel change process (Was: [UPSTREAM] Move backlight handling out of pcf50633 driver)

Rod Whitby rod at whitby.id.au
Mon Oct 20 00:49:37 CEST 2008


Sean McNeil wrote:
> Rod Whitby wrote:
>> [snip...]
>> If we can all agree that changes to existing Openmoko kernel
>> functionality must be RFC'd on the openmoko kernel mailing list, in a
>> way that invites comment and review, then I don't think there's any
>> argument between anyone here.
>>
>> Just like downstream distos of the mainline Linux kernel need to
>> subscribe to the kernel mailing list (or some summarising service), so
>> should Openmoko distro developers subscribe to the openmoko kernel list.
> 
> In practice, this is an excellent idea. I'm afraid, however, that there 
> might be times when something gets discussed incidentally and slips 
> through the cracks. Perhaps some sympathetic soul might rebroadcast such 
> discussions to email tagged with [RFC] when they notice such an occurrence?

If we all agree on the process, I doubt that anyone would have a problem
with a genuine failure to remember to follow the process (especially if
it's accompanied by a "Mea Culpa" when it's identified politely).  At
least that's how I'd like to treat these things ...

A key part of an effective community relationship is making sure that
all such "incidental" discussions in Openmoko are rebroadcasted.

>>> 4) OM can do anything they want with the kernel. It is their project. 
>>> They have control over it. If you don't like it then put up your own git 
>>> tree.
>>>     
>> I think Andy has stated a couple of times that he is keen for the
>> Openmoko kernel to be useable as-is by all the downstream distros if at
>> all possible, so it seems that Openmoko themselves would prefer to
>> discuss and compromise before downstream distros resort to forking the
>> Openmoko kernel tree.
>>   
> 
> Yes, both Andy and OM as a whole are very keen to work with the 
> community. My not-so-subtle point is that OM has veto rights on any action.

There is absolutely no question that OM have absolute power over the git
repo at git.openmoko.org - and whether or not people use that repo and
kernel will be directly related to how "friendly" the maintainers of
that repo are the to community.

We have already seen the Trolltech/Nokia Qtopia distribution (the
distribution that Openmoko itself recommends for new non-developer users
of the Freerunner) decide to *not* point to the official Openmoko kernel
with their latest release, but instead point to one with mwester's
patches in it.  It'd be great to see everyone work towards making that
type of fragmentation disappear ...

Of course, this will all go away once the kernel is mainlined, after
which not even Openmoko will be the ultimate authority on Freerunner
support in the Linux kernel and everyone will be forced to use the
conventional Linux kernel change processes.

-- Rod




More information about the openmoko-kernel mailing list