Author Topic: Graphene vs. BitShares in GitHub  (Read 2646 times)

0 Members and 1 Guest are viewing this topic.

Offline vikram

Graphene vs. BitShares in GitHub
« on: January 16, 2017, 02:06:54 am »
I'd like some developer feedback on reorganizing the GitHub repositories.

For the most part the https://github.com/cryptonomex/ organization seems to be no longer maintained. Specifically there is no one that is maintaining issues and pull requests in https://github.com/cryptonomex/graphene and https://github.com/cryptonomex/fc. [member=11456]svk[/member] is still maintaining https://github.com/cryptonomex/graphene-ui but I think there is a possibility he will be abandoning it soon based on his approved worker proposal here: https://bitsharestalk.org/index.php/topic,23645.0.html

I've already started a new fc fork here https://github.com/bitshares/bitshares-fc which merges all applicable updates and pull requests from https://github.com/cryptonomex/fc and https://github.com/steemit/fc. BitShares will use the bitshares-fc fork moving forward.

I'd like to propose a merge of https://github.com/cryptonomex/graphene and https://github.com/bitshares/bitshares-2. The main reasons for doing so would be to bring the issue tracker into the BitShares organization where myself and other BitShares developers can maintain it, and also to avoid confusion about which of multiple issue trackers and forks BitShares users and contributors should work with.

Due to the way GitHub works, in practice such a merge would essentially involve deleting the current bitshares-2 repository, moving and renaming the graphene repository to take its place, and then restoring all missing branches, tags, and releases from the previous bitshares-2 repository into the new one.

This would also effectively mean that BitShares would become the "reference" Graphene implementation and there would be no more "pure" Graphene project. I think this would be fine, because it can be seen from the current diff between graphene and bitshares-2 at https://github.com/cryptonomex/graphene/compare/master...bitshares:bitshares?w=1 that Graphene already contains "hardfork" code as though it were already part of BitShares, and that it is already missing a number of patches that BitShares contains since nobody is maintaining it. If desired, somebody could maintain a branch downstream of BitShares that removes hardforking code, etc. that would represent a clean Graphene. I would likely do this to begin with as there are still differences for example in the testing infrastructure in Graphene vs BitShares which still need to be fixed.

Performing such a merge would also require agreement from Cryptonomex, whom I cannot speak for. If they do not want to do this or it is otherwise undesirable, an alternative would be to use the https://github-issue-mover.appspot.com/ tool to copy all issues from the graphene repo into the bitshares-2 repo. This would still leave the upstream Graphene repo and issue tracker in place though, which could still be confusing for users and contributors. It could be a reasonable middle ground if perhaps the upstream graphene issue tracker was disabled afterwards to help avoid confusion.

Any thoughts are appreciated.

[member=18687]abit[/member] [member=11]dannotestein[/member] [member=30868]kenCode[/member] [member=11456]svk[/member] [member=120]xeroc[/member]

Offline Chris4210

  • Sr. Member
  • ****
  • Posts: 431
  • Keep Building!
    • View Profile
    • www.payger.com
  • BitShares: chris4210
Re: Graphene vs. BitShares in GitHub
« Reply #1 on: January 16, 2017, 11:14:20 am »
Thank you Vikram for bringing up this issue and to actively bring up new projects in the forum. Since I am not a developer myself, I cannot give a competent suggestion how the code should be handled in the future.

But from a founder/business perspective, I want to get the latest graphene code for my project. Right now the Github channel is a bit confusing and It would be great to further clean it up.

I am looking forward to the respond of our developers on this issue.
Vote Chris4210 for Committee Member http://bit.ly/1WKC03B! | www.Payger.com - Payments + Messenger | www.BitShareshub.io - Community based fanpage for the BitShares Blockchain

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12915
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Re: Graphene vs. BitShares in GitHub
« Reply #2 on: January 16, 2017, 03:30:00 pm »
Let's abandon cnx/graphene and start working in our own organization/repo!

+5%!
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline Pheonike

Re: Graphene vs. BitShares in GitHub
« Reply #3 on: January 16, 2017, 03:43:46 pm »
Let's abandon cnx/graphene and start working in our own organization/repo!

+5%!
Agree, they in a sense abandoned bitshares.

Sent from my SM-N920T using Tapatalk


Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4473
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
Re: Graphene vs. BitShares in GitHub
« Reply #4 on: January 17, 2017, 01:02:51 am »
Let's abandon cnx/graphene and start working in our own organization/repo!

+5%!
You didn't answer the question.

Copy all the issues from cnx/graphene to bitshares/bitshares-2 repo, or remove bitshares/bitshares-2 then move the entire cnx/graphene project (with issue tracker) to bithsares org then rename it to bitshares-2?

