[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
