Re: LONG JAMES v2.4 Road Map

[Jürgen Hoffmann <jh...@byteaction.de>]

Hi to all Developers,

I have been following this thread for some time now. Being a Person
that is only watching, I came to the conclusion that You as Developers
have a totally different understanding as of what should be a 2.4
Release.

Right now you are quarreling about things that should be defined once
and then be clear to everyone. Looking at the Message History,
quarreling and endless discussions are quite common to this project.

I know I am an outsider talking, but my Company is spending a certain
amount of time and money into this project by giving Norman the
opportunity to support this project (the official way). We chose james
because we felt that James has a good codebase, and gives us the
opportunity to extend its functionality to what we need. We have a lot
of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing
was as easily extendable as james. On the Contrary, the Feature Set is
still very limited.

That said, there have been great efforts in widening this topic. Our
Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail
Server which can be used as a drop-in solution with best-of-breed
solutions to common problems.

What we have found out is, that this project is willing to walk the
way with us. BUT I have also found out, that the Members are hindering
themselves to some extent by not talking objectively about certain
topics.


I see and understand that there are different understandings about
release planning. So I want to first lay the cornerstone for the next
release. Please vote on which mechanism you want to keep on
developing. Vincenzo suggested the most common approach

project-x.y.z releases where

x - is a release change that is not backwards compatible, or contains
    major feature enhancements, that involve more inspection by the
    user, because current configurations are incompatible with this
    release.
y - is a release change that is backward compatible, but contains
    major feature enhancements. The Installation is not guaranteed to
    be working with current configurations, but most likely will.
z - is completely compatible to the previous release, and contains
    only bugfixes.

From what I understood from the recent posts, is that release planning
was handles different in the past, and why should one change it now,
when it was different in the past. Well IMHO we all evolve with a
project. Sometimes certain decisions are good, sometimes they are bad.
But just because there have been bad decisions does not mean to keep
bearing with them instead of changing them to something better.

But the version numbering is only solving half the problem. The next
thing is to define what should be inside a Release. this should first
be analyzed by topic i.e. will feature a be an incompatible change, or
not.

Successful Open-Source Projects (Eclipse, ...) have a strict Release
Plan (Minor Releases every 6 Months, Major Releases every Year), with a
certain set of features. The Feature Sets should be chosen, so that the release is
possible. The Projected Release Dates are fixed to some
extend. If a Release Date is coming closer, and it is obvious that a
certain feature can not be implemented/integrated to the projected
date, there should be a vote on what to do. Move the Release Date, or
Move the Feature to the next Release Cycle.

Those Rules should be clear to everyone, so noone has to argue or
quarrel about what is a next release.

That said/written please vote about how release planning should be
considered in the future.

I would consider the discussed road map to be the 3.0 road map,
Norman and Stefano should be responsible for its development. Features
that are wanted in 2.4 should be backported by the people that want
it within 2.4 release. Noel and Vincenzo should be responsible fpr the
2.4 release. If there are Problems during backporting/migration of
features Stefano and Norman should be available for helping, but
should keep their focus on 3.0

So please step back from terms of throwing trunk on people and the
like, and keep focus on the project. Clear the misunderstandings out,
vote on release planning/cycles terminology. Keep focus on the
project in favor of interpersonal dislikings.


Again I know I am an Outsider, but still I hope you consider my
suggestions to this project

Kind regards

Juergen Hoffmann







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

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: LONG JAMES v2.4 Road Map

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

On 9/15/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> Hi to all Developers,
>
> I have been following this thread for some time now. Being a Person
> that is only watching, I came to the conclusion that You as Developers
> have a totally different understanding as of what should be a 2.4
> Release.

As always, well observed ;-)

> Right now you are quarreling about things that should be defined once
> and then be clear to everyone. Looking at the Message History,
> quarreling and endless discussions are quite common to this project.

... and probably common many others here at Apache. (Some are even
worse ;-)) It is sometimes painful, but this community is not driven
by project management, it is driven by _consent_. It's not always as
pragmatic as everyone would like to have it. And there are means to
come to conclusions, mostly from shorter or longer ;-) discussions.
Votes are only the ultimate choice. This project is healthy and very
verbose in terms of communication.
Just take a second, do a quick man-power calculation and think about
how few people with very few effort (compared to other software
development) put out great software for free!

> I know I am an outsider talking, but my Company is spending a certain
> amount of time and money into this project by giving Norman the
> opportunity to support this project (the official way).

That's really great. I'd guess you get some real value back for that!

> We chose james
> because we felt that James has a good codebase, and gives us the
> opportunity to extend its functionality to what we need. We have a lot
> of Experience in E-Mail Clusters and E-Mail Product Solutions. Nothing
> was as easily extendable as james. On the Contrary, the Feature Set is
> still very limited.
>
> That said, there have been great efforts in widening this topic. Our
> Companies Goal is to make the JAMES Server a State-Of-The Art E-Mail
> Server which can be used as a drop-in solution with best-of-breed
> solutions to common problems.
>
> What we have found out is, that this project is willing to walk the
> way with us. BUT I have also found out, that the Members are hindering
> themselves to some extent by not talking objectively about certain
> topics.

There is no way talking objectivly. This is our free-time dedication,
we are enthusiastic about it!
The only thing we have to adhere to is to deliver mail server software for free.

> Successful Open-Source Projects (Eclipse, ...) have a strict Release
> Plan (Minor Releases every 6 Months, Major Releases every Year), with a
> certain set of features. The Feature Sets should be chosen, so that the release is
> possible. The Projected Release Dates are fixed to some
> extend. If a Release Date is coming closer, and it is obvious that a
> certain feature can not be implemented/integrated to the projected
> date, there should be a vote on what to do. Move the Release Date, or
> Move the Feature to the next Release Cycle.

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.

> Those Rules should be clear to everyone, so noone has to argue or
> quarrel about what is a next release.
>
> That said/written please vote about how release planning should be
> considered in the future.

I guess, release planning is done through discussing the topic on
public mailing lists. Not changing that, no vote needed.

>
> I would consider the discussed road map to be the 3.0 road map,
> Norman and Stefano should be responsible for its development. Features
> that are wanted in 2.4 should be backported by the people that want
> it within 2.4 release. Noel and Vincenzo should be responsible fpr the
> 2.4 release. If there are Problems during backporting/migration of
> features Stefano and Norman should be available for helping, but
> should keep their focus on 3.0

Well, that's not how it works. (For example, just as a side note, you
are exluding me from the list.)
We could have a "release manager" but he'd have no additional rights
than all the others.

> So please step back from terms of throwing trunk on people and the
> like, and keep focus on the project. Clear the misunderstandings out,
> vote on release planning/cycles terminology. Keep focus on the
> project in favor of interpersonal dislikings.

