PBSA Bounty - 1 : Core-Wallet Builds

Description

PBSA is looking to improve the documentation and release consistency of the Peerplays-Core Wallet. We want to know how to compile and build the wallet for the windows/linux/macosx operating systems. 

Details

  • The wallet essentially has 3 layers (dl, electron, web). As per the README instructions, each of these directories need to be installed in a particular order before the app can be run/compiled/release
    • The wallets release artifacts are being built with the gulpfile located in '/electron/gulpfile.js' and '/electron/tasks/release.js'
      • This file queries the OS to determine which OS is being used, and builds an executable for that operating system
      • When trying to force the "windows" build on a mac, gulpfile throws an error.
  • The issue as observed by PBSA devs is that the wallet requires PBSA devs to go through the build / release process on MacOSX, Linux (Ubuntu) and Windows (10) separately to generate the release files.
    • We would like to be able to build / release future iterations of the wallet without having to log into the separate operating systems.

Suggestions




Reward

$500 USD

PBSA will payout the equivalent USD value in BTC.

The reward value is based on urgency, severity and perceived difficulty.

Once the reward value has been published, it will not change.

Future bounties are subject to change based on market fluctuations and changing requirements.




Grading Process

All solutions are evaluated on a first come first serve basis.

PBSA will choose the first solution that meets ALL of the requirements. 


Our evaluators adhere to the following process when evaluating a submitted solution.

  1. Evaluate Requirements - Enter Process
    1. Select next chronological requirement - GOTO Step 1b
    2. Evaluate requirement - GOTO Step 1c
    3. If Requirement doesn't meet the definition of done, reject the solution and give reasonable feedback to the submitter - Exit Process
    4. If Requirement meets the definition of done, accept the requirement and ...
      1. If Requirement is the last requirement in the list and all requirements have met the definition of done - GOTO Step 2a
      2. If Requirement is not the last requirement, evaluate the next chronological requirement - GOTO Step 1a
  2. Closure & Acceptance
    1. Immediately inform the community of that the bounty has been closed and a solution has been accepted by the team - GOTO Step 2b
    2. Reach out to the individual/group that submitted the solution for notification of acceptance - GOTO Step 3a
  3. Reward
    1. Distribute the reward to the appropriate group/individual - Exit Process




Requirements

RequirementDescriptionAcceptance Criteria / Definition of Done
Modify the READMEModify the README.md to include instructions specific to how to build and distribute the wallet in the respective operating systems
  • The README clearly articulates how to build and compile the wallet into a .exe, .dmg and .deb file
  • The instructions given are repeatable by PBSA devs
Modify the Gulp/Electron PipelineThe pipeline may require modification in order to get the build pipe to generate a stable .exe, .dmg and .deb build.
  • Config modifications result in stable build
  • Code is neat and tidy
  • Code is commented when necessary
Executables are functionalEach of the executable files can successfully be run on multiple platforms.
  • .dmg can be run on at least OSX 10.12 - 10.13
  • .exe can be run on at least Windows 10
  • .deb can be run on at least Ubuntu 16.04




How to Submit

Submit To: Github Repo Pull Request

We will use your GitHub account that you used to submit your solution to contact you in the event that your solution is selected as the winner of the bounty.

  • Must contain README.md describing how to run your solution (If standalone codebase)
  • Must contain instructions on how to run the code (If PR inside existing codebase)
  • Must contain your PPY account


Questions

All questions can be forwarded to bounty@pbsa.info

Disclaimers

  • PBSA reserves the right to accept or reject solutions for the following reasons (When Applicable)
    • Incomplete Solution
    • Requirements do not meet the definition of done
    • Incomplete or poorly written documentation
    • Low Quality Code 
      • Debug Console Logs
      • Not following coding standards
      • Inefficient solution
    • Cannot Build/Run Solution
    • Incomplete submission
      • Missing supporting documents
    • Late submissions
  • Once a solution has been picked as the valid solution, all other submissions will be discarded