xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved Sandstrom <Arved...@chebucto.ns.ca>
Subject Re: [spinnaker] Announce
Date Sun, 09 Jul 2000 11:55:20 GMT
At 10:38 PM 7/8/00 -0700, James Duncan Davidson wrote:
>on 7/8/00 3:31 PM, Arved Sandstrom at Arved_37@chebucto.ns.ca wrote:
>
>> On a very related issue, as "developers" we don't spend most of our time on
>> code. When we communicate, we communicate with design documents. UML,
>> IEEE-compliant design descriptions, yada yada.
>
>I don't see a lot of UML on Open Source projects. Typically we communicate
>with code and mail. But that's a personal thing. I can hold a discussion in
>UML as well as anything -- so what's your design for a NG parser? :)

I don't personally see _any_ UML on open source projects. :-) I wouldn't 
mind seeing some judicious use of the most expressive diagrams, and I plan 
to start sneaking them into FOP, which has some fairly intricate stuff 
happening, and could benefit from them.

This is a completely unrelated tack, but maybe that's something we want to 
encourage - communication of designs with formal modelling notation (not 
getting completely anal, mind you), rather than code. I suppose the main 
problem right now is access to the tools - Visio 2000, or Together/J, or 
Rational Rose, are not cheap. I'm keeping an eye on ArgoUML, though (which 
is under the auspices of the Tigris project), and recommend it to anyone who 
wishes to get a start with UML. There isn't support for everything yet, but 
that's coming.

>> I personally don't want to
>> receive a new source tree as the first deliverable.
>
>Take a look at the spinnaker tree. There's not much there. In fact, some of
>my friends were concerned that there should have been more. What it is is a
>README that points out some obvious goals, then a few utility classes that
>I've managed to pull out of Xerces so far (And I'm pulling out more as we
>speak). You'll note that in the README I actually outline talking about an
>API set, and moving forward from there. I would have actually felt bad about
>checking in too much code at once because then it *would* have been a fiat.
>
> [ SNIPPAGE ]

Well, I'm satisfied that the intentions were good. In any case, since I'm 
not a Xerces member I don't exactly have to be satisfied anyway. But as an 
Apache XML member I had some concerns.

>> Speaking for myself, since I'm the release coordinator for FOP, if I saw
>> that some group came in out of the blue and launched an entire new source
>> tree I'd be pretty fired up. On any open-source project there is at least
>> the principle of coordination. You can commit new source without
>> consultation if it doesn't impact existing API's; new branches are a cut
>> above that and require some feedback.
>
>No, new branches are experimental. And at Apache, we encourage
>experimentation. To the point where on the Jakarta project we created a
>manifesto for it that expresses some of the points in use from early days of
>Apache. I'll try to dig that out of the archives and post it somewhere.

I'd like to see it.

I don't think anyone is arguing that new branches cannot be created. :-) I 
think that what is being expressed is a sense of dismay at the lack of news. 
You know, I could, theoretically, start a new FOP branch today, and it could 
contain one file - the interface for a complete FO processor, somewhat 
different than what we have now. Then I could go away for a few weeks. This 
would cause consternation and probably some anger - what's this guy up to? 
what's the direction of the project? am I spinning my wheels doing any more 
work on the main branch?
 
>Basically it expresses that anybody has a right to go off and create
>something new. If people (developers and users) flock to it, then it's
>something worthwhile and should be considered, if people don't, that sends
>an equally strong message. At the end of the day, it only becomes the
>santioned next version when everyone is convinced that it's the right thing
>to do.

Yes, you are correct. I think the significant thing here is that one 
normally doesn't start up a potential competitor under the auspices of the 
original. There would have been much less hullaballoo if this refactoring 
were taking place elsewhere, I think. Failing that, consider HR and 
politics. Keep people informed. 

>Changes to the main tree require more process, things on the periphery
>should require no process. This is one of the problems with the Jakarta and
>XML processes -- they have been influenced by corporate thinking and the
>notion of processes has crept in -- and some amount of fiefdom. Some
>companies feel that one project is theirs to own, and the other project
>isn't something that they feel welcome in so they will shun it. I've seen it
>in both my corp, and in other corps. And that's BS. These projects are owned
>by Apache. And we play by Apache rules here.. And the number one Apache rule
>is to collaborate and produce code (in fact the +1/0/-1 rule is about all
>that we really do have in stone). There aren't many rules, and those that we
>have change over time -- it doesn't work beautifully, but it does manage to
>work.

You said the magic word - "collaborate". To me that means "communicate 
design decisions and announce intentions".

There is absolutely nothing wrong with process. Most open source projects 
are operating at CMM Level 1 - projects are successful because of the 
individuals. Getting most of the processes covered under Levels 2 & 3 
injected into OS would be a boon, I think. I suspect that maybe these are 
not the kinds of processes you had in mind?

We had a situation over with FOP when James Tauber gave the software to 
Apache, and because of real work, has essentially withdrawn. There was no 
formal handover process that would have ensured that James' ideas as to 
design and implementation were captured - no design documentation. I think 
that he himself would acknowledge that this is not good. FOP is just one 
among many OS projects in this regard.

Anyhow, I think this is interesting. Apache is maturing, and I don't think 
that is synonymous with "ossifying". :-) Stuff like this has to occur, and 
be argued, and dealt with.

Arved Sandstrom

Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"


Mime
View raw message