[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Half-baked unused features.
From: |
Carl Sorensen |
Subject: |
Re: Half-baked unused features. |
Date: |
Sun, 15 Aug 2010 17:32:55 -0600 |
On 8/15/10 9:40 AM, "David Kastrup" <address@hidden> wrote:
> 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.
But if you don't have a patch that applies to user source, how can you
"remove the feature in a single commit"? It seems that the problem you're
having right now is one of isolating the removal of the old code. Your
first email said "if I remove the old code in a separate commit that can be
reverted" or something to that effect.
The problem you're talking about now is a problem of isolating the removal,
not one of waiting for review on Rietveld.
Thanks,
Carl
- Re: Half-baked unused features., (continued)
- Re: Half-baked unused features., David Kastrup, 2010/08/15
- Re: Half-baked unused features., David Kastrup, 2010/08/15
- Re: Half-baked unused features., Carl Sorensen, 2010/08/15
- Re: Half-baked unused features., David Kastrup, 2010/08/15
- Review: remove markup function aliasing mechanism (was: Half-baked unused features.), David Kastrup, 2010/08/15
- Review: start work on markup doc and code (was: Half-baked unused features.), David Kastrup, 2010/08/15
- Re: Half-baked unused features., David Kastrup, 2010/08/15
- Re: Half-baked unused features.,
Carl Sorensen <=
- Re: Half-baked unused features., David Kastrup, 2010/08/15
- git merge drivers (was: Half-baked unused features.), Ralf Wildenhues, 2010/08/16
- Re: Half-baked unused features., Graham Percival, 2010/08/15
- Re: Half-baked unused features., David Kastrup, 2010/08/15
- Re: Half-baked unused features., Carl Sorensen, 2010/08/15
- Re: Half-baked unused features., Graham Percival, 2010/08/15
- Re: Half-baked unused features., Reinhold Kainhofer, 2010/08/16
Re: Half-baked unused features., Werner LEMBERG, 2010/08/15
Re: Half-baked unused features., Reinhold Kainhofer, 2010/08/16