On Oct 20, 2010, at 9:39 AM, Markus Roberts wrote:
>
> 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
Definitely.
> 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.
--
Seize opportunity by the beard, for it is bald behind.
-- Bulgarian Proverb
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
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.
