Thanks for moving the discussion here, Vladimir. First of all, I honestly appreciate the fact that you launched this discussion, I think you raised some valid points; what you propose sounds reasonable, and it seems a valid approach too. My main argument is that I have no big issues with the current approach (which, of course, is not perfect).
I guess my bottom-line is that I believe that issue tracking and version control (+ code review) are two different things, which serve two different purposes, and it is arguably a good thing to keep them separated: using Jira for the former and Github PRs for the latter is adequate IMO. > You did use GitHub for tracking already. As I see it, I have used Jira for issue tracking, and GitHub PRs for code review + merge. If you ask me, perhaps I am old-fashioned, but I think the development workflow should focus on the Jira ticket, and not on the GitHub PR. > Here's a good example: https://github.com/apache/calcite/pull/2329 I agree it is a good example. The associated Jira has several comments with a high-level discussion, the PR contains code-review comments for technical details. I am happy with this decoupling, although sometimes this is not always the case in all tickets; perhaps we should clarify our current workflow and try to enforce some rules, instead of changing it into something completely new. It is also a good example because the Jira reporter and the PR creator were not the same person, plus there was a span of almost two years between the ticket creation and the PR submission. I know this is usually uncommon, but it shows that there are two different roles / actions: one thing is describing / analyzing an issue; and a second, different thing is carrying out its implementation (with its corresponding code review). > GitHub allows links, and links have no properties like "caused by", "duplicated by". However, basic links are just enough for Calcite. I think it would be sad to lose this feature, but I admit it is a minor detail. > If you have a "customized dashboard" that is useful for many contributors, please show it. I was thinking for example at the dashboard mentioned by Stamatis, which is very useful (not only for the release manager, but for all contributors) when a release date is coming. Best regards, Ruben On Mon, Dec 6, 2021 at 12:44 PM Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > Moving the reply to DISCUSS thread. > > Ruben>My vote might be biased because I have used Jira for many years (and > I have > Ruben>never used Github for issue tracking). > > It is really sad to hear. > You authored 87 PRs for Calcite! > You did use GitHub for tracking already. > > https://github.com/apache/calcite/pulls?q=is%3Apr+author%3Arubenada+is%3Aclosed > > Here's a good example: https://github.com/apache/calcite/pull/2329 > PR description says the intention of the feature. > There are overall and line-targeted comments. > Creating GitHub Issue is not that different from creating a PR. > > Ruben>I have the impression that some of the problems described discussion > are > Ruben>not per se Jira-related, but they appear because we misuse the > current > Ruben>tools (and it would remain more or less the same if we switched from > Jira > Ruben>to GitHub Issues). > > Ruben, I claim that we split information for no reason. > What is the real meaning behind having 50% of the review comments in JIRA, > and 50% of the comments in PR? > What is the real meaning behind putting "common description in JIRA, and > putting NO description in the PR"? > Does it help to have different markup languages for JIRA and GitHub? > > My main motivation is not "replace JIRA with Issues". That replacement > alone has few benefits. > The key improvement to the current process is creating PRs **with > description**, and keeping the relevant discussion in the PR itself. > I really see no point in PR comments like "let's continue in JIRA". > If a comment targets a specific PR, then why don't we just use PR's > comment fields for that? > > Ruben>high level discussion (e.g. feature design) should > Ruben>happen in Jira > > The vast majority of the changes are small. Adding Jira barrier for every > change is a productivity killer (for both contributors and for the > reviewers). > I don't mean just "switch between JIRA and PR". > I mean that comments are duplicated at different sites. > The description of the issue and the code changes are separated. > The notifications are duplicated (gitbox duplicates GitHub notifications). > The markup format is different. > The search is not coherent (there's no way to find issues and PRs at the > same time). > GitHub blame does not show the full picture (it shows PRs, however, > opening the JIRA is a separate step). > PR (and GitHub Issue) can be associated to a version, so it would be much > easier to relate the PR with its release version. > I think the list can go and go. > > Ruben>IMO every change must have a dedicated Jira ticket > > What are the benefits of "a dedicated Jira ticket"? > How "a dedicated Jira ticket" is different from "a dedicated PR"? > > Ruben>high level discussion (e.g. feature design) should > Ruben>happen in Jira, low-level details (e.g. line by line code review) in > the > Ruben>PR; > > Both can be in PR, so what are the benefits from splitting "low-level" vs > "high-level"? > There is a lot of cases when people discuss low-level details in JIRA. > > It would be so much better, if we aligned the review approach. > Jira and GitHub are just tools, and if we don't agree to review high-level > stuff first, then no tool helps. > That implies, GitHub is just fine for high-level reviews. > > Ruben>like customized dashboards, or linked issues ("issue A is blocked by > / > Ruben>caused by / duplicated by / ... issue B"). > > GitHub allows links, and links have no properties like "caused by", > "duplicated by". > However, basic links are just enough for Calcite. > > If you have a "customized dashboard" that is useful for many contributors, > please show it. > The ASF is a set of volunteers, so it is not right to enforce usage of > JIRA when only a single person needs "a customized dashboard". > > Vladimir > >
