I recently opened my first pull request [1], against master. After re-reading CONTRIBUTORS.md I see that Puppet prefers to merge bug fixes into the earliest branch first (eg 2.6.x or 2.7.x), rather than master first. I thought this might be a problem for my merge request, and so Dominic in IRC suggested that I re-submit a new merge request against an earlier branch instead. Ouch.
I'm wondering why Puppet doesn't have a "master first" policy? It seems like this would fit with the way that most other software projects work. Get everything into master first, then backport bits and pieces into stable branches. (Of course if a bug fix *only* applies to an old branch like 2.6.x, that wouldn't be committed to master, and it could just go to 2.6.x directly... but I imagine those cases are few and far between.) There are a couple advantages that come to mind: 1. Bug fixes naturally "trickle down", rather than trying to remember to merge everything against the natural flow of new development. 2. Reduce effort for release managers: When everyone commits to master first, master moves faster and it's more straightforward to cut brand new major releases from master. 3. Reduce effort for the bug fixers: if a casual bug fixer only cares that it's fixed "eventually", he or she can get it into master, and then backport when he or she has extra time available. With the current submission model, the submitter must make an effort to get it into an old branch, plus the effort to get it "up" into master, or else risk having his or her fix disappear in new major releases. 4. Help reduce confusion for newbies like myself :-) - Ken [1] https://github.com/puppetlabs/puppet/pull/979 -- 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.
