Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Vladimir Kuklin]

Matthew

Thanks for your feedback. Could you please elaborate more on the statistics
of such tech-debt eliminations? My perception is that such bugs do not ever
get fixed actually jeopardizing our efforts on bugfixing and actually
making our statistics manupilative.

So far my suggestion is the following - if you can, please do not introduce
workarounds. If you have - introduce a TODO/FIXME comment for it in the
code and create a tech-debt bug. If you see something of that kind that is
already there and does not have such a comment - add this TODO/FIXME and
create a tech-debt bug.

So this is a best effort initiative, but I would encourage core reviewers
to be stricter with such workarounds and hacks - please, do not get them
pass through your hands unless there is a really good reason to merge this
code with these hacks right now.

On Wed, Nov 11, 2015 at 1:43 PM, Matthew Mosesohn 
wrote:

> Vladimir,
>
> Bugfixes and minor refactoring often belong in separate commits. Combining
> "extending foo to enable bar in XYZ" with "ensuring logs from service abc
> are sent via syslog" often makes little sense to code reviewers. In this
> case it is a feature enhancement + a bugfix.
>
> Looking at it from one perspective, if the bugfix is made poorly without a
> feature commit, then it looks like the scenario you described. However, it
> has the benefit that it can be cleanly backported. If we simply reverse the
> order of the commits (untangling the workaround), we get the same result,
> but get flamed.
>
> Sometimes both approaches are necessary. I agree that not growing tech
> debt is important, but perceptions really depend on trends over 3+ weeks.
> It's possible that such tech debt bugs are created and solved within 2-3
> days of the workaround. I know that's the exception, but I think we should
> be most concerned about what happens when we carry tech debt across entire
> Fuel releases.
> On Nov 11, 2015 10:28 AM, "Aleksandr Didenko" 
> wrote:
>
>> +1 from me
>>
>> On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin <
>> sbogat...@mirantis.com> wrote:
>>
>>> I think that it is excellent thought.
>>> +1
>>>
>>> On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin 
>>> wrote:
>>>
 Folks

 I wanted to raise awareness about one of the things I captured while
 doing reviews recently - we are sacrificing quality to bugfixing and
 feature development velocity, essentially moving from one heap to another -
 from bugs/features to 'tech-debt' bugs.

 I understand that we all have deadlines and need to meet them. But,
 folks, let's create the following policy:

 1) do not introduce hacks/workarounds/kludges if it is possible.
 2) while fixing things if you have a hack/workaround/kludge that you
 need to work with - think of removing it instead of enhancing and extending
 it. If it is possible - fix it. Do not let our technical debt grow.
 3) if there is no way to avoid kludge addition/enhancing, if there is
 no way to remove it - please, add a 'TODO/FIXME' line above it, so that we
 can collect them in the future and fix them gradually.

 I suggest to add this requirement into code-review policy.

 What do you think about this?

 --
 Yours Faithfully,
 Vladimir Kuklin,
 Fuel Library Tech Lead,
 Mirantis, Inc.
 +7 (495) 640-49-04
 +7 (926) 702-39-68
 Skype kuklinvv
 35bk3, Vorontsovskaya Str.
 Moscow, Russia,
 www.mirantis.com 
 www.mirantis.ru
 vkuk...@mirantis.com


 __
 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
>
>


-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype 

Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Matthew Mosesohn]

Vladimir,

Bugfixes and minor refactoring often belong in separate commits. Combining
"extending foo to enable bar in XYZ" with "ensuring logs from service abc
are sent via syslog" often makes little sense to code reviewers. In this
case it is a feature enhancement + a bugfix.

Looking at it from one perspective, if the bugfix is made poorly without a
feature commit, then it looks like the scenario you described. However, it
has the benefit that it can be cleanly backported. If we simply reverse the
order of the commits (untangling the workaround), we get the same result,
but get flamed.

Sometimes both approaches are necessary. I agree that not growing tech debt
is important, but perceptions really depend on trends over 3+ weeks. It's
possible that such tech debt bugs are created and solved within 2-3 days of
the workaround. I know that's the exception, but I think we should be most
concerned about what happens when we carry tech debt across entire Fuel
releases.
On Nov 11, 2015 10:28 AM, "Aleksandr Didenko"  wrote:

