You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Sean Owen <so...@cloudera.com> on 2016/10/08 09:09:42 UTC
PSA: JIRA resolutions and meanings
That flood of emails means several people (Xiao, Holden mostly AFAICT) have
been updating the status of old JIRAs. Thank you, I think that really does
help.
I have a suggested set of conventions I've been using, just to bring some
order to the resolutions. It helps because JIRA functions as a huge archive
of decisions and the more accurately we can record that the better. What do
people think of this?
- Resolve as Fixed if there's a change you can point to that resolved the
issue
- If the issue is a proper subset of another issue, mark it a Duplicate of
that issue (rather than the other way around)
- If it's probably resolved, but not obvious what fixed it or when, then
Cannot Reproduce or Not a Problem
- Obsolete issue? Not a Problem
- If it's a coherent issue but does not seem like there is support or
interest in acting on it, then Won't Fix
- If the issue doesn't make sense (non-Spark issue, etc) then Invalid
- I tend to mark Umbrellas as "Done" when done if they're just containers
- Try to set Fix version
- Try to set Assignee to the person who most contributed to the resolution.
Usually the person who opened the PR. Strong preference for ties going to
the more 'junior' contributor
The only ones I think are sort of important are getting the Duplicate
pointers right, and possibly making sure that Fixed issues have a clear
path to finding what change fixed it and when. The rest doesn't matter much.
Re: PSA: JIRA resolutions and meanings
Posted by Cody Koeninger <co...@koeninger.org>.
That's awesome Sean, very clear.
One minor thing, noncommiters can't change assigned field as far as I know.
On Oct 9, 2016 3:40 AM, "Sean Owen" <so...@cloudera.com> wrote:
I added a variant on this text to https://cwiki.apache.org/
confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-
ContributingtoJIRAMaintenance
On Sat, Oct 8, 2016 at 10:09 AM Sean Owen <so...@cloudera.com> wrote:
> That flood of emails means several people (Xiao, Holden mostly AFAICT)
> have been updating the status of old JIRAs. Thank you, I think that really
> does help.
>
> I have a suggested set of conventions I've been using, just to bring some
> order to the resolutions. It helps because JIRA functions as a huge archive
> of decisions and the more accurately we can record that the better. What do
> people think of this?
>
> - Resolve as Fixed if there's a change you can point to that resolved the
> issue
> - If the issue is a proper subset of another issue, mark it a Duplicate of
> that issue (rather than the other way around)
> - If it's probably resolved, but not obvious what fixed it or when, then
> Cannot Reproduce or Not a Problem
> - Obsolete issue? Not a Problem
> - If it's a coherent issue but does not seem like there is support or
> interest in acting on it, then Won't Fix
> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
> - I tend to mark Umbrellas as "Done" when done if they're just containers
> - Try to set Fix version
> - Try to set Assignee to the person who most contributed to the
> resolution. Usually the person who opened the PR. Strong preference for
> ties going to the more 'junior' contributor
>
> The only ones I think are sort of important are getting the Duplicate
> pointers right, and possibly making sure that Fixed issues have a clear
> path to finding what change fixed it and when. The rest doesn't matter much.
>
>
Re: PSA: JIRA resolutions and meanings
Posted by Sean Owen <so...@cloudera.com>.
I added a variant on this text to
https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-ContributingtoJIRAMaintenance
On Sat, Oct 8, 2016 at 10:09 AM Sean Owen <so...@cloudera.com> wrote:
> That flood of emails means several people (Xiao, Holden mostly AFAICT)
> have been updating the status of old JIRAs. Thank you, I think that really
> does help.
>
> I have a suggested set of conventions I've been using, just to bring some
> order to the resolutions. It helps because JIRA functions as a huge archive
> of decisions and the more accurately we can record that the better. What do
> people think of this?
>
> - Resolve as Fixed if there's a change you can point to that resolved the
> issue
> - If the issue is a proper subset of another issue, mark it a Duplicate of
> that issue (rather than the other way around)
> - If it's probably resolved, but not obvious what fixed it or when, then
> Cannot Reproduce or Not a Problem
> - Obsolete issue? Not a Problem
> - If it's a coherent issue but does not seem like there is support or
> interest in acting on it, then Won't Fix
> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
> - I tend to mark Umbrellas as "Done" when done if they're just containers
> - Try to set Fix version
> - Try to set Assignee to the person who most contributed to the
> resolution. Usually the person who opened the PR. Strong preference for
> ties going to the more 'junior' contributor
>
> The only ones I think are sort of important are getting the Duplicate
> pointers right, and possibly making sure that Fixed issues have a clear
> path to finding what change fixed it and when. The rest doesn't matter much.
>
>
Re: PSA: JIRA resolutions and meanings
Posted by Cody Koeninger <co...@koeninger.org>.
Cool, I'll start going through stuff as I have time. Already closed
one, if anyone sees a problem let me know.
Still think it would be nice to have some way to make it obvious to
the people who have the will and knowledge to do it that it's ok for
them to do it :)
On Sat, Oct 8, 2016 at 2:19 PM, Reynold Xin <rx...@databricks.com> wrote:
> I think so (at least I think it is socially acceptable). Of course, use good
> judgement here :)
>
>
>
> On Sat, Oct 8, 2016 at 12:06 PM, Cody Koeninger <co...@koeninger.org> wrote:
>>
>> So to be clear, can I go clean up the Kafka cruft?
>>
>> On Sat, Oct 8, 2016 at 1:41 PM, Reynold Xin <rx...@databricks.com> wrote:
>> >
>> > On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen <so...@cloudera.com> wrote:
>> >>
>> >>
>> >> - Resolve as Fixed if there's a change you can point to that resolved
>> >> the
>> >> issue
>> >> - If the issue is a proper subset of another issue, mark it a Duplicate
>> >> of
>> >> that issue (rather than the other way around)
>> >> - If it's probably resolved, but not obvious what fixed it or when,
>> >> then
>> >> Cannot Reproduce or Not a Problem
>> >> - Obsolete issue? Not a Problem
>> >> - If it's a coherent issue but does not seem like there is support or
>> >> interest in acting on it, then Won't Fix
>> >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
>> >> - I tend to mark Umbrellas as "Done" when done if they're just
>> >> containers
>> >> - Try to set Fix version
>> >> - Try to set Assignee to the person who most contributed to the
>> >> resolution. Usually the person who opened the PR. Strong preference for
>> >> ties
>> >> going to the more 'junior' contributor
>> >
>> >
>> > +1
>> >
>> > This is consistent with my understanding. It would be good to document
>> > these
>> > on JIRA. And I second "The only ones I think are sort of important are
>> > getting the Duplicate pointers right, and possibly making sure that
>> > Fixed
>> > issues have a clear path to finding what change fixed it and when. The
>> > rest
>> > doesn't matter much."
>> >
>> > I also think it is a good idea to give people rights to close tickets to
>> > help with JIRA maintenance. We can always revoke that if we see a
>> > malicious
>> > actor (or somebody with extremely bad judgement), but we are pretty far
>> > away
>> > from that right now.
>> >
>> >
>> >
>
>
---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
Re: PSA: JIRA resolutions and meanings
Posted by Reynold Xin <rx...@databricks.com>.
I think so (at least I think it is socially acceptable). Of course, use
good judgement here :)
On Sat, Oct 8, 2016 at 12:06 PM, Cody Koeninger <co...@koeninger.org> wrote:
> So to be clear, can I go clean up the Kafka cruft?
>
> On Sat, Oct 8, 2016 at 1:41 PM, Reynold Xin <rx...@databricks.com> wrote:
> >
> > On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen <so...@cloudera.com> wrote:
> >>
> >>
> >> - Resolve as Fixed if there's a change you can point to that resolved
> the
> >> issue
> >> - If the issue is a proper subset of another issue, mark it a Duplicate
> of
> >> that issue (rather than the other way around)
> >> - If it's probably resolved, but not obvious what fixed it or when, then
> >> Cannot Reproduce or Not a Problem
> >> - Obsolete issue? Not a Problem
> >> - If it's a coherent issue but does not seem like there is support or
> >> interest in acting on it, then Won't Fix
> >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
> >> - I tend to mark Umbrellas as "Done" when done if they're just
> containers
> >> - Try to set Fix version
> >> - Try to set Assignee to the person who most contributed to the
> >> resolution. Usually the person who opened the PR. Strong preference for
> ties
> >> going to the more 'junior' contributor
> >
> >
> > +1
> >
> > This is consistent with my understanding. It would be good to document
> these
> > on JIRA. And I second "The only ones I think are sort of important are
> > getting the Duplicate pointers right, and possibly making sure that Fixed
> > issues have a clear path to finding what change fixed it and when. The
> rest
> > doesn't matter much."
> >
> > I also think it is a good idea to give people rights to close tickets to
> > help with JIRA maintenance. We can always revoke that if we see a
> malicious
> > actor (or somebody with extremely bad judgement), but we are pretty far
> away
> > from that right now.
> >
> >
> >
>
Re: PSA: JIRA resolutions and meanings
Posted by Cody Koeninger <co...@koeninger.org>.
So to be clear, can I go clean up the Kafka cruft?
On Sat, Oct 8, 2016 at 1:41 PM, Reynold Xin <rx...@databricks.com> wrote:
>
> On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen <so...@cloudera.com> wrote:
>>
>>
>> - Resolve as Fixed if there's a change you can point to that resolved the
>> issue
>> - If the issue is a proper subset of another issue, mark it a Duplicate of
>> that issue (rather than the other way around)
>> - If it's probably resolved, but not obvious what fixed it or when, then
>> Cannot Reproduce or Not a Problem
>> - Obsolete issue? Not a Problem
>> - If it's a coherent issue but does not seem like there is support or
>> interest in acting on it, then Won't Fix
>> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
>> - I tend to mark Umbrellas as "Done" when done if they're just containers
>> - Try to set Fix version
>> - Try to set Assignee to the person who most contributed to the
>> resolution. Usually the person who opened the PR. Strong preference for ties
>> going to the more 'junior' contributor
>
>
> +1
>
> This is consistent with my understanding. It would be good to document these
> on JIRA. And I second "The only ones I think are sort of important are
> getting the Duplicate pointers right, and possibly making sure that Fixed
> issues have a clear path to finding what change fixed it and when. The rest
> doesn't matter much."
>
> I also think it is a good idea to give people rights to close tickets to
> help with JIRA maintenance. We can always revoke that if we see a malicious
> actor (or somebody with extremely bad judgement), but we are pretty far away
> from that right now.
>
>
>
---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
Re: PSA: JIRA resolutions and meanings
Posted by Reynold Xin <rx...@databricks.com>.
On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen <so...@cloudera.com> wrote:
>
> - Resolve as Fixed if there's a change you can point to that resolved the
> issue
> - If the issue is a proper subset of another issue, mark it a Duplicate of
> that issue (rather than the other way around)
> - If it's probably resolved, but not obvious what fixed it or when, then
> Cannot Reproduce or Not a Problem
> - Obsolete issue? Not a Problem
> - If it's a coherent issue but does not seem like there is support or
> interest in acting on it, then Won't Fix
> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
> - I tend to mark Umbrellas as "Done" when done if they're just containers
> - Try to set Fix version
> - Try to set Assignee to the person who most contributed to the
> resolution. Usually the person who opened the PR. Strong preference for
> ties going to the more 'junior' contributor
>
+1
This is consistent with my understanding. It would be good to document
these on JIRA. And I second "The only ones I think are sort of important
are getting the Duplicate pointers right, and possibly making sure that
Fixed issues have a clear path to finding what change fixed it and when.
The rest doesn't matter much."
I also think it is a good idea to give people rights to close tickets to
help with JIRA maintenance. We can always revoke that if we see a malicious
actor (or somebody with extremely bad judgement), but we are pretty far
away from that right now.
Re: PSA: JIRA resolutions and meanings
Posted by Xiao Li <ga...@gmail.com>.
Thank you, Sean Owen! Your guideline looks pretty good. I will try to
follow it when closing the JIRAs. Please correct me if you found
anything is not appropriate.
Actually, the unresolved SQL JIRAs has almost 1000. Compared with the
other components, I think SQL might be the biggest one. I will try to
go over all of them at my best. Then, maybe the other Committers and
contributors can go over the still-open JIRAs again and see whether
some of them should be closed or resolved in the next releases.
In the future, personally, I will try to do it whenever I am free.
Hopefully, it can help the community.
BTW, since I started joining the Spark community, I already realized
Sean Owen, Reynold Xin, Yin Huai are doing it on a regular basis. I
believe most appreciate their contribution to the community. Here, I
just want to say thank you to them: THANK YOU!
Cheers,
Xiao
2016-10-08 10:56 GMT-07:00 Felix Cheung <fe...@hotmail.com>:
> +1 on this proposal and everyone can contribute to updates and discussions
> on JIRAs
>
> Will be great if this could be put on the Spark wiki.
>
>
>
>
>
> On Sat, Oct 8, 2016 at 9:05 AM -0700, "Ted Yu" <yu...@gmail.com> wrote:
>
> Makes sense.
>
> I trust Hyukjin, Holden and Cody's judgement in respective areas.
>
> I just wish to see more participation from the committers.
>
> Thanks
>
>> On Oct 8, 2016, at 8:27 AM, Sean Owen <so...@cloudera.com> wrote:
>>
>> Hyukjin
>
> ---------------------------------------------------------------------
> To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
>
---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
Re: PSA: JIRA resolutions and meanings
Posted by Felix Cheung <fe...@hotmail.com>.
+1 on this proposal and everyone can contribute to updates and discussions on JIRAs
Will be great if this could be put on the Spark wiki.
On Sat, Oct 8, 2016 at 9:05 AM -0700, "Ted Yu" <yu...@gmail.com>> wrote:
Makes sense.
I trust Hyukjin, Holden and Cody's judgement in respective areas.
I just wish to see more participation from the committers.
Thanks
> On Oct 8, 2016, at 8:27 AM, Sean Owen <so...@cloudera.com> wrote:
>
> Hyukjin
---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
Re: PSA: JIRA resolutions and meanings
Posted by Ted Yu <yu...@gmail.com>.
Makes sense.
I trust Hyukjin, Holden and Cody's judgement in respective areas.
I just wish to see more participation from the committers.
Thanks
> On Oct 8, 2016, at 8:27 AM, Sean Owen <so...@cloudera.com> wrote:
>
> Hyukjin
---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
Re: PSA: JIRA resolutions and meanings
Posted by Sean Owen <so...@cloudera.com>.
I know what you mean Ted, and I think actually what's happening here is
fine, but I'll explain my theory.
There are a range of actions in the project where someone makes a decision,
from answering an email to creating a release. We already accept that only
some of these require a formal status; anyone can answer emails, but only
the PMC can bless a release, for example.
The reason commits and releases require a certain status is not _entirely_
to block most people from participating in these activities. It's in part
because things the ASF's liability protections for releases depend on the
existence of well-defined governance models, that wouldn't quite be
compatible with anyone adding software at will.
Issue management isn't in this category, and, of course, we let anyone make
JIRAs and PRs. This causes problems occasionally but is on the whole
powerfully good. So, it seems reasonable to let people close JIRAs if, in
good faith, they have clear reason to do so. These things are reversible,
too. I also think there's a cost to not getting this triage work done, just
as there would be a cost to blocking people from creating issues.
I've reviewed the cleanup in the past 24 hours and agree with virtually
every action, so I have confidence that in practice this is a big positive.
That said, I have suggested in the past that perhaps only committers should
set "Blocker" and "Target Version", because this communicates something
specific about what will be committed and in what release, and acting on
those requires commit access. Although by the theory above we should let
anyone set these -- and actually, we do -- I have found it usually set
incorrectly, and so, argue that these fields should be treated differently
as a matter of convention.
Sean
On Sat, Oct 8, 2016 at 3:54 PM Holden Karau <ho...@pigscanfly.ca> wrote:
> We could certainly do that system - but given the current somewhat small
> set of active committers its clearly not scaling very well. There are many
> developers in Spark like Hyukjin, Cody, and myself who care about specific
> areas and can verify if an issue is still present in mainline.
>
> That being said if the general view is that only committers should resolve
> JIRAs I'm happy to back off and leave that to the current committers (or we
> could try ping them to close issues which I think are resolved instead of
> closing them myself but given how many pings I sometimes have to make to
> get an issue looked at I'm hesitant to suggest this system).
>
> I'll hold off on my JIRA review for a bit while we get this sorted :)
>
> On Sat, Oct 8, 2016 at 7:47 AM, Ted Yu <yu...@gmail.com> wrote:
>
> I think only committers should resolve JIRAs which were not created by
> himself / herself.
>
>
>
Re: PSA: JIRA resolutions and meanings
Posted by Holden Karau <ho...@pigscanfly.ca>.
We could certainly do that system - but given the current somewhat small
set of active committers its clearly not scaling very well. There are many
developers in Spark like Hyukjin, Cody, and myself who care about specific
areas and can verify if an issue is still present in mainline.
That being said if the general view is that only committers should resolve
JIRAs I'm happy to back off and leave that to the current committers (or we
could try ping them to close issues which I think are resolved instead of
closing them myself but given how many pings I sometimes have to make to
get an issue looked at I'm hesitant to suggest this system).
I'll hold off on my JIRA review for a bit while we get this sorted :)
On Sat, Oct 8, 2016 at 7:47 AM, Ted Yu <yu...@gmail.com> wrote:
> I think only committers should resolve JIRAs which were not created by
> himself / herself.
>
> On Oct 8, 2016, at 6:53 AM, Hyukjin Kwon <gu...@gmail.com> wrote:
>
> I am uncertain too. It'd be great if these are documented too.
>
> FWIW, in my case, I privately asked and told Sean first that I am going to
> look though the JIRAs
> and resolve some via the suggested conventions from Sean.
> (Definitely all blames should be on me if I have done something terribly
> wrong).
>
>
>
> 2016-10-08 22:37 GMT+09:00 Cody Koeninger <co...@koeninger.org>:
>
>> That makes sense, thanks.
>>
>> One thing I've never been clear on is who should be allowed to resolve
>> Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created
>> by me?
>>
>> If there's an informal policy here, can we update the wiki to reflect
>> it? Maybe it's there already, but I didn't see it last time I looked.
>>
>> On Oct 8, 2016 4:10 AM, "Sean Owen" <so...@cloudera.com> wrote:
>>
>> That flood of emails means several people (Xiao, Holden mostly AFAICT)
>> have been updating the status of old JIRAs. Thank you, I think that really
>> does help.
>>
>> I have a suggested set of conventions I've been using, just to bring some
>> order to the resolutions. It helps because JIRA functions as a huge archive
>> of decisions and the more accurately we can record that the better. What do
>> people think of this?
>>
>> - Resolve as Fixed if there's a change you can point to that resolved the
>> issue
>> - If the issue is a proper subset of another issue, mark it a Duplicate
>> of that issue (rather than the other way around)
>> - If it's probably resolved, but not obvious what fixed it or when, then
>> Cannot Reproduce or Not a Problem
>> - Obsolete issue? Not a Problem
>> - If it's a coherent issue but does not seem like there is support or
>> interest in acting on it, then Won't Fix
>> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
>> - I tend to mark Umbrellas as "Done" when done if they're just containers
>> - Try to set Fix version
>> - Try to set Assignee to the person who most contributed to the
>> resolution. Usually the person who opened the PR. Strong preference for
>> ties going to the more 'junior' contributor
>>
>> The only ones I think are sort of important are getting the Duplicate
>> pointers right, and possibly making sure that Fixed issues have a clear
>> path to finding what change fixed it and when. The rest doesn't matter much.
>>
>>
>>
>
--
Cell : 425-233-8271
Twitter: https://twitter.com/holdenkarau
Re: PSA: JIRA resolutions and meanings
Posted by Ted Yu <yu...@gmail.com>.
I think only committers should resolve JIRAs which were not created by himself / herself.
> On Oct 8, 2016, at 6:53 AM, Hyukjin Kwon <gu...@gmail.com> wrote:
>
> I am uncertain too. It'd be great if these are documented too.
>
> FWIW, in my case, I privately asked and told Sean first that I am going to look though the JIRAs
> and resolve some via the suggested conventions from Sean.
> (Definitely all blames should be on me if I have done something terribly wrong).
>
>
>
> 2016-10-08 22:37 GMT+09:00 Cody Koeninger <co...@koeninger.org>:
>> That makes sense, thanks.
>>
>> One thing I've never been clear on is who should be allowed to resolve Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created by me?
>>
>> If there's an informal policy here, can we update the wiki to reflect it? Maybe it's there already, but I didn't see it last time I looked.
>>
>>
>> On Oct 8, 2016 4:10 AM, "Sean Owen" <so...@cloudera.com> wrote:
>> That flood of emails means several people (Xiao, Holden mostly AFAICT) have been updating the status of old JIRAs. Thank you, I think that really does help.
>>
>> I have a suggested set of conventions I've been using, just to bring some order to the resolutions. It helps because JIRA functions as a huge archive of decisions and the more accurately we can record that the better. What do people think of this?
>>
>> - Resolve as Fixed if there's a change you can point to that resolved the issue
>> - If the issue is a proper subset of another issue, mark it a Duplicate of that issue (rather than the other way around)
>> - If it's probably resolved, but not obvious what fixed it or when, then Cannot Reproduce or Not a Problem
>> - Obsolete issue? Not a Problem
>> - If it's a coherent issue but does not seem like there is support or interest in acting on it, then Won't Fix
>> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
>> - I tend to mark Umbrellas as "Done" when done if they're just containers
>> - Try to set Fix version
>> - Try to set Assignee to the person who most contributed to the resolution. Usually the person who opened the PR. Strong preference for ties going to the more 'junior' contributor
>>
>> The only ones I think are sort of important are getting the Duplicate pointers right, and possibly making sure that Fixed issues have a clear path to finding what change fixed it and when. The rest doesn't matter much.
>
Re: PSA: JIRA resolutions and meanings
Posted by Hyukjin Kwon <gu...@gmail.com>.
I am uncertain too. It'd be great if these are documented too.
FWIW, in my case, I privately asked and told Sean first that I am going to
look though the JIRAs
and resolve some via the suggested conventions from Sean.
(Definitely all blames should be on me if I have done something terribly
wrong).
2016-10-08 22:37 GMT+09:00 Cody Koeninger <co...@koeninger.org>:
> That makes sense, thanks.
>
> One thing I've never been clear on is who should be allowed to resolve
> Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created
> by me?
>
> If there's an informal policy here, can we update the wiki to reflect it?
> Maybe it's there already, but I didn't see it last time I looked.
>
> On Oct 8, 2016 4:10 AM, "Sean Owen" <so...@cloudera.com> wrote:
>
> That flood of emails means several people (Xiao, Holden mostly AFAICT)
> have been updating the status of old JIRAs. Thank you, I think that really
> does help.
>
> I have a suggested set of conventions I've been using, just to bring some
> order to the resolutions. It helps because JIRA functions as a huge archive
> of decisions and the more accurately we can record that the better. What do
> people think of this?
>
> - Resolve as Fixed if there's a change you can point to that resolved the
> issue
> - If the issue is a proper subset of another issue, mark it a Duplicate of
> that issue (rather than the other way around)
> - If it's probably resolved, but not obvious what fixed it or when, then
> Cannot Reproduce or Not a Problem
> - Obsolete issue? Not a Problem
> - If it's a coherent issue but does not seem like there is support or
> interest in acting on it, then Won't Fix
> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid
> - I tend to mark Umbrellas as "Done" when done if they're just containers
> - Try to set Fix version
> - Try to set Assignee to the person who most contributed to the
> resolution. Usually the person who opened the PR. Strong preference for
> ties going to the more 'junior' contributor
>
> The only ones I think are sort of important are getting the Duplicate
> pointers right, and possibly making sure that Fixed issues have a clear
> path to finding what change fixed it and when. The rest doesn't matter much.
>
>
>
Re: PSA: JIRA resolutions and meanings
Posted by Cody Koeninger <co...@koeninger.org>.
That makes sense, thanks.
One thing I've never been clear on is who should be allowed to resolve
Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created
by me?
If there's an informal policy here, can we update the wiki to reflect it?
Maybe it's there already, but I didn't see it last time I looked.
On Oct 8, 2016 4:10 AM, "Sean Owen" <so...@cloudera.com> wrote:
That flood of emails means several people (Xiao, Holden mostly AFAICT) have
been updating the status of old JIRAs. Thank you, I think that really does
help.
I have a suggested set of conventions I've been using, just to bring some
order to the resolutions. It helps because JIRA functions as a huge archive
of decisions and the more accurately we can record that the better. What do
people think of this?
- Resolve as Fixed if there's a change you can point to that resolved the
issue
- If the issue is a proper subset of another issue, mark it a Duplicate of
that issue (rather than the other way around)
- If it's probably resolved, but not obvious what fixed it or when, then
Cannot Reproduce or Not a Problem
- Obsolete issue? Not a Problem
- If it's a coherent issue but does not seem like there is support or
interest in acting on it, then Won't Fix
- If the issue doesn't make sense (non-Spark issue, etc) then Invalid
- I tend to mark Umbrellas as "Done" when done if they're just containers
- Try to set Fix version
- Try to set Assignee to the person who most contributed to the resolution.
Usually the person who opened the PR. Strong preference for ties going to
the more 'junior' contributor
The only ones I think are sort of important are getting the Duplicate
pointers right, and possibly making sure that Fixed issues have a clear
path to finding what change fixed it and when. The rest doesn't matter much.