Re: [DISCUSS] JIRA vs GitHub Issues

[Vladimir Sitnikov <si...@gmail.com>]

>I know people/companies who have built tools/plugins
>around JIRA for getting useful information such as which internal forks
>have this particular fix, etc

That is true. However, I do not know what should we do about it.
Of course, any change brings hidden costs, so if the benefits are unclear,
there's not much point in making changes.

On the other hand, the more I discover, the more I am sure GitHub Issues
would be great for Calcite.
I started the discussion like "it looks we are fine, but we can try
GitHub", and now I am quite
enthusiastic that moving to GitHub would bring multiple improvements in
various aspects.

>I turn to JIRA
>or GitHub and it turns out that I am able to find the information easier
>with JIRA.

GitHub issues are searchable, including comments.
We currently "enforce" JIRA tickets, so PRs lack descriptions and
explanations, so it is expected you can't find them.

Try using JIRA to figure out when we bumped Guava to 31. There's no JIRA
for that.

On the other hand, GitHub search returns PRs, code files, and commits that
match the search.
https://github.com/apache/calcite/search?q=guava+31

Then, if you know Git SHA (e.g. from "git blame"), you can find PRs related
to that SHA.
For example
https://github.com/apache/calcite/search?q=890eb61efcccc486e2192110cefe4cac5aa6f150&type=issues
Frankly speaking, I never thought of trying to search via commit SHA, but
it is a definitely cool trick I learned
when reading
https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests

When it comes to versions, GitHub PRs and issues would have "milestones" (~
"fix version"),
and when you browse commits, GitHub shows the list of tags that include
this commit.
For instance, if you open
https://github.com/apache/calcite/commit/2326cf8dc97f473d0efa2b0e4883fef87a40746b
,
you know Guava was updated to 31 since Calcite 1.28.0

>One unpleasant situation which comes up from time to time is when
>discussions develop in both places. However, migrating to GitHub issues
>will not completely solve this since we will still need to navigate back
>and forth between issue and PR

If we allow PR-first (no issue, no JIRA, just PR with the proper
description) contributions, then:
1) It will be in a single place, no need to switch
2) Navigation between issues and comments would still be easier in GitHub
than commenting like "please continue in JIRA"

GitHub allows responding to issues/PRs via mail, and I find it a nice
feature.
I don't use it often, however, I use it from time to time, and I see others
using it.

>Moreover, many Apache projects are using
>JIRA already which makes it easy to perform cross project search

GitHub has an out-of-the-box way to scope search for organizations.

Here's a search for Calcite in the Apache organization:
https://github.com/search?q=org%3Aapache+calcite

At any point in time, you can remove org:apache, and you get GitHub-wide
search.
GitHub hosts more projects than ASF JIRA, so being able to search and link
across them (all, not just ASF projects) would be useful.

>I find JIRA search superior to GitHub both when it comes to approximate
>text search and exact filters

I might be wrong here, however, I think we do not really use JIRA metadata.
In most cases, we use only the ticket title, description, and the fix
version.

There's "affects version" in JIRA, and I do not know if GitHub has a
one-to-one replacement for that.
However, I would be fine if the affected version was in the issue/PR
description.

"component" (~core, linq4j, cassandra, ...) could become a label in GitHub.
AFAIK the limitation is that labels can only be changed by committers or
collaborators.
We can mitigate that by:
a) Adding collaborators (via asf.yaml)
b) Adding committers
c) Adding GitHub Actions that label Issues based on descriptions or even
PRs based on the set of touched files.

GitHub's search features are more than enough for us. We have no fancy
metadata for complicated searches :)

Vladimir

Re: [DISCUSS] JIRA vs GitHub Issues

[Julian Hyde <jh...@gmail.com>]

Stamatis,

You use the word ‘patch’ to describe all code changes, but code changes are different in nature, and to be successful need to be accompanied by more than code.

A bug fix needs a good description of the bug. Not ‘I changed these lines and the problem I was having went away and so I think you should accept this patch’. The description needs to be good enough that anyone reading the release notes would understand what the problem was. And there needs to be a test case.

A feature needs a description of the feature, why it is beneficial, an illustration how to use the feature, a description of the limits of the feature (edge cases) and some test cases.

For both bugs and features, all that description needs to come first. For those, I just don’t agree that people can use GitHub first. GitHub tends to focus on the code, and the important stuff gets forgotten.

