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) > 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
