Selection of roadmap for i386 platform End-of-Life (EOL)

[ejc]

As one who moved from i386 hardware to x86_64 about 2 weeks ago, I'd vote
for option 2; Declare Release 3.4 last release for i386 but fix serious
bugs until end of 2014.  The Dell OptiPlex gx270 I retired is circa 2004 --
9 years ago.  There is getting to be less and less non-x86_64 hardware out
there  And I hold onto stuff for a long time.  I got rid of my last G4 mac
and a couple of Athlon T-bird boxes about a year ago.  If anyone should be
sad to see i386 go, it's me and I'm not sad :-)

Thanks,
Eric


On Wed, Apr 17, 2013 at 6:15 AM, John Marino <dragonflybsd at marino.st> wrote:

> The topic of how to cease i386 platform support has been discussed ad
> nauseam on the #dragonflybsd IRC channel.  I promised to post something on
> the mail lists as we got closer to 3.4 release.  I hope that we reach a
> conclusion rather than devolve into a never-ending and frustrating
> discussion.
>
> For the purposes of discussion, assume that the EOL of the i386 platform
> will happen.  It's a question of "when" and "how", not "if".  Also, for the
> initial discussion's sake, let assume that EOL is defined as 31 December,
> 2014, approximately 19 months from now.
>
> There are two schools of thought on the method of achieving the dropping
> of support for i386:
>
> 1) Continue supporting i386 as usual for 3 more releases (e.g. 3.6, 3.8,
> 3.10) and then drop support completely (e.g. no new bug reports accepted).
>  One day it's fully supported, the next day it's not supported at all.
>
> 2) Declare Release 3.4 as the last release for i386 but pledge to fix
> serious bugs and panics until the end of 2014.  Currently a release is only
> supported for about 6 months, so this would make Release 3.4 a kind of
> "Long-Term Support" release.  It would also receive periodic package
> updates until EOL.
>
> My bias is towards approach #2.  From the perspective of a user, if their
> (older) box cpu is limited to the i386 architecture, then having extended
> support is probably more attractive than having the latest DragonFly
> technology.  From a developer point of view, it means a 50% decrease of
> support in some areas, including the architecture specific algorithms in
> the kernel.  Personally I'm also thinking about package building, non-base
> compiler bootstrapping, image building and mirroring, etc.  This can free
> up time to make the x86_64 platform better faster.
>
> The main benefit to approach #1 is that Long Term Support can be avoided,
> which is primarily a benefit to (some) developers.  That is, it's easier to
> maintain a status quo than to fix bugs in a 1.5 year old release.  The
> benefit to users is that the last release of DragonFly for i386 would be
> more advanced than DragonFly 3.4, with the downside that it would also be
> unsupported (aka completely as-is, use at your own risk)
>
> I believe that Release 3.4 will be a very good, stable release, and a
> worthy release to serve as a send-off for i386.  It's easily been the most
> stable version of DragonFly I've run, so I can imagine that serious bug-fix
> support won't be that taxing.
>
> Anyway, the Project decisions I'd like to get out of this discussion with
> relatively little bloodshed is:
>
> 1) Agreement on the EOL date (or Release if it's pegged to a release)
> 2) A declaration of which road map will be used (method #1 or #2)
>
> I know some people might be tempted to argue to try to "save" the
> platform, but I think it's inevitable that it will be contracted. Again, I
> think it's merely a question of when and how base on these IRC discussions.
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20130417/aa105aac/attachment-0002.html>