0 Members and 1 Guest are viewing this topic.
Quote from: clayop on February 17, 2016, 05:38:42 pmQuote from: iHashFury on February 17, 2016, 05:30:58 pmShareholders can subscribe to this linkhttps://github.com/bitshares/bitshares-2/subscriptionTo keep up-to-dateIMO this is naïve mind. Devs and witnesses can do that but normal users and business partners don't think a github tag is an announcement.It's just a lazy manner I think. It only needs 10 min and user-friendly mind to write short announcements and newsletters.It doesn't take 10 minutes.. a proper well authored document that is not torn apart for being unprofessional or having all kinds of mistakes takes hours.
Quote from: iHashFury on February 17, 2016, 05:30:58 pmShareholders can subscribe to this linkhttps://github.com/bitshares/bitshares-2/subscriptionTo keep up-to-dateIMO this is naïve mind. Devs and witnesses can do that but normal users and business partners don't think a github tag is an announcement.It's just a lazy manner I think. It only needs 10 min and user-friendly mind to write short announcements and newsletters.
Shareholders can subscribe to this linkhttps://github.com/bitshares/bitshares-2/subscriptionTo keep up-to-date
+5%Clayop is right, so is iamfox, who is calling for witnesses to vet the new release (i.e. test it) before it goes into production.This has been taken for granted far too long. We need to allow time in the deployment schedule to allow witnesses to test a release, and until now this has not been done or much concern shown for it. We need to take deployment of new code seriously. It only serves to strengthen confidence, not just that we know what we're doing but also that we take such measures to protect the integrity of the BitShares network.It would be nice to see some type of report from the devs that shows they have tested the release and signed off on it for production readiness.The witnesses are discussing this on telegram now. It will take time for this discussion to make it's way through all the witnesses to get a commitment on gathering the resources (i.e. VPS nodes) required to devote to a testnet to serve as a staging area for pre-production testing.
Quote from: bytemaster on February 16, 2016, 09:00:12 pmQuote from: clayop on February 16, 2016, 08:50:42 pmhttps://github.com/bitshares/bitshares-2/releases/tag/2.0.160216I'm little sick of this kind of practice...BM said the upgrade will be Thursday only in mumble. NO pre-announcement.Theoretical post update Tuesday. NO announcement on forum or via email.The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.We are in the process of notifying exchanges and posting the update in the appropriate threads. We cannot broadcast on all channels at the same time. Also, it is helpful to have witnesses verify the code before we notify exchanges.That makes sense. I maybe over sensitive, but we should notify all types of customers, not only exchanges, so that we need more specific channel IMHO.
Quote from: clayop on February 16, 2016, 08:50:42 pmhttps://github.com/bitshares/bitshares-2/releases/tag/2.0.160216I'm little sick of this kind of practice...BM said the upgrade will be Thursday only in mumble. NO pre-announcement.Theoretical post update Tuesday. NO announcement on forum or via email.The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.We are in the process of notifying exchanges and posting the update in the appropriate threads. We cannot broadcast on all channels at the same time. Also, it is helpful to have witnesses verify the code before we notify exchanges.
https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216I'm little sick of this kind of practice...BM said the upgrade will be Thursday only in mumble. NO pre-announcement.Theoretical post update Tuesday. NO announcement on forum or via email.The devs should realize that Github notification is not an announcement. We need more formal and official one, to become a successful platform.
Quote from: Akado on February 16, 2016, 09:22:35 pmSure devs are expected to do that since they are more into those matters and have more info than us, but if it's a problem that big - just letting them know there will be a fork - why not just tell them ourselves too? The community also needs to be proactive. Sure any issues during an update that might appear (ie 1.0 to 2.0 update) should have a closer look from the devs and provide some help if necessary.However if the problem is just informing them why can't the community do it too? Yesterday I just went to Polo and told a mod who said he would pass the info to the rest of the crew, what's the problem with that? 2m and it's done.Yeah I already noticed polo two days ago via ticket (it took 3 min :p) But it's a matter of organizing things and services. What if they asked you where's the announcement they can read? Go and read the whole script of hangout?
Sure devs are expected to do that since they are more into those matters and have more info than us, but if it's a problem that big - just letting them know there will be a fork - why not just tell them ourselves too? The community also needs to be proactive. Sure any issues during an update that might appear (ie 1.0 to 2.0 update) should have a closer look from the devs and provide some help if necessary.However if the problem is just informing them why can't the community do it too? Yesterday I just went to Polo and told a mod who said he would pass the info to the rest of the crew, what's the problem with that? 2m and it's done.
Ben is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.
We will give exchanges 1 week notice from the time we publish the final code.
maybe I'm missing something... why is it important to inform exchanges about stealth? Is it just important to inform them of any hardfork? If they are not informed, will this prevent them from making BTS transfers?
Quote from: tbone on February 16, 2016, 01:42:44 amQuote from: BunkerChain Labs on February 16, 2016, 01:13:45 amQuote from: tbone on February 15, 2016, 08:19:49 pmI'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?). But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork. You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/There is no 2FA for the wallet currently.I see. Interesting. @xeroc mentioned that a 2FA solution would be ready along with the upcoming release of the new hosted web wallet. I assume this is what he was referring to?That is xerocs 2FA solution. I don't know if it is ready for integration into the wallet yet though. Yes though, this is what he would have been referring to. There are no others currently under development.
Quote from: BunkerChain Labs on February 16, 2016, 01:13:45 amQuote from: tbone on February 15, 2016, 08:19:49 pmI'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?). But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork. You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/There is no 2FA for the wallet currently.I see. Interesting. @xeroc mentioned that a 2FA solution would be ready along with the upcoming release of the new hosted web wallet. I assume this is what he was referring to?
Quote from: tbone on February 15, 2016, 08:19:49 pmI'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?). But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork. You can add 2FA not to your wallet but to your account with this: http://beta.peermit.com/There is no 2FA for the wallet currently.
I'm INCREDIBLY eager to have STEALTH features along with the hosted web wallet (with 2FA?). But I agree with those on this thread expressing the great importance of giving our exchange partners some advance warning of this hard fork.
I think if they are notified via skype, an email to the CTO's and even a phone call, then this close relationship will instill trust again.
Quote from: clayop on February 15, 2016, 07:46:33 pmQuote from: bytemaster on February 15, 2016, 07:35:44 pmBen is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.So will your team contact exchanges? Or leave them behind?There is a skype group with many exchanges that has been created for this particular case (and for emergency fixes of course)bytemaster is in that group as well
Quote from: bytemaster on February 15, 2016, 07:35:44 pmBen is preparing the release for stealth, we can set the hard fork date to any day we like, but the code should be frozen today with all changes merged to the Bitshares branch.So will your team contact exchanges? Or leave them behind?
Quote from: Thom on February 15, 2016, 07:11:29 pmIs it reasonable or neglectful to expect our partners to monitor proposal voting and set their plans accordingly?If we were more respected we wouldn't have to go to them to make sure they were ready, they would just watch us and BE ready when necessary. I just don't think we should expect that, and we ought to make sure -- proactively -- that our partners are ready for any hardfork we might have in the pipeline.It's EXTREMELY neglectful to expect partners/exchanges to be ready imo. BTS lost a lot of value/momentum because the BTS 2.0 update wasn't properly communicated and planned with exchanges. The exchanges themselves lost little business overall and mostly maintained their BTS market share after too. So the only one that loses if BTS doesn't properly communicate and plan with exchanges/others is BTS itself.
Is it reasonable or neglectful to expect our partners to monitor proposal voting and set their plans accordingly?If we were more respected we wouldn't have to go to them to make sure they were ready, they would just watch us and BE ready when necessary. I just don't think we should expect that, and we ought to make sure -- proactively -- that our partners are ready for any hardfork we might have in the pipeline.
Quote from: xeroc on February 15, 2016, 02:57:02 pmThe hardfork has been approved via voting of the STEALTH worker.Anyone wanting to read into FBA, can already do so from the graphene/develop code. AFAIK most of FBA and STEALTH (mostly API calls) are already thereIs this the code kept in github? Is this also in the help section of the wallet? Do you have a link?
The hardfork has been approved via voting of the STEALTH worker.Anyone wanting to read into FBA, can already do so from the graphene/develop code. AFAIK most of FBA and STEALTH (mostly API calls) are already there
I think it is supposed to be ready by the 18th. If it is, it doesn't mean we need to fork it asap, let it be ready and once we have talked with everyone, it's done. I recall BM mentioning one of the devs was to schedule the hardfork however atm I dont remember if it is already decided to be on the 18th or if everything is ready on the 18th but it will be forked later.Either way what matters is it's ready, then we can wait and plan the fork accordingly so it shouldn't be a problem.