On Thu, Apr 17, 2014 at 6:58 PM, Bálint Réczey <[email protected]> wrote: > 2014-04-17 23:21 GMT+02:00 Evan Huus <[email protected]>: >> On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman >> <[email protected]> wrote: >>> >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] 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 <[email protected]>: >>>> 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 <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
