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 <[email protected]> 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 >
