[dpdk-stable] [scripts] README: clean DPDK clone and main branch to generate list

[Xueming(Steven) Li]

> -----Original Message-----
> From: Christian Ehrhardt <christian.ehrhardt at canonical.com>
> Sent: Wednesday, April 28, 2021 2:40 PM
> To: Xueming(Steven) Li <xuemingl at nvidia.com>
> Cc: dpdk stable <stable at dpdk.org>; Luca Boccassi <bluca at debian.org>
> Subject: Re: [scripts] README: clean DPDK clone and main branch to generate list
> 
> On Wed, Apr 28, 2021 at 8:03 AM Xueming Li <xuemingl at nvidia.com> wrote:
> >
> > Tags of "dirty" repository confuse git-log-fixes.sh.
> > The script also expects current branch to contains end tag of range.
> >
> >
> > Signed-off-by: Xueming Li <xuemingl at nvidia.com>
> > ---
> >  README | 8 ++++++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/README b/README
> > index 70f4320..911f169 100644
> > --- a/README
> > +++ b/README
> > @@ -26,11 +26,15 @@ as tmp dir for the patches and mails.
> >  1.A
> >  ---
> >  A list of commits to backport should be generated. This can be
> > generated -from "git-log-fixes.sh" script from DPDK. Normally the
> > start of range is
> > +from "git-log-fixes.sh" script from DPDK. The DPDK repository should
> > +be clean to avoid additional tags confuse script. Normally the start
> > +of range is
> 
> I agree with the overall hint being useful, but dirty/clean have a very specific meaning in git and I wonder if that makes this confusing.
> How about: "The repository this is executed in needs to be free of conflicting tags - since developers accumulate remote repositories,
> branches and tags a fresh git clone is the most reliable source to use."
> ^^ This (using a new clone) also matches your extended example that you've added

Thanks, new version sent.

> 
> >  the end tag of last generated range, branch tag if working on the
> > first  stable release. The end of range is latest release tag.
> > Assuming v17.11-rc1 -is out you can prepare a commit list for v17.08.1 stable release with:
> > +is out, you should checkout a branch that contains end of range,
> > +normally main branch.
> 
> Hmm, you are right it is needed to be on a branch containing those.
> I never realized that and got lucky by accident it seems.
> I tried a different branch and it indeed returns an empty list.
> It is the function commit_version and therein the --merged that otherwise fails.
> One could provide a commit to --merged, but then how would we reliably know how the repository and branches are called.
> I agree that asking for the main branch to be checked out is a simple solution until someone wants to improve git-log-fixes.sh in that
> regard

I'm wondering is there some mature scripts from popular open source community could be borrowed.

> Thereby ack to this section.
> 
> > Then prepare a commit list for v17.08.1 stable release with:
> >
> > +    $ git clone http://dpdk.org/git/dpdk
> > +    $ cd dpdk
> 
> Ack to this, while everyone can do it differently - this example works "for sure"
> 
> >      $ ./devtools/git-log-fixes.sh v17.08..v17.11-rc1 > /tmp/list
> >
> >
> > --
> > 2.25.1
> >
> 
> 
> --
> Christian Ehrhardt
> Staff Engineer, Ubuntu Server
> Canonical Ltd