Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Adrian Otto]

Although I do think this is a good suggestion, let's resist the temptation to 
overthink this. No matter what guidance is offered, each exception to a policy 
needs to be judged individually. I suggest that when we encounter situations 
like this, that we allow the submitter to simply label the change as trivial 
and we trust that commit to go untracked unless there is a clear consensus to 
the contrary. Really the only downside to not tracking trivial changes is that 
our bug fix statistics are slightly lower. That's okay with me, as long as we 
are actually tracking the meaningful contributions.

--
Adrian

On Sep 18, 2015, at 4:02 PM, Hongbin Lu 
<hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote:

For the guidance, I saw the judgement is a bit subjective. It could happen that 
a contributor think his/her patch is trivial (or it is not fixing a function 
defect), but a reviewer think the opposite. For example, I find it hard to 
judge when I reviewed the following patches:

https://review.openstack.org/#/c/224183/
https://review.openstack.org/#/c/224198/
https://review.openstack.org/#/c/224184/

It could be helpful if the guide can provide some examples of what is a trivial 
patch, and what is not. OpenStack uses this approach to define what is a 
good/bad commit message, which I find it quite helpful.

https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_bad_practice
https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_good_practice

Best regards,
Hongbin

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: September-17-15 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please 
don't hurt me)

For posterity, I have recorded this guidance in our Contributing Wiki:

See the NOTE section under:

https://wiki.openstack.org/wiki/Magnum/Contributing#Identify_bugs

Excerpt:

"NOTE: If you are fixing something trivial, that is not actually a functional 
defect in the software, you can do that without filing a bug ticket, if you 
don't want it to be tracked when we tally this work between releases. If you do 
this, just mention it in the commit message that it's a trivial change that 
does not require a bug ticket. You can reference this guideline if it comes up 
in discussion during the review process. Functional defects should be tracked 
in bug tickets. New features should be tracked in blueprints. Trivial features 
may be tracked using a bug ticket marked as 'Wishlist' importance."

I hope that helps.

Adrian

On Sep 17, 2015, at 2:01 PM, Adrian Otto 
<adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> wrote:

Let’s apply sensible reason. If it’s a new feature or a bug, it should be 
tracked against an artifact like a bug ticket or a blueprint. If it’s truly 
trivia, we don’t care. I can tell you that some of the worst bugs I have ever 
seen in my career had fixes that were about 4 bytes long. That did not make 
them any less serious.

If you are fixing an actual legitimate bug that has a three character fix, and 
you don’t want it to be tracked as the reviewer, then you can say so in the 
commit message. We can act accordingly going forward.

Adrian

On Sep 17, 2015, at 1:53 PM, Assaf Muller 
<amul...@redhat.com<mailto:amul...@redhat.com>> wrote:


On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler 
<jpee...@redhat.com<mailto:jpee...@redhat.com>> wrote:

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

It is indeed frustrating. I've had a few similar reviews (in other projects - 
hopefully it's okay I comment here) as well. Honestly, I think if a given team 
is willing to draw the line as for what is permissible to commit without bug 
creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come release 
time having the list of bugs fixed in a given release is handy, spelling errors 
included.

We've had the same debate in Neutron and we relaxed the rules. We don't require 
bugs for trivial changes. In fact, my argument has always been: Come release
time, when we say that the Neutron community fixed so and so bugs, we would be 
lying if we were to include fixing spelling issues in comments. That's not a 
bug.


__

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Hongbin Lu]

For the guidance, I saw the judgement is a bit subjective. It could happen that 
a contributor think his/her patch is trivial (or it is not fixing a function 
defect), but a reviewer think the opposite. For example, I find it hard to 
judge when I reviewed the following patches:

https://review.openstack.org/#/c/224183/
https://review.openstack.org/#/c/224198/
https://review.openstack.org/#/c/224184/

It could be helpful if the guide can provide some examples of what is a trivial 
patch, and what is not. OpenStack uses this approach to define what is a 
good/bad commit message, which I find it quite helpful.

