> This is a practice we developed a couple of years ago as the amount of > refactoring started to surge: basically, it should just be done in > the commit series in which you decided the refactor was needed, but it > has to be clearly broken out as a refactor commit, and the message > should include both the goal of the commit and the ticket you were > working when you ran into the refactor. >
Also, adding in a few things that 1) should be obvious when you think about it, 2) are policy (per Jesse) for code going into 2.7.x, and 3) I got burned on last winter by ignoring even when I knew better: * The refactor commits should come first, wherever possible * The existing tests should still pass after just the refactor commits; if they don't either the refactor is broken or the tests need to be updated in that commit If either of these seems unmanageably challenging, take it as a warning and not a dare. To see why, consider the case where the "refactor" breaks something that your payload commit will fix. Seems reasonable, until the payload gets reverted... and this isn't the only away things can get ugly. -- M ----------------------------------------------------------- The power of accurate observation is commonly called cynicism by those who have not got it. ~George Bernard Shaw ------------------------------------------------------------ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
