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

[ejc <eric.j.christeson@xxxxxxxxx>]

--bcaec50162e3ae78c704da8ff515
Content-Type: text/plain; charset=UTF-8

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@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
>

--bcaec50162e3ae78c704da8ff515
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As one who moved from i386 hardware to x86_64 about 2=
 weeks ago, I&#39;d vote for option 2; Declare Release 3.4 last release for=
 i386 but fix serious bugs until end of 2014.=C2=A0 The Dell OptiPlex gx270=
 I retired is circa 2004 -- 9 years ago.=C2=A0 There is getting to be less =
and less non-x86_64 hardware out there=C2=A0 And I hold onto stuff for a lo=
ng time.=C2=A0 I got rid of my last G4 mac and a couple of Athlon T-bird bo=
xes about a year ago.=C2=A0 If anyone should be sad to see i386 go, it&#39;=
s me and I&#39;m not sad :-)<br>
<br></div>Thanks,<br>Eric <br></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Wed, Apr 17, 2013 at 6:15 AM, John Marino <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:dragonflybsd@marino.st"; target=3D"_blank">=
dragonflybsd@marino.st</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">The topic of how to cease i386 platform supp=
ort has been discussed ad nauseam on the #dragonflybsd IRC channel. =C2=A0I=
 promised to post something on the mail lists as we got closer to 3.4 relea=
se. =C2=A0I hope that we reach a conclusion rather than devolve into a neve=
r-ending and frustrating discussion.<br>

<br>
For the purposes of discussion, assume that the EOL of the i386 platform wi=
ll happen. =C2=A0It&#39;s a question of &quot;when&quot; and &quot;how&quot=
;, not &quot;if&quot;. =C2=A0Also, for the initial discussion&#39;s sake, l=
et assume that EOL is defined as 31 December, 2014, approximately 19 months=
 from now.<br>

<br>
There are two schools of thought on the method of achieving the dropping of=
 support for i386:<br>
<br>
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). =
=C2=A0One day it&#39;s fully supported, the next day it&#39;s not supported=
 at all.<br>

<br>
2) Declare Release 3.4 as the last release for i386 but pledge to fix serio=
us bugs and panics until the end of 2014. =C2=A0Currently a release is only=
 supported for about 6 months, so this would make Release 3.4 a kind of &qu=
ot;Long-Term Support&quot; release. =C2=A0It would also receive periodic pa=
ckage updates until EOL.<br>

<br>
My bias is towards approach #2. =C2=A0From the perspective of a user, if th=
eir (older) box cpu is limited to the i386 architecture, then having extend=
ed support is probably more attractive than having the latest DragonFly tec=
hnology. =C2=A0From a developer point of view, it means a 50% decrease of s=
upport in some areas, including the architecture specific algorithms in the=
 kernel. =C2=A0Personally I&#39;m also thinking about package building, non=
-base compiler bootstrapping, image building and mirroring, etc. =C2=A0This=
 can free up time to make the x86_64 platform better faster.<br>

<br>
The main benefit to approach #1 is that Long Term Support can be avoided, w=
hich is primarily a benefit to (some) developers. =C2=A0That is, it&#39;s e=
asier to maintain a status quo than to fix bugs in a 1.5 year old release. =
=C2=A0The benefit to users is that the last release of DragonFly for i386 w=
ould be more advanced than DragonFly 3.4, with the downside that it would a=
lso be unsupported (aka completely as-is, use at your own risk)<br>

<br>
I believe that Release 3.4 will be a very good, stable release, and a worth=
y release to serve as a send-off for i386. =C2=A0It&#39;s easily been the m=
ost stable version of DragonFly I&#39;ve run, so I can imagine that serious=
 bug-fix support won&#39;t be that taxing.<br>

<br>
Anyway, the Project decisions I&#39;d like to get out of this discussion wi=
th relatively little bloodshed is:<br>
<br>
1) Agreement on the EOL date (or Release if it&#39;s pegged to a release)<b=
r>
2) A declaration of which road map will be used (method #1 or #2)<br>
<br>
I know some people might be tempted to argue to try to &quot;save&quot; the=
 platform, but I think it&#39;s inevitable that it will be contracted. Agai=
n, I think it&#39;s merely a question of when and how base on these IRC dis=
cussions.<span class=3D"HOEnZb"><font color=3D"#888888"><br>

<br>
John<br>
</font></span></blockquote></div><br></div>

--bcaec50162e3ae78c704da8ff515--