What's up at GitHub

I can’t fast-forward merge the 2.0.6-pl2 branch into develop and it’s not a CRLF issue. Two files in the docs folder have been modified separately in both branches.

I’ve been working from the develop branch and merging in the changes of the latest release branch, which has always worked fine.

It looks like 2.0.6-pl2 has been merged into master but not develop and the history looks a little funky now. I don’t see any way to issue a usable pull request (except to the master branch, which can’t be right).

Has there been a change in strategy?

Please advise.

You cannot fast-forward the release branches into develop. Ever. You should never manually merge anything into develop. Develop and master are permanent branches; if you put a new commit it in that diverges from upstream, you well, have diverged and have a different repository at that point. The release branch or the commits that made up the latest changes on it will be merged to develop, but you going to have to wait for the actual repository to change upstream. Patience please when working with the develop, or any unstable branch in the blessed repository.

Sorry, my point wasn’t very clear. I didn’t mean to advocate direct merges into develop. I was trying to point out that the release version (pl2) was merged into master last week but still hasn’t been merged into develop. I was going by this guideline from the Integrator’s Guide::

Release branches

* May branch from: develop
* Must merge into: develop and master

I assumed that the two merges of the release branch (into develop and master) would be done at the same time. It seems wrong to have master ahead of develop in some ways and develop ahead of master in others and putting off the merge into develop is just going to increase the odds of merge conflicts. I don’t think the current merge conflicts would be there if this had been done.

Obviously, you’re right about the history given the current strategy, but it does create some problems for add-on developers and testers alike, who need, or at least would like to have, changes from both develop and the current release branches. And when we are working in a branch based on develop, it’s frustrating to see changes in master that we need but can’t have.

Patience will solve this, obviously, but it’s hard to be patient when you know there’s an existing fix for a bug that you reported because it broke your component. The fix is out there and you know how to get it and you can’t proceed with work on your component without the fix, but you can’t have it because it’s in an unmerged release branch.

Here are some thoughts on guidelines that might (or might not) help. Some may already be being followed, but if so, should be in the Integrators Guide. You’d know much better than I would what the implications would be, but as food for thought:

1. Merge release branches into develop at the same time they are merged into master (or at least the same day) - no commits to develop between the two merges.

2. Don’t commit bug fixes in the develop branch if a release branch is active unless the bugs are in new feature code.

3. Hold off on direct commits to develop if a current release branch exists that hasn’t been merged yet, commit to a feature branch instead (this might be just a bad idea).

Quote from: BobRay at Jan 09, 2011, 03:26 PM

I assumed that the two merges of the release branch (into develop and master) would be done at the same time. It seems wrong to have master ahead of develop in some ways and develop ahead of master in others and putting off the merge into develop is just going to increase the odds of merge conflicts. I don’t think the current merge conflicts would be there if this had been done.

It was supposed to be done that way; I did not do the pl2 release merges and have been ill. I’ll straighten it out ASAP.

Quote from: BobRay at Jan 09, 2011, 03:26 PM

1. Merge release branches into develop at the same time they are merged into master (or at least the same day) - no commits to develop between the two merges.

Again, this was supposed to happen. I will correct this for all future releases.

Quote from: BobRay at Jan 09, 2011, 03:26 PM

2. Don’t commit bug fixes in the develop branch if a release branch is active unless the bugs are in new feature code.

Release branches should only have bugs identified during the release phase fixed. These will make it back into develop when the release is completed. That is our process. If it’s a critical bug, it will be merged to develop immediately so folks can get on with their work. This is the intention of the process.

Quote from: BobRay at Jan 09, 2011, 03:26 PM

3. Hold off on direct commits to develop if a current release branch exists that hasn’t been merged yet, commit to a feature branch instead (this might be just a bad idea).

Definitely not; the whole point of release branches is to allow development to continue.

Sorry to hear you’ve been ill. It sounds like we’re more-or-less on the same page.

Of course I meant to say:

2. Don’t commit bug fixes in the develop branch if a release branch is active unless the bugs are in new feature code or necessary for work in the development branch to continue.

I’ll try to be more patient in the future -- not my strong suit.

It’s hard for me to know which branch to branch from to work on an add-on or book topic. The develop branch is the obvious choice, but I often find serious, but not critical bugs in a release branch, and some of those, I could submit fixes for with a pull request to the release branch. If I find the same bugs while on the develop branch, my pull requests would be to the wrong branch and would be unusable to patch the release branch, even though that’s where they belong. And, as I said, commits in the release branch seem to often be necessary for me to continue working.

Hope you’re feeling better.

Quote from: BobRay at Jan 09, 2011, 08:47 PM

