On Tue, Jul 31, 2012 at 3:40 PM, Ken Dreyer <[email protected]> wrote:
> Andy and Luke, > > Thanks a lot for giving my email some thought. I appreciate it. > > No problem. It's why I'm here :) > > On Monday, July 30, 2012 1:41:46 PM UTC-6, Andy Parker wrote: > >> The submitter doesn't have to make sure it gets up into later branches. >> We take care of that. >> > > I admit this is a bit of a tangent: I was wondering what the process was > for that. In my example pull request, the same bug is present in 2.6.x, > 2.7.x, and master. It sounds like "someone else" will propose my patch to > all these branches, and there's nothing I can do? This was one of those > things that made me guess "at least master will be safe". I wish I'd read > CONTRIBUTORS.md more closely the first time around. > I'd like it so that we don't need close readings for people to feel comfortable with contributing. It is probably still too wordy... > > >> Can you help me understand what caused the confusion? I seems like the >> policy is fairly straightforward (the earliest of the open branches). I can >> maybe see how it might be hard to know what the open branches are, but are >> there different problems that you encountered? >> > > You pointed out the biggest one: I didn't know what Puppet Labs' criteria > were for whether a branch is open or not. I thought it would be a safe > guess that "master" is open, and unfortunately I guessed wrong :) > > When I propose patches against a branch, I mentally associate the "first > branch to get the patch" with "bleeding edge". Under this model, it feels > like 2.6.x or 2.7.x would be the most bleeding edge branch, because patches > will hit it first before going anywhere else! :) > > I see now that it's really important for everyone, even the casual > contributor, to understand the lifecycle comments at the top of > CONTRIBUTING.md. And I also see now that CONTRIBUTING.md says "new features > that are breaking changes" are only allowed in master. It still feels weird > to me to have *any* patching hitting an older branch first before going > through master. > > I can see your point. Also, sometimes it is hard to see that something is a breaking change until it has been tried out in a larger context. > > I can definitely understand how a rule of "just target master" would >> really help reduce confusion for contributors. On the other hand in order >> to fix a problem, you really need to know where the problem lies. What >> version of the code shows the issue, that is the thing that needs to get >> fixed. Having everything targeted at the same branch would probably end up >> causing a lot more problems on our end related to getting code into the >> right places. >> > > Well, I'm not exactly proposing "everyone *only* target master", I'm just > saying "everyone target master first". Maybe I'm not really following what > you're saying above, but wouldn't the answer to "where does this bugfix > belong" be found with the appropriate unit tests attached on each bugfix? > Or perhaps ask that each pull request originator state "this needs to be > backported to xxx as well" ? > > The OSS projects I'm most familiar with (Fedora, OpenAFS, Apache httpd, > XBMC) all follow the master-first model, and it seems like it would be > easier for casual Puppet contributers if you could have a similar model. > > I'll have to beg forgiveness here. I'm quite new to working on OSS and kinda inherited the model that we are working with. I agree that in my background of closed source development, dealing with branches was done as target the mainline and then cherry-pick and backport onto older release branches. I looked over the model that Apache states and I think something like their model is a change that we could manage. Something like: Pull requests should be submitted against the master branch. You may also make the pull request against the release branch on which needs the change, but that is not necessary. 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). - Ken > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-dev/-/KkuAsfwI1uQJ. > > 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.