I really honestly see no "personal dislikings". We are (mostly) always
on subject. What you read as dislikings are different technical
opinions and goals (which will never change) and maybe some cultural
differences. But we still are a team working together on concrete
software.

> Again I know I am an Outsider, but still I hope you consider my
> suggestions to this project

And this is where it gets interesting. ;-)
Of course we want to hear from our user base. As a user, what concrete
features do you want in the next release? Keep on your good discussion
on the mailing list and you are no longer an "outsider".

Sorry that we aren't able to deliver more quickly, but we try to
improve. We welcome all people who'd like to contribute.

  Bernd

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

Re: LONG JAMES v2.4 Road Map

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

Jürgen Hoffmann wrote:
> Right now you are quarreling about things that should be defined once
> and then be clear to everyone. Looking at the Message History,
> quarreling and endless discussions are quite common to this project.

Welcome to server-dev ;-)

> I see and understand that there are different understandings about
> release planning. So I want to first lay the cornerstone for the next
> release. Please vote on which mechanism you want to keep on
> developing. Vincenzo suggested the most common approach
> [...]
>>>From what I understood from the recent posts, is that release planning
> was handles different in the past, and why should one change it now,
> when it was different in the past. Well IMHO we all evolve with a
> project. Sometimes certain decisions are good, sometimes they are bad.
> But just because there have been bad decisions does not mean to keep
> bearing with them instead of changing them to something better.

So, do you think that current 2.3.0rc3 should be released as 3.0?

> But the version numbering is only solving half the problem. The next
> thing is to define what should be inside a Release. this should first
> be analyzed by topic i.e. will feature a be an incompatible change, or
> not.

I think that the version numbering is solving 5% of the problem: if we 
don't write the new features we could have defined the best version 
numbering scheme ever, but we would never use it.

> Successful Open-Source Projects (Eclipse, ...) have a strict Release
> Plan (Minor Releases every 6 Months, Major Releases every Year), with a
> certain set of features. The Feature Sets should be chosen, so that the release is
> possible. The Projected Release Dates are fixed to some
> extend. If a Release Date is coming closer, and it is obvious that a
> certain feature can not be implemented/integrated to the projected
> date, there should be a vote on what to do. Move the Release Date, or
> Move the Feature to the next Release Cycle.

IMO a string release plan is not in our possibilities now: we have less 
than the equivalend of 2 fulltime developers working on it and not on a 
regular basis (I don't know about Norman but I cannot take the 
responsibility to work every day on James, I can only say I would like 
to do that). Eclipse project as hundreds of developers supported by 
their own companies. We could have much strict roadmaps and much more 
stable releases and we would probably need a good project manager to 
handle it (and not a "lazy" PMC ;-) ).

> Those Rules should be clear to everyone, so noone has to argue or
> quarrel about what is a next release.
> 
> That said/written please vote about how release planning should be
> considered in the future.
> 
> I would consider the discussed road map to be the 3.0 road map,
> Norman and Stefano should be responsible for its development. Features
> that are wanted in 2.4 should be backported by the people that want
> it within 2.4 release. Noel and Vincenzo should be responsible fpr the
> 2.4 release. If there are Problems during backporting/migration of
> features Stefano and Norman should be available for helping, but
> should keep their focus on 3.0

I still don't know what Vincenzo and Noel want to do with the 
"next-minor" release so I'm not able to vote now the number of their 
release. We also don't have a string roadmap for "next-major" release (6 
months) and I would be more inclined in using 2.x if we don't add some 
more major change in current trunk, but I won't be against 3.0 or any 
other number. I simply say that I'm fine with "next-minor" and 
"next-major" and we can define the number as the release content is more 
concrete. I think that in 3 months we'll be able to evaluate a number 
for next-major, I can't say anything about next-minor until I say the 
list of things that they want to backport (it seems to me that the 
roadmap for this next-minor is not so defined yet)

> So please step back from terms of throwing trunk on people and the
> like, and keep focus on the project. Clear the misunderstandings out,
> vote on release planning/cycles terminology. Keep focus on the
> project in favor of interpersonal dislikings.

I want to say it again because I don't want to be misunderstood. Don't 
take my ideas or my objections as trunks on people and I'm just trying 
to keep the focus on the project.

I think we should use votes much more frequently and avoid endless 
discussions. I already wrote a proposal for the next spf/mime4j release, 
a proposal for a website change (to accomodate 2.2, 2.3 and 
next-minor/next-major docs) and a proposal for the next-minor/next-major 
stuff because I want to keep the focus on concrete things.

> Again I know I am an Outsider, but still I hope you consider my
> suggestions to this project
> 
> Kind regards
> 
> Juergen Hoffmann

One of the part I liked much more in your message is the "X and Y should 
be responsible for A and Z should be responsible for B". This is really 
important in project management: we cast votes, we take decisions, +1 
votes should always mean active commitment toward a goal and we should 
try to take responsibilities or to delegate to people we trust some of them.

As I said, I trust Vincenzo and Noel enough to know that if they work to 
make a release they will do a good release so I don't need to review and 
vote every single diff between trunk and 2.3 to decide what to do: I 
know I may have different opinions on the risks related to a given patch 
or to the importance a give feature has for our users, but I understand 
that 1) I'm not the only developer, 2) this is not *my* project, 3) 
other committers have enough experience to avoid big mistakes.

Stefano

PS: if it is "official" that your company support Norman in the james 
work you may want to submit a Corporate CLA 
(http://www.apache.org/licenses/cla-corporate.txt) as an additional 
piece of paper to protect ASF from possible licensing problems.


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

Re: LONG JAMES v2.4 Road Map

[Joachim Draeger <jd...@joachim-draeger.de>]

Stefano Bagnara schrieb:

> Unfortunately I guess that IMAP won't be included in next-minor or 
> next-major, but we can only expect to be able to do some steps in that 2 
> releases (it would be *really* cool if we were able to put experimental 
> unstable support for imap in next-major but this is not realistic to me).

Of course I can't forecast how much time we/I can invest in IMAP the next 
months, but I do hope there will be something.
But I think that it is realistic, that it won't share its API with James from 
the beginning but provide Mail- or even MessageRepository wrappers for 
integration. (This is how it works at the moment)
So it doesn't destabilize James or blocks releases but can be continuously 
integrated and easily tried out and tested by developers/users by just 
uncommenting/inserting some lines in config/assembly.xml.
Well and sometimes users find the product usable while the developer still 
considers it as experimental.

Joachim

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

Re: LONG JAMES v2.4 Road Map

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

Bernd Fondermann wrote:
>> Do you agree with one of these 2 plans? Have you, instead, a third
>> proposal (possibly including expected date to branch/date to release and
>> expected feature list)?
> 
> As I said, let's go forward with trunk. (Exception: make hotfixes to
> 2.3 and release that as 2.3.1 onward.)
> Then, at some time in the future, let's branch and release. Just like
> we did with 2.3! The date may be January. Maybe but unlikely: before
> January.
> 
>  Bernd

