You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2012/08/08 05:57:13 UTC
[lucy-dev] RT vs JIRA
Because Lucy is distributed through CPAN, we often get RT tickets opened[0].
That means we have 2 competing ticketing systems, our official Apache JIRA
system being the other.
When we eventually distribute through other host-language-specific systems like
CPAN, the issue will get worse.
What's the preferred way of dealing with this kind of situation?
[0] https://rt.cpan.org/Dist/Display.html?Queue=Lucy
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] RT vs JIRA
Posted by "David E. Wheeler" <da...@justatheory.com>.
On Aug 9, 2012, at 3:06 PM, Marvin Humphrey wrote:
> These are covered. The dev list notifications that Github pull
> requests trigger include
> the SHA sum. I wrote the code. :)
>
> http://markmail.org/message/bxvva44n77vre34a
> https://issues.apache.org/jira/browse/INFRA-4651
Nice!
David
Re: [lucy-dev] RT vs JIRA
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Aug 9, 2012 at 2:56 PM, David E. Wheeler <da...@justatheory.com> wrote:
> What you are more likely to see are pull requests on the GitHub mirror.
These are covered. The dev list notifications that Github pull
requests trigger include
the SHA sum. I wrote the code. :)
http://markmail.org/message/bxvva44n77vre34a
https://issues.apache.org/jira/browse/INFRA-4651
Marvin Humphrey
Re: [lucy-dev] RT vs JIRA
Posted by "David E. Wheeler" <da...@justatheory.com>.
On Aug 9, 2012, at 1:58 PM, Chris Hostetter wrote:
> But many users don't know /think to search svn history -- particularly
> when there is an official bug tracker and docs saying that they can search
> that bug tracker to find out all about known bugs/fixes in particular
> erions.
Yeah.
> To be clear: i was definitely refering to the commiter opening a Jira to
> track any bug fix they do based on annecdotal reports they hear about form
> the mailing list, blog, stackoverflow, CPAN RT, etc... by no means is it
> a good idea to tell people "we'll only fix this bug if you file it in the
> right place" ... it's definitley more productive to say "thanks for
> mentioning this, i've filed it in the official bug tracker and i'll take a
> look" -- hell, that's usually helpful even if you don't have any idea how
> to fix the bug. i do that in Lucene/Solr all the time. (it doesn't take
> long ... half the time i just cut/paste the meat of hte problem and
> include a URL to where i saw it mentioned)
Great, as it should be. :-)
> if you commit that code, based on that blog comment, and cite the authors
> permission and hte blog URL in your commit message, you're *probably* ok
> ... but what happens if the site hosting that blog goes away in 3 years?
> what happens 2 years after that if the author of that code says the ASF
> is stealing his IP?
I would probably re-confirm via email before committing.
> Is it likely? not really ... but it's the reason why it's a good idea to
> get any "non-trivial" contributions "on the record" in the ASF mailing
> list or ASF Jira instance.
What you are more likely to see are pull requests on the GitHub mirror.
Best,
David
Re: [lucy-dev] RT vs JIRA
Posted by Chris Hostetter <ho...@fucit.org>.
: Well, we have version control, too. That ought to be sufficient for a
: simple fix such as this.
But many users don't know /think to search svn history -- particularly
when there is an official bug tracker and docs saying that they can search
that bug tracker to find out all about known bugs/fixes in particular
erions.
: My humble $0.02 is: Accept reports and patches from *anywhere*, always
: be friendly to contributors, minimize the hoops they have to jump
: through. If it’s important to the project that everything be added to
: Jira, then it should be *our* responsibility to do that (and reference
: the Jira ticket in response to the OP in their ticket system).
To be clear: i was definitely refering to the commiter opening a Jira to
track any bug fix they do based on annecdotal reports they hear about form
the mailing list, blog, stackoverflow, CPAN RT, etc... by no means is it
a good idea to tell people "we'll only fix this bug if you file it in the
right place" ... it's definitley more productive to say "thanks for
mentioning this, i've filed it in the official bug tracker and i'll take a
look" -- hell, that's usually helpful even if you don't have any idea how
to fix the bug. i do that in Lucene/Solr all the time. (it doesn't take
long ... half the time i just cut/paste the meat of hte problem and
include a URL to where i saw it mentioned)
There is however a slight grey area in "accept patches from anywhere"
because of the audit trail ...
if someone posts a *small* patch on pastebin or a blog comment that fixes
something (doc, minor bug, whatever) in an "obvious" way (ie: that would
be clear to anyone knowledgable of the code if you described the problem
and pointed them at the affected lines) then it's fair game to commit w/o
formal tracking in Jira -- but for anything substantial you have to watch
out for the audit trail of the contribution --- lets say someone writes a
blog post about a feature or optimization, and includes in that blog post
a big hunk of new code and or a patch to existing code -- and in the
coments of that blog you say "hey this is cool, you should contribute it
back to Lucy" and the author comments back "you're welcome to commit it"
-- but the author doesn't personally ever actaully post it to Jira or send
it to an apache mailing list as an attachment saying "here is a
contribution for the project".
if you commit that code, based on that blog comment, and cite the authors
permission and hte blog URL in your commit message, you're *probably* ok
... but what happens if the site hosting that blog goes away in 3 years?
what happens 2 years after that if the author of that code says the ASF
is stealing his IP?
Is it likely? not really ... but it's the reason why it's a good idea to
get any "non-trivial" contributions "on the record" in the ASF mailing
list or ASF Jira instance.
-Hoss
Re: [lucy-dev] RT vs JIRA
Posted by "David E. Wheeler" <da...@justatheory.com>.
On Aug 9, 2012, at 10:38 AM, Chris Hostetter wrote:
> : Should I also have opened a JIRA ticket? I'm lazy. I'd prefer not to. I
> : referenced the RT ticket in my svn commit message, because as I saw it, that
> : constituted an adequate audit trail considering there was little question of IP
> : conflict. Was that adequate? I dunno. Hence, this thread.
Seems adequate to me.
> I don't follow the lucy commit list so i'm not familar with the specifics
> of this example, but...
>
> personally i think any "bug" should be filed in jira, regardless of how
> trivial it is to fix, because that way there is a clear record of it that
> is easy to see if someone else gets burned by the same bug and goes
> seraching in the "official" place to seach for bugs to see if it's already
> been reported/fixed.
Well, we have version control, too. That ought to be sufficient for a simple fix such as this.
> Filing a Jira for all bugs seems particularly important for Lucy since the
> CHANGES.txt in the releases is built from the Jira changelog feature -- so
> if a bug fix isn't in Jira, it doesn't even get listed in the CHANGES.txt,
> so users never know that you fixed it (or to be wary of that bug in older
> versions if they choose not to upgrade, or to sanity check that the fix
> doesn't have side affects that burn them in some particular use case,
> etc....)
Yeah, if it is important enough to mention in Changes, it ought to be in Jira for as long as Changes is generated from Jira.
My humble $0.02 is: Accept reports and patches from *anywhere*, always be friendly to contributors, minimize the hoops they have to jump through. If it’s important to the project that everything be added to Jira, then it should be *our* responsibility to do that (and reference the Jira ticket in response to the OP in their ticket system).
Best,
David
Re: [lucy-dev] RT vs JIRA
Posted by Chris Hostetter <ho...@fucit.org>.
: E.g., yesterday someone opened a bug report on CPAN's RT system. There was no
: actual patch, but a suggested fix in the narrative. I applied a fix. I commented
: on the RT ticket to that effect.
:
: Should I also have opened a JIRA ticket? I'm lazy. I'd prefer not to. I
: referenced the RT ticket in my svn commit message, because as I saw it, that
: constituted an adequate audit trail considering there was little question of IP
: conflict. Was that adequate? I dunno. Hence, this thread.
I don't follow the lucy commit list so i'm not familar with the specifics
of this example, but...
personally i think any "bug" should be filed in jira, regardless of how
trivial it is to fix, because that way there is a clear record of it that
is easy to see if someone else gets burned by the same bug and goes
seraching in the "official" place to seach for bugs to see if it's already
been reported/fixed.
Filing a Jira for all bugs seems particularly important for Lucy since the
CHANGES.txt in the releases is built from the Jira changelog feature -- so
if a bug fix isn't in Jira, it doesn't even get listed in the CHANGES.txt,
so users never know that you fixed it (or to be wary of that bug in older
versions if they choose not to upgrade, or to sanity check that the fix
doesn't have side affects that burn them in some particular use case,
etc....)
But beyond that, even for projects that manage CHANGES.txt manually (or
build from svn commit logs instead) a Jira issue becomes hte focal point
for discussing that bug, discussing the fix (should there be subsequnet
discussion about alternative fixes, larger ramifications, regression in
future versions) and a place for people who have not yet (or can not)
upgrade to the fixed version to ask questions about ramifications and
workarrounds, etc...
if you only refrence the third-party tracker URL where you heard about the
bug in the commit message for the fix, then you have implicitly suggested
that that third-party tracker is an appropriate place people should go for
more information about that bug, which diminishes the cohesion arround the
official Jira system and contributes to fragmentaation in discussions
surrounding the project -- which is going to happen anyway, not reason to
enourage it.
That's for "bugs" ... for "new features" i would make the same arguments.
However: if someone on some blog, or stackoverflow tread, or CPAN RT
issue, or IRC channel, or the lucy-user list, points out a simple typo,
confusing doc paragraph, minor optimization, clearer way to do something
in the build scripts, or suggests a new test case -- then maybe a Jira
isn't really required.
But that's just my opinon -- personally i file a jira for *EVERYTHING*
-Hoss
Re: [lucy-dev] RT vs JIRA
Posted by Peter Karman <pe...@peknet.com>.
Chris Hostetter wrote on 8/8/12 3:39 PM:
> : > That means we have 2 competing ticketing systems, our official Apache JIRA
> : > system being the other.
> : >
> : > When we eventually distribute through other host-language-specific systems like
> : > CPAN, the issue will get worse.
> : >
> : > What's the preferred way of dealing with this kind of situation?
>
> Apache Lucy has a single bug tracker. There may be lots of other
> downstream "places" where people file bugs, submit patches, or otherwise
> gripe about Lucy, and it would certianly be a good idea for the Lucy
> community to monitor those "places" and act as they see fit (and open jira
> issues when they see fit), but the ASF Jira server is the system of record
> for bugs/features.
I agree.
I guess what I was hoping to do was start a conversation about this community's
expectations around the details of "as they see fit" in case anyone had a
different idea of "fit" than my own.
E.g., yesterday someone opened a bug report on CPAN's RT system. There was no
actual patch, but a suggested fix in the narrative. I applied a fix. I commented
on the RT ticket to that effect.
Should I also have opened a JIRA ticket? I'm lazy. I'd prefer not to. I
referenced the RT ticket in my svn commit message, because as I saw it, that
constituted an adequate audit trail considering there was little question of IP
conflict. Was that adequate? I dunno. Hence, this thread.
Marvin's comments on this thread seem to indicate that my actions were in line
with his expectations, and that what I am still missing is a note on the RT
ticket pointing the reporter at our CONTRIBUTING doc. That makes sense, and I'll
do that.
Thanks to you both.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] RT vs JIRA
Posted by Chris Hostetter <ho...@fucit.org>.
: > That means we have 2 competing ticketing systems, our official Apache JIRA
: > system being the other.
: >
: > When we eventually distribute through other host-language-specific systems like
: > CPAN, the issue will get worse.
: >
: > What's the preferred way of dealing with this kind of situation?
Apache Lucy has a single bug tracker. There may be lots of other
downstream "places" where people file bugs, submit patches, or otherwise
gripe about Lucy, and it would certianly be a good idea for the Lucy
community to monitor those "places" and act as they see fit (and open jira
issues when they see fit), but the ASF Jira server is the system of record
for bugs/features. just as ASF SVN server is the system of record for
software changes.
To put it in perspective: what would you do if you became aware of a URL
on perlmonks, or stackoverflow, or a personal blog where someone posted
about a problem with Lucy and then someone else replied with a patch
against Lucy that fixed that bug? ... treat downstream bug trackers
exactly the same as any other downstream discussion/forum.
-Hoss
Re: [lucy-dev] RT vs JIRA
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Aug 7, 2012 at 8:57 PM, Peter Karman <pe...@peknet.com> wrote:
> Because Lucy is distributed through CPAN, we often get RT tickets opened[0].
>
> That means we have 2 competing ticketing systems, our official Apache JIRA
> system being the other.
>
> When we eventually distribute through other host-language-specific systems like
> CPAN, the issue will get worse.
>
> What's the preferred way of dealing with this kind of situation?
Thanks for dealing with the bug report and supplied patch today, Peter.
There are multiple reasons why we should encourage people to use Lucy's ASF
JIRA issue tracker.
For non-trivial patches, it is important that we capture both the contribution
itself and the intent of the contributor within Apache-controlled channels --
they can mail a patch to one of our lists, or they can attach it to an issue
in our ASF-run tracker, either is fine. This way we do not have our
provenance history compromised when an external service loses data.
Then there are the more obvious problems with maintaining multiple issue
trackers, such as the overhead of watching them all.
Hopefully Grant McLean's latest patch will change the issue tracker links on
search.cpan.org and friends with the next Lucy release. That should help.
But we are still certain get the occasional patch via an odd channel every
once in a while.
For simple bugs, with no patch or with a trivial patch, my feeling is that it
makes sense to fix the code, close the issue, and politely suggest that they
look over the CONTRIBUTING document at the root of our source tree in case
there's a next time.
For stuff that's more involved, we'll need to shunt the discussion into our
own channels, either the mailing list or the tracker.
Does that make sense?
Marvin Humphrey