I missed the part of the meeting/lunch when our use of Github came up. Can anyone that was present summarize the discussion in a little more detail?
re: issues on github. There are challenges like avoiding fragmentation and keeping multiple issue sources up to date, but those are problems that probably shrink or go away with appropriate automation. IMO at least, issue reporting is largely the same whether you're on Github, JIRA, trello, etc. You fill out a form, set the appropriate tags and fields, etc. I'm fine w/ changes there, but it's hard for me to imagine how that would have much/any impact on barrier to entry. I see our code-contribution process as a much bigger driver of the barrier-to-entry. First time contributors must learn how to generate patches. They receive code-review on JIRA, so they get one chunk of text in a comment. And contributions have very weak version control (identically named SOLR-####.patch files piling up on the same issue). Github has concrete benefits here. If the goal is to make it easier for contributors to get involved, making Github first-class for code contributions might be where the real gains are. (We allow Github PR's, but could steer people towards them more clearly: rewrite HowToContribute docs to assume Github, hide the patch process for new contributors, set up workflows in Github to run precommit/tests on PRs, etc.) On Tue, Sep 17, 2019 at 8:56 AM Eric Pugh <ep...@opensourceconnections.com> wrote: > > 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 > > > On Mon, Sep 16, 2019 at 6:27 PM Gus Heck <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> 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 >>> >>> 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 >>> >>> 16. sep. 2019 kl. 20:57 skrev Andrzej Białecki <a...@getopt.org>: >>> >>> >>> On 16 Sep 2019, at 19:38, Yonik Seeley <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 (work) >> http://www.the111shift.com (play) > > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com | My Free/Busy > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > 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. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