> +1 from me
>
> On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin <
> sbogat...@mirantis.com> wrote:
>
>> I think that it is excellent thought.
>> +1
>>
>> On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin 
>> wrote:
>>
>>> Folks
>>>
>>> I wanted to raise awareness about one of the things I captured while
>>> doing reviews recently - we are sacrificing quality to bugfixing and
>>> feature development velocity, essentially moving from one heap to another -
>>> from bugs/features to 'tech-debt' bugs.
>>>
>>> I understand that we all have deadlines and need to meet them. But,
>>> folks, let's create the following policy:
>>>
>>> 1) do not introduce hacks/workarounds/kludges if it is possible.
>>> 2) while fixing things if you have a hack/workaround/kludge that you
>>> need to work with - think of removing it instead of enhancing and extending
>>> it. If it is possible - fix it. Do not let our technical debt grow.
>>> 3) if there is no way to avoid kludge addition/enhancing, if there is no
>>> way to remove it - please, add a 'TODO/FIXME' line above it, so that we can
>>> collect them in the future and fix them gradually.
>>>
>>> I suggest to add this requirement into code-review policy.
>>>
>>> What do you think about this?
>>>
>>> --
>>> Yours Faithfully,
>>> Vladimir Kuklin,
>>> Fuel Library Tech Lead,
>>> Mirantis, Inc.
>>> +7 (495) 640-49-04
>>> +7 (926) 702-39-68
>>> Skype kuklinvv
>>> 35bk3, Vorontsovskaya Str.
>>> Moscow, Russia,
>>> www.mirantis.com 
>>> www.mirantis.ru
>>> vkuk...@mirantis.com
>>>
>>>
>>> __
>>> 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

Re: [openstack-dev] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Igor Kalnitsky]

Folks,

I have one thing to add: if workaround is unavoidable, please DO
comment it. Usually  workaround aren't obvious, and it would be
incredibly helpful to comment all of them; and do not hesitate to
write extensive comments. The clearer you write - the less time your
colleagues will spend next time they touch such code.

Thanks,
Igor

On Wed, Nov 11, 2015 at 2:58 AM, Vladimir Kuklin  wrote:
> Matthew
>
> Thanks for your feedback. Could you please elaborate more on the statistics
> of such tech-debt eliminations? My perception is that such bugs do not ever
> get fixed actually jeopardizing our efforts on bugfixing and actually making
> our statistics manupilative.
>
> So far my suggestion is the following - if you can, please do not introduce
> workarounds. If you have - introduce a TODO/FIXME comment for it in the code
> and create a tech-debt bug. If you see something of that kind that is
> already there and does not have such a comment - add this TODO/FIXME and
> create a tech-debt bug.
>
> So this is a best effort initiative, but I would encourage core reviewers to
> be stricter with such workarounds and hacks - please, do not get them pass
> through your hands unless there is a really good reason to merge this code
> with these hacks right now.
>
> On Wed, Nov 11, 2015 at 1:43 PM, Matthew Mosesohn 
> wrote:
>>
>> Vladimir,
>>
>> Bugfixes and minor refactoring often belong in separate commits. Combining
>> "extending foo to enable bar in XYZ" with "ensuring logs from service abc
>> are sent via syslog" often makes little sense to code reviewers. In this
>> case it is a feature enhancement + a bugfix.
>>
>> Looking at it from one perspective, if the bugfix is made poorly without a
>> feature commit, then it looks like the scenario you described. However, it
>> has the benefit that it can be cleanly backported. If we simply reverse the
>> order of the commits (untangling the workaround), we get the same result,
>> but get flamed.
>>
>> Sometimes both approaches are necessary. I agree that not growing tech
>> debt is important, but perceptions really depend on trends over 3+ weeks.
>> It's possible that such tech debt bugs are created and solved within 2-3
>> days of the workaround. I know that's the exception, but I think we should
>> be most concerned about what happens when we carry tech debt across entire
>> Fuel releases.
>>
>> On Nov 11, 2015 10:28 AM, "Aleksandr Didenko" 
>> wrote:
>>>
>>> +1 from me
>>>
>>> On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin
>>>  wrote:

 I think that it is excellent thought.
 +1

 On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin 
 wrote:
