I for
one don’t have time to review 3340 issues to determine the
merits of each or comment on each so how do we tackle this
historical backlog in a way to make it manageable?
I agree
on your comments RE: test case so how about I soften the
proposal a little;
1) Team
triages the issue and decides whether more information or a
test case is required. If no test case or information
required mark the issue as Enhancement or Confirmed Bug.
Otherwise go to step 2.
2)
Request a compilable, reproducible test case hosted in
GitHub as a maven project or more information and detailed
steps to reproduce if a test case is not appropriate.
3) If a
test case or response for more information is not provided
in 2 weeks remind the reporter of the issue of the need for
a response
4) If a
test case or response for more information is not provided
after 4 weeks remind again
5) If a
test case or response for more information is not provided
after 6 weeks close the issue commenting that the issue has
been closed due to inactivity.
My
experience of open source is that the number of issues can
increase rapidly due to the mismatch between the ease with
which an issue can be created and the difficulty required to
investigate and close the issue by both parties. In my
experience many people register GH accounts just to raise an
issue on a project for support but never follow up when
asked for more information. We need to ensure that the
number of issues is manageable at a sustainable level and
that issues where the creator is unresponsive or unhelpful
are closed in a fair but rapid fashion.
Steve
I think you're
setting the bar too high.
First, closing issues without looking at them and with no
comment is a great way to discourage people from filing
issues. I'm fine with closing issues filed against previous
releases with a comment encouraging the submitter to reopen
the issue if it still occurs on 5.x.
Encouraging a reproducible test case is good, but sometimes a
bug is so trivial that creating a reproducible test case is
more work than actually fixing the bug. While we'd like
people to submit pull requests with fixes, sometimes a simple
description of the bug is enough to tell someone familiar with
the code what needs to be fixed. At the other extreme,
sometimes an issue is so complex that there's no reasonable
way to create a reproducible test case. I think we still want
to hear about those issues, however.
We need to allow judgment to be applied on both sides.
If a Committer reviews an issue and determines that a
reproducible test case is going to be needed in order to fix
the bug, then requesting a test case and following your aging
policy might be appropriate. I would be flexible on the form
of the test case. And I wouldn't close a bug that I believe
very likely could be a real bug, just because I didn't have a
reproducible test case.
Steve Millidge (Payara) wrote on 4/6/19
2:45 PM:
Hi,
I think we need to
rationalise the number of GitHub issues in the GlassFish
project. Currently there are 3340 issues many of which
are very old and some of which are random support
requests.
I suggest we have a major
deletion of issues. My suggestions are;
1) Close all issues older
than 2 years
2) Close all issues that
are for versions of GlassFish prior to 5.x
3) Request a reproducible
test case for all bug reports that don't follow the
current template
Finally I think we need to
create an issue aging policy.
The rules that have worked
for me on other projects is;
1) Request a compilable,
reproducible test case hosted in GitHub as a maven
project or detailed steps to reproduce if a test case is
not appropriate.
2) If a test case is not
provided in 2 weeks remind the reporter of the issue of
the need for a test case
3) If a test case is not
provided after 4 weeks remind again
4) If a test case is not
provided after 6 weeks close the issue.
Thoughts everybody?
Steve
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/glassfish-dev
