Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3EECB7C8.90805@apache.org>
Date: Sun, 15 Jun 2003 13:15:36 -0500
From: Stefano Mazzocchi <stefano@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
 rv:1.3.1) Gecko/20030425
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: FOM blocking 2.1 release
References: <bcg7h2$i1q$1@main.gmane.org> <3EEC5BB4.5060103@outerthought.org>
In-Reply-To: <3EEC5BB4.5060103@outerthought.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

on 6/15/03 6:42 AM Steven Noels wrote:

> On 15/06/2003 0:31 Stefano Mazzocchi wrote:
> 
> 
>> 1) I will try to patch the FOM for the proposed plan for June 24th.
>>
>> 2) If I can't do it, we release with what we have and we state loud and
>>clear that the FOM contract should be considered unstable and that might
>>change in future releases.
> 
> 
> Just some quick thoughts out the top of my head:
> 
> I don't understand the intention of your mail subject. What do I mean: I 
> don't see FOM blocking any release, I just see FOM not being ready yet, 
> partly caused by the small amount of people being involved in it ATM 
> (neutral observation).
> 
> It has been our own decision to consider a stable FOM as being part of a 
> 2.1 release. Or we change that decision, or we release later. From what 
> I hear, quite a few people find flow to be the quantum leap for Cocoon, 
> and 2.1 seems like a good release version to indicate this to the world.
> 
> Some people think we should ship 2.1 before summer, even though FOM will 
> be marked as a transient thing. Others don't mind a stable 2.1, and can 
> still live with the Milestone thing. Personally, I find shipping 
> instable foundations for what is being regarded as the New Great Thing a 
> dangerous thing, but then again I don't mind waiting for another couple 
> of months.

I totally resonate with this: flow, IMHO, *is* the big thing for Cocoon
2.1 and coming out with a beta contract on such an important piece is a
big mistake.

At the same time, I think that there has been enough discussion and
first-hand implementation on the FOM to understand patterns of design
that can help us bring the contract forward.

Ovidiu wrote the FOM with "let's cover everything" mindset. He restated
the fact that he likes this approach better on his last mail to this list.

The problem I have with this approach is that *NO* part of Cocoon has
been designed like this, but rather with more XP-like approaches of
"start small and grow with needs, questioning them everytime".

As a parallel, if we were to design the sitemap markup with "let's cover
all possible usecases" mindset, we would have dynamic pipelines and we
would not have flow today, but just a completely complex and
procedural-like markup that would look like a programming language and
would be hated by most.

What I want for the FOM is the *same* evolutionary paradigm and this is
not possible with what we have today because it already covers stuff
that should not be covered and will potentially have to be deprecated as
we go.

So, instead of starting with all and deprecate what we consider harmful,
I would like to start small and add those things that were missing in
the beginning (or were left out because unsure, awaiting for community
feedback).

So, I would be -1 to release Cocoon 2.1 final with the current FOM
because it's asking for contract evolutionary trouble.

Or we can release 2.1 with the current flow marked as "unstable
contract" and release 2.2 shortly after with a more stabilized FOM and
postpone "real blocks" for 2.3.

As I said, I'll try to patch the FOM before the 24th so that we can go
beta without contract evolution issues. But since I have two congress
presentations to prepare in the meanwhile, I can't guarantee you anything.

> So, my question is: what do people _want_ to see finished in 2.1? FOM? 
> New portal FW? Form FW consolidation? Anything else?
> 
> I'm just curious, really.

FOM is part of the core. all you list are blocks and I don't care about
contract solidity of blocks as much as I care about the contract
solidity of core stuff. This is why I'm so concerned about this.

-- 
Stefano.