You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Leo Sutic <le...@inspireinfrastructure.com> on 2003/03/13 10:42:57 UTC
Spice Dependency (was: RE: Spice License)
> -----Original Message-----
> From: Peter Donald [mailto:peter@realityforge.org]
Regarding the license, I think Ken Coar pretty much settled that
point.
> > And I don't think having Spice as a dependency is any good.
> Any reason why? We have plenty of other external dependencies and at
least
> spice is quality controlled.
1. Because the Avalon project voted that we should migrate to
Commons CLI and not Spice CLI. A more constructive approach
would have been for you to explain the problems with Commons CLI
and then ket us help you resolve them instead of going off
by yourself 90 degrees from the voted and decided path.
2. Situations like this are bound to happen again. What are you
going to do then? Bring in even more Spice dependencies?
Do you realize that you might as well move all of Phoenix
to Spice now and be done with it? Having a fork *now* would
be prefereable to the slow Spice-ification of Phoenix in
Avalon CVS, because by the end of it, Avalon no longer has
control of Phoenix - it will have been, in effect, a Spice
project hosted at Apache. I don't even want to go into the
troubles that will lead to.
PS: Do I get to call you "Smarty Spice" or "Scary Spice" now?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Jakarta JAMES is building!!!!
:-D
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Berin Loritsch <bl...@apache.org>.
Stefano Mazzocchi wrote:
> I think the most important thing is to get Gump to work. Since it
> appears that you are very concerned about back-compatibility issues,
> what prevents you from helping out to make gump work right for avalon
> and specifically excalibur?
I am addressing GUMP, and have been for the past few days. It is a
frustratingly slow turn around time--and I have a feeling that there
are two GUMP repositories--and the one that cvs.apache.org uses is not
the one nagoya.apache.org/~rubys uses.
I would like to point out that there are *much* fewer compilation
problems listed here:
http://nagoya.apache.org/~rubys/gump/
Which is where I see my changes happening.
Cocoon has a problem in the gump descriptor where the jar file
I am trying to reference isn't comming through. Hopefully the
next run will let me see a clear cocoon build the next time it
is run.
I have not been able to get gump running locally, so I have
to wait *hours* to see the effects of my changes.
To note:
Jakarta JAMES is building!!!!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> Avalons track record wrt to stability and quality control is fairly piss poor
> except for framework/logkit/phoenix.
Oh, please. Would you stop behaving as you are the only one knowing what
to do around here?
What is stopping you from helping instead of crying like a baby everytime?
> Hell I have had my code broken 4 times
> in the last 3 weeks let alone any extended period.
So did everybody, but things *are* getting more solid, Peter. It used to
be much worse and I didn't perceive anybody on this list who is *NOT*
committed or values stability of contracts. It just didn't happen
because excalibur was a mess, it's overlyfragmented and there is no
notion of 'scratchpad' in avalon.
> The problems in Avalon are far more than just interaction between me and
> Stephen.
True.
> The problem occurs because people who don't contribute to a
> component/area but are more than willing to tell others what to do.
True as well.
> Worse is
> when these changes are made but never maintained.
Even more true.
> I would love it if
> everytime someone voted or made a commit they were also giving a guarentee
> that they would support the change.
This is a very good point. You don't know how happy I am (and I'm
stinking serious!) to see you actually pointing out the serious issues
using a polite and useful tone like in these last sentences.
At the same time, I think it will be *much* more constructive if you
outlined *specific* problems so that people might just get down and deal
with them.
At the same time, I believe that avalon suffers from the anti-pattern of
'overcomponentization'.
That means: too many contracts around, too easy to break.
I think the most important thing is to get Gump to work. Since it
appears that you are very concerned about back-compatibility issues,
what prevents you from helping out to make gump work right for avalon
and specifically excalibur?
Pointing out problems is good and appreciated.
Helping by using this knowledge to solve them would be even more.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 07:57, Rodent of Unusual Size wrote:
> the paragraph that follows is working from my impression that
> your 'my code broke' remark above has been pressed into service
> as a justification for some of your vetos. if that is not the
> case, then ignore the rest of this message.
Not the case. The problem is breaking backwards compatability in library code
for no reason or for a poor reason. If there is a good reason to break
backwards compat then I am all for it but if there is not then it will be a
problem ... at least if I notice and care and that mostly associated with
stuff I use.
--
Cheers,
Peter Donald
"All my life I wanted to be someone; I guess I should have been more
specific."
-- Jane Wagner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Peter Donald wrote:
> On Fri, 14 Mar 2003 02:28, Rodent of Unusual Size wrote:
>> Peter Donald wrote:
>> > Avalons track record wrt to stability and quality control is fairly piss
>> > poor except for framework/logkit/phoenix. Hell I have had my code broken
>> > 4 times in the last 3 weeks let alone any extended period.
>>
>> 'your' code? are you referring to code in avalon, or stuff of your
>> own that is based on avalon code?
>
> stuff based on avalon code.
aha.
> Though theres enough Apache based code that is
> broken .. witness James/Phoenix.
that is irrelevant to my question which concerned your use of
the possessive pronoun. you have clarified that you were
not expressing possession of code in the asf repository;
thank you for the clarification.
the paragraph that follows is working from my impression that
your 'my code broke' remark above has been pressed into service
as a justification for some of your vetos. if that is not the
case, then ignore the rest of this message.
as for the breakage in your own external code: in a word, tough.
that's what you get for tying it to bleeding-edge stuff. using
it for your own stuff *and* being an avalon developer empowers
you to work on fixing the problem. IN NO WAY does the collateral
breakage of your personal code entitle you to block anyone else's work.
no committer is permitted to hold up an asf project just because
his/her own private work is broken by a change in cvs HEAD. as an
example: if a change in the apr api broke subversion, no committer
is entitled to veto or revert that change for that reason alone.
i pick that particular example because there is a significant
overlap between those two developer communities, and it is a
scenario which could quite reasonably come up.
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 02:28, Rodent of Unusual Size wrote:
> Peter Donald wrote:
> > Avalons track record wrt to stability and quality control is fairly piss
> > poor except for framework/logkit/phoenix. Hell I have had my code broken
> > 4 times in the last 3 weeks let alone any extended period.
>
> 'your' code? are you referring to code in avalon, or stuff of your
> own that is based on avalon code?
stuff based on avalon code. Though theres enough Apache based code that is
broken .. witness James/Phoenix.
--
Cheers,
Peter Donald
The big mistake that men make is that when they turn thirteen or fourteen and
all of a sudden they've reached puberty, they believe that they like women.
Actually, you're just horny. It doesn't mean you like women any more at
twenty-one than you did at ten. --Jules Feiffer (cartoonist)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Peter Donald wrote:
>
> Avalons track record wrt to stability and quality control is fairly piss poor
> except for framework/logkit/phoenix. Hell I have had my code broken 4 times
> in the last 3 weeks let alone any extended period.
'your' code? are you referring to code in avalon, or stuff of your
own that is based on avalon code?
--
#ken P-)}
Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/
Author, developer, opinionist http://Apache-Server.Com/
"Millennium hand and shrimp!"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Stefano Mazzocchi <st...@apache.org>.
Peter Donald wrote:
> On Thu, 13 Mar 2003 20:42, Leo Sutic wrote:
>
>> 1. Because the Avalon project voted that we should migrate to
>> Commons CLI and not Spice CLI.
>
>
> Nope.
>
> I would have vetoed any code change that led to that.
Peter, you don't nor will ever have the power to veto anything around
Apache.
Stefano.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 00:25, Peter Donald wrote:
> On Thu, 13 Mar 2003 23:57, Leo Sutic wrote:
> > Look, how about we meet half way - would you support going back to
> > Excalibur CLI (hosted in the Excalibur compatibility project here
> > at Apache), if I do the work?
>
> Not if it is deprecated as there is no need to add dependencies to
> deprecated code unless it is compatability layers.
>
> Not if it is in its current state as it is broken in excalibur and doesn't
> even pass its unit tests.
>
> Not if it will be deprecated in the future or any migration will be forced.
>
> Not unless you show some real commitment to actually doing maintanence.
Oh and the offer still stands. If you want to put your money where your mouth
is then I will add you as a member of spice.
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote, On 13/03/2003 14.58:
> On Fri, 14 Mar 2003 00:32, Leo Sutic wrote:
>
>>Number 1: By deprecated, do you mean code marked with @deprecated,
>>or code that isn't marked so, but no longer considered part of
>>Avalon proper? I'm fine with removing @deprecated tags from CLI,
>>if that's what you want, but I'm not fine with pulling it out
>>of the compatibility project again.
>
> funny thing is it should not be in the compatability project as I -1'ed that
> but then again maybe some people are more equal than others.
Below is part of the message that IIUC refers to the above.
Vetos do not apply to things such as organizational things, project
management etc, which are a majority decision.
I regard the below as a vote, not a veto. These things have been wrongly
treated as vetos in the past, hampering the ability of Avalon to make
comprehensive project decisions.
Thus you have expressed your opinion and your vote, as anyone here.
So please stop this nonsense of being treated differently, because it's
plain false. Yes, you are acting differently, but that's up to you.
-------- Original Message --------
Subject: Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Date: Wed, 12 Mar 2003 07:37:19 +1100
From: Peter Donald <pe...@realityforge.org>
Reply-To: Avalon Developers List <de...@avalon.apache.org>
To: Avalon Developers List <de...@avalon.apache.org>
References: <20...@icarus.apache.org>
...
-1 on cli and io being removed as free standing projects. There is no
justification for doing so and they worked fine as they were previously. Why
break something that worked and add extra cruft into dependency trees of
projects that don't need that cruft?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>>What you're asking me to do is to monitor the Phoenix project. That is
>>impossible - I don't use Phoenix, nor do I intend to. Unless I test the
>>project every day, I can not be a good monitor
>
> Gents ... what about having GUMP run tests when it does the builds? Better
> to have a machine doing rote tasks.
;-)
- Sam Ruby
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> What you're asking me to do is to monitor the Phoenix project. That is
> impossible - I don't use Phoenix, nor do I intend to. Unless I test the
> project every day, I can not be a good monitor
Gents ... what about having GUMP run tests when it does the builds? Better
to have a machine doing rote tasks.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Sat, 15 Mar 2003 00:09, Leo Sutic wrote:
> > Unlikely in the sense that we're getting rid of parts of Avalon that
> > are out of scope.
>
> yep - Why add a dependency on something scheduled to be culled ?
As a stepping stone to Commons CLI.
1. Keep deps inside Apache.
2. Switch to Commons CLI.
There appears to be no technical reasons not to to the switch. Your
objections have been largely invalidated since they were made -
Commons CLI has evolved.
> > So, I don't get this maintenance part. If I leave it in a
> stable state
> > - and coder X goes in a breaks it, shouldn't then coder X fix it?
>
> They should fix it (but history shows that does not happen). However
you
> should also be monitoring the change and making sure all the changers
done by
> coder X do not inadverantly break something (ie coder X may not know
> something is broken) and if coderX skimps on some of the work (docs,
unit
> tests, etc) then you have to be willing to step up and do something
about it.
What you're asking me to do is to monitor the Phoenix project. That is
impossible - I don't use Phoenix, nor do I intend to. Unless I test the
project every day, I can not be a good monitor and would not do my duty
according to you, and according to my idea of responsibility.
What I offered to you was help in making a change that I believe is
beneficial to Avalon as a whole - I did not offer to become a Phoenix
developer.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 15 Mar 2003 00:09, Leo Sutic wrote:
> > Because it is not being maintained in Avalon now and it is
> > unlikely it will be maintained in Avalon in the future.
>
> Unlikely in the sense that we're getting rid of parts of Avalon
> that are out of scope.
yep - Why add a dependency on something scheduled to be culled ?
> 4. But, there is no need for that dependency - Phoenix
> can depend on Excalibur/Compatibility. You and everyone
> else can develop the CLI project under Compatibility
> just as well as you can do it under Spice.
Not true.
If I want to undeprecate CLI and continue development and guarentee stability
of CLI for years to come I can not do that in Avalon but I can do that
outside Avalon.
> So, I don't get this maintenance part. If I leave it in a stable
> state - and coder X goes in a breaks it, shouldn't then coder X
> fix it?
They should fix it (but history shows that does not happen). However you
should also be monitoring the change and making sure all the changers done by
coder X do not inadverantly break something (ie coder X may not know
something is broken) and if coderX skimps on some of the work (docs, unit
tests, etc) then you have to be willing to step up and do something about it.
--
Cheers,
Peter Donald
------------------------------------------------
"No. Try not. Do. Or do not. There is no try."
-- Yoda
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
Could we quickly recap the issues:
1.
> Not if it is deprecated as there is no need to add
> dependencies to deprecated code unless it is compatability
> layers.
2.
> Not if it is in its current state as it is broken in excalibur and
> doesn't even pass its unit tests.
3.
> Not if it will be deprecated in the future or any migration
> will be forced.
4.
> Not unless you show some real commitment to actually doing
> maintanence.
(1) has been settled by PMC - the point is out.
(2) is agreed upon - no discussion here.
(3) is unreasonable, and you know it.
(4) is contested - it seems like we have different opinions on
what Apache delevlopment is.
So can I throw out points 1-3 and focus on 4?
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Fri, 14 Mar 2003 01:39, Leo Sutic wrote:
> > There is no rub - ownership of code is collective, not individual.
> > However, as an individual, I'm happy to assume the responsibility of
> > finishing what I start - so if I start making a change to a stable
> > package, I will leave it in a stable form - success or rollback.
>
> Proof is in the pudding.
Of what - that there is a rub, or my ability to execute the proposed
changes?
> > Why do you need to designate individual maintainers of
> > pieces of code?
>
> Because it is not being maintained in Avalon now and it is
> unlikely it will be maintained in Avalon in the future.
Unlikely in the sense that we're getting rid of parts of Avalon
that are out of scope. But take CLI for example - what
maintenance is needed? The code works, is solid, and basically
isn't about to rot. By committment to doing maintenance -
just what do you mean?
This is how I see it:
1. There is general consensus that we prefer intra-apache
dependencies (i.e. Commons).
2. Phoenix uses Excalibur CLI, which we've deprecated.
3. Due to (2), Phoenix is now dependent on Spice.
4. But, there is no need for that dependency - Phoenix
can depend on Excalibur/Compatibility. You and everyone
else can develop the CLI project under Compatibility
just as well as you can do it under Spice.
5. I don't use Phoenix, probably never will, but I
see this as a little smudge on my otherwise perfect
dependency tree (as defined by my propably perverted
sensibilities).
6. So I offer to re-set the dependency to Excalibur/Compat.
So, I don't get this maintenance part. If I leave it in a stable
state - and coder X goes in a breaks it, shouldn't then coder X
fix it? I.e. everyone is responsible for maintaining the code
in a stable functioning state. Sort of a "transactional" approach.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Because it is not being maintained in Avalon now and it is
> unlikely it will be maintained in Avalon in the future.
I suppose that is the idea behind the culling ... Avalon wants to support
its core code, and migrate to use common code where possible.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 01:39, Leo Sutic wrote:
> There is no rub - ownership of code is collective, not individual.
> However, as an individual, I'm happy to assume the responsibility
> of finishing what I start - so if I start making a change to a stable
> package, I will leave it in a stable form - success or rollback.
Proof is in the pudding.
> Why do you need to designate individual maintainers of pieces of code?
Because it is not being maintained in Avalon now and it is unlikely it will be
maintained in Avalon in the future.
--
Cheers,
Peter Donald
--------------------------------------------------
Logic: The art of being wrong with confidence...
--------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Fri, 14 Mar 2003 00:32, Leo Sutic wrote:
> > Number 1: By deprecated, do you mean code marked with @deprecated,
or
> > code that isn't marked so, but no longer considered part of Avalon
> > proper? I'm fine with removing @deprecated tags from CLI, if that's
> > what you want, but I'm not fine with pulling it out of the
> > compatibility project again.
>
> funny thing is it should not be in the compatability project
> as I -1'ed that
> but then again maybe some people are more equal than others.
I consider this one closed by PMC action.
> > I'll make the change and leave you in a nice, stable state.
> > If I fuck up the change, I will fix it. But I don't consider
> > this - and I see no reason to do so - as a perpetual committment
> > to fix things in Excalibur CLI.
>
> And theres the rub. If no one is willing to maintain it in
> Avalon - why is it in Avalon?
There is no rub - ownership of code is collective, not individual.
However, as an individual, I'm happy to assume the responsibility
of finishing what I start - so if I start making a change to a stable
package, I will leave it in a stable form - success or rollback.
Why do you need to designate individual maintainers of pieces of code?
Isn't that the problem which damn near shattered Avalon previously,
when we had a number of prima donnas and fiefdoms?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 14 Mar 2003 00:32, Leo Sutic wrote:
> Number 1: By deprecated, do you mean code marked with @deprecated,
> or code that isn't marked so, but no longer considered part of
> Avalon proper? I'm fine with removing @deprecated tags from CLI,
> if that's what you want, but I'm not fine with pulling it out
> of the compatibility project again.
funny thing is it should not be in the compatability project as I -1'ed that
but then again maybe some people are more equal than others.
> I'll make the change and leave you in a nice, stable state. If I fuck
> up the change, I will fix it. But I don't consider this - and I see
> no reason to do so - as a perpetual committment to fix things in
> Excalibur CLI.
And theres the rub. If no one is willing to maintain it in Avalon - why is it
in Avalon?
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Thu, 13 Mar 2003 23:57, Leo Sutic wrote:
> > Look, how about we meet half way - would you support going back to
> > Excalibur CLI (hosted in the Excalibur compatibility project here at
> > Apache), if I do the work?
>
Just numbering your points - see below and I'll deal with them.
1.
> Not if it is deprecated as there is no need to add
> dependencies to deprecated code unless it is compatability
> layers.
2.
> Not if it is in its current state as it is broken in excalibur and
> doesn't even pass its unit tests.
3.
> Not if it will be deprecated in the future or any migration
> will be forced.
4.
> Not unless you show some real commitment to actually doing
> maintanence.
Peter,
I think some of your requirements are unreasonable. Number (2)
I'm fine with - I consider that part of the job. When I'm done
you'll have Phoenix running just as you have today, except with
Excalibur CLI instead of Spice CLI.
Number 1: By deprecated, do you mean code marked with @deprecated,
or code that isn't marked so, but no longer considered part of
Avalon proper? I'm fine with removing @deprecated tags from CLI,
if that's what you want, but I'm not fine with pulling it out
of the compatibility project again.
Number 3: That's not something I can promise, and you know that.
This requirement is completely and utterly unreasonable.
Number 4: Given that the only difference for you after the change
will be that the code will be hosted at Apache and that it will be
in an Avalon package instead of Spice, I really don't see why
you can't do any maintenance you need of the code after the move.
I don't consider myself completely and solely responsible for a
piece of code just by touching it. What, can I shove it over on the
next person touching it?
I'll make the change and leave you in a nice, stable state. If I fuck
up the change, I will fix it. But I don't consider this - and I see
no reason to do so - as a perpetual committment to fix things in
Excalibur CLI.
If you have a reason, I'd like to hear it.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 13 Mar 2003 23:57, Leo Sutic wrote:
> Look, how about we meet half way - would you support going back to
> Excalibur CLI (hosted in the Excalibur compatibility project here
> at Apache), if I do the work?
Not if it is deprecated as there is no need to add dependencies to deprecated
code unless it is compatability layers.
Not if it is in its current state as it is broken in excalibur and doesn't
even pass its unit tests.
Not if it will be deprecated in the future or any migration will be forced.
Not unless you show some real commitment to actually doing maintanence.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "The whole problem with the world is that fools and |
| fanatics are always so certain of themselves, but |
| wiser people so full of doubts." - Bertrand Russell |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> errr .. like the vetos I have given since I have been back
> that have been completely ignored so far?
Start a thread named "Ignored Vetoes", list 'em, and I'm sure
they can be resolved.
> I just don't want it to be part of framework or something I
> have to support at any stage in the future.
Exactly.
> Technically I think it is crap
Given the sensitivity of the subject, and the fact that you
did get an apology, I think you should be nice enough to not
say such things.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 13 Mar 2003 23:57, Leo Sutic wrote:
> > The problem occurs because people who don't contribute to a
> > component/area but are more than willing to tell others what
> > to do.
>
> There are times when one should speak up *fast* to stop something,
> or to avert something that may become a future problem.
errr .. like the vetos I have given since I have been back that have been
completely ignored so far?
> For example, I oppose the Spice dependency as I see it leading to
> future problems - licensing, dependencies, etc. You did much the
> same regarding the Lifecycle-in-Framework discussion.
You misinterpret. I don't really care if lifecycle is part of fortress or not.
I just don't want it to be part of framework or something I have to support
at any stage in the future. Technically I think it is crap but if someone
else wants to support it and implement it then goodluck to em. Best way to
learn is to do - it is how most people came around to my marker interfaces
are evil meme :) I may even be wrong and in 6 months could change my mind -
it has happened before (re legacy/wrapper stuff in framework) but usually I
have a pretty good track record of spotting crap code.
> Only if the other person is totally
> uninterested in a compromise or in figuring out a solution is there
> a problem. But I haven't seen much of that here.
It only takes one time.
--
Cheers,
Peter Donald
---------------------------------------------------
"Therefore it can be said that victorious warriors
win first, and then go to battle, while defeated
warriors go to battle first, and then seek to win."
- Sun Tzu, the Art Of War
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> On Thu, 13 Mar 2003 20:42, Leo Sutic wrote:
> > 1. Because the Avalon project voted that we should migrate to
> > Commons CLI and not Spice CLI.
>
> Nope.
>
> I would have vetoed any code change that led to that.
And you did. My mistake - my view of reality appears distorted.
However, I blame it all on Berin - his "Evening out the Release
Schedule" thread listed Excalibut CLI -> Commons CLI as a migration
path.
http://marc.theaimsgroup.com/?l=avalon-dev&m=104698191317412&w=2
Either that, or the dog ate my email.
> As Noel pointed out I have pointed out the problems I have
> with it numerous times in the past.
Those issues being:
1. It has additional dependencies
2. It's not under our control
(1) appeared fairly inconsequential - it had deps on Commons/Lang.
As for (2) well, Spice isn't either, is it?
> > and then ket us help you resolve them instead of going off
> > by yourself 90 degrees from the voted and decided path.
>
> Actually Berin was supportive when I mentioned it the first
> time which is why I did it. (And I plan to do the same to parts
> of io as long as it remains deprecated and there is no high quality
> alternative).
Well, I think there's a difference of interpertation here.
I think you refer to this mail:
http://marc.theaimsgroup.com/?l=avalon-dev&m=104583538310053&w=2
PeterD: No need to deprecate something that works and is mor
PeterD: eloosely coupled than the alternative. However it may
PeterD: be best to move it out of Avalon.
Berin: I think that is what everyone wants. I have no problems with the
Spice
Berin: project hosting it.
I interpreted "hosting" as just taking the existing code as-is, and,
well, host it. I.e. put in on a server. I didn't read that as
fold it into the spice project by:
+ changing license
+ renaming packages
+ making Avalon code dependent on Spice-licensed code.
With Excalibur CLI migrating to a compatibility project, I'd prefer
to have Phoenix depend on *that*, and then, perhaps, move to Commons CLI
if it ever should become acceptable.
> The basic thing is that there is plenty of code in Avalon
> that was written by me and was basically only maintained by
> me.
> Some of it sucks, some is usable and some is good. If
> Avalon wants it out then I am more than happy to move it
> out and will do so.
Well, there's moving out and moving out. I think the moving out
of Excalibur CLI has not been done in quite the way I thought it
would happen, and not quite in the way I think is best for Avalon.
> The problem occurs because people who don't contribute to a
> component/area but are more than willing to tell others what
> to do.
There are times when one should speak up *fast* to stop something,
or to avert something that may become a future problem.
For example, I oppose the Spice dependency as I see it leading to
future problems - licensing, dependencies, etc. You did much the
same regarding the Lifecycle-in-Framework discussion.
I don't see this as a problem.
If I make a change to some code that someone else thinks is bad
because it will cause problems down the road for some reason, I
don't mind hearing that person. Only if the other person is totally
uninterested in a compromise or in figuring out a solution is there
a problem. But I haven't seen much of that here.
Look, how about we meet half way - would you support going back to
Excalibur CLI (hosted in the Excalibur compatibility project here
at Apache), if I do the work?
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>
>
>>I have reviwed all occurances of the usage of the excalibur CLI package
>>that I was able to identity across the CVS repositories
>>
>>
>
>
>
>>In each case the CLI usage patterns were consitent with the
>>functioanlity provided by the Jakarta Commons CLI package.
>>
>>
>
>So you are representing that there are no functional issues in terms of the
>code?
>
No functional issues.
Furthermore, the Commons CLI includes greater functionality than the
Excalibur CLI package.
>Am I to understand that the ONLY issue is that Jakarta Commons CLI
>has some additional external dependencies that would require more jar files?
>
If the Commons CLI package is used in a manner equivalent to the
Excalibur CLI package you can use the commons CLI jar without any other
jar file (which is perfectly acceptable when the usage of the CLI code
is not exposed - as is that case with all usages of Excalibur CLI that I
was able to idetify). In other words - the dependency argument is
technically missleading. If anyone wants to see a dmonstration that
proves this - just let me know and I will post links as appropriate.
>If that is the only issue, how hard would it be to reduce or eliminate those
>are requirements, and leave them as optional?
>
Its already possible - just leave out the depedent commons-lang jar
file. It is only required if you want to parse command line expressions
into Java objects (which is accademic relative to the set of features
common to the Commons/Excalibur solutions).
>And if that were done, does it eliminate the reasons not to migrate?
>
AFAICS thare arre no reasons not to migrate.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
> I have reviwed all occurances of the usage of the excalibur CLI package
> that I was able to identity across the CVS repositories
> In each case the CLI usage patterns were consitent with the
> functioanlity provided by the Jakarta Commons CLI package.
So you are representing that there are no functional issues in terms of the
code? Am I to understand that the ONLY issue is that Jakarta Commons CLI
has some additional external dependencies that would require more jar files?
If that is the only issue, how hard would it be to reduce or eliminate those
are requirements, and leave them as optional? And if that were done, does
it eliminate the reasons not to migrate?
Note: there would still need to be Excalibur CLI in AV4, if only to bridge
to Commons, to preserve binary compatibility.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>> 1. Because the Avalon project voted that we should migrate to
>>> Commons CLI and not Spice CLI.
>>>
>>>
>
>My understanding is that the Avalon Community has adopted a policy that what
>it considers its core functionality should rely upon standard, maintained,
>packages, rather than expending resources to maintain ancillary,
>semi-competitive, packages. Standard appears to be defined as either
>java.*, javax.*, or org.apache. Apparently, CLI is not considered part of
>the core functionality.
>
>In some cases, I have seen arguments that a standard package isn't suitable
>because it has incompatible interfaces, e.g., precludes IoC/SoC. Even so,
>it might be acceptable for Avalon to use adapter classes rather than
>complete implementations where possible.
>
>
>
>>I would have vetoed any code change that led to that. I was opposed to
>>the deprecation of a stable working library
>>
>>
>
>
>
>>As Noel pointed out I have pointed out the problems I have
>>with it numerous times in the past.
>>
>>
>
>Once more won't hurt. Let's focus on the technical. What are the technical
>issues that block migrating Avalon dependency from its own CLI to Commons
>CLI? What would have to be done with Commons CLI to eliminate the
>objections?
>
Noel:
I have reviwed all occurances of the usage of the excalibur CLI package
that I was able to identity across the CVS repositories I have locally,
and any available Gump references I was able to track down. The lead me
to the review of the Phoenix project, Cocoon, and Turbine. In each case
the CLI usage patterns were consitent with the functioanlity provided by
the Jakarta Commons CLI package. I made a note to that effect on this
list when the dicussions took place concerning a community policy of
migration from Excalibur CLI towards Commons CLI.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Spice Dependency (was: RE: Spice License)
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > 1. Because the Avalon project voted that we should migrate to
> > Commons CLI and not Spice CLI.
My understanding is that the Avalon Community has adopted a policy that what
it considers its core functionality should rely upon standard, maintained,
packages, rather than expending resources to maintain ancillary,
semi-competitive, packages. Standard appears to be defined as either
java.*, javax.*, or org.apache. Apparently, CLI is not considered part of
the core functionality.
In some cases, I have seen arguments that a standard package isn't suitable
because it has incompatible interfaces, e.g., precludes IoC/SoC. Even so,
it might be acceptable for Avalon to use adapter classes rather than
complete implementations where possible.
> I would have vetoed any code change that led to that. I was opposed to
> the deprecation of a stable working library
> As Noel pointed out I have pointed out the problems I have
> with it numerous times in the past.
Once more won't hurt. Let's focus on the technical. What are the technical
issues that block migrating Avalon dependency from its own CLI to Commons
CLI? What would have to be done with Commons CLI to eliminate the
objections?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Spice Dependency (was: RE: Spice License)
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 13 Mar 2003 20:42, Leo Sutic wrote:
> 1. Because the Avalon project voted that we should migrate to
> Commons CLI and not Spice CLI.
Nope.
I would have vetoed any code change that led to that. I was opposed to
the deprecation of a stable working library and would have blocked it if there
was not support for migrating it out.
> A more constructive approach
> would have been for you to explain the problems with Commons CLI
As Noel pointed out I have pointed out the problems I have with it numerous
times in the past.
> and then ket us help you resolve them instead of going off
> by yourself 90 degrees from the voted and decided path.
Actually Berin was supportive when I mentioned it the first time which is why
I did it. (And I plan to do the same to parts of io as long as it remains
deprecated and there is no high quality alternative).
The basic thing is that there is plenty of code in Avalon that was written by
me and was basically only maintained by me. Some of it sucks, some is usable
and some is good. If Avalon wants it out then I am more than happy to move it
out and will do so.
Given the fact that few people are willing to actually do any work in actually
maintaining the majority oof these libraries I think it would best if they
moved out anyways.
Avalons track record wrt to stability and quality control is fairly piss poor
except for framework/logkit/phoenix. Hell I have had my code broken 4 times
in the last 3 weeks let alone any extended period.
The problems in Avalon are far more than just interaction between me and
Stephen. The problem occurs because people who don't contribute to a
component/area but are more than willing to tell others what to do. Worse is
when these changes are made but never maintained. I would love it if
everytime someone voted or made a commit they were also giving a guarentee
that they would support the change.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| An expert is someone who knows everything about the |
| topic except for its place in the world. |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org