>> Our idea is to have the topic branches be rebased in succession onto >> testing (which is a mercurial/throwaway branch), producing a clean >> series of commits that can be tested and the prefix of which can be >> promoted to master once it is deemed worthy. > > Are there any examples of what you're planning to do up somewhere Markus? > > We've recently moved all the Debian packaging to use git-buildpackage > (which is brilliant), but relies heavily upon being able to merge, and > I'm not quite clear from your descriptions above whether we'd still be > able to do this.
I don't think that should be affected--hedged, because this is all speculative at the moment--as I'm only concerned here with the process of funneling long-lived topic branches (agressive bug fixes, new features, extensive refactorings) through testing and into master. The basic idea is this: * We have in the queue a bunch of modifications that make sweeping changes to the system (architectural changes, internal data path refactorings, global renamings, code smell reductions, etc.). * They form a forest of dependencies, with some subsets having structured relationships (it makes no sense to do H without F and G, and J is an alternative implementation of H) and others being completely orthogonal. * Many of them touch intersecting sets of lines * None of them have been extensively tested * We'd like to start putting these together into a coherent, testable build * We'd like to reserve the right to remove / reorder / rework parts and try again * We don't want the resulting change history to look like a bowl of noodles So: * We are writing a rake task to take a list of branches and a set of sanctioned resolutions for potential conflicts and build a mercurial testing branch on top of master which applies these changes in a controlled, coherent order. * The branch should be creatable by anyone who wants to play with it, and then thrown out when they've seen what they came to see * At any time that some prefix of this branch is deemed sound it can be applied to master as a fast-forward and removed from the list of testing branches (though the results should be roughly the same even if it is not removed). * My present inclination is that this testing branch should be constructed as a single linear branch from master, with no merge commits either created in the process or absorbed from the component branches * There may be extensive rebasing, squashing, cherry-picking, amending, reordering and other shenanigans going on in the testing cycle * Once things actually make it to master it should be business as usual, with no rewriting of history or playing games with the space time continuum. -- Markus -- 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.
