Some of the issues are mine. I'm pretty sure that at some point I realised that to get it working properly for my use case would require forking it to a privately released version. I guess now that it's mostly or all in git, that's feasible. The conflicting requirements across SCMs, the highly varied usage, and the historical bias towards SVN that runs deep through far more than just m-rel-p make it pretty difficult, though. At least, without breaking stuff for existing users.
I'm curious as to what an "irrelevant bug" is? If it's not a bug, then close on review immediately after creation. Fred. On Sat, Jun 27, 2015 at 9:57 PM, Robert Scholte <rfscho...@apache.org> wrote: > It was even worse. > When I joined this team I started working on this plugin and managed to > close half of them ( let's say from 300 back to 150 issues). > Right now there's a situation where new issues are often easy to reproduce. > The older ones are often harder to reproduce or are already fixed. > I've already asked for feedback for a lot of issues. If I go through that > list again,I'm pretty sure I can close a lot again. > Then there are some issues which require some redesign, but without good > code coverage it is hard to discover regression. > For instance, I'd like to replace jdom with woodstox, because there are a > lot of hacks in the code to please jdom. > When I'm done with the M3 plugin migration I'd love to pick it up again. > > Then there's this tricky thing that it should work for all SCM's. It's > great that maven-scm is a separate project, but that might need even more > attention. But then we hit the problem that there's not enough knowledge > for all these systems. And without the ability to verify both the bug and > the fix *I* won't apply those patches (unless the code clearly exposes the > issue). > > thanks, > Robert > > > Op Fri, 26 Jun 2015 22:55:02 +0200 schreef Tibor Digana < > tibordig...@apache.org>: > > > Do you know what's wrong with Jira on maven-release-plugin MRELEASE? >> It's growing nearly to 200 open bugs. It looks like the community use to >> fix 5 in each release. Maybe the community should start closing irrelevant >> bugs which better helps concentrating on more relevant bugs. >> >> We started this strategy in surefire plugin and closed irrelevant bugs. >> This iteration has happened several times already. Then we released cca 30 >> fixed issues in every major release. This way we are now under 100 open >> issues and still cutting the bugs down. >> I have a strategy to handle new bug as it comes in Jira and ask the >> originator to fix it and offering some hints to him/her. This way we have >> got few more contributors in surefire project. Even if the contributor >> does >> not implement properly, it always saves my time and I can still modify his >> implementation or ask him to reimplement it. >> >> Maybe it's the only question if we really want to have better statistics >> and fix more bugs. >> Maybe it's a question of resources like number of committers. We have some >> contributors on GitHub, so maybe it is as simple as to ask them get this >> position. >> >> Cheers >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
