*** This is not for discussion, but is only intended to be informative. *** Please do not post replies to this to the list. I hope that this *** is non-confontational. I am unhappy with the situation that is occuring in the linux-arm world, and feel that this has been going on for some time. The events of this week have caused me to do some re-thinking. This is the story of events: As all of you should know, I posted on Sunday the release note for the latest patch to the Linux kernel, patch-2.2.1-rmk2.gz. This contained the usual bits and pieces after a weekends work on the Acorn A5000 architecture. On Monday evening, I tried compiling the code for my Risc PC, a StrongARM based machine. However, I found a problem that would prevent the compilation from succeeding for any ARM6, ARM7 or StrongARM based hardware. Obviously this is a serious problem, however at the time I didn't have the opportunity to generate a new patch. However, I was slightly supprised to find that *no one* had picked it up, but not concerned. Philip released his patches that night, and later when I got his patches to have a look at them, I noticed that he had fixed the problem. I also found that he had modified some code that was partly under my ownership and partly under Alex Holden's ownership. Philip also proposed a change to the FIQ code on Acorn machines into public. I would have thought that it should have been sent to me directly, rather than to the mailing list. These are some excerpts from various emails that I received on Tuesday: -- Philip: > Me: > >I'm getting concerned at the number of apparantly sundry changes that are > >appearing in your patches. My areas of concern are: > > > > - LEDs stuff. > - the LEDs stuff was changed to address some issues that Woody > brought up with performance, modules and the NetWinder. -- Philip: > Me: > >What performance issues are there, and where do modules come into the LED > >driver? > > The old LED driver was somewhat inefficient. I'm not personally convinced > this was a big deal but some people were concerned about it and it seemed > worth experimenting with the alternatives. > > Modules come into it because they may want to play with the LED state. The > NetWinder flash driver is an example. -- Philip: > Me: > >I ask my self from time to time, why do people mention these things to you > >and not to me? > > One can only speculate. -- Philip: > Me > >Hang on. I write the driver and people contact you? > > Apparently so. -- On Wednesday, I find that Philip has released yet another patch, in response to bug reports for his code. Finally, on Friday, the following ensued: Philip: > Me: > >Would you mind discussing/forwarding your changes and bug fixes to the > >relevent maintainers at some point, rather than just overruling them > >snatching the maintainence from them? I find this extremely discourtious. > > Once I'm happy that the changes are correct, yes. The only way for me to find > this out is to ask other people to try them. As you are so fond of pointing > out, your "official" kernel is supposed to be stable so it probably isn't > the best place to test experimental changes. In fact if you consult the > guidelines in the MAINTAINERS file, they explicitly suggest making patches > available for testing before bothering the maintainer. Later: Philip: > Me: > >I'm sorry - I can't find this in the Maintainers file. Could you please > >give me a line number? > > About lines 7 to 40. Firstly one is exhorted to "release a few alpha test > versions to the net", then to make the patch "generally available for > testing", and only after that to send it to the maintainer in a form ready for > merging. Now, looking at the file actually says: 1. Always _test_ your changes, however small, on at least 4 or 5 people, preferably many more. 2. ... Announce them onto the kernel channel and await results. ... 5. Make a patch available to the relevant maintainer in the list. My understanding of point (2) is to let the maintainer know that there are changes in existance for his bit of code, so that the maintainer knows what is going on. Maybe this is a misunderstanding? Also, linux-arm (and apparantly a lot of other lists) got spammed. I decided, since I did not want the mailing list to be come swampped with spam, to change the rules to protect those subscribed. This does not mean that I don't get the spam - I still receive it from Majordomo. I got a few welcoming public responses from it, and what I consider a damn right overreacted public response from Philip, which IMHO should have been in private mail. To date, there have been 70 downloads of the latest kernel patch this week since I uploaded it on February 7th, zero bug reports about the patch, and two patches, one to fix a small bug in tty_io.c and another to add the Philips LED stuff. Thanks to those who sent them to me. However, still no one has reported the bug. >From my point of view, producing all these patches once or twice a week and getting very little feedback on them, I'm wondering what it is that I am actually doing? Am I just someone who takes patches from Philip, puts them in my tree, uploads them, and sends stuff onto Linus? Or do I actually maintain the kernel? I'm not sure which it is at the moment. I thank those Acorn users out there who have given me feedback on various driver problems - that is very much appreciated. I can draw the only conclusion that no one out there is really interested in my work. On Saturday, I was questioning whether it was really worth continuing. And on that note, I shall leave you to draw your own conclusions. Again, please do not post replies to the list - I don't want another flame war. Thanks. _____ |_____| ------------------------------------------------- ---+---+- | | Russell King [EMAIL PROTECTED] --- --- | | | | http://www.arm.linux.org.uk/~rmk/armlinux.html / / | | +-+-+ --- -+- / | THE developer of ARM Linux |+| /|\ / | | | --- | +-+-+ ------------------------------------------------- /\\\ | unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
