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
<[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
