Events have unfolded quickly regarding OS X builds. Three days ago (the 8th) @woodstockmerkle, currently our most active developer on the NuBit project, told me that he had just succeeded in creating OS X builds. He mentioned he would like to purchase a used Mac and make builds for NuBits and B&C going forward. Prior to this, I had stated on the forum that I am stepping back from OS X builds personally, but would facilitate payment to someone who would commit to be responsible for them. Naturally, I was pleased with this development as I regard woodstockmerkle as trustworthy and told @woodstockmerkle that he could invoice for OS X builds and the used Mac, splitting the cost of that between NuBits and B&C.
With the proposal @backpacker has made, I am concerned that backpacker will feel that what has just unfolded is unfair. I can see why. I didn’t want to alienate backpacker. I would rather have him join the community and work with us.
Perhaps the best way to deal with this is just reveal all that has occurred (as I just did) and ask forum participants how they want to move forward with OS X builds. I will do whatever consensus indicates should be done, so long as it doesn’t require me to violate agreements that I have made (like those I just made with woodstockmerkle which I described above).
We need to encourage @backpacker. Could we have @woodstockmerkle check @backpacker’s builds, or vice versa? As far as I’m concerned, backpacker did everything right here and wires just get crossed sometimes. @JordanLee posted a request for dev help, Backpacker responded in a very fair and reasonable way, even going so far as to hash a grant proposal and everything.
I have no clue whether a code review is as challenging as writing the code itself (in terms of time). If a review is not that much work and backpacker’s offer is strongly competitive in terms of price and quality, it is a necessity for me to get backpacker on board. If he asks for better rates from a shareholder perspective, how can we decline his offer if we have someone to review his code to make sure everything is fine. If woodstockmerkle doesn’t like it and aims at charging higher rates than backpacker does for the same work, how are we ever going to expand our skillset if whenever that situation occurs, we must stick to the one charging the higher rates because he has been part of the inner circle for a longer time?
We will definitely need to find a balance for those situations because it is bad to dismiss someone who really has good intentions. Of course, we need to make sure those intentions are real…
Apart from that, I would really like to know what the price will be for that used mac.
I wasn’t aware of this development when I updated my Nu data feed a few minutes ago.
I don’t intend to remove this grant of @backpacker from my data feed, because what he offered was very welcome or even necessary when he offered his services.
Even if the next months will have OSX builds from @woodstockmerkle I’d like to honor @backpacker’s work and the offer to continue the services for months by keeping that grant in the data feed hoping that it passes.
Obviously @backpacker didn’t start his support only for the money - at least that’s my impression.
And even if one could argue that voting for this grant is wasting money for services that are not required any more (making OSX builds) or are not part of the grant (co-operating with @woodstockmerkle, checking the builds) my stance on supporting what he already did and maybe will do will not be moved easily.
100% agree. We certainly need to establish trust through reasonable measures when it comes to new contractual relationships, but just dismissing shouldn’t be an option considering his offer.
OK, I’ll try to be as straight forward as possible about the situation.
Of course it would be disappointing to have my efforts of preparing my personal machine to generate builds for nu-qt and bcexchange go to waste, but I understand that there was never any official go-ahead from the community, so I have no one to blame but myself for wasting time with this.
I must have misunderstood the way this DAO operates, I was under impression of shareholders being in control of the course of action and decisions made, that’s why I have spent time creating a proposal for grant. Perhaps it took me too long as it was my first time and events beyond my field of view changed the situation.
I still remain committed to my proposal and also to provide help with setup and keeping up to date of macosx build environment and dependencies under control of more trustworthy developers, just like I said in initial thread, if there is any need.
@Sabreiib and @ChrisS I have received your donations, thank you. I do appreciate it.
You release your builds to us (work that’s already done right?) then let us continue voting on your grant. Anyway, that’s my opinion. Usually, what you did is just fine, this is just kind of an awkward position because of the trust and stuff involved.
No misunderstanding. Shareholders are in full control, but if we needed to hold a vote for every little decision we wouldn’t get much done. Jordan Lee is in charge of development of Nu and B&C. Shareholders provide him and contractors in other roles some amount of discretion when carrying out their responsibilities, so that things can get done as smoothly and quickly as possible. If a controversial decision had been made though, shareholders could always overrule it by voting and passing a new motion.
As for the current situation, I agree with supporting @backpacker’s current motion and having a trusted person on the team like @woodstockmerkle check the build before releasing it.
I must have misunderstood the way this DAO operates, I was under impression of shareholders being in control of the course of action and decisions made, that’s why I have spent time creating a proposal for grant. Perhaps it took me too long as it was my first time and events beyond my field of view changed the situation.
Remember Satoshi control 80% hashrate in 2009? B&C is in a start up stage and not very decentralized now, but in future I believe shareholders can get more power. E.g. if Jordan and sigmike quit our business for some personal(such as health) or other irresistible reasons, shareholder may hire & fire other core developers. And it’s possible two or three dev groups disagree with each other, like Classic vs Core in BTC community, shareholders can simply vote for their favorite. Anything is possible, even Apple fired Steve Jobs, shareholder may also hire him again.
Where do we go from here?
Destination: MacOS QT build tutorial?
I believe the RaspberryPi tutorial helps quite some people setting up their minting rigs. https://docs.nubits.com/nu-raspberry-minting/
To maintain that tutorial costs some manhours because the software environment on Mac OS is always changing. If you write that tutorial with screenshot and explaination of technical issues, I’ll appreciate a lot.
None build is more trustworthy than that made by myself.
it is not possible to produce exactly same dmg file, because it contains timestamps of bundled files, generated from source and copied from frameworks and libraries.
what i meant by my comment is that user can confirm that nobody replaced my file, after I compiled it.
Yes sorry I figured that out after I posted that’s why I deleted my post. But other people seems to assume they can ask someone to verify your builds, which is not possible. That’s what I meant:
If the build is not deterministic it’s not possible to verify it. If you want the builds to be verifiable you must first allow others to produce the exact same build from the same source code. It may be just a how-to or something. The bitcoin documentation may give some good hints to achieve that, but we do not use the same build system yet so I’m not
sure: https://github.com/bitcoin/bitcoin/blob/master/doc/README_osx.txt
