For reasons others have mentioned (nightmare to continuously update branch and resolve merge conflicts, existing patches/big features..) it will be a nightmare. It seems like in software projects (just basing it off personal experience) people typically refactor if a ticket they are working on touches the part of the code base that needs refactoring, I've not really seen a freeze and work off technical debt before (I'll admit upfront I don't know much).
Thinking about it, the only ones I could come up with are the same as Sylvain had mentioned, which is start with a small subset and just do only renaming and cleaning up comments; no logic changes. I would think some parts of the code may take ages more before a ticket finds its way to it (and a knowledgable enough person is involved to even guide the refactor). So definitely, you have my (moral) support if you are going to go with it, +1 +1 +1 On 22 March 2018 at 00:31, Eric Evans <john.eric.ev...@gmail.com> wrote: > On Wed, Mar 21, 2018 at 3:48 AM, Sylvain Lebresne <lebre...@gmail.com> > wrote: > > [ ... ] > > > - pure code renaming is one reasonably simple aspect, but quite a few > > renaming may have user visible impact. Particularly around JMX where many > > things are name based on their class, and to a lesser extend some of our > > tools still use "old" naming. We can't and shouldn't ignore those impact: > > such user visible changes should imo be documented, and we should make > sure > > we have a reasonably painless (and thus incremental) upgrade path. My > hunch > > is the latter isn't as simple as it seems. > > Speaking as someone who has personally been burned by this > (repeatedly, and it's on-going), please think very carefully before > making such changes. I hate to think about of all the hours I wasted > shaving this breed of yak. > > > On Wed, Mar 21, 2018 at 9:06 AM kurt greaves <k...@instaclustr.com> > wrote: > > [ ... ] > > -- > Eric Evans > john.eric.ev...@gmail.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
