Andy and Luke,

Thanks a lot for giving my email some thought. I appreciate it.

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.
 

> 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 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.

- 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.

Reply via email to