[groovy-dev] Groovy issues governance

[Thibault Kruse]

Hi,

by mere curiosity I searched Groovy JIRA for issues containing
'groovysh'. I found several recent ones from last year related to
Groovy-2.4.0-betas:

https://jira.codehaus.org/browse/GROOVY-6871
https://jira.codehaus.org/browse/GROOVY-7045
https://jira.codehaus.org/browse/GROOVY-7290

I am not officially supporting Groovysh, but I provided many commits
over the last 2 years. I would have fixed those issues if I had been
made aware of them (given they are most likely caused by my changes,
and they are likely trivial to fix). Instead, those reports remained
unassigned and unanswered.

That in turn may make Groovy as an open-source project look bad, the
persons who kindly provided the reports got no response, and will less
likely provide feedback in the future.

So the question is: Should the process for handling issue reports be
improved, or is it acceptable that such non-critical bugs go
unanswered, given that properly answering all issues takes a lot of
time?

regards,
Thibault

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Am 19.02.2015 18:51, schrieb Thibault Kruse:
[...]

Post by Thibault Kruse
So the question is: Should the process for handling issue reports be
improved, or is it acceptable that such non-critical bugs go
unanswered, given that properly answering all issues takes a lot of
time?

"should be improved" gets us nowhere. There is always a better as there
is a worse. Let us talk about what you have in mind as improvement instead.

bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Thibault Kruse]

It is difficult for me to make a suggestion for an improvement since I
do not know what the status quo is, in terms of what those people who
do get JIRA notifications are currently supposed to do with them.

I personally find it important that every issue gets a timely reply
(within 72h on weekends) that thanks the reporter for his report,
assigns the issue to a real person, and makes an initial
categorization of which subproject is likely to be most relevant to
the issue. This is the minimum of what a reporter can reasonably
expect by a healthy project maintained by volunteers. A reporter
cannot expect an immediate technical response, workaround, patch, or
any other serious work, by a project maintained by volunteers.

Then I would think that when creating release candidates, it would be
useful to write a mail to the community listing all reported issues
tagged with previous release candidates (which are not closed
already), or have no fix version. Something like
"""
The Groovy team is happy to release the second release candidate of Groovy 2.4.

Since the last release candidate, we have been notified of these
unsolved issues:

GROOVY-XXX:
GROOVY-XXX:
"""

This does not mean a next release candidate cannot be created (slowing
us down), but it would be a general heads-up, a possibility for
someone to raise a hand and say: "I can fix this until next week, if
possible hold back the release".

[...]

Post by Thibault Kruse
So the question is: Should the process for handling issue reports be
improved, or is it acceptable that such non-critical bugs go
unanswered, given that properly answering all issues takes a lot of
time?

"should be improved" gets us nowhere. There is always a better as there is a
worse. Let us talk about what you have in mind as improvement instead.
bye blackdrag
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Pascal Schumacher]

Hi Thibault,

sadly there are never enough resources to fix every bug, so most big
open source (and cosed) source projects I'm aware of, have bugs which
are never fixed.

When I report bugs I hope they are fixed or that I'm provided with a
workaround. Every other response - like simply acknowledging the bug -
is just a waste of time in my opinion.

Regards,
Pascal

Post by Thibault Kruse
Hi,
by mere curiosity I searched Groovy JIRA for issues containing
'groovysh'. I found several recent ones from last year related to
https://jira.codehaus.org/browse/GROOVY-6871
https://jira.codehaus.org/browse/GROOVY-7045
https://jira.codehaus.org/browse/GROOVY-7290
I am not officially supporting Groovysh, but I provided many commits
over the last 2 years. I would have fixed those issues if I had been
made aware of them (given they are most likely caused by my changes,
and they are likely trivial to fix). Instead, those reports remained
unassigned and unanswered.
That in turn may make Groovy as an open-source project look bad, the
persons who kindly provided the reports got no response, and will less
likely provide feedback in the future.
So the question is: Should the process for handling issue reports be
improved, or is it acceptable that such non-critical bugs go
unanswered, given that properly answering all issues takes a lot of
time?
regards,
Thibault
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Cédric Champeau]

Hi Thibaut,

With all due respect, this is highly unrealistic. Take the number of open
issues in JIRA and you will have an idea of how much work it represents. As
you said, it's an open-source project and when I started contributing on
Groovy, I started by taking a look at open jira issues and fixing them
myself. You cannot expect the core team to be able to fix everything or
take all issues at the same level of priority. We have lots of things to
do, and I am very sorry that I don't have enough time to review all
tickets, so we make implicit choices. And it's not going to improve if we
cannot work full time on Groovy, so the best thing to do, again, if you
want an issue to be fixed quickly, is to discuss it either on JIRA or the
mailing list.

