lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smiley <>
Subject Re: Notes from the committers' meeting at Activate 2019
Date Tue, 17 Sep 2019 04:38:48 GMT
+1 to all that Gus said.  On a fresh project then indeed perhaps we would
use GitHub issues but it's not nearly so compelling at this point with so
much rich history in JIRA, not to mention those issues being referenced in
commit messages.

Is the point to lower barriers for contributors that are not in our
community yet (thus don't have an ASF JIRA account)?  Well... they don't
*have* to create the JIRA issue if a committer is sufficiently interested
in the issue at hand to do it.  And as mentioned this could be automated.

~ David Smiley
Apache Lucene/Solr Search Developer

On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <> wrote:

> FWIW, One thing that needs to be figured out is how github would
> accommodate security issues (or how the process for those issues would
> change).  Does github have the ability to assign roles and visibility
> (could be I haven't really worked with organizations on GitHub, all my
> clients have been on jira ... except the one that has trello, and another
> with gitlab... neither of which have impressed me very much )?
> Additionally, I'm slightly leery of the move since I don't (yet) see the
> real benefit that pays for the splitting of the records into two systems.
> Can issues be migrated to github? I've not really been on a large project
> that used only GitHub, can someone explain what we *gain* by moving to
> GitHub issues. At least two things are lost: continuity and familiarity. My
> impression is that there are a lot fewer features, but maybe I've just not
> been exposed to them.
> Part of me worries that this is the usual cycle of "this is simpler" (mass
> migration ensues) "but it doesn't x, y and z" (x, y and z are added) "wow
> this is complex, but THAT is simpler...." (mass migration ensues...) "hmm
> p, q an z are missing" (p q and z are added  and cycle repeats). So I'm
> skeptical of any "gain" hanging it's hat solely on "simplicity". Jira used
> to be the simpler, snazzier, sexier alternative to bugzilla...
> Sell me, I'm all ears, but not seeing it yet :)
> -Gus
> On Mon, Sep 16, 2019 at 3:57 PM Jan Høydahl <> wrote:
>> Is there any reason at all that we need to hold on to JIRA? ASF allows us
>> to move all issue handling over to GH, I'd like us to consider such a move.
>> Until then, I made a script that "diffs" GH and JIRA and outputs a
>> report, see
>> Running the tool shows that we're not very successful in keeping the two
>> in sync, we also forget to close PRs after JIRAs are resolved:
>> $ ./
>> Lucene/Solr Github PR report
>> ============================
>> Number of open Pull Requests: 208
>> PRs lacking JIRA reference in title
>>   #882: Add versions.lock entry for
>> "org.apache.yetus:audience-annotations"
>>   #880: Tweak header format.
>>   [… many more ]
>> Open PRs with a resolved JIRA
>>   #723: SOLR-13545 status=Closed, resolution=Fixed,
>> resolutiondate=2019-06-22T13:04:47.000+0000 (SOLR-13545: AutoClose stream
>> in ContentStreamUpdateRequest)
>>   #643: SOLR-13391 status=Resolved, resolution=Resolved,
>> resolutiondate=2019-04-12T14:09:27.000+0000 (SOLR-13391: Add variance and
>> standard deviation stream evaluators)
>>   [… many more]
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS -
>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <>:
>> On 16 Sep 2019, at 19:38, Yonik Seeley <> wrote:
>> >  - PR is opened - should automatically create a jira if it doesn’t
>> exist yet
>> What were the reasons behind this? Shouldn't a JIRA just be optional if
>> we started with a PR?
>> That’s why we need to discuss this :)
>> I remember that at some point ASF treated JIRA as the system of record
>> for the legal validation of contributions.
>> I also remember that at some point we used to say that if a discussion
>> didn’t happen in JIRA then it didn’t exist, and that any decisions
>> regarding code should be recorded in JIRA because we can’t expect people to
>> monitor and contribute / object to decisions happening elsewhere.
>> —
>> Andrzej Białecki
> --
> (work)
> (play)

View raw message