Change to README ought to be reverted

[Christoph Otto]

On Tue, 26 Jul 2011 22:19 -0700, "jerry gay" <jerry.gay at gmail.com>
wrote:
> On Tue, Jul 26, 2011 at 19:27, Moritz Lenz <moritz at faui2k3.org> wrote:
> > On 07/27/2011 02:33 AM, James E Keenan wrote:
> >> I object to this change for two reasons.
> >>
> >> First, on one platform I use, Parrot does not PASS 'make test' when I
> >> configure with '--optimize'.
> >
> > So there's a bug, and it must be fixed. If the fix isn't easy, I'm fine
> > with documenting the lack of '--optimize' as a workaround for that platform.
> > I don't see why a platform-specific bug should mean we should recommend
> > our users a slow parrot by default. I don't think slow-by-default does
> > parrot any good. I'd go so far as to actually make --optimize the
> > default for Configure.pl.
> >
> >> Second, I think a change in our README about how our users ought to
> >> start out building Parrot really warrants more discussion than what
> >> little I could find on #parrot today.
> >
> > I don't see how the need for more discussion should prevent a gradual
> > improvement.
> >
> >> It appears to have been a
> >> spur-of-the-moment decision.  I think this should have been a Trac
> >> ticket with type RFC.
> >>
> >> I would really like to see this reverted until we can discuss it more
> >> thoroughly.
> >
> > If you feel strongly, feel free to revert that commit, but as I argued
> > above, I can't see the reason behind either of your points.
> >
> if, as you argue, it should be the default, why must it be specified
> as an option?
> 
> parrot users deserve better; parrot developers should do work with
> users in mind rather than asking them to do it. don't make users
> deviate from the norm in order to get normal behavior.
> 
> ~jerry

I strongly agree with the sentiment here.  If an optimized Parrot is
broken on
a platform, we need to fix that bug.  kid51++ mentioned the test in
question is
tt #1930.  Unfortunately Darwin/PCC, where the test fails, is becoming a
rare
platform, but if we want to call it "supported", we need to fix it.

I also want users to get the best possible Parrot without requiring them
to
know to pass --optimize to Configure.pl.  It makes sense for a git clone
not to
be optimized by default because it's more likely to be broken and in
need of
debugging (which optimization makes harder).  As an alternative, I
propose that
we make all release tarballs build with optimizations enabled by
default.  This
would mean we'll need more emphasis on testing optimized Parrots in the
week
before a release, but I don't think this will pose a meaningful
difficulty.

Thanks,
Christoph