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

[John Marino <dragonflybsd@xxxxxxxxx>]

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