Jenkins JIRA

[Andrew Gray]

Hi All,

Looking at the list of all open Bugs for the Jenkins project, (at time of writing) there are 1,012 matching tickets.

Many of the oldest ones like JENKINS-1640 do not appear to be active any more despite still be open.

Is the community ignoring these old issues since the move from Hudson to Jenkins?

Are all open issues still be considered active?

I'm imagining an idealised state were we have only 100 open bugs no more than 3 months old.

Regards,

Andrew

[Ulli Hafner]

I think we simply have not the manpower to catch up with the number of bugs reported. There are a lot of old issues that are not valid anymore or could not be reproduced anymore.  But it would take a lot of time to check the status for each bug. And it would take even more time to fix the remaining ones. So I'm not sure if it would help to identify the still valid ones if we don't have the manpower to fix all of these. 

At least the first part, i.e. identifying the still valid issues, could be done by some volunteers. It should not need much core knowledge to verify which issues are still valid and should be considered for a release. 

Ulli

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Andrew Gray]

Could it be the subject of a testing meetup?

Just a thought.

a whole bunch of open source enthusiasts with a bend for testing find eliminate all the non-reproducible issues.

Just a thought.

[Jesse Glick]

On Tue, Oct 22, 2013 at 6:53 AM, Andrew Gray <andrew.p...@gmail.com> wrote:
> eliminate all the non-reproducible issues

Unfortunately this would be most of the issues that get filed, even
those whose cause could be guessed at and perhaps fixed.

[Stephen Connolly]

Mwah ha ha... I decided to spend 45min closing some old issues...

[Andrew Gray]

Thanks you Stephen

[Stephen Connolly]

JENKINS-455 fixed!

[evernat]

Hi all,

I feel concerned about this subject.
After all, I have looked at, resolved as duplicate, asked the reporter for more, closed because of issue resignation from reporters, refused and often left alone those old Jenkins issues for some years now.

In all Jenkins' time, for every newly opened issue, the reporter has about 40% chance that the issue will stay open forever, and about 60% chance that the issue will be resolved as fixed, or something like incomplete because of no response from the reporter after about 1 year. This ratio is really a constant for several years in Jenkins JIRA, core and plugins included.

What's the problem with that:
- Nobody could know what real issues can be in their current Jenkins server
- At best, there are probably hundreds of valid bugs that will never get fixed, core and "popular" plugins included
- Yes, there are many invalid, incomplete and not reproduced issues in JIRA (blame reporters!), but they are rarely commented as "need more information" and rarely said as "we don't care about your issue because you are the only guy concerned"
- To me, opened and valid bugs feel a bit like "I have made so much crap code, can you find a fix for me?"

Of course, whatever Jenkins is, all the reporters in JIRA should understand that the road to a fix comes from the tests from the reporter and then a good issue and perhaps a pull request, but not from those stupid developers. Except by calling Olivier, I don't know how to make them understand.

Yours truly,
Emeric

[Daniel Beck]

Is there a guideline how to use the Jenkins Jira as a regular user?

I've seen many issues that seem obsolete, incomplete, or just plain wrong (this feature not being implemented is not a bug!), but I've always hesitated to just close or relabel them, especially when it's about a plugin, as I'm no more an authority on what's a valid issue than the guy that opened it. On Stack Overflow, I'd "flag for moderator attention", but there's no such feature in Jira.

[1] doesn't cover what seems to be the most common case, a reporter not responding to questions in comments, or any other situations unrelated to reproducing an issue or verifying a fix.

1: https://wiki.jenkins-ci.org/display/JENKINS/Beginners+Guide+to+Contributing

[Andrew Gray]

Based on the points raised in the discussion maybe there is scope to have some ground rules for open tickets. Something like:

A ticket can be closed if:

- no activity for 12 months.

- no response from the reporter to requests for information for 12 months.

Applying this may mean we have a better chance of seeing the wood for the trees so to speak.

What does everyone think?

Cheers,

Andrew

[Slide]

+1

--
Website: http://earl-of-code.com

[Kohsuke Kawaguchi]

On 10/22/2013 02:49 PM, Andrew Gray wrote:
> Based on the points raised in the discussion maybe there is scope to
> have some ground rules for open tickets. Something like:
>
> A ticket can be closed if:
> - no activity for 12 months.

How does doing this help us improve the speed/quality/etc of bug fixes?

Today, you can see the list of recently updated open issues by issuing
an appropriate query. Wouldn't that achieve the same result?

> - no response from the reporter to requests for information for 12 months.

Closing a ticket, when the reporter fails to provide requested details,
that's a fair game.

