[U-Boot] ATMEL Custodians == /dev/null ??

Haavard Skinnemoen
2010-08-09T11:13:18Z

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