Team Work and *my* approach to open source (Was: LONG JAMES v2.4 Road Map)

[Stefano Bagnara <ap...@bago.org>]

Bernd Fondermann wrote:
> [...]
> There is some truth in this. But Eclipse is driven by companies, it is
> like a software company.
> We are not this way.  That does not mean we aren't successfull, but
> this is not an objective opinion either ;-) I am not willing to follow
> strict release cycles. But it would be good to have a common
> perspective. That's what is still evolving from the mailing list
> discussion. It is not simply a thing of voting.

I really agree on the whole paragrapg but the last sentence: I think 
that it is ok to use the vote as a pragmatic way to define the limits of 
our discussions. I don't like to discuss ages without a conclusion when 
I know we could have done both of our different ideas if we simply 
discussed less and to end up without anything done. I think I'm able to 
work in team but the team works if we agree we have advantages in 
working together.

You brought us the biggest new feature in James: Unit tests.

I think that your contribution, in term of code, is what is making me 
more happy to be still in James and not working on my own local branch.

Now we have 25% unittest coverage in trunk and this is really a good 
step forward if we consider that 1 year ago we had 0%! I always thought 
that test was one of the biggest requirements for James but I never had 
the willing to start working on it.

This is to say that often it is not the consensus or the friendship that 
keep us in a group but simply a concrete reasoning: before you started 
providing the unittests I worked *alone* for maybe 6 months and I also 
had to fight for my ideas or even few refactorings to be accepted. I 
lost much more time than I would have need to do all of this in my local 
branch. In fact I still have to commit a lot of things that I developed 
2 years ago in my local branch and that I never been able to commit or I 
delayed because of major changes needed (ESMTP DSN support as an example 
, mass remote delivery service as another example) and if it wasn't for 
you and Norman I would have probably "left" the project.

I often had different ideas from you but I think we have to find 
compromises if we want to take the advantages of a bigger team.

As an example your first tests used ristretto: i thought that it was not 
good to james because of licensing (and maybe other I don't remember 
now). I could have said "-1 to commit it, +1 if YOU replace ristretto 
with commons-net" and start discussions about why using commons-net over 
ristretto and so on.. instead I preferred to work on the commons-net 
change and we have been all happy with it.

Stefano


---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Team Work and *my* approach to open source (Was: LONG JAMES v2.4 Road Map)

[Bernd Fondermann <be...@googlemail.com>]

On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > [...]
> > There is some truth in this. But Eclipse is driven by companies, it is
> > like a software company.
> > We are not this way.  That does not mean we aren't successfull, but
> > this is not an objective opinion either ;-) I am not willing to follow
> > strict release cycles. But it would be good to have a common
> > perspective. That's what is still evolving from the mailing list
> > discussion. It is not simply a thing of voting.
>
> I really agree on the whole paragrapg but the last sentence: I think
> that it is ok to use the vote as a pragmatic way to define the limits of
> our discussions.

+1, fully.

What I wanted to emphasize is: It's not only a matter of proposing and
voting _alone_.
proposal = bone
discussion = flesh
vote = skin
well, then comes development, of course...

_all_ of those taking part in the discussions are required to discuss
+ technical
+ short and on the point
+ on-topic or fork new thread
+ be consent driven

if everyone remembers those points before hitting "send", you will
see, discussion outcome will dramatically improve.
there is _so_ much noise, repetition and re-iteration going on
currently, I have trouble following.
I bet others have the same problems, too.

BTW, that also applies to the number of proposals that get started
virtually in parallel. I have noticed all, I have read some, I
understood 1 or 2, I will try to answer all of them. My apologies for
not having more time for them. Really, there is so much good stuff you
put out, I only wish I had more time. If this is causing frustration
on some part: it is not ingorance, it is the missing time.

> I don't like to discuss ages without a conclusion when
> I know we could have done both of our different ideas if we simply
> discussed less and to end up without anything done. I think I'm able to
> work in team but the team works if we agree we have advantages in
> working together.

OK, agreed, help us to keep disussions short. ;-)

> You brought us the biggest new feature in James: Unit tests.
>
> I think that your contribution, in term of code, is what is making me
> more happy to be still in James and not working on my own local branch.

Wait for the stuff I am going to contribute in future! ;-)
I, for my part, like Postage much more than the unit tests. But
obviously opinions vary.

<snip/>
>  instead I preferred to work on the commons-net
> change and we have been all happy with it.

that was cool, couldn't have done that myself so quickly, many thanks again.

  Bernd

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org