[U-Boot] ATMEL Custodians == /dev/null ??
Hello all,
it seems that Atmel is not willing to provide manpower for custodians.
I have spend considerable extra time to split my work towards the u-boot port of our new boards into separate patches for the AT91 SoCs.
I have sent them to the list some weeks ago only to see that exactly NOTHING happens to move them towards mainstream.
Unless something happens soon in that regard I will in the future refrain from investing extra hours to create patches for Atmel hardware.
With Best Regards, Reinhard
On Wednesday, July 28, 2010 22:02:12 Reinhard Meyer wrote:
it seems that Atmel is not willing to provide manpower for custodians.
i think the linux/open source team there saw some shrinkage, and/or the higher ups thought a change in direction away from working with the community/upstream was the way to go (and to simply maintain an internal fork perpetually). i'm of course just speculating based on their drop off in submissions in general across open source projects and have no direct knowledge of anything.
from the developers pov, they probably dont have much choice. when the economy shrinks and your boss says that is no longer your job, then it's a hard choice. do the right thing or continue to eat ;).
I have spend considerable extra time to split my work towards the u-boot port of our new boards into separate patches for the AT91 SoCs.
I have sent them to the list some weeks ago only to see that exactly NOTHING happens to move them towards mainstream.
Unless something happens soon in that regard I will in the future refrain from investing extra hours to create patches for Atmel hardware.
if the maintainers are effectively dead, then i'd suggest someone (i.e. Wolfgang) hand the custodian role over to someone willing to do the work. employment by the company who owns the processor in question only goes so far. vastly more important are the people doing the actual work and in this case, it seems like that person might be you vs anyone with @atmel.com in their e- mail address. -mike
Dear Mike Frysinger,
In message 201007290018.40886.vapier@gentoo.org you wrote:
if the maintainers are effectively dead, then i'd suggest someone (i.e. Wolfgang) hand the custodian role over to someone willing to do the work.
Full ACK.
employment by the company who owns the processor in question only goes so far. vastly more important are the people doing the actual work and in this case, it seems like that person might be you vs anyone with @atmel.com in their e- mail address.
Full ACK again.
Reinhard, do you volunteer? For AVR32? Or also for AT91?
Best regards,
Wolfgang Denk
Wolfgang Denk schrieb:
Dear Mike Frysinger,
In message 201007290018.40886.vapier@gentoo.org you wrote:
if the maintainers are effectively dead, then i'd suggest someone (i.e. Wolfgang) hand the custodian role over to someone willing to do the work.
Full ACK.
employment by the company who owns the processor in question only goes so far. vastly more important are the people doing the actual work and in this case, it seems like that person might be you vs anyone with @atmel.com in their e- mail address.
Full ACK again.
Reinhard, do you volunteer? For AVR32? Or also for AT91?
Hello Wolfgang, hello Mike,
that would be a possibility. However I was more thinking in the way, that since there are practically no other contributors right now that Wolfgang would take my patches directly to mainstream unless someone protests them in due time.
Apparently no one is testing them on other AT91 boards (are there any except for Atmel's EKs?); no one critisizes any coding issues :). Naturally those patches work on the AT91SAM9XE-EK (which I use as a substitute as long as our own hardware is not available - mid-August now). After that, I can still test on both.
Then I consider AVR32 a dead architecture for LinuX based systems, since all LinuX-able Variants (AP700x) are "not recommended for new design".
And I am still fighting with GIT in terms of producing Patches and reworking Patches, if, for example I later find an even "nicer" solution or continued testing shows up problems. Of course I read the man pages, read several articles about git, but they usually fail to explain the idea and inner working of a command. Sometimes commands have (for me) unexpected effects which are hard to undo.
As a custodian I sure would need more help and advice on how to handle certain situations. I would (for start) have to rely on advice from Wolfgang or someone else.
And as a custodian for AT91 I would mostly collect my own patches, <sarcasm> review them, apply them after 2 weeks of nobody commenting on them </sarcasm> and once in a while ask Wolfgang to pull them to mainstream?
Of course, hopefully more people would volunteer to work on that architecture there are still lots of places where coding style can be improved, not to mention the vast number of AT91 drivers using #define registers access instead of structures. Also when I tried to cleanup the multi-wrapped defines for controller adresses I noticed that this issue spans the whole AT91 files.
If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.
With Best Regards, Reinhard
PS: from messages in Atmel forums I notice that many users use some branched-off old versions of u-boot and (almost naturally) have issues with that.
Dear Reinhard Meyer,
Am 05.08.2010 11:14, schrieb Reinhard Meyer:
Wolfgang Denk schrieb:
Dear Mike Frysinger,
[snip]
Reinhard, do you volunteer? For AVR32? Or also for AT91?
[snip]
Then I consider AVR32 a dead architecture for LinuX based systems, since all LinuX-able Variants (AP700x) are "not recommended for new design".
Yes, AVR32 seems to be a dead architecture but I do think mainline U-Boot support for it has its right to exist.
We have two devices using the AP7000. We do think about a major U-Boot update for at least one of these devices. With latest patches from Haavard the avr32 architecture is usable again and we may switch from 2008.10 to 2010.06.
On the other hand there are a lot of evaluation kits still available. I think they are used at least by hobbyists. The main statement is to not loose off avr32 support in near future no matter what way atmel decides for his products. But therefore it is necessary to get avr32 working in next release. I know 2010.09 is closed but it would be great to get the "simple paging" patch into 2010.09. Nevertheless 2010.12 should be doable for the paging stuff and maybe atmel_usart too.
[snip]
And as a custodian for AT91 I would mostly collect my own patches, <sarcasm> review them, apply them after 2 weeks of nobody commenting on them </sarcasm> and once in a while ask Wolfgang to pull them to mainstream?
I have an at91rm9200 based eval kit at home and plan to do some effort to get this board mainline (but since january I work on arm-linux toolchain for my mac ...). Therefore I can do testing for some at91 drivers in near future.
We plan to use some at91sam based cpu's for further products. Therefore I could do testing and/or reviews at work too (maybe end of this year).
Of course, hopefully more people would volunteer to work on that architecture there are still lots of places where coding style can be improved, not to mention the vast number of AT91 drivers using #define registers access instead of structures. Also when I tried to cleanup the multi-wrapped defines for controller adresses I noticed that this issue spans the whole AT91 files.
If we do switch to 2010.06 I plan to do some work on atmel_usart which I think is a shared driver between avr32 and at91.
regards
Andreas Bießmann
Andreas Bießmann schrieb:
Dear Reinhard Meyer,
Yes, AVR32 seems to be a dead architecture but I do think mainline U-Boot support for it has its right to exist.
I was not meaning to remove support, just pointing out that a custodian might not be necessary (anymore). Since it is unlikely the many patches pop up... Patches for common drivers for AVR32 and AT91 will be mainlined the AT91 way, and maybe testing them always on AVR32 should not be required.
We have two devices using the AP7000. We do think about a major U-Boot update for at least one of these devices. With latest patches from Haavard the avr32 architecture is usable again and we may switch from 2008.10 to 2010.06.
I had the ATNGW100 working fine with 2010.06, the patches from June 4th onwards still linger around.
I have an at91rm9200 based eval kit at home and plan to do some effort to get this board mainline (but since january I work on arm-linux toolchain for my mac ...). Therefore I can do testing for some at91 drivers in near future.
I think the RM9200 is quite different from the bunch of the SAM9 ones.
We plan to use some at91sam based cpu's for further products. Therefore I could do testing and/or reviews at work too (maybe end of this year).
That would help, of course.
If we do switch to 2010.06 I plan to do some work on atmel_usart which I think is a shared driver between avr32 and at91.
Yes, and because of that its needs testing on both architectures. What I don't like in the current AVR32 and AT91 drivers is the several times and in different .h files wrapping of the peripherals' hardware address into new defines.
Reinhard
Hi Reinhard,
Le 05/08/2010 11:14, Reinhard Meyer a écrit :
Wolfgang Denk schrieb:
Reinhard, do you volunteer? For AVR32? Or also for AT91?
that would be a possibility. However I was more thinking in the way, that since there are practically no other contributors right now that Wolfgang would take my patches directly to mainstream unless someone protests them in due time.
Apparently no one is testing them on other AT91 boards (are there any except for Atmel's EKs?); no one critisizes any coding issues :). Naturally those patches work on the AT91SAM9XE-EK (which I use as a substitute as long as our own hardware is not available - mid-August now). After that, I can still test on both.
I sent patches to update our cpuat91 board 3 times, so you are not the only one trying to get patches merged for AT9 :-).
If needed, I also can help you for AT91 (I have board using : at91rm9200, at91sam9260 and at91sam9g20).
Eric
On Thursday, August 05, 2010 05:14:09 Reinhard Meyer wrote:
And I am still fighting with GIT in terms of producing Patches and reworking Patches, if, for example I later find an even "nicer" solution or continued testing shows up problems. Of course I read the man pages, read several articles about git, but they usually fail to explain the idea and inner working of a command. Sometimes commands have (for me) unexpected effects which are hard to undo.
As a custodian I sure would need more help and advice on how to handle certain situations. I would (for start) have to rely on advice from Wolfgang or someone else.
rebasing in my own branch tends to be how i manage my own changes. this allows you to merge commits into one, change the order of things, edit changes in he middle of a tree, or drop commits. but this is obviously for your own branches only and not for public branches other people are working off of.
i can probably answer most of your git related questions ... not sure if Wolfgang prefers them to be answered off list ...
If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.
go for it -mike
Dear Mike Frysinger,
In message 201008051216.14165.vapier@gentoo.org you wrote:
i can probably answer most of your git related questions ... not sure if Wolfgang prefers them to be answered off list ...
I recommend to use comon sense - most stuff can go over the list, so everybody can benefit from it. If you feel it's a generic topic, you are also welcome to add thjis to the wiki, and post a link here. If you have lenghty examples that are really uninteresting for anybody else you can run it off list.
Best regards,
Wolfgang Denk
Mike Frysinger wrote:
If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.
go for it -mike
Hi Wolfgang, Mike,
considering that both AVR32 and AT91 share most of the peripheral hardware building blocks, and therefore share the drivers, it seems to make sense to have an atmel custodian tree instead of avr32 and at91. Each change to a shared driver must (at least with MAKEALL) be checked for both architectures and adding it to both trees would make life unnecessary complicated...
Best Regards, Reinhard
On Friday, August 06, 2010 20:01:45 Reinhard Meyer wrote:
Mike Frysinger wrote:
If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.
go for it
considering that both AVR32 and AT91 share most of the peripheral hardware building blocks, and therefore share the drivers, it seems to make sense to have an atmel custodian tree instead of avr32 and at91. Each change to a shared driver must (at least with MAKEALL) be checked for both architectures and adding it to both trees would make life unnecessary complicated...
yes, but the cores are going to be radically different. so i imagine you'd be fine with the peripheral drivers, but not the avr32 core. it's your time though of course. -mike
Mike Frysinger wrote:
On Friday, August 06, 2010 20:01:45 Reinhard Meyer wrote:
Mike Frysinger wrote:
If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.
go for it
considering that both AVR32 and AT91 share most of the peripheral hardware building blocks, and therefore share the drivers, it seems to make sense to have an atmel custodian tree instead of avr32 and at91. Each change to a shared driver must (at least with MAKEALL) be checked for both architectures and adding it to both trees would make life unnecessary complicated...
yes, but the cores are going to be radically different. so i imagine you'd be fine with the peripheral drivers, but not the avr32 core. it's your time though of course. -mike
Dear Mike,
So what areas do we have? 1. AVR32 core - avr32 custodian 2. ARMxxx core - ARM custodian 3. AT91 core specifics and drivers - at91 custodian 4. Atmel peripheral hardware drivers - avr32 AND at91 custodians
Area 1. there will be not much new development for AVR32-AP700x, since Atmel declared the AP700x NRFD. None of the UC3 Variants will be likely to use u-boot. Only one of them allows significant external ROM and RAM. Picking up the few commits for AVR32 core, should not be much work.
Area 3. I see nothing specific right now for the ARM core itself. In arch/.../at91 are some "drivers" that manage at91 specific stuff like peripheral inits, clock, (now my at91sam9xe-specific eflash driver), led(!), reset, timer. Nothing really ARM core related. It might even be discussed whether some of the files even belong in this directory...
Area 4. any commit in this area would need both custodians' work before it can go mainline. Wolfgang pulling from both trees might sometimes give him extra work because of conflicts. Or we postulate that common driver work goes through the at91 custodian only.
And yes, taking care of AVR32 as well looks like extra work at first, but it seems to me that the extra work involved for Area 4 is not less if there are two trees.
Reinhard
On Friday, August 06, 2010 20:58:14 Reinhard Meyer wrote:
- AVR32 core - avr32 custodian
- ARMxxx core - ARM custodian
- AT91 core specifics and drivers - at91 custodian
- Atmel peripheral hardware drivers - avr32 AND at91 custodians
Area 1. there will be not much new development for AVR32-AP700x, since Atmel declared the AP700x NRFD. None of the UC3 Variants will be likely to use u-boot. Only one of them allows significant external ROM and RAM. Picking up the few commits for AVR32 core, should not be much work.
picking up random commits from a mailing list isnt exactly the same as being familiar with a core architecture and knowing whether the changes in question are even correct. any patch monkey can save an e-mail and run `git am` on it. a real custodian should understand what's going on.
Area 4. any commit in this area would need both custodians' work before it can go mainline. Wolfgang pulling from both trees might sometimes give him extra work because of conflicts.
it isnt that hard to talk to each other on a public mailing list. as for conflicts, Wolfgang is good about telling someone they need to redo their changes because of conflicts. so if he pulled at91 and then pulled avr32 and hit a conflict, the avr32 custodian gets to resolve it.
but again, i have no interest in either arch, so what people do with them doesnt really matter to me. i'm just providing general advice. -mike
Dear Mike Frysinger,
In message 201008062339.51320.vapier@gentoo.org you wrote:
it isnt that hard to talk to each other on a public mailing list. as for conflicts, Wolfgang is good about telling someone they need to redo their changes because of conflicts. so if he pulled at91 and then pulled avr32 and hit a conflict, the avr32 custodian gets to resolve it.
You were right, _if_ we had active at91 and avr32 custodians. Unfortunaltey, we have none for avr32 and a non-responsive one for at91. So if we find a volunteer who handles it both in one tree that can be only an improvement. And if it should turn out later that two separate repos would be better, well, then we split them again.
Best regards,
Wolfgang Denk
Dear Reinhard Meyer,
In message 4C5CA269.8010401@emk-elektronik.de you wrote:
considering that both AVR32 and AT91 share most of the peripheral hardware building blocks, and therefore share the drivers, it seems to make sense to have an atmel custodian tree instead of avr32 and at91. Each change to a shared driver must (at least with MAKEALL) be checked for both architectures and adding it to both trees would make life unnecessary complicated...
I'm fine with that.
You take this, then? :-)
Best regards,
Wolfgang Denk
Dear Reinhard Meyer,
In message 4C5A80E1.9050504@emk-elektronik.de you wrote:
Reinhard, do you volunteer? For AVR32? Or also for AT91?
that would be a possibility. However I was more thinking in the way, that since there are practically no other contributors right now that Wolfgang would take my patches directly to mainstream unless someone protests them in due time.
I have no chance to test anything, so rather leave responsibility with someone who actually can do at least some testing, and who has an understanding of the architecture.
As a custodian I sure would need more help and advice on how to handle certain situations. I would (for start) have to rely on advice from Wolfgang or someone else.
No problem.
And as a custodian for AT91 I would mostly collect my own patches, <sarcasm> review them, apply them after 2 weeks of nobody commenting on them </sarcasm> and once in a while ask Wolfgang to pull them to mainstream?
Right. And please don't forget the testing :-)
If, after considering my comments above, you still think you really need a custodian for AT91, I am game for it.
If you are willing to take that responsibility, please send me (off list) your SSH public key so I can give you write permission to the custodian repository. And thanks in advance.
PS: from messages in Atmel forums I notice that many users use some branched-off old versions of u-boot and (almost naturally) have issues with that.
I'd be happy to have working support for them in mainline.
Best regards,
Wolfgang Denk
Wolfgang Denk wrote: Dear Wolfgang,
I have no chance to test anything, so rather leave responsibility with someone who actually can do at least some testing, and who has an understanding of the architecture.
Sure there are different levels of testing possible.
1. If the patch is simple enough reasoning might be sufficient. 2. If its a new driver, it has to be proven to work (reliably) on at least one board (other boards cannot break since they won't use it), and it should be reasonably obvious that the new code is not board specific, or (if REALLY unavoidable) that board specific parts are at least obvious by using #if defined(CONFIG_<board>) 3. If its a rework, it should be shown working on at least one board in each architecture (if it is a shared source) 4. If nobody but the submitter is able/willing to test the patch, what do we do then? n. of course all must survive the MAKEALL test.
As a custodian I sure would need more help and advice on how to handle certain situations. I would (for start) have to rely on advice from Wolfgang or someone else.
No problem.
I'll collect Q&A in a text file, maybe one can make a FAQ out of it later.
And as a custodian for AT91 I would mostly collect my own patches, <sarcasm> review them, apply them after 2 weeks of nobody commenting on them </sarcasm> and once in a while ask Wolfgang to pull them to mainstream?
Right. And please don't forget the testing :-)
That's implicit on my own patches. They are either of type 2. or type 3. as above ;)
If you are willing to take that responsibility, please send me (off list) your SSH public key so I can give you write permission to the custodian repository. And thanks in advance.
Yes. And the first Qs: Q: how do I get a key pair, and where do I find it? A: I'll figure that out tomorrow, I think my system has generated one during install... Q: it should be save when everyone knows the public part, why not on the list? A: its not necessary...
PS: from messages in Atmel forums I notice that many users use some branched-off old versions of u-boot and (almost naturally) have issues with that.
I'd be happy to have working support for them in mainline.
It is actually working in the mainline, I compiled ATNGW100 and AT91SAM9XE-EK out of mainline and both worked out of the box (apart from that AVR32 CFI issue).
I should put our new board's support files as patches out soon, even if they are not final, to give others a glimpse how to add the new features to their boards. That raises the next few Qs: Q: who resolves conflicts in very common files like MAINTAINERS, boards.cfg etc, they are bound to have merge conflicts when you pull? Q: boards.cfg does not appear to be completely sorted, its not even sorted by ARCH. And using the vi command does sort the header of that file, too....
Best regards,
Reinhard
On Saturday, August 07, 2010 19:19:19 Reinhard Meyer wrote:
Wolfgang Denk wrote:
If you are willing to take that responsibility, please send me (off list) your SSH public key so I can give you write permission to the custodian repository. And thanks in advance.
Yes. And the first Qs: Q: how do I get a key pair, and where do I find it?
use `ssh-keygen` to create one in ~/.ssh/. send Wolfgang the .pub file. configure your ~/.ssh/config to use that key when connecting to the denx servers.
A: I'll figure that out tomorrow, I think my system has generated one during install...
it probably only generated a host key pair for sshd and you dont want to go mixing those
Q: it should be save when everyone knows the public part, why not on the list? A: its not necessary...
right, no one cares :P -mike
Dear Reinhard Meyer,
In message 4C5DE9F7.4070701@emk-elektronik.de you wrote:
- If the patch is simple enough reasoning might be sufficient.
Might. But things might go wrong. Turn around - Murphy is standing right behind you.
- If its a new driver, it has to be proven to work (reliably) on at
least one board (other boards cannot break since they won't use it), and it should be
Adding a bad driver can break ALL boards. You just have to mess up the Makefile.
reasonably obvious that the new code is not board specific, or (if REALLY unavoidable) that board specific parts are at least obvious by using #if defined(CONFIG_<board>)
CONFIG_<board> should always be avoided and replaced by an appropriate CONFIG_<feature>.
- If its a rework, it should be shown working on at least one board in
each architecture (if it is a shared source)
That's what happens often, and turns out to be unreliable often, too.
- If nobody but the submitter is able/willing to test the patch, what
do we do then?
If nobody complains, it goes in.
Q: who resolves conflicts in very common files like MAINTAINERS, boards.cfg etc, they are bound to have merge conflicts when you pull?
If that's the only problems, and if your code is based on reasonably current versions, I will fix these.
Q: boards.cfg does not appear to be completely sorted, its not even sorted by ARCH.
The file is mostly sorted, as described in the comment.
And using the vi command does sort the header of that file, too....
Not if you place the cursor (i. e. the '.') on the first non-comment line.
Best regards,
Wolfgang Denk
On Tue, 03 Aug 2010 23:28:58 +0200, Wolfgang Denk wd@denx.de wrote:
Full ACK again.
Reinhard, do you volunteer? For AVR32? Or also for AT91?
I would love to work with Reinhard and others to test and integrate stuff for AVR32 NGW100 board. My target is to get current 2010.06 with patches really working on this board. Currently, I see two problems:
1) One cannot save the environment due to wrong flash address stuff (recent patch from Haavard Skinnemoen should fix that) 2) With a completely erased flash, at least 2008.10 and 2010.06 detect the flash to be 3.2Gig or 4Gig and crash. 1.3.3 is fine.
When the U-Boot environment settings block was not erased, they boot fine but cannot erase nor write flash.
I'm going to test the solution for 1) and I'm still investigating 2).
Then, I'll push that version with the required patches to OpenWRT to replace the ancient 1.3.3 with LZMA patches that is used now. After that, I'll wait until (2010.06&patches) lands in a new release and push that to OpenWRT as well.
explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32 have been handled over to someone else without their explicit ACK ... -mike
Mike Frysinger vapier@gentoo.org wrote:
explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32 have been handled over to someone else without their explicit ACK ...
So...what exactly are you Cc'ing us on?
Haavard
On Sun, Aug 8, 2010 at 9:27 PM, Haavard Skinnemoen wrote:
Mike Frysinger vapier@gentoo.org wrote:
explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32 have been handled over to someone else without their explicit ACK ...
So...what exactly are you Cc'ing us on?
read the thread -mike
Mike Frysinger vapier@gentoo.org wrote:
On Sun, Aug 8, 2010 at 9:27 PM, Haavard Skinnemoen wrote:
Mike Frysinger vapier@gentoo.org wrote:
explicitly cc-ing the atmel guys just so there's no surprise when at91/avr32 have been handled over to someone else without their explicit ACK ...
So...what exactly are you Cc'ing us on?
read the thread
That sort of brings us back to my original question, doesn't it?
<reads the archives>
Ok, so there are complaints about the non-responsiveness of some of Atmel's custodians and a wish for someone to take over. Fine by me, I guess, since I've already indicated I'm probably not the right person for the job anymore. I can't speak for the AT91 team, however.
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?
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
Haavard
On Mon, Aug 9, 2010 at 2:29 AM, Haavard Skinnemoen 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?
i think the supposition might have been that active maintainers watch the lists. or it was an accidental oversight from the start.
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...
i'm not terribly inclined to summarize a topic i'm not vested in when i'd too have to review the archives in order to do so. nothing personal of course.
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
pipermail blows at threading across months. you'd think they'd fix something so extremely basic ...
at any rate, gmane shows it nicely: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81812 -mike
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?
It's not that I'm going to hand off (note that nothing has happened yet) anything from any active custodian.
First, I have poked them a number of times, both on and off list.
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?
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.
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.
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.
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.
Guess what I'll do? Continue to wait that some vendor wakes up?
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
Best regards,
Wolfgang Denk
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
Dear Haavard Skinnemoen,
In message 20100809181318.5ec2ab8c@hskinnemoen-d830 you wrote:
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.
I'm not talking about you here. You have clearly indicated that you resign as custodian, which I have accepted. So why should I poke you?
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.
A custodian who is not subscried on the mailing list? How is this supposed to work? I have to admit that I never expected somebody would come up with such a concept.
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
It has never been a requirement to Cc: the custodian. It is up to the custodian to pick up the work that falls into hiw bailiwick, including for example global changes that happen to affect his architecture / subsystem. Of course this requires that you are subscribed. And that you actually *read* the list, at leats to the extend that you recognize certain buzzwords in the Subject: lines, like the name of the architure you feel responsible for.
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.
Your idea of working as a maintainer is very much different from mine, and from the actual requirements for the job.
Thanks, I'll have a look at those. Please forgive me for following the link on your mailserver ;-)
mailman has certain restrictions and limitations, but I'm not an expert in that field. If you know better solutions, then suggestions are welcome.
Best regards,
Wolfgang Denk
Wolfgang Denk wd@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20100809181318.5ec2ab8c@hskinnemoen-d830 you wrote:
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.
I'm not talking about you here. You have clearly indicated that you resign as custodian, which I have accepted. So why should I poke you?
I didn't resign _that_ long ago.
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.
A custodian who is not subscried on the mailing list? How is this supposed to work? I have to admit that I never expected somebody would come up with such a concept.
It actually works on Linux, where people know that they need to Cc the maintainer to get his attention. So you can actually maintain a dozen drivers across half a dozen subsystems without getting completely bogged down with e-mail. If you just drop a patch into the LKML firehose, it will most likely be ignored unless akpm picks it up and pokes the relevant maintainer.
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
It has never been a requirement to Cc: the custodian. It is up to the custodian to pick up the work that falls into hiw bailiwick, including for example global changes that happen to affect his architecture / subsystem. Of course this requires that you are subscribed. And that you actually *read* the list, at leats to the extend that you recognize certain buzzwords in the Subject: lines, like the name of the architure you feel responsible for.
In other words, being a u-boot custodian takes a lot more work than being a Linux maintainer. Combine this with what I said before about it being difficult to justify spending a lot of time keeping the bootloader limping along, and it's not good news if you want more vendor involvement.
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.
Your idea of working as a maintainer is very much different from mine, and from the actual requirements for the job.
That seems to be the case, yes.
Haavard
participants (7)
-
Andreas Bießmann -
Bas Mevissen -
Eric Bénard -
Haavard Skinnemoen -
Mike Frysinger -
Reinhard Meyer -
Wolfgang Denk