Collaboration Guide

[Ho-Ro]

Hi avrdudes,

After my question about coding style here's another missing guide - how to submit PRs in a most practical way. What I learned was that you like small independent commits targeted at one subfeature each, so a specific PR can sometimes consist of a huge stack of smaller commits. If the PR is reviewed and finally released the maintainer will typically squash and merge to avoid clutter, so in the end only one big commit goes into the main branch. This model allows the collaborators to release early and often during the working on the PR.
I could think that this kind of information should be easy available for avrdude user that are willing and able to provide new features or bug fixes (I searched but did not manage to find something comparable).

Just another idea
Martin

[mcuee]

@stefanrueger and @dl8dtl

You may want to share your views. Thanks.

[stefanrueger]

This is a pretty difficult to put into a set of rules. Firstly, there is the question of scope: should AVRDUDE concern itself with the suggested functionality at all? This is often openly discussed as an issue. Then the question of how: Should the code be intelligent and know about parts/programmers behaviour? Should the necessary aspects be modelled using externalised knowledge, eg, command line options, programmer/part options in config fiies, a more complex grammar of the configuration file? Again, we maintainers are often surprisingly at odds with each other and tend to discuss how to solve a certain aspect. Then the question of how general should this be implemented? For all programmers? For all suitable parts? Which of the functionality should end up in library functions?

There are three overriding principles though: keep existing functionality (AVRDUDE still supports a shedload of parallel-printer-interface(!) programmers), don't surprise the user and do document all functionality.

We tend to play with ideas trying them out and then either forfeiting them or keeping them. We try to view PRs from the hardware angle, from the user's point of view, through future expansions and development lenses, and from an implementation angle. This draws on different expertise and experiences, so again it's important that the team discusses these.

All of that means that a PR can have quite a few commits that look odd in hindsight. We have withdrawn PRs in the past and re-coded the best solution, or squash merged or simply merged (keeping a record of what we tried).

So, no I don't think we have a collaboration guide (and maybe we don't need one?).

[dl8dtl]

There are three overriding principles though: keep existing functionality (AVRDUDE still supports a shedload of parallel-printer-interface(!) programmers), don't surprise the user and do document all functionality.

Wholeheartedly agreed.