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 <[email protected]> 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 <[email protected]> > 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" <[email protected]> >> wrote: >>> >>> +1 from me >>> >>> On Tue, Nov 10, 2015 at 6:38 PM, Stanislaw Bogatkin >>> <[email protected]> wrote: >>>> >>>> I think that it is excellent thought. >>>> +1 >>>> >>>> On Tue, Nov 10, 2015 at 6:52 PM, Vladimir Kuklin <[email protected]> >>>> 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 >>>>> [email protected] >>>>> >>>>> >>>>> __________________________________________________________________________ >>>>> OpenStack Development Mailing List (not for usage questions) >>>>> Unsubscribe: >>>>> [email protected]?subject:unsubscribe >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: >>>> [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> [email protected]?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: [email protected]?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 kuklinvv > 35bk3, Vorontsovskaya Str. > Moscow, Russia, > www.mirantis.com > www.mirantis.ru > [email protected] > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
