You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/12/03 05:53:35 UTC
Here is where we are divided
It appears that we are split down the middle on whether we want a
clean slate or build on what we have. Part of the problem is because
we are afraid of what it would take to come to consensus. As a result
there are some potentially really cool things that we might be able
to do with a clean slate that we might not see. There is also the
fear that we are abandoning our current users.
First, the reassurances. None of us want to abandon our current users.
We aren't all masochistic/sadistic/whateveristic. That is why any
brand new development absolutely requires a compatibility layer.
Next, the realities. We have an existing framework that works. It
has a couple rough edges that we can't clean up because there is
current software dependent on it. They are not show-stoppers, but
things that stick in some of our craws. Any time we have new
contracts that were not there before, we have a new version. It is
a question of degrees, but it is a new version nonetheless.
Framework Version 4.2 means we keep everything we have already. It
means we don't smooth the rough edges. It means we don't do anything
radical.
Framework Version 5.0 might be a smoking gun. Emotions are high right
now, which means that we might have to delay any hopes or dreams for 5.0
even longer. Keep in mind it will always be an emotional prospect.
However our attention can't be devided when we are discussing it.
We either shoot for the moon, or we play it safe.
---------------------------------------------
Introducing NetZero Long Distance
1st month Free!
Sign up today at: www.netzerolongdistance.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Dec 02, 2002 at 11:53:35PM -0500, Berin Loritsch wrote:
>
> We either shoot for the moon, or we play it safe.
From my side, I think we should shoot for the moon.
Berin's already pointed out that we'll have a compatiblity package to
ensure 4.x continues to work. If we're going to guarentee
backwards compatibility I would see no problems in re-evaluating our
current contracts, and aiming for that silver bullet.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Dec 02, 2002 at 11:53:35PM -0500, Berin Loritsch wrote:
>
> We either shoot for the moon, or we play it safe.
From my side, I think we should shoot for the moon.
Berin's already pointed out that we'll have a compatiblity package to
ensure 4.x continues to work. If we're going to guarentee
backwards compatibility I would see no problems in re-evaluating our
current contracts, and aiming for that silver bullet.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Berin Loritsch wrote:
>>
>>> It appears that we are split down the middle on whether we want a
>>> clean slate or build on what we have. Part of the problem is because
>>> we are afraid of what it would take to come to consensus. As a result
>>> there are some potentially really cool things that we might be able
>>> to do with a clean slate that we might not see. There is also the
>>> fear that we are abandoning our current users.
>>>
>>> First, the reassurances. None of us want to abandon our current users.
>>> We aren't all masochistic/sadistic/whateveristic. That is why any
>>> brand new development absolutely requires a compatibility layer.
>>>
>>> Next, the realities. We have an existing framework that works. It
>>> has a couple rough edges that we can't clean up because there is
>>> current software dependent on it. They are not show-stoppers, but
>>> things that stick in some of our craws. Any time we have new
>>> contracts that were not there before, we have a new version. It is
>>> a question of degrees, but it is a new version nonetheless.
>>>
>>> Framework Version 4.2 means we keep everything we have already. It
>>> means we don't smooth the rough edges. It means we don't do anything
>>> radical.
>>>
>>> Framework Version 5.0 might be a smoking gun. Emotions are high right
>>> now, which means that we might have to delay any hopes or dreams for
>>> 5.0
>>> even longer. Keep in mind it will always be an emotional prospect.
>>> However our attention can't be devided when we are discussing it.
>>>
>>> We either shoot for the moon, or we play it safe.
>>
>>
>>
>> I have not yet voted on this, but it seems that there is a deadlock,
>> so here is my opinion.
>>
>> I think that complete rewrites are very dangerous, and must be done
>> only as a last resort. They make code loose much of the information
>> that's there, in bugfixes, patches and testing.
>>
>> On the other hand, things must continue to go forward, and things
>> that obviously don't work must be rectified and changed.
>>
>> Avalon has still in minds of many a bad name about the heavy
>> refactorings it did years ago. Avalon is stable, works well, but
>> still developers remember what happened back then. I don't want this
>> to repeat.
>>
>> So this is my opinion: let's go for *AValon* (V==5).
>>
>> *BUT*
>>
>> Let's build on 4.1. That means *not* change packagenames, *not*
>> change class names just for the sake of it, *not* create new classes
>> when the existing ones can do with proper deprecation.
>>
>> Let's bring out our issues and visions, understand what users need
>> and we want; then take 4.1, package per package, discuss them, see
>> what can be taken - and I'm sure it's most of it - and make AValon.
>>
>> +1
>
>
>
>
> a.ka. 4.2
>
I'm changing my mind.
My thinking is that starting this process withing the scope of A5 is
probably better. I have suficient investment in A4.x to make sure
whatever happens - it will be rationale with respect to A4.x and I'm not
about to drop 4.x support - but at the same time doing a A5 shift lets
us to that quantum leap that we need to make make the new Avalon a success.
Consider me on board.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Berin Loritsch wrote:
>>
>>> It appears that we are split down the middle on whether we want a
>>> clean slate or build on what we have. Part of the problem is because
>>> we are afraid of what it would take to come to consensus. As a result
>>> there are some potentially really cool things that we might be able
>>> to do with a clean slate that we might not see. There is also the
>>> fear that we are abandoning our current users.
>>>
>>> First, the reassurances. None of us want to abandon our current users.
>>> We aren't all masochistic/sadistic/whateveristic. That is why any
>>> brand new development absolutely requires a compatibility layer.
>>>
>>> Next, the realities. We have an existing framework that works. It
>>> has a couple rough edges that we can't clean up because there is
>>> current software dependent on it. They are not show-stoppers, but
>>> things that stick in some of our craws. Any time we have new
>>> contracts that were not there before, we have a new version. It is
>>> a question of degrees, but it is a new version nonetheless.
>>>
>>> Framework Version 4.2 means we keep everything we have already. It
>>> means we don't smooth the rough edges. It means we don't do anything
>>> radical.
>>>
>>> Framework Version 5.0 might be a smoking gun. Emotions are high right
>>> now, which means that we might have to delay any hopes or dreams for
>>> 5.0
>>> even longer. Keep in mind it will always be an emotional prospect.
>>> However our attention can't be devided when we are discussing it.
>>>
>>> We either shoot for the moon, or we play it safe.
>>
>>
>>
>> I have not yet voted on this, but it seems that there is a deadlock,
>> so here is my opinion.
>>
>> I think that complete rewrites are very dangerous, and must be done
>> only as a last resort. They make code loose much of the information
>> that's there, in bugfixes, patches and testing.
>>
>> On the other hand, things must continue to go forward, and things
>> that obviously don't work must be rectified and changed.
>>
>> Avalon has still in minds of many a bad name about the heavy
>> refactorings it did years ago. Avalon is stable, works well, but
>> still developers remember what happened back then. I don't want this
>> to repeat.
>>
>> So this is my opinion: let's go for *AValon* (V==5).
>>
>> *BUT*
>>
>> Let's build on 4.1. That means *not* change packagenames, *not*
>> change class names just for the sake of it, *not* create new classes
>> when the existing ones can do with proper deprecation.
>>
>> Let's bring out our issues and visions, understand what users need
>> and we want; then take 4.1, package per package, discuss them, see
>> what can be taken - and I'm sure it's most of it - and make AValon.
>>
>> +1
>
>
>
>
> a.ka. 4.2
>
I'm changing my mind.
My thinking is that starting this process withing the scope of A5 is
probably better. I have suficient investment in A4.x to make sure
whatever happens - it will be rationale with respect to A4.x and I'm not
about to drop 4.x support - but at the same time doing a A5 shift lets
us to that quantum leap that we need to make make the new Avalon a success.
Consider me on board.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Berin Loritsch wrote:
>>
>>> It appears that we are split down the middle on whether we want a
>>> clean slate or build on what we have. Part of the problem is because
>>> we are afraid of what it would take to come to consensus. As a result
>>> there are some potentially really cool things that we might be able
>>> to do with a clean slate that we might not see. There is also the
>>> fear that we are abandoning our current users.
>>>
>>> First, the reassurances. None of us want to abandon our current users.
>>> We aren't all masochistic/sadistic/whateveristic. That is why any
>>> brand new development absolutely requires a compatibility layer.
>>>
>>> Next, the realities. We have an existing framework that works. It
>>> has a couple rough edges that we can't clean up because there is
>>> current software dependent on it. They are not show-stoppers, but
>>> things that stick in some of our craws. Any time we have new
>>> contracts that were not there before, we have a new version. It is
>>> a question of degrees, but it is a new version nonetheless.
>>>
>>> Framework Version 4.2 means we keep everything we have already. It
>>> means we don't smooth the rough edges. It means we don't do anything
>>> radical.
>>>
>>> Framework Version 5.0 might be a smoking gun. Emotions are high right
>>> now, which means that we might have to delay any hopes or dreams for
>>> 5.0
>>> even longer. Keep in mind it will always be an emotional prospect.
>>> However our attention can't be devided when we are discussing it.
>>>
>>> We either shoot for the moon, or we play it safe.
>>
>>
>>
>> I have not yet voted on this, but it seems that there is a deadlock,
>> so here is my opinion.
>>
>> I think that complete rewrites are very dangerous, and must be done
>> only as a last resort. They make code loose much of the information
>> that's there, in bugfixes, patches and testing.
>>
>> On the other hand, things must continue to go forward, and things
>> that obviously don't work must be rectified and changed.
>>
>> Avalon has still in minds of many a bad name about the heavy
>> refactorings it did years ago. Avalon is stable, works well, but
>> still developers remember what happened back then. I don't want this
>> to repeat.
>>
>> So this is my opinion: let's go for *AValon* (V==5).
>>
>> *BUT*
>>
>> Let's build on 4.1. That means *not* change packagenames, *not*
>> change class names just for the sake of it, *not* create new classes
>> when the existing ones can do with proper deprecation.
>>
>> Let's bring out our issues and visions, understand what users need
>> and we want; then take 4.1, package per package, discuss them, see
>> what can be taken - and I'm sure it's most of it - and make AValon.
>>
>> +1
>
>
>
>
> a.ka. 4.2
>
I'm changing my mind.
My thinking is that starting this process withing the scope of A5 is
probably better. I have suficient investment in A4.x to make sure
whatever happens - it will be rationale with respect to A4.x and I'm not
about to drop 4.x support - but at the same time doing a A5 shift lets
us to that quantum leap that we need to make make the new Avalon a success.
Consider me on board.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Berin Loritsch wrote:
>
>> It appears that we are split down the middle on whether we want a
>> clean slate or build on what we have. Part of the problem is because
>> we are afraid of what it would take to come to consensus. As a result
>> there are some potentially really cool things that we might be able
>> to do with a clean slate that we might not see. There is also the
>> fear that we are abandoning our current users.
>>
>> First, the reassurances. None of us want to abandon our current users.
>> We aren't all masochistic/sadistic/whateveristic. That is why any
>> brand new development absolutely requires a compatibility layer.
>>
>> Next, the realities. We have an existing framework that works. It
>> has a couple rough edges that we can't clean up because there is
>> current software dependent on it. They are not show-stoppers, but
>> things that stick in some of our craws. Any time we have new
>> contracts that were not there before, we have a new version. It is
>> a question of degrees, but it is a new version nonetheless.
>>
>> Framework Version 4.2 means we keep everything we have already. It
>> means we don't smooth the rough edges. It means we don't do anything
>> radical.
>>
>> Framework Version 5.0 might be a smoking gun. Emotions are high right
>> now, which means that we might have to delay any hopes or dreams for 5.0
>> even longer. Keep in mind it will always be an emotional prospect.
>> However our attention can't be devided when we are discussing it.
>>
>> We either shoot for the moon, or we play it safe.
>
>
> I have not yet voted on this, but it seems that there is a deadlock,
> so here is my opinion.
>
> I think that complete rewrites are very dangerous, and must be done
> only as a last resort. They make code loose much of the information
> that's there, in bugfixes, patches and testing.
>
> On the other hand, things must continue to go forward, and things that
> obviously don't work must be rectified and changed.
>
> Avalon has still in minds of many a bad name about the heavy
> refactorings it did years ago. Avalon is stable, works well, but still
> developers remember what happened back then. I don't want this to repeat.
>
> So this is my opinion: let's go for *AValon* (V==5).
>
> *BUT*
>
> Let's build on 4.1. That means *not* change packagenames, *not* change
> class names just for the sake of it, *not* create new classes when the
> existing ones can do with proper deprecation.
>
> Let's bring out our issues and visions, understand what users need and
> we want; then take 4.1, package per package, discuss them, see what
> can be taken - and I'm sure it's most of it - and make AValon.
>
> +1
a.ka. 4.2
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Here is where we are divided
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> On the other hand, things must continue to go forward, and
> things that
> obviously don't work must be rectified and changed.
>
> Avalon has still in minds of many a bad name about the heavy
> refactorings it did years ago. Avalon is stable, works well,
> but still
> developers remember what happened back then. I don't want
> this to repeat.
>
> So this is my opinion: let's go for *AValon* (V==5).
>
> *BUT*
>
> Let's build on 4.1. That means *not* change packagenames,
> *not* change
> class names just for the sake of it, *not* create new classes
> when the
> existing ones can do with proper deprecation.
Essentially you want Framework 4.2
That's fine, but you aren't looking to get rid of the already
deprecated stuff, or clean up how some things work.
> Let's bring out our issues and visions, understand what users
> need and
> we want; then take 4.1, package per package, discuss them,
> see what can
> be taken - and I'm sure it's most of it - and make AValon.
That's how I would do Avalon 5, but keep in mind where we
were back when we first discussed the idea of Avalon 5.
For instance we had ComponentLocator (no release method
because the container was supposed to be able to intelligently
pool behind the scenes), and a couple of other things.
That would mean YADP (Yet Another Deprecated Package).
After a while it gets rather heavy.
Let's be clear though, Framework 5 is a clean slate,
Framework 4.2 is an evolutionary approach. It seems that
there are several of us who want the 4.2 approach--which
is not necessarily bad, but there are certain things we
cannot do yet.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Here is where we are divided
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> On the other hand, things must continue to go forward, and
> things that
> obviously don't work must be rectified and changed.
>
> Avalon has still in minds of many a bad name about the heavy
> refactorings it did years ago. Avalon is stable, works well,
> but still
> developers remember what happened back then. I don't want
> this to repeat.
>
> So this is my opinion: let's go for *AValon* (V==5).
>
> *BUT*
>
> Let's build on 4.1. That means *not* change packagenames,
> *not* change
> class names just for the sake of it, *not* create new classes
> when the
> existing ones can do with proper deprecation.
Essentially you want Framework 4.2
That's fine, but you aren't looking to get rid of the already
deprecated stuff, or clean up how some things work.
> Let's bring out our issues and visions, understand what users
> need and
> we want; then take 4.1, package per package, discuss them,
> see what can
> be taken - and I'm sure it's most of it - and make AValon.
That's how I would do Avalon 5, but keep in mind where we
were back when we first discussed the idea of Avalon 5.
For instance we had ComponentLocator (no release method
because the container was supposed to be able to intelligently
pool behind the scenes), and a couple of other things.
That would mean YADP (Yet Another Deprecated Package).
After a while it gets rather heavy.
Let's be clear though, Framework 5 is a clean slate,
Framework 4.2 is an evolutionary approach. It seems that
there are several of us who want the 4.2 approach--which
is not necessarily bad, but there are certain things we
cannot do yet.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Here is where we are divided
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> On the other hand, things must continue to go forward, and
> things that
> obviously don't work must be rectified and changed.
>
> Avalon has still in minds of many a bad name about the heavy
> refactorings it did years ago. Avalon is stable, works well,
> but still
> developers remember what happened back then. I don't want
> this to repeat.
>
> So this is my opinion: let's go for *AValon* (V==5).
>
> *BUT*
>
> Let's build on 4.1. That means *not* change packagenames,
> *not* change
> class names just for the sake of it, *not* create new classes
> when the
> existing ones can do with proper deprecation.
Essentially you want Framework 4.2
That's fine, but you aren't looking to get rid of the already
deprecated stuff, or clean up how some things work.
> Let's bring out our issues and visions, understand what users
> need and
> we want; then take 4.1, package per package, discuss them,
> see what can
> be taken - and I'm sure it's most of it - and make AValon.
That's how I would do Avalon 5, but keep in mind where we
were back when we first discussed the idea of Avalon 5.
For instance we had ComponentLocator (no release method
because the container was supposed to be able to intelligently
pool behind the scenes), and a couple of other things.
That would mean YADP (Yet Another Deprecated Package).
After a while it gets rather heavy.
Let's be clear though, Framework 5 is a clean slate,
Framework 4.2 is an evolutionary approach. It seems that
there are several of us who want the 4.2 approach--which
is not necessarily bad, but there are certain things we
cannot do yet.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> It appears that we are split down the middle on whether we want a
> clean slate or build on what we have. Part of the problem is because
> we are afraid of what it would take to come to consensus. As a result
> there are some potentially really cool things that we might be able
> to do with a clean slate that we might not see. There is also the
> fear that we are abandoning our current users.
>
> First, the reassurances. None of us want to abandon our current users.
> We aren't all masochistic/sadistic/whateveristic. That is why any
> brand new development absolutely requires a compatibility layer.
>
> Next, the realities. We have an existing framework that works. It
> has a couple rough edges that we can't clean up because there is
> current software dependent on it. They are not show-stoppers, but
> things that stick in some of our craws. Any time we have new
> contracts that were not there before, we have a new version. It is
> a question of degrees, but it is a new version nonetheless.
>
> Framework Version 4.2 means we keep everything we have already. It
> means we don't smooth the rough edges. It means we don't do anything
> radical.
>
> Framework Version 5.0 might be a smoking gun. Emotions are high right
> now, which means that we might have to delay any hopes or dreams for 5.0
> even longer. Keep in mind it will always be an emotional prospect.
> However our attention can't be devided when we are discussing it.
>
> We either shoot for the moon, or we play it safe.
I have not yet voted on this, but it seems that there is a deadlock, so
here is my opinion.
I think that complete rewrites are very dangerous, and must be done only
as a last resort. They make code loose much of the information that's
there, in bugfixes, patches and testing.
On the other hand, things must continue to go forward, and things that
obviously don't work must be rectified and changed.
Avalon has still in minds of many a bad name about the heavy
refactorings it did years ago. Avalon is stable, works well, but still
developers remember what happened back then. I don't want this to repeat.
So this is my opinion: let's go for *AValon* (V==5).
*BUT*
Let's build on 4.1. That means *not* change packagenames, *not* change
class names just for the sake of it, *not* create new classes when the
existing ones can do with proper deprecation.
Let's bring out our issues and visions, understand what users need and
we want; then take 4.1, package per package, discuss them, see what can
be taken - and I'm sure it's most of it - and make AValon.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Leo Simons <le...@apache.org>.
(changing back the subject to something merrier)
On Tue, 2002-12-03 at 07:14, Stephen McConnell wrote:
> Berin Loritsch wrote:
> > We either shoot for the moon, or we play it safe.
>
> Shoot for the moon and play safe.
Agreed.
I'm going to sprout some thoughts on this rather than write a very
directed reply. I think otherwise I won't be saying what I want to say.
Apologies in advance ;)
---- = O = ----
For our company, I need a stable standalone container (ie
Avalon-Phoenix) right now and I need a stable servlet-embeddable
container (hoping it'll be Avalon-Fortress) in mid-january.
I need the stable Avalon-Framework to go with them. I need both of them
to support both ServiceManager and ComponentManager, and I need the
proxy features that wrap non-Components as Components. I need to
commercially support these products. I get paid to do so and paid to
provide support and work on them. I'll play safe regardless of what
avalon as a whole decides on this matter because I need to.
I suspect many people are in similar situations. We don't want these
people, contributing based on immediate need, to stop their work; we've
worked long and hard to have something stable and we need to harvest
some of the fruits of that labour.
Whether we call future stuff "Avalon 4.1.4", "Avalon 4.2", "Avalon 4.4"
or "RealCool Java Platform XP, .Net Edition", the APIs need evolution
rather than revolution to guarantee stability.
I think we all more or less agree on the big picture here: current
Avalon releases (all the stuff in
http://jakarta.apache.org/builds/jakarta-avalon/release/) are way cool,
need, deserve, and will get evolutionary development and support.
---- = O = ----
Avalon as a community needs to come together and do some refocusing.
We've got some nasty episodes behind us and we need to drop all that.
We're well underway to doing all that; I think it'll work out and avalon
will come out of this process as one of the healtiest, leanest, meanest
and coolest open source projects on the planet. There'll probably be a
lot of "blood, sugar, sex, magic" involved, but it'll work.
I don't think everyone believes that yet but I'm confident that everyone
will in a few months when we are back on track.
Regardless, we've spent a lot of time talking about the why's and the
hows of that and we're ready to "get our hands dirty", define charters,
bylaws, move stuff around, work on cool new code together, etc etc.
Everything is in place to make that happen. This is the big task
immediately ahead of us.
---- = O = ----
We've also gained a lot of experience since first releasing Framework
4.0 and ECM 4.0, gained new developers with new ideas, gained insights
from seeing our code in actual use, and many people are eager to put all
that new knowledge to use. This is something both fun to do (hence good
for the community) and something that might result in better code. The
not fun part of it (coding compatibility is not fun IMHO :) will happen
because there will be need for it.
How this new development takes place and which direction it goes in,
no-one knows for sure....as long as the entire community is part of the
new development I'll be real happy and I'm sure lots of cool stuff can
come from it.
Maybe we want to start with a common meta model, maybe with an
"ubercontainer", maybe with "Avalon-Framework 5", maybe all at once.
It's not the real point which areas we want to revolutionize. If it
makes sense to do so, good. Shoot for the moon, or mars. If we get
there, everyone's happy. If we don't, we'll have a solid orbital base to
return to.
---- = O = ----
There's three things on the table right now:
1 - community "reboot", along with setting up charter, bylaws etc. Very
important this happens correctly, thoroughly and in good spirit if
possible, with good participation from everyone involved.
2 - continuing work on existing releases. There's a need for this stuff,
and if the avalon project doesn't support it, things will just move
elsewhere along with the people that need it.
3 - work on "next-gen" stuff where it makes sense to have "next-gen"
stuff.
We've more or less decided on (1), now we just need to get that underway
together with the other projects working on this. (2) is going to happen
simply because that's how OSS works. (3) is going to happen in some
areas because it makes sense and people want to work on it.
+1 on making (1) the primary focus
+1 on allowing (2) to continue (ie -1 on a "maintainance mode only")
+1 on allowing (3) to happen as well (ie +1 on "controlled
community-wide revolution")
Do we need to agree now that the stuff that comes out of the next-gen
will replace the current products eventually? Yes. Is that something to
vote on? dunno. But I don't think it's an if/else decision.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Leo Simons <le...@apache.org>.
(changing back the subject to something merrier)
On Tue, 2002-12-03 at 07:14, Stephen McConnell wrote:
> Berin Loritsch wrote:
> > We either shoot for the moon, or we play it safe.
>
> Shoot for the moon and play safe.
Agreed.
I'm going to sprout some thoughts on this rather than write a very
directed reply. I think otherwise I won't be saying what I want to say.
Apologies in advance ;)
---- = O = ----
For our company, I need a stable standalone container (ie
Avalon-Phoenix) right now and I need a stable servlet-embeddable
container (hoping it'll be Avalon-Fortress) in mid-january.
I need the stable Avalon-Framework to go with them. I need both of them
to support both ServiceManager and ComponentManager, and I need the
proxy features that wrap non-Components as Components. I need to
commercially support these products. I get paid to do so and paid to
provide support and work on them. I'll play safe regardless of what
avalon as a whole decides on this matter because I need to.
I suspect many people are in similar situations. We don't want these
people, contributing based on immediate need, to stop their work; we've
worked long and hard to have something stable and we need to harvest
some of the fruits of that labour.
Whether we call future stuff "Avalon 4.1.4", "Avalon 4.2", "Avalon 4.4"
or "RealCool Java Platform XP, .Net Edition", the APIs need evolution
rather than revolution to guarantee stability.
I think we all more or less agree on the big picture here: current
Avalon releases (all the stuff in
http://jakarta.apache.org/builds/jakarta-avalon/release/) are way cool,
need, deserve, and will get evolutionary development and support.
---- = O = ----
Avalon as a community needs to come together and do some refocusing.
We've got some nasty episodes behind us and we need to drop all that.
We're well underway to doing all that; I think it'll work out and avalon
will come out of this process as one of the healtiest, leanest, meanest
and coolest open source projects on the planet. There'll probably be a
lot of "blood, sugar, sex, magic" involved, but it'll work.
I don't think everyone believes that yet but I'm confident that everyone
will in a few months when we are back on track.
Regardless, we've spent a lot of time talking about the why's and the
hows of that and we're ready to "get our hands dirty", define charters,
bylaws, move stuff around, work on cool new code together, etc etc.
Everything is in place to make that happen. This is the big task
immediately ahead of us.
---- = O = ----
We've also gained a lot of experience since first releasing Framework
4.0 and ECM 4.0, gained new developers with new ideas, gained insights
from seeing our code in actual use, and many people are eager to put all
that new knowledge to use. This is something both fun to do (hence good
for the community) and something that might result in better code. The
not fun part of it (coding compatibility is not fun IMHO :) will happen
because there will be need for it.
How this new development takes place and which direction it goes in,
no-one knows for sure....as long as the entire community is part of the
new development I'll be real happy and I'm sure lots of cool stuff can
come from it.
Maybe we want to start with a common meta model, maybe with an
"ubercontainer", maybe with "Avalon-Framework 5", maybe all at once.
It's not the real point which areas we want to revolutionize. If it
makes sense to do so, good. Shoot for the moon, or mars. If we get
there, everyone's happy. If we don't, we'll have a solid orbital base to
return to.
---- = O = ----
There's three things on the table right now:
1 - community "reboot", along with setting up charter, bylaws etc. Very
important this happens correctly, thoroughly and in good spirit if
possible, with good participation from everyone involved.
2 - continuing work on existing releases. There's a need for this stuff,
and if the avalon project doesn't support it, things will just move
elsewhere along with the people that need it.
3 - work on "next-gen" stuff where it makes sense to have "next-gen"
stuff.
We've more or less decided on (1), now we just need to get that underway
together with the other projects working on this. (2) is going to happen
simply because that's how OSS works. (3) is going to happen in some
areas because it makes sense and people want to work on it.
+1 on making (1) the primary focus
+1 on allowing (2) to continue (ie -1 on a "maintainance mode only")
+1 on allowing (3) to happen as well (ie +1 on "controlled
community-wide revolution")
Do we need to agree now that the stuff that comes out of the next-gen
will replace the current products eventually? Yes. Is that something to
vote on? dunno. But I don't think it's an if/else decision.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] New Development Direction
Posted by Leo Simons <le...@apache.org>.
(changing back the subject to something merrier)
On Tue, 2002-12-03 at 07:14, Stephen McConnell wrote:
> Berin Loritsch wrote:
> > We either shoot for the moon, or we play it safe.
>
> Shoot for the moon and play safe.
Agreed.
I'm going to sprout some thoughts on this rather than write a very
directed reply. I think otherwise I won't be saying what I want to say.
Apologies in advance ;)
---- = O = ----
For our company, I need a stable standalone container (ie
Avalon-Phoenix) right now and I need a stable servlet-embeddable
container (hoping it'll be Avalon-Fortress) in mid-january.
I need the stable Avalon-Framework to go with them. I need both of them
to support both ServiceManager and ComponentManager, and I need the
proxy features that wrap non-Components as Components. I need to
commercially support these products. I get paid to do so and paid to
provide support and work on them. I'll play safe regardless of what
avalon as a whole decides on this matter because I need to.
I suspect many people are in similar situations. We don't want these
people, contributing based on immediate need, to stop their work; we've
worked long and hard to have something stable and we need to harvest
some of the fruits of that labour.
Whether we call future stuff "Avalon 4.1.4", "Avalon 4.2", "Avalon 4.4"
or "RealCool Java Platform XP, .Net Edition", the APIs need evolution
rather than revolution to guarantee stability.
I think we all more or less agree on the big picture here: current
Avalon releases (all the stuff in
http://jakarta.apache.org/builds/jakarta-avalon/release/) are way cool,
need, deserve, and will get evolutionary development and support.
---- = O = ----
Avalon as a community needs to come together and do some refocusing.
We've got some nasty episodes behind us and we need to drop all that.
We're well underway to doing all that; I think it'll work out and avalon
will come out of this process as one of the healtiest, leanest, meanest
and coolest open source projects on the planet. There'll probably be a
lot of "blood, sugar, sex, magic" involved, but it'll work.
I don't think everyone believes that yet but I'm confident that everyone
will in a few months when we are back on track.
Regardless, we've spent a lot of time talking about the why's and the
hows of that and we're ready to "get our hands dirty", define charters,
bylaws, move stuff around, work on cool new code together, etc etc.
Everything is in place to make that happen. This is the big task
immediately ahead of us.
---- = O = ----
We've also gained a lot of experience since first releasing Framework
4.0 and ECM 4.0, gained new developers with new ideas, gained insights
from seeing our code in actual use, and many people are eager to put all
that new knowledge to use. This is something both fun to do (hence good
for the community) and something that might result in better code. The
not fun part of it (coding compatibility is not fun IMHO :) will happen
because there will be need for it.
How this new development takes place and which direction it goes in,
no-one knows for sure....as long as the entire community is part of the
new development I'll be real happy and I'm sure lots of cool stuff can
come from it.
Maybe we want to start with a common meta model, maybe with an
"ubercontainer", maybe with "Avalon-Framework 5", maybe all at once.
It's not the real point which areas we want to revolutionize. If it
makes sense to do so, good. Shoot for the moon, or mars. If we get
there, everyone's happy. If we don't, we'll have a solid orbital base to
return to.
---- = O = ----
There's three things on the table right now:
1 - community "reboot", along with setting up charter, bylaws etc. Very
important this happens correctly, thoroughly and in good spirit if
possible, with good participation from everyone involved.
2 - continuing work on existing releases. There's a need for this stuff,
and if the avalon project doesn't support it, things will just move
elsewhere along with the people that need it.
3 - work on "next-gen" stuff where it makes sense to have "next-gen"
stuff.
We've more or less decided on (1), now we just need to get that underway
together with the other projects working on this. (2) is going to happen
simply because that's how OSS works. (3) is going to happen in some
areas because it makes sense and people want to work on it.
+1 on making (1) the primary focus
+1 on allowing (2) to continue (ie -1 on a "maintainance mode only")
+1 on allowing (3) to happen as well (ie +1 on "controlled
community-wide revolution")
Do we need to agree now that the stuff that comes out of the next-gen
will replace the current products eventually? Yes. Is that something to
vote on? dunno. But I don't think it's an if/else decision.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> It appears that we are split down the middle on whether we want a
> clean slate or build on what we have. Part of the problem is because
> we are afraid of what it would take to come to consensus. As a result
> there are some potentially really cool things that we might be able
> to do with a clean slate that we might not see. There is also the
> fear that we are abandoning our current users.
>
> First, the reassurances. None of us want to abandon our current users.
> We aren't all masochistic/sadistic/whateveristic. That is why any
> brand new development absolutely requires a compatibility layer.
>
> Next, the realities. We have an existing framework that works. It
> has a couple rough edges that we can't clean up because there is
> current software dependent on it. They are not show-stoppers, but
> things that stick in some of our craws. Any time we have new
> contracts that were not there before, we have a new version. It is
> a question of degrees, but it is a new version nonetheless.
>
> Framework Version 4.2 means we keep everything we have already. It
> means we don't smooth the rough edges. It means we don't do anything
> radical.
>
> Framework Version 5.0 might be a smoking gun. Emotions are high right
> now, which means that we might have to delay any hopes or dreams for 5.0
> even longer. Keep in mind it will always be an emotional prospect.
> However our attention can't be devided when we are discussing it.
>
> We either shoot for the moon, or we play it safe.
Shoot for the moon and play safe.
We can do amazing stuff on te container side of the equation - more than
Phoenix, more than Merlin, more than Fortress - hell, we can do more
that all of these combined and use less memory, disk, whatever. That's
shooting for the moon - we can do it - but we do it running on 4.1
client contract, we can bitch and complain and add some cool stuff into
a 4.2 supplement and still run containers that are adaptive. That's not
only shooting for the moon - its a managed round trip - hello Houston,
touchdown in 3 minuets.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Here is where we are divided
Posted by Marcus Crafter <cr...@fztig938.bank.dresdner.net>.
On Mon, Dec 02, 2002 at 11:53:35PM -0500, Berin Loritsch wrote:
>
> We either shoot for the moon, or we play it safe.
From my side, I think we should shoot for the moon.
Berin's already pointed out that we'll have a compatiblity package to
ensure 4.x continues to work. If we're going to guarentee
backwards compatibility I would see no problems in re-evaluating our
current contracts, and aiming for that silver bullet.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: ManageSoft GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&'
&&&&.
&&&&&&&:
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>