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
-~----------~----~----~----~------~----~------~--~---