That said, you are aware that Groovysh got a very special treatment thanks
to your contributions. It is the *only* module where we have accepted
binary breaking changes in dot releases. That means that groovysh is not
binary compatible between 2.0, 2.1, ... Lots of our users would consider
this unacceptable, so it's IMHO more a problem of finding the right balance
between motivating contributors, fixing bugs and not breaking important
rules like binary breaking changes.

Post by Pascal Schumacher
Hi Thibault,
sadly there are never enough resources to fix every bug, so most big open
source (and cosed) source projects I'm aware of, have bugs which are never
fixed.
When I report bugs I hope they are fixed or that I'm provided with a
workaround. Every other response - like simply acknowledging the bug - is
just a waste of time in my opinion.
Regards,
Pascal
Hi,

Post by Thibault Kruse
by mere curiosity I searched Groovy JIRA for issues containing
'groovysh'. I found several recent ones from last year related to
https://jira.codehaus.org/browse/GROOVY-6871
https://jira.codehaus.org/browse/GROOVY-7045
https://jira.codehaus.org/browse/GROOVY-7290
I am not officially supporting Groovysh, but I provided many commits
over the last 2 years. I would have fixed those issues if I had been
made aware of them (given they are most likely caused by my changes,
and they are likely trivial to fix). Instead, those reports remained
unassigned and unanswered.
That in turn may make Groovy as an open-source project look bad, the
persons who kindly provided the reports got no response, and will less
likely provide feedback in the future.
So the question is: Should the process for handling issue reports be
improved, or is it acceptable that such non-critical bugs go
unanswered, given that properly answering all issues takes a lot of
time?
regards,
Thibault
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Thibault Kruse]

My JIRA profile is here:
https://jira.codehaus.org/secure/ViewProfile.jspa?name=tkruse

I am happy to be notified of issues categorized as related to groovysh

On Thu, Feb 19, 2015 at 9:09 PM, Pascal Schumacher

Post by Pascal Schumacher
Hi Thibault,
sadly there are never enough resources to fix every bug, so most big open
source (and cosed) source projects I'm aware of, have bugs which are never
fixed.
When I report bugs I hope they are fixed or that I'm provided with a
workaround. Every other response - like simply acknowledging the bug - is
just a waste of time in my opinion.

I think it is not your or my opinion that matters here, but the
opinion of the people who take the time to report bugs, or not.


On Thu, Feb 19, 2015 at 9:20 PM, Cédric Champeau

Post by Pascal Schumacher
You cannot expect the core team to be able to fix everything or take
all issues at the same level of priority.

I don't think I have said anything like that.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

I've set you up as lead on the groovysh component.
You can subscribe to the SCM list to see all the tickets being opened.
And if there's a new one coming up with groovysh as component, you'll be
assigned automaticall.

Guillaume

Post by Thibault Kruse
https://jira.codehaus.org/secure/ViewProfile.jspa?name=tkruse
I am happy to be notified of issues categorized as related to groovysh
On Thu, Feb 19, 2015 at 9:09 PM, Pascal Schumacher

Post by Pascal Schumacher
Hi Thibault,
sadly there are never enough resources to fix every bug, so most big open
source (and cosed) source projects I'm aware of, have bugs which are

never

Post by Pascal Schumacher
fixed.
When I report bugs I hope they are fixed or that I'm provided with a
workaround. Every other response - like simply acknowledging the bug - is
just a waste of time in my opinion.

I think it is not your or my opinion that matters here, but the
opinion of the people who take the time to report bugs, or not.
On Thu, Feb 19, 2015 at 9:20 PM, Cédric Champeau

Post by Pascal Schumacher
You cannot expect the core team to be able to fix everything or take
all issues at the same level of priority.

I don't think I have said anything like that.
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

Do you have an account on JIRA by the way?
You can get the notifications if you're subscribed, I believe, or if you
subscribe to the scm mailing-list, if you want to help triage tickets.
At least for those Groovysh related issues, you could be made the lead of
that component in JIRA, to be automatically notified / assigned on those
tickets, if you wish (but I couldn't find your account, not sure what it is
if you have one).

Guillaume

Post by Thibault Kruse
Hi,
by mere curiosity I searched Groovy JIRA for issues containing
'groovysh'. I found several recent ones from last year related to
https://jira.codehaus.org/browse/GROOVY-6871
https://jira.codehaus.org/browse/GROOVY-7045
https://jira.codehaus.org/browse/GROOVY-7290
I am not officially supporting Groovysh, but I provided many commits
over the last 2 years. I would have fixed those issues if I had been
made aware of them (given they are most likely caused by my changes,
and they are likely trivial to fix). Instead, those reports remained
unassigned and unanswered.
That in turn may make Groovy as an open-source project look bad, the
persons who kindly provided the reports got no response, and will less
likely provide feedback in the future.
So the question is: Should the process for handling issue reports be
improved, or is it acceptable that such non-critical bugs go
unanswered, given that properly answering all issues takes a lot of
time?
regards,
Thibault
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email