You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/03/15 12:13:24 UTC
excalibur thread update
Have just committed some changes in the excalibur thread package linked
to the updates I made to excalibur-pool:
1. created an api/impl/instrumented package separation
- stripped out instrumentable support in
ResourceLimitingThreadPool
- added InstrumentedResourceLimitingThreadPool under
instrumented package that uses the excalibur-pool
InstrumentedResourceLimitingPool as the backing pool
2. removed deprecated ThreadControl and ThreadPool
3. removed references to deprecated classes in
BasicThreadPool and un-deprecated the class as there
does not seem to be a replacement and it is used in
non-deprecated content
4. un-deprecated ExecutableExecutable as it is used by
BasicThreadPool
5. removed dependence on excalibur component testcase
6. set version on all artifacts to SNAPSHOT
The original source and build content remains unchanged. Next step is
to validate the api and impl against cornerstone threads.
Cheers, Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur thread update
Posted by Stephen McConnell <mc...@apache.org>.
Noel:
Please - I understand what your concerns are. Yes - I have a different
set of priorities. The text of your email is not a veto - it is a
threat to veto. If you want to put up a veto then do it. State it
clearly, make sure you include the technical validation - and we can
deal with it from there.
Stephen.
Noel J. Bergman wrote:
>>The sources for excalibur thread 1.1.1 and excalibur pool 1.2 remain in
>>the respective /src directories and irrespective of anything going on
>>will not dissapear suddenly. Once I've got everything validated I'll
>>tag the /src content and remove it from CVS head assuming there is
>>consensus to do so.
>
>
> This will cause me to cast the first veto I have ever cast here. And I
> would not be surprised if Leif feels exactly the same way. I find it
> absolutely and totally unacceptable to effectively discard the development
> history. And we agree that the package separations, in your words,
> "introduce the history disconnect."
>
>
>>Yes - CVS history is an issue however its a issue that has to be
>>considered against the benefits of actually getting a clean
>>api/impl separation
>
>
> I don't dispute the benefits of refactoring.
>
> The only way forward that I see is to immediately adopt Subversion so that
> we can have all of the good work that we can build a consensus upon, without
> disconnecting significant portions of the Avalon codebase from its history.
>
> I am absolutely serious about this issue. We have a tool that prevents
> history from being lost. It is no longer acceptable to sacrifice history at
> the altar of functional improvement. As far as I am concerned, the
> perfectly reasonable desire to refactor Avalon code is mandating the switch
> to Subversion.
>
> Switching to Subversion so that we can refactor the code without
> disconnecting it from its history would remove my veto.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The sources for excalibur thread 1.1.1 and excalibur pool 1.2 remain in
> the respective /src directories and irrespective of anything going on
> will not dissapear suddenly. Once I've got everything validated I'll
> tag the /src content and remove it from CVS head assuming there is
> consensus to do so.
This will cause me to cast the first veto I have ever cast here. And I
would not be surprised if Leif feels exactly the same way. I find it
absolutely and totally unacceptable to effectively discard the development
history. And we agree that the package separations, in your words,
"introduce the history disconnect."
> Yes - CVS history is an issue however its a issue that has to be
> considered against the benefits of actually getting a clean
> api/impl separation
I don't dispute the benefits of refactoring.
The only way forward that I see is to immediately adopt Subversion so that
we can have all of the good work that we can build a consensus upon, without
disconnecting significant portions of the Avalon codebase from its history.
I am absolutely serious about this issue. We have a tool that prevents
history from being lost. It is no longer acceptable to sacrifice history at
the altar of functional improvement. As far as I am concerned, the
perfectly reasonable desire to refactor Avalon code is mandating the switch
to Subversion.
Switching to Subversion so that we can refactor the code without
disconnecting it from its history would remove my veto.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur thread update
Posted by Stephen McConnell <mc...@apache.org>.
Noel:
The sources for excalibur thread 1.1.1 and excalibur pool 1.2 remain in
the respective /src directories and irrespective of anything going on
will not dissapear suddenly. Once I've got everything validated I'll
tag the /src content and remove it from CVS head assuming there is
consensus to do so. But that's a subject for later.
The immediate subject of the api, impl, and instrumented package
separations (which introduce the history disconnect) deal with the
following problems:
1. the practice of including optional classes in a package
definition which plays havoc with automated resource
loading - addressed through separation of the api from
implementation, and secondly, through separation of
different implementation variants based on dependencies
2. cleaning up of the codebase to bring it into a
maintainable state while maintaining the current 1.X
codebase - involving the establishment of a 2.X major
version increment and removal of deprecated content
Yes - CVS history is an issue however its a issue that has to be
considered against the benefits of actually getting a clean api/impl
separation in place and validated, enabling the assessment of the real
ramifications of updated apis throughout the codebase. So far the
ramifications arising from the excalibur and cornerstone updates involve
the following:
* replacement of deprecated org.apache.avalon.excalibur.thread
with org org.apache.excalibur.thread for ThreadControl, ThreadPool
and Executable
* usage of DefaultPool/getSize replaced by DefaultPool/size
* users of instrumented pools and thread pools migrating to the
instrumented package and instrumented implementations.
* clients dependent on the connection handler factory implementations
in cornerstone connection will need to include the impl jar into
the classpath
As far as the impact on James is concerned - according to the result of
building james against the updated content:
SimpleConnectionManager, removal of the placeholder operation
that adapts between the deprecated and non-deprecated ThreadPool.
AbstractJamesService, removal of the casting to the deprecated
ThreadPool interface.
A couple of minor code updates relating to context references
that I don't completely understand just at the moment but relate
to the addition of native avalon descriptors in the cornerstone
blocks.
Aside from that I have james running against the candidate excalibur
content, the candidate cornerstone blocks, and a very slightly modified
james head. I can send you a diff if you like.
Stephen.
Noel J. Bergman wrote:
>>>> 2. removed deprecated ThreadControl and ThreadPool
>>>
>>>it sounds as if we just broke
>>>org.apache.james.util.thread.DefaultThreadPool.
>
>
>>Nothing is broken.
>
>
> Oh?
>
>
>>James is not dependent on the updates I have made.
>
>
> Are the updates going into a release that James should be using? Did you
> look at the code in James that I referenced?
>
>
>>If James is dependent on deprecated interfaces then in order
>>to migrate from a 1.X to a 2.X James code would need to be updated.
>
>
> Deprecation is not removal. There is a reason why Sun has left the
> deprecated interaces in J2SE, rather than remove them. But this is a minor
> point compared to the one that really has me going.
>
>
>>>Unfortunately, with all of the shuffling of file locations, we've
>>>effectively lost all of the CVS history, so when I look at
>>>something like
>>>
>
> http://cvs.apache.org/viewcvs.cgi/avalon-xcalibur/thread/impl/src/java/org/a
> pache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there
>
>>>is no history *at all* to see.
>
>
>>None of the current codebase has been touched. You have full CVS
>>history under the src directory.
>
>
> So then what is in
> http://cvs.apache.org/viewcvs.cgi/avalon-xcalibur/thread/impl/src/java/org/a
> pache/avalon/excalibur/thread/impl? Is that a throwaway, or the new
> location? If it isn't clear, that is rhetorical. The old code is replaced
> by the new refactoring, and the history has been lost from the perspective
> of the code. I cannot find the history without chasing down which file is
> the current one for where, and where that file came from before, and
> mentally link together the history. History should not be distributed and
> disconnected from the code.
>
>
>>If someone wants to help on things like getting CVS history updated -
>
> great.
>
> CVS doesn't work that way. You are running into one of those areas where
> CVS is a disaster, and SVN shines. With SVN, we could do:
>
> svn cp MyClass MyClassInterface
> svn mv MyClass MyClassImpl
>
> and commit changes so that one is the interface, one is the implementation,
> and no history is lost. We could sort of do that in CVS, but it would
> require copying the actual ",v" files, is not accessible to most, and has
> other bad consequences.
>
>
>>THE LOGS ARE NOT GONE.
>
>
> Yes they are. Maybe not from the current location, until someone says "Oh,
> we don't need those anymore, since they've been refactored", but from a
> practical perspective, they are gone: the code is no longer attached its
> history.
>
>
>>I'm interested in getting some of the excalibur content into a
>>maintainable state - and that means getting rid of the
>>deprecated content.
>
>
> There are two issues. One is that you are changing interfaces. The other
> is that as you are doing it, you are separating the code from its history.
> I am far more concerned and annoyed about the latter, although I don't
> believe that you are taking stability of interfaces seriously enough as a
> platform provider. I'll accept that some interface change is necessary to
> get the code to a more stable place. The disconnecting of code from history
> is a more serious issue.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>> 2. removed deprecated ThreadControl and ThreadPool
>> it sounds as if we just broke
>> org.apache.james.util.thread.DefaultThreadPool.
> Nothing is broken.
Oh?
> James is not dependent on the updates I have made.
Are the updates going into a release that James should be using? Did you
look at the code in James that I referenced?
> If James is dependent on deprecated interfaces then in order
> to migrate from a 1.X to a 2.X James code would need to be updated.
Deprecation is not removal. There is a reason why Sun has left the
deprecated interaces in J2SE, rather than remove them. But this is a minor
point compared to the one that really has me going.
> > Unfortunately, with all of the shuffling of file locations, we've
> > effectively lost all of the CVS history, so when I look at
> > something like
> >
http://cvs.apache.org/viewcvs.cgi/avalon-xcalibur/thread/impl/src/java/org/a
pache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there
> > is no history *at all* to see.
> None of the current codebase has been touched. You have full CVS
> history under the src directory.
So then what is in
http://cvs.apache.org/viewcvs.cgi/avalon-xcalibur/thread/impl/src/java/org/a
pache/avalon/excalibur/thread/impl? Is that a throwaway, or the new
location? If it isn't clear, that is rhetorical. The old code is replaced
by the new refactoring, and the history has been lost from the perspective
of the code. I cannot find the history without chasing down which file is
the current one for where, and where that file came from before, and
mentally link together the history. History should not be distributed and
disconnected from the code.
> If someone wants to help on things like getting CVS history updated -
great.
CVS doesn't work that way. You are running into one of those areas where
CVS is a disaster, and SVN shines. With SVN, we could do:
svn cp MyClass MyClassInterface
svn mv MyClass MyClassImpl
and commit changes so that one is the interface, one is the implementation,
and no history is lost. We could sort of do that in CVS, but it would
require copying the actual ",v" files, is not accessible to most, and has
other bad consequences.
> THE LOGS ARE NOT GONE.
Yes they are. Maybe not from the current location, until someone says "Oh,
we don't need those anymore, since they've been refactored", but from a
practical perspective, they are gone: the code is no longer attached its
history.
> I'm interested in getting some of the excalibur content into a
> maintainable state - and that means getting rid of the
> deprecated content.
There are two issues. One is that you are changing interfaces. The other
is that as you are doing it, you are separating the code from its history.
I am far more concerned and annoyed about the latter, although I don't
believe that you are taking stability of interfaces seriously enough as a
platform provider. I'll accept that some interface change is necessary to
get the code to a more stable place. The disconnecting of code from history
is a more serious issue.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur thread update
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>Have just committed some changes in the excalibur thread package
>>linked to the updates I made to excalibur-pool
>
>
>> 2. removed deprecated ThreadControl and ThreadPool
>
>
> If Avalon's ResourceLimitingPool is finally working properly, so that we
> don't need the one in James, let me know. Otherwise, it sounds as if we
> just broke org.apache.james.util.thread.DefaultThreadPool.
Nothing is broken.
James is not dependent on the updates I have made. If James is dependent
on deprecated interfaces then in order to migrate from a 1.X to a 2.X
James code would need to be updated.
See:
> http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/uti
> l/thread/?only_with_tag=branch_2_1_fcs
>
> If everything works, I could use
> http://cvs.apache.org/viewcvs.cgi/avalon-components/cornerstone/threads/impl
> /src/java/org/apache/avalon/cornerstone/blocks/threads/ResourceLimitingThrea
> dManager.java. However, there were bugs in the Avalon code in the past. I
> know that Leif did some work on parts of it back in the same timeframe when
> I extracted the necessary code for James to work, but I don't know if he got
> to all of the bugs. Unfortunately, with all of the shuffling of file
> locations, we've effectively lost all of the CVS history, so when I look at
> something like
> http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/
> apache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there
> is no history *at all* to see.
None of the current codebase has been touched. You have full CVS
history under the src directory. Yes - checking out a diff between
sources in different directories is not automatic - but not impossible
either.
> If we are going to keep re-organizing code, perhaps it is time to get into
> Subversion, so that we stop losing the change history? If you look here:
> http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/
> apache/avalon/excalibur/thread/impl/, not one file has any change history.
> And don't tell me to go look in the Attic somewhere.
I'm not telling you to go looking in an attic - I am saying that the
packages I've been addressing need to be brought into a manageable
state. What I'm doing it to verify if this is reasonable or not. So
far things are looking positive but its far from a done deal. If
someone wants to help on things like getting CVS history updated - great.
> If I come across as a bit annoyed, actually I am. I spent a lot of time in
> the past to trace through the code. Now I want to go back and see if
> problems were fixed so that we can use the new code. But the change logs
> are gone,
THE LOGS ARE NOT GONE.
so I have to re-analyze the code from scratch. That's pretty much
> an incentive to use the already tested code in the James CVS, except that
> the interface changes mean that code is broken, too.
>
> Am I getting my point(s) across?
Not really.
What you are getting across is that there is content in James that
addresses apparent issues with the excalibur-thread package. All of the
cvs history for cornerstone and excalibur threads and pool are available.
Please note that some projects will never upgrade and that the 1.X
series in excalibur (together with the myriad of deprecations) will
remain in cvs under tag. In the meantime I'm interested in getting some
of the excalibur content into a maintainable state - and that means
getting rid of the deprecated content.
Stephen.
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur thread update
Posted by Leif Mortenson <le...@tanukisoftware.com>.
Noel,
I had not built the latest pool code from CVS in a while. But I
make use of the
ResourceLimitingPool from excalibur-pool-1.2 in several projects without any
problems. It has been a very long time since I was aware of any bugs
in that code
and had fixed the few that I was aware of.
As I wrote that, I checked out the latest code and did a build and
found that
tests were failing.
Looking at the code of the test, I don't see how it could have ever
passed reliably.
This is not the test that I originally committed. But I am not sure
originally rewrote it
to use JUnitPerf as the history is gone! Nicolas looks like he tried
to fix it recently.
But the fix was still highly dependent on CPU speed.
This was a bug with the test, not with the pool. But it is fixed
now and should
now pass reliably.
I agree 100% with the need to be careful about wiping out the CVS
history. As
a contributor. I find it very discouraging. Between that and the
removal of all author
tags in the source. It feels like evidence of much of the sweat time
and energy that
I have put into avalon has been removed. I do not contribute code
simply for
recognition. But I do not feel it is in anyway unreasonable to expect
that a record
of my work and recognition for who did that work remain in the code. I
know I
lost that argument a while back when the discussion of whether or not to
remove
the author tags came up. But at least then I thought there would be a
record of
my work in CVS.
You look through the pool package and there is now absolutely no
record that
I had ever existed. I am afraid to go look at the rest of the CVS
archive... It
does not encourage me to find time in my busy schedule to continue
contributing.
Cheers,
Leif
Noel J. Bergman wrote:
>>Have just committed some changes in the excalibur thread package
>>linked to the updates I made to excalibur-pool
>>
>>
>
>
>
>> 2. removed deprecated ThreadControl and ThreadPool
>>
>>
>
>If Avalon's ResourceLimitingPool is finally working properly, so that we
>don't need the one in James, let me know. Otherwise, it sounds as if we
>just broke org.apache.james.util.thread.DefaultThreadPool. See:
>http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/uti
>l/thread/?only_with_tag=branch_2_1_fcs
>
>If everything works, I could use
>http://cvs.apache.org/viewcvs.cgi/avalon-components/cornerstone/threads/impl
>/src/java/org/apache/avalon/cornerstone/blocks/threads/ResourceLimitingThrea
>dManager.java. However, there were bugs in the Avalon code in the past. I
>know that Leif did some work on parts of it back in the same timeframe when
>I extracted the necessary code for James to work, but I don't know if he got
>to all of the bugs. Unfortunately, with all of the shuffling of file
>locations, we've effectively lost all of the CVS history, so when I look at
>something like
>http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/
>apache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there
>is no history *at all* to see.
>
>If we are going to keep re-organizing code, perhaps it is time to get into
>Subversion, so that we stop losing the change history? If you look here:
>http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/
>apache/avalon/excalibur/thread/impl/, not one file has any change history.
>And don't tell me to go look in the Attic somewhere.
>
>If I come across as a bit annoyed, actually I am. I spent a lot of time in
>the past to trace through the code. Now I want to go back and see if
>problems were fixed so that we can use the new code. But the change logs
>are gone, so I have to re-analyze the code from scratch. That's pretty much
>an incentive to use the already tested code in the James CVS, except that
>the interface changes mean that code is broken, too.
>
>Am I getting my point(s) across?
>
> --- Noel
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Can you confirm if the following actions sounds plausible:
> 1. duplicate current excalibur/thread and pool src content in
> cvs to an equivalent svn repository
I believe that you need to move an entire CVS module at a time.
> 2. copy/branch/whatever the current excalibur/thread/src to
> thread/api and thread/impl and thread/instrumented
> (preserving history) and equivalent for pool
Yes, svn copy is the right thing. And you might create a tag before doing
so, in case someone wants easy access to the current packaging. Tags are
just a lightweight copy in Subversion.
See http://svnbook.red-bean.com, which is the definitive work on Subversion.
> 3. dump the duplicates between api and impl through a normal
> removal
Not sure what you mean here.
> 4. copy over the new content from the current CVS api
> impl and instrumented package over the svn content for the
> respective directories (generating historical diffs)
> 5. commit
Yes, you could copy your existing files from your CVS checkout to your SVN
checkout, and commit them. You don't have to edit all over again.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur thread update
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>I think he is the only one currently with objections. I don't
>>want him to be pressured into it.
>
>
> I don't want him to feel unduly pressured, but I don't really see that we
> have much choice. This isn't a matter of wanting to use a new toy or
> implement some agenda. Refactoring and CVS are incompatible. We need
> Subversion to be able to carry out the desired changes without disconnecting
> code from history. It is as fundemental as that. This is a major reason
> why Subversion was created.
Noel:
Can you confirm if the following actions sounds plausible:
1. duplicate current excalibur/thread and pool src content in
cvs to an equivalent svn repository
2. copy/branch/whatever the current excalibur/thread/src to
thread/api and thread/impl and thread/instrumented
(preserving history) and equivalent for pool
3. dump the duplicates between api and impl through a normal
removal
4. copy over the new content from the current CVS api
impl and instrumented package over the svn content for the
respective directories (generating historical diffs)
5. commit
Stephen.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
--
|------------------------------------------------|
| Magic by Merlin |
| Production by Avalon |
| |
| http://avalon.apache.org/merlin |
| http://dpml.net/merlin/distributions/latest |
|------------------------------------------------|
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Commit counts (was: RE: excalibur thread update)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Thursday 18 March 2004 04:21, Alex Karasulu wrote:
> > Now that it's a matter of loosing history this is no
> > longer a matter of preference. The history is something we
> owe to all
> > contributors and I think Niclas will appreciate that.
>
> Personally, I couldn't care less if the history of my work is
> available or
> not. I am listed as one of the developers, on equal terms
> with everyone else.
>
> I got blasted last time I put a foot forward and pointed towards who
> contribute and who doesn't, and was TOLD in rather sharp
> words, that who does the work doesn't matter.
Yes. The rationale is simply that you end up using the fact that
you went on a 800+ commits coding spree to justify that coding
spree.
For example, if I nuke Merlin from CVS, then I'm doing work. Since
I do the work, the rest of y'all should just accept what I'm doing,
right?
If you think the above is far-fetched, then consider what happens if
two committers with roughly equal committ counts disagree.
(If you have a hard time picturing it, go back in the archives and
check what happened prior to one committer having his commit rights
revoked was kicked.)
What this "it doesn't matter who does the work" accomplishes is
that everyone is forced to *talk to* the other developers, *establish
consensus* and so on. Keeps the community happy.
Trust me, you don't want to go to the land where number of commits
determine your standing. You really, really don't. It may seem
counter to your ideas of a meritocracy, but it is the least bad
system.
> Obviously it does now - So please, stop the HIPPOCRACY.
> Either it does matter (history is preserved, and I keep
> bugging about 'stop the rhetoric and do the work') or it
> does NOT matter (history is lost, and I'll shut up).
The "who did it" doesn't matter. This is for legal reasons. In
order for the ASF to be able to protect us the code must be
"by the ASF". That's why the @author tags were removed.
But having a changelog is good.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Wednesday, March 17, 2004 11:58 PM
> To: Avalon Developers List
> Subject: RE: excalibur thread update
>
> > So please, stop the HIPPOCRACY. Either it does matter (history
> > is preserved, and I keep bugging about 'stop the rhetoric and do
> > the work') or it does NOT matter (history is lost, and I'll shut up).
>
> Alex and Leif are concerned about history preserving contributions. But
> that is only one aspect of it. When I'm reviewing CVS histories, I rarely
> look to see WHO did something. I look at WHAT was fixed, changed,
> different.
Yes that's much more critical IMO and the 'who' question is only a part of
it. The 'who' only becomes important when you want to get in touch with ONE
OF THE AUTHORS when the comments are anemic. Excuse me for putting the
'who' in the forefront. It seems to be a sore spot to contributors. I
just want to dispel any ridiculous suspicion of a master plot to take
authorship away from anyone.
For the record I originally did not like the notion of stripping
away @author tags and after some thought it started to make a lot of
sense. We just need to think about the facts rather than being suspicious
then the reasons for removing the @author tag become crystal clear.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> So please, stop the HIPPOCRACY. Either it does matter (history
> is preserved, and I keep bugging about 'stop the rhetoric and do
> the work') or it does NOT matter (history is lost, and I'll shut up).
Alex and Leif are concerned about history preserving contributions. But
that is only one aspect of it. When I'm reviewing CVS histories, I rarely
look to see WHO did something. I look at WHAT was fixed, changed,
different.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Excalibur thread update
Posted by Alex Karasulu <ao...@bellsouth.net>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Thursday 18 March 2004 04:21, Alex Karasulu wrote:
> > Now that it's a matter of loosing history this is no
> > longer a matter of preference. The history is something we owe to all
> > contributors and I think Niclas will appreciate that.
>
> Personally, I couldn't care less if the history of my work is available or
> not. I am listed as one of the developers, on equal terms with everyone
> else.
> I got blasted last time I put a foot forward and pointed towards who
> contribute and who doesn't, and was TOLD in rather sharp words, that who
> does
> the work doesn't matter.
I never blasted anyone nor will I.
> Obviously it does now - So please, stop the HIPPOCRACY.
> Either it does matter (history is preserved, and I keep bugging about
> 'stop
> the rhetoric and do the work') or it does NOT matter (history is lost, and
> I'll shut up).
I've always have been a proponent of giving credit where credit is due
and would never take that away from anyone. However I think you're not
referring to me specifically but I had to say that regardless. I have
agreed to the removal of the @author tags because they are ambiguous and
actually take more away from the orig author of a file. The history is the
true judge of who did what. It's what is sacred not the @author tags.
I'm not here for the glamour, if any, with writing OS code but it's
important to maintain this history. To some, the credit is very important
and I can't judge their motives - everyone has their own reasons for
contributing. Personally for me it's to be part of something bigger than
myself. The fact however does remain that @author tags are ambiguous.
There is no hypocrisy in stating that and working hard to maintain
history.
Don't attach a moral judgment or notion of hidden agendas to the removal
of @author tags. Just work with the facts. @author does not mean anything
when the code is authored by a community. We'd be better off writing our
own doclet and have an @community custom tag and be done with it. Anyway
if you stop thinking people are trying to undermine the efforts of others
you'll be free to interpret just the facts. @author does nothing for
anyone. I can just change a file and add my own @author tag to it or
replace the original author's tag. There after people only see me as
the author. Javadocs have high visibility and authorship through the
@author tag can be very misleading especially to our users. It can actually
result in situations where perceived authorship is taken away from one
and granted to another. So the final verdict always rests with history.
In the history we can see those who really groked the code if that was
the question on the table. Treating @author tags as really meaning
@community tags and emphasizing the history as the master record in the
end protects people like you and Stephen who are working their buns off.
Disclaimer: I know others are working their buns off too.
Respectfully,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: excalibur thread update
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 18 March 2004 04:21, Alex Karasulu wrote:
> Now that it's a matter of loosing history this is no
> longer a matter of preference. The history is something we owe to all
> contributors and I think Niclas will appreciate that.
Personally, I couldn't care less if the history of my work is available or
not. I am listed as one of the developers, on equal terms with everyone else.
I got blasted last time I put a foot forward and pointed towards who
contribute and who doesn't, and was TOLD in rather sharp words, that who does
the work doesn't matter.
Obviously it does now - So please, stop the HIPPOCRACY.
Either it does matter (history is preserved, and I keep bugging about 'stop
the rhetoric and do the work') or it does NOT matter (history is lost, and
I'll shut up).
Niclas
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > I think he is the only one currently with objections. I don't
> > want him to be pressured into it.
>
> I don't want him to feel unduly pressured, but I don't really see that we
> have much choice. This isn't a matter of wanting to use a new toy or
I agree now with you after seeing Leif's email, which arrived after I had
sent the above. Now that it's a matter of loosing history this is no longer
a matter of preference. The history is something we owe to all contributors
and I think Niclas will appreciate that.
> implement some agenda. Refactoring and CVS are incompatible. We need
> Subversion to be able to carry out the desired changes without
> disconnecting
> code from history. It is as fundemental as that. This is a major reason
> why Subversion was created.
Yes absolutely.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I think he is the only one currently with objections. I don't
> want him to be pressured into it.
I don't want him to feel unduly pressured, but I don't really see that we
have much choice. This isn't a matter of wanting to use a new toy or
implement some agenda. Refactoring and CVS are incompatible. We need
Subversion to be able to carry out the desired changes without disconnecting
code from history. It is as fundemental as that. This is a major reason
why Subversion was created.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by Alex Karasulu <ao...@bellsouth.net>.
Noel,
> If we are going to keep re-organizing code, perhaps it is time to get into
> Subversion, so that we stop losing the change history? If you look here:
> http://cvs.apache.org/viewcvs.cgi/avalon-
> excalibur/thread/impl/src/java/org/
> apache/avalon/excalibur/thread/impl/, not one file has any change history.
> And don't tell me to go look in the Attic somewhere.
+1
I'm totally up for that. It might be a good time to see if Niclas is cool
with it again. I think he is the only one currently with objections. I
don't want him to be pressured into it. Consider this a ping for svn once
more.
Nick btw Noel might be able to find the trails where I adamantly was against
Subversion. I gave a real big fight not to have it. Can't believe I did
that but I was in your shoes and understand where you are coming from.
However resistance is futile :-)! Subversion is the future.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: excalibur thread update
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Have just committed some changes in the excalibur thread package
> linked to the updates I made to excalibur-pool
> 2. removed deprecated ThreadControl and ThreadPool
If Avalon's ResourceLimitingPool is finally working properly, so that we
don't need the one in James, let me know. Otherwise, it sounds as if we
just broke org.apache.james.util.thread.DefaultThreadPool. See:
http://cvs.apache.org/viewcvs.cgi/james-server/src/java/org/apache/james/uti
l/thread/?only_with_tag=branch_2_1_fcs
If everything works, I could use
http://cvs.apache.org/viewcvs.cgi/avalon-components/cornerstone/threads/impl
/src/java/org/apache/avalon/cornerstone/blocks/threads/ResourceLimitingThrea
dManager.java. However, there were bugs in the Avalon code in the past. I
know that Leif did some work on parts of it back in the same timeframe when
I extracted the necessary code for James to work, but I don't know if he got
to all of the bugs. Unfortunately, with all of the shuffling of file
locations, we've effectively lost all of the CVS history, so when I look at
something like
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/
apache/avalon/excalibur/thread/impl/ResourceLimitingThreadPool.java, there
is no history *at all* to see.
If we are going to keep re-organizing code, perhaps it is time to get into
Subversion, so that we stop losing the change history? If you look here:
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/thread/impl/src/java/org/
apache/avalon/excalibur/thread/impl/, not one file has any change history.
And don't tell me to go look in the Attic somewhere.
If I come across as a bit annoyed, actually I am. I spent a lot of time in
the past to trace through the code. Now I want to go back and see if
problems were fixed so that we can use the new code. But the change logs
are gone, so I have to re-analyze the code from scratch. That's pretty much
an incentive to use the already tested code in the James CVS, except that
the interface changes mean that code is broken, too.
Am I getting my point(s) across?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org