So your idea perfectly matches what me and Norman would like to do.

Stefano


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

Re: LONG JAMES v2.4 Road Map

[Norman Maurer <nm...@byteaction.de>]

Stefano Bagnara schrieb:
> Bernd Fondermann wrote:
>>> Do you agree with one of these 2 plans? Have you, instead, a third
>>> proposal (possibly including expected date to branch/date to release 
>>> and
>>> expected feature list)?
>>
>> As I said, let's go forward with trunk. (Exception: make hotfixes to
>> 2.3 and release that as 2.3.1 onward.)
>> Then, at some time in the future, let's branch and release. Just like
>> we did with 2.3! The date may be January. Maybe but unlikely: before
>> January.
>>
>>  Bernd
>
> So your idea perfectly matches what me and Norman would like to do.
>
> Stefano 

Im happy to read this :-)

bye
Norman



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

Re: LONG JAMES v2.4 Road Map

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

On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > Let's at first work together on trunk and then decide to release (when
> > time is due but quite soon).
> > If there are developments which are not completed, ok. Lets disable
> > them, or mark them as experimental, but release what we have. Then,
> > let's move on.
> > I am not opposing doing larger refactorings, or maybe even break
> > features for a limited time. But let's move forward carefully
> > nonetheless.
>
> Sorry, I think that with all this messages I'm not sure I understood
> your position.
>
> Norman and I agreed on a possible release plan for what we identified
> temporarily as "next-major":
>
> We proposed to include everything we have in current trunk + what we are
> able to implement until the beginning of January choosing from a list of
> issues we already defined (and maybe something more, discussing it). In
> January we will branch and start consolidating things to be released
> (and I expect a first alpha/beta really soon after the branch).

I am totally fine with this.

>
> Vincenzo and Noel seems to agree on branching from 2.3 and backporting
> some few selected changes to make an interim release (If I understood it
> they would not do any new development in the branch, but only
> backporting+bugfixing). They have not published the list of this few
> issues, but maybe they will do this soon.

I am OK with this, as you write it down theoretically.
My objection is: I think it is unrealistic. There would very probably
be changes on the patch branch which then would have to be
"forward-backported" (immediatly or later or never?) to trunk.
If it is only a digest of patches, that's OK.

> Do you agree with one of these 2 plans? Have you, instead, a third
> proposal (possibly including expected date to branch/date to release and
> expected feature list)?

As I said, let's go forward with trunk. (Exception: make hotfixes to
2.3 and release that as 2.3.1 onward.)
Then, at some time in the future, let's branch and release. Just like
we did with 2.3! The date may be January. Maybe but unlikely: before
January.

  Bernd

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

Re: LONG JAMES v2.4 Road Map

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

Bernd Fondermann wrote:
> Let's at first work together on trunk and then decide to release (when
> time is due but quite soon).
> If there are developments which are not completed, ok. Lets disable
> them, or mark them as experimental, but release what we have. Then,
> let's move on.
> I am not opposing doing larger refactorings, or maybe even break
> features for a limited time. But let's move forward carefully
> nonetheless.

Sorry, I think that with all this messages I'm not sure I understood 
your position.

Norman and I agreed on a possible release plan for what we identified 
temporarily as "next-major":

We proposed to include everything we have in current trunk + what we are 
able to implement until the beginning of January choosing from a list of 
issues we already defined (and maybe something more, discussing it). In 
January we will branch and start consolidating things to be released 
(and I expect a first alpha/beta really soon after the branch).

Vincenzo and Noel seems to agree on branching from 2.3 and backporting 
some few selected changes to make an interim release (If I understood it 
they would not do any new development in the branch, but only 
backporting+bugfixing). They have not published the list of this few 
issues, but maybe they will do this soon.

Do you agree with one of these 2 plans? Have you, instead, a third 
proposal (possibly including expected date to branch/date to release and 
expected feature list)?

Stefano


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

Re: LONG JAMES v2.4 Road Map

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

On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> >> Bernd, this was by no means to be understood as an offense or anything
> >> against other active contributors on this project. This List is neither
> >> complete nor a concrete suggestion. Replace the Names in the Lists with
> >> A, B, C, and D.
> >
> > -1. Not agreed. I favor all the committers working together on the
> > current release. We don't want to split the community up. Other
> > projects here at Apache are in deep, deep trouble just because of
> > this!
>
> I've proposed the "next-minor"/"next-major" because I don't see it as a
> split. It is simply a group of people that put efforts to consolidate
> some of the features we have in trunk, while new work in trunk is being
> done.

I am jumping on the expression "be responsible for" (which has been
cut out by me).
It sounds to me like a project manager's assignment. Please, let's not
split responsability.

> Imho the 2 active trees rule we agreed in past is still valid: trunk is
> always the main active tree. We're waiting to close 2.3 so the
> next-minor can be started and only when next-minor will be closed we're
> going to open the next-major release.

Agreed. I like sandboxes, I like 2.3 branch, I like trunk. I am fine
with all that.

> Furthermore, I already wrote that the "split" could give our users the
> best results (3 releases in 6 months!!) and let everyone work on the
> preferred tree.

I am very much in doubt that those 2 additional releases will be
possible or at least are honest goals. And if they would become
reality, I am fearing it would become impossible to merge branches
again.

What makes me suddenly think that people want to accelerate
development and releases like mad when some month ago they didn't care
much about releasing at all?
(That said when the 2.3 release is not even through the door.)

Let's at first work together on trunk and then decide to release (when
time is due but quite soon).
If there are developments which are not completed, ok. Lets disable
them, or mark them as experimental, but release what we have. Then,
let's move on.
I am not opposing doing larger refactorings, or maybe even break
features for a limited time. But let's move forward carefully
nonetheless.

> >> So do we/you want to deliver standards, or do you want to chase them?
> >
> > Is that related to IMAP? Hopefully, this will be added soon.
>
> Unfortunately I guess that IMAP won't be included in next-minor or
> next-major, but we can only expect to be able to do some steps in that 2
> releases (it would be *really* cool if we were able to put experimental
> unstable support for imap in next-major but this is not realistic to me).

Yes, seems so.

  Bernd

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

Re: LONG JAMES v2.4 Road Map

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

On 9/15/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> Hi Stefano, Hi Bernd,
>

