It sounds like this change in process is getting a lot of support. I've talked to a couple of the people here at Puppet Labs about it and they are on board, too.
I think the big remaining question is how to track where the patch needs to be applied. The master branch is a given. The ticket already has a field for affected version and target version, but that doesn't allow us to have multiple target versions and track them independently. I guess the problem I'm thinking of is one that we currently have. Namely, in the current workflow we have "Merged - Pending Release" which after a release of the target version changes to "Closed". We cannot track right now (as far as I know) that it has been fixed in 2.7.x and released as 2.7.22, and fixed in 3.0.x but not yet released. I guess we could handle that by having a ticket for each release that is affected, but I'm a little worried about the overhead of tracking that, but if is what is needed we can at the very least try it out. On Wed, Aug 1, 2012 at 4:43 AM, David Schmitt <[email protected]> wrote: > > 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. > -- 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.
