[ATTENTION] STEALTH will come on 18th Feb?

[iHashFury]

"Knowledge is power" but it depends what you do with it!

[clayop]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

IMO 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.

https://bitsharestalk.org/index.php/topic,19040.30.html

[BunkerChainLabs-DataSecurityNode]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

IMO 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.

[clayop]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

IMO 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.

[iHashFury]

Shareholders can subscribe to this link
https://github.com/bitshares/bitshares-2/subscription

To keep up-to-date

[kenCode]

+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.

 

[Thom]

 +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.

[luckybit]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'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.

http://mailchimp.com/

[Akado]

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.

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?

GeezUp asked me for a link for the updates and I provided one that xeroc shared here, wasn't sure if it was that one lol but they know about it that's what matters, mission accomplished.

[clayop]

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.

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?

[Akado]

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.

[clayop]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'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.

[bytemaster]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'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.

[clayop]

https://github.com/bitshares/bitshares-2/releases/tag/2.0.160216

I'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.

[abit]

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.

Sounds good.

We will give exchanges 1 week notice from the time we publish the final code.

Acceptable for me.

So how about public testing? Looks like fewer people cares (than the announcement/notice)?
Or at least do you have an internal testing report which can be publicized? @bytemaster