I don't think CNX will agree to the latter, as Graphene is still a brand. Just my speculation though.
BTS account: abit
BTS committee member: abit
BTS witness: in.abit

Offline vikram

Re: Graphene vs. BitShares in GitHub
« Reply #5 on: January 17, 2017, 09:13:55 am »
Let's abandon cnx/graphene and start working in our own organization/repo!

+5%!
You didn't answer the question.

Copy all the issues from cnx/graphene to bitshares/bitshares-2 repo, or remove bitshares/bitshares-2 then move the entire cnx/graphene project (with issue tracker) to bithsares org then rename it to bitshares-2?

I don't think CNX will agree to the latter, as Graphene is still a brand. Just my speculation though.

Yeah I'm still somewhat on the fence but I'm starting to think maybe the right thing to do is use https://github-issue-mover.appspot.com/ to copy all the issues from the graphene to the bitshares repos, and then ask CNX to disable the graphene issue trackers to avoid confusion. The graphene repos would then be left as-is for historical purposes, but otherwise abandoned. Development would then continue solely in the bitshares repos with the copied issues.

Offline vikram

Re: Graphene vs. BitShares in GitHub
« Reply #6 on: January 18, 2017, 05:35:07 am »
I've gone ahead and made the following changes on GitHub:

Active developers should update their local git configurations to reflect the new repository remote URL, submodule remote URLs, and default branch. People just building from source can maybe just re-clone if they want to make it easy. Be careful not to unintentionally delete wallets, blockchain databases, or other files if you decide to reclone.

Active developers and those building from source can update their submodule remote URLs using "git submodule sync --recursive".
« Last Edit: January 31, 2017, 10:39:57 pm by vikram »

Offline ElMato

  • Sr. Member
  • ****
  • Posts: 288
    • View Profile
Re: Graphene vs. BitShares in GitHub
« Reply #7 on: January 18, 2017, 08:04:26 am »
Great work!!  +5%

Just one question.
Shouldn't we also have a local fork of this two repos?

https://github.com/zaphoyd/websocketpp.git
https://github.com/leutloff/diff-match-patch-cpp-stl

What happen if zaphoyd/leutloff got compromised in any way?

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: Graphene vs. BitShares in GitHub
« Reply #8 on: January 18, 2017, 04:28:26 pm »
Great work!!  +5%

Just one question.
Shouldn't we also have a local fork of this two repos?

https://github.com/zaphoyd/websocketpp.git
https://github.com/leutloff/diff-match-patch-cpp-stl

What happen if zaphoyd/leutloff got compromised in any way?

The submodule references a specific git commit, i. e. a hash of the tree. So we're safe as long as we don't update the submodule ref.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline Brekyrself

  • Hero Member
  • *****
  • Posts: 511
    • View Profile
Re: Graphene vs. BitShares in GitHub
« Reply #9 on: January 19, 2017, 06:02:24 am »
I do not see the ability to open issues within bitshares/bitshares-2-ui.  It still requires us to go into cryptonomex/graphene-ui to open a UI issue.  Should this be changed as well?

Offline svk

Re: Graphene vs. BitShares in GitHub
« Reply #10 on: January 19, 2017, 07:00:54 am »
I do not see the ability to open issues within bitshares/bitshares-2-ui.  It still requires us to go into cryptonomex/graphene-ui to open a UI issue.  Should this be changed as well?

It will be changed soon.
Worker: dev.bitsharesblocks

Offline Thom

Re: Graphene vs. BitShares in GitHub
« Reply #11 on: January 20, 2017, 03:15:10 am »
I didn't see this until Vikram moved ahead. Whatever you devs decide is best for you. All I ask is that you also keep noob devs in mind and make it as easy to work with as possible.

I have always been confused by the dual repos for cryptonomex & bitshares-2. So glad you're trying to clean it up. Let's remove any unnecessary points of confusion for those trying to come up to speed on the codebase.

I believe you're moving in the right direction.

Make sure you describe the active codebase in the readme.md file that appears at the top of the main tree, that it is the repo for the production BitShares blockchain, and keep it updated and relevant. It should either include basic build instructions or where to find them for example.

I kindof like the build instructions to be maintained right there at the top of the repo in the readme.md, as that is up front, in your face and serves as a reminder to update it when necessary. However, if that is too much or too complex to achieve such that a separate document is preferred, make sure the readme has a clear reference to it.

I think the different shades of the UI (light wallet, hosted, OL ...) should also be identified. I haven't built the UI in almost a year now so I don't know if the variants are in separate repos or in the same one with lots of conditional qualifiers that work against it. Good cases can be made for both approaches. 
« Last Edit: January 20, 2017, 03:20:35 am by Thom »
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html