From 3b15dc6a8123dcda922b738fab52c2fbf3e7a91a Mon Sep 17 00:00:00 2001 From: Dexter <61384688+DRG-developer@users.noreply.github.com> Date: Sat, 25 Jul 2020 17:16:38 +0100 Subject: [PATCH 1/3] Fixed typo, fixed caps and clarified one line more I don't know what you mean with line 86, because it's the same as, or different than. I just assumed the same as Basically i did nothing that would actually help the project, but since i don't own the skills or a pinewatch to contribute code (i can't even write a wayland compositor yet, and my only watch related projects are 2 garmin watchfaces with 8k combined downloads) ai did this, to at least help you guys with something. And i do not expect/want to appear on this list of peolle, as i did nothing useful. --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 643c3717..9de32410 100644 --- a/README.md +++ b/README.md @@ -27,12 +27,12 @@ As of now, here is the list of achievements of this project: - Time synchronisation via BLE - Notification via BLE - Multiple 'apps' : - * Clock (displays the date, time, battery level, ble connection status, heart rate and step count) + * Clock (displays the date, time, battery level, BLE connection status, heart rate and step count) * Heart rate * Motion - * System info (displays various info : BLE MAC, build date/time, uptime, version,...) + * System info (displays various info : BLE MAC adress, build date/time, uptime, version,...) * Brightess (allows the user to configure the brightness of the display) - - Supported by 2 companion apps (developpments ongoing): + - Supported by 2 companion apps (development is ongoing): * [Gadgetbridge](https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/pinetime-jf) (on Android) * [Amazfish](https://openrepos.net/content/piggz/amazfish) (on SailfishOS) - **[Experimental]** OTA (Over-the-air) update via BLE @@ -83,7 +83,7 @@ I’m not working alone on this project. First, many people create PR for this p Here are some people I would like to highlight: - [Atc1441](https://github.com/atc1441/) : He works on an Arduino based firmware for the Pinetime and many other smartwatches based on similar hardware. He was of great help when I was implementing support for the BMA421 motion sensor and I²C driver. - - [Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs than me : NimBLE, LittleVGL,… His help was invaluable too! + - [Koen](https://github.com/bosmoment) : He’s working on a firmware based on RiotOS. He integrated similar libs as me : NimBLE, LittleVGL,… His help was invaluable too! - [Lup Yuen Lee](https://github.com/lupyuen) : He is everywhere : he works on a Rust firmware, buils a MCUBoot based bootloader for the Pinetime, design a Flutter based companion app for smartphones and write a lot of articles about the Pinetime! *If you feel like you should appear on this list, just get in touch with me or submit a PR :)* From c96a53e1a8d203e18ccda24b3754037fad12a6ca Mon Sep 17 00:00:00 2001 From: Dexter <61384688+DRG-developer@users.noreply.github.com> Date: Sat, 25 Jul 2020 21:48:53 +0100 Subject: [PATCH 2/3] iOS instead of IoS --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 9de32410..95e98eed 100644 --- a/README.md +++ b/README.md @@ -72,7 +72,7 @@ Here a quick list out of my head of things to do for this project: - Measure power consumption and improve battery life - Improve documentation, take better pictures and video than mine - Improve the UI - - Create companion app for multiple OSes (Linux, Android, IoS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/). + - Create companion app for multiple OSes (Linux, Android, iOS) and platforms (desktop, ARM, mobile). Do not forget the other devices from Pine64 like [the Pinephone](https://www.pine64.org/pinephone/) and the [Pinebook Pro](https://www.pine64.org/pinebook-pro/). - Design a simple CI (preferably selfhosted and easy to reproduce). Do not hesitate to clone/fork the code, hack it and create pull-requests. I'll do my best to review and merge them :) From 8c77c8631de753a4c32bc7c79a22a1452b37f3f6 Mon Sep 17 00:00:00 2001 From: JF002 Date: Sun, 26 Jul 2020 16:15:12 +0200 Subject: [PATCH 3/3] Add doc about branches, versioning and contributions --- README.md | 7 ++++++- doc/branches.md | 12 ++++++++++++ doc/contribute.md | 24 ++++++++++++++++++++++++ doc/versioning.md | 6 ++++++ 4 files changed, 48 insertions(+), 1 deletion(-) create mode 100644 doc/branches.md create mode 100644 doc/contribute.md create mode 100644 doc/versioning.md diff --git a/README.md b/README.md index b045df46..444f52d1 100644 --- a/README.md +++ b/README.md @@ -40,12 +40,17 @@ As of now, here is the list of achievements of this project: ## Documentation ### Build, flash and debug + - [Project branches](doc/branches.md) + - [Versioning](doc/versioning.md) - [Build the project](doc/buildAndProgram.md) - [Bootloader, OTA and DFU](./bootloader/README.md) - [Stub using NRF52-DK](./doc/PinetimeStubWithNrf52DK.md) - Logging with JLink RTT. - Using files from the releases - + +## Contribute + - [How to contribute ?](doc/contribute.md) + ### API - [BLE implementation and API](./doc/ble.md) diff --git a/doc/branches.md b/doc/branches.md new file mode 100644 index 00000000..0fb8316d --- /dev/null +++ b/doc/branches.md @@ -0,0 +1,12 @@ +# Branches +The branching model of this project is based on the workflow named [Git flow](https://nvie.com/posts/a-successful-git-branching-model/). + +It is based on 2 main branches: + - **master** : this branch is always ready to be reployed. It means that at any time, we should be able to build the branch and release a new version of the application. + - **develop** : this branch contains the latest development that will be integrated in the next release once it's considered as stable. + +New features should be implemented in **feature branches** created from **develop**. When the feature is ready, a pull-request is created and it'll be merge into **develop** when it is succesfully reviewed and accepted. + +To release a new version of the application, when develop is considered stable, a **release** branch is created from **develop**. This can be considered as a *release candidate* branch. When everything is OK, this release branch is merged into **master** and the release is generated (a tag is applied to git, the release note is finalized, binaries are built,...) from **master**. + +Git flow also supports the creation of **hotfix** branches when a bug is discovered in a released version. The **hotfix** branch is created from **master** and will be used only to implement a fix to this bug. Multiple hotfix branches can be created for the same release if more than one bugs are discovered. \ No newline at end of file diff --git a/doc/contribute.md b/doc/contribute.md new file mode 100644 index 00000000..53c6ac06 --- /dev/null +++ b/doc/contribute.md @@ -0,0 +1,24 @@ +# How to contribute? +## Report bugs +You use your Pinetime and find a bug in the firmware? [Create an issue on Github](https://github.com/JF002/Pinetime/issues) explaining the bug, how to reproduce it, the version of the firmware you use... +## Write and improve documentation +Documentation might be incomplete, or not clear enough, and it is always possible to improve it with better wording, pictures, photo, video,... + +As the documentation is part of the source code, you can submit your improvements to the documentation by submitting a pull request (see below). +## Fix bugs, add functionalities and improve the code +You want to fix a bug, add a cool new functionality or improve the code? See *How to submit a pull request below*. +## Spread the word +Pinetime is a cool open source project that deserves to be know. Talk about it around you, on social networks, on your blog,... and let people know that we are working on an open-source firmware for a smartwatch! + +# How to submit a pull request ? +Your contribution is more than welcome! + +If you want to fix a bug, add a functionality or improve the code, you'll first need to create a branch from the **develop** branch (see [this page about the branching model](./branches.md)). This branch is called a feature branch, and you should choose a name that explains what you are working on (ex: "add-doc-about-contributions"). In this branch, try to focus on only one topic, bug or feature. For example, if you created this branch to work on the UI of a specific application, do not commit modifications about the SPI driver. If you want to work on multiple topics, create one branch per topic. + +When your feature branch is ready, make sure it actually works and do not forget to write documentation about it if necessary. + +Then, you can submit a pull-request for review. Try to describe your pull request as much as possible: what did you do in this branch, how does it work, how is it designed, are there any limitations,... This will help the contributors to understand and review your code easily. + +Other contributors can post comments about the pull request, maybe ask for more info or adjustements in the code. + +Once the pull request is reviewed an accepted, it'll be merge in **develop** and will be released in the next release version of the firmware. \ No newline at end of file diff --git a/doc/versioning.md b/doc/versioning.md new file mode 100644 index 00000000..b08af714 --- /dev/null +++ b/doc/versioning.md @@ -0,0 +1,6 @@ +# Versioning +The versioning of this project is based on [Semantic versionning](https://semver.org/) : + + - The **patch** is incremented when we fix a bug on a **released** version (most of the time using a **hotfix** branch). + - The **minor** is incremented when we release a new version with new features. It corresponds to a merge of **develop** into **master**. + - The **major** should be incremented when a breaking change is made to the application. We still have to define what is a breaking change in the context of this project. For now, I suggest that it stays **0** until we have a fully functionning firmware suited for the final user. \ No newline at end of file