BitShares Forum
Main => Stakeholder Proposals => Topic started by: vikram on November 06, 2016, 12:13:42 am
-
This proposal is based on my original thread here: https://bitsharestalk.org/index.php/topic,23474.msg300044.html#msg300044
Soledger Inc. (https://www.soledger.com/) (myself and @Agent86) is proposing a BitShares worker for handling administrative and maintenance tasks including--but not limited to--the following:
- Emergency security patches
- Emergency network stability patches
- Merge upstream Graphene, fc, other library updates
- Fix important compilation and compatibility issues
- Tag core releases
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
I have prior experience with all of these tasks from when I was project manager of BitShares 1.
We think it's important that a specific party maintains responsibility for addressing any emergency issues that disrupt the ongoing stability and operations of the network. In addition, it is my experience that it is helpful to have an unambiguous project administrator to act as a clear point of contact to help coordinate community contributions, avoid fragmentation of community efforts, and generally help keep things organized so that important information is readily accessible.
Taking into account that the BitShares codebase is reasonably stable at present, we have chosen a pay rate of 10,000 BTS/day for this worker. At a conservative exchange rate of $0.004/BTS, this is roughly $1200/month or $14,500/year. $0.004/BTS currently corresponds roughly to a market cap of $10.3 million. At the time of posting, the current price is around $0.0045/BTS and market cap $11.6 million.
For comparison, here are the most recent expired workers:
(https://i.sli.mg/2wfI6v.png)
This Soledger worker has been defined to last until 2017-12-31. For those who want to approve this worker, please choose the correct version that expires in 2017, instead of my first attempt that was mistakenly set to expire in 2016:
(https://i.sli.mg/8tospr.png)
If and when this worker is approved, I will request full administrative permissions for the BitShares GitHub organization (https://github.com/bitshares/). Upon acquiring said permissions, I will begin to perform any reorganization/cleanup/updating that I see fit, in line with the tasks outlined in the initial bullet points.
Edit: Given the decentralized nature of the greater BitShares project, I think it is important that currently active community leaders hold some administrative authority, and so if I am given GitHub admin permissions, I will also look into adding other admins: @xeroc and @svk are two names that come to mind.
Thank you to all stakeholders for your consideration.
-
Transaction confirmed
#b6f2f6208ac7152a709505e29f15996262d9efc0@11138682
Bunkerchainlabs-com supported.
-
- Emergency security patches
- Emergency network stability patches
Would you be responsible for coding these patches, should the need arise?
We have chosen a pay rate of 10,000 BTS/day for this worker. At an exchange rate of $0.004/BTS, this is roughly $1200/month or $14,500/year.
This example is a bit misleading, since the current exchange rate is actually more than 12% higher than your example. Imagine if you were interviewing for a job, and you didn't bother to mention that you expected your pay to be 12% higher than discussed. :)
This Soledger worker has been defined to last until 2017-12-31.
A full year strikes me as a long time for a BTS-denominated worker. It's almost a guarantee that the pay will be eventually quite out-of-whack. Any thoughts on this?
-
- Emergency security patches
- Emergency network stability patches
Would you be responsible for coding these patches, should the need arise?
Yes.
We have chosen a pay rate of 10,000 BTS/day for this worker. At an exchange rate of $0.004/BTS, this is roughly $1200/month or $14,500/year.
This example is a bit misleading, since the current exchange rate is actually more than 12% higher than your example. Imagine if you were interviewing for a job, and you didn't bother to mention that you expected your pay to be 12% higher than discussed. :)
Good point. I've edited that part to reflect the current price as well. We just picked $0.004 as a round number, and a bit more conservative than the current price.
This Soledger worker has been defined to last until 2017-12-31.
A full year strikes me as a long time for a BTS-denominated worker. It's almost a guarantee that the pay will be eventually quite out-of-whack. Any thoughts on this?
Wasn't totally sure about this either, but figured that if the price gets too low, we can always make another worker. Conversely, if the price gets too high, we should be voted out. Edit: I'm not sure that this is that much of an issue otherwise, as the BTS amount is still a fixed percentage of the daily fund.
-
I'm with you Vikram, voted. Good luck! :)
edit: holy hell..
https://github.com/cryptonomex/graphene/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
-
I hope vikram get money using robots ,and waiting worker be voted.
agent86‘s inflation thought made him unpopular.His comedy life is my tragedy life.
However,I still hope to see your sincere cooperation.
-
I think this was brought up earlier, but isn't Dan Notenstein still in possession of several million bts that are to be used for bitshares maintenance issues as they pop up? Do consider those bts gone? How are patches going to be implemented and work delegated unless the two parties are working together?
-
Good to see that old BTS developers want to come back.
-
I think this was brought up earlier, but isn't Dan Notenstein still in possession of several million bts that are to be used for bitshares maintenance issues as they pop up? Do consider those bts gone? How are patches going to be implemented and work delegated unless the two parties are working together?
Wold like to know this as well.
-
Soledger Inc. (https://www.soledger.com/) (myself and @Agent86) is proposing a BitShares worker for handling administrative and maintenance tasks including--but not limited to--the following:
- Emergency security patches
- Emergency network stability patches
- Merge upstream Graphene, fc, other library updates
- Fix important compilation and compatibility issues
- Tag core releases
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
Vikram - I don't mean to quench your enthusiam, but like others have already said, the software has been *very* stable, which means that there is no immediate need for any of the above. You've set up a worker that pays $1200 per month - for essentially nothing.
Also, I find it a little strange that someone with little knowledge of Graphene turns up after a year of absence, and the first (well, second actually) thing they do is request full access to the main GitHub repo.
I know you're a very capable person, but I would still prefer a more gentle approach to things. That would allow the community to evaluate your work, and give you a chance make yourself familiar with the new codebase. If we reach a point again where BitShares sees more or less regular updates, with your help, I will certainly approve your maintenance worker as proposed above. But not yet.
-
Soledger Inc. (https://www.soledger.com/) (myself and @Agent86) is proposing a BitShares worker for handling administrative and maintenance tasks including--but not limited to--the following:
- Emergency security patches
- Emergency network stability patches
- Merge upstream Graphene, fc, other library updates
- Fix important compilation and compatibility issues
- Tag core releases
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
Vikram - I don't mean to quench your enthusiam, but like others have already said, the software has been *very* stable, which means that there is no immediate need for any of the above. You've set up a worker that pays $1200 per month - for essentially nothing.
Also, I find it a little strange that someone with little knowledge of Graphene turns up after a year of absence, and the first (well, second actually) thing they do is request full access to the main GitHub repo.
I know you're a very capable person, but I would still prefer a more gentle approach to things. That would allow the community to evaluate your work, and give you a chance make yourself familiar with the new codebase. If we reach a point again where BitShares sees more or less regular updates, with your help, I will certainly approve your maintenance worker as proposed above. But not yet.
@pc There may not be an immediate need however having someone like Vikram more involved can help tackle idea's found in this thread: https://bitsharestalk.org/index.php/topic,23355.0.html
We need someone technical to keep pushing the BTS codebase forward.
-
Soledger Inc. (https://www.soledger.com/) (myself and @Agent86) is proposing a BitShares worker for handling administrative and maintenance tasks including--but not limited to--the following:
- Emergency security patches
- Emergency network stability patches
- Merge upstream Graphene, fc, other library updates
- Fix important compilation and compatibility issues
- Tag core releases
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
Vikram - I don't mean to quench your enthusiam, but like others have already said, the software has been *very* stable, which means that there is no immediate need for any of the above. You've set up a worker that pays $1200 per month - for essentially nothing.
Also, I find it a little strange that someone with little knowledge of Graphene turns up after a year of absence, and the first (well, second actually) thing they do is request full access to the main GitHub repo.
I know you're a very capable person, but I would still prefer a more gentle approach to things. That would allow the community to evaluate your work, and give you a chance make yourself familiar with the new codebase. If we reach a point again where BitShares sees more or less regular updates, with your help, I will certainly approve your maintenance worker as proposed above. But not yet.
I definitely hear your concerns and perhaps we should have reached out to you directly before attempting to finalize such a proposal. And perhaps I should have also been more descriptive in the OP:
- Emergency security patches
- Emergency network stability patches
Ideally these would never require any work. However, if such an issue were to arise--which may happen unexpectedly at any time--I think it is important that a specific party has responsibility for ensuring that the issue ultimately gets resolved.
- Merge upstream Graphene, fc, other library updates
This may be a combination of minor things, but something that I want to make sure is maintained well nonetheless. I note that bitshares/bitshares-2/bitshares has diverged from cryptonomex/graphene/master after commit 006d54863312c7daf1ccb73d5940ec658c860efb and has diverged from cryptonomex/graphene/develop after commit f049fce4e97154ce0d037ee2818a285ebffb944f. bitshares/fc has also diverged from steemit/fc after commit 0dca15c3954d38f2a8603aab316d214ca893930f. The updates themselves may not be particularly important but I think it points to a lack of organization in that these divergences persist.
I am also interested in backporting other base Graphene fixes from Steem when applicable and permissible. I also want to look into the feasibility of backporting an upgrade like ChainBase (https://steemit.com/steem/@steemitblog/announcing-steem-0-14-4-shared-db-preview-release) should it be successfully integrated into Steem.
- Fix important compilation and compatibility issues
Ideally this would never require any work. However, operating systems and environments continue to update and move forward, and it may become more difficult to contribute to or run BitShares as time goes on. As an example, I am unable to compile BitShares on my local machine running Arch Linux, presumably due to compilers or libraries which are too new. Perhaps nobody needs specific responsibility for issues like this, but it is something that I intend to keep track of and try to address when possible.
- Tag core releases
Perhaps I misunderstood this initially; although @svk has been tagging what are marked "GUI Release"s, they indeed incorporate all of the few changes to the core code that occurred as well. I do not want to interfere with his work. However, if in the future, there are non-trivial changes to the core code, I am willing to perform final reviews of all said changes before signing off on an official release tag, as I previously was responsible for with BitShares 1. Further, if there are significant updates in the future, someone should also be responsible for coordinating and notifying exchanges and other service providers, a step which has had oversights in the past.
- Manage GitHub issue tracker
- Manage GitHub pull requests
- Consolidate high-quality community projects into BitShares GitHub organization
- Consolidate and maintain other important documentation to help ease contributing and integrating
On second look, I am not yet sure on the best path for the issue tracker. If it seems that bitshares/bitshares-2 will continue to diverge from cryptonomex/graphene, perhaps it does make sense to open an independent issue tracker for bitshares/bitshares-2. This can also be used to collect BitShares-specific issues and should also be more discoverable for BitShares users who do not understand the Graphene heritage.
There are also outstanding pull requests in cryptonomex/graphene, cryptonomex/fc, and bitshares/bitshares-2. The commits may ultimately be inconsequential, but again I think it points to a lack of organization that these requests sometimes go unaddressed. I want to make sure that potentially valuable issues or contributions do not fall through the cracks.
I will have to do more of a survey of projects to get a better idea, but I was thinking that projects from community leaders such as https://github.com/xeroc/python-graphenelib, https://github.com/xeroc/graphene-paperwallet, https://github.com/svk31/graphenejs-lib, https://github.com/svk31/graphenejs-ws, https://github.com/kenCode-de/bitshares-wallet, https://github.com/kenCode-de/smartcoins-wallet as some examples, could potentially be moved into https://github.com/bitshares if said owners find it suitable, to consolidate pieces of the BitShares ecosystem more clearly under the "official" BitShares name.
I will also have to explore the state of documentation more, but I want to look into consolidating and updating info from places like https://bitshares.org/, http://docs.bitshares.eu/, https://bitshares.org/doxygen/, https://github.com/bitshares/bitshares-2/wiki, or at least try to help organize things so that relevant information is more discoverable.
In general, I will also do my best to address relatively clear issues that arise if and when possible. As an example, while syncing a new node yesterday my p2p logs ballooned to greater than 35GB. I can't say that fixing such an issue will be straightforward, but it is the kind of clear problem that I will look into.
Again, I hear your concerns but I hope I have clarified my thinking at least somewhat. The system has indeed been stable and hopefully will remain so, but I do not think these responsibilities amount to nothing. In a system as large and integrated as BitShares--still around a $10 million market cap--I think it is important that even the small details are taken care of. If BitShares were to rise dramatically in value, I think it is even more important to pay attention to the details.
I indeed have relatively little experience working with Graphene, especially after the time that has passed, but I am not wholly unfamiliar with its design--I was there when it was first built and made a number of commits (https://github.com/bitshares/bitshares-2/graphs/contributors) --and am confident in my ability to get back up to speed.
If I recall correctly from when I previously stepped down as GitHub admin, at the time the only other admins were Cryptonomex, BlockTrades, and maybe @cass. If no one else has been added since, it seems like there is room for additional active community leaders to be given administrative permissions, which I would want to grant to probably at least @xeroc and @svk--if there is no great objection to me adding more admins. I will edit the OP to mention this, but it's a natural extension of consolidating community project repos into the GitHub organization. Part of the intent of this worker proposal is for stakeholders to vote on assigning administrative authority to a new party. BitShares is a decentralized project and will continue to have different people in different roles as time goes on.
I hope I have made my thinking a bit more clear. Thank you for the honest thoughts and consideration.
-
Thanks for spelling it our for me. That description looks a lot more convincing than the initial list of bullet points. You have my vote.
-
Just voted for your worker!
If and when this worker is approved, I will request full administrative permissions for the BitShares GitHub organization (https://github.com/bitshares/). Upon acquiring said permissions, I will begin to perform any reorganization/cleanup/updating that I see fit, in line with the tasks outlined in the initial bullet points.
If I recall correctly, CNX as well as @cass are administrators for the bitshares organization.
Edit: Given the decentralized nature of the greater BitShares project, I think it is important that currently active community leaders hold some administrative authority, and so if I am given GitHub admin permissions, I will also look into adding other admins: @xeroc and @svk are two names that come to mind.
I already do have write permissions to some of the repos and don't see the need to become an administrator. Given that I am the biggest proxy, it could mean too much power in the hands of a single entity
-
NOTE: 2 pages of posts disappeared from this thread (I asked about this here: https://bitsharestalk.org/index.php/topic,23506.0.html)
Again, I want to express sincere thanks to all stakeholders from myself and @Agent86 at Soledger. Our worker has been voted in and I've been given administrative privileges for the BitShares GitHub organization. I've merged some minor commits (https://github.com/bitshares/bitshares-2/compare/d7c51f26e3...4eaef390a3) and will continue to address tasks in line with what I've outlined in earlier posts.
Continued feedback and thoughts are always appreciated.
-
I'd like to see a monthly report of what you have done and what are your goals for the next month.
Nothing special, just a small list published here and on steemit.
Thanks
-
I'd like to see a monthly report of what you have done and what are your goals for the next month.
Nothing special, just a small list published here and on steemit.
Thanks
+5%
-
Just broadly so far I've:
- Merged some fixes from upstream Graphene repo that have been sitting there for a while
- Workaround for log files filling up disk space during sync
- Removed some offline seed nodes
- Deleted some abandoned branches from GitHub repo
- Updated docs submodule (repo wiki) with upstream Graphene updates
- Merged a couple minor pull requests
- Removed some no longer active members from GitHub org
- Added @svk as admin to GitHub org
Next I want to begin merging updates/fixes (of which there are many) from upstream steemit/fc. This requires a lot of care because some of them are incompatible with BitShares.
-
Just broadly so far I've:
- Merged some fixes from upstream Graphene repo that have been sitting there for a while
- Workaround for log files filling up disk space during sync
- Removed some offline seed nodes
- Deleted some abandoned branches from GitHub repo
- Updated docs submodule (repo wiki) with upstream Graphene updates
- Merged a couple minor pull requests
- Removed some no longer active members from GitHub org
- Added @svk as admin to GitHub org
Next I want to begin merging updates/fixes (of which there are many) from upstream steemit/fc. This requires a lot of care because some of them are incompatible with BitShares.
General housecleaning as promised. I know it is tedious and generally boring but it needs doing. Thanks for that. +5%
-
Just broadly so far I've:
- Merged some fixes from upstream Graphene repo that have been sitting there for a while
- Workaround for log files filling up disk space during sync
- Removed some offline seed nodes
- Deleted some abandoned branches from GitHub repo
- Updated docs submodule (repo wiki) with upstream Graphene updates
- Merged a couple minor pull requests
- Removed some no longer active members from GitHub org
- Added @svk as admin to GitHub org
Next I want to begin merging updates/fixes (of which there are many) from upstream steemit/fc. This requires a lot of care because some of them are incompatible with BitShares.
Thanks for the update. Nice to see all the commits on GitHub, forward progress for BitShares.
-
Just broadly so far I've:
- Merged some fixes from upstream Graphene repo that have been sitting there for a while
- Workaround for log files filling up disk space during sync
- Removed some offline seed nodes
- Deleted some abandoned branches from GitHub repo
- Updated docs submodule (repo wiki) with upstream Graphene updates
- Merged a couple minor pull requests
- Removed some no longer active members from GitHub org
- Added @svk as admin to GitHub org
Next I want to begin merging updates/fixes (of which there are many) from upstream steemit/fc. This requires a lot of care because some of them are incompatible with BitShares.
Thanks for the update Vikram, great to see work progressing and excited to hear about target updates and fixes you mentioned from steemit/fc.
If you have a spare 15-20 minutes on a Friday; it would be really great if you could stop into the Beyond Bitcoin mumble (https://steemit.com/beyondbitcoin/@officialfuzzy/guest-signups-beyond-bitcoin-hangout-185-12-9-16-rsvp-to-guest-speak-about-your-blockchain-project-last-week-s-payouts-signups) and just say Hi and let us know some of the updates you think are worth merging.
I am hoping one day you may look to expand your role and take on further dev work on the platform.
Cheers,
GC
-
cool. keep my vote.
-
+5% thanks for taking care of that. Keep it up!
-
Glad to have Vikram back. +5%
-
+5%
-
@vikram or @Agent86 can we have a status update please? I emailed you but no reply, I hope you guys are well.
We are paying you about 300,000 BTS per month and I do not see any github commits for ~2.5 months now:
https://github.com/vikramrajkumar
https://github.com/vikramrajkumar/dotfiles/commits/master
https://github.com/bitshares/bitshares-2/
I know R&D can take some time, but we voted for "soledger" because you are already experienced with Bitshares, so could move things along quickly.
Weekly updates would be really nice please, even if it is just a few sentences.
There is a lot of work to be done:
https://github.com/cryptonomex/graphene/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
-
@vikram or @Agent86 can we have a status update please? I emailed you but no reply, I hope you guys are well.
We are paying you about 300,000 BTS per month and I do not see any github commits for ~2.5 months now:
https://github.com/vikramrajkumar
https://github.com/vikramrajkumar/dotfiles/commits/master
https://github.com/bitshares/bitshares-2/
I know R&D can take some time, but we voted for "soledger" because you are already experienced with Bitshares, so could move things along quickly.
Weekly updates would be really nice please, even if it is just a few sentences.
There is a lot of work to be done:
https://github.com/cryptonomex/graphene/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
Replying to your email right after this Ken. Sorry for the delay I've been mostly offline between Christmas and New Years.
To be clear, since my initial work in November, I have nothing to report for December. Lance and I ended up heavily focusing on our internal Soledger project this past month.
In January, I intend to switch gears and make progress on BTS including making up for December. As I mentioned in my previous update, the primary thing I am considering next is to update fc with upstream patches from steemit/fc.
In the long term I think this is important to do because at present, fc has problems building with newer versions of the Boost library as well as with the Clang compiler. As time goes on, I want to avoid compatibility issues like this preventing people from building/developing BTS in newer system environments.
Again, this will require alot of care to avoid including for example changes to JSON serialization to avoid changing the BTS API. The Boost compatibility upgrade is also specifically a major change and will require more analysis to see the feasibility of it working with BTS. I've had some discussion with @modprobe (https://github.com/nathanhourt) and he is also interested in an upgraded fc for the compatibility reasons I mentioned.
I will also review the issue tracker for low-hanging fruit. To reiterate however, the scope of this worker is focused on administration and essential maintenance as described in the OP and my later reply https://bitsharestalk.org/index.php/topic,23495.msg300215.html#msg300215, so I think monthly (rather than weekly) status updates strike a good balance. If anyone is running into specific bugs that are preventing them from doing something please let me know.
All that being said I am open to any feedback from you guys. Happy new years all.
-
Thank you for the email reply Vikram, much appreciated.
When you said "Maintenance" I was banking on the idea that some of the existing Issues would be tackled:
https://github.com/cryptonomex/graphene/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
At least some of the easy ones. Activity on our github repos also shows the world that we are not a dead community, but a very active one, WITH active Bitshares Developers too.
Thank you again for your update, I look forward to your Bitshares commits in January.
-
@vikram or @Agent86 can we have a status update please? I emailed you but no reply, I hope you guys are well.
We are paying you about 300,000 BTS per month and I do not see any github commits for ~2.5 months now:
https://github.com/vikramrajkumar
https://github.com/vikramrajkumar/dotfiles/commits/master
https://github.com/bitshares/bitshares-2/
I know R&D can take some time, but we voted for "soledger" because you are already experienced with Bitshares, so could move things along quickly.
Weekly updates would be really nice please, even if it is just a few sentences.
There is a lot of work to be done:
https://github.com/cryptonomex/graphene/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
Replying to your email right after this Ken. Sorry for the delay I've been mostly offline between Christmas and New Years.
To be clear, since my initial work in November, I have nothing to report for December. Lance and I ended up heavily focusing on our internal Soledger project this past month.
In January, I intend to switch gears and make progress on BTS including making up for December. As I mentioned in my previous update, the primary thing I am considering next is to update fc with upstream patches from steemit/fc.
In the long term I think this is important to do because at present, fc has problems building with newer versions of the Boost library as well as with the Clang compiler. As time goes on, I want to avoid compatibility issues like this preventing people from building/developing BTS in newer system environments.
Again, this will require alot of care to avoid including for example changes to JSON serialization to avoid changing the BTS API. The Boost compatibility upgrade is also specifically a major change and will require more analysis to see the feasibility of it working with BTS. I've had some discussion with @modprobe (https://github.com/nathanhourt) and he is also interested in an upgraded fc for the compatibility reasons I mentioned.
I will also review the issue tracker for low-hanging fruit. To reiterate however, the scope of this worker is focused on administration and essential maintenance as described in the OP and my later reply https://bitsharestalk.org/index.php/topic,23495.msg300215.html#msg300215, so I think monthly (rather than weekly) status updates strike a good balance. If anyone is running into specific bugs that are preventing them from doing something please let me know.
All that being said I am open to any feedback from you guys. Happy new years all.
You should be aware @vikram that today you were voted out due to lack of activity.
Just making you aware in case you are not watching.
-
I have re-added my support after finding the reply of @vikram. My votes have only been removed for a couple hours.
-
Also very helpful is to stay connected with the community and give regular updates about the progress.
We now have a weekly BitShares Mumble 1h before the Beyond Bitcoin show.
https://steemit.com/bitshares/@Chris4210/bitshares-hangout-2-1-6-17
Please feel free to join us there too.
-
where are @vikram latest updates ?
-
where are @vikram latest updates ?
Pushed some updates to bitshares/fc to bring it into sync with steemit/fc: https://github.com/bitshares/fc/compare/31adee49...master
Should be compatible with latest gcc and clang compilers. Boost compatibility past Boost 1.60 will still have to wait on upstream development from Steemit.
Hoping to do some reorganization of the bitshares-2 repo soon before updating it to reflect the fc upgrades.
-
Latest updates:
bitshares-fc
- Created new fc fork https://github.com/bitshares/bitshares-fc for use by BitShares and to keep ongoing compatibility
- Includes most updates and PRs from https://github.com/steemit/fc and https://github.com/cryptonomex/fc
- Merged some new PRs (great work @ElMato!)
bitshares-core (https://bitsharestalk.org/index.php/topic,23716.msg301955.html#msg301955)
- Renamed https://github.com/bitshares/bitshares-2 into https://github.com/bitshares/bitshares-core
- Moved all the issues from https://github.com/cryptonomex/graphene into https://github.com/bitshares/bitshares-core
- Closed many old issues
- Updated git submodule remotes to point to bitshares forks instead of cryptonomex forks (defined here https://github.com/bitshares/bitshares-core/blob/master/.gitmodules)
- Changed default bitshares-core branch from bitshares to master
- Merged some new PRs (great work @ElMato!)
Active developers and those building from source can update their submodule remote URLs using "git submodule sync --recursive".
I am also the one that reorganized the BitSharesTalk subforums (https://bitsharestalk.org/index.php/topic,23650.0.html).
Some things I want to look at next:
- Continue to handle outstanding PRs for bitshares-core
- Continue to incorporate upstream fc updates and PRs
- Clean up bitshares-core branches and include/merge applicable branches from https://github.com/cryptonomex/graphene
- Improve bitshares-core documentation on developing/contributing
-
Latest updates:
bitshares-fc
- Created new fc fork https://github.com/bitshares/bitshares-fc for use by BitShares and to keep ongoing compatibility
- Includes most updates and PRs from https://github.com/steemit/fc and https://github.com/cryptonomex/fc
- Merged some new PRs (great work @ElMato!)
bitshares-core (https://bitsharestalk.org/index.php/topic,23716.msg301955.html#msg301955)
- Renamed https://github.com/bitshares/bitshares-2 into https://github.com/bitshares/bitshares-core
- Moved all the issues from https://github.com/cryptonomex/graphene into https://github.com/bitshares/bitshares-core
- Closed many old issues
- Updated git submodule remotes to point to bitshares forks instead of cryptonomex forks (defined here https://github.com/bitshares/bitshares-core/blob/master/.gitmodules)
- Changed default bitshares-core branch from bitshares to master
- Merged some new PRs (great work @ElMato!)
Active developers and those building from source can update their submodule remote URLs using "git submodule sync --recursive".
I am also the one that reorganized the BitSharesTalk subforums (https://bitsharestalk.org/index.php/topic,23650.0.html).
Some things I want to look at next:
- Continue to handle outstanding PRs for bitshares-core
- Continue to incorporate upstream fc updates and PRs
- Clean up bitshares-core branches and include/merge applicable branches from https://github.com/cryptonomex/graphene
- Improve bitshares-core documentation on developing/contributing
Wow, great work @vikram! You H A V E been busy!
Just to clarify, to build the latest from source what is the top level repo to clone, https://github.com/bitshares/bitshares-core? If building from a clean slate (no existing src tree locally), is it necessary to update build scripts with anything besides the top level repo URL? If so is that reflected in a script or step by step build instructions?
That would sure be nice for any newbies that are trying to build a witness or seed node from scratch.
-
Just to clarify, to build the latest from source what is the top level repo to clone, https://github.com/bitshares/bitshares-core? If building from a clean slate (no existing src tree locally), is it necessary to update build scripts with anything besides the top level repo URL? If so is that reflected in a script or step by step build instructions?
Yup, bitshares-core. The old URLs (bitshares-2) will still work because GitHub redirects from the old name--but I will indeed be updating some of the build instructions (intended as part of my last point above).
-
+1
Good work!
-
great work ...
-
Recent updates:
- Continued handling PRs (great work especially by @oxarbitrage)
- Updated seed nodes based on reports in seed node thread (https://bitsharestalk.org/index.php/topic,23715.0.html)
- Cleaned up README (https://github.com/bitshares/bitshares-core#bitshares-core)
-
Good. I am looking for more active updates about your work Vikram. Please also join us on Telegram for direct communication. We also have a developer channel.
-
Any updates about your worker!?
-
Any updates about your worker!?
last report was almost 3 weeks ago. removed my vote.
-
Since the last update I've basically:
- Merged a few bitshares-core PRs (https://github.com/bitshares/bitshares-core/pulls?utf8=%E2%9C%93&q=is%3Apr)
- Including a large API notification patch that @ElMato and @oxarbitrage have been working on for some time (https://github.com/bitshares/bitshares-core/pull/249)
- I also simplified the internal time system to help improve the consistency of the code (https://github.com/bitshares/bitshares-core/issues/76)
- Merged a few minor updates to bitshares-fc (https://github.com/bitshares/bitshares-fc/commits/master)
- Including merging an upstream feature from steemit-fc to help log the time taken by API calls (https://github.com/bitshares/bitshares-fc/commit/1f41494f360a1800fc967d647631cf64fdc549ee)
As mentioned previously, there is not a whole lot of core/fc development activity at the moment, so I think roughly monthly updates strike a good balance. Again, part of the intent of this worker is to be a clearly defined agent that can encourage and integrate contributions, but while ensuring that the stability of the network does not suffer while doing so.
This worker is unlikely to make big enhancements or other potentially nonessential upgrades on its own, but if there is a specific issue really hurting service integration or usability, of course let me know.
Shoutout to @oxarbitrage, @ElMato, @svk, and TheTaconator (@Taconator ?) for their patches or other work!
-
Since the last update I've basically:
- Merged a few bitshares-core PRs (https://github.com/bitshares/bitshares-core/pulls?utf8=%E2%9C%93&q=is%3Apr)
- Including a large API notification patch that @ElMato and @oxarbitrage have been working on for some time (https://github.com/bitshares/bitshares-core/pull/249)
- I also simplified the internal time system to help improve the consistency of the code (https://github.com/bitshares/bitshares-core/issues/76)
- Merged a few minor updates to bitshares-fc (https://github.com/bitshares/bitshares-fc/commits/master)
- Including merging an upstream feature from steemit-fc to help log the time taken by API calls (https://github.com/bitshares/bitshares-fc/commit/1f41494f360a1800fc967d647631cf64fdc549ee)
As mentioned previously, there is not a whole lot of core/fc development activity at the moment, so I think roughly monthly updates strike a good balance. Again, part of the intent of this worker is to be a clearly defined agent that can encourage and integrate contributions, but while ensuring that the stability of the network does not suffer while doing so.
This worker is unlikely to make big enhancements or other potentially nonessential upgrades on its own, but if there is a specific issue really hurting service integration or usability, of course let me know.
Shoutout to @oxarbitrage, @ElMato, @svk, and TheTaconator (@Taconator ?) for their patches or other work!
Thanks for your updates! Much appreciated
-
Hi Vikram,
thank you for the update, unfortunately these updates are not regular enough to understand what you worked on the past few days and what you would like to improve next. Regular communication to all BitShares Shareholders is very important.
Until the communication has been improved, I removed my support for this worker.
Best regards,
Christoph
-
- Fixed a crash in get_ticker and get_24_volume API calls as identified by @oxarbitrage (https://github.com/bitshares/bitshares-core/pull/250)
-
- Merged memory leak fix by @abit (https://github.com/bitshares/bitshares-core/pull/257)
- Merged -track-account command line argument fix by @abit (https://github.com/bitshares/bitshares-core/pull/259)
- Merged get_full_accounts API enhancement by @alt (https://github.com/bitshares/bitshares-core/pull/261)
- Merged console P2P error issue fix by @oxarbitrage (https://github.com/bitshares/bitshares-core/pull/264)
- Merged new get_block_header_batch API by @oxarbitrage (https://github.com/bitshares/bitshares-core/pull/263)
- Fixed compilation compatibility with new Clang 4.0.0 (https://github.com/bitshares/bitshares-fc/commit/908762d687eccab019403189fd1d95502fb75c89#commitcomment-21919423)
-
- Fixes to re-indexing decisions and behaviour (https://github.com/bitshares/bitshares-core/commit/f13698370b9eb2d64677bad0e2bc6a52aa93f039)
- Merged upstream JSON RPC improvements (https://github.com/steemit/fc/issues/13)
- Updated seed nodes (https://github.com/bitshares/bitshares-core/compare/8c0668de367b3826c52e4217880eb8a227caadf7...cda895abd6d7a7d4556d63e31f61438f310ead9f)
- Fixed broken reference links and cleaned out old pages on GitHub wiki (https://github.com/bitshares/bitshares-core/wiki)
- Cleaned up bitshares-core GitHub branches
I am looking forward to see whether the upcoming Peerplays blockchain might have any general Graphene patches that could be applicable to BitShares.
-
Thanks.
More docs need to update.
-
A few updates:
- Merged broadcast_transaction_synchronous API addition from Steem by @ElMato (https://github.com/bitshares/bitshares-core/pull/311)
- Merged get_asset_holders API fix from @oxarbitrage (https://github.com/bitshares/bitshares-core/pull/312)
- Merged Windows build fix from @abit (https://github.com/bitshares/bitshares-core/pull/299)
- Documented OpenSSL compatibility issue (https://github.com/bitshares/bitshares-core/wiki)
- Merged minor graphene constant cleanups from @oxarbitrage (https://github.com/bitshares/bitshares-core/pull/309, https://github.com/bitshares/bitshares-core/pull/310)
- Added additional seed node from @sahkan (https://github.com/bitshares/bitshares-core/pull/286)
- Merged Visual Studio compatibility fix from btsabc for bitshares-fc (https://github.com/bitshares/bitshares-fc/pull/4)
- Miscellaneous bitshares-fc cleanup (https://github.com/bitshares/bitshares-fc/commits/master)
Huge thanks to everyone who supported this worker. One of the unique things about BitShares is how decentralized its development is, and over time I've added active contributors directly to the BitShares GitHub organization. I think this plays an important part in helping ensure that BitShares will continue to improve and grow, without needing to depend on any single person. Special thanks to @abit, @ElMato, @oxarbitrage, @pc, @svk, @xeroc and any other team members for their continuing work.
Unless this worker gets voted back in at some point, all of my focus is now dedicated to the upcoming Soledger blockchain project. I will make an initial announcement on the project after development has progressed a bit more. The details may change, but my hope is that the project can directly benefit the members of the BitShares community. If possible, I hope to also give an extra bonus to those who directly supported myself and Soledger either through this worker, or with other contributions to the project in the future.
As always, anyone still feel free to contact me about helping organize things on the GitHub or forum, or other related issues to help the improve the community.
-
Thanks for your work, Vikram!
-
Unless this worker gets voted back in at some point, all of my focus is now dedicated to the upcoming Soledger blockchain project. I will make an initial announcement on the project after development has progressed a bit more. The details may change, but my hope is that the project can directly benefit the members of the BitShares community. If possible, I hope to also give an extra bonus to those who directly supported myself and Soledger either through this worker, or with other contributions to the project in the future.
create a new worker proposal in bitusd like @xeroc. your current worker is too expensive at this point.
-
@vikram thanks for your work. We do like you to be around, however, the pay of current workers are a bit too high according to current market price/rate of BTS token (around $3k per day). As quoted below, if you still like to be paid to work with this project, please consider creating a new worker proposal like @xeroc's -- multisig and be paid in bitUSD. Related link: https://bitsharestalk.org/index.php/topic,23770.0.html
Unless this worker gets voted back in at some point, all of my focus is now dedicated to the upcoming Soledger blockchain project. I will make an initial announcement on the project after development has progressed a bit more. The details may change, but my hope is that the project can directly benefit the members of the BitShares community. If possible, I hope to also give an extra bonus to those who directly supported myself and Soledger either through this worker, or with other contributions to the project in the future.
create a new worker proposal in bitusd like @xeroc. your current worker is too expensive at this point.
-
Unless this worker gets voted back in at some point, all of my focus is now dedicated to the upcoming Soledger blockchain project. I will make an initial announcement on the project after development has progressed a bit more. The details may change, but my hope is that the project can directly benefit the members of the BitShares community. If possible, I hope to also give an extra bonus to those who directly supported myself and Soledger either through this worker, or with other contributions to the project in the future.
create a new worker proposal in bitusd like @xeroc. your current worker is too expensive at this point.
@vikram This is a good idea, any interest in doing so? With the BTS and crypto market heating up, continued development would be a great asset. Even if you can only do it part time etc...
-
@vikram is great, will be of big value for us if we can have any way to keep him involved. the best of the luck with your project also vikram!
-
Thanks for the support guys. Things are a bit hectic for me at the moment, but once I get a few things out of the way, I will likely look into some sort of limited worker using an arrangement similar to what was mentioned earlier.
-
Why did this worker never get approved? Was the proposal flawed in some way?
-
It would be a terrible shame to lose Vikram.
-
vikram was with us until the workers were suspended due to high price in bitshares. we asked vikram to submit a new worker in bitusd but he was moving on into working in a new chain project outside bitshares. of course this was a big loss, i am trying with my reduced skills compared to him to do the basic maintenance he was doing since then.
-
Why don't we just offer his more $$ then? Have him submit proposal for a rate that would bring him over immediately?
-
last time he was simply not interested, was not a matter of offering more $. maybe that changed now, not sure.