The only missing “status” in a PR is fix-version. Maybe a fix-version solution is needed before a PR should exist without a JIRA. Again, at least for anything of “substance”.
Distinguishing “substantive” or not for internal APIs and the degree to which a “small” bug such is obviously a slippery slope, so I’d rather we leave that to a guidance/preference document than a mandate. I would prefer a weaker distinction than yours, letting minor changes go through without a JIRA. A rare NPE fix for example (so rare it’s a waste of time to add it or have many people read it in CHANGES.txt IMO). Minor Java API changes, very subjective there of course. Walking down the slippery slope we go, here. See what I mean? I’m trying to make it easier for contributors and us too for that matter. No matter how simple it is to create a JIRA issue, it’s still sometimes wasted time (what’s the point again?) — that breaks up one’s flow. It’s generally not less than a minute if thought is put into it (isn’t rushed). Differences in formatting between both systems. A PR with a mandated pointless JIRA does itself contribute to bifurcation. If I find the PR and see a JIRA link, I wonder what’s there. I look and ascertain if it’s the ~same description. If it’s the same, then it was wasted time. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Mon, Mar 25, 2024 at 5:46 AM Gus Heck <gus.h...@gmail.com> wrote: > I definitely prefer to have a real description of what is intended, and a > clear place for status and reporting of fix versions and the like for any > "substantive" change. Also a central place to subscribe to hear what people > say, or learn when things are addressed/decided I also really don't want to > have to search more than one place to find changes relating to a feature, > and I'm particularly interested in being able to find both when a feature > was directly touched, and when it was discussed as part of some other > development. (i.e. if something about streaming expressions impacted how we > migrated solrj code from one technology to another... If discussions are > spread across multiple locations this gets harder and harder. As it stands > now, things might be discussed on the list or in Jira... we have tried hard > not to make Slack a 3rd location and having Github sneak in as a 4th is > equally undesirable to me, and at present the situation with discussions on > PR's is only tolerable because the PR will be auto-linked from the Jira. > Without that Jira as a hub, the existence of the discussion will be much > harder to discover. Good Jira tickets link the archived discussion on the > list when applicable. > > So what's substantive? Below is my opinion by way of examples. > > - Anything that changes back compatibility > - Anything that changes an API (in code or HTTP) including throwing new > exceptions or responding with new response codes. > - Anything that adds a feature > - Anything that removes a feature (see item 1) > - Anything that alters (or might alter) performance > (CPU/Mem/Disk/Network) intentionally > - Anything that fixes a bug in a released feature (because even > seemingly simple stuff can cause fix/breaks). > - Anything worthy of an entry in CHANGES.txt (i.e. something that users > might want to know about). > - Any change that moves/renames a file. > - Anything that has (should have) a unit test. > > What's clearly not substantive: > > - Fixing typos > - Elimination or suppression of simple static analysis warnings where > the change is localized to a few lines in a single method. > - Improvement of docs to better portray the *previously existing* > features > > Gray zone: > > - Minor but not trivial refactoring such as extracting a method and then > updating various code to utilize it to reduce duplication. Such a thing > greatly depends on how complicated the method is, and if the usages are > all > identical. This trends toward substantive if there are varying patterns > of > argument usage with null being commonly passed in, or introduction of > "result objects". etc. > > For anything substantive I really want fix version information, and I think > it's a fundamental part of good programing to communicate what it was you > intended to do so that later when someone looks at the code (especially if > it's been updated by several more people) there's a prayer that they can > know if it's drifted away from it's intent (and if that was on purpose as > evidence by subsequent JIRA's) > > I seriously don't understand what's so difficult about making a JIRA > ticket. It takes like 30 seconds plus the time to write the same > description that **I hope** you would also write in a PR. It smells of > people who drank a bunch of kool-aid from people marketing in competition > with JIRA, or people who think that they don't have to write descriptions > of their intentions if it's a PR... Sure Jira's not perfect but I've never > seen any issue tracking system that didn't have ... well... issues. All > issue tracking systems have problems. > > The only thing worse than issue tracking systems is not having/using an > issue tracking system. > > -Gus > > On Sun, Mar 24, 2024 at 9:33 AM David Smiley <dsmi...@apache.org> wrote: > > > 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 > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) >
