launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Mar 11, 2010 at 4:02 PM, Tom Berger <tom.berger@xxxxxxxxxxxxx> wrote:
> On 11 March 2010 15:51, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
>> I had to make a change to sample data to accommodate a migration script.
>> `make lint` correctly reported there was problem and told me to run
>> makenewsampledata. I was surprised to see hundreds of lines changed for
>> when the migration script only added 15 lines. Most of the changes
>> relate to bug heat schema changes. This is not the first time this has
>> happened to me. In fact, this has always happened to me.
>>
>> I add the sampledata check to make lint because engineers were
>> complaining that they could not find their changes in the diff. I added
>> this feature because it was requested, but I think I am the only
>> engineer who is fixing the data. I want to remove this feature...this is
>> not my problem.
>>
>> Since make lint will always report the issue, I strongly suspect
>> engineers are not running make lint at all.
>
> Another thing that happens quite a lot (and I must admit I'm guilty
> myself) is that people do run lint, but ignore warnings that they know
> for certain are not a result of the changes they introduced. If we
> want to enforce lint we could have buildbot run it, but if we do we'll
> have to make sure it produces a reasonable set of warnings.
>

I suspect that the correct thing is to have a check that stops new
lint from being added. That way, once someone fixes some lint, the
amount of lint is permanently reduced. It also would spare us the
tedious exercise of getting the amount to zero before adding enforcing
rules.

Alternatively, we could add a unit test that asserts that the amount
of lint is a particular number, and then have an honesty policy of
never increasing the number. I think Bazaar do this for some of their
performance tests.

jml