There are other kinds of changes - improving documentation, changing the web site, adding test cases, fixing the occasional ’no brainer’ bug - but most are bug fixes or features, and I believe that “Jira first” has served us well.

As a reviewer, I often won’t even look at a PR until the Jira description is in good shape. I would encourage other reviewers to do the same.

Calcite is about ten years old, and is set to go on for another ten or twenty. It is in good shape because we have required analysis and documentation of code changes, not just accepted every patch that was thrown at us. Jira is a record of the design decisions that we have made. We can cross reference new bugs with the design decisions that caused them.

In short, Jira is how we do software engineering. We would lose a lot if it ceases to be a central part of our process.

I don’t understand what ‘milestones in GitHub’ would entail. I have no objections to that per se.

Julian



> On Dec 18, 2021, at 10:44 AM, Stamatis Zampetakis <za...@gmail.com> wrote:
> 
> There are many good ideas in this thread and some of them we could probably
> directly use without changing the current workflows a lot.
> 
> Inspired from the discussion so far my main suggestion would be to enable
> and start using the GitHub milestones keeping a one-to-one mapping with
> Calcite versions.
> 
> As other people have mentioned already, currently we allow JIRAless pull
> requests and it does make sense in many cases (I will not repeat here what
> others have said already). The drawback with the current process is that we
> cannot associate a "fix version" if the PR does not have a JIRA and it
> might be difficult to track down what changes went on which version. If we
> have milestones then we can solve this inconvenience with some other added
> benefits.
> 
> Note that I am not proposing to replace JIRA. People are free to create
> JIRAs and/or pull requests. The difference is that every pull request
> before it gets merged should have an assigned milestone. This small
> addition in our workflow will make all patches (with or without JIRA)
> easier to track.
> 
> The main goal of this change is to allow people to use JIRA, GitHub, or
> both, as they prefer. This essentially means that we relax the requirement
> to have a JIRA case for every patch. At a second time, we can introduce PR
> templates to ensure all the necessary information is there when somebody
> raises a PR.
> 
> If people think it's worth enabling GitHub milestones I can prepare a PR
> with changes in the documentation to see concretely how this will
> affect our current procedures. On the other hand, if nobody sees any
> advantage in using milestones then I'm fine leaving things as they are
> right now.
> 
> Best,
> Stamatis
> 
> On Mon, Dec 6, 2021 at 7:33 PM Ruben Q L <ru...@gmail.com> wrote:
> 
>> 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.vladimir@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
>>> 
>>> 
>> 

Re: [DISCUSS] JIRA vs GitHub Issues

[Stamatis Zampetakis <za...@gmail.com>]

There are many good ideas in this thread and some of them we could probably
directly use without changing the current workflows a lot.

Inspired from the discussion so far my main suggestion would be to enable
and start using the GitHub milestones keeping a one-to-one mapping with
Calcite versions.

As other people have mentioned already, currently we allow JIRAless pull
requests and it does make sense in many cases (I will not repeat here what
others have said already). The drawback with the current process is that we
cannot associate a "fix version" if the PR does not have a JIRA and it
might be difficult to track down what changes went on which version. If we
have milestones then we can solve this inconvenience with some other added
benefits.

Note that I am not proposing to replace JIRA. People are free to create
JIRAs and/or pull requests. The difference is that every pull request
before it gets merged should have an assigned milestone. This small
addition in our workflow will make all patches (with or without JIRA)
easier to track.

The main goal of this change is to allow people to use JIRA, GitHub, or
both, as they prefer. This essentially means that we relax the requirement
to have a JIRA case for every patch. At a second time, we can introduce PR
templates to ensure all the necessary information is there when somebody
raises a PR.

If people think it's worth enabling GitHub milestones I can prepare a PR
with changes in the documentation to see concretely how this will
affect our current procedures. On the other hand, if nobody sees any
advantage in using milestones then I'm fine leaving things as they are
right now.

Best,
Stamatis

On Mon, Dec 6, 2021 at 7:33 PM Ruben Q L <ru...@gmail.com> wrote:

> 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.vladimir@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
> >
> >
>

Re: [DISCUSS] JIRA vs GitHub Issues

[Ruben Q L <ru...@gmail.com>]

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.vladimir@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
>
>

Re: [DISCUSS] JIRA vs GitHub Issues

[Vladimir Sitnikov <si...@gmail.com>]

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