>
> Folks
>
> I wanted to raise awareness about one of the things I captured while
> doing reviews recently - we are sacrificing quality to bugfixing and 
> feature
> development velocity, essentially moving from one heap to another - from
> bugs/features to 'tech-debt' bugs.
>
> I understand that we all have deadlines and need to meet them. But,
> folks, let's create the following policy:
>
> 1) do not introduce hacks/workarounds/kludges if it is possible.
> 2) while fixing things if you have a hack/workaround/kludge that you
> need to work with - think of removing it instead of enhancing and 
> extending
> it. If it is possible - fix it. Do not let our technical debt grow.
> 3) if there is no way to avoid kludge addition/enhancing, if there is
> no way to remove it - please, add a 'TODO/FIXME' line above it, so that we
> can collect them in the future and fix them gradually.
>
> I suggest to add this requirement into code-review policy.
>
> What do you think about this?
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com
> www.mirantis.ru
> vkuk...@mirantis.com
>
>
> __
> 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] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Vladimir Kuklin]

Folks

I wanted to raise awareness about one of the things I captured while doing
reviews recently - we are sacrificing quality to bugfixing and feature
development velocity, essentially moving from one heap to another - from
bugs/features to 'tech-debt' bugs.

I understand that we all have deadlines and need to meet them. But, folks,
let's create the following policy:

1) do not introduce hacks/workarounds/kludges if it is possible.
2) while fixing things if you have a hack/workaround/kludge that you need
to work with - think of removing it instead of enhancing and extending it.
If it is possible - fix it. Do not let our technical debt grow.
3) if there is no way to avoid kludge addition/enhancing, if there is no
way to remove it - please, add a 'TODO/FIXME' line above it, so that we can
collect them in the future and fix them gradually.

I suggest to add this requirement into code-review policy.

What do you think about this?

-- 
Yours Faithfully,
Vladimir Kuklin,
Fuel Library Tech Lead,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
35bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com 
www.mirantis.ru
vkuk...@mirantis.com
__
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] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Stanislaw Bogatkin]

I think that it is excellent thought.
+1

On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin 
wrote:

> Folks
>
> I wanted to raise awareness about one of the things I captured while doing
> reviews recently - we are sacrificing quality to bugfixing and feature
> development velocity, essentially moving from one heap to another - from
> bugs/features to 'tech-debt' bugs.
>
> I understand that we all have deadlines and need to meet them. But, folks,
> let's create the following policy:
>
> 1) do not introduce hacks/workarounds/kludges if it is possible.
> 2) while fixing things if you have a hack/workaround/kludge that you need
> to work with - think of removing it instead of enhancing and extending it.
> If it is possible - fix it. Do not let our technical debt grow.
> 3) if there is no way to avoid kludge addition/enhancing, if there is no
> way to remove it - please, add a 'TODO/FIXME' line above it, so that we can
> collect them in the future and fix them gradually.
>
> I suggest to add this requirement into code-review policy.
>
> What do you think about this?
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 35bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com 
> www.mirantis.ru
> vkuk...@mirantis.com
>
> __
> 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] [Fuel][Fuel-QA][Fuel-TechDebt] Code Quality: Do Not Hardcode - Fix Things Instead

[Aleksandr Didenko]

+1 from me

On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin 
wrote:

> I think that it is excellent thought.
> +1
>
> On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin 
> wrote:
>
>> Folks
>>
>> I wanted to raise awareness about one of the things I captured while
>> doing reviews recently - we are sacrificing quality to bugfixing and
>> feature development velocity, essentially moving from one heap to another -
>> from bugs/features to 'tech-debt' bugs.
>>
>> I understand that we all have deadlines and need to meet them. But,
>> folks, let's create the following policy:
>>
>> 1) do not introduce hacks/workarounds/kludges if it is possible.
>> 2) while fixing things if you have a hack/workaround/kludge that you need
>> to work with - think of removing it instead of enhancing and extending it.
>> If it is possible - fix it. Do not let our technical debt grow.
>> 3) if there is no way to avoid kludge addition/enhancing, if there is no
>> way to remove it - please, add a 'TODO/FIXME' line above it, so that we can
>> collect them in the future and fix them gradually.
>>
>> I suggest to add this requirement into code-review policy.
>>
>> What do you think about this?
>>
>> --
>> Yours Faithfully,
>> Vladimir Kuklin,
>> Fuel Library Tech Lead,
>> Mirantis, Inc.
>> +7 (495) 640-49-04
>> +7 (926) 702-39-68
>> Skype kuklinvv
>> 35bk3, Vorontsovskaya Str.
>> Moscow, Russia,
>> www.mirantis.com 
>> www.mirantis.ru
>> vkuk...@mirantis.com
>>
>> __
>> 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