I think I may prefer JIRA to GitHub Issues. I'm not sure. Anyway, it's worth wondering if we can just move JIRA to GitHub. GitHub is now a first class mirror for Apache that we can commit to, but they still keep a primary copy of our code at Apache. Perhaps that is only a code concern now though.
It appears others have moved: https://accumulo.apache.org/blog/2018/03/16/moving-to-github-issues.html As far as the GitHub vs patch issue, I don't want tell everyone they can't use patches, I usually prefer them, but, if we pushed everything through GitHub we can take super advantage of their free and way nicer than what we will ever have at Apache, Actions CI stuff. I'm not saying that will drive unit tests now or something, but for things like precommit and other checks (beasting on new tests or whatever), everyone going through that would be great. Would be awesome to project ourselves well in front of prs, or end up using the 2 branches and promoting changes when they are checked more thoroughly. If we started using Git primarily that way, not using issues is probably more friction than we need ... Mark On Tue, Sep 17, 2019 at 2:46 PM David Smiley <david.w.smi...@gmail.com> wrote: > 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 <gerlowsk...@gmail.com> > 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 >> <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 >> >> -- - Mark http://about.me/markrmiller
