Wireshark · Wireshark-dev: Re: [Wireshark-dev] Wireshark LTS branches

[Bálint Réczey <balint@xxxxxxxxxxxxxxx>]

Hi,

2014-04-18 21:51 GMT+07:00 Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>:
> On 04/17/14 23:11, Guy Harris wrote:
>>
>>
>> On Apr 17, 2014, at 3:58 PM, Bálint Réczey <balint@xxxxxxxxxxxxxxx> wrote:
>>
>>> Well, last time I brought this up the project decision was to allow
>>> minor improvements, too:
>>> http://comments.gmane.org/gmane.network.wireshark.devel/15323
>>>
>>> The best solution for me as a maintainer at Debian would be limiting
>>> the changes to security fixes conforming to the policy:
>>> https://www.debian.org/security/faq#policy , but as a second-best
>>> option I could live with the special LTS branches.
>>
>>
>> The best solution for many end-users would probably be *not* to limit the
>> changes to security fixes - if we have a fix for a mis-dissection, they'd
>> probably want that, for example.
>
>
> I agree.  I push the stable release micro versions to my users because it's
> often important to have bug fixes too.
>
> Fedora appears to be picking up the micro-releases as-is (Fedora 18 actually
> even upgraded from 1.8.3 to 1.10.2; hopefully this means they've come to
> think of Wireshark as a "desktop app" like Firefox which must be reasonably
> up-to-date in order to be useful).
Debian does that with Firefox, too, not because it is a "desktop app",
but AFAIK because upstream refuses providing separated security fixes
and mining them from micro-releases is prohibitively time consuming
for the Firefox (Iceweasel) package maintainers.
Luckily being a Wireshark Developer in addition to a DD and thanks to
Wireshark's more maintainer-friendly release policy I was able to
extract security fixes from point releases thus we (Debian) did not
have to make an exception for Wireshark.
Having the aforementioned LTS branches would help me in ensuring
better quality of back-ported patches and would help other
distributions' wireshark maintainers to pick the same patches more
easily.
It is also worth mentioning that Debian stable has latest Wireshark
(1.10.7) packaged too, through Debian's official wheezy-backports thus
users of stable can choose between the slower-moving 1.8.2 + security
patches and the latest upstream's stable version.

>
>
>> Given that, having separate "security fixes only" branches, for packagers
>> and users who *only* want security fixes, and support branches, for
>> packagers and users who also want those bug fixes that we deem "appropriate"
>> for the support branches, is probably the right answer.
>
>
> ... And on the other hand we have RHEL/CentOS which seem to be manually
> applying patches: 6.0 came with Wireshark 1.8.10-4 (the "-4" being their
> nano-version) and the latest update appears to be 1.8.10-7.
>
> The problem, I think, with having "security fixes only" branches is that
> different distributions pick different starting points--probably based on
> when they ship.  Balint/Debian, for example, wants a branch off of 1.8.2 but
> it appears RHEL/CentOS would like one off of 1.8.10. Obviously this doesn't
> scale well [for us] so presumably we'd only do "master-lts-1.8.0" [at least
> for future versions]?
Usually the most obvious bugs are found and fixed in the early
versions of each maintenance branch thus I would not pick .0, but the
first version when any major distribution or party signals the need
for starting an LTS branch.
(I'm a bit surprised that no one showed up from RH or SuSe in this thread.)

>
> Another aspect is I'd be willing to bet that RHEL doesn't apply just
> security fixes but also bug fixes that their (paying) customers have run
> into--so they might not use our lts branch anyway.
Even though they probably won't use our LTS branches it would help
them in picking security fixes.

I have prepared the branches in form of patches ready for being 'git
am' -ed here:
http://cs.bme.hu/~rbalint/lts-1.2.11.tar.gz
http://cs.bme.hu/~rbalint/lts-1.8.2.tar.gz

They were forked off from 1.2.11 and 1.8.2 respectively and they
contain the non-Debian-specific changes used in the Debian security
updates.
I think the new branches could be called simply lts-1.2.11 and
lts-1.8.2, but I would be fine with master-lts-x.y.z or any other
scheme.

I think there is no opposition formed against the proposed LTS
branches so if Gerald agrees he could name and start the branches and
I would submit the proposed content through Gerrit or he could import
and push the content directly.

Is there other concerns, comments?

Cheers,
Balint