> this is exactly why there should be certain assignments ( I did not use
> "responsibilities" with a purpose ;) ) I see two parties right now. One
> that ones to do the big thing, work on the next major release, and the
> other party that just wants to do minor/little changes, and release
> that. Which is fine. Why should the guys developing the main features
> decide on what goes into the minor changes and what does not. In fact
> they really do not care, do they?

I care.

You are stating we have two parties, with two different goals? And you
are seeing that as a problem for the project? Then you suggest those
two parties would get around each other easiest by everyone doing
there own thing?

I don't think this is true. Instead:
We have a bunch of people, having one goal, developing James. Everyone
is having its own thoughts about reaching that goal. Everyone can
commit code to trunk or supply patches. That's where it gets tricky.
Because most code is liked, but some isn't, discussions raise up.

You say: Discussion have to be fruitful. I say: Damn right!

Those have to come to a conclusion. Conflicts have to be resolved. Not
circumvented.
This is what this project is essentially all about. Not about
branches, timelines, vetoes, assignments, parties and whatnot. (I am
not totally sure about parties. We should have a release party soon!
;-) )

> > What makes me suddenly think that people want to accelerate
> > development and releases like mad when some month ago they didn't care
> > much about releasing at all?
>
> It is not acceleration. It is planning. It is Feedback to the Users. It
> is showing confidence. It is by no means about acceleration. As I said
> the dates are not to be put into concrete ( German saying, don't know if
> that maps to the english language ;) ). It just represents a goal, each
> contributer commited to. It just says, "We plan to put this and this
> feature set into the release." If we see that we cannot meet the goals,
> we can still decide on leaving it out or move the release date.

Can't argue with you on this one. Exept that I cannot commit myself to
anything but the next task. Sometimes not even that. I only can
volunteer. And commit to svn of course.

> How do you want that to be done, if you have developers that want to
> achieve different things? They will be vetoing changes etc. I do not
> even know if we are fine with sandboxes. At least I recall that there
> was some discussion about the topic.

A veto is there to be resolved, not to postpone or block changes.
Anything else would is a misuse.

> >> >> So do we/you want to deliver standards, or do you want to chase them?
> >> >
> >> > Is that related to IMAP? Hopefully, this will be added soon.
> >>
> >> Unfortunately I guess that IMAP won't be included in next-minor or
> >> next-major, but we can only expect to be able to do some steps in that 2
> >> releases (it would be *really* cool if we were able to put experimental
> >> unstable support for imap in next-major but this is not realistic to
> >> me).
>
> IMAP? This is not what I meant by *setting* a standard? It is a standard
> for Years. This is an example of chasing it ;) spf, surbl, greylisting,
> sieve, tight integration into existing business environments is what i
> am talking about. There is not even a solid Alias/Forward/Virtual Domain
> Implementation. As far as I can tell, James is far away from being a
> standalone Business Ready Mail Server Solution, As opposed to a very
> good Relaying, Mail Processing Solution.

Well, this is a volunteer-driven project. I am all for that. Not
opposing anything.
But also not trading new features for quality. No bad fast hacking
here. That is done somewhere else. (Well, I am not totally sure where,
but must be somewhere ;-) )

> I see a great future for the project by setting standards, because I
> feel that the E-Mail Standard is finding itself new. It is getting more
> and more important to fight spam and other email related problems
> without changing the existing infrastructure.
>
> I believe we can set Standards with James. Instead of chasing them.

I like that. Let's keep the team working together and other will join us.

  Bernd

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

Re: LONG JAMES v2.4 Road Map

[Jürgen Hoffmann <jh...@byteaction.de>]

Hi Stefano, Hi Bernd,

>> >> Bernd, this was by no means to be understood as an offense or 
>> anything
>> >> against other active contributors on this project. This List is 
>> neither
>> >> complete nor a concrete suggestion. Replace the Names in the Lists 
>> with
>> >> A, B, C, and D.
>> >
>> > -1. Not agreed. I favor all the committers working together on the
>> > current release. We don't want to split the community up. Other
>> > projects here at Apache are in deep, deep trouble just because of
>> > this!
>>
>> I've proposed the "next-minor"/"next-major" because I don't see it as a
>> split. It is simply a group of people that put efforts to consolidate
>> some of the features we have in trunk, while new work in trunk is being
>> done.
>
> I am jumping on the expression "be responsible for" (which has been
> cut out by me).
> It sounds to me like a project manager's assignment. Please, let's not
> split responsability.
Well the only reason why I put this out is that it seems to me, that we 
have contributors, which have different viewpoints about what should be 
in the nexte major-/minor-/whatever release. I just wanted to *suggest* 
a way on how both parties can reach their particular goal. Nothing more.

>> Imho the 2 active trees rule we agreed in past is still valid: trunk is
>> always the main active tree. We're waiting to close 2.3 so the
>> next-minor can be started and only when next-minor will be closed we're
>> going to open the next-major release.
>
> Agreed. I like sandboxes, I like 2.3 branch, I like trunk. I am fine
> with all that.

So it is true? We all do want the same? :)

>> Furthermore, I already wrote that the "split" could give our users the
>> best results (3 releases in 6 months!!) and let everyone work on the
>> preferred tree.
>
> I am very much in doubt that those 2 additional releases will be
> possible or at least are honest goals. And if they would become
> reality, I am fearing it would become impossible to merge branches
> again.

this is exactly why there should be certain assignments ( I did not use 
"responsibilities" with a purpose ;) ) I see two parties right now. One 
that ones to do the big thing, work on the next major release, and the 
other party that just wants to do minor/little changes, and release 
that. Which is fine. Why should the guys developing the main features 
decide on what goes into the minor changes and what does not. In fact 
they really do not care, do they?

But others do. The other Party is interested into the main features, and 
wants the coming into james anywhere in the future. And they want to 
keep things stable. Watch all the important things, like JDK 
Compatibility, etc. This does not mean, that the Developers should start 
developing on 2 Branches! I see this a bit like the Linux Kernel Source 
Development. There are still Maintainers for the old 2.0 Kernel, and it 
has released some time ago. Why People still use the old Kernel? This is 
really beyond my scope. But what I am trying to say is, that there must 
be people out there still using the old Kernel, And they must have a 
reason for doing so. So the maintainer saw something great getting into 
the actual Kernel and thought, "hey, We can use that also!" So he went 
on, and backported the feature. Plain and simple.

What is important, that people agreed, that the 2.0 Kernel is not 
developed anymore, and main development should go into the 2.4 and 2.6 
kernel. So if it is clear that the Main development is being done on 3.0 
(or whatever release number) and only some features wanted, are being 
backported into the next minor 2.4 release, than there should be no more 
problems. Or do I see this totally wrong?

> What makes me suddenly think that people want to accelerate
> development and releases like mad when some month ago they didn't care
> much about releasing at all?