Re: [DISCUSS] JIRA vs GitHub Issues

[Vladimir Sitnikov <si...@gmail.com>]

Julian, it looks like you have not been using GitHub for the past 5 years,
and you miss a lot of improvements.
GitHub allows a superset of what we do in JIRA, so I really can't
understand why do you suggest enforcing JIRA.

None of what you say sounds like a "good point to keep using JIRA", and
none of what you say sounds like "a pitfall of using GitHub".

>As to the backlog of PRs

I could have just merged 2628, however:
1) We spend time on discussions in JIRA
2) After PR merge, someone would have to "resolve the JIRA"

That consumes the reviewer's time.

Julian>GitHub also makes it easy to write code, submit it as a PR, and that
PR becomes the issue.

That is a great GitHub feature. I do not see how do you treat it as
something bad.
It really makes no sense to create JIRA for adding tests, updating
documentation.

Julian>Lastly, another quibble about GitHub: that it allows people to
squash, rebase and amend commits. The line-by-line comments quickly go out
of date.

squash, rebase, and amendments make JIRA comments go out of date at the
same rate.
However, in GitHub there's an explicit "resolve discussion", "reopen
discussion" features,
so there's a clear way to tell when the discussion is closed.

JIRA has no conversation threads. GitHub has threads (code-related).

Julian>GitHub makes it easy to review line by line, but you can then miss
the important stuff.

Do you mean we should stop code reviews?
If we review code, then using both "JIRA and GitHub" makes it way easier to
miss stuff.

However, I agree we should review high-level ideas first, and put
line-by-line comments
only when high-level direction is OK.

GitHub UI does have regular comments that are not attached to the diff
lines,
so you can comment there just like you add JIRA comments.

Julian>And I like making holistic reviews

What stops you from adding an overall review in GitHub?

Julian>Then discussion can happen before coding starts.

https://github.com/apache/calcite/pull/2628 is a perfect example here.
The PR is trivial, and it adds a couple of tests.

The PR looks good to me, except for method names.
However, I truly do not know how to make test names better in Java, so I
just ignore it.
In Kotlin, one could use method name with spaces, so it would be better,
however, I just ignored it.

Then Julian comments "The test case names are not very useful".
This should really belong to line-by-line diff rather than JIRA ticket.
Now everyone should navigate between JIRA and PR to figure out the meaning.

I see Julian suggests adding all the tests into a single method,
however, I think we should just merge the thing and get over it.

I am sure the discussion in CALCITE-4917 is not worth the time we spend
there.
We are discussing 2 lines of code there. Exactly two lines of test code.
It would be OK to discuss method vs class when it comes to 100 lines.

Even adding tests to JdbcTest does not have those levels of discussions.

Vladimir

Re: [DISCUSS] JIRA vs GitHub Issues

[Julian Hyde <jh...@gmail.com>]

For what it’s worth, I actually prefer JIRA’s workflow model. I strongly believe that people should log a JIRA case before starting work on a bug or feature. Then discussion can happen before coding starts.

And I like making holistic reviews - reviewing the whole change, its goals, its impact, and what’s missing - rather than reviewing line by line.

GitHub makes it easy to review line by line, but you can then miss the important stuff.

GitHub also makes it easy to write code, submit it as a PR, and that PR becomes the issue.

Lastly, another quibble about GitHub: that it allows people to squash, rebase and amend commits. The line-by-line comments quickly go out of date.

As to the backlog of PRs. There are multiple problems and solutions. The main one is that reviewing PRs quite simply takes work. We need more people to spend more time reviewing PRs. We have solved the problem for RMs - people volunteer, and put in the effort, and there is a rota so that no one person is doing all the work.

Julian



