On Thu, Jun 23, 2016 at 9:36 AM, Christopher Maynard < [email protected]> 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.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
