Robert Burrell Donkin ha scritto:
On Thu, Jul 17, 2008 at 8:21 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
Robert Burrell Donkin ha scritto:
On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
I created a branch to commit the code I worked on in the last 2 days.
The branch included commits to fix:
MIME4J-50 - InputBuffer to extend FilterInputStream
http://issues.apache.org/jira/browse/MIME4J-50
MIME4J-52 - Infinite loop when nested multipart is missing end boundary
http://issues.apache.org/jira/browse/MIME4J-52
MIME4J-56 - In nested multiparts outer boundaries are not recognized when
parsing inner multiparts
http://issues.apache.org/jira/browse/MIME4J-56
when the branch was mooted, AIUI the idea was to allow people to
easily understand the proposed repackaging. now it's turned into a
development branch. i'm not impressed.
sorry Robert, I opened 2 different branches.
ok: my confusion (i should have double checked but was a little short of time)
np
the package reorganization branch is only demonstrative and there is another
topic about it.
cool
There is still discussion about that branch: please keep up with your
comments on the "Review Packaging" thread so we find a fast solution to
that too.
This one instead was to let me study how to refactor the InputBuffer and to
fix the related issues. I didn't do this in the main tree simply because I
don't know who is working there and if people had work in progress patches,
so I preferred to simply work somewhere else and to propose a merge later.
this may be easier in the short term but tends to lead to community issues.
IMO a series of patches posted to a JIRA would be an better way to
discuss and develop a solution
You know it was not intended to end in a to-be-merged branch. Random
events caused me to have a "refactor in progress" local folder while a
bug has been filed and I found that within that refactoring was easy to
fix that bug. This led me to create a branch to share what was doing
before leaving.
Unfortunately this also happened during days where you was much less
active (busy) and you didn't follow the issue on a hourly basis like
other days.
Oleg decided that my refactoring and the bug fix was helpful and also
simplified his next work and decided to provide patches against the same
branch, but this is not what I suggested.
In my plan Oleg would have continued bug fixing in trunk and I would
have managed conflict resolution / merging of my code if we eventually
agreed on what I was proposing.
And it also include the stream renaming proposed in the thread "[mime4j]
BufferingInputStreamAdaptor => BufferedInputStreamFilter".
Please note that MIME4J-56 require a fix even if we don't want MIME4J-50
but
my fix depends I have not a fix for it without first applying MIME4J-50,
so
this is why I'm proposing this "merge" instead of single patches.
I'd like to merge the work from this branch to trunk and to remove the
branch ASAP as we also have a bunch of new critical bugs to be fixed in
trunk before we can try a release.
right or wrong, please merge it now
Robert, can you explain me what's wrong with me having created a branch for
the stream-refactoring? I'm not sure I understand the issue and I don't want
to make the same mistake in future.
breaking trunk and then taking a branch without discussion is
annoying. it's bound to lead to conflicts as soon as anyone needs to
have a working trunk and so dives in. it's inevitable that your branch
will be merged in so it's better to merge and fix ASAP so that trunk
is available for development.
My opinion is that it is better some code in an svn folder than in my
local disc, but if no one else share this idea next time I will not
commit to a branch.
This time it happened something unexpected simply because the patch I
was proposing probably found the consent from Oleg and simplified his
bug hunting, too.
I will merge it ASAP (tomorrow morning, probably).
IMO excessive use of branching lies at the heart of many of community
issues experience by JAMES. when branches are used in this way, there
tends to be a lack of community engagement and involvement in the
branch and the results are present as a complete take-it-or-leave-it
solution.
I usually use branches/sandbox only to demonstrate stuff or as part of
the release process.
I knew you and Oled was much more active than me that days and so I
decided my work on trunk would have created issue and it was not
appropriate for a JIRA patch because of the related issue based on that
patch (patch against patched code in JIRA is useless IMHO).
You are too much scared of the branch: if Oleg simply ignored my branch
and kept fixing bugs in trunk I would have simply waited agreement on my
branch and committed the needed stuff the same way I would have done
with local code or with JIRA patches.
May it be you are much more busy than a week ago and you had no time to
understand what was going on? I hope this is the case.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
