Carl Sorensen <c_soren...@byu.edu> writes: > On 8/15/10 7:39 AM, "David Kastrup" <d...@gnu.org> wrote: > >> Carl Sorensen <c_soren...@byu.edu> writes: >> >>> On 8/15/10 6:48 AM, "David Kastrup" <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
