--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSS-Idle-bug-handling-approach-tp5815394p5817003.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr
Am 2014-11-26 um 18:05 schrieb tibor17:
Hi Michael,
I've seen that you are closing the issues in SUREFIRE according to
https://cwiki.apache.org/confluence/display/MAVEN/The+Great+JIRA+Cleanup+of+2014
Do you want to make any new regulations in closing the bugs or you suppose
this mail
this message in context:
http://maven.40175.n5.nabble.com/DISCUSS-Idle-bug-handling-approach-tp5815394p5815645.html
Sent from the Maven Developers mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr
I thinks this is great. Add item 5:
5. Some judgement should be used when applying this procedure to
issues that have significant user involvement.
We should probably make 2 tags in jira for issues that are in state 2
and 4; feedbackRequired and Closeable ? :)
Kristian
2014-11-24 22:58
bug where I made an exception which will be categorized as an
improvement possibly in a new JIRA ticket.
-
BR, tibor17
--
View this message in context:
http://maven.40175.n5.nabble.com/DISCUSS-Idle-bug-handling-approach-tp5815394p5815645.html
Sent from the Maven Developers mailing
Folks,
here is a little wrap up after the ideas and votes posted so far:
1. Ask for additional information if you think you can fix that bug or
want to help someone else to drag some attention
2. Give the reporter 30 days
3. Add a reminder after 30 days for a grace period of 10 days
4. 10
Hi folks,
this has been itching me for quite some time now. Once in a while, I
check our JIRA projects for open issues and try to evaluate them for
fixability, etc. While some reporters respond after a question, some
never do.
I'd like to propose to close a ticket as *Incomplete* when the
+1
On Sunday, November 23, 2014, Michael Osipov micha...@apache.org wrote:
Hi folks,
this has been itching me for quite some time now. Once in a while, I check
our JIRA projects for open issues and try to evaluate them for fixability,
etc. While some reporters respond after a question, some
+1
Good idea. I err on the side of expunging to reduce the foot print. If the
person cares enough they will come back. There's a lot of gorp in JIRA.
On Nov 23, 2014, at 2:05 PM, Michael Osipov micha...@apache.org wrote:
Hi folks,
this has been itching me for quite some time now. Once in a
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
detailed descriptions on reproduction and/or quite a few watchers too.
I've seen this rule
Hi,
+1 from me to...
On 11/23/14 8:48 PM, Kristian Rosenvold wrote:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
detailed descriptions
+1
Le dimanche 23 novembre 2014 21:34:31 Karl Heinz Marbaise a écrit :
Hi,
+1 from me to...
On 11/23/14 8:48 PM, Kristian Rosenvold wrote:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
On 23 November 2014 at 19:48, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
I am also slightly sceptical of carpet-bombing jira with this stuff;
once we request more test data we're also giving the expectation that
someone /will/ be looking at the additional data that the user has
supplied. So I would be expecting whoever triages with this method to
also
Am 2014-11-23 um 22:32 schrieb Stephen Connolly:
On 23 November 2014 at 19:48, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs
Am 2014-11-23 um 22:33 schrieb Benson Margulies:
I am also slightly sceptical of carpet-bombing jira with this stuff;
once we request more test data we're also giving the expectation that
someone /will/ be looking at the additional data that the user has
supplied. So I would be expecting
Am 2014-11-23 um 20:48 schrieb Kristian Rosenvold:
I think this is a very good idea. But I have seen this mis-used a few
times in other projects, and I think we want to avoid this scenario:
There are some bugs that have very well written bug reports with
detailed descriptions on reproduction
On 23 November 2014 at 21:33, Benson Margulies bimargul...@gmail.com
wrote:
I am also slightly sceptical of carpet-bombing jira with this stuff;
once we request more test data we're also giving the expectation that
someone /will/ be looking at the additional data that the user has
At m2e, we automatically close bugs that have not seen a meaningful
movement for 12+ months. This helps keep our bug backlog manageable and
m2e users seems to be content with this policy for the most part.
We don't have development resources to fix every single problem in our
projects, so we
19 matches
Mail list logo
