[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

On Thu, Jun 23, 2016 at 9:36 AM, Christopher Maynard <Christopher.Maynard@xxxxxxx> wrote:

I don't recall what support policy, if any, was decided regarding the
various distributions, but I believe at least one commit
(https://code.wireshark.org/review/#/c/14041/) was reverted due to the
adverse affect of breaking Wireshark builds on RHEL6.

Now that RHEL6 has reached the end of production phase 1[1], I don't know if
we want to move forward with that patch (or other patches?).  I don't follow
other distributions that closely and don't know what versions of the various
packages they supply, so while I think it would be reasonable to no longer
worry about supporting RHEL6, perhaps there are other distributions that
would be the new bottleneck?

Actually it appears that change was not reverted.  RHEL 6 (and, from what Anders was telling me, SLES 11) users must now manually install autoconf if they want to build from git or otherwise need to run autoconf/automake.

At Sharkfest I updated our upstream tracking page:

https://wiki.wireshark.org/Development/Support_library_version_tracking

to indicate the release and EOS dates for both RHEL and SLES--but in the case of the former I used the end of production phase 3 dates (which seems a more realistic measure of when one can reasonably expect people to actually stop using the release).

It's not a written policy but in general I've tried to look at/question the cost-benefit analysis whenever we risk losing a large class of users like those on RHEL or SLES.  I'd hate to lose/annoy the users--or force them to run Wireshark on Windows. ;-)  I think a general policy of not losing a class of users without good cause is a reasonable one.