Branching 2.x

["Noel J. Bergman" <no...@devtech.com>]

I'm looking at a defect (one or more, but seemingly related) in the current
release code, so I'll be forking a branch that is maintainable.

I have already generated a complete diff between 2.3.0 and 2.3.1 to see what
was done to the code and packaging, and stripped out the licensing changes
so that the substantive changes are more apparent.

Other than fixing outstanding defects, adding the per-IP connection support,
and fixing what appears to be a problem related to partial delivery in the
face of exceptions (I'm seeing problems specifically with Yahoo! -- which we
already know doesn't do the right thing -- and bellsouth), one of which is
resulting in an OOM exception no matter how big a heap, nor how few remote
delivery threads, is there anything on anyone's wish list for a 2.working
version?

	--- Noel



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

Re: Branching 2.x

[Norman Maurer <no...@apache.org>]

Noel J. Bergman schrieb:
> I'm looking at a defect (one or more, but seemingly related) in the current
> release code, so I'll be forking a branch that is maintainable.
>
> I have already generated a complete diff between 2.3.0 and 2.3.1 to see what
> was done to the code and packaging, and stripped out the licensing changes
> so that the substantive changes are more apparent.
>
> Other than fixing outstanding defects, adding the per-IP connection support,
> and fixing what appears to be a problem related to partial delivery in the
> face of exceptions (I'm seeing problems specifically with Yahoo! -- which we
> already know doesn't do the right thing -- and bellsouth), one of which is
> resulting in an OOM exception no matter how big a heap, nor how few remote
> delivery threads, is there anything on anyone's wish list for a 2.working
> version?
>
> 	--- Noel
>   

I think it whould be a good step to copy the DNSServer from trunk to the 
branch.. We did some importent bugfixin in there.

bye
Norman


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

Re: Branching 2.x

[robert burrell donkin <ro...@gmail.com>]

On 5/23/07, Noel J. Bergman <no...@devtech.com> wrote:

> one of which is resulting in an OOM exception no matter how big a heap,

what's your JVM version?

- robert

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

Re: Branching 2.x

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

robert burrell donkin ha scritto:
> On 5/23/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Experimental or dead sandboxes are not an issue to me: most of them have
>> been created with the only purpose to show some ideas or to experiment
>> something.
> 
> sometimes it's easier to think about changesets
> 
> sounds like noel has a pressing need to fix issues with his setup.
> this means changing the latest release. it's better if this changeset
> is available to everyone rather then the work just being done locally.
> there's no need to worry about release now.

+1 As I said I always prefer to see code in svn that messages in the
mailing list ;-)
My only concern is about the purpose of the code: if Noel want to work
on his own things and does not want to follow a shared goal then a
server/sandbox/noel-v2.3-fixes is what I suggest.

>> My point is that if you plan to make a release from a branch then it has
>> not to diverge from trunk.
>                                  ^^^^^
> did you mean release branch?

No, I meant trunk. Sorry for my not so good english, I'll try to explain.

We have v2.3 branch and trunk. If you change some code in v2.3 only then
you make it to diverge from trunk. If you instead change the code in
trunk and then backport to v2.3 (when possible, of course) then you
don't have diverging branches.

We have a really small team, IMHO we can't afford multiple diversing
branches.

Btw I think this can be chose by active developers. As PMC member I will
try to require at least one active developer for each release branch and
for trunk before allowing more release branches.

>> If you don't plan to release than I don't
>> care at all: the more code you share in the repository in sandboxes the
>> more I'm happy (I prefer to read a new java file in sandbox than most
>> messages on server-dev).
> 
> this is probably one of those occasions where it's better to think
> about changesets. providing that noel uses good message or (even
> better) commits a record with version  numbers in the STATUS file then
> it doesn't matter. when the time comes, we take a new release branch
> and merge in those changesets which are wanted.
> 
>> I think none of our current sandboxes is alive (excluding the new jcr
>> experiment) and none of them is near to be merged back.
> 
> SEDA IMAP is active

Right. And as I written many times before I think you should merge
everything to trunk, as you are the only active developer on this stuff.

As an user asked in the list today it is difficult otherwise to
understand where the current work is happening and where to look to
start helping.

>> FWIW I updated the STATUS file about the only sandbox I worked on. It
>> would be cool if others can do the same for other sandboxes.
> 
> +1
> 
> i find that version numbers work well

