Hi Bernd,
this is *the best* Mail I read on this thread !!!
Kind regards
Juergen
Bernd Fondermann schrieb:
> Hi guys,
>
> so much words again for so few information, and not always fun to read.
>
> anyway, a few very short takes from me to let you know what my
> preferences are:
>
> Working
Noel J. Bergman wrote:
Stefano and I certainly had a misunderstanding over his intent for
"2.4" (the next minor release), due to the subject heading. If were were in
physical proximity, I'd shake his hand. We've already apologized for the
misunderstanding, and had a very long chat (each of us m
Noel J. Bergman wrote:
All I want is some discipline about what goes into a release, and then I'll
be a happy camper again. Stop telling me about releasing trunk, and start
talking about how we'll put together a safe, stable, reliable distribution
with all of the new features we want, and my doc
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I would ask you one important thing: as you talk english better than me
and you know Noel much more than me try to discuss the vhosting issue
with Noel and let's see if both of you can at least agree on a common
roadmap on this issue. Once
Stefano,
In many ways I agree with you, but I still believe that som summary
information reported in a status file, along with a record of the
decisions needed, made and outstanding, will help *you* to do the
things you want to without frightening everyone else ;-)
If we can agree on a standard
Norman,
(I seem to have missed alot of mail, and got it all in one batch!)
I've replied about vhosting in a new thread,
I think the most problems of people are that they fear to "break"
james.. But why we should fear with new junit tests :-P
This is true, but it is also true that some propos
Noel J. Bergman schrieb:
> Steve Brewin wrote:
>
>
>> Norman wrote:
>>
>
>
>>> Vincenzo Gianferrari Pini wrote:
>>>
>
>
> On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>
>
>
>> I've added this point because Noel and Vincenzo brought
>> th
nt message in my drafts. I had decided not to
send it, but in the light of current server-dev discussions I've changed my
mind (obviously). The original context was "Version numbers (Was: LONG JAMES
v2.4 Road Map)". I'm sending this to the PMC as I don't think it good to ai
Stefano wrote:
> Noel wrote:
>> Stefano Bagnara wrote:
>>> I don't agree with your version numbers, but if you can read my message
>>> you will find that I never talked about 2.4 or 3.0
>> See the subject header.
> Then now that I explained you that it was not related to 2.4 you can
> read it again
Hi guys,
so much words again for so few information, and not always fun to read.
anyway, a few very short takes from me to let you know what my preferences are:
Working on trunk towards 3.0: +1
Supporting old configuration in future versions: +1
Working on 2.4 by backporting stuff: +0
Using mi
Noel J. Bergman wrote:
I don't know what's the problem with you.
And I don't know the meaning of "decision by message volume".
See Steve Brewin's e-mail.
I don't agree with your version numbers, but if you can read my message
you will find that I never talked about 2.4 or 3.0
See the subjec
> I don't know what's the problem with you.
> And I don't know the meaning of "decision by message volume".
See Steve Brewin's e-mail.
> I don't agree with your version numbers, but if you can read my message
> you will find that I never talked about 2.4 or 3.0
See the subject header.
Steve Brewin wrote:
> Hi,
>
> I stumbled across this unsent message in my drafts.
Feck! Sorry, too late now.
-- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi,
I stumbled across this unsent message in my drafts. I had decided not to
send it, but in the light of current server-dev discussions I've changed my
mind (obviously). The original context was "Version numbers (Was: LONG JAMES
v2.4 Road Map)". I'm sending this to the PMC
Noel J. Bergman wrote:
Steve Brewin wrote:
Norman wrote:
Vincenzo Gianferrari Pini wrote:
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I've added this point because Noel and Vincenzo brought
this as animportant point in the 2.4 roadmap discussion.
I personally don't care of
Noel J. Bergman wrote:
My proposal is:
- everything we have in trunk now: now I can't see anything critical
enough to be removed.
Well, this was already there ;-)
Release planning by fiat? I think that we would have to be INSANE to
release trunk as JAMES v2.4!
1) This was not a relase p
Noel J. Bergman wrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
And I disagreed with you then, and so did others, and I am really getting
tired of decision by message volume. I don't believe that I am alone in
> > My proposal is:
> > - everything we have in trunk now: now I can't see anything critical
> > enough to be removed.
> Well, this was already there ;-)
Release planning by fiat? I think that we would have to be INSANE to
release trunk as JAMES v2.4!
More to come. And, no, I am not just rea
Steve Brewin wrote:
> Norman wrote:
>> Vincenzo Gianferrari Pini wrote:
> >>> On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> I've added this point because Noel and Vincenzo brought
> this as animportant point in the 2.4 roadmap discussion.
> I personally don't care of
> Slightly more than a month ago I wrote a roadmap, here is an update for
> people that has not time for a day to day oversight.
And I disagreed with you then, and so did others, and I am really getting
tired of decision by message volume. I don't believe that I am alone in
that sentiment.
Trunk
Vincenzo Gianferrari Pini wrote:
> Norman Maurer wrote:
> > Vincenzo Gianferrari Pini schrieb:
> >
> >> Danny Angus wrote:
> >>
> >>> On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> >>>
> >>>
> I've added this point because Noel and Vincenzo brought
> this as an
> important poi
Vincenzo Gianferrari Pini schrieb:
Norman Maurer wrote:
Vincenzo Gianferrari Pini schrieb:
Danny Angus wrote:
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
Norman Maurer wrote:
Vincenzo Gianferrari Pini schrieb:
Danny Angus wrote:
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config
Vincenzo Gianferrari Pini schrieb:
> Danny Angus wrote:
>> On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
>>
>>> I've added this point because Noel and Vincenzo brought this as an
>>> important point in the 2.4 roadmap discussion.
>>> I personally don't care of config.xml compatibility: I
Hi Danny,
something to say ..
Danny Angus schrieb:
> Hi Stefano,
>
> Thanks for your detailed reply, I hope my comments below will reassure
> you that I'm not proposing anything radical, just a slightly more
> visible planning process, and some small refactorings.
> I also hope that we're beginni
and minor cycles to
prevent major changes from blocking defect fixes.
I just saw that you didn't partecipate to this thread 1 month ago. You
should read it and maybe add your comments:
http://www.mail-archive.com/search?l=server-dev%40james.apache.org&q=JAMES+v2.4+Road+Map
I say this
Vincenzo Gianferrari Pini wrote:
Danny Angus wrote:
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reportin
Danny Angus wrote:
On 10/24/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I've added this point because Noel and Vincenzo brought this as an
important point in the 2.4 roadmap discussion.
I personally don't care of config.xml compatibility: I was just
reporting what I understood was important
Danny Angus wrote:
Hi Stefano,
Thanks for your detailed reply, I hope my comments below will reassure
you that I'm not proposing anything radical, just a slightly more
visible planning process, and some small refactorings.
I also hope that we're beginning to reach a common understanding of
what
I extracted things related to VHosting from the roadmap thread, and my
only reply is at the end of this message.
Danny Angus wrote:
I've been very busy for a long time now, but I'm finding more
opportunities now, and I'm keen to re-start where I left off, which
was looking at vhosting and a mai
Hi Danny,
I extracted the status file related sentences from the previous message.
I think that the "in-progress" issues in JIRA already have the
informations you would like to add to the status file:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&pid=10411&status=3
In f
Hi Stefano,
Thanks for your detailed reply, I hope my comments below will reassure
you that I'm not proposing anything radical, just a slightly more
visible planning process, and some small refactorings.
I also hope that we're beginning to reach a common understanding of
what James project is lac
Danny Angus wrote:
On 10/21/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Can we consider timetabling some other changes now that we've made
> such good progress?
Well, I think important things are:
1) don't delay the next release cycle once we added the features we
planned (and currenlty th
On 10/21/06, Norman Maurer <[EMAIL PROTECTED]> wrote:
> In POP3 people would have to use "[EMAIL PROTECTED]" as login and no more
> "user".
Thats exactly what i whould like to see as next steps.. The path of the
mailboxes should also switch then to : /var/mail/domain/user
The enabling/disabling
On 10/21/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
> Can we consider timetabling some other changes now that we've made
> such good progress?
Well, I think important things are:
1) don't delay the next release cycle once we added the features we
planned (and currenlty the only missing big p
Stefano Bagnara wrote:
> I think that the solution I found out-there to provide easy
> out-of-the-box v hosting support is to put "[EMAIL PROTECTED]" into the
> UsersRepository and change "LocalDelivery" (ToMultiRepository) to use
> the full recipient instead of the recipient.getName() when retrie
Stefano Bagnara schrieb:
Danny Angus wrote:
On 10/20/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
Thanks Stefano ;-)
Can we consider timetabling some other changes n
Danny Angus wrote:
On 10/20/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
Thanks Stefano ;-)
Can we consider timetabling some other changes now that we've made
such go
On 10/20/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
Thanks Stefano ;-)
Can we consider timetabling some other changes now that we've made
such good progress?
1/ One
Slightly more than a month ago I wrote a roadmap, here is an update for
people that has not time for a day to day oversight.
Stefano Bagnara wrote:
Norman Maurer wrote:
I agree with Stefano.. And i think we can push a 2.4 release in 6 Month
( At least i hope so).
So i think the next step mu
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 r
On 9/16/06, Stefano Bagnara <[EMAIL PROTECTED]> 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
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 re
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 h
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.)
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 nu
On 9/15/06, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Bernd Fondermann wrote:
>> For me its:
>> 2.3.x = bugfixes
>> 2.4 = 2.3.x + new features ( compatible)
>> 3.0 = incompatible changes
>
> addition: 3.0 = incompatible changes, big new features
>
> +1, thats absolutely my take, and my understan
On 9/15/06, Jürgen Hoffmann <[EMAIL PROTECTED]> 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
o
On 9/15/06, Stefano Bagnara <[EMAIL PROTECTED]> 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 re
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
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 doin
On 9/15/06, Stefano Bagnara <[EMAIL PROTECTED]> 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
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 committe
On 9/15/06, Jürgen Hoffmann <[EMAIL PROTECTED]> 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
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
s
On 9/15/06, Stefano Bagnara <[EMAIL PROTECTED]> 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 eithe
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
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
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 wo
On 9/15/06, Jürgen Hoffmann <[EMAIL PROTECTED]> 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
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 differ
Bernd Fondermann schrieb:
On 9/14/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
I will read and reply to the various comments later, but I want to
put some
figures into the picture.
$ du -hs branches/v2.3/src/java trunk/src/java
13M branches/v2.3/src/java
15M trunk/src/java
$ svn
Vincenzo Gianferrari Pini schrieb:
Stefano Bagnara wrote:
Vincenzo Gianferrari Pini wrote:
Yes, but we already used a different scheme for 2.1, 2.2 and 2.3..
so why change it for 2.4?
Because IMHO it was wrong :-) .
Ok, What I'm trying to say that consistency helps understanding: if
yo
Bernd Fondermann wrote:
For me its:
2.3.x = bugfixes
2.4 = 2.3.x + new features ( compatible)
3.0 = incompatible changes
addition: 3.0 = incompatible changes, big new features
+1, thats absolutely my take, and my understanding about what is
common sense in the industry
And I don't think its on
On 9/15/06, Vincenzo Gianferrari Pini
<[EMAIL PROTECTED]> wrote:
Stefano Bagnara wrote:
> Vincenzo Gianferrari Pini wrote:
>
>
> It's more than one year that I write to this list, you should have
> learned that my discussion are a little rude. Don't take it so hard.
Ok :-) . But we italians (es
On 9/14/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
I will read and reply to the various comments later, but I want to put some
figures into the picture.
$ du -hs branches/v2.3/src/java trunk/src/java
13M branches/v2.3/src/java
15M trunk/src/java
$ svn
diff --old=https://svn.apac
On 9/14/06, Norman Maurer <[EMAIL PROTECTED]> wrote:
Vincenzo Gianferrari Pini schrieb:
> I think that we have different goals and views about what is a minor
> release, and how it should be reflected in the naming (numbering) scheme.
>
> For me (and as I understand also for Noel) a James x.(y+1)
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 defi
Vincenzo Gianferrari Pini wrote:
I think that you can create a new version in jira and call it
"next-minor" and make a list of things you want to merge back in this
release. I hope it is fine for you if I won't work on this branch and
to agree that this release should not block trunk developmen
Stefano Bagnara wrote:
Vincenzo Gianferrari Pini wrote:
Yes, but we already used a different scheme for 2.1, 2.2 and 2.3..
so why change it for 2.4?
Because IMHO it was wrong :-) .
Ok, What I'm trying to say that consistency helps understanding: if
you change the rules in the middle you
Vincenzo Gianferrari Pini wrote:
Furthermore I want to let you know that the new fastfail stuff need
changes to configuration files and would no allow conditions (ii) and
(iv), so using your numbering scheme would not be suitable for 2.4.
My point is (without integralism) to be able to get 2.4
Noel J. Bergman wrote:
I will read and reply to the various comments later, but I want to put some
figures into the picture.
[..]
$ ls -l diff.txt
-rw-rw-r-- 1 noel noel 2056010 Sep 14 13:19 diff.txt
So there are 2MB worth of differences in the Java code between trunk and
v2.3. Some of the 2
Noel J. Bergman schrieb:
I will read and reply to the various comments later, but I want to put some
figures into the picture.
$ du -hs branches/v2.3/src/java trunk/src/java
13M branches/v2.3/src/java
15M trunk/src/java
$ svn
diff --old=https://svn.apache.org/repos/asf/james/server/
I will read and reply to the various comments later, but I want to put some
figures into the picture.
$ du -hs branches/v2.3/src/java trunk/src/java
13M branches/v2.3/src/java
15M trunk/src/java
$ svn
diff --old=https://svn.apache.org/repos/asf/james/server/branches/v2.3/src/j
ava \
Vincenzo Gianferrari Pini wrote:
Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so
why change it for 2.4?
Because IMHO it was wrong :-) .
Ok, What I'm trying to say that consistency helps understanding: if you
change the rules in the middle you don't help people.
And if y
Stefano Bagnara wrote:
Vincenzo Gianferrari Pini wrote:
I think that we have different goals and views about what is a minor
release, and how it should be reflected in the naming (numbering)
scheme.
For me (and as I understand also for Noel) a James x.(y+1) release
should be a release that
Vincenzo Gianferrari Pini schrieb:
I think that we have different goals and views about what is a minor
release, and how it should be reflected in the naming (numbering) scheme.
For me (and as I understand also for Noel) a James x.(y+1) release
should be a release that (i) comes out after no m
Vincenzo Gianferrari Pini wrote:
I think that we have different goals and views about what is a minor
release, and how it should be reflected in the naming (numbering) scheme.
For me (and as I understand also for Noel) a James x.(y+1) release
should be a release that (i) comes out after no mor
I think that we have different goals and views about what is a minor
release, and how it should be reflected in the naming (numbering) scheme.
For me (and as I understand also for Noel) a James x.(y+1) release
should be a release that (i) comes out after no more than 2-3 months
after an x.y re
Am Mittwoch, den 13.09.2006, 10:13 +0200 schrieb Stefano Bagnara:
> Norman Maurer wrote:
> >>> Now I think that not only we should include everything we have now in
> >>> trunk, but we should also define a period of feature development where
> >>> we try to put in every cool feature we are able to
Norman Maurer wrote:
>>> Now I think that not only we should include everything we have now in
>>> trunk, but we should also define a period of feature development where
>>> we try to put in every cool feature we are able to develop in this time
>>> with one single restriction: keep storage compati
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> Noel J. Bergman wrote:
>>> As I said long ago, if you want to move trunk to 2.4, we should
>>> review every difference. Then, if we agree that each one
>>> represents a suitable risk/reward, fine.
>
>> I'm sorry but (as I also said long ago) I
Am Dienstag, den 12.09.2006, 21:44 -0400 schrieb Noel J. Bergman:
> Stefano Bagnara wrote:
>
> > Noel J. Bergman wrote:
> > > As I said long ago, if you want to move trunk to 2.4, we should
> > > review every difference. Then, if we agree that each one
> > > represents a suitable risk/reward, fin
Stefano Bagnara wrote:
> Noel J. Bergman wrote:
> > As I said long ago, if you want to move trunk to 2.4, we should
> > review every difference. Then, if we agree that each one
> > represents a suitable risk/reward, fine.
> I'm sorry but (as I also said long ago) I'm on the opposite position
> a
Noel J. Bergman wrote:
> Norman Maurer wrote:
>
Personally, I'm ready to make it a release, and start work on 2.4,
> which
should be a careful selection of things to add, not a core dump from
> trunk.
>>> We never agreed on this roadmap. And I think I won't agree on this
>>> approach eve
Norman Maurer wrote:
> > > Personally, I'm ready to make it a release, and start work on 2.4,
which
> > > should be a careful selection of things to add, not a core dump from
trunk.
> > We never agreed on this roadmap. And I think I won't agree on this
> > approach even later.
> I agree with Stefa
86 matches
Mail list logo
