[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Rolf Ebert
Subject: [avr-gcc-list] Re: AVR toolchain patch hell
Date: Thu, 07 Sep 2006 00:23:29 +0200
User-agent: Thunderbird (Windows/20060719)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]