> Applying this may mean we have a better chance of seeing the wood for
> the trees so to speak.
>
> What does everyone think?
>
> Cheers,
>
> Andrew
>
> On Wednesday, October 23, 2013, Daniel Beck wrote:
>
> Is there a guideline how to use the Jenkins Jira as a regular user?
>
> I've seen many issues that seem obsolete, incomplete, or just plain
> wrong (this feature not being implemented is not a bug!), but I've
> always hesitated to just close or relabel them, especially when it's
> about a plugin, as I'm no more an authority on what's a valid issue
> than the guy that opened it. On Stack Overflow, I'd "flag for
> moderator attention", but there's no such feature in Jira.
>
> [1] doesn't cover what seems to be the most common case, a reporter
> not responding to questions in comments, or any other situations
> unrelated to reproducing an issue or verifying a fix.
>
> 1:
> https://wiki.jenkins-ci.org/display/JENKINS/Beginners+Guide+to+Contributing
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jenkinsci-de...@googlegroups.com

> <javascript:;>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

[Kohsuke Kawaguchi]

On 10/22/2013 12:50 PM, Daniel Beck wrote:
> Is there a guideline how to use the Jenkins Jira as a regular user?

Sounds like the question is more about how to use it as a developer.

>
> I've seen many issues that seem obsolete, incomplete, or just plain
> wrong (this feature not being implemented is not a bug!), but I've
> always hesitated to just close or relabel them, especially when it's
> about a plugin, as I'm no more an authority on what's a valid issue
> than the guy that opened it. On Stack Overflow, I'd "flag for moderator
> attention", but there's no such feature in Jira.

I'd say you should go ahead and make these updates. You spent the
cognitive effort groking the issue, we should leave that in the record.

Nothing you do in the issue tracker is irreversible. If other people
disagreed they just need to reopen or reroute the ticket.

Except in a few plugins where there's a clear de-facto owner, plugins do
not have any "authoritative source" more often than not.

>
> [1] doesn't cover what seems to be the most common case, a reporter not responding to questions in comments, or any other situations unrelated to reproducing an issue or verifying a fix.
>
> 1: https://wiki.jenkins-ci.org/display/JENKINS/Beginners+Guide+to+Contributing
>

[Marcelo]

+1 for bugs

But I'm not sure do this with New Features and Improvements requests.

For example, the issue JENKINS-1201 was open on "22/Jan/08", has 26 votes, but until this year no one had time for finish the new feature, when i needed a similar functionality for my job. The last update until I took the issue was issued on "14/Feb/11".

The point is that the history of this issue really helped, because other people had already analyzed it (and half implemented) before me.

[Jesse Glick]

On Tue, Oct 22, 2013 at 6:50 PM, Marcelo <mreb...@gmail.com> wrote:
> But I'm not sure do this with New Features and Improvements requests.
>
> For example, the issue JENKINS-1201 was open on "22/Jan/08", has 26 votes,
> but until this year no one had time for finish the new feature

That is normal enough, and no reason to close the issue. An RFE should
be closed if it seems to be obsolete, or the description is hopelessly
muddled, or the functionality is too marginal for anyone to
realistically ever bother with it. But there are plenty of RFEs which
you can look at and say “yes, this makes as much sense today as when
it was filed, and it would be great if someone worked on this”; the
same is true of a lot of bugs.

[Daniel Beck]

On 22.10.2013, at 23:49, Andrew Gray <andrew.p...@gmail.com> wrote:

> - no activity for 12 months.

An issue thats not constantly being updated might simply mean it's well described. Nothing needs to be added, or asked. I don't think changes to watchers and votes count as activity, so this would affect issues with tons of followers accumulating over time as well. This would mostly impact the difficult requests for no real reason.

OTOH getting a few core devs to agree that something will never be fixed/added might be a possible solution for the hopeless ones. But that'll take some effort.

[Owen Mehegan]

I mentioned this issue to Kohsuke in IRC recently. One of the ways I've tried to contribute to Jenkins has been by filing good bugs and following up on them. Sometimes it takes some legwork to find the right person to assign them to (the JIRA default is not always right), and when I see that something has been fixed I close the bug.

That said, I would be willing to organize a regular volunteer bug scrub if anyone else is interested in helping. Perhaps we could coordinate via IRC, each grab a bunch of stale open issues, and see if we can get movement or closure on them. If this sounds good, get in touch and I'll help get it going.

--
Twitter: literatesavant
IRC: autojack
www.holisticqa.com -- my dev productivity blog

[Stephen Connolly]

Go for it!

[Mark Waite]

I'm interested in helping with the bug scrub effort.

Most of my efforts have been focused on testing and bug scrubbing for the Git plugin, and I'd prefer to keep my focus there, since I've learned many things by focusing my testing and bug verification efforts on that plugin.

Mark Waite

[Owen Mehegan]

I'll coordinate this with Mark to start with, to avoid spamming the list. If anyone else is interested, email me! If it sticks, perhaps we can give it some more official attention/advertisement. 

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/B1ONTcvhXBU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.