CVS Karma?

[Peter Donald <do...@apache.org>]

Hi,

I would like to propose a flattening of CVS karmas between our projects
(james/avalon). What this would mean is that if you have commit access to
avalon you have commit access to james and vice versa. The reason for this
is that it would encourage us to have more interaction.

It would also help us avoid incompatabilities. For example I know that in
the next release of Avalon I am going to change things that will break
james. With a flattening of permissions I could go in with a preemptive
strike and update James so that the anoying gump messages don't scream
"James is broken" each day ;) Likewise if you find a bug in the pooling
code or connection manager you can go direct to the source and fix it. As
we are dealing with CVS we will always be able to revert it if it is wrong.

I would also like to propose that the developers in alexandria/gump be
given access to the CVS repositories. They are working on a system that
automagically generates documentation across the projects and does dailys
builds and in the future hopefully unit testing. Giving them access would
allow them to quickly change bugs that crop up in our build processes that
are simple to fix. We can always revert a change if it is bad.

Votes/Comments?


Cheers,

Pete

*-----------------------------------------------------*
| "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               |
*-----------------------------------------------------*

[Very important] avalon 4.0 proposal.

[Federico Barbieri <sc...@betaversion.org>]

There is a proposal/4.0 folder in tha jakarta-avalon cvs wich is the
"work in progress" rearchitecturing/cleaning for the 4.0 framework
generation. It's a tuning of all design patterns and contract, nothing
to do with the kernel implementation so I think it's something we should
work on toghether. 

Please take a deep look and let's work out a nice solution that can make
everybody's happy. 

Most discussions will be on the avalon list since cross posting can be a
real pain so please subcribe and express your opinion. To ease things
from now on each discussion on the proposal will have [proposal] in the
subject. The more we are the best solutoin we can find and we will be
all prepared and willing to move to the new generation.

Fede

Re: CVS Karma?

[Matthew Pangaro <mp...@lokitech.com>]

That all sounds good and reasonable to me. Of course I'm not a committer.

BTW, I never saw a response to my follow-up on the message size limiting
patch. I had posted a second patch that only pre-loaded the MimeMessage if
the size limit was in effect. This hopefully would have prevented having to
have a second version of the SMTPHandler class. Don't know if I missed the
response, and haven't checked to see if the code was committed, since I'm
out of touch most of the time right now. Anyway, just curious.
Thanks,
Matt Pangaro
Loki Technologies

----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <av...@jakarta.apache.org>; <ja...@jakarta.apache.org>
Sent: Sunday, February 25, 2001 4:52 PM
Subject: CVS Karma?


> Votes/Comments?

[Very important] avalon 4.0 proposal.

[Federico Barbieri <sc...@betaversion.org>]

There is a proposal/4.0 folder in tha jakarta-avalon cvs wich is the
"work in progress" rearchitecturing/cleaning for the 4.0 framework
generation. It's a tuning of all design patterns and contract, nothing
to do with the kernel implementation so I think it's something we should
work on toghether. 

Please take a deep look and let's work out a nice solution that can make
everybody's happy. 

Most discussions will be on the avalon list since cross posting can be a
real pain so please subcribe and express your opinion. To ease things
from now on each discussion on the proposal will have [proposal] in the
subject. The more we are the best solutoin we can find and we will be
all prepared and willing to move to the new generation.

Fede

[Very important] avalon 4.0 proposal.

[Federico Barbieri <sc...@betaversion.org>]

There is a proposal/4.0 folder in tha jakarta-avalon cvs wich is the
"work in progress" rearchitecturing/cleaning for the 4.0 framework
generation. It's a tuning of all design patterns and contract, nothing
to do with the kernel implementation so I think it's something we should
work on toghether. 

Please take a deep look and let's work out a nice solution that can make
everybody's happy. 

Most discussions will be on the avalon list since cross posting can be a
real pain so please subcribe and express your opinion. To ease things
from now on each discussion on the proposal will have [proposal] in the
subject. The more we are the best solutoin we can find and we will be
all prepared and willing to move to the new generation.

Fede