I agree. Unfortunately here there are too many diverging ideas about
what the numbers should be, so we never agreed on numbers.
I will cast my preferences if someone will propose something or start a
vote about this sooner or later.

Stefano


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

Re: Branching 2.x

[robert burrell donkin <ro...@gmail.com>]

On 5/23/07, Stefano Bagnara <ap...@bago.org> wrote:

<snip>


> >> we agreed in past we don't want diverging live branches
> >
> > LOL Yeah, right.  I'm the one who pushed that point, because some of us have
> > already had the joyful experience of having to merge things, but that horse
> > seems to be long out of the barn.  With all of the many development branches
> > in the sandbox ... what else do you call some of the more active ones except
> > for branches ... it'll be a good year or more before things come back
> > together.  Robert is working hard to make that somewhat less painful, so
> > we'll see.
>
> Experimental or dead sandboxes are not an issue to me: most of them have
> been created with the only purpose to show some ideas or to experiment
> something.

sometimes it's easier to think about changesets

sounds like noel has a pressing need to fix issues with his setup.
this means changing the latest release. it's better if this changeset
is available to everyone rather then the work just being done locally.
there's no need to worry about release now.

> My point is that if you plan to make a release from a branch then it has
> not to diverge from trunk.
                                  ^^^^^
did you mean release branch?

> If you don't plan to release than I don't
> care at all: the more code you share in the repository in sandboxes the
> more I'm happy (I prefer to read a new java file in sandbox than most
> messages on server-dev).

this is probably one of those occasions where it's better to think
about changesets. providing that noel uses good message or (even
better) commits a record with version  numbers in the STATUS file then
it doesn't matter. when the time comes, we take a new release branch
and merge in those changesets which are wanted.

> I think none of our current sandboxes is alive (excluding the new jcr
> experiment) and none of them is near to be merged back.

SEDA IMAP is active

> FWIW I updated the STATUS file about the only sandbox I worked on. It
> would be cool if others can do the same for other sandboxes.

+1

i find that version numbers work well

- robert

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

Re: Branching 2.x

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

Summarizing my opinion:

+1 - if you want to create a branch in the sandbox folder using "noel"
in the name to indicate it is a personal area and is not intended to be
used as a release branch.

+1 - if you want to create a proposal (or reuse the next-minor one) to
start a "v2.4" branch as a base to release a 2.3.1 backward compatible
release including some new feature/bugfix from trunk.

If none of the 2 +1 satisfy your request then please explain because I
probably misunderstood your message ;-)

....details in line:

Noel J. Bergman ha scritto:
> Stefano Bagnara wrote:
> 
>> Noel J. Bergman ha scritto:
>>> I'm looking at a defect (one or more, but seemingly related) in the
> current
>>> release code, so I'll be forking a branch that is maintainable.
> 
>> Is this "next-minor" or something new? If it is next-minor (delayed 6
>> months), then simply go ahead, we already agreed on it.
> 
> I've no idea what you call next-minor or anything else.  This is a branch in
> which I can put necessary fixes.  If people want them, fine.  If not,
> consider it an interim fork to have something that works while we do the
> various major re-developments that have been discussed.

If you don't plan to manage a release or to play teamwork on that branch
then I suggest to use sandbox folder and prefix it with "noel-".

Otherwise if you have a description (a branch proposal) for what the
branch is for and you will accept other to commit there respecting the
rule of your branch proposal, imo you can name it v2.4 and we can use it
with the old "next-minor" proposal.

If you don't remember what is next-minor you should read the STATUS file
;-) . In the mean time you could update the STATUS file, too :-)

>>> I have already generated a complete diff between 2.3.0 and 2.3.1 to see
> what
>>> was done to the code and packaging
> 
>> I don't understand why did you need to compare 2.3.0 to 2.3.1 for a new
>> branch: am I missing something? You will branch from "v2.3" and not from
>> build_2.3.0, right?
> 
> I wanted to see the differences between what we used to have in 2.3.0, and
> what we have now.  The tag is stable, so I could compare against the tag
> without that diff changing on me, and separately compare 2.3.1 to the 2.3
> branch to see what else is different.  I've been reviewing every line that
> was changed.

Thank you! Are you telling this because you found something interesting
by this line-to-line compare or only to let us know you finally reviewed
the code we released?

