Date: Sat, 10 May 2014 00:26:36 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: <marino@freebsd.org>, "Doug Ambrisko" <ambrisko@ambrisko.com> Cc: freebsd-ports@freebsd.org Subject: Re: Unable to use ports on 8.3 or earlier since r352986 Message-ID: <EC9A150072C94C44BA7C20D396B52B2E@multiplay.co.uk> References: <495738D66545411BA78B31A6615EFA48@multiplay.co.uk> <CAHcXP%2BcyLKCXejUT=A9sGnwGQ-0KfG2VLnzEd79KBGy238=jzQ@mail.gmail.com> <EDCDD12BB5FA4EACA2A91C4A108CAD5C@multiplay.co.uk> <536D05E6.10905@marino.st> <20140509202212.GA39777@ambrisko.com> <536D3E7E.6070209@marino.st>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "John Marino" <freebsd.contact@marino.st>
> On 5/9/2014 22:22, Doug Ambrisko wrote:
>> On Fri, May 09, 2014 at 06:44:22PM +0200, John Marino wrote:
>> | I'll stress the previous point again. The change that broke this was
>> | desired 8 months ago. It was applied as soon as it was legal to do so.
>>
>> FYI, because some might be legal doesn't necessarily make it in the
>> best interest of users.
>
> It should be obvious that nobody breaks trees intentionally for fun.
> It's done in the overall best interest of users.
That said based soley on the change log this compatibility removal did seem
to be done with no clear benefit appart from removing an old compat shims,
yes its nice to remove old hacks when they aren't needed any more, but
if they aren't causing any problems when leaving it for users to catch
up is a good thing to consider.
Don't get me wrong, progress is definitely good, but if this was done just
to remove old hacks like the commit message indicated then it would be
nice for users if it was delayed until required so to speak.
>> | Anyone who knowingly chose not migrate off before the EOL pretty much is
>> | getting a lesson about why that was an unwise decision. That lesson is
>> | not specific to FreeBSD.
>>
>> There are company's that use FreeBSD as a basis of their product and can't
>> move quickly and when they move tend to move in big steps. Doing a QA
>> of a complete OS is expensive and will turn up unknown new problems and
>> yes fix some as well. However, when you have a large installed base
>> that is a big risk. So rather then track an 8 -stable release it makes
>> more sense to focus to co-ordinate a move to 9 release and 10 release.
>> Once we pick a X.Y release we stick to it and back changes until we
>> go to a X+1 release. Depending on SW requirements a newer port might
>> be required. Also some company's depend on 3rd party binary SDK's. We
>> have binaries running on "unsupported" OS versions but with newer OS kernels.
>
> If these companies are going to ignore EOL at their own risk, then they
> can simply freeze the ports tree and then cherry pick and modify as
> needed. The release is unsupported. The timeline is published years in
> advance, so there is no one to blame. If a company's lifeblood is based
> on unsupported releases, I hope they have post-EOL plans.
Users will achnowledge that, and can make their own plans as mentioned,
however its not usually expected for the ports tree to become instantly
unusable after release EOL.
>> The company that I work for is not currently impacted by this but we
>> might if we have to grab a newer port for an older release of FreeBSD.
>>
>> | > Users may well be quite happy to port the small number of OS security fixes
>> | > until they have completed their upgrades, I know thats something we plan to
>> | > do here. Ports on the other hand is a different matter, as the number of
>> | > fixes / changes is much higher so makes it impractical.
>> |
>> | They were supposed to have completed their upgrades prior to the EOL.
>>
>> It that along the lines of saying that FreeBSD will stop running 4.x
>> binaries since FreeBSD 4 is not longer supported? That is a value I
>> find good with FreeBSD that it is some what easy to do ... to make it
>> work well I have some rtld patches that deal with ports library conflicts
>> of name/version.
>
> No, it's along the lines of saying don't update the ports tree after the
> release is EOL'd.
That's not exactly practical now is it. Some issues are to be expected but
in general the ports tree has been eminently useable way after EOL for previous
releases, so without any indication otherwise its going to come as a shock
to users.
> There is always the option of moving to pkgsrc - although doing so is
> more disruptive than simply upgrading to release 8.4.
Moving to 8.4 is likely a waste of time for most, I know we're moving directly
to 10 but with the number of changes that require retooling its taking us longer
than expected. Don't forget its only been out 5 months, which isn't very long in
the grand scheme of things.
>> | > One example that springs to mind is the release version of pfsense is still
>> | > 8.3 so being to still compile updated ports with fixes for that is very
>> | > useful.
>> |
>> | I don't know anything about pfsense, or why it needs to compile ports,
>> | but I think you should asked them why they haven't had a release prior
>> | to 8.3 EOL. That's probably an excellent question.
>>
>> Maybe they are spending their limited resources on a 10.1 release?
>>
>> The point people are raising is that this is breaking things for them
>> with no easy migration plan except an OS redo of which they might not
>> have time to qualify to deploy. So then they thing is it time to switch
>> to a different OS?
>
> They didn't get caught with their pants down. Anyone in a bad spot is
> here as a result of poor planning and switching the OS isn't going to
> solve that problem. And the length of time FreeBSD provides release
> support as competitive with just about gratis OS, is it not?
But the point still remains that if we're nice to users and maintain
compatibility, where it doesn't cause us pain, then they are more
likely to continue to use FreeBSD in the future.
It comes back to is the change really needed right now?
If so I'd be interested to why, out of genuine curiosity?
P.S. Don't shoot the messenger :D
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EC9A150072C94C44BA7C20D396B52B2E>