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

["Samuel J. Greear" <sjg@xxxxxxxxxxxx>]

--047d7b343300d7481704da94581e
Content-Type: text/plain; charset=ISO-8859-1

How about option #3, we declare 3.4 or 3.6 or (insert future release here)
the last release of i386 -- with the last release meaning we don't roll new
releases and no longer build packages for the platform.

Whoever is doing snapshots may at their option continue building snaps to
keep a second platform compile-tested. Folks updating software in base may
conditionalize new versions for only x86-64 if there is a conflict. Bug
reports may still be accepted against the i386 platform, but will not be
given high priority (no i386 bug report will ever possibly be a release
blocker, since we won't be rolling releases of i386). i386 can continue to
limp on in a neutered fashion if only to help enforce portability
abstractions.

As soon as someone cooks up some kernel changes that are not easily
adaptable to i386 (such as requiring use of the DMAP) then the i386
platform can be removed.

Sam


On Wed, Apr 17, 2013 at 5: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
>

--047d7b343300d7481704da94581e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">How about option #3, we declare 3.4 or 3.6 or (insert futu=
re release here) the last release of i386 -- with the last release meaning =
we don&#39;t roll new releases and no longer build packages for the platfor=
m.<div>
<br></div><div style>Whoever is doing snapshots may at their option continu=
e building snaps to keep a second platform compile-tested. Folks updating s=
oftware in base may conditionalize new versions for only x86-64 if there is=
 a conflict. Bug reports may still be accepted against the i386 platform, b=
ut will not be given high priority (no i386 bug report will ever possibly b=
e a release blocker, since we won&#39;t be rolling releases of i386). i386 =
can continue to limp on in a neutered fashion if only to help enforce porta=
bility abstractions.</div>
<div style><br></div><div style>As soon as someone cooks up some kernel cha=
nges that are not easily adaptable to i386 (such as requiring use of the DM=
AP) then the i386 platform can be removed.</div><div style><br></div><div s=
tyle>
Sam</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">On Wed, Apr 17, 2013 at 5:15 AM, John Marino <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:dragonflybsd@marino.st"; target=3D"_blank">dragonflybsd@marino.s=
t</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. =A0I pr=
omised to post something on the mail lists as we got closer to 3.4 release.=
 =A0I hope that we reach a conclusion rather than devolve into a never-endi=
ng and frustrating discussion.<br>

<br>
For the purposes of discussion, assume that the EOL of the i386 platform wi=
ll happen. =A0It&#39;s a question of &quot;when&quot; and &quot;how&quot;, =
not &quot;if&quot;. =A0Also, for the initial discussion&#39;s sake, let ass=
ume 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). =
=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. =A0Currently a release is only su=
pported for about 6 months, so this would make Release 3.4 a kind of &quot;=
Long-Term Support&quot; release. =A0It would also receive periodic package =
updates until EOL.<br>

<br>
My bias is towards approach #2. =A0From 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 techno=
logy. =A0From a developer point of view, it means a 50% decrease of support=
 in some areas, including the architecture specific algorithms in the kerne=
l. =A0Personally I&#39;m also thinking about package building, non-base com=
piler bootstrapping, image building and mirroring, etc. =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. =A0That is, it&#39;s easi=
er to maintain a status quo than to fix bugs in a 1.5 year old release. =A0=
The benefit to users is that the last release of DragonFly for i386 would b=
e more advanced than DragonFly 3.4, with the downside that it would also 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. =A0It&#39;s easily been the most=
 stable version of DragonFly I&#39;ve run, so I can imagine that serious bu=
g-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>

--047d7b343300d7481704da94581e--