开云体育

Neil,

Thank you for doing this. I think having a centrally-managed repo for our code is an absolute necessity to maintain the sanity of everyone involved - users and developers!

73
--
K4OSS
Charlie Ross

On Wed, Jan 3, 2018, at 01:39, Neil Martinsen-Burrell wrote:
> My uBitX arrived in the mail today and I found some time tonight to put
> together a sample of what is possible for developing our uBitX sketch on
> Github, similar to what Allard has done for the Bitx40. Farhan has
> indicated that he is looking for volunteers to help integrate patches (
> ) and tools
> like Git, GitHub, and continuous integration can make that job much more
> manageable for whoever is doing it.
>
> I forked Farhan's afarhan/ubitx Github repository at
> . As a proof of concept, I merged the
> two
> existing pull requests from Farhan's repository. Then I added some
> configuration for the PlatformIO tool that has been mentioned on this
> list
> before (
> ).
> PlatformIO allows building Arduino sketches from the command line and it
> reports many more warnings and errors than the Arduino IDE (unused
> variables, incorrect return types, incorrect type casts, see
>
> ).
>
> Finally, I added configuration for the Travis-CI.org continuous
> integration
> tool. This service is free for open-source projects and watches Github
> for
> changes and runs a test suite for the new versions. A tool like this is
> crucial when welcoming contributions from others because it provides
> some
> basic assurances that the submitted code will at least compile. As an
> example, I configured a test that fails if the Arduino code has trailing
> whitespace (yuck;
> ).
> You can see here
> that the build "failed" because there was trailing whitespace in
> Farhan's
> code, but another change in Git
>
> removed the problem and made the Travis build pass
> .
>
> I just wanted to do this to show what is possible with modern software
> engineering tools to make it easy and reliable for many people to
> contribute to the uBitX code. I'd happily welcome Ian Lee's pull request
> adding further CAT control code for the BitX, or W8TEE's change to actual
> .cpp files, or improvements to the keyer timing, or who knows what comes
> next! Then all of us together can be sure that the code meets the (minimal)
> standards that the community sets out before it gets merged with the
> "master" branch.
>
> In my dream world, Farhan could keep shipping uBitX kits with the basic
> code from his afarhan/ubitx repository, while all of us together can
> iterate new features in a ubitx-ng repository. The hope would be that new
> builders would get a working radio, but the first thing we would encourage
> them to do is to get the latest and greatest code from ubitx-ng. Like
> Allard did with the bitx40, we would maintain hardware compatibility with
> the radio as delivered and people who wanted to make hardware modifications
> could make further changes in their own repositories. (Although K3NG has
> shown with his arduino keyer that many different configurations can be
> supported in one codebase with some additional effort.)
>
> Thanks for reading this far, and I hope, whatever people decide, that uBitx
> firmware development will be rapid, reliable, long-lived, community-wide,
> and use modern software engineering tools, for all of our benefit.
>
> -Neil N0FN