Release schedule and stable releases

[Cong Wang]

On Tue, Mar 17, 2015 at 3:26 AM, Thomas Haller <thaller at redhat.com> wrote:
> 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)...
>

It is already how kernel stable releases work. :)

>
>> > 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


Yes, this is how stable kernels work too. Usually we can pick and
stick to a major version, say 3.2.25, so we don't have to check all
these releases, we only need to check 3.2.25.2 here. :)


>
>
> 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.
>

That is true, that is distro maintainers' work to pick the right version
of Mesos to work with a right version of libnl. However, for Mesos
upstream, aka distro-independent, we need to work with libnl
upstream rather than any distro. This is why I am asking here.


> 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.
>

Compare with libnl, kernel is an indirect and weak dependency for
Mesos, we do pick a minimum major kernel version too (3.10 for
network isolation). We can workaround some minor kernel bugs, but
we can't workaround run time libnl bugs like the one mentioned
previously.


>
>
> 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.
>

We already use nl_has_capability() in Mesos to test features we need,
but this way doesn't scale for bug fixes, it is limited by its int parameter.

Thanks.