BitShares Forum
Main => General Discussion => Topic started by: theoretical on November 02, 2015, 11:11:04 pm
-
There are two deployed Graphene-based blockchains in production right now: Bitshares 2 and Muse. That number will only grow in the future. For example, at some point we would like to create a demo network which will be like a testnet, but with interesting stuff like live price feeds and (maybe later) other interesting stuff like market bots. As things stand now, I'm told it can be tough to get new users when the first thing they hear is "you have to buy lots of BTS to really experience the system." With a demo net where none of the tokens have real value, we can give away the core token, so everyone can experience how awesome Graphene is and try some of the more advanced features like creating assets, without committing to buy anything until they're ready.
Anyway, we need a way to effectively manage features which may or may not be deployed on each of the branches. To that end, we've moved to a new forking model:
https://github.com/cryptonomex/graphene/wiki/How-we-use-version-control
Be advised the master branch has been force-pushed, as I used the new forking model to help me make sure all the new features were properly tested for today's release, and there wasn't really a simple way to reconcile things without force-pushing to the master branch. We'll try not to do this often on master (develop is another matter).
The single most important item for community contributors is to please base your commits on stable.
-
Great idea! Demo accounts are the biggest reason retail traders begin trading. This could be the biggest thing for bitshares in a long time.
-
+5% This is a great idea.
-
If we will have workflow based on Pull Requests that is great! :)
On wiki there is a section:
Code review policy
It doesn't mention anything about manual testing. It is common practice (at least in projects in which I worked on) to test each PR (or "each story" like we like to call it) separately. This helps keep main branch stable, what helps in development and makes deployment almost painless.
One of the reviewers may be the author of the change.
I am not sure, whether I understand. Are you suggesting, that developer could make a "self-code-review" in this workflow?
I suggest to require at least 2 reviewers (each has to give "OK" ) and "QA Done" from tester. Like here:
(http://i.imgur.com/3VMkad4.png)
OK... you may say, that you don't have enough testers.. what is not true. I suggest to give a chance a community. I would like to help you with simple fixes and with testing...and I am sure, that there is a lot of guys like me here.
You might also think, that it would be difficult to coordinate all of that. I have already suggested (https://github.com/cryptonomex/graphene/issues/421) to use gitter for that:
(http://i.imgur.com/dP2Axbt.png)
-
Huzzah! +5%
-
Yes! We really need a demo/test network where newbies can mess around freely without a fear that they'll lose all their money.
-
Do community contributors then:
Branch off graphene/stable
And pull request to graphene/develop?
We don't have permission to push to graphene/api-123 I think
Nice work!
-
Do community contributors then:
Branch off graphene/stable
And pull request to graphene/develop?
We don't have permission to push to graphene/api-123 I think
Rather:
git clone https://github.com/cryptonomex/graphene.git
cd graphene
# create own fork on github and add as your 2nd remote
git remote add noisy https://github.com/noisy/graphene.git
# sync repos before creating new branch
git fetch --all
# create new branch based on 'stable'
git checkout origin/stable -b api-123
# make some changes
vim README.md
git add README.md
git commit -m "type in README"
# push branch to your fork
git push noisy api-123
# And the last thing.... create a pull request: noisy/api-123 to graphene/develop
If you have ANY questions about git please ask me. I am always happy to help. I consider myself as git expert :) 8) I started using it in 2008 when I worked in Opera Software, and since then... git is considered by my as the most important tool I use :)
-
demo chain is a good idea +1
-
Do community contributors then:
Branch off graphene/stable
And pull request to graphene/develop?
We don't have permission to push to graphene/api-123 I think
Rather:
git clone https://github.com/cryptonomex/graphene.git
cd graphene
# create own fork on github and add as your 2nd remote
git remote add noisy https://github.com/noisy/graphene.git
# sync repos before creating new branch
git fetch --all
# create new branch based on 'stable'
git checkout origin/stable -b api-123
# make some changes
vim README.md
git add README.md
git commit -m "type in README"
# push branch to your fork
git push noisy api-123
# And the last thing.... create a pull request: noisy/api-123 to graphene/stable
If you have ANY questions about git please ask me. I am always happy to help. I consider myself as git expert :) 8) I started using it in 2008 when I worked in Opera Software, and since then... git is considered by my as the most important tool I use :)
One part says to merge your change fork with graphene/stable, and another part of the instructions say to merge with graphene/develop.
https://github.com/cryptonomex/graphene/wiki/How-we-use-version-control
graphene/stable : Most recent common ancestor of $CHAIN/master across all chains. Preferred basis for patches, since patches written against this should apply to any chain. so graphene/stable is the basis for patches
and then it says:
All pull requests should be against graphene/stable, unless they contain code specific to some chain.However, in the workflow examples, the instructions say to:
1) create your own branch with the changes (based on graphene/stable)
2) merge your changes with graphene/develop
Merge it into graphene/develop:
git fetch graphene git checkout graphene/develop -b develop git merge graphene/api-123 git push graphene HEAD:develop3) then aftercode review merge graphene/develop to graphene/master
the documented workflow skips merging/pull-request with graphene/stable
-
One part says to merge your change fork with graphene/stable, and another part of the instructions say to merge with graphene/develop.
Sorry... typo. I have already corrected it.
-
demo chain is a good idea +1
+5%