mavlink / qgc-dev-guide

QGroundControl Developers Guide
https://dev.qgroundcontrol.com/en/
Other
42 stars 51 forks source link

Getting Started Guide for Ubuntu 16.04 #78

Closed isarota closed 4 years ago

isarota commented 4 years ago

I've tried to build QGC on my Ubuntu based computer and I faced lots of guidance problems. Then I decided to prepare a stable guide that any developer can easily build QGC on an Ubuntu based computer.

hamishwillee commented 4 years ago

Thanks @isaimadoglu - appreciated.

I'll leave it to @DonLakeFlyer to decide on what he wants to do. I just have a few points:

  1. I've run the official instructions lots of times and they work fine. That said, I wrote them, so not surprising I can follow them.
  2. Having duplicate docs is a maintenance burden. Not opposed to splitting out instructions for different OS, but should be agreed that is the plan for all OS. i.e. one set of docs for installation, not multiples.
  3. If we aren't splitting out, would be good to understand what the pain points of current instructions are.
isarota commented 4 years ago

Thank you @hamishwillee for your response, I can say that the document which is current is good and it works. As I am a starter of QGC, everything is blurry for me and I need a clear document with sorted instructions so as to I can be sure that I am on the right way.

I just want to point out some problems here:

So, in any case QGC is dependent on some specific versions of programs, it makes things harder int the starting point. I think that we can make guidance simpler.

DonLakeFlyer commented 4 years ago

If there is something missing from the existing docs then they should just be updated. I don't see a need for another completely separate set of instructions.

isarota commented 4 years ago

Okay, if it's proper to do like that for the presentation of guide, I'm closing this Pull Request. @hamishwillee and @DonLakeFlyer thank you for your quick responses.

hamishwillee commented 4 years ago

Hi @isaimadoglu

In summary, we're consciously sacrificing ease-of-use for an approach we know can be maintained and kept up to date more easily.

If we had more time and fewer updates we'd probably have gone with something what you did. Thanks again for your contribution!