Re: Issue reporting and Pull Request rules?

[Jeff Long]

The backport-3.8 label would mean "this PR is against a non-3.8 branch and needs to be ported to 3.8", though it hasn't been used that way consistently. A PR for 3.8 would already be targeted at that branch, so there's no need to also tag it that way. There will also be forward ports. It's likely that, since 3.8 is going to be usable for a while, people will submit bug fixes for it. A PR could be tagged (3.10,3.9,port-3.8) potentially.

Here are some ideas about the process, to get a discussion started:

• TBD: clearly define the meaning of version numbers, with respect to API, ABI and even GRC changes/compatibility.
• Decide whether the PR is eligible for backporting, and to what branch. This is kind of rough due to the number of different ways changes can affect compilation/linking/runtime.
• Simple fixes with no API or runtime behavior change can go in the next a.b.c.d version. These version can be tagged often. An example is an internal fix to a calculation.
• Changes that do not affect the API (except addition of blocks), but that change runtime behavior for the better would go in the next a.b.c version. Block yml may change, causing the need to regenerate a flowgraph, though this would be avoided if possible. Autogenerated code messes up nice versioning rules, so this may continue to be a grey area.
• API changes (except maybe serious bug fixes?) go in the next minor (a.b) version.
• Things that cause OOTs a lot of work go in next major version.
• For smaller, easily understandable changes, a PR could be marked "Backport-a.b", implying that it would be easier for a maintainer to figure out the correct backport. Maintainers can then say "sorry, need more help from the author" if it's a bigger deal than the PR author though it was, it requires testing, etc.
• For larger changes, the PR author would make separate PRs and work with maintainers to get everything settled. This implies that the PR author builds/tests against each each targeted branch.
• Issues can be tagged with version numbers. The issue should contain the version (and other info) in text, explaining the environment where the issue was found. The minor versions (a.b) known to be affected would appear as tags.

Any ideas from other projects that have complex dependencies and a small crew of maintainers?

On Sat, Feb 20, 2021 at 6:01 PM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

As a regular user of GNURadio, I sometime trying to improve the code and made some PR. I came to these questions and observations :

I think It would be a good practice to encourage those reporting issues (and also posting email on this list) to clearly indicates which GR version(s) is (are) concerned. I don't remember having seen such recommendations on GNURadio Github.

And for those making PR, may be we need to propose or expose some rules.

I made a PR for another issue this evening, and was not really aware of what should be done since it concerned 3.8 3.9 and master. So I made 3 PR.

• Is this the right method ?
  
• How to avoid fixing a bug on one branch while forgetting that other branches could have the same bug not fixed (which seems to be the case in #4251)
• What is the best method to reduce maintainer work ?
  

A related question: what is the real meaning of issue label "backport-3.8" ? does it means we must check if this issue is present in GR 3.8, or, something similar?

In case code modifications are light and identical or similar for both branches, is there a simpler methods than sending 3 PR ?

Once again, many thanks to the maintainers and Marcus for his (passed) Mainternership. Gnuradio is really becoming a great tool for SDR and radiocommunications

Regards, Christophe