Release schedule and stable releases

[Thomas Haller]

On Mon, 2015-03-16 at 20:12 -0700, Cong Wang wrote:
> On Fri, Mar 13, 2015 at 3:44 AM, Thomas Haller <thaller at redhat.com> wrote:

Hi Cong,


thank you for your input. I very appreciate it, I just don't agree on
the solution (yet)...


> > On Thu, 2015-03-12 at 11:52 -0700, Cong Wang wrote:
> >
> >> Also, there seems no stable release like 3.2.25.x? Commits like
> >> "idiag: fix out of bound error parsing idiag messages" really deserves
> >> a stable release, since there are more than 6 months between 3.2.25
> >> and 3.2.26 releases.
> >
> > libnl3 never had minor releases... I think what is a good way to manage
> > releases for large projects (e.g. for the kernel), is not necessarily
> > best for libnl3.
> >
> >
> > I will do more often major releases whenever something important shows
> > up or when somebody here asks me for a new release (*hint*).
> >
> >
> > For a downstream package maintainer it's hard to asses which patches
> > should be backported. A minor release would highlight that there is
> > something important/new.
> > But instead, I added a git-note refs/notes/release-notes to highlight
> > important patches that should be backported.
> 
> 
> The problem with this is that different package maintainers have
> different versions, it is hard for library users to check the minimum
> version of libnl to ensure it is complied against on a non-buggy libnl.


> Say Mesos needs a bug fix merged between 3.2.25 and 3.2.26
> in upstream, some distro backports it to its 3.2.25.3, another one
> backports it to its 3.2.25.4, which version should Mesos check to
> ensure it is not compiled against a buggy libnl? :)

For example:


The mentioned patch 

  >> fffc7ece - idiag: fix out of bound error parsing idiag messages
     (after libnl3_2_25)

fixes

  >> 81d2b1d - Add support for inet diag Netlink protocol.
     (after libnl3_2_22)


So, we would need minor releases 3.2.23.1, 3.2.24.1, and 3.2.25.1 with
this fix.

As we backport more patches and have more minor-releases, the numbers
fragment much. E.g. backporting a patch that fixes a bug after
libnl3_2_20 could result in following minor releases:
  3.2.21.1, 3.2.22.3, 3.2.23.4, 3.2.24.2, 3.2.25.2



> > I will mark commits there (for the future). When new important patches show up,
> > I will send an email to the mailing list to notify downstream package maintainers
> > that there is something to backport.
> >
> > Only question is, which commits should be marked as "backport". But that
> > problem is largely the same as which commits to cherry-pick for
> > backporting. Pointer from anybody welcome.
> >
> >
> > how does that sound?
> 
> I don't worry about backporting patches, at very least we can backport
> by ourselves. The problem is the version number, we need an upstream
> version which works for all distros.


Many downstream distributions don't follow the minor releases. At least,
RHEL and Debian would only cherry-pick the important patches and not
rebase to the new upstream minor version.

This is a common thing. E.g. the kernel version number on RHEL is
usually quite dated. But still a recent fix can be backported. The
version number doesn't tell you -- although kernel has minor releases
upstream.



Depend on downstream version numbers -- on a per distro-basis. On
Fedora, you would then require at least libnl-3.2.25-XY package. The
package maintainer of your software, must require a fixed downstream
version of libnl. In this
case:
  Requires: libnl3 >= 3.2.25-XY




But IMO there is another good solution:


nl_has_capability() can help to decide whether you need to workaround a
bug:
 https://github.com/thom311/libnl/blob/50a76998ac36ace3716d3c979b352fac73cfc80a/lib/utils.c#L1115
 http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/platform/nm-linux-platform.c?id=641a57994c83ed3622002b2d40fc1f9b030057bf#n4029

A capability tells you if libnl has a certain fix. On a per-fix basis!
These capability numbers are upstream and stable. "1" means everywhere
NL_CAPABILITY_ROUTE_BUILD_MSG_SET_SCOPE.


I will apply patches that help you to track features downstream.


For example we could upstream
  #define NL_CAPABILITY_HAS_FIX_fffc7ece 23

and your software does:
  if (!nl_has_capability (23, /*NL_CAPABILITY_HAS_FIX_fffc7ece*/)) {
      fprintf(stderr, "libnl3 version is broken\n");
      exit(1);
  }
or at compile time:
  #ifndef NL_CAPABILITY_HAS_FIX_fffc7ece
  #error libnl3 requires important fix fffc7ece
  #endif



Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libnl/attachments/20150317/3e132c39/attachment.sig>