https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_bad_practice
https://wiki.openstack.org/wiki/GitCommitMessages#Examples_of_good_practice

Best regards,
Hongbin

From: Adrian Otto [mailto:adrian.o...@rackspace.com]
Sent: September-17-15 5:09 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please 
don't hurt me)

For posterity, I have recorded this guidance in our Contributing Wiki:

See the NOTE section under:

https://wiki.openstack.org/wiki/Magnum/Contributing#Identify_bugs

Excerpt:

"NOTE: If you are fixing something trivial, that is not actually a functional 
defect in the software, you can do that without filing a bug ticket, if you 
don't want it to be tracked when we tally this work between releases. If you do 
this, just mention it in the commit message that it's a trivial change that 
does not require a bug ticket. You can reference this guideline if it comes up 
in discussion during the review process. Functional defects should be tracked 
in bug tickets. New features should be tracked in blueprints. Trivial features 
may be tracked using a bug ticket marked as 'Wishlist' importance."

I hope that helps.

Adrian

On Sep 17, 2015, at 2:01 PM, Adrian Otto 
<adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> wrote:

Let’s apply sensible reason. If it’s a new feature or a bug, it should be 
tracked against an artifact like a bug ticket or a blueprint. If it’s truly 
trivia, we don’t care. I can tell you that some of the worst bugs I have ever 
seen in my career had fixes that were about 4 bytes long. That did not make 
them any less serious.

If you are fixing an actual legitimate bug that has a three character fix, and 
you don’t want it to be tracked as the reviewer, then you can say so in the 
commit message. We can act accordingly going forward.

Adrian

On Sep 17, 2015, at 1:53 PM, Assaf Muller 
<amul...@redhat.com<mailto:amul...@redhat.com>> wrote:


On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler 
<jpee...@redhat.com<mailto:jpee...@redhat.com>> wrote:

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M 
<kevin@pnnl.gov<mailto:kevin@pnnl.gov>> wrote:
I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

It is indeed frustrating. I've had a few similar reviews (in other projects - 
hopefully it's okay I comment here) as well. Honestly, I think if a given team 
is willing to draw the line as for what is permissible to commit without bug 
creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come release 
time having the list of bugs fixed in a given release is handy, spelling errors 
included.

We've had the same debate in Neutron and we relaxed the rules. We don't require 
bugs for trivial changes. In fact, my argument has always been: Come release
time, when we say that the Neutron community fixed so and so bugs, we would be 
lying if we were to include fixing spelling issues in comments. That's not a 
bug.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__

[openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Ryan Rossiter]

I'm going to start out by making this clear: I am not looking to incite 
a flame war.


I've been working in Magnum for a couple of weeks now, and I'm starting 
to get down the processes for contribution. I'm here to talk about the 
process of always needing to have a patch associated with a bug or 
blueprint.


I have a good example of this being too strict. I knew the rules, so I 
opened [1] to say there are some improperly named variables and classes. 
I think it took longer for me to open the bug than it did to actually 
fix it. I think we need to start taking a look at how strict we need to 
be in requiring bugs to be opened and linked to patches. I understand 
it's a fine line between "it's broken" to "it would be nice to make this 
better".


I remember the debate when I was originally putting up [2] for review. 
The worry was that if these new tests would cut into developer 
productivity because it is more strict. The same argument can be applied 
to opening these bugs. If we have to open something up for everything we 
want to upload a patch for, that's just another step in the process to 
take up time.


Now, with my opinion out there, if we still want to take the direction 
of opening up bugs for everything, I will comply (I'm not the guy making 
decisions around here). I would like to see clear and present 
documentation explaining this to new contributors, though ([3] would 
probably be a good place to explain this).


Once again, not looking to start an argument. If everyone feels the way 
it works now is the best, I'm more than happy to join in :)


[1] https://bugs.launchpad.net/magnum/+bug/1496568
[2] https://review.openstack.org/#/c/217342/
[3] http://docs.openstack.org/developer/magnum/contributing.html