> On Dec 1, 2021, at 10:14 PM, Vladimir Sitnikov <si...@gmail.com> wrote:
> 
>> A bigger problem around our process that I see is not enough reviews/triage
> for the contributions we do receive. We have 224 open prs and I'd estimate
> a median open time of 1 year+
> 
> I am sure JIRA is slowing us down here.
> 
> If we accept we do not need JIRA, PRs could become the way to go for the
> reviews.
> 
> Jacques, I see you've just created
> https://github.com/apache/calcite/pull/2625 (generic visitor), and you
> followed the exact pattern I suggest: you filed a PR without JIRA, and you
> put all the clarifications into the description.
> Congratulations. It confirms JIRA adds no value to our workflow.
> 
> Your https://github.com/apache/calcite/pull/2624 (introduce
> handlerbased...) is less fun. Why did you create JIRA? ;)
> It could have been a JIRA-less PR as well.
> 
> As you put description to the PR itself, it becomes easier to review.
> 
> That is what I mean.
> 
> ----
> 
> We rarely reject contribution or ideas, and, I believe, we could reduce
> time-to-merge by lowering the barrier and allowing PR-first contributions.
> 
> Let me put it as follows: in many cases committers and experienced
> contributors know they are doing good.
> For example, I see you are moving towards AOT. That is fine, and I do not
> really need all those JIRA's.
> It would be so much easier to review and follow if you created a single
> Issue that references all your AOT PRs.
> 
> It is not really fun to create tickets for moving to JUnit5. We could just
> do it instead of spending time on JIRA comments.
> 
> ----
> 
>> I'd estimate a median open time of 1 year+
> 
> I suggested moving "core test framework classes" from core/src/test/ into
> its own test module long ago. My mistake was I sent an email instead of
> just sending a PR.
> 
> The response to my mail was strongly negative, however, recently I did the
> split, and it works great.
> 
>> This seems to solve a problem that doesn't exist
> 
> It does exist. My current mail highlights it right away: you could submit
> JIRA-less PRs, everybody would have a single page for reviews, and so on.
> It is really sad to hear "does not exist".
> 
> JIRA causes excessive mails: "jira created", "pr created".
> 
> In case we skip JIRA completely, it would be less notifications for
> everybody.
> 
> Vladimir

Re: [DISCUSS] JIRA vs GitHub Issues

[Vladimir Sitnikov <si...@gmail.com>]

>A bigger problem around our process that I see is not enough reviews/triage
for the contributions we do receive. We have 224 open prs and I'd estimate
a median open time of 1 year+

I am sure JIRA is slowing us down here.

If we accept we do not need JIRA, PRs could become the way to go for the
reviews.

Jacques, I see you've just created
https://github.com/apache/calcite/pull/2625 (generic visitor), and you
followed the exact pattern I suggest: you filed a PR without JIRA, and you
put all the clarifications into the description.
Congratulations. It confirms JIRA adds no value to our workflow.

Your https://github.com/apache/calcite/pull/2624 (introduce
handlerbased...) is less fun. Why did you create JIRA? ;)
It could have been a JIRA-less PR as well.

As you put description to the PR itself, it becomes easier to review.

That is what I mean.

----

We rarely reject contribution or ideas, and, I believe, we could reduce
time-to-merge by lowering the barrier and allowing PR-first contributions.

Let me put it as follows: in many cases committers and experienced
contributors know they are doing good.
For example, I see you are moving towards AOT. That is fine, and I do not
really need all those JIRA's.
It would be so much easier to review and follow if you created a single
Issue that references all your AOT PRs.

It is not really fun to create tickets for moving to JUnit5. We could just
do it instead of spending time on JIRA comments.

----

>I'd estimate a median open time of 1 year+

I suggested moving "core test framework classes" from core/src/test/ into
its own test module long ago. My mistake was I sent an email instead of
just sending a PR.

The response to my mail was strongly negative, however, recently I did the
split, and it works great.

>This seems to solve a problem that doesn't exist

It does exist. My current mail highlights it right away: you could submit
JIRA-less PRs, everybody would have a single page for reviews, and so on.
It is really sad to hear "does not exist".

JIRA causes excessive mails: "jira created", "pr created".

In case we skip JIRA completely, it would be less notifications for
everybody.

Vladimir

Re: [DISCUSS] JIRA vs GitHub Issues

[Jacques Nadeau <ja...@apache.org>]

I'm generally -0.47 on this.

This seems to solve a problem that doesn't exist (or at least isn't
pressing). Calcite contribution speed is very helpful. Don't get me wrong,
I hate jira as much as anyone. Nonetheless, process change takes time in
both the direct costs (migration/workflow disruption/etc) and the indirect
costs (learning/refining a new system).

A bigger problem around our process that I see is not enough reviews/triage
for the contributions we do receive. We have 224 open prs and I'd estimate
a median open time of 1 year+. Many of those may now be abandoned but it'd
be great to actually mark them as such (if we think that). I'm much more
excited about creative ways to solve that problem and if someone feels like
putting time against process improvement, I think that would be a good
place for it.

