I think it might help if we rename those labels. Maybe something like
"PleasePortThisTo3.9". A less verbose label would also work as long as it
conveys the intent.
On Sun, Feb 21, 2021 at 2:33 PM Jeff Long <willcode4@gmail.com
<mailto:willcode4@gmail.com>> wrote:
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.
o 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.
o 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.
o API changes (except maybe serious bug fixes?) go in the next minor
(a.b) version.
o 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
<mailto: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
<https://github.com/gnuradio/gnuradio/issues/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