On Jul 28, 2012, at 2:04 PM, Ken Dreyer <[email protected]> wrote:
> 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.) I think the main reason we do it this way is that it's almost always safe to merge up but you can never merge down, which means that if you always merge into master first, your only choice is to cherry-pick, rather than just merging. I'm not saying that's right, but that is my understanding of the reasoning. > 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. How do they naturally trickle down? It seems like it'd be harder to remember to get all of them then just a periodic merge up. > 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. That's absolutely true, but we release from stable branches far more often than from master because the community has been clear that new full releases every three months would be a bit overwhelming. > 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 :-) Those are definitely the most compelling reasons for me - I know Andy Parker and the team is working hard to make it easier to contribute. I'd look to him to comment on whether this can be changed, since it's in their court now. -- Luke Kanies | http://about.me/lak | http://puppetlabs.com/ | +1-615-594-8199 -- 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.