It is not acceleration. It is planning. It is Feedback to the Users. It 
is showing confidence. It is by no means about acceleration. As I said 
the dates are not to be put into concrete ( German saying, don't know if 
that maps to the english language ;) ). It just represents a goal, each 
contributer commited to. It just says, "We plan to put this and this 
feature set into the release." If we see that we cannot meet the goals, 
we can still decide on leaving it out or move the release date.

> (That said when the 2.3 release is not even through the door.)

exactly!

> Let's at first work together on trunk and then decide to release (when
> time is due but quite soon).

How do you want that to be done, if you have developers that want to 
achieve different things? They will be vetoing changes etc. I do not 
even know if we are fine with sandboxes. At least I recall that there 
was some discussion about the topic.

> If there are developments which are not completed, ok. Lets disable
> them, or mark them as experimental, but release what we have. Then,
> let's move on.

How does that conflict with my suggestion. You have an release. Then 
after the release, if there are bugs found, they are put into 2.3.1 or 
2.3.2 fixing the bug immediately. Main development is on the trunk. 
Features wanted in the 2.3 codebase and that should be compatible with 
2.3 should be backported from trunk.

> I am not opposing doing larger refactorings, or maybe even break
> features for a limited time. But let's move forward carefully
> nonetheless.

-1 Refactorings should be done, when they need to be done. If you keep 
on bearing with the problem, you will make the Integration harder, and 
possibly end up with never doing them.

>> >> So do we/you want to deliver standards, or do you want to chase them?
>> >
>> > Is that related to IMAP? Hopefully, this will be added soon.
>>
>> Unfortunately I guess that IMAP won't be included in next-minor or
>> next-major, but we can only expect to be able to do some steps in that 2
>> releases (it would be *really* cool if we were able to put experimental
>> unstable support for imap in next-major but this is not realistic to 
>> me).

IMAP? This is not what I meant by *setting* a standard? It is a standard 
for Years. This is an example of chasing it ;) spf, surbl, greylisting, 
sieve, tight integration into existing business environments is what i 
am talking about. There is not even a solid Alias/Forward/Virtual Domain 
Implementation. As far as I can tell, James is far away from being a 
standalone Business Ready Mail Server Solution, As opposed to a very 
good Relaying, Mail Processing Solution.


I see a great future for the project by setting standards, because I 
feel that the E-Mail Standard is finding itself new. It is getting more 
and more important to fight spam and other email related problems 
without changing the existing infrastructure.

I believe we can set Standards with James. Instead of chasing them.

Juergen



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

Re: LONG JAMES v2.4 Road Map

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

Bernd Fondermann wrote:
>> Bernd, this was by no means to be understood as an offense or anything
>> against other active contributors on this project. This List is neither
>> complete nor a concrete suggestion. Replace the Names in the Lists with
>> A, B, C, and D.
> 
> -1. Not agreed. I favor all the committers working together on the
> current release. We don't want to split the community up. Other
> projects here at Apache are in deep, deep trouble just because of
> this!

I've proposed the "next-minor"/"next-major" because I don't see it as a 
split. It is simply a group of people that put efforts to consolidate 
some of the features we have in trunk, while new work in trunk is being 
done.

So I don't think at this as a project fork, but simply a consolidation 
branch, like we did for 2.3. The main difference between 2.3 is that 
this time I already said I can't (and want) put my efforts on the 
consolidation branch. Nothing terrible at all, nothing to call home for.

Imho the 2 active trees rule we agreed in past is still valid: trunk is 
always the main active tree. We're waiting to close 2.3 so the 
next-minor can be started and only when next-minor will be closed we're 
going to open the next-major release.

Imho this make sense. We can't think we'll have the efforts of every 
committer for everything we decide to do. There are many James 
committers that did nothing since 2.1 but they still have the power to 
vote (even if they don't do this so often). As you said everyone should 
be able to do what he wants (by respecting the high-level project goals) 
and when he wants (and not being managed) and we should only try to 
synchronize/optimize our efforts.

Furthermore, I already wrote that the "split" could give our users the 
best results (3 releases in 6 months!!) and let everyone work on the 
preferred tree.

>> So do we/you want to deliver standards, or do you want to chase them?
> 
> Is that related to IMAP? Hopefully, this will be added soon.

Unfortunately I guess that IMAP won't be included in next-minor or 
next-major, but we can only expect to be able to do some steps in that 2 
releases (it would be *really* cool if we were able to put experimental 
unstable support for imap in next-major but this is not realistic to me).

Stefano


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

Re: LONG JAMES v2.4 Road Map

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

On 9/15/06, Jürgen Hoffmann <jh...@byteaction.de> wrote:
> Hi Bernd,
>
> Bernd Fondermann schrieb:
> > That's really great. I'd guess you get some real value back for that!
> At this point in time, the amount of value put into the project is much
> much greater.

how can you say that?! you get other's and my craftship and expertise
for free! :-)

> > There is no way talking objectivly. This is our free-time dedication,
> > we are enthusiastic about it!
> > The only thing we have to adhere to is to deliver mail server software
> > for free.
> Well, by objective I meant, to put personal interests aside, and focus
> on the problem at hand. Sometimes it seems as if there are developers
> sitting and persisting on their viewpoint for days and weeks. That is
> not helping the problem at hand, Hopefully I could get this point across
> now.

Everyone participating is free to put up a vote.  Why doesn't it
happen more often?

> But Eclipse is driven by companies, it is
> > like a software company.
> driven by the community though. Take jboss for another example.

Well, JBoss is not a good example. There is an open source project
JBoss and there is a company JBoss who owns (to use neutral wording)
the project.

> > 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.
> Well from my Point of View there are certain standards on how to plan
> releases and release cycles. Instead of re-inventing the wheel, I
> suggest to vote for a proven method. If it is Method A or B is not
> important to me. That everyone knows and understands it, is more important.

I am doing project management all day, being managed all day. Sorry, I
am not able to work like that, here.
And don't get me wrong. I want to have a professional result. I want
to release often, I want cool features. But I simply cannot commit
myself to a project plan.
If we'd vote, say, to release 12th december, it would be a nice
target. But it would not have any binding in terms of delivering to
the user base.

> >> That said/written please vote about how release planning should be
> >> considered in the future.
> > I guess, release planning is done through discussing the topic on
> > public mailing lists. Not changing that, no vote needed.
> So you are saying that it makes more sense to discuss how to do the next
> release each and every time a release was made?

No, doesn't make sense probably. But, you see, as this community
changes, so does release management and notion thereof.

