Wolfgang Denk wd@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20100809132949.43c81f64@hskinnemoen-d830 you wrote:
But it does seem kind of rude to just hand everything off without Cc'ing any of the maintainers in question. Perhaps they would respond more quickly if people actually send e-mail to them?
Rude? send e-mail to them?
I mean rude _not_ to send e-mail to them.
It's not that I'm going to hand off (note that nothing has happened yet) anything from any active custodian.
It's not that I necessarily oppose such a hand-off either.
First, I have poked them a number of times, both on and off list.
I haven't received any such pokes from you in a long time.
Second, they are subscribed to this list, and supposed to read the traffic. Especially if addresses directly in the Subject they should notice that, right?
I used to be subscribed to a whole bunch of lists, but after hitting around 70,000 unread e-mail, I decided to unsubscribe from most of them, including u-boot and LKML.
Of course, this is also the main reason why I wanted to resign as a custodian; I felt I hadn't been able to do a proper job for some time. But this makes it especially odd that I wasn't Cc'd on the discussion about custodianship.
Third, there have been patches posted that clearly fall in their domain, and there is zero response: no comment, no activity in the custodian directory, no pull request, nothing.
If I wasn't Cc'd, that would explain it. Of course, it's always best if maintainers follow all relevant mailing lists, but sometimes it's just not an option, not if you're working on several other projects besides u-boot.
Finally, I have to admit that I have been a bit sceptic right from the beginning to assign custodianship to someone who has no track record as developer in the community. But obviously Atmel would be in the best positition to provide decent support for their chips. At least that was my hope.
Atmel should definitely be in a good position for that, at least in theory. But the reality is that people need to do other things too, and it's difficult to justify spending a lot of time on the boot loader when there are more customer-focused tasks at hand.
And then there's the whole cost/benefit thing. I've been arguing quite enthusiastically for the benefits of getting things upstream earlier, but I've lately started to realize that maybe we're not really getting all that much in return for the work we've been putting in. Especially when we're forced to implement a bloody VM subsystem just to fix a regression someone else introduced.
I am seriously sick with the current situation. We have a number of AT91 and AVR32 related patches sitting there with nobody taking care of them. No life signs of any custodian or anybody else from Atmel.
Again, not Cc'ing the relevant maintainers might be an explanation, though I'm not saying I'm sure it's the _right_ explanation.
But then there are people available who are actively working with these chips, who post fixes and other patches, and who even volunteer to take the burden of maintaining the tree.
Sure, if someone outside Atmel wants to take over the AVR32 tree, I'm all for it. I would really appreciate to be Cc'd on the discussion, however. And I can be available to help whoever takes over the custodianship if there's anything avr32-specific they can't figure out.
Again, I'm not speaking for the AT91 team.
Guess what I'll do? Continue to wait that some vendor wakes up?
Not commenting on this beyond what I said above.
Btw, I'm not ranting at you, Mike. Thanks for letting me know about the discussion, although I would have preferred a bit more context...
For the record, the thread seems to be this one, but I seem to be unable to find the start of it...
http://lists.denx.de/pipermail/u-boot/2010-August/074769.html
Just have a look at the "References:" headers, and look up the first one in gmane - just append the message ID to http://mid.gmane.org/
==> http://mid.gmane.org/4C50E124.2000807@emk-elektronik.de
==> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81812
Thanks, I'll have a look at those. Please forgive me for following the link on your mailserver ;-)
Haavard