On 01/08/12 01:08, Ashley Penney wrote: > On Tue, Jul 31, 2012 at 7:42 PM, Andy Parker <[email protected]> wrote: > >> Would that make it easier for you? The change on our end would be that >> github pull requests would just be a staging area for code and we often >> wouldn't use it for merging (which is not a big loss). > > I think that might be a positive change in that I love using pull requests for > work in progress. It's an ideal way to send something to Puppetlabs > developers > as a kind of request for feedback. If that's what you mean by staging area > for > code then I think that's probably ideal. People work in master and > then Puppetlabs > merge things back to stable branches.
I wonder what this merging back process would look like. Would you have a way to suggest a particular commit for backporting, via another ticket or some other mechanism? Would Puppet Labs be committing to backport anything that looks like a bug? As somebody who has submitted code to the "wrong" branch a number of times, I think this would be a useful change. I've submitted patches to master (that became Telly) over a year ago and it's a shame that they're still unreleased because I hadn't chosen the right branch. I was probably taking the "bug fixes only" policy of 2.7.x more literally than was actually the case. With a consistent master-first and backport policy we could follow, it might make development easier and more transparent to people wondering why changes are in one version and not another. Cheers, -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- 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.