> >> I would consider the discussed road map to be the 3.0 road map,
> >> Norman and Stefano should be responsible for its development. Features
> >> that are wanted in 2.4 should be backported by the people that want
> >> it within 2.4 release. Noel and Vincenzo should be responsible fpr the
> >> 2.4 release. If there are Problems during backporting/migration of
> >> features Stefano and Norman should be available for helping, but
> >> should keep their focus on 3.0
> >
> > Well, that's not how it works. (For example, just as a side note, you
> > are exluding me from the list.)
> > We could have a "release manager" but he'd have no additional rights
> > than all the others.
> Bernd, this was by no means to be understood as an offense or anything
> against other active contributors on this project. This List is neither
> complete nor a concrete suggestion. Replace the Names in the Lists with
> A, B, C, and D.

-1. Not agreed. I favor all the committers working together on the
current release. We don't want to split the community up. Other
projects here at Apache are in deep, deep trouble just because of
this!

> >> Again I know I am an Outsider, but still I hope you consider my
> >> suggestions to this project
> > And this is where it gets interesting. ;-)
> > Of course we want to hear from our user base. As a user, what concrete
> > features do you want in the next release? Keep on your good discussion
> > on the mailing list and you are no longer an "outsider".
> Features that I want into the next release are many. Most of Norman
> knows about. Will they be in the next release? I do not know. And this
> is because I think I may not decide on what should go into the next
> release. I have not enough inside into the codebase. All I know is that
> the E-Mail Standard will change rapidly in the next years, starting with
> big companies deploying their "Standards".

To have an _opinion_ on a whish list item does not require you to have
an insight into the codebase. (Or do you know anything about
manifacturing your MP3 player which is on your personal birthday wish
list.)

> So do we/you want to deliver standards, or do you want to chase them?

Is that related to IMAP? Hopefully, this will be added soon.

> > Sorry that we aren't able to deliver more quickly, but we try to
> > improve. We welcome all people who'd like to contribute.
> If the day had 72 hours, I'd be a contributor. Believe me ;) But 4 Kids
> are a time eating business ;)

OK, I see you have your fun anyway ;-)

  Bernd

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

Re: LONG JAMES v2.4 Road Map

[Jürgen Hoffmann <jh...@byteaction.de>]

Hi Bernd,

Bernd Fondermann schrieb:
> ... and probably common many others here at Apache. (Some are even
> worse ;-)) It is sometimes painful, but this community is not driven
> by project management, it is driven by _consent_. It's not always as
> pragmatic as everyone would like to have it. And there are means to
> come to conclusions, mostly from shorter or longer ;-) discussions.
> Votes are only the ultimate choice. This project is healthy and very
> verbose in terms of communication.
never said it isn't. And it is good to see that the project is active. :)
> Just take a second, do a quick man-power calculation and think about
> how few people with very few effort (compared to other software
> development) put out great software for free!
I am a big fan of Apache, do not get me wrong. I am a strong believer 
into open-source. And I personally know how difficult it is to support 
the project next to the daily business.
>> I know I am an outsider talking, but my Company is spending a certain
>> amount of time and money into this project by giving Norman the
>> opportunity to support this project (the official way).
>
> That's really great. I'd guess you get some real value back for that!
At this point in time, the amount of value put into the project is much 
much greater.
> There is no way talking objectivly. This is our free-time dedication,
> we are enthusiastic about it!
> The only thing we have to adhere to is to deliver mail server software 
> for free.
Well, by objective I meant, to put personal interests aside, and focus 
on the problem at hand. Sometimes it seems as if there are developers 
sitting and persisting on their viewpoint for days and weeks. That is 
not helping the problem at hand, Hopefully I could get this point across 
now.
>> Successful Open-Source Projects (Eclipse, ...) have a strict Release
>> Plan (Minor Releases every 6 Months, Major Releases every Year), with a
>> certain set of features. The Feature Sets should be chosen, so that 
>> the release is
>> possible. The Projected Release Dates are fixed to some
>> extend. If a Release Date is coming closer, and it is obvious that a
>> certain feature can not be implemented/integrated to the projected
>> date, there should be a vote on what to do. Move the Release Date, or
>> Move the Feature to the next Release Cycle.
>
> There is some truth in this. But Eclipse is driven by companies, it is
> like a software company.
driven by the community though. Take jboss for another example.
> 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.
Well from my Point of View there are certain standards on how to plan 
releases and release cycles. Instead of re-inventing the wheel, I 
suggest to vote for a proven method. If it is Method A or B is not 
important to me. That everyone knows and understands it, is more important.
>> That said/written please vote about how release planning should be
>> considered in the future.
> I guess, release planning is done through discussing the topic on
> public mailing lists. Not changing that, no vote needed.
So you are saying that it makes more sense to discuss how to do the next 
release each and every time a release was made?
>> I would consider the discussed road map to be the 3.0 road map,
>> Norman and Stefano should be responsible for its development. Features
>> that are wanted in 2.4 should be backported by the people that want
>> it within 2.4 release. Noel and Vincenzo should be responsible fpr the
>> 2.4 release. If there are Problems during backporting/migration of
>> features Stefano and Norman should be available for helping, but
>> should keep their focus on 3.0
>
> Well, that's not how it works. (For example, just as a side note, you
> are exluding me from the list.)
> We could have a "release manager" but he'd have no additional rights
> than all the others.
Bernd, this was by no means to be understood as an offense or anything 
against other active contributors on this project. This List is neither 
complete nor a concrete suggestion. Replace the Names in the Lists with 
A, B, C, and D.
>> So please step back from terms of throwing trunk on people and the
>> like, and keep focus on the project. Clear the misunderstandings out,
>> vote on release planning/cycles terminology. Keep focus on the
>> project in favor of interpersonal dislikings.
> I really honestly see no "personal dislikings". We are (mostly) always
> on subject. What you read as dislikings are different technical
> opinions and goals (which will never change) and maybe some cultural
> differences. But we still are a team working together on concrete
> software.
>
>> Again I know I am an Outsider, but still I hope you consider my
>> suggestions to this project
> And this is where it gets interesting. ;-)
> Of course we want to hear from our user base. As a user, what concrete
> features do you want in the next release? Keep on your good discussion
> on the mailing list and you are no longer an "outsider".
Features that I want into the next release are many. Most of Norman 
knows about. Will they be in the next release? I do not know. And this 
is because I think I may not decide on what should go into the next 
release. I have not enough inside into the codebase. All I know is that 
the E-Mail Standard will change rapidly in the next years, starting with 
big companies deploying their "Standards".

So do we/you want to deliver standards, or do you want to chase them?

> Sorry that we aren't able to deliver more quickly, but we try to
> improve. We welcome all people who'd like to contribute.
If the day had 72 hours, I'd be a contributor. Believe me ;) But 4 Kids 
are a time eating business ;)

Jürgen


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

Re: Version numbers (Was: LONG JAMES v2.4 Road Map)

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

