Draft Product Description for Fedora Workstation

[Josh Boyer]

On Wed, Nov 6, 2013 at 2:38 PM, Adam Williamson <awilliam at redhat.com> wrote:
> On Wed, 2013-11-06 at 13:24 -0500, Josh Boyer wrote:
>> On Tue, Nov 5, 2013 at 3:56 PM, Adam Williamson <awilliam at redhat.com> wrote:
>> > In this situation what we should do is carefully consider the relative
>> > possibilities of the good, bad and mixed outcomes with as much precision
>> > as we can, and try to come up with a path forward which makes the
>> > likelihood of a good outcome as high as possible and the likelihood of a
>> > bad outcome as low as possible. "Let's just try it and see what
>> > happens!" is not a mature approach to risk management.
>>
>> I'm asking this question genuinely and not sarcastically.
>>
>> Isn't that very "let's try it and see what happens!" approach exactly
>> what we're doing with Fedora.next?  It seems to me we've forged ahead
>
> Hoo boy, just when the thread was quieting down...
>
> I'm still slightly out of sync with the fedora.next stuff (REALLY picked
> a bad time to go on vacation), but it does seem to me that a decent
> amount of 'mature reflection' was done on it before it was approved, at
> least. And it does not appear to be irreversible at this point: we are
> still only at the point where a bunch of WGs are going away to come up
> with proposals for FESCo's review, yes? FESCo could ultimately still
> decide to shoot down the whole thing, or demand major changes, or delay
> it for any given amount of time? As I read the process, we are not
> irreversibly committed to any practical changes to any Fedora product at
> this point.

Sure.  That doesn't change that the risk is still there and that there
are lots of unknowns and will be ever after FESCo approves (or
rejects) the governance and PDRs for the WGs.  I suppose the point of
little return is Jan.  That doesn't mean that it's _not_ a somewhat
cavalier approach.

My point is, we're seriously considering changing Fedora as a whole
because it allows us to make certain things better.  So do app
containers, or containers in general.  So do a lot of other technical
things that could _possibly_ lead to some downsides.  I'm just
imploring people to stop screaming NO on these technical items before
they even get started.  I think we need a bit more of a bold approach
or we're going to be stuck where we are with other projects doing the
innovation people find interesting and useful.

josh