--
Thanks,

Ryan Rossiter (rlrossit)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Fox, Kevin M]

I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

Thanks,
Kevin


From: Ryan Rossiter [rlros...@linux.vnet.ibm.com]
Sent: Thursday, September 17, 2015 11:58 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [magnum] Associating patches with bugs/bps (Please 
don't hurt me)

I'm going to start out by making this clear: I am not looking to incite
a flame war.

I've been working in Magnum for a couple of weeks now, and I'm starting
to get down the processes for contribution. I'm here to talk about the
process of always needing to have a patch associated with a bug or
blueprint.

I have a good example of this being too strict. I knew the rules, so I
opened [1] to say there are some improperly named variables and classes.
I think it took longer for me to open the bug than it did to actually
fix it. I think we need to start taking a look at how strict we need to
be in requiring bugs to be opened and linked to patches. I understand
it's a fine line between "it's broken" to "it would be nice to make this
better".

I remember the debate when I was originally putting up [2] for review.
The worry was that if these new tests would cut into developer
productivity because it is more strict. The same argument can be applied
to opening these bugs. If we have to open something up for everything we
want to upload a patch for, that's just another step in the process to
take up time.

Now, with my opinion out there, if we still want to take the direction
of opening up bugs for everything, I will comply (I'm not the guy making
decisions around here). I would like to see clear and present
documentation explaining this to new contributors, though ([3] would
probably be a good place to explain this).

Once again, not looking to start an argument. If everyone feels the way
it works now is the best, I'm more than happy to join in :)

[1] https://bugs.launchpad.net/magnum/+bug/1496568
[2] https://review.openstack.org/#/c/217342/
[3] http://docs.openstack.org/developer/magnum/contributing.html

--
Thanks,

Ryan Rossiter (rlrossit)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Jeff Peeler]

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M  wrote:

> I agree. Lots of projects have this issue. I submitted a bug fix once that
> literally was 3 characters long, and it took:
> A short commit message, a long commit message, and a full bug report being
> filed and cross linked. The amount of time writing it up was orders of
> magnitude longer then the actual fix.
>
> Seems a bit much...
>
> Looking at this review, I'd go a step farther and argue that code cleanups
> like this one should be really really easy to get through. No one likes to
> do them, so we should be encouraging folks that actually do it. Not pile up
> roadblocks.


It is indeed frustrating. I've had a few similar reviews (in other projects
- hopefully it's okay I comment here) as well. Honestly, I think if a given
team is willing to draw the line as for what is permissible to commit
without bug creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come
release time having the list of bugs fixed in a given release is handy,
spelling errors included.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Assaf Muller]

On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler  wrote:

>
> On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M  wrote:
>
>> I agree. Lots of projects have this issue. I submitted a bug fix once
>> that literally was 3 characters long, and it took:
>> A short commit message, a long commit message, and a full bug report
>> being filed and cross linked. The amount of time writing it up was orders
>> of magnitude longer then the actual fix.
>>
>> Seems a bit much...
>>
>> Looking at this review, I'd go a step farther and argue that code
>> cleanups like this one should be really really easy to get through. No one
>> likes to do them, so we should be encouraging folks that actually do it.
>> Not pile up roadblocks.
>
>
> It is indeed frustrating. I've had a few similar reviews (in other
> projects - hopefully it's okay I comment here) as well. Honestly, I think
> if a given team is willing to draw the line as for what is permissible to
> commit without bug creation, then they should be permitted that freedom.
>
> However, that said, I'm sure somebody is going to point out that come
> release time having the list of bugs fixed in a given release is handy,
> spelling errors included.
>

We've had the same debate in Neutron and we relaxed the rules. We don't
require bugs for trivial changes. In fact, my argument has always been:
Come release
time, when we say that the Neutron community fixed so and so bugs, we would
be lying if we were to include fixing spelling issues in comments. That's
not a bug.


>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Adrian Otto]

