On Aug 11, 2009, at 3:21 PM, James Turnbull wrote: > 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.
There's got to be some solution we can come to that allows people to develop their fixes against (and test) the default branch, right? What is that solution? To me, this means that the next release people can expect their code to be merged into has to be 'master' (which is git's default branch), but this branch can't have lots of crazy speculative development because it has to only be release-worthy code. > >> 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. In general, this shouldn't be a problem because you'll have an ordered list of branches, and as long as everything is merged in the same order you shouldn't have an issue. Or put it another way: Other projects (i.e., git and linux) have solved this problem. Are we so different that we can't? Or am I missing something? > >> 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. :) s/scotch/baby in each/ >> Next week would work well for me on that. Any other takers? >> > > Fine with me. What time would people prefer? I keep recommending the time, and it seems not to work for so many. -- I am a kind of paranoiac in reverse. I suspect people of plotting to make me happy. --J. D. Salinger --------------------------------------------------------------------- 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 -~----------~----~----~----~------~----~------~--~---
