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

Rod Whitby rod at whitby.id.au
Sun Oct 19 23:45:39 CEST 2008


[The below comments make no opinion on how anyone has acted in the past,
I want to constructively discuss how things are done in the future,
without anyone reacting based on what was or was not done in the past.]

Sean McNeil wrote:
> 1) You didn't explain anything. There is no ABI that specifies 
> brightness control shall be 0-63. This is why max_brightness was 
> invented. In fact, the only thing I've seen in the wiki site is
> 
>     http://wiki.openmoko.org/wiki/Neo1973:GTA01:Kernel
> 
> which states there is a sysfs entry to get max_brightness. I'd be 
> interested in knowing where it says brightness shall be 0-63.

Any change to existing (in the source code) kernel functionality is
effectively an ABI change.  Whether it was documented outside of the
source code or not determines whether it's a feature change or a bug
fix.  Either way, it needs to be identified as a kernel change, and
discussed before implementation.  In rare circumstances, bug fixes are
sometimes delayed before entering the mainline Linux kernel due to a
massive downstream impact that needs to be dealt with in userspace.

[Note that I make no opinion on whether or not this has been done in the
past by Openmoko, this email is all about looking to the future.]

> 3) ... Your stance is 
> unacceptable as it limits both growth and the ability to correct what 
> might have been poor decisions. Think where Linux would be if they never 
> allowed for improvements.

I think what Mike is looking for here is for the Openmoko kernel
developers to follow a process like the upstream Linux kernel, where
proposed patches are reviewed on a mailing list and committed when there
are no more objections (or in the case of irresolvable differences,
someone in authority makes an overriding decision).

[Note that I make no opinion on whether or not this has been done in the
past, this email is all about looking to the future.]

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.

> 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.

-- Rod



More information about the openmoko-kernel mailing list