Well put Jason. I think we didn't discuss it in any further detail than what you said right here -- basically cater to GitHub PRs and either discourage or undocument "patch file" based contributions. That's it in a sentence. We all nodded our head to that, albeit some of us like me confess to enjoying the ease of patch based contributions.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Tue, Sep 17, 2019 at 9:46 AM Jason Gerlowski <[email protected]> wrote: > 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 > <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]>: > >>> > >>> > >>> On 16 Sep 2019, at 19:38, Yonik Seeley <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > >
