On 21/02/09 20:00, Luke Kanies wrote: > On Feb 21, 2009, at 2:48 AM, Brice Figureau wrote: >>> This all makes sense except for one bit: How do we track what's been >>> merged into next vs. master? >> With the redmine tickets? >> I understand that's not practical because it is out of band. > > Well, I guess we could have different statuses in the tickets. I > *think* redmine supports pretty good API-style calls with its restful > URIs, so maybe we could make some decent CLI tools for managing what's > in where.
That's a solution. >>> That is, given, say, 15 topic branches published since the last >>> release, how does the release maintainer track what's been applied to >>> next, what's been applied to master, and what's still to be applied >>> anywhere? >> Re-applying a patch won't work since it's already applied. At worst >> you >> have lost some time. > > I guess that's true; just apply them all each time, I suppose. > >>> I think it's related to the fact that the document mentions always >>> having a merge commit (as opposed to how we currently do it, where we >>> fast-forward all of our merges to explicitly avoid that merge >>> commit), >>> but a) I don't know how to force a merge commit in a fast-forward >>> situation and 2) I don't really see how it solves our problem unless >>> James is just supposed to read 'git log' all day. >> git merge -ff >> this merges with fast-forward but at the same time produces a merge >> commit. > > Um. That's awesome. A year ago I would have blustered that it was > silly to rebase and then have the merge commit, but I now clearly see > the benefit of both. Sorry, that's git merge --no-ff, but that's the meaning I intended. >> The workflow for a maintainer can be: >> $ git fecth super-duper-repository >> $ git checkout -b newfeature super-duper-repository/newfeature >> $ git rebase master >> $ git checkout master >> $ git merge -ff newfeature >> $ git branch -D newfeature > > Yep. > >>>> Clearly master will track major and middle version number X.Y >>>> Since we also wants minor version increments, we should branch >>>> master on >>>> each release with a branch named from the version and/or codename >>>> (if >>>> you still want them). >>>> Bug fixes on this releases can be: >>>> * backported from master >>>> or >>>> * applied on those branches only if the code has been >>>> changed/refactored in master >>>> Each subrelease on those branches will increase only the minor >>>> number. >>>> >>>> What this scheme can give us is: >>>> * an assurance that there are not too many changes between minor >>>> version release (unlike what we did between 0.24.5 and 0.24.6 with >>>> all >>>> the stuff I contributed). >>>> * an assurance we'll be doing more frequent middle release >>>> (0.25,0.26...) >>>> * an always (or as much as possible) stable moving forward master >>>> * more people trying the master branch (we could have a nightly >>>> build >>>> of the master tip), or running the current master. >>>> >>>> To summarize, I like the way the git dev have architectured their >>>> repositories. >>> I think this all basically makes sense; we just need to find a >>> relatively low-overhead way of doing it. >> Yes, that's the whole point :-) >> Unfortunately I'm working only on projects involving a small number of >> people working almost at the same place on a handful of branches, so >> my >> at-work git workflow is not as complex as yours (and clearly not as >> distributed). > > > And ours isn't nearly as complicated as others, but we need to make it > just a bit more complicated - although I prefer "sophisticated", it > gives a better impression. :) :-) -- Brice Figureau Days of Wonder http://www.daysofwonder.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to puppet-dev@googlegroups.com To unsubscribe from this group, send email to puppet-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
