| Age | Commit message (Collapse) | Author |
|---|
|
The candidate list for backports lists partial fixes like:
"(21.02 (partially fixed in 21.08))"
That is useful to identify fixes meant for later releases, but
indirectly applying to older ones as well.
While the devscript has no access to the stable tree to fully check
if the respective interim commit is present there, reporting the commit
id will still help to check it later - because only if the interim commit
id is in the stable tree, then also the new fix is a real candidate
for backporting.
The above would become "(21.02 (partially fixed in c30751afc360 @ 21.08))"
Signed-off-by: Christian Ehrhardt <[email protected]>
Acked-by: Luca Boccassi <[email protected]>
Acked-by: Kevin Traynor <[email protected]>
Acked-by: Xueming Li <[email protected]>
|
|
It was important in the past to select anything with "fix" in the
headline, but recently more often created false positives and work
to sort things out than identifying many helpful patches.
The community and processes around DPDK matured enough that developers
(rightfully) expect to rely on "Fixes:" or "stable@" marking for
backports.
Therefore do no more include patches that just include the word fix
in the backport candidate list.
Signed-off-by: Christian Ehrhardt <[email protected]>
Acked-by: Luca Boccassi <[email protected]>
Acked-by: Kevin Traynor <[email protected]>
Acked-by: Xueming Li <[email protected]>
|
|
A decision was made [1] to no longer support Make in DPDK, this patch
removes all Makefiles that do not make use of pkg-config, along with
the mk directory previously used by make.
[1] https://mails.dpdk.org/archives/dev/2020-April/162839.html
Signed-off-by: Ciara Power <[email protected]>
Reviewed-by: Ruifeng Wang <[email protected]>
Signed-off-by: Thomas Monjalon <[email protected]>
|
|
During backporting, if the fixes or stable tag are missing,
it usually requires some investigation by stable maintainer
as to why.
The presence of a fixes tag may be known from whether the
originating release of the issue is printed at the end of the
line but with variable line lengths and nested partial fixes
it doesn't catch the eye.
When there are a large amount of commits, adding an aligned column
indicating the presence of a fixes tag beside the stable one makes
it easier to quickly see the patches requiring further investigation.
e.g.
20.02 8f33cbcfa S F net/i40e/base: fix buffer address (16.04)
20.02 4b3da9415 S F net/i40e/base: fix error message (1.7.0)
20.02 1da546c39 - F net/i40e/base: fix missing link modes (17.08)
20.02 79bfe7808 S F net/i40e/base: fix Tx descriptors number (1.7.0)
20.02 50126939c - F net/i40e/base: fix retrying logic (18.02)
20.02 dcd05da0a S F app/testpmd: fix GENEVE flow item (18.02)
20.02 b0b9fdad2 S - net/bnx2x: support secondary process (N/A)
20.02 f8279f47d S F net/netvsc: fix crash in secondary process (18.08)
Signed-off-by: Kevin Traynor <[email protected]>
|
|
Signed-off-by: Olivier Matz <[email protected]>
|
|
The script git-log-fixes.sh (used in check-git-log.sh) looks
for git tags to find the version where a bug is introduced.
In DPDK 17.08, the script has been fixed to ignore tags from
non current branch.
It was using the option --merged which was introduced in git 2.7.0.
As git 2.7.0 is not so old, a fallback is provided for some years.
The fallback is replacing the tag --merged option by a branch filter.
If the tag is found in the branch, the branch name is replaced
by the tag.
This script could be improved to allow using another reference branch,
instead of hard coding HEAD branch (the current one).
Fixes: 26857dabb3c9 ("devtools: ignore non merged tags for backport")
Cc: [email protected]
Signed-off-by: Thomas Monjalon <[email protected]>
Tested-by: Nelio Laranjeiro <[email protected]>
|
|
When checking if a buggy commit was introduced in an old version,
the script compares last tag containing the bug and current version.
The non merged tags from non related branches must be ignored.
Signed-off-by: Thomas Monjalon <[email protected]>
|
|
Some commits for stable releases (with Cc stable tag) may not have the
fixline.
Thus, this patch makes git-log-fixes.sh script also list those stable
commits do not have fixline.
Signed-off-by: Yuanhan Liu <[email protected]>
|
|
So that, as a stable maintainer while picking commits to a stable release,
I could pay less attention to those have it and pay more attention to those
don't have it.
Signed-off-by: Yuanhan Liu <[email protected]>
|
|
There was a bug when looking at a commit fixing a commit which
itself was fixing many commits:
% devtools/git-log-fixes.sh 12ee45a36~..12ee45a36
devtools/git-log-fixes.sh: 96: local: 5499c1fc9baa: bad variable name
In this case, the list of commits was not quoted in variable assignment.
Signed-off-by: Thomas Monjalon <[email protected]>
|
|
The remaining scripts in the scripts/ directory are only useful
to developers. That's why devtools/ is a better name.
Signed-off-by: Thomas Monjalon <[email protected]>
Tested-by: Ferruh Yigit <[email protected]>
|
