Bart Smaalders wrote:
> Joseph Kowalski wrote:
>> Garrett D'Amore wrote:
>>> I never said that I believed that they didn't. But it was the
>>> presumption of the earlier mail from someone else (Joe?) that I was
>>> commenting on.
>> That was me, prompted by the /usr/gnu/bin:/usr/bin observation about
>> Indiana (from Alan?).
>>
>> I **strongly** believe that some things need to be reviewed
>> pre-Preview and this is one of them. We all know that Previews
>> (incl. Solaris Express) have some funny guarantees. We've had this
>> discussion in the Solaris Express context a couple of times already.
>>
>> Let's just forget the rules, and play what if...
>>
>> Indiana ships with the alternate gnu personality by default.
>>
>> PSARC/whoever says "NO".
>>
>> Somebody (perhaps Indiana users? perhaps other users? perhaps ???)
>> will be very unhappy. Expectations are being set.
>>
>> This class of expectations is the "train wreck" I was referring to -
>> not a general Indiana vs process issue.
>
> Now you feel that PSARC should be involved before a preview are done, so
> that expectations are not raised/dashed w/o appropriate review? Should
> you also vet our discussions on opensolaris aliases so those
> would not set any expectations that would not meet w/ PSARC approval?
>
> Indiana is a prototype. Things are going to change. It's going to be
> different.
>
> Innovation requires experimentation. Experimentation implies both
> positive and
> negative outcomes; we aim to learn from our mistakes and share the
> experience
> with the world during development. This means that we _will_ try
> something that
> doesn't make it into the finished product for one reason or another.
> That's ok.
>
> It's a prototype.
Prototyping is *good*.
But so is design review. I don't think anyone here is suggesting that
the design team needs to come up with a fully fleshed out design, and
present it for full review and voting, before a prototype can ship.
Rather, the suggestion here is to offer an inception review, which
allows PSARC to get some early familiarity with the project, and also
raise any possible questions or concerns at a time when the project team
still has the option to adapt to that feedback.
Is there some reason the project team feels they need to wait to come to
ARC?
"ARC early, ARC often."
-- Garrett
