You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Jens Geyer <je...@hotmail.com> on 2019/02/16 17:57:18 UTC
[DISCUSSION] JIRA-Tickets vs. Patches & Pull Requests
Hi all,
a few days ago Jim raised the question about the policy regarding JIRA tickets.
As I am not fully happy with either solution we practiced so far, I gave it a second thought.
So here’s my proposal:
1. We have one ticket per patch or pull request.
2. Minor changes may be put into one patch/PR.
The first part should be obvious, so let me focus on the second point.
Larger changes should still be split into multiple Patches / PRs, because they usually come with their own language specific discussion, problems, implermentation details and last not least test cases. In contrast, if a patch is quite minorish and affects a lot of languages needing a 3-liner fix in (basically) the same way, there is no point in creating 20 tickets just for the sake of having them.
A larger patch is defined by “changes that cannot easily be managed/commented/reviewed by one single person as a whole”. Yes, that’s a vague criterion, but it should only serve as a “intended outcome” kind of guide. The whole idea is to reduce unnecessary administrative overhead where possible, but split up matters where necessary. That’s what I want to achieve.
Could that work for us? Are there any objections? Other (maybe better) ideas?
Have fun,
JensG
Re: [DISCUSSION] JIRA-Tickets vs. Patches & Pull Requests
Posted by Jens Geyer <je...@hotmail.com>.
Hi Jim,
right, we rarely do tickets on web site contents, so it is probably fine to
do the same with build jobs and CI.
I was merely talking about the code base as such. As a general rule, every
patch to the code base should be justified, except for the super-trivial
ones. I didn't have that case in mind, but yes, I also agree here.
On that occasion, I want to fix a typo :-) I would like to change
one ticket per patch or pull request.
into
one ticket per patch set, or pull request.
Sometimes we have multiple patch files that belong to one ticket and are not
necessarily cumulative. In the idea of reducing overhead it makes sense to
mention that case explicitly.
Have fun,
JensG
-----Ursprüngliche Nachricht-----
From: James E. King III
Sent: Sunday, February 17, 2019 6:17 PM
To: dev@thrift.apache.org
Subject: Re: [DISCUSSION] JIRA-Tickets vs. Patches & Pull Requests
I don't think a ticket per pull request is appropriate for things like
typos, modifications to documentation, simple modifications to the CI
environment, or to code comments.
For example if I move the bionic build jobs from go 1.11.4 to 1.11.5, that
should not require a ticket. It's just noise in release notes.
- Jim
On Sat, Feb 16, 2019 at 12:57 PM Jens Geyer <je...@hotmail.com> wrote:
> Hi all,
>
> a few days ago Jim raised the question about the policy regarding JIRA
> tickets.
> As I am not fully happy with either solution we practiced so far, I gave
> it a second thought.
>
> So here’s my proposal:
>
> 1. We have one ticket per patch or pull request.
> 2. Minor changes may be put into one patch/PR.
>
> The first part should be obvious, so let me focus on the second point.
>
> Larger changes should still be split into multiple Patches / PRs, because
> they usually come with their own language specific discussion, problems,
> implermentation details and last not least test cases. In contrast, if a
> patch is quite minorish and affects a lot of languages needing a 3-liner
> fix in (basically) the same way, there is no point in creating 20 tickets
> just for the sake of having them.
>
> A larger patch is defined by “changes that cannot easily be
> managed/commented/reviewed by one single person as a whole”. Yes, that’s a
> vague criterion, but it should only serve as a “intended outcome” kind of
> guide. The whole idea is to reduce unnecessary administrative overhead
> where possible, but split up matters where necessary. That’s what I want
> to
> achieve.
>
> Could that work for us? Are there any objections? Other (maybe better)
> ideas?
>
> Have fun,
> JensG
>
>
>
>
Re: [DISCUSSION] JIRA-Tickets vs. Patches & Pull Requests
Posted by "James E. King III" <jk...@apache.org>.
I don't think a ticket per pull request is appropriate for things like
typos, modifications to documentation, simple modifications to the CI
environment, or to code comments.
For example if I move the bionic build jobs from go 1.11.4 to 1.11.5, that
should not require a ticket. It's just noise in release notes.
- Jim
On Sat, Feb 16, 2019 at 12:57 PM Jens Geyer <je...@hotmail.com> wrote:
> Hi all,
>
> a few days ago Jim raised the question about the policy regarding JIRA
> tickets.
> As I am not fully happy with either solution we practiced so far, I gave
> it a second thought.
>
> So here’s my proposal:
>
> 1. We have one ticket per patch or pull request.
> 2. Minor changes may be put into one patch/PR.
>
> The first part should be obvious, so let me focus on the second point.
>
> Larger changes should still be split into multiple Patches / PRs, because
> they usually come with their own language specific discussion, problems,
> implermentation details and last not least test cases. In contrast, if a
> patch is quite minorish and affects a lot of languages needing a 3-liner
> fix in (basically) the same way, there is no point in creating 20 tickets
> just for the sake of having them.
>
> A larger patch is defined by “changes that cannot easily be
> managed/commented/reviewed by one single person as a whole”. Yes, that’s a
> vague criterion, but it should only serve as a “intended outcome” kind of
> guide. The whole idea is to reduce unnecessary administrative overhead
> where possible, but split up matters where necessary. That’s what I want to
> achieve.
>
> Could that work for us? Are there any objections? Other (maybe better)
> ideas?
>
> Have fun,
> JensG
>
>
>
>