I’ve had mixed feelings about JIRA. I like it when I can use it to organize work “to be done”. It’s really helped me for example on revamping the CLI effort. And of course, the related issues feature has been really wonderful over the years to find connections between things.
I was hoping at this years C/C NA that we would hear from the Lucene folks about the results of their migration away from JIRA and to using GitHub Issues. My fear on JIRA’s being “optional” is that then someone has to make a determination of if something is optional or not, and we may not all be on the same page about that (or remember!). The binary “Ref Guide changes don’t require JIRA or Changelog” is pretty clear, and yet in someways I don’t think it helps the process at all. Those Ref Guide tickets often get lost in Github because we DO assign tickets via JIRA, we don’t do it via Github Assignee as a common pattern. I kind of wish Ref Guide doc fixes and revamps all had JIRAs too. Honestly, the biggest blocker that I experience is the solr/CHANGES.txt file. That’s what I find frustrating. I’d rather require a JIRA for everything, and create our change logs out of JIRA. > On Mar 25, 2024, at 8:41 AM, Gus Heck <gus.h...@gmail.com> wrote: > > 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) _______________________ Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
