I have my opinion, you have yours, one thing I seem to have miscommunicated...
You said: > 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. > But I am in no way advocating cut and paste the same description in both places. That's laziness that no convention will fix. The Jira should discuss how it was found, why it's a problem, The PR should briefly reference the issue and describe the fix. WITHOUT a jira, both descriptions should be provided in the PR. It should not save anyone any "description" time. The only added work is filling out fields for the Jira... which I still find hard to believe takes more than a minute. Another missing tagging (though I never really use it so it might not matter) is component.. In any case I can't see how choosing issue type, summary, priority, component and maybe fix version takes over a minute, even if you have to open a browser and log in too... And I'm more or less ok with someone cut and pasting the summary line... -Gus On Mon, Mar 25, 2024 at 5:27 AM David Smiley <dsmi...@apache.org> wrote: > 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) > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
