I like the "catch-all jira per released Solr version" idea, as something to try out for a release or two and then see if/how it works for us or not as the case may be.
Christine From: dev@solr.apache.org At: 03/24/24 10:54:09 UTCTo: dev@solr.apache.org Subject: Re: DISCUSS: Optionality of JIRA issues I do like having a place where a discussion can be had on a code change. Years later it helps. Also, some Jiras get comments or questions long after the code has been merged. If people find that it really slows them down to create a jira, we can create a catch-all jira per released Solr version, referenced by all PR’s that would like no jira. Whoever references that jira will have to think twice and might decide it makes more sense to create a specific jira instead. Ilan On Fri 22 Mar 2024 at 21:57, David Smiley <dsmi...@apache.org> wrote: > There was a recent conversation in priv...@solr.apache.org that should > not have been conducted there so I am moving it to the dev list. I > intend to hold a VOTE to formalize the decision soon. It would be a > procedural vote and as-such needs a majority of voters approving for > it to pass. > > -- PROPOSAL BEGIN -- > JIRA issues are optional for code changes, except non-public matters > like fixing a security vulnerability. We may have a documented > *preference* (e.g. please create them for "big" things but not "small" > things), but ultimately it's optional. So if a GitHub PR appears to > be ready but lacks an associated JIRA -- it may be merged anyway, > regardless of documented JIRA usage preferences. > -- END -- > > This isn't the same decision as GitHub Issues vs JIRA -- > https://issues.apache.org/jira/browse/SOLR-16455 because this isn't > about GitHub Issues at all. Nonetheless I think fans of SOLR-16455 > would eagerly vote +1 to the proposal here. > > This doesn't retire Solr's use of JIRA nor make it deprecated. JIRA > is required for private/security issues that can't be disclosed. > > Not requiring JIRA does not substantively change our use of > CHANGES.txt. Use "PR#2320" syntax, for example (that's an excerpt I > copy-pasted). PRs don't necessarily need a CHANGES.txt either (minor > stuff might omit). No change in policy/guidance. > > Commit messages thus won't have a SOLR-XXXX prefix. There is no > guidance on what the prefix should be. Please don't use "NO-JIRA". > GitHub adds a suffix like (#2320), which is fine; easily click-able in > an IDE & GitHub UI. Separately from this discussion thread, I hope we > might discuss a useful prefix standard. > > I acknowledge that optionality in use of JIRA will styme people's > attempts to use JIRA as a comprehensive resource of Solr work > tracking. For example if you have a JIRA filter / alert on keywords > of interest; it will become less effective; try switching to emails on > the iss...@solr.apache.org list instead. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > >
