[Evan Huus <eapache@xxxxxxxxx>]

On Thu, Apr 17, 2014 at 6:58 PM, Bálint Réczey <balint@xxxxxxxxxxxxxxx> wrote:
> 2014-04-17 23:21 GMT+02:00 Evan Huus <eapache@xxxxxxxxx>:
>> On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman
>> <anders.broman@xxxxxxxxxxxx> wrote:
>>>
>>>
>>> -----Original Message-----
>>> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Bálint Réczey
>>> Sent: den 17 april 2014 09:59
>>> To: Gerald Combs
>>> Cc: Developer support list for Wireshark
>>> Subject: Re: [Wireshark-dev] Wireshark LTS branches
>>>
>>> Hi Gerald,
>>>
>>> 2014-04-17 1:59 GMT+02:00 Gerald Combs <gerald@xxxxxxxxxxxxx>:
>>>> On 4/16/14 3:42 AM, Bálint Réczey wrote:
>>>>> Hi,
>>>>>
>>>>> Many of you probably know about the Wireshark package [1] in Debian
>>>>> which I started maintaining a few years ago. Like every other package
>>>>> in Debian, the version of Wireshark included in the major
>>>>> distribution release is getting security and stability updates
>>>>> through the lifetime [2] of the major distribution release which is
>>>>> typically 3 years, but it is still shorter than the lifetime of an
>>>>> Ubuntu LTS (5 years) or Red Hat [3] (10 years).
>>>>>
>>>>> Wireshark, the Project, makes a major release every year and
>>>>> according our current policy we support [4] the current and previous
>>>>> release which makes Wireshark releases lifetime 2 years.
>>>>>
>>>>> Wireshark makes point releases after each major release fixing bugs
>>>>> adding minor features and improvements, but only the security and
>>>>> some stability related fixes get included in updates to the Debian package.
>>>>> Since the Debian packages have longer lifetime than Wireshark release
>>>>> I back-port security related fixes to older releases than the project
>>>>> which means that I already maintain two Wireshark branches with
>>>>> security fixes only in the form of patch sets [5]. Other distribution
>>>>> maintainers do the same.
>>>>>
>>>>> Since we moved to Git maintaining the branches became easier and I
>>>>> would like to as the project to allow me to maintain the two existing
>>>>> branches in the projects repository. Going forward I would like to
>>>>> open one similar branch for at least every Debian major release and
>>>>> maintain at least through the major release's lifetime.
>>>>>
>>>>> I think it would not create any significant additional work for the
>>>>> community but it would provide many advantages.
>>>>>
>>>>> 1. We could provide an upgrade path for people focused only on
>>>>> security but not on other improvements keeping the existing release
>>>>> plan.
>>>>> 2. Distribution maintainers could eliminate the duplicate work by
>>>>> collaborating in the LTS branches.
>>>>> 3. Back-ported fixes could get better testing using the existing
>>>>> buildbot infrastructure.
>>>>> 4. Back-ported fixes could be reviewed by more people.
>>>>>
>>>>> One additional note regarding Debian, we (at Debian) are thinking
>>>>> about extending the lifespan of each release to 5 years [7] and this
>>>>> would extend my commitment to maintaining the Wireshark LTS branches
>>>>> naturally.
>>>>>
>>>>> Would the Project be open for the proposed branches?
>>>>
>>>> Overall it sounds fine to me. How many branches would be created and
>>>> how would they be named?
>>> I would like to create two branches forking off from 1.2.11 1.8.2 because those are the base versions for Debian oldstable and stable.
>>> If others are interested, we could find an LTS forking point for every major branch, but those are which I maintain already.
>>>
>>> The next could fork off from 1.12.x based on the freeze date for next stable, which is November 5th. If other distributions are interested we could find a forking point which would fit their release schedule as well.
> I forgot to answer the question regarding the naming,
> master-lts-1.2.11 and master-lts-1.8.2 would be close to the current
> scheme, I think.
>
>>>
>>> Hmm this seems backwards to me, if the distributions don't take the point releases we make, there is something wrong with our point releases or we shouldn't be making them in
>>> The first place if no one is using them. Seems like a lot of work for nothing to me.
>>
>> This was also my original reaction. We do a fair amount of work (or at
>> least Gerald does quite a lot of work), maintaining stable and
>> old-stable Wireshark branches already. It seems like it would be
>> easier for everybody if we tweaked our stable-backport policy so that
>> Debian and whoever else could just grab new stable versions from us
>> directly.
>>
>> I can't speak for Debian, but Ubuntu has a specific policy for this
>> sort of thing:
>> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
>>
>>> Should we change our backport policy to fit the distributions need or are they to different to have a fits all procedure. Perhaps the distribution should point out which backports to do?
>
> 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.

I'm reading that link as saying Debian Stable doesn't get *any*
non-security bug-fixes, which is surprising?

> Ubuntu usually syncs security updates without changes from Debian.
>
> Are there any other distribution maintainers on the list? :-)

I've thought about applying as Ubuntu maintainer before, but you've
always done such a good job with the Debian stuff it's been easier to
just let the syncs happen automatically :)

> Cheers,
> Balint
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe