cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject [RF] Entropy Killed the Cat
Date Mon, 10 Mar 2003 19:13:35 GMT
[not knowing if Ovidiu is still subscribed to this list, I'm copying him]

There are three things going on:

1) major build refactoring

2) contract solidification

3) transition to

All three things are related and aim to provide more solid foundation 
for the future of this project: technical foundation, legal foundation, 
usability foundation.

In this email I give you my very personal, no-string-attached, 
no-hat-on, random feelings on why entropy is killing our cat and why a 
rather rapid steer is required

                               - o -

But first, let me tell you one thing:


Of all mistakes I could possibly do in such a transition period, messing 
up with CVS has been the worst. I still can't figure out what I did 
wrong and managed to corrupt the history of our xml-cocoon2 CVS, but I 
did and I can't drive back.

                               - o -

Ok, now that you know that you'll never want to hire me for my sysadmin 
skills, let's keep going.

Carsten wrote:
> I'm not surprised that this is happening, but I'm still
> surprised by the ignorance and the "I don't care" mentalitiy.

I wonder why the build system and the samples were in such a bad shape 
if you knew already what was best to do and what would have happened.

> As a vital project we need two things: a) working samples and
> b) nightly builds - and both are not working right now; and 
> they are not working since some weeks now!


In case you didn't notice, we were able to run a clean gump compile on 
the cocoon core for the first time in the history of Gump.

> The new build system is fast (and much more cleaner), but it's
> not working; 

 From there I stand:

The core builds clean.
The build system is much more integrated with Gump (in fact, it even did 
a clean run a few days ago)
The blocks build clean.
You can remove each one of the block without breaking the build
You can build a minimal webapp.
You can make javadocs that link to all over javadocs.
You can generate documentation

All in a fraction of the time, without memory issues, in a fraction of 
the lines and with much better usability of properties (not perfect, I 
admit, but a much better step forward).

> so, let's be honest, what does it help if it's
> fast but not working? Would you drive a fast car that is not
> able drive backwards?

The things missing are:

- build a complete webapp with samples, documents and javadocs

- validation targets (but they require rethinking of the way 
configurations and sitemap are validated and integrated into the system)

- build the distribution (this will require another rethinking)

> Before the new build system was checked in, Stefano said, that 
> he wanted to add a new build system besides the existing one 
> and *when* the new one is working to switch. But unfortunately, 
> the old one was immediately replaced with the new one. And that 
> was really a bad idea.

Since it was impossible to refactor the build and do a serious 
block-ization without moving things around, the only way of doing it 
would have been to branch Cocoon.

I knew it was going to be painful but i didn't expect to take this long 
(I also didn't expect some small shit in my life, but that's none of 
your business)

> The next problem is that it seems that noone is able to help
> to get the samples working again. I asked last week, what
> I can to do help - but apart from "I'm stuck" there was
> no helpful answer. 
> And please: don't always say: "It's alpha". It's true, that
> we are officially in an alpha state and it's ok that new
> things are not working when they are checked in. Everyone
> makes mistakes of course, this includes myself, this includes
> Stefano and this includes every single committer. There is
> absolutely no exception to this rule!
> But, if something is not working, at least the committer
> checking in this part, should try to fix this problem as
> soon as possible. And if this is not possible, he should
> try to get help in order to fix the problem as soon
> as possible. But what you really never should do is,
> going down to your cave, saying "hey, it's alpha, so
> what do you expect?" and wait and wait and wait.

I will avoid reinjecting negative feelings into the loop here.

> Now, the last thing I want to say is: if YOU as a committer
> are not happy with something someone else did, please stand
> up and make your voice be heard! There are no "gods" that
> will kill you if you are against their opinion. 

This is what I've been saying since day one.

> We can only survive as a community if we act like one.
> So, conclusion:
> a) Let's get the samples working asap

I never said the opposite, I just have finite amount of time and, guess 
what, nobody that pays me to do the job of polishign this distribution 
so I have to do it as a hobby and let you people earn all the money.

> b) Let's get the nightly build working asap

the nightly build works, Carsten. What is the problem you are experiencing?

> c) If there are problems, let others know so that they can help

the problem is that samples need to be factored out in the blocks they 
belong to and the system being able to assemble them at need.

it's not rocket science, it's just boring work and tons of details. Also 
the samples are outdated and show lack of coherence.

I wanted to do a good job, not a quick and dirty one.

> d) Let's collect the missing parts for a 2.1 beta
> PS: It is easy to fix the samples by using the samples build
> from the old build system, but that's not the wanted solution.
> I will reinstall the old build system during the week if noone
> comes up with a better solution.

