On Sun, Mar 24, 2024 at 6:54 AM Ilan Ginzburg <ilans...@gmail.com> wrote: > > 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.
Maybe you mean *in advance of* a code change; i.e. to discuss an idea? This is what a JIRA issue does pretty well; indeed we will continue to create them sometimes -- I will. Dev list threads get more visibility though. It's rare to link to a dev list thread from a PR; I wish that was easier -- we should encourage that when it applies. Speaking for myself, I monitor the dev list daily but not the issues list (hey I have a day job LOL). I suspect new people interested in Solr development miss subscribing to that list. If you mean *after* a code change -- note the PR isn't closed for comments. I've commented on a PR after a merge to follow up. The participants to the PR (subscribers) should get notified. I've found it's increasingly rare for people to even "Watch" the JIRA issue if there is a PR accompanying it, making me wonder if whatever I write there will be read. When GitHub PRs with code review commentary was a new contribution approach for Solr, I had suggested at the time that JIRA issues be where we discuss the high level matter -- requirements and approach. In practice, once you start looking at the PR, you instinctively want to comment there no matter what level of detail; it's just natural. Not just for little things but bigger things (i.e. should we even be doing it this way?). Sometimes I've conversed back on the JIRA issue to discuss the bigger picture. Independently of the forthcoming vote thread, more could be done to make our use of JIRA better. For example, if we could get a weekly (or more often?) digest summary of what's happening in JIRA and post this to the dev list, I think it'd be very helpful to bring visibility there. And we could re-examine the JIRA-PR synchronization options that the ASF gives us. Originally it was configured for all individual updates to be copied to JIRA which was way too much but if it could be configured to be top level comments only, I think that'd be a nice balance. Nevertheless; if someone has a PR and doesn't want to create a JIRA; I don't blame them :-) > 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. I don't get the point. If it is only to satisfy a JIRA mandate, we should really reconsider the mandate. > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
