Hi all, Yesterday Paul had a question about when to do small scale refactoring (I.e., a commit or three), given that it wouldn't be associated with a single ticket. I figured I'd share what I told him.
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. Note that tis has been the functional policy of Puppet for at least two years, and AFAIK it has never been officially changed, so it should IMO be the policy of all of our projects. The main edge case is when the refactor is entirely orthogonal to the ticket work, but essentially you just have to make your call as to whether it's an appropriate use of your time. My sense is that there are a *lot* of small refactors that could be done relatively simply that could have a big impact and be totally worth it, but are not worth opening tickets for. If you don't fix those inline, they'll never get fixed. -- http://puppetlabs.com/ | +1-615-594-8199 | @puppetmasterd -- 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.