On 9/16/06, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann wrote:
> > Stefano,
> >
> > Sorry, cannot parse this. You lost me way before you said that -1
> > should not be the next version number for James. I feel stupid. You
> > are using too much words for me to cope with. Do you have 3 or 4
> > simple words summarizing your ideas?
> >
> > Are you saying that, the higher the next version number will be, the
> > more substantial changes can be made? - That, I would agree upon.
>
> More easy: Let's do the changes first, we'll define the numbers later.
>

+1

(Wow, it is as easy as that?)

  Bernd

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

Re: Version numbers (Was: LONG JAMES v2.4 Road Map)

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

Bernd Fondermann wrote:
> Stefano,
> 
> Sorry, cannot parse this. You lost me way before you said that -1
> should not be the next version number for James. I feel stupid. You
> are using too much words for me to cope with. Do you have 3 or 4
> simple words summarizing your ideas?
> 
> Are you saying that, the higher the next version number will be, the
> more substantial changes can be made? - That, I would agree upon.

More easy: Let's do the changes first, we'll define the numbers later.

Stefano


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

Re: Version numbers (Was: LONG JAMES v2.4 Road Map)

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

Stefano,

Sorry, cannot parse this. You lost me way before you said that -1
should not be the next version number for James. I feel stupid. You
are using too much words for me to cope with. Do you have 3 or 4
simple words summarizing your ideas?

Are you saying that, the higher the next version number will be, the
more substantial changes can be made? - That, I would agree upon.

  Bernd

On 9/15/06, Stefano Bagnara <ap...@bago.org> wrote:
> Jürgen Hoffmann wrote:
> >> I still don't know what Vincenzo and Noel want to do with the
> >> "next-minor" release so I'm not able to vote now the number of their
> >> release. We also don't have a string roadmap for "next-major" release
> >> (6 months) and I would be more inclined in using 2.x if we don't add
> >> some more major change in current trunk, but I won't be against 3.0 or
> >> any other number. I simply say that I'm fine with "next-minor" and
> >> "next-major" and we can define the number as the release content is
> >> more concrete. I think that in 3 months we'll be able to evaluate a
> >> number for next-major, I can't say anything about next-minor until I
> >> say the list of things that they want to backport (it seems to me that
> >> the roadmap for this next-minor is not so defined yet)
> > Great. So let us keep it in that way. You are fine with
> > 3.0 = Trunk
> > 2.3 = Release Branch with possible bugfix sub releases
> > 2.4 = Features that went into 3.0 which would be great to have within
> > the 2.3 application layout (This Integration Effort is do be done by the
> > 2.4 maintainers)
>
> I think the main "problem" in this discussion is that I believe that
> changes that are in trunk now and that I would like to put in the 6
> months release (next-major) are on the same line and on the same layout
> of 2.3 and they would be part of 2.3 if we didn't branch before.
>
> In fact the only common thing between 2.2 and 2.3 is that it is storage
> compatible and it didn't changed too much the mailets api (but they
> changed, and furthermore we changed the WHOLE avalon references from
> components to services). From 2.3 to trunk and to the other features we
> listed as possible candidates for inclusion there is nothing different
> from this: we'll keep it storage compatible. (I avoided committing
> storage incompatible changes because I thought to this "personal"
> roadmap few months ago).
>
> So if I was the only one to choose names I would use the 2.4 for the
> "next-minor" and 2.5 for what we defined "next-major" and delay major
> changes in the architecture for 3.0 (dsn support, container changes,
> repository changes) and I would use 2.4 for "next-major" in the case
> there was no "next-minor" release.
>
> I thought this (my idea) was clear enough, but I prefer to be clear so I
> tried to explain it one more time.
>
> I think that the numbers are appropriate from a developer perspective:
> imho the first number change has to be related to total rewrites or to
> major architectural changes included. The second number is changed when
> new features are included, the third for minor releases (tipically bug
> fixes or really small changes). I also understand the marketing
> importance of "big" version numbers, as M$ teach us, but I don't like
> James XP or James 2006 ;-) and that's why I alsways said that I prefer
> 2.3 for the current branch and not 3.0 and why I think the next should
> be consistent with that schema. And about consistency if I knew that the
> next-major will be an increment in the first number I would probably
> have preferred 3.0 for the current 2.3.0 and 4.0 for the next (this
> reflect much better what we changed).
>
> I hope I have explained enough the "why" behind my ideas and I don't
> think I need to convince anyone that my idea is better than another. In
> past PMC decided to give me the rights to vote (and I hope I deserved
> it), so I will simply vote my preference and be sure I won't use a -1
> for the version number.
>
> The only thing I care is to be able to work on my goals when I have the
> right mental state to do a good job: if we call next-major 3.0 I simply
> have more freedom on changes than what I would have if the branch is
> called 2.5 ;-) so this is enough to be happy even with a bigger number.
> Furthermore if we use a major number we can also deprecate things and
> remove some old deprecated code.
>
> So I think we should just wait for Noel, Vincenzo and anyone else that
> is willing to work for the "next-minor" release to prepare a list or
> things to be included and we can decide what the version will be (and I
> believe that if such release will be prepared we'll probably agree on
> the "2.4 branch"/2.4.0 release). About next-major we have 2-3 months
> before branching and I would like to keep storage compatibility anyway
> until that day (if possible), so we have a lot of weeks before we'll
> have to "svn copy trunk branches/vX.X" !
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>

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

Version numbers (Was: LONG JAMES v2.4 Road Map)

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

Jürgen Hoffmann wrote:
>> I still don't know what Vincenzo and Noel want to do with the 
>> "next-minor" release so I'm not able to vote now the number of their 
>> release. We also don't have a string roadmap for "next-major" release 
>> (6 months) and I would be more inclined in using 2.x if we don't add 
>> some more major change in current trunk, but I won't be against 3.0 or 
>> any other number. I simply say that I'm fine with "next-minor" and 
>> "next-major" and we can define the number as the release content is 
>> more concrete. I think that in 3 months we'll be able to evaluate a 
>> number for next-major, I can't say anything about next-minor until I 
>> say the list of things that they want to backport (it seems to me that 
>> the roadmap for this next-minor is not so defined yet)
> Great. So let us keep it in that way. You are fine with
> 3.0 = Trunk
> 2.3 = Release Branch with possible bugfix sub releases
> 2.4 = Features that went into 3.0 which would be great to have within 
> the 2.3 application layout (This Integration Effort is do be done by the 
> 2.4 maintainers)

I think the main "problem" in this discussion is that I believe that 
changes that are in trunk now and that I would like to put in the 6 
months release (next-major) are on the same line and on the same layout 
of 2.3 and they would be part of 2.3 if we didn't branch before.

