[dpdk-stable] What kind of commits can be backported to help the process

[dpdk-stable] What kind of commits can be backported to help the process

[Nélio Laranjeiro]

Hi stable mailing list,

As written in the subject, it is not fully clear on what kind of patches
can enter this branch.

Some fixes apply easily on top of other ones which may not be related,
the question is on those "unrelated" patches.  Is it acceptable to
backport them, and if yes at what point is it acceptable depending on
the nature of the patch:

 1. Re-work: just a refactor of some structure, clean-up, ...
 2. Behavior: it change the behavior of a part of the code, ...
 3. Performances: it impacts performances (positively or negatively).
 4. None, the patch must apply by itself.
 5. ...

What is the expectation for this branch?

Thanks,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-stable] What kind of commits can be backported to help the process

[Yuanhan Liu]

On Wed, Feb 15, 2017 at 11:23:45AM +0100, Nélio Laranjeiro wrote:
> Hi stable mailing list,
> 
> As written in the subject, it is not fully clear on what kind of patches
> can enter this branch.
> 
> Some fixes apply easily on top of other ones which may not be related,
> the question is on those "unrelated" patches.  Is it acceptable to
> backport them, and if yes at what point is it acceptable depending on
> the nature of the patch:
> 
>  1. Re-work: just a refactor of some structure, clean-up, ...
>  2. Behavior: it change the behavior of a part of the code, ...
>  3. Performances: it impacts performances (positively or negatively).
>  4. None, the patch must apply by itself.
>  5. ...
> 
> What is the expectation for this branch?

Here is the typical flow I took to pick commits to a specific stable
branch:

- firstly, I will get a list of bug fixing commits, with the help of
  devtools/git-log-fixes.sh (as well as the "cc: stable@dpdk.org" tag
  inside the commit log).

  Those commits fix some bugs in a former releases, thus they will be
  applied to a specific stable branch.

- Some of them could be applied cleanly. I will then drop a note to
  all related people (the author, the reviewer, etc) and stable list,
  to inform that this commit will be in a specific stable release.

- And some of them could not be applied cleanly, when conflicts happens
  (code base could be changed).

  When that happens, I will try to backport it by myself if the commit
  is simple enough (say, just few lines of code and the conflicts could
  be easily fixed).

  If not, I will stop (to not mess something up because I'm not familar
  with the code), instead I will then ask the author (and even, the
  maintainer) to do the backport. And that's how the 'request-backport'
  email comes.

So to answer your question. The backport should be easy (when one guy
knows the code enough). If it invovles re-work and changes the behavior
the commit doesn't have, it basically means it's done wrongly.

That helps?

	--yliu

Re: [dpdk-stable] What kind of commits can be backported to help the process

[Nélio Laranjeiro]

On Thu, Feb 16, 2017 at 01:03:03PM +0800, Yuanhan Liu wrote:
> On Wed, Feb 15, 2017 at 11:23:45AM +0100, Nélio Laranjeiro wrote:
> > Hi stable mailing list,
> > 
> > As written in the subject, it is not fully clear on what kind of patches
> > can enter this branch.
> > 
> > Some fixes apply easily on top of other ones which may not be related,
> > the question is on those "unrelated" patches.  Is it acceptable to
> > backport them, and if yes at what point is it acceptable depending on
> > the nature of the patch:
> > 
> >  1. Re-work: just a refactor of some structure, clean-up, ...
> >  2. Behavior: it change the behavior of a part of the code, ...
> >  3. Performances: it impacts performances (positively or negatively).
> >  4. None, the patch must apply by itself.
> >  5. ...
> > 
> > What is the expectation for this branch?
> 
> Here is the typical flow I took to pick commits to a specific stable
> branch:
> 
> - firstly, I will get a list of bug fixing commits, with the help of
>   devtools/git-log-fixes.sh (as well as the "cc: stable@dpdk.org" tag
>   inside the commit log).
> 
>   Those commits fix some bugs in a former releases, thus they will be
>   applied to a specific stable branch.
> 
> - Some of them could be applied cleanly. I will then drop a note to
>   all related people (the author, the reviewer, etc) and stable list,
>   to inform that this commit will be in a specific stable release.
> 
> - And some of them could not be applied cleanly, when conflicts happens
>   (code base could be changed).
> 
>   When that happens, I will try to backport it by myself if the commit
>   is simple enough (say, just few lines of code and the conflicts could
>   be easily fixed).
> 
>   If not, I will stop (to not mess something up because I'm not familar
>   with the code), instead I will then ask the author (and even, the
>   maintainer) to do the backport. And that's how the 'request-backport'
>   email comes.

Thanks for this information, it helps to understand how you do it.

> So to answer your question. The backport should be easy (when one guy
> knows the code enough). If it invovles re-work and changes the behavior
> the commit doesn't have, it basically means it's done wrongly.
> 
> That helps?

Not really, the issue is more related to fixes which have been published
after a re-work of the code, this re-work may have changed internal
API/ABI, structures, ...  Backporting it becomes like fixing the issue
on totally different code inducing several days of work, tests and
validation.

Should those fixes be backported?

Thanks,

-- 
Nélio Laranjeiro
6WIND

Re: [dpdk-stable] What kind of commits can be backported to help the process

[Yuanhan Liu]

On Thu, Feb 16, 2017 at 09:21:28AM +0100, Nélio Laranjeiro wrote:
> > So to answer your question. The backport should be easy (when one guy
> > knows the code enough). If it invovles re-work and changes the behavior
> > the commit doesn't have, it basically means it's done wrongly.
> > 
> > That helps?
> 
> Not really, the issue is more related to fixes which have been published
> after a re-work of the code,

Yes, that may happen.

> this re-work may have changed internal
> API/ABI,

No API/ABI changes are allowed for a stable release. But as far as the
fix doesn't offend API/ABI, it's __possible__ to backport.

> structures, ...  Backporting it becomes like fixing the issue
> on totally different code inducing several days of work, tests and
> validation.
>
> Should those fixes be backported?

My understanding is, that may depend. If it fixed a fatal bug (say,
crash, misfunction, etc), the extra several days of work/validation
may be worthwhile. If not, we may skip it.

And I think it's only the author (and maintainer) could answer the
question whether it's fatal or not.

	--yliu