On 7/17/08, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Stefano Bagnara ha scritto: >> 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. >> >> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
