[avr-gcc-list] Re: AVR toolchain patch hell

[Rolf Ebert]

Eric Weddington schrieb:

> - Can we get more people to be official maintainers of the avr port of
> binutils and gcc? That way there won't be such a bottleneck in getting
> patches committed to mainline.

Thanks to everybody who responded here and who took the responsibility 
to become official maintainers.

> - Can we figure out some level of coordination between all the various
> distros as to what should be the patch list for a particular release?

I think this is the main issue and has not been addressed yet in the 
discussion.  Eric provides us a list of open issues in the toolchain. 
Thanks a lot for that!

This list is an excellent starting point to manage the existing patches, 
their quality (test, doc status), and their release status (planned and 
actual). For example the patch for PR23479 has corresponding 
documentation and test cases and is already applied in the WinAVR binary 
distribution since several (?) years.

Other patches like e.g. Bernd's backport of the ATmega256X patch to 
binutils-2.17 (see his message as of two days ago) should get a test 
status and probably a planned release tag (e.g. will be part of the next 
WinAVR release)

So, I propose to add some more attributes to the bug list:
- patch exists (yes/no) with link to the latest patch
- relative gcc/binutils version
- language (C/C++/Ada) or host system (MinGW) specific patch
- planned/considered for next/second next release
(probably it would help to use a naming scheme for the patch files that 
includes some of the attributes.  That helps in automated build scripts)

I know that some of the information is readily available in the problem 
reports themselves.  Nevertheless, it should be shown in the AVR 
Toolchan Bugs list, too.  The AVR bug list and the PRs have different 
purposes.  The PRs help managing the corresponding upstream tools, the 
AVR bug list intends (as I understand it) to give an overview of all 
open issues in all AVR GNU tools and to coordinate the efforts that have 
to be spent.  It takes several months if not years until an existing 
patch is actually deliverd in a new upstream release of gcc or binutils. 
 All this "patch hell" is caused by our appetite to see the 
enhancements as soon as possible, i.e. in the next release of WinAVR.


    Rolf