>>> Other than fixing outstanding defects, adding the per-IP connection
> support,
>>> and fixing what appears to be a problem related to partial delivery in
> the
>>> face of exceptions [...] is there anything on anyone's wish list for a
>>> 2.working version?
> 
>> My only request is that you open a JIRA issue (or post a message here)
>> for the OOM exception ASAP and that you explain us what did you find
>> about this OOM issue :-)
> 
> I didn't do anything to "find" it.  The things are sitting in my log files.
> I have a specific message (actually a couple of them), which are *tiny* and
> yet easily reproduce the problem.  I've experimented with expanding the
> heap, reducing the number of concurrent delivery threads, etc., but none of
> that resolved the problem.  It is not a persistent OOM.  You can see the OOM
> get thrown, JAMES recovers, there is plenty of heap, and we start to rebuild
> our resources (e.g., mailboxes that were discarded), and then the same
> message hits and the OOM is thrown.  It is very specifically linked to
> sending a message to bellsouth.net that is has a dozen or more users
> attached, and where we are getting some sort of partial failure.

As you talked of this OOM when proposing what to include in your branch
I thought you already had some code or identified something more.

If this is useful to your investigation I don't restart my main JAMES
Server deployment since 2 months and I deliver almost 1 million message
per day (using 50 threads) and I don't see any OOM. In this deploument I
use a remotedelivery service but most code is inherited by standard
RemoteDelivery, so it is much probable that the OOM is related to a very
specific condition (like you described).

Please keep us updated and open a JIRA issue as soon as you will have
found more informations about the OOM.

>> My personal preference is that you copy "v2.3" to "v2.4" branch
> 
> <<shrug>> I couldn't care less what it is called.  The last time I put fixes
> into JAMES, they were discarded, and our users get to deal with the
> consequences of that action, so this time I'll create a separate branch.

I'm sorry you don't accept the PMC decisions. Fortunately no user (but
you) complained for this yet, so maybe the PMC made the right thing
about this.

> As
> far as I'm concerned, it can be called JAMES-noel, and you can take whatever
> you do or don't want from it.  I really don't care.  I just need something
> stable to run in production while we work on trunk.  Anyone else who wants
> to benefit from it is welcome.  If you guys want to vote it as a release,
> and give it a number, fine.  Otherwise, it's just code.

Btw if you don't plan to work on a release based on that code then my
preference is to create a "noel-v2.3" sandbox. I prefer to not use
branches for code that is not a result of a team work and collective
decisions.

If you work on your own custom sandbox I won't oversight the quality of
the code with release in mind and I will do this only if someone will
eventually propose to create a release or to start a releasing branch
from there. If you start a "v2.4" of course this will instead result in
direct oversight and team-work.

>> and work there by backporting from trunk.
> 
> Yes, I was planning to backport, as I had before.

Noel, you don't really need to remind me what happened, I have a very
clear picture of what happened :-)

>> we agreed in past we don't want diverging live branches
> 
> LOL Yeah, right.  I'm the one who pushed that point, because some of us have
> already had the joyful experience of having to merge things, but that horse
> seems to be long out of the barn.  With all of the many development branches
> in the sandbox ... what else do you call some of the more active ones except
> for branches ... it'll be a good year or more before things come back
> together.  Robert is working hard to make that somewhat less painful, so
> we'll see.
> 
> 	--- Noel

Experimental or dead sandboxes are not an issue to me: most of them have
been created with the only purpose to show some ideas or to experiment
something.

My point is that if you plan to make a release from a branch then it has
not to diverge from trunk. If you don't plan to release than I don't
care at all: the more code you share in the repository in sandboxes the
more I'm happy (I prefer to read a new java file in sandbox than most
messages on server-dev).

I think none of our current sandboxes is alive (excluding the new jcr
experiment) and none of them is near to be merged back.

FWIW I updated the STATUS file about the only sandbox I worked on. It
would be cool if others can do the same for other sandboxes.


Stefano


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

RE: Branching 2.x

["Noel J. Bergman" <no...@devtech.com>]

Stefano Bagnara wrote:

> Noel J. Bergman ha scritto:
> > I'm looking at a defect (one or more, but seemingly related) in the
current
> > release code, so I'll be forking a branch that is maintainable.

> Is this "next-minor" or something new? If it is next-minor (delayed 6
> months), then simply go ahead, we already agreed on it.