You are proposing to blast weeks of work because 20% of the job is not 


                                      - o -

If this wasn't enough, we have another part of the system that is going 
under contract solidification and this sparked interesting comments.

But let's start with some context first.

I showed Pier the flow and he fell in love with it. He expressed rather 
'colorful' appreciation of this. So much that Ovidiu was so pleased that 
wrote it in his weblog.

> February 02, 2003
> Cocoon control flow
> It looks like Cocoon control flow based on continuations is gaining admirers and I'm
about to be sanctified [1 2 3]!

A few weeks later, Pier used the same 'colorful' tone to show less 
appreciation on the way the Flow Object Model was designed, this was 
done after my suggestion to make an effort to freeze the FOM and polish 
it for a beta release.

Chris was worried about this call because he tought it was personally 
related to his adding the database connection capabilities to the FOM 
and sent us privately an email.

Ovidiu followed with a private email. I replied. Then he decided to 
reply to the list, without asking neither one of us copied (Chris, Pier 
and myself).

I spent days trying to figure out the best way to reply to this email 
without harming the process even more, then Ovidiu decides to leave to 
show his discomfort.

Note that I asked him *explicitly* if this was the case because I didn't 
want to misunderstand moves. He stated that his leaving has a lot to do 
with what happened.

I now reply to him.

> On Friday, Mar 7, 2003, at 05:23 US/Pacific, Stefano Mazzocchi wrote:
>> Ovidiu Predescu wrote:
>>> Hi Chris,
>>> I was really busy these past two weeks at office for a new launch, 
>>> and didn't follow the discussions on the mailing list at all.
>>> I quickly glanced at the messages: my gosh Pier, with all due 
>>> respect, you are really nervous!! You do not seem to understand 
>>> people are doing this for fun! If you want to critique something, 
>>> please do so by being a bit more calm and behave more professionally.
>> I'm sorry but I didn't see any lack of professionalism in his emails.
> But Chris felt sufficiently aggressed to send out an email with his 
> concerns. I find this is a good indication of the level of discussion 
> on the public mailing list and what he felt about it.

In that email (see below) he was asking us (Pier and myself) if he was 
doing something wrong that he had overlooked and wanted to know it.

I will let him state if he felt *aggressed* or simply found himself 
uncomfortable in a situation where more people depend on a technology 
and more cooperation is required to move on.

This said, I totally agree that Pier's tone can be rather 
'over-the-line' sometimes. [believe it or not, I'm teaching him 
diplomatic skills...] I came to appreciate his rather direct vocality, 
but I understand he can be somewhat harsh in trying to cut down words to 
type (but Carsten is doing the same thing, even if he uses less 'F' words)

>>> Chris has done a lot of work on the Rhino engine for us, even before 
>>> being involved in Cocoon. There's no reason to denigrate his work or 
>>> to take his contribution lightly.
>> With all due respect, Ovidiu, I don't see how polishing things out and 
>> expressing one's opinion in the open can mean to 'denigrate' the work 
>> of others.
> Not when is done too aggressively. We managed to avoid flames on 
> cocoon-dev so far and keep the discussions at the ideas level. Pier's 
> messages crossed the certain threshold after which they become personal.

There are two possibilities on the table when somebody crosses that 

1) he does it intentionally

2) he does it unintentionally

I don't see any intentionality in his behavior, nor any explicit 
personal attack.

>> Let's face it: the work on the flow engine has been, so far, a one man 
>> show. Since we were in 'experimental mode', this was all great and 
>> perfect but now that we are facing the burden of providing long-term 
>> back-compatibility of the interfaces of the FOM, we *MUST* behave as a 
>> community and treat the FOM just like we treat the sitemap semantics 
>> or the cocoon component interfaces.
> As with any other software, in the beginning was a one man show because 
> nobody understood what was going on and how they can contribute. A 
> while back people started to get it and able to contribute not only 
> ideas, but code as well.
> I don't argue about the topic changing the FOM, I argue about *how* the 
> discussion around it was conducted by Pier. 

Ok, this is a very important point.

> I don't believe the "F" 
> word and the sanguine tone of his emails belong in such a discussion.

Let me quote what *you* wrote:

> If you want to critique something, please do so by being a bit more calm 
 > and behave more professionally.

Here you state that Pier is not behaving professionally.

> [...] for the flow work most of the developers involved used to work 
 > very well so far by having private discussions instead of spilling
 > testosterone on the public mailing list.

Let me ask you, how would *you* behave if you were approached like this 
by someone commenting on your volunteer work to help this project?

