Re: Half-baked unused features.

[David Kastrup]

David Kastrup <address@hidden> writes:

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

Ok, moving it to the bottom of the branch was a bad idea: moving the
cleanup across other changes done before it causes rebase conflicts
galore.  So I'll have to branch off the feature branch, meaning that my
diffs will not be applicable to the unchanged origin.  Maybe I can
rebase after moving it out?

But that should be similarly expensive.

-- 
David Kastrup