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

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

[Reinhard Meyer]

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

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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100729/2f9cd3c0/attachment.pgp 

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Houston, Tranquillity Base here.  The Eagle has landed.
                                                    -- Neil Armstrong

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

[Reinhard Meyer]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reinhard_meyer.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100805/8967afaf/attachment.vcf 

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

[Andreas Bießmann]

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

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

[Reinhard Meyer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: reinhard_meyer.vcf
Type: text/x-vcard
Size: 370 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100805/5f4f725f/attachment.vcf 

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

[Eric Bénard]

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

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

[Bas Mevissen]

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.

-- 
Bas.

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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100805/90ff1f99/attachment.pgp 

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Celestial navigation is based on the premise that the  Earth  is  the
center  of  the  universe.  The  premise is wrong, but the navigation
works. An incorrect model can be a useful tool.   - Kelvin Throop III

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

[Reinhard Meyer]

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

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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100806/1cb5b623/attachment.pgp 

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

[Reinhard Meyer]

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

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

[Mike Frysinger]

On Friday, August 06, 2010 20:58:14 Reinhard Meyer wrote:
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100806/09a245a6/attachment.pgp 

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The rule on staying alive as a program manager is to give 'em a  num-
ber or give 'em a date, but never give 'em both at once.

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

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"...one of the main causes of the fall of the Roman Empire was  that,
lacking  zero,  they had no way to indicate successful termination of
their C programs."                                     - Robert Firth

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Have you lived in this village all your life?"        "No, not yet."

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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100807/a9e29901/attachment.pgp 

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

[Reinhard Meyer]

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

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

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100807/34812983/attachment.pgp 

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

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4C5DE9F7.4070701@emk-elektronik.de> you wrote:
>
> 1. If the patch is simple enough reasoning might be sufficient.

Might. But things might go wrong.  Turn around - Murphy is standing
right behind you.

> 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 

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

> 3. 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.

> 4. 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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Every solution breeds new problems.

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

[Haavard Skinnemoen]

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

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

[Mike Frysinger]

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

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

[Haavard Skinnemoen]

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

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

[Mike Frysinger]

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

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

[Wolfgang Denk]

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 at emk-elektronik.de

==> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81812


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.                                               - Bill Gates

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

[Haavard Skinnemoen]

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

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

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To be a winner, all you need to give is all you have.

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

[Haavard Skinnemoen]

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