Now, read again what Pier wrote:

I believe the 'touchy' parts are:

> It looks like there is no whatsoever OO-design behind
> the flow object model, and that's the same feeling you get when you take
> MSIE and try to make sense of its Jscript stuff

please, don't tell me that *you* felt offended because you wrote the 
first implementation of that object model.

But also

> I believe that before we can call a release, we need to have a _proper_
> object model for flow scripts, well defined, well architected. The other
> only outcome I see otherwise is the same _HUGE_ mistake that browsers did
> when they started to make pages scriptable...

and at the very end

> BTW, despite this "harshness" the flow is just mind-blowing. There isn't
> anything even close to it available now... As I see the potentialities of
> if, and cherish the concepts in my private little shrine at home, I believe
> it's even more important _NOW_ to do it right... And, IMO, we can...

What's wrong with this?

Ah, the almightly "F" word.

I searched MARC for 'rant fuck' and here is what I got:

where Pier uses this 'colorful' expression for stating his appreciation 
to Chris suggestion to use a tool for autodocumentation of IDL.

> The current FOM model exists because of various needs myself and other 
> users of the flow had over time. If people have other needs today, I 
> don't see a problem changing them. Let's do it in courteous manner.

I'm sure Pier will refrain from using 'colorful' words in the future.

>> When we designed the sitemap semantics, we spent 9 months discussing 
>> publicly. The only public discussion about the flow was about the 
>> sendPage* names. Nothing else was discussed.
> Is that right? I remember a lot of discussion describing the 
> architecture of the whole system and how the flow fits in it. I 
> sincerely hope the sendPage* discussion is not the only thing you 
> remember from the past 14 months of the flow discussions.

I'm sorry. I was irritated by your comments and wrote something that I 
shouldn't have because this doesn't really represent my thinking.

Please, allow me to restate:

The flow had several very deep architectural and technical discussions, 
but only recently the mass of cocoon developers who are familiar with it 
is enough to really reach critical mass.

If new HP was created a year before, or if Chris wasn't backing you up 
on the flow work, the Flow could well have died.

This is so for any technology, I agree.

But I think that the only community-wide discussion about the flow was 
about sendPage* and now is going to be about the FOM.

>> Pier is calling a discussion because he believes that overall design 
>> is not as clean as the rest of the cocoon system. I don't know if he's 
>> right or not, but I agree that without visibility (read: docs) on the 
>> FOM interfaces, it's really hard to know and people will *hack* their 
>> way thru to do what they need.
> Could you please point out how the design can be made more clean?

How can I possibly know how to make the design cleaner if I can't even 
grasp its shape? the FOM is totally hidden, you have to go thru several 
layers of java-javascript hooks to find out what methods you can call 
and what you can't.

Pier and Chris are doing exactly this: outline the shape of what we 
already have so that everybody can take a look and suggest ways to improve.

At the end, it might turn out that the FOM that you designed was great 
and didn't need anything different. But at *that* point, we'll have a 
community that decided and a community that knows about it and a 
community that is committed to maintain it.

This is what I asked.

> If 
> the design is indeed bad, let's redesign it. I don't think however the 
> lack of documentation or Java objects exposed in JavaScripts as part of 
> the FOM constitute bad design. 

I didn't say it's badly designed. I said we need to 'judge' its design 
by having a way to look at it!

> I may be wrong, in which case I stand 
> corrected: please produce a better design and implementation to replace 
> the current one.
> The documentation is clearly lacking, so let's write it.

Pier and Chris are doing exactly this.

Too bad you decided not to follow us in this improvement of your work.

>>> He's throwing out ideas because he wants to spark people's interest 
>>> and see what they can do with the flow. We're trying to work things 
>>> out, not to fight with each other.
>> Adding stuff to the FOM without a solid foundation is like building on 
>> sand. I've already said that cocoon has been building on sand for a 
>> while now but this was not understood because we are not releasing 
>> thus we are not faced with the burden of back compatibility.
> OK, no problem. Please explain why the current foundation is not solid.

Because it's design was not overviewed by the entire cocoon development 

> Software evolves and designs also do. I don't have any problem somebody 
> else producing a better design.

I hoped to have your contribution on it and I'm very sorry that my words 
led you to leaving.

