JUnit issue responsiveness (was: Re: [junit] Re: Misc improvements)

Marc,

In your position, I'd be frustrated, too.  I'll respond to the direct
situation on the original thread, but I wanted to talk here about the
larger context.

For those not aware of the context of Marc's comment, the
highest-voted issue on github is now over a year old, and there are
140 open issues.  By reducing the time to resolve issues, we wouldn't
lose the effort of motivated developers like Marc.

Here's a first couple of steps.

1) For several years now, issue triage and patch acceptance has been
one of several priorities that have competed for time during pair
programming sessions between the developers.  One benefit was that the
project didn't get away from either of us, and we were able to
evaluate proposed changes from multiple perspectives.  I'm going to
try taking solo point on these activities, with Kent as advisor.  Give
me a couple months to get a routine going, and then let me know if the
project seems like a more appealing place to contribute.

2) As part of this, I'll try to provide feedback within a week on new
issues and patches.  This may mean that feature requests we are
unlikely to incorporate will get closed quickly, rather than left open
and abandoned.  Let me know if it starts feeling like too much
pushback.

While this will apply to new issues and patches, there's still a
backlog to get through.  I can't estimate how quickly I'll be able to
get through it, nor am I sure in advance whether I will prioritize the
communication backlog above all new development activities.  If you've
read this far, and would like to bump your issue or patch up in the
queue with a reminder message, I should see it.

JUnit will likely continue to grow more slowly than your average open
source project.  This has had advantages in maintaining a coherent
core of concepts and limited churn in the core.  There are things like
reporting and data parsing that the core junit.jar file is unlikely to
ever do, as it strives to be "the intersection of all useful test
frameworks, not their union".  The Runners and Rules included in
junit.jar have always been intended as examples and starting points
for further extension outside of the core.

I think there could be value in a bundling of JUnitUnion: the JUnit
Core, plus a set of very useful and reusable extensions managed by
people outside the core JUnit team.  I'd love suggestions on the
technical and managerial ways such a super-package could be maintained
and distributed.

Thanks for sticking around.  Share and Enjoy.

   David Saff

On Mon, Feb 14, 2011 at 3:47 AM, mguillemot <[email protected]> wrote:
> Hi David,
>
> not really the most motivating answer :-(
>
> Providing a clean patch requires time. I follow JUnit GitHub issues since=
 long enough to have an idea of what happens there, therefore I will use my=
 time for other activities.
>
> Cheers,
> Marc.
>
>
> --- In [email protected], David Saff <david@...> wrote:
>>
>> Marc,
>>
>> After the release of 4.9 (hopefully soon), my plan is to concentrate
>> development and patching activity on GitHub issues with high vote
>> counts. =A0I recommend posting these as GitHub issues
>> (http://github.com/KentBeck/junit/issues)--feel free to use this forum
>> to encourage votes. =A0Thanks,
>>
>> =A0 =A0David Saff
>>
>> On Thu, Feb 10, 2011 at 12:09 PM, mguillemot <mguillemot@...> wrote:
>> > Hi,
>> >
>> > I would be interested to know if JUnit team would have interest in the=
 features below for integration in JUnit. If yes, I would look at providing=
 patches and if not, I'll find an other way to waste my time ;-)
>> >
>> > - ForkingVMTestRunner
>> > a runner executing the unit tests in a forked virtual machine allowing=
 to test effect of command line JVM switches for instance
>> >
>> > - ParrallelRunner
>> > JUnit already contains nearly the whole code for that but not availabl=
e as runner running tests in parallel
>> >
>> > - ParameterizedRunner
>> > a runner far more flexible than JUnit's Parameterized runner allowing =
to configure usage per method (a bit like TestNG) and for different types
>> >
>> > - @NotYetImplemented
>> > this is an annotation allowing to indicate that a unit test is expecte=
d to fail. A failure should be reported as success whereas a success should=
 be reported as failure. This has proven to be far more interesting than @I=
gnore which is just a little better than removing a test: @NotYetImplemente=
d allows to write tests for "accepted" bugs or future features and to get n=
otified when they are fixed as side effect of other changes
>> >
>> > - assertEquals & IDE integration
>> > small improvement to throw ComparisonFailure not only for String compa=
rison what allows IDE like Eclipse to better display differences between ex=
pected and actual result.
>> >
>> > Cheers,
>> > Marc.
>> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
> <*> To visit your group on the web, go to:
> =A0 =A0http://groups.yahoo.com/group/junit/
>
> <*> Your email settings:
> =A0 =A0Individual Email | Traditional
>
> <*> To change settings online go to:
> =A0 =A0http://groups.yahoo.com/group/junit/join
> =A0 =A0(Yahoo! ID required)
>
> <*> To change settings via email:
> =A0 [email protected]
> =A0 [email protected]
>
> <*> To unsubscribe from this group, send an email to:
> =A0 [email protected]
>
> <*> Your use of Yahoo! Groups is subject to:
> =A0 =A0http://docs.yahoo.com/info/terms/
>
>

---------------------------------------------------------------------------=
---
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb