You could create the issue if you are so inclined. The "author" metadata of the issue might not be quite right but that's quite minor... and could be ameliorated with mentioning the original author in the description.
Multiple sources of truth is troubling to me and of course complicates tracking project activity. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sun, Sep 29, 2019 at 10:08 PM Varun Thacker <[email protected]> wrote: > I have a question for a PR like this - > https://github.com/apache/lucene-solr/pull/908/ > > This user is a first time contributor and now we have to ask the user to > create a tracking Jira for a PR before we can commit this - Is there a > process we can take that can make this smoother for the user? > > PR is opened - should automatically create a jira if it doesn’t exist yet >> > > This would have definitely helped , but could we just commit this with the > PR number in the CHANGES file ? I'm not sold on this idea completely myself > because you now have two sources of truths , but that will still happen if > we create a Jira ( the inline code reviews etc would be in the PR ) > > > On Thu, Sep 19, 2019 at 12:57 PM Noble Paul <[email protected]> wrote: > >> My 2 sents >> I like the workflow of PR and code review in github. >> But, I still prefer JIRA and I don't want it to replace it with github >> issues >> >> On Tue, Sep 17, 2019 at 5:57 AM 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 >> > >> > >> >> >> -- >> ----------------------------------------------------- >> Noble Paul >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
