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:
>> 
>>> On 8/15/10 6:48 AM, "David Kastrup" <address@hidden> wrote:
>>> 
>>> 
>>> IMO, getting rid of bit-rotted code is always a good idea.
>>> 
>>>> Should it
>>>> be wrapped in a full review process?
>>> 
>>> 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.  And you don't have
> to eliminate the change from the ongoing development in the related area; if
> you're confident it's worth eliminating then eliminate it in your
> development work.

The development work should go up to Rietveld, the cleanup should go up
to Rietveld.  git-cl can associate only one review per branch.  So I
need to fork out the cleanup from the middle of the branch.  Possibly by
rebasing it to the tip of the branch and then creating a branch from
HEAD~1, cherrypicking HEAD.  No wait, more likely to the bottom and then
just labelling a new branch there.  Whatever.  I'll figure it out.

-- 
David Kastrup