Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA
It's just my preference. I do not think current workflow is so painful that
we have to replace it.
Would the GitHub workflow boost our review? I doubt it somehow. Actually,
I like the current
workflow. Not only because I am used to it, but also it is easier to review
all the discussions.
Best,
Chunwei
On Mon, Dec 6, 2021 at 7:47 PM Ruben Q L wrote:
> -1 I am satisfied with the current situation.
>
> My vote might be biased because I have used Jira for many years (and I have
> never used Github for issue tracking).
> I have the impression that some of the problems described discussion are
> not per se Jira-related, but they appear because we misuse the current
> tools (and it would remain more or less the same if we switched from Jira
> to GitHub Issues).
> I like the current workflow, as described in the website [1]; the
> navigation between Jira and Github can be inconvenient for some, but for me
> it is not painful.
> IMO every change must have a dedicated Jira ticket, that should be the
> norm; and having a ticket-less PR or commit should be exception, only for
> very specific cases; high level discussion (e.g. feature design) should
> happen in Jira, low-level details (e.g. line by line code review) in the
> PR; but I must admit that sometimes this does not happen.
> I think Jira has some useful features that I'm not sure we can find in
> Github (perhaps we can, as I said before, I'm not very familiar with it)
> like customized dashboards, or linked issues ("issue A is blocked by /
> caused by / duplicated by / ... issue B").
>
> [1] https://calcite.apache.org/develop/#contributing
>
>
>
> On Mon, Dec 6, 2021 at 9:12 AM Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>
> > >I think JIRA works well.
> >
> > I would appreciate it if you could clarify.
> > What I suggest would work better than JIRA in virtually all the cases. So
> > why stick with JIRA?
> >
> > Vladimir
> >
>
Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA
-1 I am satisfied with the current situation.
My vote might be biased because I have used Jira for many years (and I have
never used Github for issue tracking).
I have the impression that some of the problems described discussion are
not per se Jira-related, but they appear because we misuse the current
tools (and it would remain more or less the same if we switched from Jira
to GitHub Issues).
I like the current workflow, as described in the website [1]; the
navigation between Jira and Github can be inconvenient for some, but for me
it is not painful.
IMO every change must have a dedicated Jira ticket, that should be the
norm; and having a ticket-less PR or commit should be exception, only for
very specific cases; high level discussion (e.g. feature design) should
happen in Jira, low-level details (e.g. line by line code review) in the
PR; but I must admit that sometimes this does not happen.
I think Jira has some useful features that I'm not sure we can find in
Github (perhaps we can, as I said before, I'm not very familiar with it)
like customized dashboards, or linked issues ("issue A is blocked by /
caused by / duplicated by / ... issue B").
[1] https://calcite.apache.org/develop/#contributing
On Mon, Dec 6, 2021 at 9:12 AM Vladimir Sitnikov <
sitnikov.vladi...@gmail.com> wrote:
> >I think JIRA works well.
>
> I would appreciate it if you could clarify.
> What I suggest would work better than JIRA in virtually all the cases. So
> why stick with JIRA?
>
> Vladimir
>
Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA
>I think JIRA works well. I would appreciate it if you could clarify. What I suggest would work better than JIRA in virtually all the cases. So why stick with JIRA? Vladimir
Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA
-1 I think JIRA works well. Best, Chunwei On Sat, Dec 4, 2021 at 1:39 PM Julian Hyde wrote: > -1 > > I’m happy with the status quo. > > > On Dec 3, 2021, at 9:34 AM, Vladimir Sitnikov < > sitnikov.vladi...@gmail.com> wrote: > > > > Hi, > > > > Let us have a vote for PR-centric workflow for Calcite. > > > > [ ] +1, let's move to GitHub PRs/Issues for change management. > > [ ] -1, keep using JIRA because, > > > > Here's my vote: > > +1 (binding), let's move to GitHub PRs/Issues for change management. > > > > Note: dev@calcite keeps as is. I do not suggest replacing it. > > > > I suggest the adjustment of development workflow would reduce maintenance > > costs, > > make contributions easier, and make reviews easier. > > > > Note: please don't consider this as "replacing JIRA with GitHub issues". > > I understand that a mere replacement of system X with system Y often > brings > > nothing. > > > > See the relevant discussion thread: > > https://lists.apache.org/thread/m2h13v2p7kowglj73qr4sqn1c3pm8tlq > > > > Current state > > > > > > We already allow committing changes to Git without PR, and without JIRA > > ticket. > > We already allow submitting PRs without JIRA. > > I do not mean we encourage that, however, there's no strict rule like > > "every commit must have JIRA". > > > > The pattern I see is: > > * contributors spend time figuring out if there's a bug in their system > or > > if there's a bug in Calcite > > * then they create JIRA with all the details > > * they submit a PR with the relevant change right away > > * they copy the same-looking information multiple times: git commit, JIRA > > description, PR description (it is often left blank though) > > > > The discussion often separates between JIRA and PR. > > PR is super-convenient for line-based comments, > > on the other hand, "bigger comments" are put in JIRA (for unknown to me > > reasons). > > It is extremely sad when JIRA comments refer to specific bits of the > code. > > > > We even have a label "discussion-in-jira" that means "there's a > discussion > > JIRA, deal with it somehow". > > > > Suggestion > > > > > > Make PR-first a common approach for most of the changes. > > > > Small changes like adding tests, fixing documentation > > could come as pull requests without creating the corresponding JIRA > ticket. > > https://github.com/apache/calcite/pull/2628 (Add test for 'a IS NOT > NULL...) > > All the comments from https://issues.apache.org/jira/browse/CALCITE-4917 > > could be put to the PR2628 itself. There's no need for a separate > "ticket" > > or "issue" > > since PR itself could explain the reason for the change quite well. > > > > I suggest we put "high level" comments into the PR itself. > > > > The same works for bigger features. > > A bigger feature can appear as a draft PR, then we shape it in comments, > > and merge it. > > A complex feature can appear as a GitHub issue that references other > issues > > or PRs. > > > > Sometimes we do not have a solution, so we might create GitHub Issue or > > send dev@calcite mail for that. > > > > In practice, the suggestion does not change much, however, > > I suggest removing the duplication of work (no need to copy the > information > > across PRs and JIRAs), > > it makes merge simpler (no need to update JIRA), > > it makes searching issues easier (there would be a single field to search > > for issues). > > > > > > Release management > > > > > > Both GitHub PR and GitHub Issue can be associated with a milestone > > (~version), > > so we could use it to track which release includes what. > > > > Issue history > > > > > > We could keep old tickets in JIRA and use GitHub for new issues only. > > That is the most trivial approach, Airflow team did that, and we might be > > ok with that. > > > > An alternative option is to copy issues (including resolved ones). > > I guess attachments would be hard to clone, however, copying issues and > > comments should not be a problem. > > > > Other > > > > > > I might miss certain bits, however, I suggest figuring out the solutions > > later. > > I am sure GitHub covers all the cases we need, and we have dev@calcite > as a > > fallback. > > > > Vladimir > >
Re: [VOTE] Move to GitHub PR-centric development workflow, phase out JIRA
-1 I’m happy with the status quo. > On Dec 3, 2021, at 9:34 AM, Vladimir Sitnikov > wrote: > > Hi, > > Let us have a vote for PR-centric workflow for Calcite. > > [ ] +1, let's move to GitHub PRs/Issues for change management. > [ ] -1, keep using JIRA because, > > Here's my vote: > +1 (binding), let's move to GitHub PRs/Issues for change management. > > Note: dev@calcite keeps as is. I do not suggest replacing it. > > I suggest the adjustment of development workflow would reduce maintenance > costs, > make contributions easier, and make reviews easier. > > Note: please don't consider this as "replacing JIRA with GitHub issues". > I understand that a mere replacement of system X with system Y often brings > nothing. > > See the relevant discussion thread: > https://lists.apache.org/thread/m2h13v2p7kowglj73qr4sqn1c3pm8tlq > > Current state > > > We already allow committing changes to Git without PR, and without JIRA > ticket. > We already allow submitting PRs without JIRA. > I do not mean we encourage that, however, there's no strict rule like > "every commit must have JIRA". > > The pattern I see is: > * contributors spend time figuring out if there's a bug in their system or > if there's a bug in Calcite > * then they create JIRA with all the details > * they submit a PR with the relevant change right away > * they copy the same-looking information multiple times: git commit, JIRA > description, PR description (it is often left blank though) > > The discussion often separates between JIRA and PR. > PR is super-convenient for line-based comments, > on the other hand, "bigger comments" are put in JIRA (for unknown to me > reasons). > It is extremely sad when JIRA comments refer to specific bits of the code. > > We even have a label "discussion-in-jira" that means "there's a discussion > JIRA, deal with it somehow". > > Suggestion > > > Make PR-first a common approach for most of the changes. > > Small changes like adding tests, fixing documentation > could come as pull requests without creating the corresponding JIRA ticket. > https://github.com/apache/calcite/pull/2628 (Add test for 'a IS NOT NULL...) > All the comments from https://issues.apache.org/jira/browse/CALCITE-4917 > could be put to the PR2628 itself. There's no need for a separate "ticket" > or "issue" > since PR itself could explain the reason for the change quite well. > > I suggest we put "high level" comments into the PR itself. > > The same works for bigger features. > A bigger feature can appear as a draft PR, then we shape it in comments, > and merge it. > A complex feature can appear as a GitHub issue that references other issues > or PRs. > > Sometimes we do not have a solution, so we might create GitHub Issue or > send dev@calcite mail for that. > > In practice, the suggestion does not change much, however, > I suggest removing the duplication of work (no need to copy the information > across PRs and JIRAs), > it makes merge simpler (no need to update JIRA), > it makes searching issues easier (there would be a single field to search > for issues). > > > Release management > > > Both GitHub PR and GitHub Issue can be associated with a milestone > (~version), > so we could use it to track which release includes what. > > Issue history > > > We could keep old tickets in JIRA and use GitHub for new issues only. > That is the most trivial approach, Airflow team did that, and we might be > ok with that. > > An alternative option is to copy issues (including resolved ones). > I guess attachments would be hard to clone, however, copying issues and > comments should not be a problem. > > Other > > > I might miss certain bits, however, I suggest figuring out the solutions > later. > I am sure GitHub covers all the cases we need, and we have dev@calcite as a > fallback. > > Vladimir
[VOTE] Move to GitHub PR-centric development workflow, phase out JIRA
Hi, Let us have a vote for PR-centric workflow for Calcite. [ ] +1, let's move to GitHub PRs/Issues for change management. [ ] -1, keep using JIRA because, Here's my vote: +1 (binding), let's move to GitHub PRs/Issues for change management. Note: dev@calcite keeps as is. I do not suggest replacing it. I suggest the adjustment of development workflow would reduce maintenance costs, make contributions easier, and make reviews easier. Note: please don't consider this as "replacing JIRA with GitHub issues". I understand that a mere replacement of system X with system Y often brings nothing. See the relevant discussion thread: https://lists.apache.org/thread/m2h13v2p7kowglj73qr4sqn1c3pm8tlq Current state We already allow committing changes to Git without PR, and without JIRA ticket. We already allow submitting PRs without JIRA. I do not mean we encourage that, however, there's no strict rule like "every commit must have JIRA". The pattern I see is: * contributors spend time figuring out if there's a bug in their system or if there's a bug in Calcite * then they create JIRA with all the details * they submit a PR with the relevant change right away * they copy the same-looking information multiple times: git commit, JIRA description, PR description (it is often left blank though) The discussion often separates between JIRA and PR. PR is super-convenient for line-based comments, on the other hand, "bigger comments" are put in JIRA (for unknown to me reasons). It is extremely sad when JIRA comments refer to specific bits of the code. We even have a label "discussion-in-jira" that means "there's a discussion JIRA, deal with it somehow". Suggestion Make PR-first a common approach for most of the changes. Small changes like adding tests, fixing documentation could come as pull requests without creating the corresponding JIRA ticket. https://github.com/apache/calcite/pull/2628 (Add test for 'a IS NOT NULL...) All the comments from https://issues.apache.org/jira/browse/CALCITE-4917 could be put to the PR2628 itself. There's no need for a separate "ticket" or "issue" since PR itself could explain the reason for the change quite well. I suggest we put "high level" comments into the PR itself. The same works for bigger features. A bigger feature can appear as a draft PR, then we shape it in comments, and merge it. A complex feature can appear as a GitHub issue that references other issues or PRs. Sometimes we do not have a solution, so we might create GitHub Issue or send dev@calcite mail for that. In practice, the suggestion does not change much, however, I suggest removing the duplication of work (no need to copy the information across PRs and JIRAs), it makes merge simpler (no need to update JIRA), it makes searching issues easier (there would be a single field to search for issues). Release management Both GitHub PR and GitHub Issue can be associated with a milestone (~version), so we could use it to track which release includes what. Issue history We could keep old tickets in JIRA and use GitHub for new issues only. That is the most trivial approach, Airflow team did that, and we might be ok with that. An alternative option is to copy issues (including resolved ones). I guess attachments would be hard to clone, however, copying issues and comments should not be a problem. Other I might miss certain bits, however, I suggest figuring out the solutions later. I am sure GitHub covers all the cases we need, and we have dev@calcite as a fallback. Vladimir
