You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stefano Bagnara <ap...@bago.org> on 2008/07/15 11:31:17 UTC
[mime4j] merge changes from streams-refactoring branch
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
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.
Opinions?
Stefano
PS: if no commit happens in the mean time the merge will be "rm
trunk/src && cp branches/streams-refactoring/src trunk/src".
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: collaboration & branches (Was: [mime4j] merge changes from streams-refactoring
branch)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 7/18/08, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Fri, Jul 18, 2008 at 8:39 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> I don't think you did anything particularly wrong (except leaving
>>>>> trunk with a broken test which I suspect was not done intentionally).
>>>> Well, it was intentional. We never agreed if a failing test proving a bug
>>>> should be something to be committed ASAP or only committed once it pass.
>>>> I
>>>> had the test, so I committed it and created a JIRA.
>>>> If you prefer to not have failing tests in svn the next time I'll attach
>>>> the
>>>> test to JIRA.
>>> IMO committing the failing test was a bad plan for a number of reasons:
>>>
>>> the test is particularly nasty since it thrashes the computer
>>> indefinitely on failure. this is bad for anyone doing continuous
>>> integration builds for Mime4J.
>>>
>>> a failing test effectively freezes trunk and so encourages developers
>>> to dive in with a fix
>> Ok, this is simply a matter of convention and guideline.
>>
>> AFAIK there was no consensus on this in past in JAMES, so I'll take your
>> request for good.
>>
>> We have many failing test now in mime4j (expecially since I activated
>> CRLF checks for a test to pass): what should we do?
>> Do you want me to remove all failing tests and attach to the JIRA I opened?
>
> No - once everything's in trunk we can start fixing them together
I already merged the streams-refactoring. The "repackaging proposal" is
waiting for a comment from you. If you like the proposed package please
reply to that thread (or the JIRA issue) so we can "close" that issue
too and eventually reproduce the refactoring in trunk.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: collaboration & branches (Was: [mime4j] merge changes from streams-refactoring branch)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/18/08, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>> On Fri, Jul 18, 2008 at 8:39 AM, Stefano Bagnara <ap...@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> I don't think you did anything particularly wrong (except leaving
>>>> trunk with a broken test which I suspect was not done intentionally).
>>> Well, it was intentional. We never agreed if a failing test proving a bug
>>> should be something to be committed ASAP or only committed once it pass.
>>> I
>>> had the test, so I committed it and created a JIRA.
>>> If you prefer to not have failing tests in svn the next time I'll attach
>>> the
>>> test to JIRA.
>>
>> IMO committing the failing test was a bad plan for a number of reasons:
>>
>> the test is particularly nasty since it thrashes the computer
>> indefinitely on failure. this is bad for anyone doing continuous
>> integration builds for Mime4J.
>>
>> a failing test effectively freezes trunk and so encourages developers
>> to dive in with a fix
>
> Ok, this is simply a matter of convention and guideline.
>
> AFAIK there was no consensus on this in past in JAMES, so I'll take your
> request for good.
>
> We have many failing test now in mime4j (expecially since I activated
> CRLF checks for a test to pass): what should we do?
> Do you want me to remove all failing tests and attach to the JIRA I opened?
No - once everything's in trunk we can start fixing them together
>
>>> Of course this is my opinion and if the community have different opinions
>>> it
>>> is good we discuss and find consensus so the next time we know what is
>>> accepted.
>>>
>>> What I don't like is criticism when people try to help: just think that
>>> I'm
>>> not here to break your code or create community issues, first, and then
>>> propose improvement to the way we collaborate.
>>>
>>> Furthermore I find it weird that you worked on a branch for IMAP and at
>>> that
>>> time I was repeating "please work in trunk as you are the only developer
>>> working there" and now we have opposite roles ;-)
>>
>> working on a branch was the only choice i was offered
>
> I'm sure I proposed multiple times that you worked in trunk ;-)
> http://markmail.org/message/ohebvfub4xoixxb5
> http://markmail.org/message/nyvbgtxm6e7n2rmk
>
> BTW, next time I think I need a branch I will make sure everyone think
> it is useful. I don't want to scare people because of a branch. At most
> I'll publish the merged code on another server for reference.
The use of the branch to illustrate the repackaging was absolutely
fine. It's just development branches that concern me.
Robert
>
> 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
Re: collaboration & branches (Was: [mime4j] merge changes from streams-refactoring
branch)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Fri, Jul 18, 2008 at 8:39 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> I don't think you did anything particularly wrong (except leaving
>>> trunk with a broken test which I suspect was not done intentionally).
>> Well, it was intentional. We never agreed if a failing test proving a bug
>> should be something to be committed ASAP or only committed once it pass. I
>> had the test, so I committed it and created a JIRA.
>> If you prefer to not have failing tests in svn the next time I'll attach the
>> test to JIRA.
>
> IMO committing the failing test was a bad plan for a number of reasons:
>
> the test is particularly nasty since it thrashes the computer
> indefinitely on failure. this is bad for anyone doing continuous
> integration builds for Mime4J.
>
> a failing test effectively freezes trunk and so encourages developers
> to dive in with a fix
Ok, this is simply a matter of convention and guideline.
AFAIK there was no consensus on this in past in JAMES, so I'll take your
request for good.
We have many failing test now in mime4j (expecially since I activated
CRLF checks for a test to pass): what should we do?
Do you want me to remove all failing tests and attach to the JIRA I opened?
>> Of course this is my opinion and if the community have different opinions it
>> is good we discuss and find consensus so the next time we know what is
>> accepted.
>>
>> What I don't like is criticism when people try to help: just think that I'm
>> not here to break your code or create community issues, first, and then
>> propose improvement to the way we collaborate.
>>
>> Furthermore I find it weird that you worked on a branch for IMAP and at that
>> time I was repeating "please work in trunk as you are the only developer
>> working there" and now we have opposite roles ;-)
>
> working on a branch was the only choice i was offered
I'm sure I proposed multiple times that you worked in trunk ;-)
http://markmail.org/message/ohebvfub4xoixxb5
http://markmail.org/message/nyvbgtxm6e7n2rmk
BTW, next time I think I need a branch I will make sure everyone think
it is useful. I don't want to scare people because of a branch. At most
I'll publish the merged code on another server for reference.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: collaboration & branches (Was: [mime4j] merge changes from streams-refactoring branch)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Jul 18, 2008 at 8:39 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> I don't think you did anything particularly wrong (except leaving
>> trunk with a broken test which I suspect was not done intentionally).
>
> Well, it was intentional. We never agreed if a failing test proving a bug
> should be something to be committed ASAP or only committed once it pass. I
> had the test, so I committed it and created a JIRA.
> If you prefer to not have failing tests in svn the next time I'll attach the
> test to JIRA.
IMO committing the failing test was a bad plan for a number of reasons:
the test is particularly nasty since it thrashes the computer
indefinitely on failure. this is bad for anyone doing continuous
integration builds for Mime4J.
a failing test effectively freezes trunk and so encourages developers
to dive in with a fix
>> I just think that branching is a bad habit to slip into. Long running
>> development branches are a community anti-pattern.
>
> I agree, but I created it no more than 72 hours ago and deleted it now:
> don't tell me that 72 hours is long running ;-)
> In 99% of cases similar branches are only demonstrative: in this very
> specific case a very specific sequence of events made it a devel branch. I
> hope this does not happen so often, but I don't agree that this kind of
> branches are evil at their root and that they create community issues. IMHO
> community issues are more often created by bad mood, bad trust between
> people and similar things.
let's forgot it then
>> In this type of case in a commercial setting, I agree that branching
>> is the best approach. With collaborative open source, patches often
>> work better. They are easy to read quickly and are atomic. RTC
>> projects such as HTTPD handle all development using this system. So I
>> recommend trying it :-)
>
> When a patch involve class movement and renames the resulting diff is not
> readable unless people patch their local code to see the result.
> I bet no one would review the package refactoring for real if there was not
> a real place where to look.
i have no objections to using branches for illustration
> Of course this is my opinion and if the community have different opinions it
> is good we discuss and find consensus so the next time we know what is
> accepted.
>
> What I don't like is criticism when people try to help: just think that I'm
> not here to break your code or create community issues, first, and then
> propose improvement to the way we collaborate.
>
> Furthermore I find it weird that you worked on a branch for IMAP and at that
> time I was repeating "please work in trunk as you are the only developer
> working there" and now we have opposite roles ;-)
working on a branch was the only choice i was offered
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: collaboration & branches (Was: [mime4j] merge changes from streams-refactoring
branch)
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> I don't think you did anything particularly wrong (except leaving
> trunk with a broken test which I suspect was not done intentionally).
Well, it was intentional. We never agreed if a failing test proving a
bug should be something to be committed ASAP or only committed once it
pass. I had the test, so I committed it and created a JIRA.
If you prefer to not have failing tests in svn the next time I'll attach
the test to JIRA.
> I just think that branching is a bad habit to slip into. Long running
> development branches are a community anti-pattern.
I agree, but I created it no more than 72 hours ago and deleted it now:
don't tell me that 72 hours is long running ;-)
In 99% of cases similar branches are only demonstrative: in this very
specific case a very specific sequence of events made it a devel branch.
I hope this does not happen so often, but I don't agree that this kind
of branches are evil at their root and that they create community
issues. IMHO community issues are more often created by bad mood, bad
trust between people and similar things.
> In this type of case in a commercial setting, I agree that branching
> is the best approach. With collaborative open source, patches often
> work better. They are easy to read quickly and are atomic. RTC
> projects such as HTTPD handle all development using this system. So I
> recommend trying it :-)
When a patch involve class movement and renames the resulting diff is
not readable unless people patch their local code to see the result.
I bet no one would review the package refactoring for real if there was
not a real place where to look.
Of course this is my opinion and if the community have different
opinions it is good we discuss and find consensus so the next time we
know what is accepted.
What I don't like is criticism when people try to help: just think that
I'm not here to break your code or create community issues, first, and
then propose improvement to the way we collaborate.
Furthermore I find it weird that you worked on a branch for IMAP and at
that time I was repeating "please work in trunk as you are the only
developer working there" and now we have opposite roles ;-)
I hope this simply means that our positions are not distant and not that
we simply like to disagree ;-)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: collaboration & branches (Was: [mime4j] merge changes from streams-refactoring branch)
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 7/17/08, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <ap...@bago.org>
>>> 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.
>>
>> the package reorganization branch is only demonstrative and there is
>> another topic about it.
>> 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.
>>
>>>> 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.
>
> Just to make it clear the way I work/worked:
>
> - I had to put my hands in the code to understand if the InputBuffer
> change I proposed was good and how it could have been done, so I worked
> on it locally (on a different folder from the one I used to test the
> repackaging). The same applies to the repackaging: IMHO discussing
> similar stuff without touching the code is most often that not a waste
> of time because most time there are issues you find only when you touch
> the code.
>
> - While I was working on that code I also found some bugs and I add new
> test messages (to trunk) to prove the bugs.
>
> - I also found a solution (based on the new code in the branch) to one
> of the bugs: I would have proposed a patch for trunk but I didn't know
> how to solve it in trunk (furthermore the patch for the issue required
> review by mime4j experts, as I'm a newbie wrt this product).
>
> - I thought it was better to commit the code somewhere (a branch)
> instead of leaving this stuff in my pc so people could have better
> reviewed what I worked on.
>
> - I didn't work in trunk directly because you was the main developer
> there and I didn't know if you had uncommitted code or any idea about
> trunk that conflicted with what I worked on, so I chose a branch (in
> jSPF, for example, I would have acted differently and worked on trunk).
>
> - I wrote 2 proposals and didn't apply anything waiting for feedback
> (expecially your).
> http://markmail.org/message/yp2bhma7u5hutjqn
> http://markmail.org/message/mhhvtir27gifcvdy
> http://markmail.org/message/k6ccmng5e4k6nfjk
>
> - I'm willing to merge the work from both branches if there is agreement
> they are good and I'm willing to handle conflicts created in the mean
> time (you can see that even my 2 branches conflict each other so to
> apply both I will have anyway to manually reproduce the changes of at
> least one of them, I don't have problem with that).
>
> - If you have issues with the code in the branch feel free to complain:
> I committed to a branch but it is nothing more than a proposed patch
> waiting for approval (we can svn remove it at any moment)
>
> - If you have issues with the replace of the src folder from a branch
> (please explain them) I can apply the merge by diff+commit or I can even
> reproduce commit by commit the work done there (having committed to a
> branch allow us to do this now, if I simply did the work on my local
> folder it would be hard now to split the change in the various granular
> commits).
>
> Please let me understand what was wrong with this because I thought I
> was simply helping the mime4j project and I was not creating any issue.
> If there is anything in the steps above I should have done differently
> please let's discuss them, because this will be helpful for future
> collaboration.
I don't think you did anything particularly wrong (except leaving
trunk with a broken test which I suspect was not done intentionally).
I just think that branching is a bad habit to slip into. Long running
development branches are a community anti-pattern.
In this type of case in a commercial setting, I agree that branching
is the best approach. With collaborative open source, patches often
work better. They are easy to read quickly and are atomic. RTC
projects such as HTTPD handle all development using this system. So I
recommend trying it :-)
Robert
>
> 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
collaboration & branches (Was: [mime4j] merge changes from streams-refactoring
branch)
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> Robert Burrell Donkin ha scritto:
>> On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <ap...@bago.org>
>> 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.
>
> the package reorganization branch is only demonstrative and there is
> another topic about it.
> 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.
>
>>> 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.
Just to make it clear the way I work/worked:
- I had to put my hands in the code to understand if the InputBuffer
change I proposed was good and how it could have been done, so I worked
on it locally (on a different folder from the one I used to test the
repackaging). The same applies to the repackaging: IMHO discussing
similar stuff without touching the code is most often that not a waste
of time because most time there are issues you find only when you touch
the code.
- While I was working on that code I also found some bugs and I add new
test messages (to trunk) to prove the bugs.
- I also found a solution (based on the new code in the branch) to one
of the bugs: I would have proposed a patch for trunk but I didn't know
how to solve it in trunk (furthermore the patch for the issue required
review by mime4j experts, as I'm a newbie wrt this product).
- I thought it was better to commit the code somewhere (a branch)
instead of leaving this stuff in my pc so people could have better
reviewed what I worked on.
- I didn't work in trunk directly because you was the main developer
there and I didn't know if you had uncommitted code or any idea about
trunk that conflicted with what I worked on, so I chose a branch (in
jSPF, for example, I would have acted differently and worked on trunk).
- I wrote 2 proposals and didn't apply anything waiting for feedback
(expecially your).
http://markmail.org/message/yp2bhma7u5hutjqn
http://markmail.org/message/mhhvtir27gifcvdy
http://markmail.org/message/k6ccmng5e4k6nfjk
- I'm willing to merge the work from both branches if there is agreement
they are good and I'm willing to handle conflicts created in the mean
time (you can see that even my 2 branches conflict each other so to
apply both I will have anyway to manually reproduce the changes of at
least one of them, I don't have problem with that).
- If you have issues with the code in the branch feel free to complain:
I committed to a branch but it is nothing more than a proposed patch
waiting for approval (we can svn remove it at any moment)
- If you have issues with the replace of the src folder from a branch
(please explain them) I can apply the merge by diff+commit or I can even
reproduce commit by commit the work done there (having committed to a
branch allow us to do this now, if I simply did the work on my local
folder it would be hard now to split the change in the various granular
commits).
Please let me understand what was wrong with this because I thought I
was simply helping the mime4j project and I was not creating any issue.
If there is anything in the steps above I should have done differently
please let's discuss them, because this will be helpful for future
collaboration.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] merge changes from streams-refactoring branch
Posted by Stefano Bagnara <ap...@bago.org>.
Serge Knystautas ha scritto:
> On Thu, Jul 17, 2008 at 1:57 PM, Robert Burrell Donkin
>> 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.
>
> +1. I think it's a good observation and a good suggestion to help
> guide future contributions.
I want also to share that community issues in JAMES started long before
we had branches at all.. but this is not the point. It is good to have
an agreement on how to use branches. I agree in principles with that and
I already explained why I think this time was a special case.
I would like to understand how to "mark" a branch as illustrative
(Robert say it is not against illustrative branches): the
stream-refactoring branch has been created with the goal to be
illustrative. I don't know how to mark it so that no one will change it
in a development branch.
I don't have problem in changing the way I work, but I have to
understand what I have 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: [mime4j] merge changes from streams-refactoring branch
Posted by Serge Knystautas <sk...@gmail.com>.
On Thu, Jul 17, 2008 at 1:57 PM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> 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.
>
> 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.
+1. I think it's a good observation and a good suggestion to help
guide future contributions.
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] merge changes from streams-refactoring branch
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Jul 17, 2008 at 7:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Thu, Jul 17, 2008 at 8:21 AM, Stefano Bagnara <ap...@bago.org> wrote:
<snip>
>> 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.
i'm not scared of branches: i just dislike the effect that they tend
to have on communities. it's great that you dived in with some code
and it's great that you shared it with us. i agree that it's best to
have a record but (innocuous as this one might be) private branches
are a bad habit to slip into. patches - or just commiting onto trunk -
are usually much better.
> 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.
i am busy (and unwell) but neither is likely to change any time soon
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] merge changes from streams-refactoring branch
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Thu, Jul 17, 2008 at 8:21 AM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <ap...@bago.org> 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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] merge changes from streams-refactoring branch
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Jul 17, 2008 at 8:21 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <ap...@bago.org> 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)
> the package reorganization branch is only demonstrative and there is another
> topic about it.
cool
> 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
>>> 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.
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.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] merge changes from streams-refactoring branch
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <ap...@bago.org> 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.
the package reorganization branch is only demonstrative and there is
another topic about it.
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.
>> 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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mime4j] merge changes from streams-refactoring branch
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Jul 15, 2008 at 10:31 AM, Stefano Bagnara <ap...@bago.org> 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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org