Ah.. The mythical committer just sitting around waiting to be “interested in the issue” that you have created! Having said that, I think thats a separate challenge!
> On Sep 17, 2019, at 12:38 AM, David Smiley <david.w.smi...@gmail.com> wrote: > > +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 > http://www.linkedin.com/in/davidwsmiley > <http://www.linkedin.com/in/davidwsmiley> > > On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <gus.h...@gmail.com > <mailto:gus.h...@gmail.com>> 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 <jan....@cominvent.com > <mailto:jan....@cominvent.com>> 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 > https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy > > <https://github.com/apache/lucene-solr/tree/master/dev-tools/scripts#githubprspy> > > 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: > > $ ./githubPRs.py > 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 - www.cominvent.com <http://www.cominvent.com/> > >> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <a...@getopt.org >> <mailto:a...@getopt.org>>: >> >> >>> On 16 Sep 2019, at 19:38, Yonik Seeley <ysee...@gmail.com >>> <mailto:ysee...@gmail.com>> 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 >> > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play) _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