I've no idea what you call next-minor or anything else.  This is a branch in
which I can put necessary fixes.  If people want them, fine.  If not,
consider it an interim fork to have something that works while we do the
various major re-developments that have been discussed.

> > I have already generated a complete diff between 2.3.0 and 2.3.1 to see
what
> > was done to the code and packaging

> I don't understand why did you need to compare 2.3.0 to 2.3.1 for a new
> branch: am I missing something? You will branch from "v2.3" and not from
> build_2.3.0, right?

I wanted to see the differences between what we used to have in 2.3.0, and
what we have now.  The tag is stable, so I could compare against the tag
without that diff changing on me, and separately compare 2.3.1 to the 2.3
branch to see what else is different.  I've been reviewing every line that
was changed.

> > Other than fixing outstanding defects, adding the per-IP connection
support,
> > and fixing what appears to be a problem related to partial delivery in
the
> > face of exceptions [...] is there anything on anyone's wish list for a
> > 2.working version?

> My only request is that you open a JIRA issue (or post a message here)
> for the OOM exception ASAP and that you explain us what did you find
> about this OOM issue :-)

I didn't do anything to "find" it.  The things are sitting in my log files.
I have a specific message (actually a couple of them), which are *tiny* and
yet easily reproduce the problem.  I've experimented with expanding the
heap, reducing the number of concurrent delivery threads, etc., but none of
that resolved the problem.  It is not a persistent OOM.  You can see the OOM
get thrown, JAMES recovers, there is plenty of heap, and we start to rebuild
our resources (e.g., mailboxes that were discarded), and then the same
message hits and the OOM is thrown.  It is very specifically linked to
sending a message to bellsouth.net that is has a dozen or more users
attached, and where we are getting some sort of partial failure.

> My personal preference is that you copy "v2.3" to "v2.4" branch

<<shrug>> I couldn't care less what it is called.  The last time I put fixes
into JAMES, they were discarded, and our users get to deal with the
consequences of that action, so this time I'll create a separate branch.  As
far as I'm concerned, it can be called JAMES-noel, and you can take whatever
you do or don't want from it.  I really don't care.  I just need something
stable to run in production while we work on trunk.  Anyone else who wants
to benefit from it is welcome.  If you guys want to vote it as a release,
and give it a number, fine.  Otherwise, it's just code.

> and work there by backporting from trunk.

Yes, I was planning to backport, as I had before.

> we agreed in past we don't want diverging live branches

LOL Yeah, right.  I'm the one who pushed that point, because some of us have
already had the joyful experience of having to merge things, but that horse
seems to be long out of the barn.  With all of the many development branches
in the sandbox ... what else do you call some of the more active ones except
for branches ... it'll be a good year or more before things come back
together.  Robert is working hard to make that somewhat less painful, so
we'll see.

	--- Noel



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

Re: Branching 2.x

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

Noel J. Bergman ha scritto:
> I'm looking at a defect (one or more, but seemingly related) in the current
> release code, so I'll be forking a branch that is maintainable.

Is this "next-minor" or something new? If it is next-minor (delayed 6
months), then simply go ahead, we already agreed on it.

> I have already generated a complete diff between 2.3.0 and 2.3.1 to see what
> was done to the code and packaging, and stripped out the licensing changes
> so that the substantive changes are more apparent.

I don't understand why did you need to compare 2.3.0 to 2.3.1 for a new
branch: am I missing something? You will branch from "v2.3" and not from
build_2.3.0, right?

> Other than fixing outstanding defects, adding the per-IP connection support,
> and fixing what appears to be a problem related to partial delivery in the
> face of exceptions (I'm seeing problems specifically with Yahoo! -- which we
> already know doesn't do the right thing -- and bellsouth), one of which is
> resulting in an OOM exception no matter how big a heap, nor how few remote
> delivery threads, is there anything on anyone's wish list for a 2.working
> version?

My only request is that you open a JIRA issue (or post a message here)
for the OOM exception ASAP and that you explain us what did you find
about this OOM issue :-)

My personal preference is that you copy "v2.3" to "v2.4" branch and work
there by backporting from trunk. If you write any code specific to v2.4
and not being written in trunk first, please explain why (as we agreed
in past we don't want diverging live branches).

Stefano

PS: I'm happy to see some new activity from you.


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