In fact the only common thing between 2.2 and 2.3 is that it is storage 
compatible and it didn't changed too much the mailets api (but they 
changed, and furthermore we changed the WHOLE avalon references from 
components to services). From 2.3 to trunk and to the other features we 
listed as possible candidates for inclusion there is nothing different 
from this: we'll keep it storage compatible. (I avoided committing 
storage incompatible changes because I thought to this "personal" 
roadmap few months ago).

So if I was the only one to choose names I would use the 2.4 for the 
"next-minor" and 2.5 for what we defined "next-major" and delay major 
changes in the architecture for 3.0 (dsn support, container changes, 
repository changes) and I would use 2.4 for "next-major" in the case 
there was no "next-minor" release.

I thought this (my idea) was clear enough, but I prefer to be clear so I 
tried to explain it one more time.

I think that the numbers are appropriate from a developer perspective: 
imho the first number change has to be related to total rewrites or to 
major architectural changes included. The second number is changed when 
new features are included, the third for minor releases (tipically bug 
fixes or really small changes). I also understand the marketing 
importance of "big" version numbers, as M$ teach us, but I don't like 
James XP or James 2006 ;-) and that's why I alsways said that I prefer 
2.3 for the current branch and not 3.0 and why I think the next should 
be consistent with that schema. And about consistency if I knew that the 
next-major will be an increment in the first number I would probably 
have preferred 3.0 for the current 2.3.0 and 4.0 for the next (this 
reflect much better what we changed).

I hope I have explained enough the "why" behind my ideas and I don't 
think I need to convince anyone that my idea is better than another. In 
past PMC decided to give me the rights to vote (and I hope I deserved 
it), so I will simply vote my preference and be sure I won't use a -1 
for the version number.

The only thing I care is to be able to work on my goals when I have the 
right mental state to do a good job: if we call next-major 3.0 I simply 
have more freedom on changes than what I would have if the branch is 
called 2.5 ;-) so this is enough to be happy even with a bigger number. 
Furthermore if we use a major number we can also deprecate things and 
remove some old deprecated code.

So I think we should just wait for Noel, Vincenzo and anyone else that 
is willing to work for the "next-minor" release to prepare a list or 
things to be included and we can decide what the version will be (and I 
believe that if such release will be prepared we'll probably agree on 
the "2.4 branch"/2.4.0 release). About next-major we have 2-3 months 
before branching and I would like to keep storage compatibility anyway 
until that day (if possible), so we have a lot of weeks before we'll 
have to "svn copy trunk branches/vX.X" !

Stefano


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

Re: LONG JAMES v2.4 Road Map

[Jürgen Hoffmann <jh...@byteaction.de>]

Hi Stefano,

Stefano Bagnara schrieb:
> So, do you think that current 2.3.0rc3 should be released as 3.0?
no. what is 2.3.0rc3 is, and stays 2.3.0rc3 and will be released as 
2.3.0 possible Bugs within it should be released as 2.3.1

Main development (your roadmap to 2.4) should now be 3.0 (Norman and 
Stefano, ...) anything that gets into 3.0 which would be great to have 
within 2.3 should go into 2.4 BUT by the 2.3/2.4 Maintainers (Noel and 
Vincenzo, ...)

Did that make it clear?
> IMO a string release plan is not in our possibilities now: we have 
> less than the equivalend of 2 fulltime developers working on it and 
> not on a regular basis (I don't know about Norman but I cannot take 
> the responsibility to work every day on James, I can only say I would 
> like to do that). Eclipse project as hundreds of developers supported 
> by their own companies. We could have much strict roadmaps and much 
> more stable releases and we would probably need a good project manager 
> to handle it (and not a "lazy" PMC ;-) ).
I see this a little dsifferent. I have been active with turbine for a 
while, and they had the same sort of problems you guys have now. Today 
development has stalled and the project (which is great) is short on 
developers willing to contribute. Because they do not see where or with 
what to help. Nobody sees the main target, or where the rpoject wants to 
go to.
> I still don't know what Vincenzo and Noel want to do with the 
> "next-minor" release so I'm not able to vote now the number of their 
> release. We also don't have a string roadmap for "next-major" release 
> (6 months) and I would be more inclined in using 2.x if we don't add 
> some more major change in current trunk, but I won't be against 3.0 or 
> any other number. I simply say that I'm fine with "next-minor" and 
> "next-major" and we can define the number as the release content is 
> more concrete. I think that in 3 months we'll be able to evaluate a 
> number for next-major, I can't say anything about next-minor until I 
> say the list of things that they want to backport (it seems to me that 
> the roadmap for this next-minor is not so defined yet)
Great. So let us keep it in that way. You are fine with
3.0 = Trunk
2.3 = Release Branch with possible bugfix sub releases
2.4 = Features that went into 3.0 which would be great to have within 
the 2.3 application layout (This Integration Effort is do be done by the 
2.4 maintainers)
>> So please step back from terms of throwing trunk on people and the
>> like, and keep focus on the project. Clear the misunderstandings out,
>> vote on release planning/cycles terminology. Keep focus on the
>> project in favor of interpersonal dislikings.
>
> I want to say it again because I don't want to be misunderstood. Don't 
> take my ideas or my objections as trunks on people and I'm just trying 
> to keep the focus on the project.
You weren't the one i was citing ;)
> I think we should use votes much more frequently and avoid endless 
> discussions. I already wrote a proposal for the next spf/mime4j 
> release, a proposal for a website change (to accomodate 2.2, 2.3 and 
> next-minor/next-major docs) and a proposal for the 
> next-minor/next-major stuff because I want to keep the focus on 
> concrete things.
agreed.
> One of the part I liked much more in your message is the "X and Y 
> should be responsible for A and Z should be responsible for B". This 
> is really important in project management: we cast votes, we take 
> decisions, +1 votes should always mean active commitment toward a goal 
> and we should try to take responsibilities or to delegate to people we 
> trust some of them.
>
> As I said, I trust Vincenzo and Noel enough to know that if they work 
> to make a release they will do a good release so I don't need to 
> review and vote every single diff between trunk and 2.3 to decide what 
> to do: I know I may have different opinions on the risks related to a 
> given patch or to the importance a give feature has for our users, but 
> I understand that 1) I'm not the only developer, 2) this is not *my* 
> project, 3) other committers have enough experience to avoid big 
> mistakes.
That would be a giant leap into the right direction.
> PS: if it is "official" that your company support Norman in the james 
> work you may want to submit a Corporate CLA 
> (http://www.apache.org/licenses/cla-corporate.txt) as an additional 
> piece of paper to protect ASF from possible licensing problems.
If it wouldn't be official, I would have to fire him ;) I can sign this 
if it is necessary. No Problem.

Jürgen Hoffmann



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