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).
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]?
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.
