Re: Half-baked unused features.

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 8/15/10 7:39 AM, "David Kastrup" <address@hidden> wrote:
>
>> Carl Sorensen <address@hidden> writes:
>>> 
>>> I think so.  The full review process for removing old stuff is
>>> generally very short and sweet (post the patch, somebody important
>>> says OK), so I don't think it hurts a bit to do it.
>> 
>> It only involves creating a separate branch, moving the change there,
>> removing the change from all ongoing development in related areas
>> (and/or postponing work on them until the review process of the
>> bitrot change has come to a close), creating a Rietveld issue,
>> uploading the changes to Rietveld, monitoring all progress on it,
>> repeating a full regtest for any proposed modifications and juggling
>> with merge/cherry-pick while doing the parallel development and so
>> on.
>
> No, you said it was all in one commit.  So you have a branch with that
> commit and you keep rebasing it.  It's quite easy to do.

The rebase is in conflict with the other development.  I tried that
first, but stopped before seriously working on the rebase conflicts
(experience tells me that one such conflict is followed by number of
conflicts in the same series, making this very tiresome since your
conflict resolution leads to more conflicts later).  Saving time less
experienced gitters would likely expend.  At the cost of making the
review less usable (patches won't apply to user source).

So up to now, just a bit more than 30 minutes of work.  "short and
sweet, doesn't hurt a bit".  Huh.

> And if it's really not used, then removing it will have no effect
> whatsoever on your downstream stuff.

Except for merge conflicts.  Huh.

> I don't think I've *ever* seen anyone propose modifications in
> bitrotted stuff to be removed.

Huh?  The area is not bitrotted.  Only an unused subfeature that is
scattered across it.

> I think your argument doesn't match with the reality of the situation.

I think it does.  And I am the one working on it.

-- 
David Kastrup