It’s hard for me to know which branch to branch from to work on an add-on or book topic. The develop branch is the obvious choice, but I often find serious, but not critical bugs in a release branch, and some of those, I could submit fixes for with a pull request to the release branch. If I find the same bugs while on the develop branch, my pull requests would be to the wrong branch and would be unusable to patch the release branch, even though that’s where they belong. And, as I said, commits in the release branch seem to often be necessary for me to continue working.

This is why I believe every issue, or related set of issues, be they bug fixes or not, should be submitted as an "issue" branch. It is up to the integrators to decide when and where to merge these branches. You can always maintain your own branch and integrate whatever issues you want to. IMO, if everyone would fix issues and push their changes as issue specific branches in their fork, integration work would be much easier, and our ability to plan and execute successful releases will be increased. It also makes it easier for people to share fixes or features before they are integrated.

As for the pull request, it doesn’t ultimately matter, as the integrators should be able to handle the merge into whatever branch is necessary when/if the request is integrated. And choosing which branch to branch from, if working on individual issues should be no problem—if you are helping test a release by following the release branch, then branch off of it if you find a bug that must be fixed before release. If you are working on a feature or improvement that you intend to have included in the "next" release, then use develop.

This is a new process and we will be implementing some improvements to it based on our recent release experiences.

And yes, patience is something I remember having a lot more of at one time or another...

Quote from: OpenGeek at Jan 09, 2011, 09:44 PM

This is why I believe every issue, or related set of issues, be they bug fixes or not, should be submitted as an "issue" branch. It is up to the integrators to decide when and where to merge these branches. You can always maintain your own branch and integrate whatever issues you want to. IMO, if everyone would fix issues and push their changes as issue specific branches in their fork, integration work would be much easier, and our ability to plan and execute successful releases will be increased. It also makes it easier for people to share fixes or features before they are integrated.

Yes, I’ve always done that and I think it’s essential -- one issue per issue branch unless they’re interdependent.

As for the pull request, it doesn’t ultimately matter, as the integrators should be able to handle the merge into whatever branch is necessary when/if the request is integrated.

I was thinking that it would be important for the issue branch to be based on the branch you’re going to merge into, but I guess the odds of the same files having been modified by someone else are about equal for the develop and release branches.

And choosing which branch to branch from, if working on individual issues should be no problem—if you are helping test a release by following the release branch, then branch off of it if you find a bug that must be fixed before release. If you are working on a feature or improvement that you intend to have included in the "next" release, then use develop.

It isn’t always that simple if you’re working on an add-on that’s being git-ignored and you find a bug in the core. The fix may or may not belong in the branch you’ve branched from. It seems that the right thing to do would be to create an new issue branch based on develop or the release branch, whichever is more appropriate and fix it there, but I find it difficult to predict whether a fix should go in develop or in the release branch and by the time the pull request gets looked at, the release branch might not exist. And, in the pull request, you specify the branch you’re suggesting to pull the commit(s) into. Also, if it goes into develop after the release branch is merged, it may be a while before it’s available in a release (making the add-on not work until then). There’s that patience thing again.

Quote from: BobRay at Jan 09, 2011, 10:36 PM

It isn’t always that simple if you’re working on an add-on that’s being git-ignored and you find a bug in the core. The fix may or may not belong in the branch you’ve branched from. It seems that the right thing to do would be to create an new issue branch based on develop or the release branch, whichever is more appropriate and fix it there, but I find it difficult to predict whether a fix should go in develop or in the release branch and by the time the pull request gets looked at, the release branch might not exist. And, in the pull request, you specify the branch you’re suggesting to pull the commit(s) into. Also, if it goes into develop after the release branch is merged, it may be a while before it’s available in a release (making the add-on not work until then). There’s that patience thing again.

If you are developing add-ons, you need to use actual releases IMO. Developing add-ons on in-development code is potentially misleading and regular users can use it if a core bug interferes with the way you’ve written it. Wouldn’t you provide the workaround for the releases you are targeting with the add-on then go back and offer a bugfix to the core based on that? At that point it could be based off the release tag. I’m a little confused as to what you are trying to accomplish, cause you can’t release the add-on dependent on a core fix to the public anyway...

That would make life easier and I’ve considered it, but there may be some value in my reporting release version bugs *before* the version is released. It’s also been more common than you might think for me to find bugs that I can’t fix myself, that prevent me from working at all, and that are fixed in another branch (e.g., the bug where you couldn’t save a doc with a particular field altered). Another issue is that when things aren’t working and I can’t find anything wrong with my code -- it’s tempting to try a newer build to see if it was a bug in the core that’s been fixed. I am finding, though, that hopping from one branch to another in a single install has its pitfalls depending on what happens in the build and install.

I do often code in workarounds and move on, especially with trivial bugs like the hidemenu schema bug and a couple of minor bugs in the resource/create processor.

If I were to work strictly from released branches, would you suggest having just the master branch (since all release versions will be merged into it)? Before the new strategy, I came to think of master as too far behind to be useful, but that’s no longer true.