There are three things going on:
1) major build refactoring
2) contract solidification
3) transition to cocoon.apache.org
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:
I AM AN IDIOT!
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!
Uh?
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 complete.
Amazing.
- 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.
http://www.webweavertech.com/ovidiu/weblog/archives/000179
>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 threshold:
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:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104683939300472&w=2
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:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104690905609879&w=2
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 community.
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 WRONG!
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 components?
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.
Ciao
