master first?

[Ken Dreyer]

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

[Ashley Penney]

I promised to +1 this on IRC. I find the current setup a little
confusing and I expected master to be the primary source of
development with specific fixes being backported to stable releases by
Puppetlabs. This would seem more 'normal'. Having to development
against old branches and hope someone merges them up eventually feels
weird. It definitely confused me.

[Luke Kanies]

On Jul 28, 2012, at 2:04 PM, Ken Dreyer <ktdr...@ktdreyer.com> 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

[Andrew Parker]

On Jul 29, 2012, at 2:41 PM, Luke Kanies wrote:

> On Jul 28, 2012, at 2:04 PM, Ken Dreyer <ktdr...@ktdreyer.com> 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.
>

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

The submitter doesn't have to make sure it gets up into later branches. We take care of that.

>> 4. Help reduce confusion for newbies like myself :-)

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?

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

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.

>
> --
> 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 puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>

[Ken Dreyer]

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

[Andy Parker]

On Tue, Jul 31, 2012 at 3:40 PM, Ken Dreyer <ktdr...@ktdreyer.com> 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.

[Ashley Penney]

On Tue, Jul 31, 2012 at 7:42 PM, Andy Parker <an...@puppetlabs.com> 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 guess I'd like to see github become more of a back and forth on git pulls at
earlier stages rather than just being where you issue a pull request
for complete
and finished patches, so this change would play nicely with that.
Plus sometimes
the code changes between the tip of development and stable branches can be
fairly significant so it makes sense that people always work against development
and then that work is merged back if appropriate. It seems confusing to try to
develop against the oldest branch and then make Puppetlabs do a bunch of
work to merge it into newer and newer branches.

[Ken Dreyer]

On Tue, Jul 31, 2012 at 5:42 PM, Andy Parker <an...@puppetlabs.com> wrote:
> 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?

Yes, this would be excellent!

On Tue, Jul 31, 2012 at 6:08 PM, Ashley Penney <ape...@gmail.com> wrote:
> It seems confusing to try to
> develop against the oldest branch and then make Puppetlabs do a bunch of
> work to merge it into newer and newer branches.

I agree; it would allow more people to share the workload, and I
imagine it would make release engineering easier for the Puppet Labs
folks.

- Ken

[Dominic Cleal]

On 01/08/12 01:08, Ashley Penney wrote:
> On Tue, Jul 31, 2012 at 7:42 PM, Andy Parker <an...@puppetlabs.com> 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?

As somebody who has submitted code to the "wrong" branch a number of
times, I think this would be a useful change. I've submitted patches to
master (that became Telly) over a year ago and it's a shame that they're
still unreleased because I hadn't chosen the right branch. I was
probably taking the "bug fixes only" policy of 2.7.x more literally than
was actually the case.

With a consistent master-first and backport policy we could follow, it
might make development easier and more transparent to people wondering
why changes are in one version and not another.

Cheers,

--
Dominic Cleal
Red Hat Consulting
m: +44 (0)7817 878113

[David Schmitt]

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 <an...@puppetlabs.com> 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

[Andy Parker]

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.

> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

[Andy Parker]

On Wed, Aug 1, 2012 at 4:01 AM, Dominic Cleal <dcl...@redhat.com> wrote:
>
> 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?
>

Good question. Right now I'm thinking that we would try to backport,
but if it turns out to be non-trivial we might push it back to the
submitter and ask for a patch against the older branch. As David said,
missing a backport is less of a loss than missing the forward-port.

> As somebody who has submitted code to the "wrong" branch a number of
> times, I think this would be a useful change. I've submitted patches to
> master (that became Telly) over a year ago and it's a shame that they're
> still unreleased because I hadn't chosen the right branch. I was
> probably taking the "bug fixes only" policy of 2.7.x more literally than
> was actually the case.
>

I have also submitted to the wrong branch many times :) You might have
been taking the "bug fix only" policy very literally, but I'd also
like to see us really try to take it much more literally. It seems
like a lot of feature changes kept happening on what was supposed to
be a branch that just got more and more stable. On the other hand we
weren't trying to follow semantic versioning at that time, so the 3rd
number in the 2.7 versions didn't really mean bugfix releases.

> With a consistent master-first and backport policy we could follow, it
> might make development easier and more transparent to people wondering
> why changes are in one version and not another.
>

I hope it makes it easier :)

> Cheers,
>
> --
> Dominic Cleal
> Red Hat Consulting
> m: +44 (0)7817 878113
>
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.

[David Schmitt]

On 2012-08-01 22:22, Andy Parker wrote:
> 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.

Perhaps it's enough to mark tickets as "needs backporting" separately?
Or have a separate "Backport Status" field that goes "Unknown" ->
"Required" -> "Merged" -> "Released" or "Unknown" -> "Unnecessary".




Best Regards, David

[Andy Parker]

