Updated Home (markdown)

master
f4exb 2020-02-29 23:33:09 +01:00
rodzic 634649a22c
commit f5616d766a
1 zmienionych plików z 25 dodań i 3 usunięć

28
Home.md

@ -12,9 +12,9 @@ This software is provided in the hope it will be useful. Its main goal is to pro
<h2>Guidelines to report issues</h2>
As the principal author, owner and maintainer of this software I spend a good part of my free time working on this software, and I do it (mostly) for fun and learning new things. But one thing that I can tell you is no fun, is losing time hunting bugs that I cannot reproduce.
As the principal author, owner and maintainer of this software I spend a good part of my free time working on this software, and I do it (mostly) for fun and learning new things. But one thing that I can tell you is no fun, is losing time hunting bugs that I cannot reproduce. I have more fun in developing new things, improving existing things or fixing defective things I can fix. And fun is the fuel to keep this project going.
Therefore I would like to enforce the following guidelines.
Therefore I ask you (as a User or Collaborator) to take the role of first level support. It means you have to help me and not the opposite: you have to help me understand the problem or what you think is a problem. Hence I would like to enforce the following guidelines.
<h3>Reporting compilation issues</h3>
@ -22,4 +22,26 @@ Therefore I would like to enforce the following guidelines.
<h3>Reporting run time issues</h3>
I (as an Author and Maintainer) have more fun in developing new things, improving existing things or fixing defective things than hunting bugs. Therefore I ask you (as a User or Collaborator) to take the role of first level support. It means you have to help me and not the opposite: you have to help me understand the problem or what you think is a problem.
An SDR application is complex having close interaction with hardware devices most often connected via USB and running in real time. Many things can happen that are related to your environment and the purpose is to extract what is relevant to the software itself. You may also consider an issue what is just a limitation. You must describe the conditions and scenario that leads to what you consider an issue the best possible so it can be reproduced in the Maintainer's reference environment.
<h3>Reference environments</h3>
This corresponds to the environments for which the artifacts are built. There are just two of them:
- Linux Ubuntu 18.04
- Windows 10
<h2>Continuous Integration and Delivery</h2>
At present this is done using [Appveyor](https://www.appveyor.com/) and is driven by the [.appveyor.yml](https://github.com/f4exb/sdrangel/blob/master/.appveyor.yml) file. The build is run at Appveyor premises on virtual machines which profile may be found here:
- [Linux](https://www.appveyor.com/docs/linux-images-software/) Ubuntu 18.04
- [Windows](https://www.appveyor.com/docs/windows-images-software/) with Visual Studio 2017
For every release on master branch the resulting artifacts are uploaded to the [releases section](https://github.com/f4exb/sdrangel/releases).
You can check [SDRangel project](https://ci.appveyor.com/project/f4exb/sdrangel) in Appveyor where all builds and artifacts may be consulted.
<h2>Repository branches</h2>
- master: this is the default branch and most stable. This is the branch used to produce release artifacts.
- dev: this is the development branch related to master. This can also serve as an integration branch. The continuous integration runs on this branch but artifacts stay in the CI/CD system.
- v5: this hosts SDRangel version 5 and is the tip of development. It contains latest developments and features. New features can occasionally make their way to master. However MIMO support stays specific to this branch. No artifacts are provided on this branch you will have to compile from source or build a Docker image.