On 17/04/2013, at 9:15 PM, 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. I would like to see DragonflyBSD 4.0 to be the beginning of x86_64 only releases. With the above mentioned restructure (or optimisation) of the kernel, many ABIs & APIs will change and 4.0 provides a milestone for that. It could also mean that Hammer2 could be a headline feature of 4.0 - hopefully simplifying development. People will also be aware that releases prior to 4.0 DragonflyBSD will support both x86_64 & i386. Future releases of 3.x may add new features, but more importantly, provide some legacy users bug fixes and security updates. regards, Stephen Welker.
