I could get behind this. Basically, we want to give more people the opportunity to eyeball patches before they are merged?
--Paul On Thu, May 22, 2008 at 2:49 PM, David Lutterkort <[EMAIL PROTECTED]> wrote: > > > On Tue, 2008-05-20 at 20:40 -0500, Luke Kanies wrote: >> Hi all, >> >> James pointed me to this great discussion on workflow around git: >> >> http://kerneltrap.org/Linux/Git_Management >> >> I've been slowly arriving at Linus's conclusion -- development always >> happens in topic branches, and that development makes its way to the >> "main" branches (e.g., master and 0.24.x) by having the branch >> maintainer do the merge. > > I think that makes a lot of sense. In a similar vein, I promised on the > dev call last week to send out something about posting patches to the > mailing list. > > In an effort to increase visibility and awareness of proposed patches, > code changes, and what's going on in the code base in general, I suggest > that all patches are sent to the puppet-dev mailing list. That will also > help Luke and James vet those patches, since there's more eyeballs on > them. While patches are currently kept in trac, I feel that that doesn't > give it as much visibility as a 'send patches to puppet-dev' process. > > The process I envision is > * every patch that you want Luke/James to merge gets sent to > puppet-dev > * once the patch gathers a number of ACK's (and no NAK), Luke or > James will merge it into their offical branch. How many ACK's to > require is a matter of taste, I think getting one should be > enough for starters > * we might still want to track some info in Trac, i.e., have a bug > report open and move it through a few states as the patch gets > ACK's and is finally merged > > Maybe we should just start with requiring this process only for the > stable branch; that would help James a lot I think, since he wouldn't be > the only one responsible when a bad patch gets merged ;) > > That leaves us with the mechanics of the whole patch submission process, > and how to make that reasonably easy for Luke and James to track. Since > I am about as far from a proficient git user as you can get, I've been > trying to find some decent resources on how to do that on the LazyWeb. > The instructions for coreutils[1] and gnulib[2] look like they might be > a good starting point; at the end of the day, it boils down to > > * Patch submitter creates patch on topic branch; when ready, > create actual patch with 'git format-patch --stdout --signoff > HEAD~1 > DIFF' > * Email that to puppet-dev, best if the patch is inline in the > message, not an attachment. Alternatively, mention where that > patch can be pulled from if you have a public git repo. > * Luke or James apply the patch with git-am > > David > > [1] > http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=HACKING;hb=HEAD > [2] http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11269 > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
