Fix disotest

[olemke]

The disotest executable was broken by the recent changes.

[riclarsson]

Please update the checks to not allow this horrible mess to happen again. It is clear that whatever the tests that there are that are running in the background are broken.

[olemke]

Building the 3rdparty directory will be addressed in a separate PR. At least that's what I'm guessing your rant was aiming at.

[riclarsson]

You broke ARTS build for several days and there was no clear way how to remove the mess you added. This is not a good thing. There is clearly a bug somewhere in the travis setup for this to be allowed to happen. Please open the PR.

It took me half an hour to just figure out how to get the code to work so I could do any work... and it turns out it is because of your idea that I should use '--rebase'. Had I ignored your idea for how to make git work 'properly', then ARTS would have worked. So I will stop using this rebase debacle to avoid the mess that is ARTS master branch.

[lkluft]

The git workflow that we supposed works perfectly fine for thousands of open source projects. We are very happy to help you, if problems occur.

The same is true for broken ARTS builds. You could have let us known that it was "broken for days".

[olemke]

I opened PR #90 which adds the 3rdparty directory to our travis checks. I refuse the claim that the ARTS build was broken for several days. This PR fixed a compilation issue solely of the disotest executable which was only added to master by the merge of PR #80 yesterday afternoon. The fix was merged this morning.

[riclarsson]

Ok, my error. Sorry. I could only see "cdisort" errors so it looked like the cause was the several days older commit that said it added cdisort. Still, advising me to rebase into a broken build turned into a very annoying problem...

How is the number of users of github even relevant? This seems like bull. Look, I do not believe this mess with cdisort would have happened on the old SVN system. The test-build would have caught it. Clearly, Oliver had put something better in place for the SVN system than whatever this travis-thing is doing. Clearly, when that test would have realized that the code was broken, this very commit would have been made available instantaneously instead of sitting on ice for a day blocking normal work. There would be no real problems. This might be an infancy issue of ARTS on this platform, but it is still a very annoying issue. The travis-thing must work as full replacement of what Hudson did to keep things sane. It is not.

[olemke]

The reason the travis system didn't catch the build error in the 3rdparty directory is plain and simple because I did not set it up to build that directory. Hudson was always running a 'make all' since we only had a single compiler setup available anyway. Travis offers the great opportunity of compiling with a number of different compilers. Something we could not handle before due to limited resources on our build server. To keep the test times low as possible, I set it up to only compile what's necessary. For the compiler tests it would be overkill to also build the documentation directory every time. That's why that is done in a separate test. I simply missed to not only add the src directory for the compilation tests, but also include the 3rd party directory. It's fixed now. Not travis' fault. It can only test what it's set up for to test. End of story.

I understand that you're having some trouble with git at the moment and are frustrated with the situation. I would rather concentrate on helping you fixing your git workflow.

Since your newlinerecord branch is continuously causing you trouble when updating it from master and is strangely missing all merge commits as I wrote in #86, I think that is something we should concentrate on to fix. I've put together a script that clones a separate working copy, sets up the upstream remote, checks out the newlinerecord branch and pulls in all the updates from upstream, applying them cleanly with a rebase. I've also attached the full terminal output from that script. Please give it a try to run it on your system (in a temporary directory to not affect your current working directory) and see if it works or where it fails compared to my run and how it differs from your current workflow:

https://gist.github.com/olemke/b0412c2f7a68bf5e0483d64aed64c267

You can also have a look at the resulting branch here:

https://github.com/olemke/arts/commits/newlinerecord-test

You can see with this workflow, your own commits will always be applied on top of the commits from upstream master, keeping things tidy and clearly laid out.