On Aug 10, 2009, at 6:52 PM, James Turnbull wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Luke Kanies wrote:
>>> Thoughts? Doctrinal arguments?
>>
>> IMO, 'master' should always be the branch we expect people to submit
>> code against, which to me means stable.
>
> How do we distinguish development branches from stable branches? Of
> which we might have multiple - for example 0.24.x, 0.25.x, 0.26.x -
> whilst I don't envisage much development on some of these we do need
> to
> be able to go back and say apply a security-related patch. How do
> we go
> back in this model? Check-out a tag? Apply the patch and tag again?
>
>> I think we should move to the often-recreated 'next' branch as we
>> discussed, probably with an additional 'dev' branch, so we can try
>> code out in one of these branches for a while and remove it if it
>> doesn't work (without having to revoke code).
>
> And you know my thoughts on this - I think it's complex and unwieldy
> and
> I note we rarely have needed to revert code. There are a handful of
> instances where we've needed to do this. It also means two separate
> methodologies - one for those of us with Git repos and one for
> stand-alone patches and diffs (of which there are many).
I didn't address the need to revert code -- I actually think there are
a *lot* of cases where we merge code and then quickly find it's not
actually what it should be. It's just that our current process makes
code reversion a real pain, so we don't do it, and instead we merge
new commits over the top.
I think this complicates a lot of our solutions, and in particular
tends to unnecessarily segment development of new features or major
refactors -- we do a chunk of work, it looks good and gets merged,
then reality kicks in and we start layering new patches on top. If,
instead, we could modify that commit series and rebuild the branch,
then you'd be looking at the whole series at a time, rather than just
being in a position of layering.
This actually came up a ton for me over the course of the last year.
Something seems like a good idea, but the initial implementation isn't
fleshed out. Sometimes it'd be much easier to actually revert the
code and save it for a later release, but instead of being able to do
that my only choice is to spend a bunch of time fixing code that was
probably not actually ready for prime time (or do a big ugly code
revert).
So, for me, I think it's a pretty big deal.
--
It is odd, but on the infrequent occasions when I have been called upon
in a formal place to play the bongo drums, the introducer never seems
to find it necessary to mention that I also do theoretical physics.
-- Richard Feynman
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
