Luke Kanies wrote: > 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? > > Tags are only for actual releases, so that doesn't seem to apply. > > I haven't thought as much about concurrent development paths beyond > dev and stable, but in general, it seems you could easily follow > either model -- a branch named after the release (only for existing > releases, not releases yet to come), and it could be either the next- > style dynamically created branch I am leaning toward, or a built-up > over time branch. > > Either way, though, you want to minimize these as much as possible and > only ever apply critical fixes, which would probably then result in a > new release ASAP.
So perhaps I wasn't clear - branches we have are: master 0.24.x In future we might have: master 0.24.x 0.25.x 0.26.x etc What is master in this model? Stable? maint? It really isn't because stable is actually the release that's currently "stable" which is reflective of a branch - 0.25.x for example. Whilst I see your argument about asking people to checkout a branch - they are going to have to anyway - I can't see how they won't to fix a particular problem. > Then it's just a question of maintaining the list itself, making sure > you create the appropriate source commits or whatever, and > periodically rebuilding the branches, right? Actually it's more complicated than that - what about rebasing and merge conflicts? I find we have regular merge conflicts and require rebasing often - I often can't do that because I am not sure what code to edit to fix the merge conflict - so what do I do? Remove that branch? What if that branch has been in next a while and multiple people have built on code in that branch? The REST stuff for example? Do I remove that branch and all its children until it can be rebased? Strikes me as a fast way to make regular CI testing difficult and cumbersome. > I'm fine with that, you going to be able to get out of bed for this > one? :) Hey - I was out of bed and on another call - not all of us can make the call whilst lounging on the couch with a scotch in hand. :) > > Next week would work well for me on that. Any other takers? > Fine with me. James -- Author of: * Pro Linux Systems Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux)
signature.asc
Description: OpenPGP digital signature
