perception of avalon (was: really long subjectline)

[Leo Simons <ma...@leosimons.com>]

> > You write with a "[VOTE]" in the subject, to the development list,
> > having committer status to avalon. I didn't figure out you were writing
> > as a user. Even if I did, I would let it show <innocent blink/>, because
> > others might not have figured it out.
> 
> ;-)
> 
> Till some time back I was only a user, so sometimes it shows.
> I was behind the barricades feeling like Avalon was a sort of ivory 
> tower, and heard the same remark from many guys.

we're ready for a user list I guess =)

nice one, btw..."ivory tower"...but we're of course a bit more like a
beautiful white city where everyone good of heart (and programming
skill) is welcome, a city promoting the universal good, the center of
what will be the most beautiful software package ever (integrating
allmost all of jakarta) governed over by a round table, where stout
knights (committers) sit as equals...

(!)

> Ok, I was messy. The problem comes with older Avalon, between Avalon 
> major versions, and having to deal with dev versions.
> 
> Avalon is so cool, that many projects just start using dev stuff, and it 
> gives bad pubblicity to a family of products that is really stable.

yup.

> I want this stability to remain in the switch to the new version, and 
> hope that the 5 version can bring more *percieved* stability, hence the 
> reference to docs, examples and reference implementations.

I think what will bring more percieved stability is a stable release of
all the important parts of avalon framework.

Thing is, it is all very usable now:

- there's a stable framework
- a stable logkit
- a stable container (ECM/ECS)
- some stable reusable components for use with ECM/ECS

all of which are supported and do their job. We also have lots of stuff
not marked as stable which is mixed up, in presentation and CVS, with
the rest.

Once we start filling the builds/ directory (Paul is doing a great job
to get this working, btw, with some assistance from the other "release
managers") this'll be easier.

> What I meant:
> "Stability of interfaces and package names has been giving problems to 
> Avalon developers between some major Avalon releases.
> I hope that we can change package names and interface names as little as 
> possible, concentrating on the conceptual inefficiencies that we 
> internally percieve as bugs, like the Component interface and other 
> marker interfaces, rather than creating more stuff."

+1. Don't see it as a bug though. Just something that could be improved
a little bit.

> > If you would just have said: "I would like to see avalon have better
> > documentation", you'd get a "me too", and any patches/commits that'd
> > provide such documentation would be very welcome (you'd get a "you
> > rock").
> 
> Personally I understand the difficulty, since I have problems in 
> documenting Centipede. It's really hard, I know.

yup. And the closer you are to the code, the more difficult.

> I will commit some images, I think that they speak a thousand words.

cool beans! (I'm saving up a "you rock" for the occasion :P)

- Leo


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>