|
From: David S. <da...@sa...> - 2011-02-14 16:45:45
|
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 <mgu...@ya...> 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 ju...@ya..., 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. I recommend posting these as GitHub issues >> (http://github.com/KentBeck/junit/issues)--feel free to use this forum >> to encourage votes. Thanks, >> >> David 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 available 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 expected 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 @Ignore which is just a little better than removing a test: @NotYetImplemented allows to write tests for "accepted" bugs or future features and to get notified when they are fixed as side effect of other changes >> > >> > - assertEquals & IDE integration >> > small improvement to throw ComparisonFailure not only for String comparison what allows IDE like Eclipse to better display differences between expected and actual result. >> > >> > Cheers, >> > Marc. >> > > > > > > ------------------------------------ > > Yahoo! Groups Links > > <*> To visit your group on the web, go to: > http://groups.yahoo.com/group/junit/ > > <*> Your email settings: > Individual Email | Traditional > > <*> To change settings online go to: > http://groups.yahoo.com/group/junit/join > (Yahoo! ID required) > > <*> To change settings via email: > jun...@ya... > jun...@ya... > > <*> To unsubscribe from this group, send an email to: > jun...@ya... > > <*> Your use of Yahoo! Groups is subject to: > http://docs.yahoo.com/info/terms/ > > |