Let’s apply sensible reason. If it’s a new feature or a bug, it should be 
tracked against an artifact like a bug ticket or a blueprint. If it’s truly 
trivia, we don’t care. I can tell you that some of the worst bugs I have ever 
seen in my career had fixes that were about 4 bytes long. That did not make 
them any less serious.

If you are fixing an actual legitimate bug that has a three character fix, and 
you don’t want it to be tracked as the reviewer, then you can say so in the 
commit message. We can act accordingly going forward.

Adrian

On Sep 17, 2015, at 1:53 PM, Assaf Muller 
> wrote:



On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler 
> wrote:

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M 
> wrote:
I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

It is indeed frustrating. I've had a few similar reviews (in other projects - 
hopefully it's okay I comment here) as well. Honestly, I think if a given team 
is willing to draw the line as for what is permissible to commit without bug 
creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come release 
time having the list of bugs fixed in a given release is handy, spelling errors 
included.

We've had the same debate in Neutron and we relaxed the rules. We don't require 
bugs for trivial changes. In fact, my argument has always been: Come release
time, when we say that the Neutron community fixed so and so bugs, we would be 
lying if we were to include fixing spelling issues in comments. That's not a 
bug.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [magnum] Associating patches with bugs/bps (Please don't hurt me)

[Adrian Otto]

For posterity, I have recorded this guidance in our Contributing Wiki:

See the NOTE section under:

https://wiki.openstack.org/wiki/Magnum/Contributing#Identify_bugs

Excerpt:

"NOTE: If you are fixing something trivial, that is not actually a functional 
defect in the software, you can do that without filing a bug ticket, if you 
don't want it to be tracked when we tally this work between releases. If you do 
this, just mention it in the commit message that it's a trivial change that 
does not require a bug ticket. You can reference this guideline if it comes up 
in discussion during the review process. Functional defects should be tracked 
in bug tickets. New features should be tracked in blueprints. Trivial features 
may be tracked using a bug ticket marked as 'Wishlist' importance."

I hope that helps.

Adrian

On Sep 17, 2015, at 2:01 PM, Adrian Otto 
> wrote:

Let’s apply sensible reason. If it’s a new feature or a bug, it should be 
tracked against an artifact like a bug ticket or a blueprint. If it’s truly 
trivia, we don’t care. I can tell you that some of the worst bugs I have ever 
seen in my career had fixes that were about 4 bytes long. That did not make 
them any less serious.

If you are fixing an actual legitimate bug that has a three character fix, and 
you don’t want it to be tracked as the reviewer, then you can say so in the 
commit message. We can act accordingly going forward.

Adrian

On Sep 17, 2015, at 1:53 PM, Assaf Muller 
> wrote:



On Thu, Sep 17, 2015 at 4:09 PM, Jeff Peeler 
> wrote:

On Thu, Sep 17, 2015 at 3:28 PM, Fox, Kevin M 
> wrote:
I agree. Lots of projects have this issue. I submitted a bug fix once that 
literally was 3 characters long, and it took:
A short commit message, a long commit message, and a full bug report being 
filed and cross linked. The amount of time writing it up was orders of 
magnitude longer then the actual fix.

Seems a bit much...

Looking at this review, I'd go a step farther and argue that code cleanups like 
this one should be really really easy to get through. No one likes to do them, 
so we should be encouraging folks that actually do it. Not pile up roadblocks.

It is indeed frustrating. I've had a few similar reviews (in other projects - 
hopefully it's okay I comment here) as well. Honestly, I think if a given team 
is willing to draw the line as for what is permissible to commit without bug 
creation, then they should be permitted that freedom.

However, that said, I'm sure somebody is going to point out that come release 
time having the list of bugs fixed in a given release is handy, spelling errors 
included.

We've had the same debate in Neutron and we relaxed the rules. We don't require 
bugs for trivial changes. In fact, my argument has always been: Come release
time, when we say that the Neutron community fixed so and so bugs, we would be 
lying if we were to include fixing spelling issues in comments. That's not a 
bug.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev