avrdude issues labeled as enhancement

[mcuee]

I will use this to discussion to better track the openning issues labeld as enhancement.
https://github.com/avrdudes/avrdude/issues?q=is%3Aopen+is%3Aissue+label%3Aenhancement

[mcuee]

The main discussion points will be the following.

1. Do we want to close a paticual enhancement request as not planned?
2. Do we want to ask community for help and label the issue as help wanted?
3. For older enhancement request with patches, do we want to conver them as a PR (even though the original author is not reachable)?
4. What is the criteria to keep an enhancement request open?
5. ???

[mcuee]

Example:

• CH341A futher improvement -- to support lower clock AVR chips #1336
  Two school of thoughts --

1. to close it for now and open it when there is a PR
2. to keep it open so that we know there is a limitation for the current CH341 implementation.

[mcuee]

Another example related to avrdude-libusb.

• CH341A futher improvement -- to support MSVC build #1339

We can swtich msvc build to use official libusb-1.0 project and then this issue and #968 can be closed. However, we should hear @mariusgreuel's opinion on this topic.

[stefanrueger]

I would keep enhancement ideas if we have someone on the team who champions it (eg, assigns themselves to it or wants the community to help out) or if we have a PR that we can review/action. Otherwise I would remove them as not planned, particularly if they have hung around for more than a few months (that's the case with #1336 and a few more). My tuppence.

[mcuee]

I have labeled most of the enhancement issues with help wanted.

1. to indicate that no active maintainers are working on them.
2. to indicate that there are some values of the enhancement request.

Then we can probably close them after a while (say a year?), or move to Discussion.

[stefanrueger]

most of the enhancement issues with help wanted.

That looks like an overkill to me. Do we have evidence that labelling an issue with help wanted makes a difference?

I would rather remove of those issues which no-one has pledged to take on.

Can we delete the two CH341A issues, please? They are a by-product of an incomplete PR. In hindsight it would have been better to not accept the original PR (as Jörg did originally based on the argument that it cannot program any factory-set parts so need a different programmer first anyway).

[mcuee]

@stefanrueger
I have moved two CH341 enhancement tickets to Discussion.

Any other enhancement issues you think we should close?

[stefanrueger]

moved two CH341 enhancement tickets to Discussion

Thank you. Really don't want to encourage partial PRs that then end up creating more issues than they solved.

Maybe we should consider one discussion (rather than many) that lists all the known issues that we might (or might not) want to address in the future. This could eventually become a section "Limitations" in the avrdude pdf manual, too.

[mcuee]

That is the idea of using this discussion for enhancement related issues.

For bugs there is another discussion. Usually we want to deal with bugs even though some bugs may be considered as low priority.

But for enhancement, we may decide to drop them.

[mcuee]

I will create another issue for known issues.

Done.

• Known issues of avrdude #1444

[mcuee]

Quick scan of the Enhancement.

• Add -xrtsdtr=low,high to the jtag2updi programmer #1408 -- PR available, should be able to merge this before 7.2 release
• Microchip MPLAB ICE 4, MPLAB ICD 5 and PICKit 5 support #1368 -- this will take some time but I think we can keep it for quite some time
• avrdude memory type enhancement #1330 -- @stefanrueger will work on this so I am sure he will be able to sort this out later
• Query a programmer to figure out its current clock speed (low priority) #1329 -- based on the investigation by @MCUdude, this may not be possible as many programmers may not support this.
• To adopt PR #1264 approach of using Readline replacement for MinGW build (Low Priority) #1271 -- nice to have but not essential
• ftdi_syncbb: very slow D2XX based MSVC build compared to libftdi based MinGW build #1253 -- nice to fix but not essential as one can use MinGW build
• Harmonize WIN32 implementation of serial time-outs with Posix one #1249 -- nice to have, but we can wait when @mariusgreuel got the time
• Enhance CMake to be able to support static link for Linux and macOS #1159 -- need to get the help from CMake experts
• Missing TPI, JTAG and UPDI support for the STK600 #1047 -- need to wait for @MCUdude or someone who has access to STK600 (not so popular)
• Switch a PICkit4 or MPLAB SNAP programmer to AVR mode #1027 -- nice to have but not essential, we can wait for @MCUdude to figure out the way with the inputs from Microchip insiders
• usbasp xmega pdi enhancement #1024 -- nice to have as there are not many PDI capable programmers outside of Microchip official tools
• Differentiate multiple USB programmers of the same VID/PID (libusb or hidapi or libftdi) #973 -- nice to have
• Add Apple M1 silicon to Nightly-Builds #939 -- need to wait for github to come out with offiial Apple Silicon support
• Support COM port discovery via USB VID/PID #907 -- nice to have, the worry is if there will be too much platform depedant codes
• Rework PICKit2 programmer to use libhidapi instead of libhid (which will make it work under macOS) #883 -- nice to have
• Using libavrdude as a standalone library #819 -- already done for Linux and FreeBSD, not a big issue under macOS, but Windows is the issue (Unable to build libavrdude dynamic library under Windows and macOS #1414)
• Remove all calls to exit(3) from libavrdude library functions #774 -- nice to have
• [patch #9565] Patch for WiFi AVR Programmer, uPDI support for jtagmkII, and serial-over-network improvements #734 -- need to wait until @dl8dtl got the time.

[stefanrueger]

@mcuee Great analysis. I would remove Help wanted from both the Nice to have and Nice to have but not essential issues. I am actually very pleased that the number of issues has shrunk to a single page (from many, many pages) and that there are hardly any known bugs left.

[mcuee]

I would remove Help wanted from both the Nice to have and Nice to have but not essential issues.

Done. Now only 6 issues are labeled as help wanted. Please check which of the following you think we should remove the help wanted label.

• Improve programmer documentation in avrdude.conf #1437
• Unable to build libavrdude dynamic library under Windows and macOS #1414 (not so sure if want to remove the help wanted label. This may not be an easy task.
• Enhance CMake to be able to support static link for Linux and macOS #1159 (need help from CMake experts to provide proper PR. working but not proper fix available from avrdude-packing project)
• To improve the documentation of libavrdude functions #1057
• Using libavrdude as a standalone library #819 (related to Unable to build libavrdude dynamic library under Windows and macOS #1414)
• [bug #44644] Missing access to user signature rows in ATmega256RFR2 et al. #379 (we may need people who have the hardware to test)

[stefanrueger]

Now that we have the number of issues brought down to around 25 they typically fit on one page. So the issues page is probably a better place to get an overview of enhancement ideas. @mcuee should we close this discussion?

[mcuee]

Yes I agree.