>>> Lastly but not the least, for the flow work most of the developers 
>>> involved used to work very well so far by having private discussions 
>>> instead of spilling testosterone on the public mailing list.
>> This comment *really* pisses me off. I was not aware of the fact that 
>> most development discussions about the flow happened in private 
>> discussions.
>> this is against everything that Apache should be. This is not the way 
>> cocoon has been built so far, and let me tell you, it shows. The flow 
>> is plagued with one-man-show-ness and Pier is not spilling 
>> testosterone but trying to build a development community around it.
> Gosh, I don't see your point! What is a one-man-show, could you please 
> explain? Chris implemented continuations in Rhino, I implemented 
> support for his modified engine in Cocoon, Christian Haul added actions 
> support in the flow, Sylvain provided excellent guidance and support in 
> the sitemap support, Michael Melhem added continuation expiration 
> support, Reinhard P?tz submitted patches to fix various things. 
> Everybody built on somebody else's work and ideas. Everything that 
> matters was discussed on the public mailing lists and the rest are 
> details we solved between us.

How many people worked on the design of the FOM?

> Is there a problem? Please explain. I'm writing software for a long 
> time and this is the first time I hear something like this.

I believe in the concept that a community of people is smarter than me.

>>> I hope this will continue to happen, so we can maintain nice personal 
>>> relationships.
>> I hope this private mail attitude will *NOT* continue.
> Sure, I cc-ed this to the public mailing list as well.
>>> Many thanks,
>>> Ovidiu
>>> On Wednesday, Mar 5, 2003, at 11:31 US/Pacific, Christopher Oliver 
>>> wrote:
>>>> Hi Pier, Stefano
>>>> Just checking. Do you have a problem with any of my actions w/r to 
>>>> Cocoon. If so, please let me know. That was not my intention. My 
>>>> intention was to help get the ball rolling again on Ovidiu's vision 
>>>> for the flow. Maybe I've done enough and others can take it from 
>>>> here. I expected that others would have contributed more a long time 
>>>> ago - I sent Ovidiu the basic code to integrate with Velocity at 
>>>> least six months ago, and I tried to encourage Ugo and others to 
>>>> integrate with XMLForm. When I saw this wasn't happening and I had 
>>>> the opportunity I took the initiative to start making these changes 
>>>> myself. Since all of these were "first cuts" at solving these 
>>>> problems, the changes aren't perfect (either in design or 
>>>> implementation) and are going to need to evolve.
>> I do not have any problems with your attitude, Chris, nor I have with 
>> the way you write software or reply to email or behave as a person. 
>> None whatsoever. Rather the opposite, I'm very glad that you came to 
>> be involved with cocoon.
>> on the other hand, I believe the flow needs a serious community 
>> polishing, more than anything else.

I restate this.

>> The flow needs *both* users and a development community around it. One 
>> without the other will end up killing the idea and harm cocoon 
>> entirely.
>> How can we do this? provide Documentation, API docs and samples. Then 
>> start a discussion on how the FOM should be or should be cleaned up. 
>> it will take a while and won't be easy, but I'm willing to moderate 
>> the discussions and build consensus around it.
> And how do we achieve this? First stir up the developers a bit and then 
> moderate the tensions created between them, right? Is this the proper 
> way to do it?

No, write documentation about the FOM and ask people to comment on it.

>>>> I'd also be happy to have an off-list discussion about flow design 
>>>> so that we can understand each other better.
>> I don't want off-list discussions. I want public discussions, i want 
>> people to talk and let others know they are talking.
>> Please, let's all start doing this and without FUD.
>> We all want this technology to succeed, but we have different aims and 
>> different needs: we need to find a public consensus and converge or 
>> the flow will always look at the eyes of the cocoon developers like 
>> "an external things that was added later but never really integrated 
>> with the system".
> I don't find this to be the case. Many people have done exactly this: 
> integrate the flow with the rest of cocoon. Why do you want to give the 
> impression it was otherwise?

I don't want to give the impression, I'm just listening to comments.

How many cocoon developers can list at least 10 methods of the flow 
object model? I know I can't.

how many cocoon developers can list at least 10 sitemap elements? or 10 

did we ever do a IoC analysis of the FOM? how it integrates with avalon 
component management? how future compatible is with new avalon containers?

>> Hopefully this clears up the problem on the table.
> Unfortunately, it doesn't. And I'm really sad to find out about your 
> and Pier's thinking.

I'm asking for the community to judge the FOM exactly because I don't 
trust Pier's judgement indefinitively. What's sad about this?

> And what exactly is the discussion about? I'm confused now.
> :(

The discussion is about making the flow a technology that cocoon can 
depend on for years.

And this passes thru stabilizing the contracts between the flow 
scripters and the cocoon internals.

And I want this to be done by a community, not by only the few 
developers that cared and knew the code.

but I maybe entirely wrong.

if so, please let me know.


View raw message