Re: [Wireshark-dev] Wireshark LTS branches
Hi Gerald, 2014-04-17 1:59 GMT+02:00 Gerald Combs ger...@wireshark.org: 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. Cheers, Balint ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark LTS branches
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] 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 ger...@wireshark.org: 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. Cheers, Balint 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. 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? Best regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] [BMR #93974] ipmi-trace dissector
Hello, Wireshark team, I would like to submit a patch which adds dissector for IPMI packet trace collection capture format, which is produced by the Pigeon Point System's ipmb_traced utility. I believe that this patch will be helpful. The DLT_ type for the capture data format is not yet assigned, but the request for assignment is in progress. Correspondingly, I ask for WTAP_ENCAP_IPMI_TRACE encapsulation format reservation from you. In the meantime, the patch utilizes the first unassigned DLT_ and WTAP_ENCAP_ values. They are going to be replaced with the actual values as the responses are going to come. The IPMI trace dissector significantly re-uses the existing IPMI dissector. The latter was revised in order to support more messaging channel protocol formats (KCS, Tmode) and simultaneous capturing from several channels. Also, the IPMI dissector's request/response logic was revised to support more options like matching the double bridged embedded messages, and embedded messages in the Get Message command responses. Change-Id: Ib269b35784c0b70892d1e0111bcfb483ea64092c Please, review. With regards, Dmitry Bazhenov ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] adding units
Message: 5 Date: Wed, 16 Apr 2014 08:59:46 + From: Anders Broman anders.bro...@ericsson.com To: Developer support list for Wireshark wireshark-dev@wireshark.org Subject: Re: [Wireshark-dev] adding units Message-ID: 43c5658ba3fb7b48a6f38eed0b6253f11a969...@esessmb105.ericsson.se Content-Type: text/plain; charset=us-ascii I'm tinkering with the 1.10.6 source code You should be doing it on trunk if you are planning to commit to gerrit as this is new functionality. My group is just now starting to convert to Subversion!, so I maintain a separate repository with a baseline from the latest release of 1.10.6 for development of the dissector plugin. Well, it's a step up from Visual SourceSafe. The reason is that management for this project desired a stable API and codebase to develop the dissector. and I'm wondering if there's any opinions about the position and placement of units when using the different 'display' enumerations. : case BASE_DEC_HEX: : } case BASE_HEX_DEC: eturn format; Both these format should probably be treated as BASE_HEX, I can't think of a case where something expressed in units would need a HEX representation. I would think the prime usage for BASE_HEX, BASE_DEC_HEX and BASE_HEX_DEC is when a standard document expresses IEs or Messages in HEX to ease comparison with the standard document. I thought about it and tend to agree with your assessment. I ended up not populating any unit strings when HEX is in the display type. It made the implementation a bit simpler too. I have something that seems to work for the use cases that I have header fields for, but it's based on 1.10.6 instead of trunk. I checked out the latest version out of git, and it appears that the API has changed enough that I'd have to adapt where the changes are made, so is it worth posting/submitting the proto.c file based on 1.10.6 (to pastebin perhaps)? I'd eventually get around to adapting it for the latest wireshark, but it's kind of out of my scope of work at this time, so I don't know when exactly that I'd get to it. And trying to add a scale factor may change things since I need to merge that in and it'll probably end up in the 'strings' location. Thanks, John Dill winmail.dat___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] TCP dissector design
I have a closed network system where there are several TCP conversations
that transmit the same kind of data, but use different application layer
messages structures. It seems to be based on the age of the code,
where TCP conversations from older code use a different application
message structure (with different headers) than newer ones.
They would like to be able to see all the data fields under the same
protocol, whether the message came from a UDP packet or TCP packet.
However, I'm a bit confused as to how to structure the dissector to
be able to handle this properly.
For the UDP, I have a top level dissector that uses an heuristic to
receive all UDP packets and discover which of these UDP messages are
the protocol's application messages. I represent the protocol with
the acronym as XYZ.
\code snippet
static void xyz_dissect_app_msg_fmt1(tvbuff_t *tvb, packet_info *pinfo, gint
offset, proto_tree *tree);
static void xyz_dissect_app_msg_fmt2(tvbuff_t *tvb, packet_info *pinfo, gint
offset, proto_tree *tree);
/* Forward declare the XYZ message sub-dissectors to handle each Message ID. */
static void dissect_xyz_message1(tvbuff_t *tvb, gint offset, proto_tree *tree);
...
static void dissect_xyz_messageN(tvbuff_t *tvb, gint offset, proto_tree *tree);
[There is a switch table in each app_msg_fmt dissector that calls
the appropriate message subdissector based on an id.]
/* Forward declare the hand-off registration. */
void proto_register_xyz(void);
void proto_reg_handoff_xyz(void);
/* This is the main XYZ dissector that gets called for every UDP packet
because it is registered as a heuristic filter under the UDP protocol. */
static gboolean
dissect_xyz_udp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
...
if (tree)
{
if (msg_fmt == APPLICATION_MSG_FMT1) {
xyz_dissect_app_msg_fmt1(tvb, pinfo, offset, xyz_tree);
}
else if (msg_fmt == APPLICATION_MSG_FMT2) {
xyz_dissect_app_msg_fmt2(tvb, pinfo, offset, xyz_tree);
}
}
...
}
static gboolean
dissect_xyz_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void
*data)
{
return dissect_xyz_udp(tvb, pinfo, tree);
}
void proto_register_xyz(void)
{
static hf_register_info hf[] = ...
static gint *ett[] = ...
/* proto_register_protocol(name, short_name, abbreviation) */
proto_xyz = proto_register_protocol(XYZ Protocol,
XYZ,
xyz);
/* The macro 'array_length' calculates the number of elements of a
fixed-size array at the compile phase. */
proto_register_field_array(proto_xyz, hf, array_length(hf));
proto_register_subtree_array(ett, array_length(ett));
/* Register configuration options for the XYZ protocol dissector. */
{
module_t *xyz_module;
xyz_module = prefs_register_protocol(proto_xyz, proto_reg_handoff_xyz);
...
}
register_dissector(xyz, dissect_xyz_udp, proto_xyz);
}
void
proto_reg_handoff_xyz(void)
{
heur_dissector_add(udp, dissect_xyz_heur, proto_xyz);
}
\endcode
The TCP dissectors can be split up into three families (as far as I
know), where port family A uses the older application message
structure and port family B uses the new application message
structure, and one port C uses its own separate custom application
message format.
Ideally, they would like to see all the messages under one protocol
family 'XYZ', regardless of whether it came from a TCP or UDP packet.
All the TCP conversations require fragments to be assembled. Can
someone offer some advice on how to structure the dissector registration
so that I can handle the TCP messages in this scenario. Is there a
dissector already developed that kind of matches this scenario that
I can glean some ideas from?
Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissector design
Hi
Not in general by the distinction of the different protocol versions, but
you could take a glance at the openSAFETY dissector, which basically
supports a variant of transport layers and a heuristic to determine the
possition of the packages in each transport layer.
If you take a look at it with one of the capture samples from the wireshark
wiki, you'll see, that udp and fieldbus messages get mixed together to
present one singular dissector information.
My distinction of openSAFETY / UDP only exists to ease reading the protocol.
regards,
Roland
On Thu, Apr 17, 2014 at 8:48 PM, John Dill john.d...@greenfieldeng.comwrote:
I have a closed network system where there are several TCP conversations
that transmit the same kind of data, but use different application layer
messages structures. It seems to be based on the age of the code,
where TCP conversations from older code use a different application
message structure (with different headers) than newer ones.
They would like to be able to see all the data fields under the same
protocol, whether the message came from a UDP packet or TCP packet.
However, I'm a bit confused as to how to structure the dissector to
be able to handle this properly.
For the UDP, I have a top level dissector that uses an heuristic to
receive all UDP packets and discover which of these UDP messages are
the protocol's application messages. I represent the protocol with
the acronym as XYZ.
\code snippet
static void xyz_dissect_app_msg_fmt1(tvbuff_t *tvb, packet_info *pinfo,
gint offset, proto_tree *tree);
static void xyz_dissect_app_msg_fmt2(tvbuff_t *tvb, packet_info *pinfo,
gint offset, proto_tree *tree);
/* Forward declare the XYZ message sub-dissectors to handle each Message
ID. */
static void dissect_xyz_message1(tvbuff_t *tvb, gint offset, proto_tree
*tree);
...
static void dissect_xyz_messageN(tvbuff_t *tvb, gint offset, proto_tree
*tree);
[There is a switch table in each app_msg_fmt dissector that calls
the appropriate message subdissector based on an id.]
/* Forward declare the hand-off registration. */
void proto_register_xyz(void);
void proto_reg_handoff_xyz(void);
/* This is the main XYZ dissector that gets called for every UDP packet
because it is registered as a heuristic filter under the UDP protocol.
*/
static gboolean
dissect_xyz_udp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
...
if (tree)
{
if (msg_fmt == APPLICATION_MSG_FMT1) {
xyz_dissect_app_msg_fmt1(tvb, pinfo, offset, xyz_tree);
}
else if (msg_fmt == APPLICATION_MSG_FMT2) {
xyz_dissect_app_msg_fmt2(tvb, pinfo, offset, xyz_tree);
}
}
...
}
static gboolean
dissect_xyz_heur(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, void
*data)
{
return dissect_xyz_udp(tvb, pinfo, tree);
}
void proto_register_xyz(void)
{
static hf_register_info hf[] = ...
static gint *ett[] = ...
/* proto_register_protocol(name, short_name, abbreviation) */
proto_xyz = proto_register_protocol(XYZ Protocol,
XYZ,
xyz);
/* The macro 'array_length' calculates the number of elements of a
fixed-size array at the compile phase. */
proto_register_field_array(proto_xyz, hf, array_length(hf));
proto_register_subtree_array(ett, array_length(ett));
/* Register configuration options for the XYZ protocol dissector. */
{
module_t *xyz_module;
xyz_module = prefs_register_protocol(proto_xyz, proto_reg_handoff_xyz);
...
}
register_dissector(xyz, dissect_xyz_udp, proto_xyz);
}
void
proto_reg_handoff_xyz(void)
{
heur_dissector_add(udp, dissect_xyz_heur, proto_xyz);
}
\endcode
The TCP dissectors can be split up into three families (as far as I
know), where port family A uses the older application message
structure and port family B uses the new application message
structure, and one port C uses its own separate custom application
message format.
Ideally, they would like to see all the messages under one protocol
family 'XYZ', regardless of whether it came from a TCP or UDP packet.
All the TCP conversations require fragments to be assembled. Can
someone offer some advice on how to structure the dissector registration
so that I can handle the TCP messages in this scenario. Is there a
dissector already developed that kind of matches this scenario that
I can glean some ideas from?
Thanks,
John Dill
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org
?subject=unsubscribe
___
Sent via:Wireshark-dev mailing
[Wireshark-dev] Mac compilation broken
Hi Just filed bug #1 ;-). Mac compilation is broken, due to 'extern' variable has an initializer See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1 for compile output. regards, Roland ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Mac compilation broken
Congratulations Roland! You have just won yourself a free copy of Wireshark on the platform of your choice. Just go to http://www.wireshark.org/download.html to claim your prize and enter Bug1 in the checkout screen. (Wait... maybe I shouldn't give out the free copy checkout code to the whole -dev list, then lots of people will end up with free copies of Wireshark) -Original Message- From: Roland Knall rkn...@gmail.com To: Developer support list for Wireshark wireshark-dev@wireshark.org Sent: Thu, Apr 17, 2014 3:53 pm Subject: [Wireshark-dev] Mac compilation broken Hi Just filed bug #1 ;-). Mac compilation is broken, due to 'extern' variable has an initializer See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1 for compile output. regards, Roland ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Mac compilation broken
I've also got the 404th entry on gerrit. Not so much fun as 1, but still. ;-) regards, Roland On Thu, Apr 17, 2014 at 10:17 PM, mman...@netscape.net wrote: Congratulations Roland! You have just won yourself a free copy of Wireshark on the platform of your choice. Just go to http://www.wireshark.org/download.html to claim your prize and enter Bug1 in the checkout screen. (Wait... maybe I shouldn't give out the free copy checkout code to the whole -dev list, then lots of people will end up with free copies of Wireshark) -Original Message- From: Roland Knall rkn...@gmail.com To: Developer support list for Wireshark wireshark-dev@wireshark.org Sent: Thu, Apr 17, 2014 3:53 pm Subject: [Wireshark-dev] Mac compilation broken Hi Just filed bug #1 ;-). Mac compilation is broken, due to 'extern' variable has an initializer See https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1 for compile output. regards, Roland ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark LTS branches
On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman anders.bro...@ericsson.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] 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 ger...@wireshark.org: 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. Cheers, Balint 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? Best regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
[Wireshark-dev] AsciiDoc Transition
Is the AsciiDoc WIP change at https://code.wireshark.org/review/#/c/9/ still active or should it be abandoned? It's seen no uploads in 2 months... Evan ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Mac compilation broken
On Apr 17, 2014, at 12:51 PM, Roland Knall rkn...@gmail.com wrote: Just filed bug #1 ;-). Mac compilation is broken, due to 'extern' variable has an initializer Fixed in I7eb98963a6d2e1bc9f869ebce3d7ba9228b6c9e4. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark LTS branches
2014-04-17 23:21 GMT+02:00 Evan Huus eapa...@gmail.com: On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman anders.bro...@ericsson.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] 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 ger...@wireshark.org: 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. Ubuntu usually syncs security updates without changes from Debian.
Re: [Wireshark-dev] Wireshark LTS branches
On Thu, Apr 17, 2014 at 6:58 PM, Bálint Réczey bal...@balintreczey.hu wrote: 2014-04-17 23:21 GMT+02:00 Evan Huus eapa...@gmail.com: On Thu, Apr 17, 2014 at 4:23 AM, Anders Broman anders.bro...@ericsson.com wrote: -Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-boun...@wireshark.org] 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 ger...@wireshark.org: 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
Re: [Wireshark-dev] Wireshark LTS branches
On Apr 17, 2014, at 3:58 PM, Bálint Réczey bal...@balintreczey.hu 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. 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. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
