On Fri, Jul 18, 2008 at 8:39 AM, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