So I was about to go and update the CONTRIBUTING.md again and felt
that it was a little frustrating that I was going to need to make the
change for puppet on several branches and for facter on several
branches. So I'm thinking of cutting down the file in the repo to
pretty much just the summary, which should be pretty static (even
remove the branch information since that will keep changing) and then
include a link to a page on the wiki that has the fleshed out
information (along with the current lines of development). I found
http://projects.puppetlabs.com/projects/puppet/wiki/Development_Lifecycle
which seems to be about the right place, but I need to find out if
other projects at puppet labs are trying to use that page (I notice
dashboard is referenced there).

[Andy Parker]

Ok, so based on what has been talked about here and my frustration
I've put together another change for
the CONTRIBUTING.md.

https://github.com/puppetlabs/puppet/pull/995

I took out a lot of the verbiage and cut it down to what I think is
the essence. A lot of the things that it used to
say I'm going to move to the wiki, but that hasn't been done yet. My
question is, does this new one look like it
is clear and concise? Does this look like a policy that would help
people feel like they can get in and contribute
with confidence that they are doing it in a way that is helpful?

[Stefan Schulte]

On Wed, Aug 01, 2012 at 03:46:09PM -0700, Andy Parker wrote:
> Ok, so based on what has been talked about here and my frustration
> I've put together another change for
> the CONTRIBUTING.md.
>
> https://github.com/puppetlabs/puppet/pull/995
>
> I took out a lot of the verbiage and cut it down to what I think is
> the essence. A lot of the things that it used to
> say I'm going to move to the wiki, but that hasn't been done yet. My
> question is, does this new one look like it
> is clear and concise? Does this look like a policy that would help
> people feel like they can get in and contribute
> with confidence that they are doing it in a way that is helpful?
>

How does the situation now looks for someone who wants to merge code?
Let's say there is a request to pull ticket/master/foo into master. If I
get it right I would first merge the code into the master branch and if
I don't do anything afterwards the new code will be present in the next
major release (so when 3.1.x is created I guess) and not earlier.

If the change needs to be backported to older branches how does this
work? If I checkout 2.7.x and cherry-pick commits from the master
branch the history of 2.7.x does not say which commit belongs to which
old feature branch right (no merge commits)? Or would I copy the branch
ticket/master/foo as ticket/2.7.x/foo and use git rebase with --onto
2.7.x and then merge ticket/2.7.x/foo into 2.7.x?

-Stefan

[Ken Dreyer]

On Sat, Aug 11, 2012 at 9:03 PM, Stefan Schulte
<stefan....@taunusstein.net> wrote:
> If the change needs to be backported to older branches how does this
> work? If I checkout 2.7.x and cherry-pick commits from the master
> branch the history of 2.7.x does not say which commit belongs to which
> old feature branch right (no merge commits)? Or would I copy the branch
> ticket/master/foo as ticket/2.7.x/foo and use git rebase with --onto
> 2.7.x and then merge ticket/2.7.x/foo into 2.7.x?

Speaking for myself, your second option sounds good to me. It seems
like would best fit with what Puppet's already doing (tracking code
reviews using explicit merge commits.)

- Ken

[Andy Parker]

On Sat, Aug 11, 2012 at 8:03 PM, Stefan Schulte
<stefan....@taunusstein.net> wrote:
> How does the situation now looks for someone who wants to merge code?
> Let's say there is a request to pull ticket/master/foo into master. If I
> get it right I would first merge the code into the master branch and if
> I don't do anything afterwards the new code will be present in the next
> major release (so when 3.1.x is created I guess) and not earlier.
>

What we have been doing is immediately trying to figure out which branches
the change needs to be on and rebasing to that and then merging up. For example,
a PR for a bug that is found in 2.7.18 is submitted against master. We
determine that
the fix is good for 2.7.x (because of low impact on other things) and
so apply the PR to
a topic branch of 2.7.x and merge it in, then we merge up through 3.x
and master.