To be clear, I prefer GitHub issues for new things and do agree that it
reduces the bar towards contribution.



On Tue, Nov 30, 2021 at 11:39 PM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> >I know people/companies who have built tools/plugins
> >around JIRA for getting useful information such as which internal forks
> >have this particular fix, etc
>
> That is true. However, I do not know what should we do about it.
> Of course, any change brings hidden costs, so if the benefits are unclear,
> there's not much point in making changes.
>
> On the other hand, the more I discover, the more I am sure GitHub Issues
> would be great for Calcite.
> I started the discussion like "it looks we are fine, but we can try
> GitHub", and now I am quite
> enthusiastic that moving to GitHub would bring multiple improvements in
> various aspects.
>
> >I turn to JIRA
> >or GitHub and it turns out that I am able to find the information easier
> >with JIRA.
>
> GitHub issues are searchable, including comments.
> We currently "enforce" JIRA tickets, so PRs lack descriptions and
> explanations, so it is expected you can't find them.
>
> Try using JIRA to figure out when we bumped Guava to 31. There's no JIRA
> for that.
>
> On the other hand, GitHub search returns PRs, code files, and commits that
> match the search.
> https://github.com/apache/calcite/search?q=guava+31
>
> Then, if you know Git SHA (e.g. from "git blame"), you can find PRs related
> to that SHA.
> For example
>
> https://github.com/apache/calcite/search?q=890eb61efcccc486e2192110cefe4cac5aa6f150&type=issues
> Frankly speaking, I never thought of trying to search via commit SHA, but
> it is a definitely cool trick I learned
> when reading
>
> https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests
>
> When it comes to versions, GitHub PRs and issues would have "milestones" (~
> "fix version"),
> and when you browse commits, GitHub shows the list of tags that include
> this commit.
> For instance, if you open
>
> https://github.com/apache/calcite/commit/2326cf8dc97f473d0efa2b0e4883fef87a40746b
> ,
> you know Guava was updated to 31 since Calcite 1.28.0
>
> >One unpleasant situation which comes up from time to time is when
> >discussions develop in both places. However, migrating to GitHub issues
> >will not completely solve this since we will still need to navigate back
> >and forth between issue and PR
>
> If we allow PR-first (no issue, no JIRA, just PR with the proper
> description) contributions, then:
> 1) It will be in a single place, no need to switch
> 2) Navigation between issues and comments would still be easier in GitHub
> than commenting like "please continue in JIRA"
>
> GitHub allows responding to issues/PRs via mail, and I find it a nice
> feature.
> I don't use it often, however, I use it from time to time, and I see others
> using it.
>
> >Moreover, many Apache projects are using
> >JIRA already which makes it easy to perform cross project search
>
> GitHub has an out-of-the-box way to scope search for organizations.
>
> Here's a search for Calcite in the Apache organization:
> https://github.com/search?q=org%3Aapache+calcite
>
> At any point in time, you can remove org:apache, and you get GitHub-wide
> search.
> GitHub hosts more projects than ASF JIRA, so being able to search and link
> across them (all, not just ASF projects) would be useful.
>
> >I find JIRA search superior to GitHub both when it comes to approximate
> >text search and exact filters
>
> I might be wrong here, however, I think we do not really use JIRA metadata.
> In most cases, we use only the ticket title, description, and the fix
> version.
>
> There's "affects version" in JIRA, and I do not know if GitHub has a
> one-to-one replacement for that.
> However, I would be fine if the affected version was in the issue/PR
> description.
>
> "component" (~core, linq4j, cassandra, ...) could become a label in GitHub.
> AFAIK the limitation is that labels can only be changed by committers or
> collaborators.
> We can mitigate that by:
> a) Adding collaborators (via asf.yaml)
> b) Adding committers
> c) Adding GitHub Actions that label Issues based on descriptions or even
> PRs based on the set of touched files.
>
> GitHub's search features are more than enough for us. We have no fancy
> metadata for complicated searches :)
>
> Vladimir
>

Re: [DISCUSS] JIRA vs GitHub Issues

[Vladimir Sitnikov <si...@gmail.com>]

Stamatis>Quite interesting information so far

One more data point: LLVM is migrating issues from their Bugzilla to GitHub
Issues right now (52K issues!)
See https://llvm.discourse.group/t/bugzilla-migration/4848

Vladimir