On 01.08.2012 13:01, Dominic Cleal wrote:
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?
The Linux kernel has a master-first policy and -stable receives anything
CC'd to the stable-maintainers list. (After a sanity check). The main
reason for such a policy seems to be that not all fixes can be
backported and it's better to miss a backport than a forward-port,
because a unfixed bug that vanishes on update is better than a regression.
Reframed for puppet, I guess that a ticket would have to have all
affected versions annotated. Then a merge in master would trigger
"someone" to backport that as required. Tickets would only be closed
when all branches have received the fix.
Best Regards, David
--
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.