You do touch on something that I've been wondering about. We somehow have ended
up with a 3.x branch, which would mean that master is really the 4.x
branch. I don't see
any point on us trying to work on 4.x when there isn't even a 3.x
release yet. Would anyone
be opposed to us getting rid of the 3.x branch? I think the flow would
then be that topics
merge onto master. At a release point we would merge master onto a
"3-stable" (or something,
I'm not sure about the name, 2.7.x is essentially 2.7-stable). Points
along "3-stable" would be
tagged as 3.0.0rc1, 3.0.0, 3.0.1rc1, etc.This is essentially the
stable/development strategy
for branching that gets talked about, I believe.

> If the change needs to be backported to older branches how does this
> work? If I checkout 2.7.x and cherry-pick commits from the master
> branch the history of 2.7.x does not say which commit belongs to which
> old feature branch right (no merge commits)? Or would I copy the branch
> ticket/master/foo as ticket/2.7.x/foo and use git rebase with --onto
> 2.7.x and then merge ticket/2.7.x/foo into 2.7.x?
>

I think your second one is what would be best. That would keep a merge
commit to more
easily track the history. Of course, if it is just one or two commits
that are being
cherry-picked from another branch, then I see no need for that and I
think it is perfectly
reasonable to go ahead without the topic branch and merge commit.

> -Stefan

[Ken Barber]

> You do touch on something that I've been wondering about. We somehow have ended
> up with a 3.x branch, which would mean that master is really the 4.x
> branch. I don't see
> any point on us trying to work on 4.x when there isn't even a 3.x
> release yet. Would anyone
> be opposed to us getting rid of the 3.x branch? I think the flow would
> then be that topics
> merge onto master. At a release point we would merge master onto a
> "3-stable" (or something,
> I'm not sure about the name, 2.7.x is essentially 2.7-stable). Points
> along "3-stable" would be
> tagged as 3.0.0rc1, 3.0.0, 3.0.1rc1, etc.This is essentially the
> stable/development strategy
> for branching that gets talked about, I believe.

The extra 3.x branch is confusing and slightly superfluous agreed, at
least until you attempt to gain stability for a 3.0.0 release by
cutting the rc branch. So +1 for removing it.

ken.

[Stefan Schulte]

On Mon, Aug 13, 2012 at 08:59:52AM -0700, Andy Parker wrote:
> On Sat, Aug 11, 2012 at 8:03 PM, Stefan Schulte
> <stefan....@taunusstein.net> wrote:
> > How does the situation now looks for someone who wants to merge code?
> > Let's say there is a request to pull ticket/master/foo into master. If I
> > get it right I would first merge the code into the master branch and if
> > I don't do anything afterwards the new code will be present in the next
> > major release (so when 3.1.x is created I guess) and not earlier.
> >
>
> What we have been doing is immediately trying to figure out which branches
> the change needs to be on and rebasing to that and then merging up. For example,
> a PR for a bug that is found in 2.7.18 is submitted against master. We
> determine that
> the fix is good for 2.7.x (because of low impact on other things) and
> so apply the PR to
> a topic branch of 2.7.x and merge it in, then we merge up through 3.x
> and master.
>

So the merges up 2.6.x -> 2.7.x -> 3.x -> master is still happening in the
future? I'm just wondering if I merge a topicbranch into master and then
rebase the topic branch to merge it into 2.7.x everything will be ok. But
if you now merge 2.7.x into master you will end up with two identical commits
(buts different SHA hash) in master right?

-Stefan

[Jeff McCune]

On Mon, Aug 13, 2012 at 2:55 PM, Stefan Schulte <stefan....@taunusstein.net> wrote:

On Mon, Aug 13, 2012 at 08:59:52AM -0700, Andy Parker wrote:
> On Sat, Aug 11, 2012 at 8:03 PM, Stefan Schulte
> <stefan....@taunusstein.net> wrote:
> > How does the situation now looks for someone who wants to merge code?
> > Let's say there is a request to pull ticket/master/foo into master. If I
> > get it right I would first merge the code into the master branch and if
> > I don't do anything afterwards the new code will be present in the next
> > major release (so when 3.1.x is created I guess) and not earlier.
> >
>
> What we have been doing is immediately trying to figure out which branches
> the change needs to be on and rebasing to that and then merging up. For example,
> a PR for a bug that is found in 2.7.18 is submitted against master. We
> determine that
> the fix is good for 2.7.x (because of low impact on other things) and
> so apply the PR to
> a topic branch of 2.7.x and merge it in, then we merge up through 3.x
> and master.
>

So the merges up 2.6.x -> 2.7.x -> 3.x -> master is still happening in the
future?

Yes

 

I'm just wondering if I merge a topicbranch into master and then
rebase the topic branch to merge it into 2.7.x everything will be ok.

It won't be OK, don't do this. =)

If the topic branch is meant to go into 2.7.x, then don't merge it into master.  Instead, merge the topic branch into 2.7.x (may need to be rebased) and then merge up into master to get the topic branch into master.

Make sense?

-Jeff

[Jeff McCune]

There are not presently any commits in master that aren't also in 3.x.

The thing to keep in mind is that as soon as we release 3.0.0 we'll establish both 3.x and 3.0.x.  3.0.x will merge up into 3.x and 3.0.x will be for bug fixes, 3.x will be for backwards compatible features.  master will be for backwards incompatible changes.

So, even if we remove it today it's just going to com back.

With that said, I'll go ahead and get rid of 3.x this week.  Look for another email to puppet-dev when I get around to it.  It'll probably be Wednesday at this point.

-Jeff

[Jeff McCune]

On Mon, Aug 13, 2012 at 3:43 PM, Jeff McCune <je...@puppetlabs.com> wrote:

With that said, I'll go ahead and get rid of 3.x this week.  Look for another email to puppet-dev when I get around to it.  It'll probably be Wednesday at this point.

Just to follow up on this, I've decided not to get rid of the 3.x branch.  There's a lot of momentum behind it right now and I don't think the energy required to change direction is worth the confusion this branch may be causing.  The energy I'm speaking of takes the form of communicating to everyone not use the branch anymore, changing all of our CI jobs, etc...

We'll be doing merge-ups regularly and we're handling that process pretty well.  Pull requests can target master and we'll take care of applying the change set to the correct branch.

There's not much of a difference between 3.x and master, so even if you're confused about which one to base your work on, there isn't a wrong or bad choice between the two until Telly ships.

-Jeff