cbf (Wed, 01 Feb 2017 20:59:44 GMT):
Hyperledger Fabric maintainers discussion

cbf (Wed, 01 Feb 2017 21:00:03 GMT):
Discussion amongst or with the Hyperledger Fabric maintainers

cbf (Thu, 02 Feb 2017 00:02:16 GMT):
User User_1 added by cbf.

rjones (Thu, 02 Feb 2017 00:06:05 GMT):
Has joined the channel.

rjones (Thu, 02 Feb 2017 00:06:10 GMT):
howdy

cbf (Thu, 02 Feb 2017 00:07:05 GMT):
User User_2 removed by cbf.

rjones (Thu, 02 Feb 2017 00:07:23 GMT):
Has joined the channel.

cbf (Thu, 02 Feb 2017 00:07:27 GMT):
ryjones

cbf (Thu, 02 Feb 2017 00:07:40 GMT):
something

cbf (Thu, 02 Feb 2017 00:07:40 GMT):
something cool

rjones (Thu, 02 Feb 2017 00:08:23 GMT):
foo

rjones (Thu, 02 Feb 2017 00:08:23 GMT):
foobar

cbf (Thu, 02 Feb 2017 00:10:17 GMT):
greg.haskins

rjones (Thu, 02 Feb 2017 00:45:56 GMT):
Has left the channel.

rjones (Thu, 02 Feb 2017 08:35:54 GMT):
Has joined the channel.

VipinB (Thu, 02 Feb 2017 17:20:07 GMT):
Has joined the channel.

C0rWin (Thu, 02 Feb 2017 17:23:47 GMT):
Has joined the channel.

jimthematrix (Thu, 02 Feb 2017 17:24:46 GMT):
Has joined the channel.

yacovm (Thu, 02 Feb 2017 17:36:22 GMT):
Has joined the channel.

silliman (Thu, 02 Feb 2017 17:56:00 GMT):
Has joined the channel.

muralisr (Thu, 02 Feb 2017 18:33:34 GMT):
Has joined the channel.

jyellick (Thu, 02 Feb 2017 19:14:00 GMT):
Has joined the channel.

ashutosh_kumar (Fri, 03 Feb 2017 00:22:55 GMT):
Has joined the channel.

salmanbaset (Fri, 03 Feb 2017 01:20:38 GMT):
Has joined the channel.

SriramaSharma (Fri, 03 Feb 2017 03:22:02 GMT):
Has joined the channel.

didnotgetagoodname (Fri, 03 Feb 2017 03:58:55 GMT):
Has joined the channel.

grapebaba (Fri, 03 Feb 2017 04:30:32 GMT):
Has joined the channel.

harsha (Fri, 03 Feb 2017 05:28:04 GMT):
Has joined the channel.

grapebaba (Fri, 03 Feb 2017 06:28:44 GMT):
guys, it seems missing twg-china channel in rocket.chat

cbf (Fri, 03 Feb 2017 06:30:39 GMT):
https://gerrit.hyperledger.org/r/#/c/5167/ has protobuf changes... we really cannot have changes post alpha. Is this absolutely it?

JonathanLevi (Fri, 03 Feb 2017 07:47:46 GMT):
Has joined the channel.

dave.enyeart (Fri, 03 Feb 2017 11:19:53 GMT):
Has joined the channel.

muralisr (Fri, 03 Feb 2017 13:11:37 GMT):
@cbf I cannot think of protobuf changes for alpha but we will likely have some for beta (at least one for adding version field to chainid if the new deployment model goes through)

muralisr (Fri, 03 Feb 2017 13:12:38 GMT):
talking of alpha, have also fixed a potential issue reported by @rameshthoomu in https://gerrit.hyperledger.org/r/#/c/5497/

rameshthoomu (Fri, 03 Feb 2017 13:12:38 GMT):
Has joined the channel.

dave.enyeart (Fri, 03 Feb 2017 14:16:31 GMT):
Since we want to minimize post-alpha changes, I've gone ahead and made the one proto change that I know about - adding an isValidated flag on the transaction header so that clients know whether the tran was validated or not by committer: https://gerrit.hyperledger.org/r/#/c/5503/

greg.haskins (Fri, 03 Feb 2017 14:16:57 GMT):
just out of curiosity: do we strive to have 0 protobuf changes after alpha, or are protobuf forwards/backwards compatible changes ok?

greg.haskins (Fri, 03 Feb 2017 14:17:12 GMT):
i dont have any plans, I am just wondering about the policy so I can enforce it in my reviews

dave.enyeart (Fri, 03 Feb 2017 14:18:32 GMT):
Seams we should strive to limit changes, but if changes are needed they are much better pre-v1 than post-v1, even if that means they come in post-alpha.

muralisr (Fri, 03 Feb 2017 14:29:03 GMT):
@greg.haskins the main issue is more of all SDKs and tooling keeping up with protobuf changes (but right, backward compatibility will become more and more important as we progress)

greg.haskins (Fri, 03 Feb 2017 14:40:19 GMT):
i agree with all that @dave.enyeart @muralisr

gormand (Fri, 03 Feb 2017 14:43:11 GMT):
Has joined the channel.

ssaddem (Fri, 03 Feb 2017 15:53:11 GMT):
Has joined the channel.

rickr (Fri, 03 Feb 2017 17:33:11 GMT):
Has joined the channel.

greg.haskins (Fri, 03 Feb 2017 18:21:45 GMT):
@all what is the plan for v1.0 GA release date, if any?

cbf (Fri, 03 Feb 2017 18:21:59 GMT):
Paul Mason

cbf (Fri, 03 Feb 2017 18:21:59 GMT):
Paul Masson

greg.haskins (Fri, 03 Feb 2017 18:22:01 GMT):
i know it could slip, or whatever, just looking for the plan

greg.haskins (Fri, 03 Feb 2017 18:22:34 GMT):
@cbf are you saying ask Paul?

cbf (Fri, 03 Feb 2017 18:23:19 GMT):
@greg.haskins https://www.youtube.com/watch?v=oSs6DcA6dFI

greg.haskins (Fri, 03 Feb 2017 18:24:13 GMT):
ah, hahah

greg.haskins (Fri, 03 Feb 2017 18:24:16 GMT):
i missed the reference

greg.haskins (Fri, 03 Feb 2017 18:24:29 GMT):
We will sell no fabric before its time

cbf (Fri, 03 Feb 2017 18:24:43 GMT):
bingo

greg.haskins (Fri, 03 Feb 2017 18:25:05 GMT):
funny, though not very helpful ;)

cbf (Fri, 03 Feb 2017 18:25:25 GMT):
I think that right now we are looking to integrate the docker image refactor and the proto changes (as well as any documentation updates) before -alpha is cut

cbf (Fri, 03 Feb 2017 18:25:45 GMT):
lots of people traveling today

greg.haskins (Fri, 03 Feb 2017 18:25:51 GMT):
I was sitting there wondering how Paul could be so key to the release yet I hadnt heard of him

greg.haskins (Fri, 03 Feb 2017 18:26:14 GMT):
yeah, to be clear though, I was wondering about GA not alpha

greg.haskins (Fri, 03 Feb 2017 18:26:30 GMT):
I know at one point we were targeting "March"

greg.haskins (Fri, 03 Feb 2017 18:26:58 GMT):
but "we dont know" is perfectly fine

JonathanLevi (Fri, 03 Feb 2017 18:53:47 GMT):

Message Attachments

muralisr (Fri, 03 Feb 2017 19:00:06 GMT):
well they are hoping the car driver does not think like them ;-) @JonathanLevi

JonathanLevi (Fri, 03 Feb 2017 19:00:35 GMT):
Yeah, they probably don't want to assume, eh?

JonathanLevi (Fri, 03 Feb 2017 19:01:10 GMT):
We should spend enough time for testing... as we really need to "lock APIs" and soon.

JonathanLevi (Fri, 03 Feb 2017 19:01:10 GMT):
We should spend/allocate enough time for testing... as we really need to "lock APIs" and soon.

fz (Fri, 03 Feb 2017 19:29:04 GMT):
Has joined the channel.

karkal (Fri, 03 Feb 2017 19:52:52 GMT):
Has joined the channel.

ashutosh_kumar (Fri, 03 Feb 2017 20:05:38 GMT):
@JonathanLevi , you read Stephen Hawkins ?

ashutosh_kumar (Fri, 03 Feb 2017 20:06:19 GMT):
I read his book , The Brief History of Time , loved that book.

rocket.chat (Fri, 03 Feb 2017 20:10:28 GMT):
Has joined the channel.

JonathanLevi (Fri, 03 Feb 2017 22:06:50 GMT):
@ashutosh_kumar Please don't write in this channel.

rjones (Fri, 03 Feb 2017 23:04:32 GMT):
JonathanLevi

rjones (Fri, 03 Feb 2017 23:04:42 GMT):
greg.haskins

rjones (Fri, 03 Feb 2017 23:04:43 GMT):
greg.haskins

jiangyaoguo (Sat, 04 Feb 2017 01:32:36 GMT):
Has joined the channel.

sheehan (Sat, 04 Feb 2017 02:34:06 GMT):
Has joined the channel.

genggjh (Sat, 04 Feb 2017 03:44:45 GMT):
Has joined the channel.

mastersingh24 (Sat, 04 Feb 2017 15:20:22 GMT):
Has joined the channel.

greg.haskins (Sun, 05 Feb 2017 13:36:40 GMT):
@cbf, all: one thing we should decide on ABI wise for v1.0 is the whole core.yaml/CORE_ name

greg.haskins (Sun, 05 Feb 2017 13:37:11 GMT):
this has never struck me as aptly named especially in the grand scheme of all the other HL projects and fabric components

greg.haskins (Sun, 05 Feb 2017 13:37:23 GMT):
do we want to try to fix that before we are more stuck with it than we are now?

greg.haskins (Sun, 05 Feb 2017 13:38:53 GMT):
also, we should probably restructure the devenv docs to be docker/docker-for-mac/docker-for-win oriented, making vagrant a sidebar and dropping docker-toolbox (we arent compatible with docker-toolbox)

mastersingh24 (Sun, 05 Feb 2017 13:39:54 GMT):
@greg.haskins - I am just going to be harsh here (not towards you). The config stuff is simply terrible. We also have a big issue IMHO where we treat the peer executable as both a server and a client (CLI).

yacovm (Sun, 05 Feb 2017 13:40:04 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=npSuJnQgn3WWc27hq) @greg.haskins a sidebar?

greg.haskins (Sun, 05 Feb 2017 13:40:32 GMT):
@yacovm by that, i mean deemphasize

yacovm (Sun, 05 Feb 2017 13:40:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Yh5bGxBuz7BJswHsD) @mastersingh24 +1 for the dual usage of the peer binary. IMO, the code needs to be common but a separate binary needs to be used for CLI.

greg.haskins (Sun, 05 Feb 2017 13:41:06 GMT):
I support a distinct CLI binary as well

mastersingh24 (Sun, 05 Feb 2017 13:41:09 GMT):
If you drop docker-toolbox, Windows users will have to go with Vagrant given Docker for Windows is not support on Win7 - just Win10

mastersingh24 (Sun, 05 Feb 2017 13:41:09 GMT):
If you drop docker-toolbox, Windows users will have to go with Vagrant given Docker for Windows is not supported on Win7 - just Win10

greg.haskins (Sun, 05 Feb 2017 13:41:43 GMT):
@mastersingh24 ok, to be clear, I dont have a desire to drop docker-toolbox, I just didnt think we worked properly with it

yacovm (Sun, 05 Feb 2017 13:42:31 GMT):
Why drop support for vagrant? so much time was invested in that. Is that really so hard to support it? I assume that some people would want to run on native linux and not in docker, and referencing the vagrant environment could be very beneficial.

mastersingh24 (Sun, 05 Feb 2017 13:42:31 GMT):
but to your original point, I do think we need to "rename" the config file(s)

greg.haskins (Sun, 05 Feb 2017 13:42:33 GMT):
one of the things I ran into was that the old docker-toolbox (on mac) was compatible with TCP transports to dockerd, but not unix. And docker-for-mac was compatible with unix transports, but not TCP

greg.haskins (Sun, 05 Feb 2017 13:42:51 GMT):
but saying it out loud, I can imagine why that is not the case on windows ;)

greg.haskins (Sun, 05 Feb 2017 13:42:56 GMT):
(no UDS on windows, for one)

greg.haskins (Sun, 05 Feb 2017 13:43:28 GMT):
but I am confused how this might work on windows, as we do things like volume mount the dockerd UDS

mastersingh24 (Sun, 05 Feb 2017 13:43:30 GMT):
well docker-toolbox uses a Linux-based VM on both Windows and Mac.

greg.haskins (Sun, 05 Feb 2017 13:43:48 GMT):
understood

greg.haskins (Sun, 05 Feb 2017 13:44:03 GMT):
the issue I was seeing was related to how you effectively do docker in docker, so to speak

greg.haskins (Sun, 05 Feb 2017 13:44:16 GMT):
there was a difference between them on mac, and I picked docker-for-mac to be supported

mastersingh24 (Sun, 05 Feb 2017 13:44:36 GMT):
the key is making sure the you run within the Docker terminal. I've used mounts, etc without issue (unless I am confusing which things I've done on which OS's) ;)

greg.haskins (Sun, 05 Feb 2017 13:44:48 GMT):
my assumption was that docker-toolbox was broken all around, but maybe windows still manages to work somehow

mastersingh24 (Sun, 05 Feb 2017 13:45:26 GMT):
do you have a proposal for renaming the config files, etc?

greg.haskins (Sun, 05 Feb 2017 13:45:47 GMT):
we should also quantify the full scope of "supported" because I am running docker-toolbox on this old MacPro and _most_ things work but not all

greg.haskins (Sun, 05 Feb 2017 13:45:58 GMT):
so I do wonder if windows on docker-toolbox is in a similar boat

greg.haskins (Sun, 05 Feb 2017 13:46:04 GMT):
most things work, but not all

greg.haskins (Sun, 05 Feb 2017 13:46:30 GMT):
regarding config name, ill think about it

greg.haskins (Sun, 05 Feb 2017 13:46:40 GMT):
i didnt have anything preconceived

yacovm (Sun, 05 Feb 2017 13:46:45 GMT):
Gari- you mean the core.yaml?

mastersingh24 (Sun, 05 Feb 2017 13:46:53 GMT):
yeah - silly name ;)

greg.haskins (Sun, 05 Feb 2017 13:46:57 GMT):
I just know "core" is not great

yacovm (Sun, 05 Feb 2017 13:47:13 GMT):
why not config.yaml and also rename the orderer.yaml accordingly?

mastersingh24 (Sun, 05 Feb 2017 13:47:32 GMT):
I would probably have something like "peer.yaml" or "peer-config.yaml" and "cli-config.yaml"

yacovm (Sun, 05 Feb 2017 13:47:36 GMT):
also something I thought about in this context- we have viper.Foo in all places in the code but do we have an index for all these knobs?

greg.haskins (Sun, 05 Feb 2017 13:48:12 GMT):
i think something like "config.yaml" is fine if its expected to be in its own dir like /etc/hyperledger/fabric/peer/config.yaml

greg.haskins (Sun, 05 Feb 2017 13:48:18 GMT):
I also like peer.yaml

greg.haskins (Sun, 05 Feb 2017 13:48:22 GMT):
anything is better than "core"

greg.haskins (Sun, 05 Feb 2017 13:48:29 GMT):
but I am just as concerned about the envvar names

greg.haskins (Sun, 05 Feb 2017 13:48:38 GMT):
CORE_ is just asking for collisions/confusion

greg.haskins (Sun, 05 Feb 2017 13:49:09 GMT):
viper is def adding some oddities into this mix

greg.haskins (Sun, 05 Feb 2017 13:49:30 GMT):
on most systems I have ever worked on, the name of the config file is of little consequence

greg.haskins (Sun, 05 Feb 2017 13:49:47 GMT):
because you would just specify the path or accept a default

greg.haskins (Sun, 05 Feb 2017 13:50:08 GMT):
e.g. "peer node start --config /etc/hyperledger/fabric/peer/config.yaml"

greg.haskins (Sun, 05 Feb 2017 13:50:25 GMT):
then, the user can call it "frank.yaml" if they want, I dont care

greg.haskins (Sun, 05 Feb 2017 13:52:16 GMT):
anyway, I will leave you guys with this: be thinking about all of this in terms of what it would look like to do an LSB install of fabric

greg.haskins (Sun, 05 Feb 2017 13:53:06 GMT):
where, traditionally, we might install config to /etc/, binaries to /usr/bin, and set up a writable area in /var

greg.haskins (Sun, 05 Feb 2017 13:55:08 GMT):
and actually, this is related: https://jira.hyperledger.org/browse/FAB-2037?filter=-2

greg.haskins (Sun, 05 Feb 2017 13:56:07 GMT):
we also need to get away from people adding ad-hoc envvars

greg.haskins (Sun, 05 Feb 2017 13:56:09 GMT):
like MSP_CONFIG

mastersingh24 (Sun, 05 Feb 2017 13:56:11 GMT):
I actually don't like Viper (or perhaps our use of Viper). The use of environment variables is "convenient" but also a nightmare

mastersingh24 (Sun, 05 Feb 2017 13:56:40 GMT):
I personally like a nice, simple config file ;)

greg.haskins (Sun, 05 Feb 2017 13:56:54 GMT):
having PEER_CFG_PATH is fine to bootstrap the lack of ability to do --config path/to/config, but from there, everything should be in the config file

greg.haskins (Sun, 05 Feb 2017 13:57:33 GMT):
FAB-2037 would help in that capacity because that msp config could be specified in the config file as absolute or relative path

greg.haskins (Sun, 05 Feb 2017 13:58:13 GMT):
@mastersingh24 i think we are aligned, except I dont mind the envvar overrides and in fact, I think that facility is more conducive to containerization

greg.haskins (Sun, 05 Feb 2017 13:58:35 GMT):
but I would like to see it all be in one file, with a sane name, and support relative paths

greg.haskins (Sun, 05 Feb 2017 13:59:48 GMT):
but I could be convinced otherwise on the envvar thing too...i know we can easily plug new bind-mounts into a container to replace a config file too

greg.haskins (Sun, 05 Feb 2017 14:00:00 GMT):
perhaps ive been too spoiled because they were there

lehors (Sun, 05 Feb 2017 18:05:19 GMT):
Has joined the channel.

JonathanLevi (Sun, 05 Feb 2017 18:32:57 GMT):
Yes, I think that `peer-config.yaml` (, `cli-config.yaml`, `fabric-ca-config.yaml`, ...) is a good convention - certainly better than `core` and `CORE_`

JonathanLevi (Sun, 05 Feb 2017 18:35:23 GMT):
In a way, if we don't want name collusion (in the environment variables) then we should have longer env variable names.

JonathanLevi (Sun, 05 Feb 2017 18:36:20 GMT):
We need to remember to rename all those `CORE_` (to the more globally friendly `PEER_CFG_*`) - and later on, see if we can remove all these.

lehors (Sun, 05 Feb 2017 19:52:27 GMT):
Hi guys. Not to be the whiner here but this is the kind of discussion/decision that we should take to the mailing list so that everyone can get a chance to comment and be informed

lehors (Sun, 05 Feb 2017 19:53:10 GMT):
Tous is not to say we can't discuss it here, just that it would be better if it wasn't only here

lehors (Sun, 05 Feb 2017 19:53:10 GMT):
This is not to say we can't discuss it here, just that it would be better if it wasn't only here

lehors (Sun, 05 Feb 2017 19:54:47 GMT):
As for the topic at hand, I'm all for consistency! :-)

dave.enyeart (Mon, 06 Feb 2017 00:10:50 GMT):
Hi maintainers, verification keeps failing for this one:

dave.enyeart (Mon, 06 Feb 2017 00:10:54 GMT):
https://gerrit.hyperledger.org/r/#/c/5539/

dave.enyeart (Mon, 06 Feb 2017 00:11:10 GMT):
Fails at this point:

dave.enyeart (Mon, 06 Feb 2017 00:11:27 GMT):
19:46:32 [33munit-tests_1 |[0m ok github.com/hyperledger/fabric/core/chaincode/shim 0.028s coverage: 16.8% of statements 19:46:57 [33munit-tests_1 |[0m 2017/02/05 19:46:42 setting Number of procs to -1, was 4

dave.enyeart (Mon, 06 Feb 2017 00:11:32 GMT):
Any ideas?

muralisr (Mon, 06 Feb 2017 00:36:55 GMT):
So @dave.enyeart the test that's failing is `github.com/hyperledger/fabric/core/comm` (comes after `github.com/hyperledger/fabric/core/chaincode/shim`

dave.enyeart (Mon, 06 Feb 2017 00:37:46 GMT):
ok, why i mine failing and not others? my changeset doesnt touch that area

dave.enyeart (Mon, 06 Feb 2017 00:37:46 GMT):
ok, why is mine failing and not others? my changeset doesnt touch that area

muralisr (Mon, 06 Feb 2017 00:38:20 GMT):
yeah...

muralisr (Mon, 06 Feb 2017 00:38:22 GMT):
not sure

muralisr (Mon, 06 Feb 2017 00:39:36 GMT):
worth rebasing perhaps ?

dave.enyeart (Mon, 06 Feb 2017 00:42:56 GMT):
yeah, just rebased and pushed as a new commit:

dave.enyeart (Mon, 06 Feb 2017 00:42:59 GMT):
https://gerrit.hyperledger.org/r/#/c/5553/

dave.enyeart (Mon, 06 Feb 2017 00:43:36 GMT):
prior one had a dependency, maybe that has some impact that i dont understand. new one is stand alone.

muralisr (Mon, 06 Feb 2017 00:44:16 GMT):
ok. lets watch out...

dave.enyeart (Mon, 06 Feb 2017 00:44:22 GMT):
thx

muralisr (Mon, 06 Feb 2017 00:44:26 GMT):
sure!

dave.enyeart (Mon, 06 Feb 2017 02:30:53 GMT):
shucks, https://gerrit.hyperledger.org/r/#/c/5553 also failing at github.com/hyperledger/fabric/core/comm

muralisr (Mon, 06 Feb 2017 02:52:40 GMT):
yes... saw that

muralisr (Mon, 06 Feb 2017 02:55:45 GMT):
@dave.enyeart ...just curious, I see `viper.Set("ledger.blockchain.deploy-system-chaincode", "false")` in the `comm/connection_test.go`

muralisr (Mon, 06 Feb 2017 02:56:08 GMT):
perhaps grasping at straws :-) but what does that ledger setting do ?

muralisr (Mon, 06 Feb 2017 02:58:46 GMT):
I think what's happening is that the comm tests rely upon the peer running in 7051 and its gone for some reason

muralisr (Mon, 06 Feb 2017 03:09:55 GMT):
Any chance that `defer env.TestBlockStorageEnv.Cleanup()` (new in the CR) cause issues with a running container ?

dave.enyeart (Mon, 06 Feb 2017 03:23:14 GMT):
i'll do some trials on my local with make unit-tests

david.peyronnin (Mon, 06 Feb 2017 09:52:41 GMT):
Has joined the channel.

harrijk (Mon, 06 Feb 2017 15:14:22 GMT):
Has joined the channel.

greg.haskins (Mon, 06 Feb 2017 15:41:38 GMT):
one point of discussion: maintainers on the new fabric-chaintool repo in gerrit

greg.haskins (Mon, 06 Feb 2017 15:41:47 GMT):
er, rather, merge policy

greg.haskins (Mon, 06 Feb 2017 15:42:34 GMT):
historically, the gh repo had three maintainers (@muralisr @ecb and myself) and we operated with an effective NACR policy

ecb (Mon, 06 Feb 2017 15:42:34 GMT):
Has joined the channel.

greg.haskins (Mon, 06 Feb 2017 15:42:46 GMT):
I think the new repo in gerrit was setup with 2+2

greg.haskins (Mon, 06 Feb 2017 15:43:08 GMT):
my concern is that will strain the small maintainer pool and question whether we should operate NACR there too

greg.haskins (Mon, 06 Feb 2017 15:43:10 GMT):
thoughts?

greg.haskins (Mon, 06 Feb 2017 15:43:50 GMT):
one difference is I think the maintainer group for gerrit fabric-chaintool mirrors fabric and adds @ecb

greg.haskins (Mon, 06 Feb 2017 15:44:11 GMT):
if that is the case, 2+2 might work if maintainers outside of the core chaintool team do not mind contributing a +2 from time to time

greg.haskins (Mon, 06 Feb 2017 15:44:41 GMT):
@cbf @rjones ^^^

rjones (Mon, 06 Feb 2017 15:46:54 GMT):
@greg.haskins yes, the current configuration is 2+2, with two committer groups: fabric and another group which is just the committers from github (you, @muralisr, @ecb). I don't see much difference between NACR and 2+2 - is anyone that isn't a committer submitting patches?

greg.haskins (Mon, 06 Feb 2017 15:47:29 GMT):
yes, we had 8 contributors though the vast majority of the patches come from me

greg.haskins (Mon, 06 Feb 2017 15:48:03 GMT):
https://github.com/hyperledger/fabric-chaintool/graphs/contributors

rjones (Mon, 06 Feb 2017 15:48:14 GMT):
I have no strong opinion on this :) Just tell me the decision - if you want NACR, NACR you get :)

greg.haskins (Mon, 06 Feb 2017 15:49:05 GMT):
I think the other maintainers should decide

rjones (Mon, 06 Feb 2017 15:49:14 GMT):
yes, agreed

greg.haskins (Mon, 06 Feb 2017 15:49:21 GMT):
my vote would be NACR only because I think we lack a critical mass for 2+2

mastersingh24 (Mon, 06 Feb 2017 15:54:55 GMT):
@greg.haskins - I am ok either way. Perhaps if we get more critical mass for it, we can add additional maintainers, etc. NACR seems fine for now

cbf (Mon, 06 Feb 2017 16:13:55 GMT):
+1 to distinct binary

cbf (Mon, 06 Feb 2017 16:14:51 GMT):
@greg.haskins if you are comfortable with fabric.maintainers + @ecb that works for me

cbf (Mon, 06 Feb 2017 16:15:09 GMT):
but NACR is also fine if you want to retain the current committers

greg.haskins (Mon, 06 Feb 2017 16:16:08 GMT):
to be clear, I have absolutely no problem with all current committers to have commit access

greg.haskins (Mon, 06 Feb 2017 16:16:37 GMT):
i am more concerned about having enough SME critical mass to get 2+2 on a timely basis

greg.haskins (Mon, 06 Feb 2017 16:16:56 GMT):
so if we want to leave it as fabric+ecb but with NACR, that works for me

cbf (Mon, 06 Feb 2017 16:17:14 GMT):
@all so I think we should have a maintainers meeting (virtual) on how we proceed with closure on v1.0-alpha

cbf (Mon, 06 Feb 2017 16:17:42 GMT):
a call might be difficult to arrange and would also be less than transparent

cbf (Mon, 06 Feb 2017 16:17:53 GMT):
however, we could do it here or email

cbf (Mon, 06 Feb 2017 16:19:12 GMT):
topics: documentation, configuration, api/abi lockdown, merge strategy until we cut the v1.0-alpha branch (distinct from the release), and testing

JonathanLevi (Mon, 06 Feb 2017 17:09:14 GMT):
Good morning - here or via email works for me (I'm finally really up!)

JonathanLevi (Mon, 06 Feb 2017 17:10:04 GMT):
BTW: A Fabric logo (that is contributed to the community etc.) is certainly not a bad idea...

mastersingh24 (Mon, 06 Feb 2017 17:42:39 GMT):
I'm on board

JonathanLevi (Mon, 06 Feb 2017 17:48:01 GMT):
Let me just say something to start the conversation maybe, despite the risk of showing my age...

JonathanLevi (Mon, 06 Feb 2017 17:48:09 GMT):
Even when working in Agile, etc... for release, I haven't found any silver bullet that allow us to beat the following: API freeze -> Feature freeze -> Code freeze -> UAT -> Staging -> Release (candidate) -> Release

JonathanLevi (Mon, 06 Feb 2017 17:48:59 GMT):
I interpret: API/ABI freeze/lockdown includes the configuration... that is a form of an input to an interface

JonathanLevi (Mon, 06 Feb 2017 17:49:23 GMT):
Document should follow the API/ABI changes (including where to retrieve the binaries)

JonathanLevi (Mon, 06 Feb 2017 17:49:23 GMT):
Document should follow the API/ABI changes (including from where one/a process should retrieve the binaries)

JonathanLevi (Mon, 06 Feb 2017 17:49:23 GMT):
Documentation should follow the API/ABI changes (including from where one/a process should retrieve the binaries)

JonathanLevi (Mon, 06 Feb 2017 17:51:19 GMT):
--- Slightly separate, but related: I believe that the merge strategy will really require us all to be on the same page (more than some of us focusing on just a few of Fabric's components)

greg.haskins (Mon, 06 Feb 2017 18:17:38 GMT):
related: last time was handled poorly, and @muralisr and I took the brunt of the punishment in the form of resolving everyones patches that were not merged on a regular basis

greg.haskins (Mon, 06 Feb 2017 18:17:43 GMT):
lets avoid that this time ;)

mastersingh24 (Mon, 06 Feb 2017 18:18:12 GMT):
on the other side, I took the brunt of the fact that stuff we put out did not actually work ;)

greg.haskins (Mon, 06 Feb 2017 18:18:22 GMT):
haha, touche

mastersingh24 (Mon, 06 Feb 2017 18:18:30 GMT):
so - we first need to decide what this thing needs to do ;)

greg.haskins (Mon, 06 Feb 2017 18:18:39 GMT):
though we all have been paying for that until recently

mastersingh24 (Mon, 06 Feb 2017 18:18:45 GMT):
indeed

mastersingh24 (Mon, 06 Feb 2017 18:19:12 GMT):
blood, sweat, tears and possibly some of our souls

greg.haskins (Mon, 06 Feb 2017 18:19:41 GMT):
yeah...on a positive note, its rapidly stabilizing

greg.haskins (Mon, 06 Feb 2017 18:20:22 GMT):
for a while there, moving one HEAD was a game of Russian roulette with 5 chambers loaded

greg.haskins (Mon, 06 Feb 2017 18:20:41 GMT):
its much better now

muralisr (Mon, 06 Feb 2017 18:41:33 GMT):
so the simple green path woukd be `create channel(s) -> join channel(s) -> deploy chaincode -> invoke chaincode`

muralisr (Mon, 06 Feb 2017 18:42:16 GMT):
documentation for that from node SDK, and CLI

muralisr (Mon, 06 Feb 2017 18:42:35 GMT):
docker samples for that

muralisr (Mon, 06 Feb 2017 18:43:49 GMT):
bdd pointers for bootstrap

muralisr (Mon, 06 Feb 2017 18:44:24 GMT):
how does that sound ?

yacovm (Mon, 06 Feb 2017 18:53:30 GMT):
So that implies single org, right? (since no fetch and nothing generated with BDD)

muralisr (Mon, 06 Feb 2017 18:56:48 GMT):
correct at will @mastersingh24

muralisr (Mon, 06 Feb 2017 18:56:59 GMT):
:grinning:

muralisr (Mon, 06 Feb 2017 18:57:34 GMT):
(right @yacovm ...that's what I was implying)

yacovm (Mon, 06 Feb 2017 18:59:16 GMT):
what does bdd pointers mean?

vpaprots (Mon, 06 Feb 2017 19:00:59 GMT):
Has joined the channel.

mastersingh24 (Mon, 06 Feb 2017 19:09:21 GMT):
We need to think about what we need to show / get feedback on and I'd say that what @muralisr wrote is not sufficient :( We are now at a point where we need to be able to demonstrate *most* if not *all* of the key attributes of the system: 1) Channels - we've spent a lot of time and effort on this feature and we need to show how it really works. This means we need to be able to have the "proper" config items as part of channel creation - e.g. member organizations (each comprised of an MSP and anchor peers) We need to be able to create multiple channels and have different membership for each channel (at least from a configuration perspective) 2) We need to be able to create channels *properly* from at least one of the SDKs (e.g. Node) and the CLI (although the CLI needs a real overhaul in this aspect as it should be a real client of the orderer) 3) Need to show that we can have peers from multiple organizations "join" a channel. This means that we need to properly parse and leverage the genesis / config block (with proper config items as specified in 1) above) - i.e. use this information in the peer to have per channel MSP list which can be used by both the endorser (to verify proposals from clients) and by gossip (gossip also needs the per channel list of anchor peers as well). We could decide that we should not show gossip across orgs but I think at this point that would be a mistake 4) Endorsement / validation policies - we need to demonstrate how to author a basic policy which requires multiple signatures. Should be able to do this from at least one SDK and from the CLI when deploying chaincode 5) There is a load of crypto material needed for 1) - 4) above so we need to document how to use fabric-ca to generate / obtain this material We have zero real documentation about any of the above items. We need to produce API docs for the SDKs, for fabric-ca (e.g. publish the Swagger), descriptions of the components in 1)- 4) above, etc

mastersingh24 (Mon, 06 Feb 2017 19:09:21 GMT):
We need to think about what we need to show / get feedback on and I'd say that what @muralisr wrote is not sufficient :( We are now at a point where we need to be able to demonstrate *most* if not *all* of the key attributes of the system: 1) Channels - we've spent a lot of time and effort on this feature and we need to show how it really works. This means we need to be able to have the "proper" config items as part of channel creation - e.g. member organizations (each comprised of an MSP and anchor peers) We need to be able to create multiple channels and have different membership for each channel (at least from a configuration perspective) 2) We need to be able to create channels *properly* from at least one of the SDKs (e.g. Node) and the CLI (although the CLI needs a real overhaul in this aspect as it should be a real client of the orderer) 3) Need to show that we can have peers from multiple organizations "join" a channel. This means that we need to properly parse and leverage the genesis / config block (with proper config items as specified in 1) above) - i.e. use this information in the peer to have per channel MSP list which can be used by both the endorser (to verify proposals from clients) and by gossip (gossip also needs the per channel list of anchor peers as well). We could decide that we should not show gossip across orgs but I think at this point that would be a mistake 4) Endorsement / validation policies - we need to demonstrate how to author a basic policy which requires multiple signatures. Should be able to do this from at least one SDK and from the CLI when deploying chaincode 5) There is a load of crypto material needed for 1) - 4) above so we need to document how to use fabric-ca to generate / obtain this material 6) We need to have published Docker images for the peer, orderer and fabric-ca plus NodeSDK published to NPM and if we are going to put out the Java SDK need to have a downloadable JAR and/or install via maven or gradle We have zero real documentation about any of the above items. We need to produce API docs for the SDKs, for fabric-ca (e.g. publish the Swagger), descriptions of the components in 1)- 4) above, etc

mastersingh24 (Mon, 06 Feb 2017 19:09:21 GMT):
We need to think about what we need to show / get feedback on and I'd say that what @muralisr wrote is not sufficient :( We are now at a point where we need to be able to demonstrate *most* if not *all* of the key attributes/features of the system: 1) Channels - we've spent a lot of time and effort on this feature and we need to show how it really works. This means we need to be able to have the "proper" config items as part of channel creation - e.g. member organizations (each comprised of an MSP and anchor peers) We need to be able to create multiple channels and have different membership for each channel (at least from a configuration perspective) 2) We need to be able to create channels *properly* from at least one of the SDKs (e.g. Node) and the CLI (although the CLI needs a real overhaul in this aspect as it should be a real client of the orderer) 3) Need to show that we can have peers from multiple organizations "join" a channel. This means that we need to properly parse and leverage the genesis / config block (with proper config items as specified in 1) above) - i.e. use this information in the peer to have per channel MSP list which can be used by both the endorser (to verify proposals from clients) and by gossip (gossip also needs the per channel list of anchor peers as well). We could decide that we should not show gossip across orgs but I think at this point that would be a mistake 4) Endorsement / validation policies - we need to demonstrate how to author a basic policy which requires multiple signatures. Should be able to do this from at least one SDK and from the CLI when deploying chaincode 5) There is a load of crypto material needed for 1) - 4) above so we need to document how to use fabric-ca to generate / obtain this material 6) We need to have published Docker images for the peer, orderer and fabric-ca plus NodeSDK published to NPM and if we are going to put out the Java SDK need to have a downloadable JAR and/or install via maven or gradle We have zero real documentation about any of the above items. We need to produce API docs for the SDKs, for fabric-ca (e.g. publish the Swagger), descriptions of the components in 1)- 4) above, etc

mastersingh24 (Mon, 06 Feb 2017 19:58:44 GMT):
BUT - there's light at the end of the tunnel here. Although maybe the above looks daunting, other than the doc piece we are not *that* far off

mastersingh24 (Mon, 06 Feb 2017 19:58:44 GMT):
BUT - there's light at the end of the tunnel here. Although maybe the above looks daunting, other than the doc piece we are *not that far off*

muralisr (Mon, 06 Feb 2017 20:24:47 GMT):
regardless that list above looks more right and complete than the simplistic "green path" of mine

muralisr (Mon, 06 Feb 2017 20:24:58 GMT):
we need to just make that happen :-) @mastersingh24

weeds (Mon, 06 Feb 2017 20:25:22 GMT):
Has joined the channel.

mastersingh24 (Mon, 06 Feb 2017 20:37:28 GMT):
so fellow maintainers, how do we make this happen? or something else if anyone has other thoughts?

cbf (Mon, 06 Feb 2017 21:34:11 GMT):
@mastersingh24 +1

JonathanLevi (Mon, 06 Feb 2017 21:40:33 GMT):
I agree and kept a bit quiet after my first round of feedback/input - as I would like to hear/get more input (from others) if possible, in case we miss anything.

JonathanLevi (Mon, 06 Feb 2017 21:41:07 GMT):
In the interim: @mastersingh24 +1

tarima (Tue, 07 Feb 2017 01:10:46 GMT):
Has joined the channel.

binhn (Tue, 07 Feb 2017 03:34:06 GMT):
Has joined the channel.

binhn (Tue, 07 Feb 2017 03:35:32 GMT):
we need some feedback/comment on https://gerrit.hyperledger.org/r/#/c/5555 -- detail in the associated fab-1783

binhn (Tue, 07 Feb 2017 03:35:47 GMT):
i posted my vote in the comment of the CR

binhn (Tue, 07 Feb 2017 03:43:06 GMT):
@mastersingh24 now we are getting greedy

crazybit (Tue, 07 Feb 2017 05:32:37 GMT):
Has joined the channel.

cbf (Tue, 07 Feb 2017 12:15:55 GMT):
@jyellick @hgabre please weigh in on @mastersingh24 proposal above

hgabre (Tue, 07 Feb 2017 12:15:55 GMT):
Has joined the channel.

jyellick (Tue, 07 Feb 2017 13:56:23 GMT):
@cbf I think @mastersingh24 is spot on. Here is my response from an orderer perspective. 1. Due to some deficiencies in the configtx discovered during integration, there are some changes coming in that path, but they should be relatively isolated inside the centralized config parsing code, so should not have a significant impact on the actual consumers of the configuration. 2. The changes in (1) will make this a little tricky for the next few days while the configtx format changes slightly. This is because the SDKs are producers of configuration and are therefore not as isolated as the consumers. But, the end result should actually make life easier for the SDKs. 3. To my knowledge this is essentially complete, the orderer and peer are both parsing MSPs from the configtx, and the peer specific MSP mgmt map has been integrated with the configtx manager. I say this with total confidence for the orderer code, but I do not know the peer code as well and it could probably use a quick audit for MSP usage. One of the deficiencies of the current config structure involves the association between anchor peer and org, to be addressed in (1). 4. Orderer independent. 5. Agreed. This is a bit of a pain point for us generating a valid genesis block / configtx right now. 6. Agreed.

cbf (Tue, 07 Feb 2017 14:00:36 GMT):
@jyellick perfect, thanks

cbf (Tue, 07 Feb 2017 14:02:27 GMT):
@tamas @sheehan when you get a chance, please join us over in rocket.chat https://hyperledgerproject.slack.com/archives/general/p1486475686004850

tamas (Tue, 07 Feb 2017 14:02:28 GMT):
Has joined the channel.

tamas (Tue, 07 Feb 2017 14:03:19 GMT):
thanks for the heads-up @cbf

Dan (Tue, 07 Feb 2017 14:38:52 GMT):
Has joined the channel.

smithbk (Tue, 07 Feb 2017 14:41:16 GMT):
Has joined the channel.

jyellick (Tue, 07 Feb 2017 14:53:38 GMT):
Before cutting alpha, I really think we need to resolve https://jira.hyperledger.org/browse/FAB-2026

brianeno (Tue, 07 Feb 2017 14:55:30 GMT):
Has joined the channel.

yacovm (Tue, 07 Feb 2017 14:57:19 GMT):
If we resolve this, we need to add the gossip proto too to the list I guess

jyellick (Tue, 07 Feb 2017 14:58:54 GMT):
Ah yes, the gossip protos were not under `protos` when I made my pass through this, so I missed htem.

jyellick (Tue, 07 Feb 2017 14:58:54 GMT):
Ah yes, the gossip protos were not under `protos` when I made my pass through this, so I missed them.

yacovm (Tue, 07 Feb 2017 14:59:43 GMT):
I was supposed to move them long ago but it got delayed, totally my fault :)

vpaprots (Tue, 07 Feb 2017 15:08:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=FNvpQM7DduH26sJhd) @mastersingh24 (5) is the one I am most interested in. Any takers there? Can be volunteered... I would like a tool under fabric (would write one too if OKed) to generated keys via BCCSP interface. Today they are standard PEM files which limits it to either SW BCCSP or key imports (not always possible).

mastersingh24 (Tue, 07 Feb 2017 15:15:35 GMT):
we should use fabric-ca - but it's got bccsp anyway

mastersingh24 (Tue, 07 Feb 2017 15:15:51 GMT):
we can figure out what we need to do

adc (Tue, 07 Feb 2017 15:19:49 GMT):
Has joined the channel.

jimthematrix (Tue, 07 Feb 2017 15:20:14 GMT):
@mastersingh24 for 2) above, it'll be a bit of work for the node (or java for that matter) SDK to complete the create/join channels support, the squad hasn't focused on that with the understanding that it's not part of the alpha plan. so this is a change from two weeks ago right? we can do it but just need more time (like this week)

mastersingh24 (Tue, 07 Feb 2017 15:20:50 GMT):
I think we need to be able to drive it from one of the SDKs to prove the externals actually work

cbf (Tue, 07 Feb 2017 15:21:02 GMT):
+1

jimthematrix (Tue, 07 Feb 2017 15:21:06 GMT):
ok, i can get started on it right away

elli-androulaki (Tue, 07 Feb 2017 15:21:06 GMT):
Has joined the channel.

jimthematrix (Tue, 07 Feb 2017 15:22:06 GMT):
do we prefer using templates for the create channel step?

mastersingh24 (Tue, 07 Feb 2017 15:22:17 GMT):
check in with Jason as we are likely to have some changes to create channel

jimthematrix (Tue, 07 Feb 2017 15:22:18 GMT):
or it doesn't matter?

mastersingh24 (Tue, 07 Feb 2017 15:22:33 GMT):
I think you want to "hide" as much as possible

jimthematrix (Tue, 07 Feb 2017 15:22:34 GMT):
yes that's another reason we've been holding off this work

jimthematrix (Tue, 07 Feb 2017 15:22:41 GMT):
the pending changes that Jason mentioned to us

jimthematrix (Tue, 07 Feb 2017 15:22:53 GMT):
ok will double check with him to make sure that work is in

simsc (Tue, 07 Feb 2017 15:46:33 GMT):
Has joined the channel.

cbf (Tue, 07 Feb 2017 16:05:58 GMT):
all, not sure if you saw @binhn's comment yesterday, but there is a new proposal for how the system deals with deploying chaincode that could use everyone's input

cbf (Tue, 07 Feb 2017 16:06:01 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=aq3TZffhkjnGBMt5T

cbf (Tue, 07 Feb 2017 16:06:38 GMT):
This proposal will have significant impact, so please review and comment in JIRA and/or here

cbf (Tue, 07 Feb 2017 16:06:59 GMT):
@all ^^

rascal-3 (Tue, 07 Feb 2017 16:07:55 GMT):
Has joined the channel.

kostas (Tue, 07 Feb 2017 16:09:48 GMT):
Has joined the channel.

JonathanLevi (Tue, 07 Feb 2017 16:14:35 GMT):
@cbf: Yes, will do. @vpaprots: "Today they are standard PEM files which limits it to either SW BCCSP or key imports (not always possible)."

JonathanLevi (Tue, 07 Feb 2017 16:15:25 GMT):
I agree that fabric-ca should be the "go-to" place for such generations. Do we have a place where the requirements/limitations are listed out? Can I assist in any way?

vpaprots (Tue, 07 Feb 2017 16:16:15 GMT):
I had created a whole slew of JIRA items a while back..

JonathanLevi (Tue, 07 Feb 2017 16:16:27 GMT):
Mind you, I go around telling everybody how we always use very basic crypto constructs/primitives (don't know if you care to listen to my talks ;-)), but if this changes... then let's document and communicate accordingly.

JonathanLevi (Tue, 07 Feb 2017 16:16:39 GMT):
Before we cut an alpha! ;-)

JonathanLevi (Tue, 07 Feb 2017 16:16:55 GMT):
I'll PM you.

rjones (Tue, 07 Feb 2017 18:00:04 GMT):
please migrate to https://chat.hyperledger.org

cbf (Tue, 07 Feb 2017 19:32:07 GMT):
@greg.haskins are you GTG to merge all the chaintool CRs?

cbf (Tue, 07 Feb 2017 19:32:14 GMT):
I can push the button if you like

ecb (Tue, 07 Feb 2017 20:09:17 GMT):
@cbf - thank you, you just beat me to it.

elli-androulaki (Tue, 07 Feb 2017 20:20:27 GMT):
Hi, for the crypto-squad Jira items under fabric-crypto, and Sprint 11 contain the list of pending items that correspond to @mastersingh24 's list. In summary, our pending work items, blockers and estimated effort in PDs (= Person Days): 1) Channel ACL in endorser, orderer, and gossip logic [~ 2 x 3 PDs]. We are blocked by channel policy setup through genesis, and pending design on LCCC instantiation 2) Minimum level of replay protection [0.5 PD] 3) MSP-implementation completion (intermediate CAs, admin/OrganizationUnit) [1.5 PD] 4) Code todos that are not covered by the items listed before 5) Application libraries for ACL [ETA: end of month] 6) Research paper (ETA: end of month) 7) Security review of new designs in CC2CC, deployment model, and reconfiguration

simsc (Tue, 07 Feb 2017 20:32:13 GMT):
thanks elli

beauson45 (Tue, 07 Feb 2017 20:58:21 GMT):
Has joined the channel.

jimthematrix (Tue, 07 Feb 2017 21:17:35 GMT):
for @mastersingh24 's list of six, the following are needed in SDK: FAB-687, FAB-1263

smithbk (Tue, 07 Feb 2017 21:39:54 GMT):
Here is what I think remains for fabric-ca

smithbk (Tue, 07 Feb 2017 21:39:57 GMT):
https://jira.hyperledger.org/browse/FAB-2012 Update fabric-ca CLI to use cobra & viper https://jira.hyperledger.org/browse/FAB-1477 BCCSP integration (ecert, tcert, auth header, etc) https://jira.hyperledger.org/browse/FAB-1463 TLS for LDAP client of fabric-ca-server https://jira.hyperledger.org/browse/FAB-2095 Document fabric-ca usage by fabric

yacovm (Tue, 07 Feb 2017 21:44:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=z55tEviaq32dd9Jcd) &> #fabric-pr-review

smithbk (Tue, 07 Feb 2017 21:52:50 GMT):
Minor change to the list above ... replacing the 2nd jira item with one with better description

smithbk (Tue, 07 Feb 2017 21:52:52 GMT):
https://jira.hyperledger.org/browse/FAB-2012 Update fabric-ca CLI to use cobra & viper https://jira.hyperledger.org/browse/FAB-2110 Complete BCCSP integration for fabric-ca https://jira.hyperledger.org/browse/FAB-1463 TLS for LDAP client of fabric-ca-server https://jira.hyperledger.org/browse/FAB-2095 Document fabric-ca usage by fabric

C0rWin (Tue, 07 Feb 2017 22:40:24 GMT):
Hi, for gossip-squad to items correspond to https://chat.hyperledger.org/channel/fabric-maintainers?msg=FNvpQM7DduH26sJhd Are: 1. [FAB - 1846] Connection between delivery client and leader election 2. [FAB - 2007] Make gossip publish external endpoints to peers from other organizations 3. [FAB - 1938] Make delivery client to track the availability of ordering service 4. [FAB - 2016] Add organization ids into GossipMessage 5. [FAB - 1845] Gossip message store timely expiraton 6. [FAB - 1879] Connect gossip configuration to core.yaml file

C0rWin (Tue, 07 Feb 2017 22:40:24 GMT):
Hi, for gossip-squad to items correspond to @mastersingh24 list, are: 1. [FAB - 1846] Connection between delivery client and leader election 2. [FAB - 2007] Make gossip publish external endpoints to peers from other organizations 3. [FAB - 1938] Make delivery client to track the availability of ordering service 4. [FAB - 2016] Add organization ids into GossipMessage 5. [FAB - 1845] Gossip message store timely expiraton 6. [FAB - 1879] Connect gossip configuration to core.yaml file

C0rWin (Tue, 07 Feb 2017 22:40:24 GMT):
Hi, for gossip-squad to items correspond to @mastersingh24 list, are: 1. [FAB - 1846] Connection between delivery client and leader election 2. [FAB - 2007] Make gossip publish external endpoints to peers from other organizations 3. [FAB - 1938] Make delivery client to track the availability of ordering service 4. [FAB - 2061] Add organization ids into GossipMessage 5. [FAB - 1845] Gossip message store timely expiraton 6. [FAB - 1879] Connect gossip configuration to core.yaml file

sanchezl (Tue, 07 Feb 2017 23:35:31 GMT):
Has joined the channel.

rjones (Tue, 07 Feb 2017 23:39:25 GMT):
Maintainers: please +1 the creation of the fabric-docs repo that we discussed in SFO: https://jira.hyperledger.org/browse/FAB-2114 please vote for the issue in JIRA directly

patchpon (Wed, 08 Feb 2017 01:16:07 GMT):
Has joined the channel.

peter (Wed, 08 Feb 2017 05:49:45 GMT):
Has joined the channel.

cbf (Wed, 08 Feb 2017 14:20:44 GMT):
@all @mastersingh24 @lehors and I were just discussing a few things and the subject of the alpha release came up (what a surprise!)

cbf (Wed, 08 Feb 2017 14:21:20 GMT):
clearly there is a lot of interest on the part of people coming to the project to have v1.0 images that they can use and explore

cbf (Wed, 08 Feb 2017 14:21:39 GMT):
yet, as we have discussed, we aren't really ready for alpha

cbf (Wed, 08 Feb 2017 14:24:23 GMT):
one compromise we discussed, which I think the three of us agreed would be worth considering, was to take the images we created for the hackfest last week, and publish those to dockerhub/u/hyperledger as fabric-xxx:v1.0-preview images - update the docs accordingly so that they gettingstarted.md points to these images and promote it as ready for developer preview.

cbf (Wed, 08 Feb 2017 14:24:53 GMT):
basically, we would not release these from a build (there's some additional bootstrap cruft that makes this intenable just yet)

cbf (Wed, 08 Feb 2017 14:28:41 GMT):
I created a JIRA to track this... if you agree, please vote on the issue https://jira.hyperledger.org/browse/FAB-2123

chris.elder (Wed, 08 Feb 2017 14:34:31 GMT):
Has joined the channel.

weeds (Wed, 08 Feb 2017 14:42:07 GMT):
Currently, there are a lot of changes how we manage configuration and that will ripple through MSP, policy and other things. Jason is hoping to be done by Friday. So next week, we will have something running.

weeds (Wed, 08 Feb 2017 14:42:20 GMT):
(Jason Yellick)

weeds (Wed, 08 Feb 2017 14:43:05 GMT):
Crytpo team can not progress until Jason's piece is done- we need policy framework and the genesis block to be complete to do the access control

weeds (Wed, 08 Feb 2017 14:43:31 GMT):
Jim Zhang said he can do the MSP initialization in paralell.

weeds (Wed, 08 Feb 2017 14:50:06 GMT):
Jim Zhang-> We need to update the protobufs (Jason is planning for more change)... once we got MSP initialization done, we need to consider how configuration is loaded and what is vehicle for that along with configuration block... That finishes off Gari's scenario. For remainder of release-- main piece are TCERT support.. managing TCERTs is complex... Another piece on SDK Verify responses, signature verification and policy verification on proposal response and need APIs for that. (this we have to have on verify)

weeds (Wed, 08 Feb 2017 14:51:58 GMT):
Jim Zhang- rest api wrapper... it falls now with another team to Ian Mitchell, but seems like that may come back to Jim- we were trying to get primitive APIs into SDK.

dave.enyeart (Wed, 08 Feb 2017 15:53:44 GMT):
@mastersingh24 I'd recommend adding a 7th item to your list. Here's the key ledger work items remaining.

dave.enyeart (Wed, 08 Feb 2017 15:54:31 GMT):
7) Clients need an expanded set of ledger APIs to meet solution requirements. For example to perform queries as part of transactions, to perform rich queries against the ledger data, and to understand the history of keys for simple provenance scenarios. FAB-1667 - Finalize ledger APIs in Query System Chaincode (QSCC) FAB-2124 - Finalize ledger chaincode APIs FAB-1502 - Ledger history: I want a chaincode API to see the history of key values FAB-787 As a fabric deployer, I want a CouchDB docker image that can be deployed with a fabric network

cbf (Wed, 08 Feb 2017 16:46:08 GMT):
@all maintainers, please vote on https://jira.hyperledger.org/browse/FAB-2114 and https://jira.hyperledger.org/browse/FAB-2123 or leave comments if you disagree so that we can move forward

muralisr (Wed, 08 Feb 2017 16:49:28 GMT):
@cbf I stayed quiet as I don't know submodules ... it seems to be a good way to organize but I sensed there were "things to be cautious about " in this approach and was hoping others with more knowledge would weigh in with pros (and cons/caution if any)

muralisr (Wed, 08 Feb 2017 16:50:03 GMT):
^^ was for https://jira.hyperledger.org/browse/FAB-2114

yacovm (Wed, 08 Feb 2017 16:51:50 GMT):
@cbf I tried to comment twice on https://jira.hyperledger.org/browse/FAB-2123 but my comment doesn't show on JIRA from some reason.

yacovm (Wed, 08 Feb 2017 16:52:38 GMT):
But I simply stated I think the script there can be fixed with https://gerrit.hyperledger.org/r/#/c/5691/ (after testing it, of course)

muralisr (Wed, 08 Feb 2017 16:53:24 GMT):
@yacovm I see your comment...

yacovm (Wed, 08 Feb 2017 16:53:43 GMT):
weird, I refreshed and nothing. Eventual consistency FTW I guess

cbf (Wed, 08 Feb 2017 16:53:46 GMT):
@muralisr submodules can be complex to manage, but as noted, opensaylight is using this approach with success so we have some sister projects using it and who have experience doing so

cbf (Wed, 08 Feb 2017 16:53:55 GMT):
@yacovm lol

cbf (Wed, 08 Feb 2017 16:54:05 GMT):
maybe had to reach concensus

cbf (Wed, 08 Feb 2017 16:54:05 GMT):
maybe had to reach consensus

yacovm (Wed, 08 Feb 2017 16:54:22 GMT):
aha, now I see with private browsing (bypasses browser cache)

yacovm (Wed, 08 Feb 2017 16:54:22 GMT):
aha, now I see with private browsing (bypasses browser cache) --- Update: re-logged into JIRA and now I see.

muralisr (Wed, 08 Feb 2017 16:55:36 GMT):
@cbf good enough for me.. seems a step in the right direction (and better than status quo in any case)

muralisr (Wed, 08 Feb 2017 16:56:13 GMT):
(thanks for that , btw, it helped!)

binhn (Wed, 08 Feb 2017 18:10:22 GMT):
@cbf on the submodules, would a code change that requires doc change end up with 2 separate CR's? 1 on the repo and another for fabric-docs repo

cbf (Wed, 08 Feb 2017 18:40:57 GMT):
no, a git submodule is akin to a symlink but versioned

cbf (Wed, 08 Feb 2017 18:41:54 GMT):
so if you have repo A as a submodule of repo B and make a change in repo A, when you bump the commit level of the submodule for A it picks up the latest changes reflected at that commit level

troyronda (Wed, 08 Feb 2017 18:44:31 GMT):
Has joined the channel.

greg.haskins (Wed, 08 Feb 2017 19:00:19 GMT):
I think binh is correct though

greg.haskins (Wed, 08 Feb 2017 19:00:47 GMT):
well, at least w.r.t. the doc becoming visible via the fabric-doc repo

greg.haskins (Wed, 08 Feb 2017 19:01:16 GMT):
There would be a CR to the official repo, and then a sep CR to fabric-doc to make the change visible

greg.haskins (Wed, 08 Feb 2017 19:02:25 GMT):
Just to reiterate, submodules have still left me with a bad taste in my mouth, proceed with caution

greg.haskins (Wed, 08 Feb 2017 19:03:19 GMT):
very very fragile experience, especially for anyone not a git expert

greg.haskins (Wed, 08 Feb 2017 19:04:30 GMT):
conceptually its a great idea, and I understand why its desired...just submodules themselves might be a fragile way to do it

greg.haskins (Wed, 08 Feb 2017 19:05:29 GMT):
we might be better served with something more direct, like a script where the pointers may be changed

kelly_ (Wed, 08 Feb 2017 19:21:37 GMT):
Has joined the channel.

rjones (Wed, 08 Feb 2017 20:20:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=qX5zLTRJcsiMDFTdZ) I need 3 more votes: @greg.haskins @JonathanLevi @hgabre @binhn @jimthematrix @jyellick @sheehan @TamasBlummer

rjones (Wed, 08 Feb 2017 20:20:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=qX5zLTRJcsiMDFTdZ) I need 4 more votes: @greg.haskins @JonathanLevi @hgabre @binhn @jimthematrix @jyellick @sheehan @TamasBlummer

TamasBlummer (Wed, 08 Feb 2017 20:20:19 GMT):
Has joined the channel.

jimthematrix (Wed, 08 Feb 2017 20:37:09 GMT):
@rjones @cbf I would vote yes for a consolidated repo for docs, but on the use of submodules, i haven't used it myself but it sounds like those who have (Greg, Binh) are expressing concerns. @dshuffma @daveryIBM are using submodules in the updated marbles repo, would like them to weigh in on their experience...

jimthematrix (Wed, 08 Feb 2017 20:37:09 GMT):
@rjones @cbf I would vote yet for a consolidated repo for docs, but on the use of submodules, i haven't used it myself but it sounds like those who have (Greg, Binh) are expressing concerns. @dshuffma @daveryIBM are using submodules in the updated marbles repo, would like them to weigh in on their experience...

daveryIBM (Wed, 08 Feb 2017 20:37:09 GMT):
Has joined the channel.

dshuffma (Wed, 08 Feb 2017 20:37:09 GMT):
Has joined the channel.

cbf (Wed, 08 Feb 2017 20:37:55 GMT):
@jimthematrix what other options are there? It is important to keep the code and docs consistent

cbf (Wed, 08 Feb 2017 20:38:23 GMT):
I DO NOT want to be juggling docs with varying versions of the various sub-components

cbf (Wed, 08 Feb 2017 20:38:32 GMT):
that will be rather messy

jimthematrix (Wed, 08 Feb 2017 20:41:54 GMT):
so for the parts of the doc that need to be hand-written, the main thing is for the maintainer of the docs to be diligent and keep the content up to date, which is a manual process anyway. for the generated part of the doc, like the html derived from javadoc/jsdoc, we can have CI jobs that publishes to the fabric-docs. did I miss anything?

greg.haskins (Wed, 08 Feb 2017 20:51:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=BKjExp8gc46vcdoQG) @cbf I assume you were asking w.r.t. submodules?

cbf (Wed, 08 Feb 2017 20:51:45 GMT):
yes

cbf (Wed, 08 Feb 2017 20:52:21 GMT):
basically, I think we want the docs to be bound to the code from a versioning perspective

cbf (Wed, 08 Feb 2017 20:52:37 GMT):
so the content stays in the repos where it is now

greg.haskins (Wed, 08 Feb 2017 20:52:38 GMT):
one thing I can think of is something as simple as a script that references versioned URLs like https://github.com/hyperledger/fabric/tree/f7c19f88e824cbaea3c55bc218b3bbed37cc29ad/docs

cbf (Wed, 08 Feb 2017 20:52:51 GMT):
and slurp in?

greg.haskins (Wed, 08 Feb 2017 20:52:59 GMT):
its effectively just as coupled as submodules, but without the git-odditites

cbf (Wed, 08 Feb 2017 20:53:08 GMT):
that's effectively what submodules to but clumsier, no?

greg.haskins (Wed, 08 Feb 2017 20:53:08 GMT):
yeah, something like that

greg.haskins (Wed, 08 Feb 2017 20:53:09 GMT):
wget

greg.haskins (Wed, 08 Feb 2017 20:53:34 GMT):
its effectively the same thing, yes, but there is some operational challenges with submodules that wouldnt exist

greg.haskins (Wed, 08 Feb 2017 20:53:51 GMT):
its less elegant, but also less complicated/fragile

greg.haskins (Wed, 08 Feb 2017 20:54:15 GMT):
what ends up happening in practice (IMO) is the submodule metadata gets messed up by users

greg.haskins (Wed, 08 Feb 2017 20:54:39 GMT):
that wouldnt be the case in a simple script, nor would it require extra care/knowledge to use

greg.haskins (Wed, 08 Feb 2017 20:55:29 GMT):
what I found is that invariably users will do things like move the git refspec but not refresh the submodules: calamity

greg.haskins (Wed, 08 Feb 2017 20:55:43 GMT):
or accidentally modify the submodule: calamity

greg.haskins (Wed, 08 Feb 2017 20:55:52 GMT):
or any number of other things: calamity

greg.haskins (Wed, 08 Feb 2017 20:55:52 GMT):
heh

greg.haskins (Wed, 08 Feb 2017 20:57:25 GMT):
to be clear, this is just my advice

greg.haskins (Wed, 08 Feb 2017 20:57:34 GMT):
if you want to try to manage it this way, go for it

cbf (Wed, 08 Feb 2017 21:08:04 GMT):
well, my take is a) we have a fairly simple setup b) I would not expect us to be changing things except the refspec periodically, tied with a release

cbf (Wed, 08 Feb 2017 21:08:54 GMT):
and 3) we have multiple eyes on things with 2+2 so I would hope we would catch any calamitous errors

greg.haskins (Wed, 08 Feb 2017 21:13:53 GMT):
yeah, the review process should highlight very clearly when the submodule meta data is changing

greg.haskins (Wed, 08 Feb 2017 21:14:05 GMT):
by that, i mean, it will

greg.haskins (Wed, 08 Feb 2017 21:14:50 GMT):
(ive worked on other projects where it had committers without a UI approval process, so sometimes you ahve to go untangle an inadvertent change to submodules after the fact

greg.haskins (Wed, 08 Feb 2017 21:15:10 GMT):
i would think we would catch that early in this setup

greg.haskins (Wed, 08 Feb 2017 21:23:27 GMT):
@mastersingh24 https://gerrit.hyperledger.org/r/#/c/5749/

greg.haskins (Wed, 08 Feb 2017 21:23:46 GMT):
still WIP as I need to add a few tests, but wanted to give an early preview

greg.haskins (Wed, 08 Feb 2017 21:24:53 GMT):
@muralisr ^^^

muralisr (Wed, 08 Feb 2017 21:34:08 GMT):
very cool @greg.haskins ... will look closer tonight (CI is running anyway)

muralisr (Wed, 08 Feb 2017 21:34:48 GMT):
one half-baked thought which can be freely ignored :-)

muralisr (Wed, 08 Feb 2017 21:36:40 GMT):
`From string ` in BuildSpec seems to suggest generalization to other types of substiutions and perhaps calls for `map[dockercmd]func() error` ?

muralisr (Wed, 08 Feb 2017 21:37:07 GMT):
certainly could be a future thought if interesting

greg.haskins (Wed, 08 Feb 2017 22:04:39 GMT):
@muralisr actually I think we need to refactor the relationship between controller and platform

greg.haskins (Wed, 08 Feb 2017 22:05:23 GMT):
right now, theres a few layering violations in the sense that the controller accepts the notion of an io.Reader (and later, BuildSpecFactor->BuildSpec

greg.haskins (Wed, 08 Feb 2017 22:05:58 GMT):
what I think we should probably do is have the container details encapsulated in the VM interface

greg.haskins (Wed, 08 Feb 2017 22:06:42 GMT):
e.g. have platform return a VM instance, which can have the details such as From, io.Reader, args, buried in it

greg.haskins (Wed, 08 Feb 2017 22:06:53 GMT):
but that is a bigger change, didnt want to tackle now

greg.haskins (Wed, 08 Feb 2017 22:07:19 GMT):
for now, just perpetuating the layering violation, as it was already there to begin with in some form

greg.haskins (Wed, 08 Feb 2017 22:07:41 GMT):
on the front of docker args, I think we need two fundamental changes:

greg.haskins (Wed, 08 Feb 2017 22:07:53 GMT):
1) the platform should be in charge of them

greg.haskins (Wed, 08 Feb 2017 22:08:18 GMT):
2) we could/should look to unifying the args as some kind of ENTRYPOINT standard

greg.haskins (Wed, 08 Feb 2017 22:08:47 GMT):
e.g. all docker containers are started in the same way (regardless of clang)

greg.haskins (Wed, 08 Feb 2017 22:09:11 GMT):
this will become more important when chaintool is supporting more than just golang

greg.haskins (Wed, 08 Feb 2017 22:09:22 GMT):
(but I think it also cleans things up)

mastersingh24 (Wed, 08 Feb 2017 22:10:03 GMT):
@greg.haskins - what about options for logging? for example, what if people don't want to use syslog for the Docker daemon but want to configure it for the chaincode containers? Or by platform you still mean we can drive some parameters from the YAML config?

greg.haskins (Wed, 08 Feb 2017 22:10:18 GMT):
that seems logical to me

greg.haskins (Wed, 08 Feb 2017 22:10:48 GMT):
by platform, i was referring to the platform abstraction in the code

greg.haskins (Wed, 08 Feb 2017 22:11:19 GMT):
https://github.com/hyperledger/fabric/blob/master/core/chaincode/platforms/platforms.go

greg.haskins (Wed, 08 Feb 2017 22:11:59 GMT):
I see no problem with the notion that we can make the exposed logging routable

greg.haskins (Wed, 08 Feb 2017 22:12:09 GMT):
and then let the platform driver decide how to do that

greg.haskins (Wed, 08 Feb 2017 22:12:37 GMT):
for instance, "SYSLOG" might cause the docker driver to enable the dockerd routing to syslog

mastersingh24 (Wed, 08 Feb 2017 22:12:59 GMT):
cool - figured as much

greg.haskins (Wed, 08 Feb 2017 22:13:07 GMT):
whereas perhaps the inproccontainer would need some golang mechanism

mastersingh24 (Wed, 08 Feb 2017 22:13:40 GMT):
I'd actually like to see if someday we can try backends other than Docker for running chaincode - for example going directly to runc instead (which conveniently supports Docker archives)

greg.haskins (Wed, 08 Feb 2017 22:14:04 GMT):
sounds good to me

mastersingh24 (Wed, 08 Feb 2017 22:15:23 GMT):
and you know I have a dream about using unikernels (for no other reason than it seems cool ;) )

jyellick (Wed, 08 Feb 2017 22:45:45 GMT):
Could we get the maintainers to vote on the below? https://jira.hyperledger.org/browse/FAB-2026 https://gerrit.hyperledger.org/r/#/c/5507/ https://gerrit.hyperledger.org/r/#/c/5509/ https://gerrit.hyperledger.org/r/#/c/5521/ Per @binhn he does not like switching to the official proto style guide. I find this understandable, as it does make reading the golang code slightly less nice, especially with respect to abbreviations like "ID". That being said, we are all over the place with our proto conventions. In some places we are using UpperCamelCase for fields, in some places lower_underscore_separated, and in some places lowerCamelCase. Being on the fence about what's best, my default is "Go with the official style guide", but regardless of what we choose, I'd say we should pick a style, and enforce it. I'm happy to rebase and fix up the above CRs, but don't want to do it, until we have a consensus.

yacovm (Wed, 08 Feb 2017 22:49:55 GMT):
Did we already merge some of the changes?

yacovm (Wed, 08 Feb 2017 22:49:55 GMT):
Did we already merge some of the changes? @jyellick

yacovm (Wed, 08 Feb 2017 22:50:10 GMT):
And- how much work is left to be done?

yacovm (Wed, 08 Feb 2017 22:50:16 GMT):
I think this also needs to be considered

jyellick (Wed, 08 Feb 2017 22:51:42 GMT):
I do not believe any of the proto style changes have been merged

binhn (Wed, 08 Feb 2017 22:52:37 GMT):
@jyellick I agreed that we need to be consistent in proto, whichever style we pick

binhn (Wed, 08 Feb 2017 22:53:18 GMT):
we just need to be diligent and make sure that since there's no tool to help scan the code

binhn (Wed, 08 Feb 2017 22:54:12 GMT):
I personally don't like the proto style because it recommends 1 style and it generates another

binhn (Wed, 08 Feb 2017 22:55:17 GMT):
but I am ok with being consistent, so if you already changed them all, let's go with that rather than undo

jyellick (Wed, 08 Feb 2017 22:55:32 GMT):
Of course the generation is language dependent, perhaps we could have some of our other proto consumers (python? javascript? java?) @jeffgarratt @jimthematrix @rickr weigh in on how the proto files affect their code?

jeffgarratt (Wed, 08 Feb 2017 22:55:32 GMT):
Has joined the channel.

jyellick (Wed, 08 Feb 2017 22:57:24 GMT):
Renaming them is mindless work, I am happy to switch to another convention which is more go friendly, say lowerCamelCase (This would be more minimally invasive than the lower_undescore changes, at least from a golang perspective). Perhaps some other opinions? @cbf @mastersingh24 @greg.haskins ?

greg.haskins (Wed, 08 Feb 2017 22:58:22 GMT):
@jyellick I think primary criteria for v1.0.x is ABI compatibility. For that, we are primarily gated on two things: type and index

greg.haskins (Wed, 08 Feb 2017 22:59:01 GMT):
field names generally only impact local consumption..and while fire drills are annoying, they arent critical to gate a release per se

greg.haskins (Wed, 08 Feb 2017 22:59:15 GMT):
that said, I also appreciate the notion of cleaning things up before a release

greg.haskins (Wed, 08 Feb 2017 22:59:45 GMT):
so, I am supportive of cleaning things up if that is what needs to be done, but I dont see it as necessary to nail down unless ABI borkage is on the table

binhn (Wed, 08 Feb 2017 22:59:59 GMT):
it looks like your changes with _ doesn't cause golang code changes, but if we change txID to tx_id would require a lot of changes. I too would like comment from other languages

binhn (Wed, 08 Feb 2017 23:00:49 GMT):
hmm, rocketchat throws away me `_`

jyellick (Wed, 08 Feb 2017 23:01:49 GMT):
Yes, I split the CRs into three, the first which requires no golang changes (simply changes all the non ID fields to be lower_underscore), the second fixes up the enum style to be UPPER_CASE, and the final actually tweaks the `ID` related things (this is the most annoyingly invasive).

jyellick (Wed, 08 Feb 2017 23:01:49 GMT):
Yes, I split the CRs into three, the first which requires no golang changes (simply changes all the non `ID` fields to be lower_underscore), the second fixes up the enum style to be UPPER_CASE, and the final actually tweaks the `ID` related things (this is the most annoyingly invasive).

jyellick (Wed, 08 Feb 2017 23:01:49 GMT):
The CRs are split into three, the first which requires no golang changes (simply changes all the non `ID` fields to be lower_underscore), the second fixes up the enum style to be UPPER_CASE, and the final actually tweaks the `ID` related things (this is the most annoyingly invasive). Essentially, for field names, the protoc for golang turns `multi_word_name` into `MultiWordName`. It does the same thing to `multiWordName` or `MultiWordName`. So, in general, switching style in the proto does not affect the output golang code. However, for fields with abbreviations, like `chaincode_id` it is turned into `ChaincodeId`. While proto field `chaincodeID` and `ChaincodeID` are both translated to `ChaincodeID`

jyellick (Wed, 08 Feb 2017 23:01:49 GMT):
The CRs are split into three, the first which requires no golang changes (simply changes all the non `ID` fields to be lower_underscore), the second fixes up the enum style to be UPPER_CASE, and the final actually tweaks the `ID` related things (this is the most annoyingly invasive). Essentially, for field names, the protoc for golang turns `multi_word_name` into `MultiWordName`. It does the same thing to `multiWordName` or `MultiWordName`. So, in general, switching style in the proto does not affect the generated golang code. However, for fields with abbreviations, like `chaincode_id` it is turned into `ChaincodeId`. While proto field `chaincodeID` and `ChaincodeID` are both translated to `ChaincodeID`

jyellick (Wed, 08 Feb 2017 23:01:49 GMT):
The CRs are split into three, the first which requires no golang changes (simply changes all the non `ID` fields to be lower_underscore), the second fixes up the enum style to be UPPER_CASE, and the final actually tweaks the `ID` related things (this is the most annoyingly invasive). Essentially, for field names, the protoc for golang turns `multi_word_name` into `MultiWordName`. So, the field names `multi_word_name`, `multiWordName` and `MultiWordName` are all translated to the golang struct member `MultiWordName`. So for the vast majority of the fields, the style has no impact on the generated golang code. However, the field name `chaincode_id` translates to the golang struct member `ChaincodeId`, while the field names `chaincodeID` and `ChaincodeID` translate to the golang struct member `ChaincodeID`. So, for any fields containing abbreviations, the output is different.

rickr (Wed, 08 Feb 2017 23:17:59 GMT):
The only way I could assess I think is bring it but I think were behind to far now that no matter what it's a chore .. this will just add to it.

jyellick (Wed, 08 Feb 2017 23:30:57 GMT):
@rickr Assuming we standardize the proto naming, does one format fit more naturally for java than another?

greg.haskins (Wed, 08 Feb 2017 23:36:28 GMT):
@jyellick thinking about this some more, I would also say that striving to achieve parity with proto styling guide is good as opposed to chasing a particular nuance of a translation into a language...which is what I think you are saying too

greg.haskins (Wed, 08 Feb 2017 23:37:02 GMT):
if we strive to get the .protos as close to the style guide as possible, then we can let the protoc module do its job of making the most natural translation to the target language

greg.haskins (Wed, 08 Feb 2017 23:37:43 GMT):
this would be the most conducive to sharing the .proto spec

greg.haskins (Wed, 08 Feb 2017 23:38:33 GMT):
if, on the other hand, we optimize the output for one particular language in spite of the style guide, that is more conducive to a per-project .proto

greg.haskins (Wed, 08 Feb 2017 23:38:47 GMT):
I think you are advocating the former, which makes sense to me

jyellick (Wed, 08 Feb 2017 23:42:30 GMT):
Exactly @greg.haskins. Following proto style should make it most likely that the protos translate nicely to all languages. However, we do the vast majority of our fabric work in golang, and acronymns do not translate well to golang from proto style. So, it's a tradeoff. My inclination is to lean towards interoperability over convenience, but I see both sides.

jyellick (Wed, 08 Feb 2017 23:42:30 GMT):
Exactly @greg.haskins . Following proto style should make it most likely that the protos translate nicely to all languages. However, we do the vast majority of our fabric work in golang, and acronymns do not translate well to golang from proto style. So, it's a tradeoff. My inclination is to lean towards interoperability over convenience, but I see both sides.

greg.haskins (Wed, 08 Feb 2017 23:45:44 GMT):
yeah...i still think its not critical to nail that before the alpha cut per se, its an internal refactoring in essence

greg.haskins (Wed, 08 Feb 2017 23:45:55 GMT):
but its also not a big deal to find/replace things too

greg.haskins (Wed, 08 Feb 2017 23:45:59 GMT):
so I would support either way

jyellick (Wed, 08 Feb 2017 23:47:17 GMT):
Although I agree ABI is most important, but, the sooner we settle the API, the smaller that pile of code to search and replace through will be.

jyellick (Wed, 08 Feb 2017 23:47:17 GMT):
I agree ABI is most important, but, the sooner we settle the API, the smaller that pile of code to search and replace through will be.

greg.haskins (Wed, 08 Feb 2017 23:50:58 GMT):
i agree proliferation is the biggest concern in this regard

greg.haskins (Wed, 08 Feb 2017 23:52:19 GMT):
but I do see your point regarding API...for instance if "request.foo" is exposed to a client of the API, changing it to "request.Foo" can be done without breaking wire compat, but it still sucks to do that to our users

JonathanLevi (Thu, 09 Feb 2017 00:59:33 GMT):
Speaking of which... do we have a rough estimate/ballpark date/kind-of-a-baseline as to when we might be able to assume that we can have a soft form of a super mild API/ABI freeze for an alpha cut?

JonathanLevi (Thu, 09 Feb 2017 01:01:17 GMT):
And apologies in advance if the above question was too direct. I don't need anything that is carved in stone - just trying to see if we can all agree on some very rough timeline (as a conversation/thread starter.)

JonathanLevi (Thu, 09 Feb 2017 01:01:43 GMT):
Do most of us feel like we are a week or two away from it?

JonathanLevi (Thu, 09 Feb 2017 01:03:27 GMT):
It sux big time to ask clients/implementers and others to break their workflow, even more so when it is more than changing 'foo' to 'Foo'... let alone test everything/everywhere.

sachikoy (Thu, 09 Feb 2017 06:39:14 GMT):
Has joined the channel.

Clayton Sims (Thu, 09 Feb 2017 14:57:30 GMT):
Has joined the channel.

greg.haskins (Thu, 09 Feb 2017 17:04:11 GMT):
i agree, I have certainly been feeling this pain personally

greg.haskins (Thu, 09 Feb 2017 17:04:15 GMT):
as many of us have, I am sure

JonathanLevi (Thu, 09 Feb 2017 17:14:35 GMT):
I believe that the sooner we lock APIs (which continuing to develop) it will also help us assessing where we actually stand.

JonathanLevi (Thu, 09 Feb 2017 17:14:35 GMT):
I believe that the sooner we lock APIs (which continuing to develop) the better - also because it help us assessing where we actually stand.

mastersingh24 (Thu, 09 Feb 2017 17:20:26 GMT):
[ Moving this over here. Look - I honestly don't care whether we "officially" publish the hackfest images or not. There was chatter that we needed to get something out for fabric users to work with ASAP - aka "preview". While we can say there's been progress on master, from a usability / config perspective, it has not improved since we put out the unofficial sfhackfest images so my assertion was that there is no point wasting time on trying to cut a release from the current master until we get the "proper" end to end flow working else we are just implementing and documenting hacks.](https://chat.hyperledger.org/channel/fabric-ci?msg=hhAYKt5TN3zhqANhb) @greg.haskins

greg.haskins (Thu, 09 Feb 2017 18:58:02 GMT):
@rjones: unless anyone else objects, pls reconfigure fabric-chaintool back to NACR

rjones (Thu, 09 Feb 2017 21:05:07 GMT):
any objections? going once...

rjones (Thu, 09 Feb 2017 21:05:07 GMT):
any objections? hearing none I now pronounce you NACR enabled

greg.haskins (Thu, 09 Feb 2017 21:13:07 GMT):
ty

rjones (Thu, 09 Feb 2017 21:13:43 GMT):
np

greg.haskins (Fri, 10 Feb 2017 03:57:56 GMT):
I just saw this was merged? https://gerrit.hyperledger.org/r/#/c/5555/

greg.haskins (Fri, 10 Feb 2017 03:58:21 GMT):
im not sure this was ready to go in

greg.haskins (Fri, 10 Feb 2017 03:58:45 GMT):
@muralisr @binhn @mastersingh24

greg.haskins (Fri, 10 Feb 2017 03:59:19 GMT):
the only deployment model is predicated on the assumption that we have CLI access on the same node as the peer

greg.haskins (Fri, 10 Feb 2017 04:00:17 GMT):
this feels like a huge step backwards: i understand the reasons for not wanting it on ledger, but I think a network deployment model should still be included

greg.haskins (Fri, 10 Feb 2017 04:00:23 GMT):
could just be p2p

greg.haskins (Fri, 10 Feb 2017 04:00:49 GMT):
this will not play well with containerized peers

binhn (Fri, 10 Feb 2017 04:01:11 GMT):
right, no remote deploy yet, but we want to get that in for sdk to build api while working the rest, including remote deploy cli and security

greg.haskins (Fri, 10 Feb 2017 04:03:51 GMT):
that seems like a core function though

greg.haskins (Fri, 10 Feb 2017 04:04:24 GMT):
it negates a ton of work I had in progress

greg.haskins (Fri, 10 Feb 2017 04:04:49 GMT):
this is just catching me by surprise

greg.haskins (Fri, 10 Feb 2017 04:06:07 GMT):
as an example: if I deploy a v1.0 network as a docker swarm or kubernetes, how would I then deploy chaincode?

greg.haskins (Fri, 10 Feb 2017 04:06:50 GMT):
i can awkwardly exec a shell into each node for the requisite cli access, but I dont have the ability to move files in or out

greg.haskins (Fri, 10 Feb 2017 04:07:07 GMT):
the only thing running in the container is the peer-node process, no sshd

greg.haskins (Fri, 10 Feb 2017 04:09:20 GMT):
I think this should have minimally included the RPC to accept the modern equivalent of a ChaincodeDeploymentSpec (at least the CodePackage sans the init payload), even if the SDK wasnt supporting it

greg.haskins (Fri, 10 Feb 2017 04:11:53 GMT):
at this point, theres very little difference between system chaincode and user chaincode...they all have to be baked in ahead of time

greg.haskins (Fri, 10 Feb 2017 04:19:55 GMT):
long story short, I'm somewhat dead in the water until this is fixed. Everything we do is in containers

binhn (Fri, 10 Feb 2017 04:52:11 GMT):
understood; it'll be like a deploy now but only copying the code to a directory and will be there by tomorrow

muralisr (Fri, 10 Feb 2017 08:59:49 GMT):
Hi @greg.haskins `I think this should have minimally included the RPC to accept the modern equivalent of a ChaincodeDeploymentSpec (at least the CodePackage sans the init payload), even if the SDK wasnt supporting it`

muralisr (Fri, 10 Feb 2017 08:59:51 GMT):
yes

muralisr (Fri, 10 Feb 2017 09:00:59 GMT):
once I get the playbacks out, that'll be the focus. Hopefully not later than monday (mechanics same as the old "deploy" so should be straightforward)

rickr (Fri, 10 Feb 2017 13:58:34 GMT):
I don't know why the API could have had just a simple change. If the init proposal and NO chaincode (maybe with a boollean option that signified that) the it was assumed to be on the file system and loaded from there. If the chaincode was present it would be installed on the files system and initialized at the same time (one api). Seems like we could have had the best of both worlds allowing the user to decide what was right for them.

rickr (Fri, 10 Feb 2017 13:58:34 GMT):
I don't know why the API could have had just a simple change. If the init proposal had NO chaincode (maybe with a boolean option that signified that) the it was assumed to be on the file system and loaded from there. If the chaincode was present it would be installed on the files system and initialized at the same time (one api). Seems like we could have had the best of both worlds allowing the user to decide what was right for them.

muralisr (Fri, 10 Feb 2017 16:14:33 GMT):
@rickr the problem is that the instantiation will contain the chaincode which become part of the transaction (one of the things the new model tries to avoid... btw, @binhn pointed that out)

greg.haskins (Fri, 10 Feb 2017 18:17:55 GMT):
The more I think about this, the more I think we need to revert it and regroup

greg.haskins (Fri, 10 Feb 2017 18:18:37 GMT):
One question I have is: Is there ever a situation where we do not want all member of a channel to have the code?

greg.haskins (Fri, 10 Feb 2017 18:18:37 GMT):
One question I have is: Is there ever a situation where we do not want all members of a channel to have the code?

greg.haskins (Fri, 10 Feb 2017 18:19:41 GMT):
I understand there can be some inefficiencies in the current design if the same chaincode is needed in multiple channels...lets just assume that is a solvable problem for a second (because I think it is)

greg.haskins (Fri, 10 Feb 2017 18:20:43 GMT):
in terms of channel function, when is it valid for channel members to have only a subset of addressable chaincodes in them?

greg.haskins (Fri, 10 Feb 2017 18:21:20 GMT):
I am seeing lots of holes in the new model and no good solution in sight

greg.haskins (Fri, 10 Feb 2017 18:21:27 GMT):
this seems too rushed this late in the game

greg.haskins (Fri, 10 Feb 2017 18:27:24 GMT):
(apologies to @muralisr )

greg.haskins (Fri, 10 Feb 2017 18:28:28 GMT):
I should also state that I do not see the chaincode on the ledger as an overarching problem

greg.haskins (Fri, 10 Feb 2017 18:28:40 GMT):
at least when its managed well

greg.haskins (Fri, 10 Feb 2017 18:29:06 GMT):
chaintool packages example02 into 2.3k.....this is smaller than most normal transactions in lots of the apps I have written

greg.haskins (Fri, 10 Feb 2017 18:29:32 GMT):
the benefit of having it be transactional at the channel scope is fairly high though

greg.haskins (Fri, 10 Feb 2017 18:29:52 GMT):
i fear we traded mild optimization for gross deficiency

greg.haskins (Fri, 10 Feb 2017 18:30:54 GMT):
this isnt to say we need chaintool for managing the deployment payload size, but that is just an example of what it looks like when its well controller

binhn (Fri, 10 Feb 2017 20:36:39 GMT):
@greg.haskins appreciate your comments here but I wish that happened earlier -- we do envision use-cases as mentioned in fab-1783 for this change in direction

binhn (Fri, 10 Feb 2017 20:38:47 GMT):
it is not just optimization for chaincode deployment, but certainly part of the motivation. It is more so on how to manage chaincodes on multichannel (1000s of channels)

greg.haskins (Fri, 10 Feb 2017 20:40:47 GMT):
thats fair, but I do my best tracking multiple facets of things including both FOSS an internal...I had been following the JIRA at a high level but it seems like it went from "JIRA WIP" to "Merged CR" without broader agreement

greg.haskins (Fri, 10 Feb 2017 20:40:47 GMT):
thats fair, but I do my best tracking multiple facets of things including both FOSS and internal...I had been following the JIRA at a high level but it seems like it went from "JIRA WIP" to "Merged CR" without broader agreement

binhn (Fri, 10 Feb 2017 20:40:49 GMT):
the difference isn't that much between "instantiate" and "deploy" tx, where deploy contains the code, and instantiate contains the hash(code+) with the assumption that the code has been "installed" on the endorsers

greg.haskins (Fri, 10 Feb 2017 20:41:30 GMT):
and I understand the concern about multi-channel, but it seems that the solution isnt fully baked

greg.haskins (Fri, 10 Feb 2017 20:42:01 GMT):
what is the deployment model now? what is the security model? how do we address the notion that not all peers within a channel may have the code

greg.haskins (Fri, 10 Feb 2017 20:42:06 GMT):
etc etc

greg.haskins (Fri, 10 Feb 2017 20:42:26 GMT):
other things too: like the lack of a transactional store for the chaincodes now

greg.haskins (Fri, 10 Feb 2017 20:42:46 GMT):
maybe I am just missing details, but it seems like key architectural details are "TBD"

greg.haskins (Fri, 10 Feb 2017 20:43:40 GMT):
I think the majority of the multi-channel concern would be addressed at the container level, and that wouldnt require a modification to the wire-protocol/network-operation

binhn (Fri, 10 Feb 2017 20:44:15 GMT):
let me look up a jira item on security related to this new model

greg.haskins (Fri, 10 Feb 2017 20:44:22 GMT):
it just seems like "payload per channel" is properly scoped and secured

greg.haskins (Fri, 10 Feb 2017 20:47:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=P5gwAyzB9LAQfuAvN) @binhn right, but thats a big assumption

binhn (Fri, 10 Feb 2017 20:47:11 GMT):
right, it would be better scoped as no cross channel things -- the new model sets up 1 container per chaincode for all channels that the chaincode is operating on provide optimization but also bringing security concerns

greg.haskins (Fri, 10 Feb 2017 20:47:52 GMT):
the way I look at it (and correct where my gaps in understanding are in both old and new models)

greg.haskins (Fri, 10 Feb 2017 20:48:20 GMT):
in the old method: I could create a channel between relevant parties, and then deploy a payload on that channel

greg.haskins (Fri, 10 Feb 2017 20:48:32 GMT):
by definition, all the parties on the channel should be privy to that code, no?

binhn (Fri, 10 Feb 2017 20:49:04 GMT):
yes, with the old model

greg.haskins (Fri, 10 Feb 2017 20:49:08 GMT):
and by association, all parties on that channel would have appropriate access to that code

greg.haskins (Fri, 10 Feb 2017 20:49:48 GMT):
i could write an LCCC policy that defines the privledge to deploy on that particular channel

greg.haskins (Fri, 10 Feb 2017 20:49:54 GMT):
so that is the security and deployment model

greg.haskins (Fri, 10 Feb 2017 20:50:07 GMT):
in the new model, the availability of the code from the channel is decoupled

greg.haskins (Fri, 10 Feb 2017 20:50:25 GMT):
i could instantiate "X" on a channel, but theres no saying that any of the members of the channel have X

greg.haskins (Fri, 10 Feb 2017 20:51:00 GMT):
so now I need to replicate a security model that mirrors the scope of the channel, but isnt built into the channel

greg.haskins (Fri, 10 Feb 2017 20:51:30 GMT):
one model is "well, every node on the channel needs to log in to their node, upload the code, and run the CLI

greg.haskins (Fri, 10 Feb 2017 20:52:20 GMT):
and that technically meets the criteria, but its both OOB to the security policy of the peer as well as awkward at best, and at worst, not an option for certain deployment models (e.g. containerized peers)

greg.haskins (Fri, 10 Feb 2017 20:52:59 GMT):
or, we could add an RPC to upload the code, but now we need an OOB security mechanism, and we need to ensure it overlaps with channel membership

greg.haskins (Fri, 10 Feb 2017 20:53:47 GMT):
im not sure its worth all this, and it seems like it breaks the (really important) property of being able to define meta policy with things like LCCC

binhn (Fri, 10 Feb 2017 20:55:06 GMT):
ok, let me try to address some and i see murali is also typing ... so let he charm in as well

muralisr (Fri, 10 Feb 2017 20:57:38 GMT):
the main differences I think is the new model allows for deployment and scenarios where (1) assets are manipulated by different peers/orgs in different ways (but they belong to one problem domain) (2) they all generate transactions in the problem domain differently (different endorser set for different kinds of proposals/transactions) (3) ownership and management of chaincode is also separated .... to me, the old model can be derived from the new but the new allows for many different scenarios

muralisr (Fri, 10 Feb 2017 20:58:24 GMT):
the linkage beweeen the code on the peer and the instantiation on the channel is the tricky part (the security concerns) which have to be carefully addressed

greg.haskins (Fri, 10 Feb 2017 20:58:48 GMT):
i dont see how this relates to assets though...that should be related to transactions on the channel in either case

greg.haskins (Fri, 10 Feb 2017 20:59:21 GMT):
as far as code, I understand why one chaincode on mulitple channels is undesirable to have multiple containers, but we can address that without changing the protocol

greg.haskins (Fri, 10 Feb 2017 20:59:48 GMT):
the peer would just need to maintain the container catalog at a lower level, but that should be achievable

greg.haskins (Fri, 10 Feb 2017 21:00:28 GMT):
e.g. if I deploy X (using the old scheme) on channel Y, and the peer hasnt seen it before, it installs X

greg.haskins (Fri, 10 Feb 2017 21:00:54 GMT):
then if I deploy Y on channel Z, the CodePackage is still on the ledger for channel Z, but the peer doesnt need to create the container again

greg.haskins (Fri, 10 Feb 2017 21:00:54 GMT):
then if I deploy X on channel Z, the CodePackage is still on the ledger for channel Z, but the peer doesnt need to create the container again

greg.haskins (Fri, 10 Feb 2017 21:00:56 GMT):
it already has it

greg.haskins (Fri, 10 Feb 2017 21:01:32 GMT):
that would solve the bulk of the problem, I would think

greg.haskins (Fri, 10 Feb 2017 21:02:26 GMT):
yes, both the Y and Z channels have the payload for the code, but we are talking probably 2k-20k in the vast majority of the cases which is smaller than many standard invokes()

greg.haskins (Fri, 10 Feb 2017 21:02:37 GMT):
but I would also argue this is a good thing

greg.haskins (Fri, 10 Feb 2017 21:02:49 GMT):
its repeatable within the channel forevermore

greg.haskins (Fri, 10 Feb 2017 21:03:07 GMT):
it was by definition, appropriate for the channel having passed as an LCCC transaction, etc

greg.haskins (Fri, 10 Feb 2017 21:03:35 GMT):
if we decouple the payload, theres now a whole slew of problems that can crop up

greg.haskins (Fri, 10 Feb 2017 21:03:53 GMT):
a) what if a node in Channel Y or Z doesnt have X now?

greg.haskins (Fri, 10 Feb 2017 21:04:00 GMT):
b) what if they dont have it in the future

greg.haskins (Fri, 10 Feb 2017 21:04:28 GMT):
c) what if X was partially written to the filesystem and then went down

greg.haskins (Fri, 10 Feb 2017 21:04:50 GMT):
d) what if I want to govern the validity of the install via consensus

greg.haskins (Fri, 10 Feb 2017 21:04:57 GMT):
etc etc

greg.haskins (Fri, 10 Feb 2017 21:05:15 GMT):
i just dont see how that is going to be addressed, all for saving 2k-20k in the init() transaction

muralisr (Fri, 10 Feb 2017 21:12:30 GMT):
The case where a chaincode need not be on all peers because they address different facet in the same problem domain.The code resides on those peers who need it and it can be accessed only on those but all peers need to be aware of the transactions generated (so having private channels for those may not always be an option)

greg.haskins (Fri, 10 Feb 2017 21:13:06 GMT):
understood, but doesnt "need not be on all peers" also overlap with channel membership?

greg.haskins (Fri, 10 Feb 2017 21:13:43 GMT):
generally, if you are on the channel, you need the code...if you are not on the channel, you may or may not

muralisr (Fri, 10 Feb 2017 21:13:55 GMT):
it would to some extent but depends upon the problem domain I think.

greg.haskins (Fri, 10 Feb 2017 21:14:41 GMT):
consider peers Alice and Bob

greg.haskins (Fri, 10 Feb 2017 21:15:05 GMT):
they want to run chaincodes X Y and Z so they install them manually

muralisr (Fri, 10 Feb 2017 21:15:09 GMT):
well take my example ```a "car consortium" channel with Vehicle Registration, Dealership companies, Insurance companies etc. The common thing is the CarAsset/Owner and everyone will have a CarAssetChaincode. But there will be chaincodes (CarDealerChaincode, InsuranceChaincode etc) which will only be on relevant peers. Everyone will be aware of the TXs but only some can generate them.```

muralisr (Fri, 10 Feb 2017 21:15:09 GMT):
well take my example - a "car consortium" channel with Vehicle Registration, Dealership companies, Insurance companies etc. The common thing is the CarAsset/Owner and everyone will have a CarAssetChaincode. But there will be chaincodes (CarDealerChaincode, InsuranceChaincode etc) which will only be on relevant peers. Everyone will be aware of the TXs but only some can generate them.

muralisr (Fri, 10 Feb 2017 21:15:28 GMT):
that didn't come out well ... let me try again

greg.haskins (Fri, 10 Feb 2017 21:15:29 GMT):
then an auditor wants to replay their history

greg.haskins (Fri, 10 Feb 2017 21:16:15 GMT):
so, would we have a channel with different endorsing scopes?

greg.haskins (Fri, 10 Feb 2017 21:16:33 GMT):
i thought a channel was how we define endorsing scopes

muralisr (Fri, 10 Feb 2017 21:16:43 GMT):
when an auditor wants to replay, install the chaincode and replay

greg.haskins (Fri, 10 Feb 2017 21:17:23 GMT):
heres my problem: there doesnt seem to be a plan for what constitutes "install the chaincodes"

greg.haskins (Fri, 10 Feb 2017 21:17:33 GMT):
its just some OOB thing that is passed off to a different layer

greg.haskins (Fri, 10 Feb 2017 21:18:29 GMT):
do Alice and/or Bob have to give the auditor the chaincodes?

greg.haskins (Fri, 10 Feb 2017 21:18:37 GMT):
is there a protocol for the Auditor to ask for them?

greg.haskins (Fri, 10 Feb 2017 21:19:00 GMT):
what are the security constraints governing the Auditors permissions to do that?

greg.haskins (Fri, 10 Feb 2017 21:19:28 GMT):
is it just left to the Auditor to figure out on their own?

muralisr (Fri, 10 Feb 2017 21:21:30 GMT):
the instantiation and the subsequent transactions are on the channel - that's a starting point. Wouln't the same concerns and protocol regarding auditing apply directly from the old model ? Granted there has to be additions to address the code part of it (which is why the strong link via the code and LCCC entries on the ledger is needed)

greg.haskins (Fri, 10 Feb 2017 21:22:27 GMT):
The difference as I see it, is that the instantiate(new) and deploy(old) employ inband processes

greg.haskins (Fri, 10 Feb 2017 21:22:52 GMT):
you need to be able to generate a valid (as per network/LCCC rules) deploy/instantiate txn to play

greg.haskins (Fri, 10 Feb 2017 21:23:22 GMT):
the problem with the instantiate model is, its a partial reference to something that happened OOB

greg.haskins (Fri, 10 Feb 2017 21:24:18 GMT):
now, if I had a clear understanding of the rules of that OOB mechanism, and it had similar extensibility to the inband network in terms of AAA, policy, consensus, etc) it would be ok

greg.haskins (Fri, 10 Feb 2017 21:24:29 GMT):
then perhaps it would be ok

muralisr (Fri, 10 Feb 2017 21:24:40 GMT):
I see a string parallel to strong links to data items via maintaining hashes on the ledger - for audit and other purposes

greg.haskins (Fri, 10 Feb 2017 21:25:07 GMT):
but the thing I dont get is: regardless of whether the plan for that OOB network exist or not, they seem to more or less overlap with what we already do at the LCCC/channel level

greg.haskins (Fri, 10 Feb 2017 21:25:31 GMT):
and therefore I question whether that OOB mechanism has real value

greg.haskins (Fri, 10 Feb 2017 21:26:03 GMT):
but even if it has a plan, and has value, I would still suggest that we should have those pieces in place before flipping the switch

muralisr (Fri, 10 Feb 2017 21:26:40 GMT):
let me make sure of one point first greg ..I think its important

greg.haskins (Fri, 10 Feb 2017 21:26:54 GMT):
to be clear, I am totally supportive of the notion that we can optimize container creation to be 1:1 with uniqueness of code

greg.haskins (Fri, 10 Feb 2017 21:27:15 GMT):
ok

muralisr (Fri, 10 Feb 2017 21:27:24 GMT):
` it had similar extensibility to the inband network in terms of AAA, policy, consensus` - trying to understand that

greg.haskins (Fri, 10 Feb 2017 21:27:57 GMT):
ok, consider the old deployment model

muralisr (Fri, 10 Feb 2017 21:28:09 GMT):
o

muralisr (Fri, 10 Feb 2017 21:28:11 GMT):
ok

greg.haskins (Fri, 10 Feb 2017 21:28:14 GMT):
to create chaincode, I had to be able to create a deploy transaction, right?

muralisr (Fri, 10 Feb 2017 21:28:22 GMT):
correct

muralisr (Fri, 10 Feb 2017 21:28:44 GMT):
I see where you are going with this

greg.haskins (Fri, 10 Feb 2017 21:28:46 GMT):
in order to create a deploy transaction, I needed to meet the general requirements of creating a transaction within a fabric network (presumably fabric-ca credentials, etc)

muralisr (Fri, 10 Feb 2017 21:28:52 GMT):
(but sorry, do continue :-) )

greg.haskins (Fri, 10 Feb 2017 21:29:04 GMT):
and I had to adhere to whatever rules we bake into LCCC

greg.haskins (Fri, 10 Feb 2017 21:29:06 GMT):
etc

greg.haskins (Fri, 10 Feb 2017 21:29:07 GMT):
etc

greg.haskins (Fri, 10 Feb 2017 21:29:36 GMT):
and then that transaction, after passing those initial validity checks, would go through consensus and eventually result in an update to the ledger, the creation of a container, etc

muralisr (Fri, 10 Feb 2017 21:29:43 GMT):
right

greg.haskins (Fri, 10 Feb 2017 21:30:04 GMT):
so, all of that was using the AAA/policy/consensus of the network as a whole

greg.haskins (Fri, 10 Feb 2017 21:30:07 GMT):
thats what I meant by that

muralisr (Fri, 10 Feb 2017 21:30:19 GMT):
right. understood

greg.haskins (Fri, 10 Feb 2017 21:30:45 GMT):
but now if its OOB, none of that is in play (presumably)....or it IS in play, but we are replicating what we already do in the old model

greg.haskins (Fri, 10 Feb 2017 21:31:37 GMT):
so for the former, id say "its not ready", and for the latter, I would say "why?"

muralisr (Fri, 10 Feb 2017 21:33:06 GMT):
but the instantiation will be using the AAA/policy/consensus (and the endorsements of others with the chaincode) ... only those endorsers know / care about the chaincode . Others in the channel get the tx and don't care about the chaincode itself (and in the old model will also have the chaincode in their ledger)

greg.haskins (Fri, 10 Feb 2017 21:33:48 GMT):
i guess what I need to understand better is: what is an endorser scope vs channel

greg.haskins (Fri, 10 Feb 2017 21:33:55 GMT):
i thought they were more or less the same thing

greg.haskins (Fri, 10 Feb 2017 21:34:26 GMT):
i thought the channels were more or less defining the endorser scope

muralisr (Fri, 10 Feb 2017 21:35:17 GMT):
but since the instantiation plays such a pivotal role, it is important to maintain the strong link between that code and that instantiation tx (vial the LCCC entry) much as we can keep bulk data in an external db but put hash on on the blockchain

muralisr (Fri, 10 Feb 2017 21:35:47 GMT):
in a channel with N peers, a subset can be endorsers for TX

greg.haskins (Fri, 10 Feb 2017 21:36:11 GMT):
ok...so what is the point of a channel?

greg.haskins (Fri, 10 Feb 2017 21:37:19 GMT):
(i am not being facetious: i am confused as to what its purpose is)

greg.haskins (Fri, 10 Feb 2017 21:37:44 GMT):
er, i thought I knew, until just now

muralisr (Fri, 10 Feb 2017 21:37:56 GMT):
absolutely, I understood :-)

greg.haskins (Fri, 10 Feb 2017 21:39:09 GMT):
to be clear, i totally get why code should only be targeted at the endorsing scope...i had just thought thats what a channel was)

muralisr (Fri, 10 Feb 2017 21:41:58 GMT):
I see.. I begin to understand the direction you were coming from. ... endorsser is just a role for a peer .... many peers in a channel, depending upon the nature of transacion and the application, different peers will be called to endorse (and run CC to do that) those txs

muralisr (Fri, 10 Feb 2017 21:42:16 GMT):
not sure that helps...

greg.haskins (Fri, 10 Feb 2017 21:43:04 GMT):
what bestows the peer with the role of endorser and when?

greg.haskins (Fri, 10 Feb 2017 21:43:25 GMT):
is it per channel (what I thought), per chaincode, per tx, something else?

greg.haskins (Fri, 10 Feb 2017 21:43:25 GMT):
is it per channel (what I thought), per chaincode-instance, per tx, something else?

binhn (Fri, 10 Feb 2017 21:43:25 GMT):
sorry, i got interrupted -- reading...

muralisr (Fri, 10 Feb 2017 21:54:30 GMT):
at one level, the application would say - "I need endorsements for this user request/tx from those two banks in that channel" - ... so application (SDK and Chaincode) and the tx I'd say (at least in that view)

greg.haskins (Fri, 10 Feb 2017 21:58:47 GMT):
what is the granularity?

greg.haskins (Fri, 10 Feb 2017 21:58:58 GMT):
is it per chaincode instance, per function?

greg.haskins (Fri, 10 Feb 2017 21:59:10 GMT):
per tx?

binhn (Fri, 10 Feb 2017 22:00:40 GMT):
in my mind, channel is for transactions isolation (private to counter parties); these transactions may involve multiple chaincodes instantiated on that channel, whose endorsers varied per chaincode endorsement policy, and hence, only those endorsers would need to have the chaincode to stand up the container.

greg.haskins (Fri, 10 Feb 2017 22:01:12 GMT):
@binhn i think that is why I am confused

greg.haskins (Fri, 10 Feb 2017 22:01:44 GMT):
all of those terms (transaction isolation, privacy to counter parties, etc) to me implies a relationship to endorsing

greg.haskins (Fri, 10 Feb 2017 22:02:03 GMT):
i think that might be why I thought channel formation was essentially setting the bounds of endorsement/privacy

greg.haskins (Fri, 10 Feb 2017 22:02:30 GMT):
i still am not clear on what _does_ set that if channels are not it

binhn (Fri, 10 Feb 2017 22:03:58 GMT):
say bob and alice (bilateral transaction) with some observers on a channel, and say bob and alice are the endorsers of their transactions involving 1 chaincode, and the observers (committing peers) only receive the transactions. So we need a model to deploy the chaincode such that observers don't get it but know about it

greg.haskins (Fri, 10 Feb 2017 22:06:36 GMT):
so, step back a level

greg.haskins (Fri, 10 Feb 2017 22:06:53 GMT):
bob and alice want to create a bilateral mechanism of some kind

greg.haskins (Fri, 10 Feb 2017 22:06:58 GMT):
how do they do that?

greg.haskins (Fri, 10 Feb 2017 22:07:03 GMT):
what are the steps

greg.haskins (Fri, 10 Feb 2017 22:07:30 GMT):
say the fabric is newly deployed and empty, but it has 10 peers from various entities

greg.haskins (Fri, 10 Feb 2017 22:07:57 GMT):
of which alice and bob own 1 each

greg.haskins (Fri, 10 Feb 2017 22:09:13 GMT):
assume the chaincode is already written

greg.haskins (Fri, 10 Feb 2017 22:09:22 GMT):
(but not deployed/installed)

greg.haskins (Fri, 10 Feb 2017 22:10:08 GMT):
how do I establish that only Alice and Bob can see/run the code and see the data that the code manipulates

binhn (Fri, 10 Feb 2017 22:15:04 GMT):
1) either alice or bob needs to have privilege to create channel (which is set as part of the config block on the ordering service) 2) they would agree on the chaincode (reviewed, signed, packaged, etc) -- FAB-2143 3) they would install the package on their peers 4) they would create a channel where they are the members, and they might optionally include others (observers) as members of this channel 4) they would instantiate the chaincode with endorsement policy requiring both alice's and bob's sig 5) they now would be able to transact

greg.haskins (Fri, 10 Feb 2017 22:15:49 GMT):
ok, and this is more or less in line with how I thought it would work

greg.haskins (Fri, 10 Feb 2017 22:16:27 GMT):
so my question is: if I create a channel and assign Alice and Bob as members...dont they, by definition, expect to be running the same code on that channel?

greg.haskins (Fri, 10 Feb 2017 22:17:07 GMT):
to put it another way, would I ever add Charlie to that channel but not want him to have/see the code?

binhn (Fri, 10 Feb 2017 22:18:25 GMT):
yes, if charlie is a required observer or some other role that might run other chaincodes with bob

greg.haskins (Fri, 10 Feb 2017 22:18:50 GMT):
well, the latter would just be a different channel between Charlie and Bob, right?

greg.haskins (Fri, 10 Feb 2017 22:19:09 GMT):
but lets talk about the Observer

greg.haskins (Fri, 10 Feb 2017 22:19:30 GMT):
wouldnt the observer want to be able to validate transactions?

binhn (Fri, 10 Feb 2017 22:20:11 GMT):
yes, but they might not need the chaincodes to do that

greg.haskins (Fri, 10 Feb 2017 22:20:14 GMT):
where I am going with this is: it seems to me that channel really does scope the privacy, including active endorsers and observers

greg.haskins (Fri, 10 Feb 2017 22:20:38 GMT):
and therefore, all members of a channel need to execute transactions (even if observers do not submit endorser signatures

binhn (Fri, 10 Feb 2017 22:21:01 GMT):
validating transaction doesn't require executing chaincodes again

greg.haskins (Fri, 10 Feb 2017 22:21:35 GMT):
well, thats a function of validation depth though, isnt it?

greg.haskins (Fri, 10 Feb 2017 22:21:53 GMT):
validating things like MVCC correctness or endorser signatures, no

greg.haskins (Fri, 10 Feb 2017 22:22:06 GMT):
validating things like the content of MVCC correctness, yes

greg.haskins (Fri, 10 Feb 2017 22:22:11 GMT):
(or, I would think anyway)

binhn (Fri, 10 Feb 2017 22:23:30 GMT):
a transaction contains static data that linked to other transactions (mvcc, right), so to prove correctness doesn't require replaying the transactions

greg.haskins (Fri, 10 Feb 2017 22:23:58 GMT):
I'm not sure everyone would agree with that though

greg.haskins (Fri, 10 Feb 2017 22:24:13 GMT):
i think in certain use cases, repeating the calculation will be important

greg.haskins (Fri, 10 Feb 2017 22:24:20 GMT):
i digress, thats actually not important right now

greg.haskins (Fri, 10 Feb 2017 22:24:44 GMT):
what is important is that: at some level, there is a group which must share code, correct?

binhn (Fri, 10 Feb 2017 22:24:59 GMT):
yes

greg.haskins (Fri, 10 Feb 2017 22:25:03 GMT):
i had thought the dichotomy was perhaps simpler than it is

greg.haskins (Fri, 10 Feb 2017 22:25:18 GMT):
i had thought it was in-channel vs out-of-channel

greg.haskins (Fri, 10 Feb 2017 22:25:27 GMT):
perhaps its at least three levels deep

greg.haskins (Fri, 10 Feb 2017 22:25:39 GMT):
endorser-inchannel, in-channel, and out-of-channel

greg.haskins (Fri, 10 Feb 2017 22:25:52 GMT):
i think we all agree the OOC case doesnt need the code

greg.haskins (Fri, 10 Feb 2017 22:26:04 GMT):
I think we all agree the endorsers do need the code

greg.haskins (Fri, 10 Feb 2017 22:26:23 GMT):
i suppose its debatable whether it matters if in-channel gets the code or not

binhn (Fri, 10 Feb 2017 22:26:36 GMT):
right

greg.haskins (Fri, 10 Feb 2017 22:26:54 GMT):
personally I think theres at least a subclass of "in-channel" that are not endorsers but who need the ability to re-execute the transactions

greg.haskins (Fri, 10 Feb 2017 22:26:59 GMT):
but lets shelve that for a minute

binhn (Fri, 10 Feb 2017 22:27:37 GMT):
ok

greg.haskins (Fri, 10 Feb 2017 22:27:44 GMT):
w.r.t. the "endorser-inchannel" group, I think there is still merit to consider an in-band deployment transaction

greg.haskins (Fri, 10 Feb 2017 22:28:01 GMT):
im not sure what the mechanics of this might look like, we would have to thnk about the design

greg.haskins (Fri, 10 Feb 2017 22:28:04 GMT):
but thats kind of my point

greg.haskins (Fri, 10 Feb 2017 22:28:10 GMT):
if we dont have a story there, the logic isnt ready

greg.haskins (Fri, 10 Feb 2017 22:28:39 GMT):
this is very important to get right

greg.haskins (Fri, 10 Feb 2017 22:29:31 GMT):
(and I would add, risky to try to change now)

greg.haskins (Fri, 10 Feb 2017 22:29:58 GMT):
though I understand the pressure to get this ABI impacting decision in for 1.0

binhn (Fri, 10 Feb 2017 22:30:00 GMT):
i thought there would be that the lccc would have an "install" function such that cli or sdk may invoke to pass long the chaincode package to the inchannel endorsers

greg.haskins (Fri, 10 Feb 2017 22:30:15 GMT):
yes, and I am sure we can come up with something

greg.haskins (Fri, 10 Feb 2017 22:30:32 GMT):
but again, my point is: we should have that nailed or defer until we do

binhn (Fri, 10 Feb 2017 22:31:22 GMT):
agreed

greg.haskins (Fri, 10 Feb 2017 22:31:49 GMT):
so where do we go from here?

binhn (Fri, 10 Feb 2017 22:33:02 GMT):
@muralisr will push a cr on FAB-2143 and we can discuss more there

greg.haskins (Fri, 10 Feb 2017 22:33:09 GMT):
ok

binhn (Fri, 10 Feb 2017 22:33:46 GMT):
thanks for all the thoughts - i will try to capture the essence of this convo on FAB-2143

greg.haskins (Fri, 10 Feb 2017 22:33:51 GMT):
ok

muralisr (Fri, 10 Feb 2017 22:36:15 GMT):
should I continue with the plan of having SDK access to push code ? ...no need to interrupt that is it (and its not a whole lot anyway)

muralisr (Fri, 10 Feb 2017 22:39:43 GMT):
sorry just saw the above `i thought there would be that the lccc would have an "install" function such that cli or sdk may invoke to pass long the chaincode package to the inchannel endorsers`

muralisr (Fri, 10 Feb 2017 22:40:12 GMT):
this chat didn't get updated for me till I was tagged for some reason

greg.haskins (Fri, 10 Feb 2017 23:11:59 GMT):
ill try to summarize my understanding and position

greg.haskins (Fri, 10 Feb 2017 23:12:24 GMT):
IIUC, the main goal of this effort was for the scenario where we have a super popular chaincode and 1000s of channels

greg.haskins (Fri, 10 Feb 2017 23:13:16 GMT):
in the previous model, we would end up with 1000s of deployment txns, 1000s of on-ledger storage of the code, and 1000s of docker containers

greg.haskins (Fri, 10 Feb 2017 23:13:49 GMT):
I think the reduction of 1 container to N contexts can be achieved without modifying the model

greg.haskins (Fri, 10 Feb 2017 23:14:47 GMT):
either way, a hash of the CodePackage tells us the container being referenced...whether that comes in the form of hash(deploy.CodePackage) or instiantiate.CodeHash doesnt matter

greg.haskins (Fri, 10 Feb 2017 23:15:12 GMT):
for the other case, I would argue that the deployment payload plays a critical function

greg.haskins (Fri, 10 Feb 2017 23:15:32 GMT):
(and its also smaller than I think we realize, at least if we do this right)

greg.haskins (Fri, 10 Feb 2017 23:16:10 GMT):
e.g. 2.4k for "example02"..so perhaps a real application range is probably 2k-50k

greg.haskins (Fri, 10 Feb 2017 23:17:38 GMT):
its critical to be carried in the channel gossip to properly distribute the code in the right context, and its proper to live on the channel's ledger to facilitate re-play validation

yacovm (Fri, 10 Feb 2017 23:18:25 GMT):
oh sure, gossip dressing goes well with anything.

greg.haskins (Fri, 10 Feb 2017 23:18:29 GMT):
so, if the payload is needed, and the optimization of 1:N containers can be achieved without changing the model, my vote is that this should not be changed

yacovm (Fri, 10 Feb 2017 23:21:31 GMT):
I have a question- the new deployment module provides a serious benefit with the multi-tenant container being a scalable solution but how does the SDK know which chaincode is installed on which peers? is there a planned solution for that? In the previous deployment module you could've selected any peer of the channel.

muralisr (Fri, 10 Feb 2017 23:23:24 GMT):
`in the previous deployment module you could've selected any peer of the channel.` - you could have, yes, but you may want only to select the peer that can endorse the chaincode and which works with the application for that type of transactions the chaincode is supposed to serve

muralisr (Fri, 10 Feb 2017 23:23:38 GMT):
in other words, the application-CC are paired

yacovm (Fri, 10 Feb 2017 23:23:56 GMT):
oh yeah, of course.

yacovm (Fri, 10 Feb 2017 23:25:23 GMT):
but who determines if the peer can endorse or not? the configuration, right? why would a peer be in a channel and not be an endorser? (am I missing something?)

yacovm (Fri, 10 Feb 2017 23:26:17 GMT):
I mean, I understand why but I don't understand *why* would users not just always configure all peers to be endorsers, apart from some security reasons of peers being in DMZs

greg.haskins (Fri, 10 Feb 2017 23:28:07 GMT):
and even if we conclude that, indeed, some members of a channel can legitimately not need to execute code (not convinced yet on this), it just means we are referring to the wrong layer

yacovm (Fri, 10 Feb 2017 23:28:11 GMT):
ah, I think I understand what you mean @muralisr - that the application "comes" with the peer it knows anyway?

yacovm (Fri, 10 Feb 2017 23:28:11 GMT):
ah, I think I understand what you mean @muralisr - that the application "comes" with the peer(s) it knows anyway?

greg.haskins (Fri, 10 Feb 2017 23:28:39 GMT):
so s/channel/endorser-group in my above statements and it still applies

muralisr (Fri, 10 Feb 2017 23:29:10 GMT):
really depends upon the domain of the blockchain .. " all are peers equal, all participate in all endorsement" and "the nature of TX/application defines which subset of peers are needed for endorsement" (and yes, @yacovm )

yacovm (Fri, 10 Feb 2017 23:29:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=edqREfKcZPeZijf8w) @greg.haskins You made my mind compile a sed statement...

yacovm (Fri, 10 Feb 2017 23:29:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=edqREfKcZPeZijf8w) @greg.haskins You made my mind compile a `sed` statement...

greg.haskins (Fri, 10 Feb 2017 23:29:22 GMT):
e.g. the code distribution group, call it just endorsers or more broadly, channel members, should still be a function of a txn of the lccc

greg.haskins (Fri, 10 Feb 2017 23:30:01 GMT):
whats a little regex between friends

muralisr (Fri, 10 Feb 2017 23:30:04 GMT):
it should be linked to LCCC for sure

muralisr (Fri, 10 Feb 2017 23:30:08 GMT):
indeed :-)

muralisr (Fri, 10 Feb 2017 23:30:27 GMT):
(reminds me of another recent regex experiance ;-)

greg.haskins (Fri, 10 Feb 2017 23:30:33 GMT):
heh

greg.haskins (Fri, 10 Feb 2017 23:30:55 GMT):
the danger is when you forget that not many people will know what that means

greg.haskins (Fri, 10 Feb 2017 23:31:13 GMT):
i mean in other scnenarios

greg.haskins (Fri, 10 Feb 2017 23:31:14 GMT):
not here

greg.haskins (Fri, 10 Feb 2017 23:31:20 GMT):
like texting my wife

muralisr (Fri, 10 Feb 2017 23:42:56 GMT):
right, i was reminded of the regex exchange and blurted it out ... :-)

rjones (Sat, 11 Feb 2017 00:25:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=tX9SvgM5bzPbhssNb) @yacovm he's missing a trailing `/g`, no?

cbf (Sat, 11 Feb 2017 09:54:51 GMT):
maybe I am missing something, but having the application "come" with the peers means a static relationship. This means I cannot dynamically add a peer node/cluster to a channel?

cbf (Sat, 11 Feb 2017 09:55:48 GMT):
so, if by some change in regulation a new auditor or regulatory body needed to have visibility to the transactions in a particular channel relationship, you'd have to redesign and redeploy? really?

yacovm (Sat, 11 Feb 2017 10:10:57 GMT):
@cbf - That means IIUC that you'll need to update the application somehow when peer(s) are added and/or are configured as endorsers.

cbf (Sat, 11 Feb 2017 10:11:19 GMT):
ugh, that isn't operationally scalable, IMO

yacovm (Sat, 11 Feb 2017 10:11:42 GMT):
The previous design, however- still has a problem that the app needs to know who are the peers of the channel.

cbf (Sat, 11 Feb 2017 10:12:10 GMT):
true, but this seems rather "hard coded"

cbf (Sat, 11 Feb 2017 10:12:49 GMT):
we could have tracked which peers on a channel in the ledger

cbf (Sat, 11 Feb 2017 10:13:11 GMT):
or some registry of sorts

yacovm (Sat, 11 Feb 2017 10:13:18 GMT):
Well- I really don't see why we can't add to the API of the peer an ability to query the peers of the channel

yacovm (Sat, 11 Feb 2017 10:13:26 GMT):
Gossip already stores and maintains this information

yacovm (Sat, 11 Feb 2017 10:13:31 GMT):
not for alpha of course

yacovm (Sat, 11 Feb 2017 10:14:01 GMT):
But- it's a no-brainer for gossip to expose that to the peer and if we somehow add an API call- you can have the app know only 1(!) peer

yacovm (Sat, 11 Feb 2017 10:14:18 GMT):
and then it could use that peer as a service-discovery endpoint

yacovm (Sat, 11 Feb 2017 10:14:40 GMT):
another totally different direction btw- is use a real service discovery service and integrate with it

yacovm (Sat, 11 Feb 2017 10:14:46 GMT):
like Eureka, or consul, etc.

yacovm (Sat, 11 Feb 2017 10:15:07 GMT):
(Or like bluemix's native service discovery service written in our group in Haifa ;) )

yacovm (Sat, 11 Feb 2017 10:15:28 GMT):
You can have the peers register into the service discovery service, and the app can come with a node.js client that can query that info

yacovm (Sat, 11 Feb 2017 10:15:32 GMT):
It's just a thought of course

C0rWin (Sat, 11 Feb 2017 10:16:17 GMT):
gossip maintains list of peers joined the channel while it's still doesn' know peers role, no? I mean we cannot differ between committer and endorser peer?

yacovm (Sat, 11 Feb 2017 10:16:35 GMT):
yeah we don't but that's fixable

C0rWin (Sat, 11 Feb 2017 10:17:15 GMT):
I do not think that gossip should do it :)

C0rWin (Sat, 11 Feb 2017 10:17:45 GMT):
IMO service discovery + DNS a way better approach

yacovm (Sat, 11 Feb 2017 10:17:54 GMT):
should do what?

C0rWin (Sat, 11 Feb 2017 10:18:23 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=WBcYKeLGL7RJ7v2cZ

yacovm (Sat, 11 Feb 2017 10:19:06 GMT):
oh- well- the benefit is that it's much less work than integrating with all kinds of service discovery products on the peer and the SDK side.

yacovm (Sat, 11 Feb 2017 10:20:13 GMT):
another problem is- what if from some reason the organization doesn't have service discovery? you'll tell it to deploy one? could be a problem.

mastersingh24 (Sat, 11 Feb 2017 10:26:08 GMT):
[ The reality is that most people will not separate the roles and worst case someone gets an error calling the endorse API and tries again](https://chat.hyperledger.org/channel/fabric-maintainers?msg=PRBrQfQES2CGDG2u2) @C0rWin

C0rWin (Sat, 11 Feb 2017 10:26:42 GMT):
ok, I'm still struggling with how it suppose to work right now? I mean how application discovers who are endorsers?

mastersingh24 (Sat, 11 Feb 2017 10:26:44 GMT):
we need to "define" a set of APIs for info the peer *should* provide and then figure out how to populate the responses to those

mastersingh24 (Sat, 11 Feb 2017 10:28:03 GMT):
1) config block has member orgs and anchor peers - we can make that info available 2) gossip will build up the list of peers on a channel by org

C0rWin (Sat, 11 Feb 2017 10:28:24 GMT):
and how app will access it?

mastersingh24 (Sat, 11 Feb 2017 10:28:26 GMT):
Am I correct on 2) - you know peers on a channel and the org for each peer

mastersingh24 (Sat, 11 Feb 2017 10:28:33 GMT):
API that I mentioned

mastersingh24 (Sat, 11 Feb 2017 10:28:34 GMT):
;)

yacovm (Sat, 11 Feb 2017 10:28:34 GMT):
yeah

C0rWin (Sat, 11 Feb 2017 10:28:41 GMT):
@mastersingh24 yes you correct

mastersingh24 (Sat, 11 Feb 2017 10:28:44 GMT):
we need to design those APIs

mastersingh24 (Sat, 11 Feb 2017 10:28:58 GMT):
oddly enough, that's on my lost to propose as a JIRA this weekend

mastersingh24 (Sat, 11 Feb 2017 10:28:58 GMT):
oddly enough, that's on my list to propose as a JIRA this weekend

yacovm (Sat, 11 Feb 2017 10:29:01 GMT):
I think that in any case the peer should expose them via gRPC

yacovm (Sat, 11 Feb 2017 10:29:10 GMT):
I mean, that the code of registration will be in the peer

mastersingh24 (Sat, 11 Feb 2017 10:30:46 GMT):
agreed

C0rWin (Sat, 11 Feb 2017 10:37:02 GMT):
I must be missing something, but how app will get list of endpoints for retries? https://chat.hyperledger.org/channel/fabric-maintainers?msg=aNF8yf75TppGTExme @mastersingh24

C0rWin (Sat, 11 Feb 2017 10:38:57 GMT):
and assuming we need to provide/support dynamicity of adding/removing peers, these endpoints are subject to changes...

C0rWin (Sat, 11 Feb 2017 10:39:23 GMT):
unless we relay on having DNS somehow

yacovm (Sat, 11 Feb 2017 10:44:57 GMT):
what I think he's saying is that the SDK can try to invoke a peer and if it's not an endorser it'll fail and re-try and invoke a different peer as if the first peer is offline. Regarding the membership changes- that's true, you need some bootstrapping point for the app to get a list of members from, and service discovery has an advantage in this area (but then you need service discover which is a disadvantage if you don't have it in your system)

C0rWin (Sat, 11 Feb 2017 10:46:50 GMT):
the invoke part is clear, the membership part is rather static right now

greg.haskins (Sat, 11 Feb 2017 13:40:41 GMT):
I think the notion of service discovery and namespace mapping, etc, are all critical services...but please please please dont be thinking of them as integrations with external services like Consul or DNS

greg.haskins (Sat, 11 Feb 2017 13:40:47 GMT):
it has to be in the fabric protocol

greg.haskins (Sat, 11 Feb 2017 13:40:52 GMT):
conceptually, yes

greg.haskins (Sat, 11 Feb 2017 13:41:02 GMT):
implementation, go integrated please

greg.haskins (Sat, 11 Feb 2017 13:41:57 GMT):
I am not denigrating products like Consul, but rather thing that architectually it needs to be tightly integrated

greg.haskins (Sat, 11 Feb 2017 13:41:57 GMT):
I am not denigrating products like Consul, but rather think that architectually it needs to be tightly integrated

yacovm (Sat, 11 Feb 2017 13:43:18 GMT):
but you can't get around the problem that you have an SDK and you have peers, and there is no way for the SDK to know the list of peers without DNS or service discovery

yacovm (Sat, 11 Feb 2017 13:43:25 GMT):
or a config file, that is

greg.haskins (Sat, 11 Feb 2017 13:43:34 GMT):
thats not what I am saying

greg.haskins (Sat, 11 Feb 2017 13:43:56 GMT):
I am saying "DNS and service discovery" == good, relying on components outside of the peer network == bad

yacovm (Sat, 11 Feb 2017 13:44:06 GMT):
ahh

greg.haskins (Sat, 11 Feb 2017 13:44:17 GMT):
bake the concept of DNS and service discovery into the fabric protocols

yacovm (Sat, 11 Feb 2017 13:44:38 GMT):
I think if we decide to solve this problem we should make it pluggable

greg.haskins (Sat, 11 Feb 2017 13:45:08 GMT):
sure, thats fine

muralisr (Sat, 11 Feb 2017 13:53:37 GMT):
catching up with the latest... (good morning!)

muralisr (Sat, 11 Feb 2017 14:55:08 GMT):
``` Trying this summary of today's discussion to make sure I understood... (please correct at will!) In a "consortium with orgs" network I'm assuming the following will typically be true . different applications with their own chaincode(s) will be running on the network . on any channel different sets of endorsers (with corresponding application/chaincode pairs) will be responsible for different transactions . if a peer needs to endorse it needs to have the chaincode for it - as an aside, this is where the new model will be different.. the chaincode has to be installed on the peer as chaincodes will not be on the ledger Given the above, we have the question "how does the application know which endorser to go to ?" One answer could be that application developers know the Orgs (and hence the peers) each application is targetted for and so will have to know about the peers anyway. The other answer could be that application itself needs discover the Org / peer for sending endorsements to. So we'd need a discovery service for the application to use. Such a discovery service would have to take the availability of chaincode on the peer into account. In either case, a discovery service supplied by the fabric and working in tandem with application seems to be a good thing... ```

muralisr (Sat, 11 Feb 2017 14:55:08 GMT):
``` Trying this summary of todays discussion to make sure I understood... (please correct at will!) In a "consortium with orgs" network assuming the following will typically be true . different applications with their own chaincode(s) will be running on the network . on any channel different sets of endorsers (with corresponding application/chaincode pairs) will be responsible for different transactions . if a peer needs to endorse it needs to have the chaincode for it - as an aside, this is where the new model will be different.. the chaincode has to be installed on the peer as chaincodes will not be on the ledger Given the above, we have the question "how does the application know which endorser to go to ?" One answer could be that application developers know the Orgs (and hence the peers) each application is targetted for and so will have to know about the peers anyway. The other answer could be that application itself needs discover the Org / peer for sending endorsements to. So wed need a discovery service for the application to use. Such a discovery service would have to take the availability of chaincode on the peer into account. In either case, a discovery service supplied by the fabric and working in tandem with application seems to be a good thing... ```

mastersingh24 (Sat, 11 Feb 2017 20:29:43 GMT):
@greg.haskins @yacovm - not sure if I understand the "bake the concept of DNS and discovery" into the fabric protocols discussion.

mastersingh24 (Sat, 11 Feb 2017 20:34:57 GMT):
what I was trying to get at is there is "information" which ordering and peer nodes have about the "network". - An application can connect to a peer node and/or an ordering node - Clearly the application will need to know at least one of those endpoints in order to do anything - The identity of the application will be scoped to one of the members / organizations else it won't be able to connect to any peer or ordering node - A peer node knows the following: channels it belongs to, information about those channels (which includes peer organizations (MSP and anchor peers) and orderer addresses/identities) and via gossip will know about public peer endpoints which are part of the channel) - Ordering nodes know about channels (which includes peer organizations (MSP and anchor peers) and orderer addresses/identities)

mastersingh24 (Sat, 11 Feb 2017 20:34:57 GMT):
what I was trying to get at is there is "information" which ordering and peer nodes have about the "network". - An application can connect to a peer node and/or an ordering node - Clearly the application will need to know at least one of those endpoints in order to do anything - The identity of the application will be scoped to one of the members / organizations else it won't be able to connect to any peer or ordering node - A peer node knows the following: channels it belongs to, information about those channels (which includes peer organizations (MSP and anchor peers) and orderer addresses/identities) and via gossip will know about public peer endpoints which are part of the channel), chaincodes (and the channels on which they are deployed), the endorsement policies for the chaincodes - Ordering nodes know about channels (which includes peer organizations (MSP and anchor peers) and orderer addresses/identities)

mastersingh24 (Sat, 11 Feb 2017 20:36:33 GMT):
given that a majority of the time applications will be communicating with peers for endorsement and then sending to orderers for ordering, it seems to me that an easy starting point is to make the information a peer possesses available to the client application

mastersingh24 (Sat, 11 Feb 2017 20:37:09 GMT):
(as a stupid example, in v0.6 you could use the /network endpoint to get the list of peers any given peer knew about)

muralisr (Sat, 11 Feb 2017 20:37:55 GMT):
@mastersingh24 `given that a majority of the time applications will be communicating with peers for endorsement ` - how did the apps know which peers to communicate with ?

mastersingh24 (Sat, 11 Feb 2017 20:38:15 GMT):
so you have to know at least one address to start with

mastersingh24 (Sat, 11 Feb 2017 20:39:25 GMT):
either a peer node or an ordering node. IMHO, getting the address of a single peer node would be the best starting point.

mastersingh24 (Sat, 11 Feb 2017 20:39:35 GMT):
but at the end of the day, you need to know some address

muralisr (Sat, 11 Feb 2017 20:39:35 GMT):
because of the binding with applications and orgs (and the txs), right ?

muralisr (Sat, 11 Feb 2017 20:40:12 GMT):
ie, we don't write applications in a vacuum... an org or set of orgs are involved in the dev of the application

mastersingh24 (Sat, 11 Feb 2017 20:40:54 GMT):
no matter how you solve the problem, you have to know something - typically that would be an endpoint address

muralisr (Sat, 11 Feb 2017 20:40:59 GMT):
right

muralisr (Sat, 11 Feb 2017 20:41:05 GMT):
I'm with you..

mastersingh24 (Sat, 11 Feb 2017 20:42:42 GMT):
and given that the peer has access to lots of info and given that in most cases the peer will be the center of the universe (either I own a peer and am writing applications or I am using someone else's peer to write applications), having the peer provide a set of APIs to make this info available seems to make the most sense to me

mastersingh24 (Sat, 11 Feb 2017 20:43:18 GMT):
of course you can create an external registry, etc to bootstrap this if you so desired, but I think we should provide some of this (in this simple form) out of the box

binhn (Sat, 11 Feb 2017 20:52:14 GMT):
every chaincode on a channel has an endorsement policy, which currently contains the MSPs (eg OR(msp1.members, msp2.members)), we also know that anchors must be part of the channel, so we could return the list of anchors of the channel and they would be responsible for disseminating the request to correct endorsers (that requires some more code). The alternative is to name the endorsers in the endorsement policy, and we would resolve the actual endpoints (DNS method)

yacovm (Sat, 11 Feb 2017 21:07:53 GMT):
@mastersingh24 - so, what I am saying is that I think that in the future we could add pluggable support for knowing about this "single peer" if in the organization there is a service discovery service or DNS.

mastersingh24 (Sat, 11 Feb 2017 21:08:53 GMT):
ok - that makes sense @yacovm - basically be able to "populate" an existing discovery or DNS service

mastersingh24 (Sat, 11 Feb 2017 21:10:05 GMT):
personally, I am a fan of using DNS SRV records ;)

muralisr (Sat, 11 Feb 2017 21:12:24 GMT):
what will be the queries to the discovery/domain service be ?

yacovm (Sat, 11 Feb 2017 21:13:28 GMT):
in case of DNS its like `dig all-kinds-of-params SRV`

yacovm (Sat, 11 Feb 2017 21:13:57 GMT):
in case of service-discovery, it's a REST call

mastersingh24 (Sat, 11 Feb 2017 21:15:13 GMT):
for DNS, SRV records like like `_Service ._ Protocol . DnsDomainName` , e.g. `_ldap._tcp.mastersingh.com`

mastersingh24 (Sat, 11 Feb 2017 21:16:17 GMT):
but in the end, once again I am saying the peers have a ton of info and we need to make it available ;)

muralisr (Sat, 11 Feb 2017 21:18:01 GMT):
so feeling a bit dense here :-) ...you are using `DNS` really in the tcp sense or as an abstraction for other service we could provide (e.g., `chaincodename.invokeparams`) ?

yacovm (Sat, 11 Feb 2017 21:20:29 GMT):
you use DNS to find the host:port of a single peer

yacovm (Sat, 11 Feb 2017 21:20:43 GMT):
and then you can talk to that peer and ask it what you need- who are the endorsers, etc.

mastersingh24 (Sat, 11 Feb 2017 21:20:47 GMT):
or multiple peers listed under a service with SRV records

muralisr (Sat, 11 Feb 2017 21:21:13 GMT):
ok. so basically DNS as in DNS

mastersingh24 (Sat, 11 Feb 2017 21:21:19 GMT):
correct

muralisr (Sat, 11 Feb 2017 21:21:23 GMT):
ok

mastersingh24 (Sat, 11 Feb 2017 21:22:02 GMT):
I like DNS SRV queries because they allow you to get a list of endpoints for a type of service

muralisr (Sat, 11 Feb 2017 21:23:45 GMT):
example of "type of service" for fabric ?

C0rWin (Sat, 11 Feb 2017 21:25:25 GMT):
endorsers, ordering service, I'd guess

muralisr (Sat, 11 Feb 2017 21:25:38 GMT):
channels on a peer ? peer ? orderer ..

yacovm (Sat, 11 Feb 2017 21:27:28 GMT):
I'd guess you can reserve a namespace for `orgA` to be something like `peers.orgA.com` or maybe even `channel1.peers.orgA.com`

yacovm (Sat, 11 Feb 2017 21:28:27 GMT):
but these are all talks, we can't even create a genesis block with all the PEM data in the CLI right now

yacovm (Sat, 11 Feb 2017 21:28:27 GMT):
but these are all talks, we can't even create a genesis block with all the PEM data with the CLI right now

mastersingh24 (Sat, 11 Feb 2017 21:32:14 GMT):
CLI sucks ;)

mastersingh24 (Sat, 11 Feb 2017 21:33:33 GMT):
hopefully we'll get all of @jyellick 's config stuff in soon and then we can get this going correctly

jyellick (Sat, 11 Feb 2017 21:35:09 GMT):
Working as fast as I can, CI not doing us any favors right now. But we should be able to scope anchor peer definition together with MSP definition soon.

muralisr (Sat, 11 Feb 2017 21:35:51 GMT):
CLI does NOT suck ;-) and if it does, we should make it not suck

yacovm (Sat, 11 Feb 2017 21:39:21 GMT):
1) Regarding the anchor peers- we would need to get rid of the PEM material in the `peer channel create` call but we would still need a list of host:port. I think a commit can be cooked prior to Jason finishing 2) Regarding the MSPs- there are still some stuff that need to be read from the CLI and can't be "just magically appear" in the genesis block. We need to enumerate all of these (Or, maybe they were but I'm simply not aware and in that case please point me to a JIRA if possible)

yacovm (Sat, 11 Feb 2017 21:39:21 GMT):
1) Regarding the anchor peers- we would need to get rid of the PEM material in the `peer channel create` call but we would still need a list of host:port. I think a commit can be cooked and then frozen until Jason finishes. 2) Regarding the MSPs- there are still some stuff that need to be read from the CLI and can't be "just magically appear" in the genesis block. We need to enumerate all of these (Or, maybe they were but I'm simply not aware and in that case please point me to a JIRA if possible)

mastersingh24 (Sat, 11 Feb 2017 22:02:59 GMT):
the CLI is NOT a good client. The fact that we try to make it be both a CLI for the peer running as a server and running as a client has been a big problem and with all of these new API calls (join channel, etc), things are even worse. Also - not sure why we attempt to configure anything directly related to the orderer via the peer CLI

mastersingh24 (Sat, 11 Feb 2017 22:04:04 GMT):
we need a REAL Go client SDK and if we want to build a CLI for the fabric we should be using that. But trying to add all commands to the peer executable has not worked well in a long time

mastersingh24 (Sat, 11 Feb 2017 22:06:12 GMT):
@yacovm - and while this is not something you did, I seriously question why we need to specify the MSPID for crypto operations. I don't understand why they are not strictly channel scoped. It would then be quite easy to build up the root of trust on a per channel basis. then there would never be a need to associate an anchor peer with an MSPID

yacovm (Sat, 11 Feb 2017 22:09:37 GMT):
I was under the impression that the MSP-ID is a way of identifying an organization in the MSP layer, isn't it? How can an MSP be channel scoped? it's built from root CA certs, and other stuff.

yacovm (Sat, 11 Feb 2017 22:10:31 GMT):
About the anchor peers- well, as you know- I work with what I get, and if I get a serializedIdentity constructor method that needs an MSP-ID, i give it an MSP-ID :)

mastersingh24 (Sat, 11 Feb 2017 22:14:19 GMT):
@yacovm - given a channel, it has a list of MSPs. There is no reason why you could not build a per channel trust store which includes all the root / intermediates for all MSPs defined in the channel

mastersingh24 (Sat, 11 Feb 2017 22:15:17 GMT):
By the way, to use TLS "out of the box", we are going to need to build a trust store that includes all MSPs for all channels for a which the peer is a meber

yacovm (Sat, 11 Feb 2017 22:17:33 GMT):
You already did 90% of the needed work

yacovm (Sat, 11 Feb 2017 22:21:04 GMT):
Regarding your MSP comment- what I think they do is: - Grab an identity - extract the MSP id - go to the peer's MSP by that id - ask the MSP- hey, is this identity ok?

yacovm (Sat, 11 Feb 2017 22:21:53 GMT):
this is a more "precise" way of validating signatures

mastersingh24 (Sat, 11 Feb 2017 22:27:48 GMT):
I can see it being more efficient if there are a lot of members per channel. but it is really ugly from the client / mgmt perspective - meaning for example when you build an app using one of the SDKs, you actually prepend the MSPID to the public cert bytes in creator field. I just think its ugly ;)

mastersingh24 (Sat, 11 Feb 2017 22:44:46 GMT):
On the CLI topic - I am not faulting what we have now as much as saying that it needs to be rethought given all the new config complexities of configuration

mastersingh24 (Sat, 11 Feb 2017 22:45:11 GMT):
but there are SO many changes happening that starting any revamp did not seem to make sense

muralisr (Sat, 11 Feb 2017 23:01:40 GMT):
right @mastersingh24 agreed ...especially `we need a REAL Go client SDK and if we want to build a CLI for the fabric we should be using that. But trying to add all commands to the peer executable has not worked well in a long time`

muralisr (Sat, 11 Feb 2017 23:02:11 GMT):
the main thing I like about CLI is that its a minimal interface.. you have the fabric, you got something to drive it immediately

muralisr (Sat, 11 Feb 2017 23:03:01 GMT):
but its boundaries need to be defined and its uses AND limitations spelled out.

muralisr (Sat, 11 Feb 2017 23:03:08 GMT):
but oh for a GO SDK

mastersingh24 (Sun, 12 Feb 2017 00:06:54 GMT):
luckily there are some nice folks working on a Go SDK ;)

mastersingh24 (Sun, 12 Feb 2017 00:07:38 GMT):
@muralisr - are you working on that earlier issue that was failing in CI (occasionally)?

mastersingh24 (Sun, 12 Feb 2017 00:08:18 GMT):
looks like you were correct - there are times with the payload of the chaincodemessage is not a response (like FSM errors)

muralisr (Sun, 12 Feb 2017 00:47:42 GMT):
@mastersingh24 ... fixed in https://gerrit.hyperledger.org/r/#/c/5889/

jyellick (Sun, 12 Feb 2017 01:48:28 GMT):
@cbf @rjones or others. What is our policy on clicking the submit button? If your own CR has two +2s from other maintainers, is it okay to click 'submit'? I've been avoiding this, but especially in cases where a CR is dependent on previous ones being merged, the second +2 may not have the ability to submit at review time. Just curious.

greg.haskins (Sun, 12 Feb 2017 03:03:39 GMT):
@mastersingh24 I was referring to this comment: https://chat.hyperledger.org/channel/fabric-maintainers?msg=6dwY5dEQHCAZp9AtA

greg.haskins (Sun, 12 Feb 2017 03:04:13 GMT):
I was commenting that whatever services we have (be it name resolution, discovery, etc, please make it integrated tightly

greg.haskins (Sun, 12 Feb 2017 03:04:52 GMT):
e.g. /network endpoint as in your example vs, say, mDNS + SRV records

hanhzf (Sun, 12 Feb 2017 04:10:51 GMT):
Has joined the channel.

rjones (Sun, 12 Feb 2017 04:48:32 GMT):
@jyellick personally, I don't have a problem with a submitter merging a change. This is a governance issue, or a social contract, so I'm not the right person to give you an authoritative answer

jyellick (Sun, 12 Feb 2017 05:24:36 GMT):
Understood, just thought there might be some standard practice standard across many LF projects

jyellick (Sun, 12 Feb 2017 05:24:36 GMT):
Understood, just thought there might be some standard practice across many LF projects

greg.haskins (Sun, 12 Feb 2017 14:57:04 GMT):
@jyellick My take is similar to @ry. I don't have a problem with it if the 2+2 is already met, though I try not to do it unless exceptional circumcstances

greg.haskins (Sun, 12 Feb 2017 14:57:25 GMT):
Like critical fix on a Saturday or something

greg.haskins (Sun, 12 Feb 2017 14:57:54 GMT):
Generally it's pretty rare this ever happens

greg.haskins (Sun, 12 Feb 2017 14:58:13 GMT):
Usually the last +2 excutes the merge I find

muralisr (Sun, 12 Feb 2017 23:04:12 GMT):
recently CI has had more chaincode test than usual. *

*This was caused by race in sending events over ... now that "init" is being treated like any other transaction we can /should use the same path *

* ... good news is the fix is simple and is mainly removal (firther streamlining of code) ... https://jira.hyperledger.org/browse/FAB-2203. Will have a fix shortly

muralisr (Sun, 12 Feb 2017 23:04:12 GMT):
recently CI has had more chaincode test failures than usual. *

*This was caused by race in sending events over ... now that "init" is being treated like any other transaction we can /should use the same path *

* ... good news is the fix is simple and is mainly removal (firther streamlining of code) ... https://jira.hyperledger.org/browse/FAB-2203. Will have a fix shortly

muralisr (Sun, 12 Feb 2017 23:11:42 GMT):
(sorry @rjones)

rjones (Sun, 12 Feb 2017 23:12:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ERLz5Dp65Z4cPLBfR) @jyellick LF provides structure, but each project (and really, each working group in each project) determines the rules they operate under

rjones (Sun, 12 Feb 2017 23:12:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=seCWwswDNkrJ9gSEk) @muralisr eh? nothing to apologize for.

muralisr (Sun, 12 Feb 2017 23:14:20 GMT):
I am fairly certain you might have been spending time wondering about these CI failures. :-) @rjones

rjones (Sun, 12 Feb 2017 23:15:13 GMT):
Yes, a little. :)

rjones (Mon, 13 Feb 2017 00:00:17 GMT):
I noticed I had accidentally left the permissions on github/fabric open to you all. I've removed that permission; if this causes you any troubles please let me know so we can work on it

muralisr (Mon, 13 Feb 2017 00:29:24 GMT):
submitted easy CR https://gerrit.hyperledger.org/r/#/c/5919 . CI succeeding first time out of the bat woukd be a good indication that https://jira.hyperledger.org/browse/FAB-2203 is fixed (going a bit on the limb here :-) )

muralisr (Mon, 13 Feb 2017 04:07:52 GMT):
it took one more CR actually https://gerrit.hyperledger.org/r/#/c/5923 ... and with https://gerrit.hyperledger.org/r/#/c/5919 should help a lot with CI

C0rWin (Mon, 13 Feb 2017 09:14:06 GMT):
I think we need to make this one: https://gerrit.hyperledger.org/r/#/c/5691/1 in, unless people will keep struggling to run steps from: http://hyperledger-fabric.readthedocs.io/en/latest/gettingstarted/

C0rWin (Mon, 13 Feb 2017 09:15:34 GMT):
@bmos299, @rameshthoomu can you please verify the CR and confirm it valid to be merged?

bmos299 (Mon, 13 Feb 2017 09:15:34 GMT):
Has joined the channel.

rjones (Mon, 13 Feb 2017 14:32:29 GMT):
@rameshthoomu Please sign https://gerrit.hyperledger.org/r/#/c/5691/2 !

rickr (Mon, 13 Feb 2017 18:27:43 GMT):
@mastersingh24 @binhn @yacovm @rjones @muralisr Can we get priority on https://gerrit.hyperledger.org/r/#/c/5899/ This will let the SDKs create test that are end to end again without a side process to install the chaincode.

cdaughtr (Mon, 13 Feb 2017 18:29:35 GMT):
Has joined the channel.

rjones (Mon, 13 Feb 2017 18:30:41 GMT):
@rickr I have no voting rights (or expertise) on that project

yacovm (Mon, 13 Feb 2017 18:31:37 GMT):
I stated my opinion. I do not think that the remote=true thing makes sense. The CLI is hard to use even now. I think we need to have normal flags and jf you already add a flag jn that cr, then it needa to be something that does it right

muralisr (Mon, 13 Feb 2017 18:38:16 GMT):
all CLI commands (at least all chaincode commands) so far have been on remote calls @yacovm and the default is to use CORE_PEER_ADDRESS. This is the one time where it is reversed - you are not doing an operation on the channel but doing it on the local peer. I just wanted that distinction

muralisr (Mon, 13 Feb 2017 18:38:48 GMT):
it might make sense to remove the "local" option altogether and just have remote - which is not a bad option

muralisr (Mon, 13 Feb 2017 18:41:06 GMT):
then it'll be uniform with other commands but we might lost the fact that is "installed" on the peer as opposed to a channel save

muralisr (Mon, 13 Feb 2017 18:41:54 GMT):
but that might just be an education thing and I'm fine with that change ... what do you think @binhn @yacovm ? Get rid of local install altighter in favor of using CORE_PEER_ADDRESS ?

binhn (Mon, 13 Feb 2017 18:58:08 GMT):
@rickr working on it

binhn (Mon, 13 Feb 2017 18:59:35 GMT):
@muralisr yes, that would simplify for the user

yacovm (Mon, 13 Feb 2017 18:59:42 GMT):
yes I think this is the best course of action

muralisr (Mon, 13 Feb 2017 19:00:15 GMT):
works for me too, thanks for the feed back @yacovm @binhn

muralisr (Mon, 13 Feb 2017 19:00:19 GMT):
will push shortly

yacovm (Mon, 13 Feb 2017 19:09:34 GMT):
I'm not at home in the next 2 hours so don't expect anything immediate

yacovm (Mon, 13 Feb 2017 19:10:08 GMT):
you know, being in a different continent, and all

mastersingh24 (Mon, 13 Feb 2017 19:55:49 GMT):
how disappointing @yacovm - we expect you to be availing at our beckon call ;)

mastersingh24 (Mon, 13 Feb 2017 19:55:49 GMT):
how disappointing @yacovm - we expect you to be availing at our beck and call ;)

yacovm (Mon, 13 Feb 2017 19:56:17 GMT):
Actually I'm back, the rain got me by surprise. Got back home all soaked

rjones (Mon, 13 Feb 2017 20:38:48 GMT):
have you agreed that the fabric-docs repo should be created, and the discussion is how to populate it - or are you @all discussing if the repo should be created at all? WRT https://jira.hyperledger.org/browse/FAB-2114?filter=-1

pmullaney (Mon, 13 Feb 2017 21:17:23 GMT):
Has joined the channel.

dshuffma (Tue, 14 Feb 2017 20:37:40 GMT):
so in the block structure, what is the difference/purpose for `Data` and `Metadata`?? i'm looking at the contents of my block and they seem awfully similar in content

dshuffma (Tue, 14 Feb 2017 20:39:22 GMT):

Message Attachments

kostas (Tue, 14 Feb 2017 20:51:30 GMT):
(@dshuffma: Let's take it #fabric, I'll respond there.)

kostas (Tue, 14 Feb 2017 20:51:30 GMT):
(@dshuffma: Let's take it to #fabric, I'll respond there.)

mbaizan (Wed, 15 Feb 2017 13:00:52 GMT):
Has joined the channel.

jansony1 (Wed, 15 Feb 2017 17:15:32 GMT):
Has joined the channel.

murrekatt (Thu, 16 Feb 2017 06:16:38 GMT):
Has joined the channel.

jojocheung (Thu, 16 Feb 2017 07:17:23 GMT):
Has joined the channel.

wutongtree (Thu, 16 Feb 2017 10:06:48 GMT):
Has joined the channel.

alviontaran (Thu, 16 Feb 2017 16:20:21 GMT):
Has joined the channel.

ylsGit (Fri, 17 Feb 2017 02:29:04 GMT):
Has joined the channel.

JonathanLevi (Fri, 17 Feb 2017 18:37:30 GMT):
An easy one that needs a "3rd" +2: https://gerrit.hyperledger.org/r/#/c/5027

JonathanLevi (Fri, 17 Feb 2017 18:37:59 GMT):
(already approved, but a manual rebase was needed)

muralisr (Fri, 17 Feb 2017 20:16:08 GMT):
with https://gerrit.hyperledger.org/r/#/c/6161 end-to-end tests work (channel create/join, chaincode install/instantiate/invoke/query)

vpaprots (Fri, 17 Feb 2017 21:50:29 GMT):
@rjones has there been any modifications to gerrit? Something odd going on, trying to push an update to a patchset and its trying to upload to a (different) closed item.. From what I read, gerrit picks where to drop this based on ChangeId, which I left the same..

rjones (Fri, 17 Feb 2017 22:19:47 GMT):
@vpaprots link please?

rjones (Fri, 17 Feb 2017 22:20:09 GMT):
I suspect the other change is on a different branch

vpaprots (Fri, 17 Feb 2017 22:20:32 GMT):
Ended up pushing to ref directly..

vpaprots (Fri, 17 Feb 2017 22:20:37 GMT):
vpapro@volodymyrs-mbp:~/git/src/github.com/hyperledger/fabric$ git push origin HEAD:refs/for/master Counting objects: 600, done. Delta compression using up to 8 threads. Compressing objects: 100% (318/318), done. Writing objects: 100% (600/600), 135.16 KiB | 0 bytes/s, done. Total 600 (delta 436), reused 367 (delta 263) remote: Resolving deltas: 100% (436/436) remote: Processing changes: refs: 1, done To ssh://gerrit.hyperledger.org:29418/fabric ! [remote rejected] HEAD -> refs/for/master (change http://gerrit.hyperledger.org/r/5705 closed) error: failed to push some refs to 'ssh://vpaprots@gerrit.hyperledger.org:29418/fabric' vpapro@volodymyrs-mbp:~/git/src/github.com/hyperledger/fabric$ git push origin HEAD:refs/changes/97/5897 Counting objects: 600, done. Delta compression using up to 8 threads. Compressing objects: 100% (318/318), done. Writing objects: 100% (600/600), 135.16 KiB | 0 bytes/s, done. Total 600 (delta 436), reused 367 (delta 263) remote: Resolving deltas: 100% (436/436) remote: Processing changes: updated: 1, refs: 1, done remote: remote: Updated Changes: remote: http://gerrit.hyperledger.org/r/5897 [FAB-1647] Yaml used to configure BCCSP remote: To ssh://gerrit.hyperledger.org:29418/fabric * [new branch] HEAD -> refs/changes/97/5897 vpapro@volodymyrs-mbp:~/git/src/github.com/hyperledger/fabric$

rjones (Fri, 17 Feb 2017 22:22:18 GMT):
5705 is merged. you can't re-use the change ID, it needs to be unique. that's what the error says.

vpaprots (Fri, 17 Feb 2017 22:22:52 GMT):
yep, except I was on 5897

vpaprots (Fri, 17 Feb 2017 22:23:11 GMT):
no clue why it got into its head to use 5705..

vpaprots (Fri, 17 Feb 2017 22:23:20 GMT):
http://stackoverflow.com/questions/24457418/how-to-change-a-patchset-and-push-it-as-a-new-one

vpaprots (Fri, 17 Feb 2017 22:24:03 GMT):
that says if I leave the `Change-Id` the same, it will match to existing, if I remove, it will upload to new..

vpaprots (Fri, 17 Feb 2017 22:24:37 GMT):
I had given up, tried uploading to new patchset by removing Change-Id.. still 5705!

rjones (Fri, 17 Feb 2017 22:27:03 GMT):
could I ask you to rebase? `git fetch origin master (or whateveer)` `git rebase -i origin/master`

rjones (Fri, 17 Feb 2017 22:27:19 GMT):
I suspect you are building on unmerged changes or something

vpaprots (Fri, 17 Feb 2017 22:29:29 GMT):
sure.. though, that was exactly what I was doing.. it was several hours ago, so I buy that I am yet again out of sync :(

vpaprots (Fri, 17 Feb 2017 22:30:11 GMT):
https://gerrit-review.googlesource.com/Documentation/user-upload.html#push_replace

vpaprots (Fri, 17 Feb 2017 22:30:43 GMT):
did the 'manual replacement mapping' per that doc

muralisr (Sat, 18 Feb 2017 22:40:48 GMT):
https://gerrit.hyperledger.org/r/#/c/6219 has been rebased to use https://gerrit.hyperledger.org/r/#/c/6225.. once it succeeds hopefully master will be back on track

greg.haskins (Sun, 19 Feb 2017 02:10:49 GMT):
@muralisr merged

muralisr (Sun, 19 Feb 2017 13:52:18 GMT):
ty @greg.haskins

greg.haskins (Sun, 19 Feb 2017 13:52:50 GMT):
np...keep an eye on https://gerrit.hyperledger.org/r/#/c/6167/

greg.haskins (Sun, 19 Feb 2017 13:52:57 GMT):
i think the remaining issues are fixed, waiting on CI

rickr (Sun, 19 Feb 2017 16:48:00 GMT):
I thaught heard some _talk_ of fabric having some issues is that all cleared up now ?

muralisr (Sun, 19 Feb 2017 18:08:14 GMT):
@greg.haskins started looking at 6167 and parents (looks real good but need a bit more time)

muralisr (Sun, 19 Feb 2017 18:09:20 GMT):
@rickr as far as I can tell the CLI based e2e is working but we are still working thru some issues from node-SDK ( @bretharrison and @adc might know more)

bretharrison (Sun, 19 Feb 2017 18:09:20 GMT):
Has joined the channel.

bretharrison (Sun, 19 Feb 2017 18:10:20 GMT):
still looking at it

adc (Sun, 19 Feb 2017 18:18:34 GMT):
so, we (are trying to have the node-SDK generating a proper txid. The issue is all about converting the output of the hash function to a string

sanchezl (Mon, 20 Feb 2017 05:27:23 GMT):
• https://gerrit.hyperledger.org/r/5929

sanchezl (Mon, 20 Feb 2017 05:28:25 GMT):
• https://gerrit.hyperledger.org/r/5857

dave.enyeart (Mon, 20 Feb 2017 15:04:58 GMT):
@all CI tests are failing intermittently due to the new CouchDB tests that were merged last night. I have a fix to disable the new CouchDB tests until we resolve the underlying problem. https://gerrit.hyperledger.org/r/#/c/6281/ Please +2 and merge as soon as possible.

dave.enyeart (Mon, 20 Feb 2017 16:11:37 GMT):
It passed verification and has two +2. Please merge.

jimthematrix (Mon, 20 Feb 2017 16:15:14 GMT):
@binhn @muralisr so at this point there's really no escc, vscc to be specified during chaincode deploy from the SDK correct? the endorser code uses only one of those each

binhn (Mon, 20 Feb 2017 16:20:03 GMT):
these is a default one but you don't have to specify that in your test if you want to use the default one

mastersingh24 (Mon, 20 Feb 2017 16:20:19 GMT):
do we have anything beyond the single signature at this point?

binhn (Mon, 20 Feb 2017 16:20:23 GMT):
the api should allow the user to pass in their e/vscc

jimthematrix (Mon, 20 Feb 2017 16:20:30 GMT):
are we going to support custom escc and vscc?

jimthematrix (Mon, 20 Feb 2017 16:20:38 GMT):
need to decide if we need to have that in the API at all

mastersingh24 (Mon, 20 Feb 2017 16:20:41 GMT):
we should AVOID people writing custom ESCC / VSCC though ;)

binhn (Mon, 20 Feb 2017 16:20:42 GMT):
of course

binhn (Mon, 20 Feb 2017 16:21:42 GMT):
@mastersingh24 from cli, you can see it support polish notation

binhn (Mon, 20 Feb 2017 16:22:00 GMT):
from api, we accept a signature policy proto

mastersingh24 (Mon, 20 Feb 2017 16:22:02 GMT):
ah - sorry - right

mastersingh24 (Mon, 20 Feb 2017 16:22:13 GMT):
I get confused the vscc actually enforces the policy

mastersingh24 (Mon, 20 Feb 2017 16:22:23 GMT):
escc is just for signing the response

binhn (Mon, 20 Feb 2017 16:22:34 GMT):
right

greg.haskins (Tue, 21 Feb 2017 01:29:46 GMT):
@mastersingh24 you had asked why not FROM scratch

greg.haskins (Tue, 21 Feb 2017 01:30:23 GMT):
its basically the same issue that killed the busybox effort: glibc/dns

greg.haskins (Tue, 21 Feb 2017 01:30:40 GMT):
otherwise, that is exactly what I would have done

greg.haskins (Tue, 21 Feb 2017 01:31:12 GMT):
(I created the hyperledger/fabric-baseos image as an alternative to the scratch/busybox option)

greg.haskins (Tue, 21 Feb 2017 01:31:29 GMT):
its not as small of course, but its also not broken ;)

kostas (Tue, 21 Feb 2017 02:17:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=vbzeKqiQSvNFeHYcN) @greg.haskins (For my own edification, what is a _slightly_ more expanded version of the `glibc/dns` issue?)

greg.haskins (Tue, 21 Feb 2017 02:19:24 GMT):
@kostas https://jira.hyperledger.org/browse/FAB-1652

greg.haskins (Tue, 21 Feb 2017 02:20:07 GMT):
in a nutshell, on any glibc based system, even compiling with -static doesnt completely decouple you from the host's .so files

greg.haskins (Tue, 21 Feb 2017 02:20:25 GMT):
this is because of how glibc implements the NSS feature

greg.haskins (Tue, 21 Feb 2017 02:21:30 GMT):
it materializes as a DNS issue because your static binary looks/acts like a static binary, but at runtime calls to functions like gethostbyname() will try to dlopen some of the nss runtime

greg.haskins (Tue, 21 Feb 2017 02:21:45 GMT):
which, with something like scratch/busybox wont be there

greg.haskins (Tue, 21 Feb 2017 02:23:09 GMT):
most of the solutions were non-trivial when considering things like supportability and multi-arch

greg.haskins (Tue, 21 Feb 2017 02:23:46 GMT):
so, ultimately, I created "baseos" as a next-best thing and with the understanding that it could be revisited someday

kostas (Tue, 21 Feb 2017 13:30:08 GMT):
@greg.haskins: Thank you for explaining this. I have read a few best-of practices for Docker, had seen the scratch image mentioned time and time again, and was wondering why we were going a different route. Now I know :)

greg.haskins (Tue, 21 Feb 2017 13:30:23 GMT):
yeah, it would have been awesome

greg.haskins (Tue, 21 Feb 2017 13:30:32 GMT):
we were using it until I found the DNS bug

greg.haskins (Tue, 21 Feb 2017 13:30:57 GMT):
the chaincode containers would be ~15M

greg.haskins (Tue, 21 Feb 2017 13:31:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=SaPXYGYb9396jNCYf) @greg.haskins to be clear, I meant we were using it to minimize the peer/orderer/ca....it hadnt been introduced to the chaincode at that time

greg.haskins (Tue, 21 Feb 2017 13:32:05 GMT):
in the end, I think it actually matters little because of how docker works

greg.haskins (Tue, 21 Feb 2017 13:32:30 GMT):
i.e. if "baseos" is 5MB or 150MB, you only pay that cost once

greg.haskins (Tue, 21 Feb 2017 13:32:39 GMT):
regardless of the number of containers

greg.haskins (Tue, 21 Feb 2017 13:33:53 GMT):
but, optics-wise, it looks better to have the container be smaller...and if anything ever gets into the situation where the chaincode containers need to be transferred around, smaller is better (not sure what the use case would be, but perhaps hosts like bluemix can take advantage)

greg.haskins (Tue, 21 Feb 2017 13:34:26 GMT):
the bigger win IMO is the elimination of unnecessary tools

greg.haskins (Tue, 21 Feb 2017 13:34:44 GMT):
from a security perspective

bretharrison (Tue, 21 Feb 2017 14:05:49 GMT):
Has left the channel.

sb2407 (Tue, 21 Feb 2017 18:35:12 GMT):
Has joined the channel.

mastersingh24 (Wed, 22 Feb 2017 13:34:25 GMT):
Hello fellow maintainers. I've officially sent a request proposing that Fabric graduate from incubation to active status. It's been a long time coming with a lot of hard work from the community. This will be a great achievement. Here's a link to the proposal: https://docs.google.com/document/d/1UQwQdAfK9DwTpGFQmIF7HU4YBTpx0ZG1VbdtGW1hlIQ/edit?usp=sharing

psa (Wed, 22 Feb 2017 15:55:59 GMT):
Has joined the channel.

JonathanLevi (Wed, 22 Feb 2017 22:06:15 GMT):
This project is definitely on the *active* side...

JonathanLevi (Wed, 22 Feb 2017 22:12:19 GMT):
Well, let's hope this goes through b/c this project is definitely on the *active* side...

weeds (Thu, 23 Feb 2017 19:18:39 GMT):
Exciting!

JonathanLevi (Thu, 23 Feb 2017 19:49:39 GMT):
Yes, certainly. BTW: on that note, the TSC vote regarding *fabric* will take place on Mar 2nd...

binhn (Fri, 24 Feb 2017 14:23:05 GMT):
what you guys think about removing z-linux CI? it hasn't been stabled and causing so much delay in getting the CRs merged. I know it's important to do CI on all but z hasn't been stabled since it's introduced

binhn (Fri, 24 Feb 2017 14:23:05 GMT):
what you guys think about removing z-linux CI? it hasn't been stable and causing so much delay in getting the CRs merged. I know it's important to do CI on all but z hasn't been stabled since it's introduced

yacovm (Fri, 24 Feb 2017 14:29:45 GMT):
Please let's do this. Time isn't on our side and these CI situation isn't helping

binhn (Fri, 24 Feb 2017 14:43:59 GMT):
being removed by ramesh

rameshthoomu (Fri, 24 Feb 2017 15:45:58 GMT):
@binhn I have submitted patch to disable voting for z jobs.. @rjones or @jwagantall have to merge this patch https://gerrit.hyperledger.org/r/#/c/6483/

rameshthoomu (Fri, 24 Feb 2017 15:45:58 GMT):
@binhn I have submitted patch to disable voting for power jobs.. @rjones or @jwagantall has to merge this patch https://gerrit.hyperledger.org/r/#/c/6483/

rameshthoomu (Fri, 24 Feb 2017 15:45:58 GMT):
@binhn I have submitted patch to disable voting for power jobs.. @rjones or @jwagantall have to merge this patch https://gerrit.hyperledger.org/r/#/c/6483/

jwagantall (Fri, 24 Feb 2017 15:45:58 GMT):
Has joined the channel.

rjones (Fri, 24 Feb 2017 16:14:54 GMT):
@binhn done

rameshthoomu (Fri, 24 Feb 2017 16:15:08 GMT):
thanks @rjones

muralisr (Fri, 24 Feb 2017 22:16:09 GMT):
CRs https://gerrit.hyperledger.org/r/#/c/6489/ https://gerrit.hyperledger.org/r/#/c/6379/ https://gerrit.hyperledger.org/r/#/c/5955/ should provide a stable commit level for the fabric with end to end function working with multiple MSPs, orgs and so forth....they have been reviewed, cherry picked and tested. Plan to test/merge these in within the next few hours. Unless urgent it'll be good to hold of other CRs till then

muralisr (Sat, 25 Feb 2017 00:03:21 GMT):
at `commit bb5a53f9c1f3c4427c1182ee6d93f7969ac40ebf` - confirm various tests pass after merging and testing. We can start working on other CRs now. Thanks for the patience!

blackskygg (Sat, 25 Feb 2017 16:52:35 GMT):
Has joined the channel.

blackskygg (Sat, 25 Feb 2017 16:57:07 GMT):
Hi there. I am in a team working on a blockchain project, and we've chosen fabric as our base platform. But we want the ability to quantify the resources used by every chaincode execution. So we want to know if there are any maintainers currently working on integrating fabric with Ethereum EVM or doing similar things.

sanchezl (Sat, 25 Feb 2017 20:39:49 GMT):
Looking for reviews on these two simple changes to fix up the permissions on some files that we flag as suspicious. It's currently blocking me from deploying any golang chaincode: • https://gerrit.hyperledger.org/r/6531 • https://gerrit.hyperledger.org/r/6529

muralisr (Sat, 25 Feb 2017 20:47:27 GMT):
@sanchezl https://gerrit.hyperledger.org/r/#/c/6531/ is just file perm change ?

muralisr (Sat, 25 Feb 2017 20:47:47 GMT):
oh both are ?

sanchezl (Sat, 25 Feb 2017 20:48:08 GMT):

Message Attachments

sanchezl (Sat, 25 Feb 2017 20:48:09 GMT):
correct

muralisr (Sat, 25 Feb 2017 20:49:03 GMT):
ok

sanchezl (Sat, 25 Feb 2017 20:49:08 GMT):
Just file perm change on both (one for fabric repo, a second set for fabric-ca repo)

muralisr (Sat, 25 Feb 2017 20:49:09 GMT):
waiting for CI

muralisr (Sat, 25 Feb 2017 21:17:37 GMT):
(also @sanchezl some people look only in fabric-pr-review for CRs to review... you may want to post there going forward)

weeds (Sat, 25 Feb 2017 22:38:55 GMT):
@blackskygg i think you might want to ask that question on the fabric- composer channel

blackskygg (Sun, 26 Feb 2017 03:41:23 GMT):
@weeds Thanks

blackskygg (Sun, 26 Feb 2017 04:13:47 GMT):
Has left the channel.

norinos (Mon, 27 Feb 2017 10:03:27 GMT):
Has joined the channel.

Hangyu (Mon, 27 Feb 2017 10:05:31 GMT):
Has joined the channel.

Hangyu (Mon, 27 Feb 2017 10:06:05 GMT):
Hi, all.. I tried to commit a changset to gerrit but failed at the compiling phase (got a -1 from Jobbuilder). This is a very trivial changset involves removing unused code. I tried twice but both were verified with failure (and the error messages ere different). Could anyone so kindly give me some advises on this?

JonathanLevi (Mon, 27 Feb 2017 11:30:56 GMT):
Hello @Hangyu! 1. Absolutely. 2. What CR? 3. Let's take it to the #fabric-pr-review channel?

hgabre (Mon, 27 Feb 2017 12:09:01 GMT):
do we have a powerpc channel anywhere?

binhn (Mon, 27 Feb 2017 23:45:42 GMT):
hi folks, I'd like to hold all new functions from being merged to stabilize the code for beta. We should only merge bug fixes, unit tests or bdd from now until we release the beta

binhn (Mon, 27 Feb 2017 23:46:31 GMT):
our current objective is to drive down this list https://jira.hyperledger.org/issues/?filter=10500

daijianw (Tue, 28 Feb 2017 03:13:08 GMT):
Has joined the channel.

rickr (Tue, 28 Feb 2017 13:24:17 GMT):
@binhn @jyellick @muralisr For chain creation the SDKs end users need a config transaction file. Where can I reference on how to create that ?

muralisr (Tue, 28 Feb 2017 15:32:54 GMT):
@rickr https://gerrit.hyperledger.org/r/#/c/6287/ puts the capability for creating config files for channel creation. It has a md on how to use the tool. We shoukd supplement that with a sample... will take that up

binhn (Tue, 28 Feb 2017 15:38:31 GMT):
@rjones can we revert this back?

rjones (Tue, 28 Feb 2017 15:43:34 GMT):
@binhn revert exactly what?

rickr (Tue, 28 Feb 2017 15:43:36 GMT):
@muralisr @binhn https://jira.hyperledger.org/browse/FAB-2536 Sending initiate proposal causes Peer panic

binhn (Tue, 28 Feb 2017 15:44:35 GMT):
@rjones undo this merge https://gerrit.hyperledger.org/r/#/c/6549

rjones (Tue, 28 Feb 2017 15:46:40 GMT):
https://gerrit.hyperledger.org/r/#/c/6633

rjones (Tue, 28 Feb 2017 15:50:25 GMT):
@binhn ^^^

binhn (Tue, 28 Feb 2017 16:26:42 GMT):
@rjones thanks

rjones (Tue, 28 Feb 2017 16:27:20 GMT):
@binhn add reviewers you think are appropriate - not sure who that would be

binhn (Tue, 28 Feb 2017 16:27:30 GMT):
will do

troyronda (Tue, 28 Feb 2017 23:26:11 GMT):
I posted the Fabric Go SDK proposal to the wiki

troyronda (Tue, 28 Feb 2017 23:26:54 GMT):
(https://wiki.hyperledger.org/community/proposals | https://docs.google.com/document/d/1tYk3t8pF2mj4IGSzPvGopzKxSz8okTW749UyNqxTGZk)

Donald Liu (Thu, 02 Mar 2017 01:25:22 GMT):
Has joined the channel.

YueyueZhao (Thu, 02 Mar 2017 11:08:30 GMT):
Has joined the channel.

troyronda (Thu, 02 Mar 2017 16:46:20 GMT):
Has left the channel.

troyronda (Thu, 02 Mar 2017 16:46:29 GMT):
Has joined the channel.

troyronda (Thu, 02 Mar 2017 16:54:56 GMT):
hi maintainers - just checking if you saw the proposal notice above? thanks 🙂

cbf (Thu, 02 Mar 2017 20:02:55 GMT):
so, heads up regarding https://gerrit.hyperledger.org/r/#/c/6741/

cbf (Thu, 02 Mar 2017 20:03:00 GMT):
it's a biggun

cbf (Thu, 02 Mar 2017 20:03:42 GMT):
however, it is _mostly_ a translation from markdown to RST so that we can take advantage of some of the styling features of RTD

cbf (Thu, 02 Mar 2017 20:04:03 GMT):
however, it does include a reorg of content and some updated content

cbf (Thu, 02 Mar 2017 20:04:18 GMT):
will try not to have this ever happen again;-)

cbf (Thu, 02 Mar 2017 20:05:10 GMT):
my recommendation to the team is to merge this and then undertake a thorough review of the docs which will be driven by @markparz on #fabric-documentation

markparz (Thu, 02 Mar 2017 20:05:11 GMT):
Has joined the channel.

RezwanKabir (Thu, 02 Mar 2017 20:08:03 GMT):
Has joined the channel.

JonathanLevi (Thu, 02 Mar 2017 20:28:28 GMT):
@cbf ;-)

binhn (Thu, 02 Mar 2017 20:33:40 GMT):
can someone with more privilege undo this commit https://gerrit.hyperledger.org/r/#/c/6273 ?

binhn (Thu, 02 Mar 2017 20:34:19 GMT):
vendoring files should not have been changed

binhn (Thu, 02 Mar 2017 20:34:46 GMT):
@JonathanLevi @mastersingh24

mastersingh24 (Thu, 02 Mar 2017 20:39:15 GMT):
what are you talking about?

mastersingh24 (Thu, 02 Mar 2017 20:39:25 GMT):
we vendor bccsp and it's been updated

mastersingh24 (Thu, 02 Mar 2017 20:39:40 GMT):
I am confused

mastersingh24 (Thu, 02 Mar 2017 20:39:50 GMT):
we need the latest version of bccsp

binhn (Thu, 02 Mar 2017 20:41:17 GMT):
the lastest of bccsp is in fabric, not here -- from this cr, a different code is here

mastersingh24 (Thu, 02 Mar 2017 20:43:07 GMT):
??????

mastersingh24 (Thu, 02 Mar 2017 20:43:23 GMT):
this is the code from fabric

binhn (Thu, 02 Mar 2017 20:43:58 GMT):
no, it contains extra code from the author submitted by mistake

mastersingh24 (Thu, 02 Mar 2017 20:44:40 GMT):
@vpaprots - can you please comment here?

binhn (Thu, 02 Mar 2017 20:44:55 GMT):
probably we don't have to undo but just revendoring to get all back

vpaprots (Thu, 02 Mar 2017 20:47:46 GMT):
I was prototyping what else I needed for fabric-ca.. GetBCCSPFromOpts in https://gerrit.hyperledger.org/r/#/c/6273/6/vendor/github.com/hyperledger/fabric/bccsp/factory/factory.go

vpaprots (Thu, 02 Mar 2017 20:48:20 GMT):
seems between rebases for the paired change (which is where that function was supposed to have stayed!!) I ended up merging into the revendor?

vpaprots (Thu, 02 Mar 2017 20:49:51 GMT):
there are no calls to it, all the uses are coming in new code.. I just can't be going back and forth updating bccsp for every function, so was going to keep on working on collecting them all

mastersingh24 (Thu, 02 Mar 2017 20:49:55 GMT):
ok - well it's going to end up in fabric/bccsp anyway, correct? so really not sure what the big issue is? these are two separate projects anyway

vpaprots (Thu, 02 Mar 2017 20:50:07 GMT):
yes, it will go into bccsp

mastersingh24 (Thu, 02 Mar 2017 20:51:19 GMT):
I guess we can do another CR to bring to vendor the "current" fabric/bccsp package?

JonathanLevi (Thu, 02 Mar 2017 20:51:27 GMT):
Yes, let's do that.

JonathanLevi (Thu, 02 Mar 2017 20:52:00 GMT):
The * GetBCCSPFromOpts* is certainly needed (which is what I focused on).

JonathanLevi (Thu, 02 Mar 2017 20:52:10 GMT):
@binhn: OK ?

mastersingh24 (Thu, 02 Mar 2017 20:53:55 GMT):
still trying to understand what the big issue is/was here?

mastersingh24 (Thu, 02 Mar 2017 20:56:57 GMT):
someone doing something with fabric-ca that we don't know about?

binhn (Thu, 02 Mar 2017 20:57:10 GMT):
the issue here is that we were not doing vendoring but forking the code -- we can't accept changes that are not bugs into Fabric at this point. If it is not used, let's keep it out for now until we cut the branch; folks can certainly work on their own branches.

binhn (Thu, 02 Mar 2017 20:57:56 GMT):
that's my take -- many maintainers here that can override my opinion

mastersingh24 (Thu, 02 Mar 2017 21:00:11 GMT):
well we should not be cutting a new branch either - I assume you mean tag and build images?

binhn (Thu, 02 Mar 2017 21:02:11 GMT):
tag is fine when we feel the quality is there

mastersingh24 (Thu, 02 Mar 2017 21:03:07 GMT):
`we were not doing vendoring but forking the code` - so how did you find this? it was an update of vendor unless I missed something. Now apparently the code that got vendored was ahead of the code in fabric master at this point

mastersingh24 (Thu, 02 Mar 2017 21:03:16 GMT):
but how did you figure that out?

mastersingh24 (Thu, 02 Mar 2017 21:04:10 GMT):
(meaning the bccsp in fabric-ca was behind the bccsp code in fabric master)

binhn (Thu, 02 Mar 2017 21:08:41 GMT):
it's the other way around: this cr contains code not in fabric bccsp, which we have decided to leave out of "beta"

mastersingh24 (Thu, 02 Mar 2017 21:09:36 GMT):
no - I get that is the case -

mastersingh24 (Thu, 02 Mar 2017 21:09:45 GMT):
but the intent was to update to the same bccsp

mastersingh24 (Thu, 02 Mar 2017 21:09:52 GMT):
as current fabric master

mastersingh24 (Thu, 02 Mar 2017 21:10:26 GMT):
I guess I am wondering how you can tell that this was not the same code as in fabric master. did you doa file by file comparison?

mastersingh24 (Thu, 02 Mar 2017 21:10:45 GMT):
prior to this, bccsp in fabric-ca was downlevel from fabric mater

mastersingh24 (Thu, 02 Mar 2017 21:10:45 GMT):
prior to this, bccsp in fabric-ca was downlevel from fabric master

mastersingh24 (Thu, 02 Mar 2017 21:11:27 GMT):
so just wondering how we could have better figured this out when we reviewed it

binhn (Thu, 02 Mar 2017 21:13:04 GMT):
ah, i just saw functions that i know not in fabric -- just being familiar with the code

JonathanLevi (Thu, 02 Mar 2017 21:13:13 GMT):
Aha! ;-)

JonathanLevi (Thu, 02 Mar 2017 21:13:34 GMT):
So there are a few issues here, 1. First: @Binhn, re: "that's my take -- many maintainers here that can override my opinion"

JonathanLevi (Thu, 02 Mar 2017 21:13:58 GMT):
-> I agree with you. Not overriding your opinion.

JonathanLevi (Thu, 02 Mar 2017 21:14:47 GMT):
2. I (can speak for myself, and so I) was under the impression that we want to have the same BCCSP version in Fabric-CA, to be aligned with the "latest" BCCSP that's in fabric.

JonathanLevi (Thu, 02 Mar 2017 21:15:00 GMT):
3. There was a genuine mistake by the CR Author.

JonathanLevi (Thu, 02 Mar 2017 21:15:34 GMT):
[ An extra function was added to the vendor'ed that is now in Fabric-CA but it's not in Fabric. ]

JonathanLevi (Thu, 02 Mar 2017 21:16:27 GMT):
Which brings me to publicly ask the following: 4. Is it not important for us to have the BCCSP integrated into fabric-ca for the upcoming release?

JonathanLevi (Thu, 02 Mar 2017 21:16:51 GMT):
(because that function that is now in fabric-ca, is really needed for fabric-ca... )

JonathanLevi (Thu, 02 Mar 2017 21:17:15 GMT):
Which is what I was asking above:

JonathanLevi (Thu, 02 Mar 2017 21:17:24 GMT):
[Here: ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Rn7yv39esXPf3u65k) @JonathanLevi

JonathanLevi (Thu, 02 Mar 2017 21:18:19 GMT):
Therefore, I asked @binhn, whether it is acceptable to add that function now to the bccsp version of fabric [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ppb4chZdZdchQwBXB) @JonathanLevi

JonathanLevi (Thu, 02 Mar 2017 21:21:23 GMT):
Meaning, if we want to freeze "fabric", that's fine as well.

JonathanLevi (Thu, 02 Mar 2017 21:21:47 GMT):
I just know that fabric-ca won't be able to use the current version that is in fabric without that change.

JonathanLevi (Thu, 02 Mar 2017 21:21:47 GMT):
I just know that *fabric-ca* won't be able to use the current BCCSP version that is in *fabric* without that change.

binhn (Thu, 02 Mar 2017 21:22:00 GMT):
@vpaprots said that the function is not being called, so I am not clear on what you meant by "which is what I focused on" ?

JonathanLevi (Thu, 02 Mar 2017 21:22:20 GMT):
Oh, I'm glad you ask!

JonathanLevi (Thu, 02 Mar 2017 21:22:58 GMT):
The reason for us merging the above, is for paving the way for https://gerrit.hyperledger.org/r/#/c/6727/ "https://gerrit.hyperledger.org/r/#/c/6727"

JonathanLevi (Thu, 02 Mar 2017 21:22:58 GMT):
The reason for us merging the above, is for paving the way for https://gerrit.hyperledger.org/r/#/c/6727/ " [FAB-2601] Fabric CA BCCSP integration"

JonathanLevi (Thu, 02 Mar 2017 21:22:58 GMT):
The reason for us merging the above, is for paving the way for https://gerrit.hyperledger.org/r/#/c/6727/ "[FAB-2601] Fabric CA BCCSP integration"

JonathanLevi (Thu, 02 Mar 2017 21:24:24 GMT):
And I appreciate that it wasn't clear from the commit message.

binhn (Thu, 02 Mar 2017 21:25:01 GMT):
but you can certainly integrate bccsp without that code - what specific capabilities on CA that we need that function?

JonathanLevi (Thu, 02 Mar 2017 21:25:06 GMT):
At first, I honestly thought that this is just "synchronizing" fabric and bccsp.

JonathanLevi (Thu, 02 Mar 2017 21:25:06 GMT):
At first, I honestly thought that this is just "synchronizing" fabric-ca with fabric's bccsp.

mastersingh24 (Thu, 02 Mar 2017 21:25:43 GMT):
there are separate servers for ecerts and tcerts

mastersingh24 (Thu, 02 Mar 2017 21:26:05 GMT):
internally

binhn (Thu, 02 Mar 2017 21:28:25 GMT):
@mastersingh24 so we need GetBCCSPFromOpts for tcerts generation?

mastersingh24 (Thu, 02 Mar 2017 21:28:47 GMT):
I think we can live without it for now - but longer term we do need it

mastersingh24 (Thu, 02 Mar 2017 21:29:54 GMT):
in any case, we should make sure that bccsp in fabric-ca and bccsp in fabric are the same

mastersingh24 (Thu, 02 Mar 2017 21:30:21 GMT):
so we can have Vlad submit another CR. I actually think that function is the only difference?

JonathanLevi (Thu, 02 Mar 2017 21:33:11 GMT):
@binhn, @mastersingh24: I think so, it boils down to this:

JonathanLevi (Thu, 02 Mar 2017 21:33:12 GMT):
https://gerrit.hyperledger.org/r/#/c/6273/1..6/vendor/github.com/hyperledger/fabric/bccsp/factory/factory.go

binhn (Thu, 02 Mar 2017 21:34:23 GMT):
yes, but vlad knows more on how much of an impact if any -- it sounds like it is not being called, so we can accept that into fabric or remove it from ca

mastersingh24 (Thu, 02 Mar 2017 21:36:21 GMT):
ok - let's go with the following:

mastersingh24 (Thu, 02 Mar 2017 21:36:39 GMT):
1) have Vlad push the change to fabric master - should only be this function

mastersingh24 (Thu, 02 Mar 2017 21:37:08 GMT):
2) we will revendor bccsp into fabric-ca after that so we are totally in sync

mastersingh24 (Thu, 02 Mar 2017 21:38:11 GMT):
BUT - given it will go into fabric anyway, I'm also OK with fabric-ca running with this for now as well and holding off on merging to fabric. Risk is minimal on the fabric-ca side

binhn (Thu, 02 Mar 2017 21:38:39 GMT):
:thumbsup:

JonathanLevi (Thu, 02 Mar 2017 21:40:03 GMT):
@binhn: which one?

JonathanLevi (Thu, 02 Mar 2017 21:41:13 GMT):
1) "have Vlad push the change to fabric master - should only be this function" Merging that function into fabric as well, so that they are both in synch right now? (after verifying with Vlad) or, 2) "fabric-ca running with this for now as well and holding off on merging to fabric"

JonathanLevi (Thu, 02 Mar 2017 21:41:13 GMT):
1) "have Vlad push the change to fabric master - should only be this function" Merging that function into fabric's BCCSP as well, so that they are both in synch right now? (after verifying with Vlad) or, 2) "fabric-ca running with this for now as well and holding off on merging to fabric"

JonathanLevi (Thu, 02 Mar 2017 21:42:00 GMT):
[FWIW, I'm fine with either resolutions. Let's do the right thing.]

mastersingh24 (Thu, 02 Mar 2017 21:59:02 GMT):
BTW - you have a Mac, right?

mastersingh24 (Thu, 02 Mar 2017 21:59:47 GMT):
are you using the desktop RocketChat app for Mac? I just started using it and its definitely better than there web interface

JonathanLevi (Thu, 02 Mar 2017 22:00:44 GMT):
Yes, the web interface (even on Safari! ;-)) is not great.

mastersingh24 (Thu, 02 Mar 2017 22:00:53 GMT):
wrong channel ;)

JonathanLevi (Thu, 02 Mar 2017 22:01:39 GMT):
Oh yeah, I should have mentioned: the Mac application has a bug, where it does not always update the current channel you are typing in.

JonathanLevi (Thu, 02 Mar 2017 22:01:39 GMT):
Oh yeah, I should have mentioned: the Mac application has a bug, where it does not always correctly show current channel you are typing in.

JonathanLevi (Thu, 02 Mar 2017 22:01:41 GMT):
Not joking.

yacovm (Thu, 02 Mar 2017 22:01:43 GMT):
these channels will be the death of us

yacovm (Thu, 02 Mar 2017 22:02:22 GMT):
it's a bug in the web app too

JonathanLevi (Thu, 02 Mar 2017 22:02:24 GMT):
Well, it's a good practice to have everything broadcasted on the blockchain, unencrypted ;-)

JonathanLevi (Thu, 02 Mar 2017 22:02:24 GMT):
Well, is it good practice to have everything broadcasted on the blockchain, unencrypted? ;-) [rephrased]

mastersingh24 (Thu, 02 Mar 2017 22:10:39 GMT):
its a good practice to use Slack ;)

binhn (Fri, 03 Mar 2017 15:18:32 GMT):
to consider # Trivial fix, no risk [FAB-2455] Fix misleading log statment # Proto change, I see this as must have, as they break ABI [FAB-2468] configtx ChannelHeader to ChannelId # Proto change, had been held off until Readers/Writers/Admins were correctly set [FAB-2615] Remove Ingress/EgressPolicyNames refs # A malicious user could use this to trivially crash the system [FAB-2616] Fix potential crash in cauthdsl # Proto changes, these are very low risk, no ABI, only API [FAB-2471] Fix gossip proto style 1/3 [FAB-2472] Fix gossip proto style 2/3 [FAB-2473] Fix gossip proto style 3/3 # Code refactoring which reduces code lines, an increases test coverage # Also a prereq to the configtx inspection, and needed for bugfix FAB-2552 [FAB-2335] Move channel config to common Proposer [FAB-2396] Move orderer config to common Proposer [FAB-2397] Move org config to common Proposer [FAB-2477] Move application config to Proposer [FAB-2399] ApplicationOrg config to common Proposer [FAB-2526] Move consolidate config to one package # Fixes a potential crash [FAB-2552] Allow concurrent config proposals # Changes to enable configtx inspection [FAB-2511] Make configtx sequence explicit [FAB-2554] configtx.Manager track deserialized val [FAB-2574] Config parsing outside configtx.Manager [FAB-2577] Add JSON rendering of configResult [FAB-2584] configtxgen prints block config as json [FAB-2612] Enable configtxgen configtx inspection

bmos299 (Fri, 03 Mar 2017 15:31:43 GMT):
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

bmos299 (Fri, 03 Mar 2017 15:47:52 GMT):
++

bmos299 (Fri, 03 Mar 2017 15:47:52 GMT):
+

bmos299 (Fri, 03 Mar 2017 15:49:48 GMT):
++++++++++++++++++++++++

bmos299 (Fri, 03 Mar 2017 15:49:50 GMT):
+

bmos299 (Fri, 03 Mar 2017 15:50:00 GMT):
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

bmos299 (Fri, 03 Mar 2017 15:51:32 GMT):
+

mastersingh24 (Fri, 03 Mar 2017 15:56:29 GMT):
@bmos299 - are you drinking already?

yacovm (Fri, 03 Mar 2017 16:07:38 GMT):
It looks like a cat is on the loose in the lab

greg.haskins (Fri, 03 Mar 2017 17:50:10 GMT):
@mastersingh24 @binhn @cbf as we roll closer to alpha, I assume we will consider creating a branch (e.g. v1.0.0-alpha) ?

cbf (Fri, 03 Mar 2017 17:50:23 GMT):
yes

greg.haskins (Fri, 03 Mar 2017 17:50:41 GMT):
we seem to already have JIRA entries for v1.0.0 and v1.1 so we'll need to start managing those CRs

mastersingh24 (Fri, 03 Mar 2017 18:03:04 GMT):
guys - are we really going to cut a branch? I don't want to be merging fixes against an alpha branch. so are we saying we don't fix bugs on the alpha branch?

mastersingh24 (Fri, 03 Mar 2017 18:04:02 GMT):
we wouldn't we just tag, set the release flag to true and publish the docker images?

mastersingh24 (Fri, 03 Mar 2017 18:04:51 GMT):
then we continue to work on master and do the same thing when we are ready for another release? or - I guess I'm fine if we are not managing fixes against the alpha branch

yacovm (Fri, 03 Mar 2017 18:06:39 GMT):
When are we cutting a branch? And if it's going to be soon can anyone take a peek at https://chat.hyperledger.org/channel/fabric-pr-review?msg=XSyPjW89A9Wvf5eHP please?

mastersingh24 (Fri, 03 Mar 2017 18:25:53 GMT):
stop gossiping ;)

mastersingh24 (Fri, 03 Mar 2017 18:25:56 GMT):
haha

greg.haskins (Fri, 03 Mar 2017 18:27:09 GMT):
@mastersingh24 we dont have to, but whatever development stream will be "alpha1" will probably want more control over how we treat master at some point

greg.haskins (Fri, 03 Mar 2017 18:27:34 GMT):
so either a branch, or discretion on merging CRs would be in order

greg.haskins (Fri, 03 Mar 2017 18:27:52 GMT):
I am fine if we dont do a branch, honestly, as it wasnt managed well last time

mastersingh24 (Fri, 03 Mar 2017 18:28:11 GMT):
I know moving forward we'll need to do branches for releases, it was just the alpha that concerned me a bit

greg.haskins (Fri, 03 Mar 2017 18:28:18 GMT):
(the whole master vs v1.0 branch was a mess for @muralisr and I to sort out)

mastersingh24 (Fri, 03 Mar 2017 18:28:28 GMT):
but perhaps we just do a branch

greg.haskins (Fri, 03 Mar 2017 18:28:44 GMT):
so if we do do branches, i hope we automate thigns a little more so they are merged more regularly

mastersingh24 (Fri, 03 Mar 2017 18:29:42 GMT):
and I guess we just use our best judgement in terms of making any fixes on the initial alpha branch versus cutting an alpha2

greg.haskins (Fri, 03 Mar 2017 18:30:14 GMT):
im not sure what you mean, but I would say branches and releases are distinct beasts

greg.haskins (Fri, 03 Mar 2017 18:30:33 GMT):
so I wouldnt see those as othogonal operations

greg.haskins (Fri, 03 Mar 2017 18:30:48 GMT):
but interelated

mastersingh24 (Fri, 03 Mar 2017 18:30:51 GMT):
they are except when you actually have branches that map to releases

greg.haskins (Fri, 03 Mar 2017 18:31:14 GMT):
dont do that, please ;)

greg.haskins (Fri, 03 Mar 2017 18:31:27 GMT):
a branch is a stream, a release is a point in time on a stream

greg.haskins (Fri, 03 Mar 2017 18:31:51 GMT):
treating branches as tags can be done, but it doesnt make sense

greg.haskins (Fri, 03 Mar 2017 18:32:46 GMT):
if we dont want an alpha stream, thats totally fine, but just tag the point in time and be done

mastersingh24 (Fri, 03 Mar 2017 18:32:57 GMT):
I like the tag option

greg.haskins (Fri, 03 Mar 2017 18:33:29 GMT):
in the spirit of "CICD" that is the path of least friction

greg.haskins (Fri, 03 Mar 2017 18:33:59 GMT):
BUT, it would require some discipline on when we take various CRs if there really is a v1.0 vs v1.1 intention

mastersingh24 (Fri, 03 Mar 2017 18:34:09 GMT):
I know

greg.haskins (Fri, 03 Mar 2017 18:34:29 GMT):
not sure we currently have that discipline ;)

mastersingh24 (Fri, 03 Mar 2017 18:34:40 GMT):
but I think that's where I might distinguish between this alpha and what we do moving forward

greg.haskins (Fri, 03 Mar 2017 18:34:50 GMT):
i see, and yes, i would be ok with that

mastersingh24 (Fri, 03 Mar 2017 18:34:56 GMT):
I see this alpha as a point in time snapshot on the way to v1.0.0

greg.haskins (Fri, 03 Mar 2017 18:35:06 GMT):
snap it, keep moving

greg.haskins (Fri, 03 Mar 2017 18:58:51 GMT):
@mastersingh24 anyway, I see your point and agree we could manage the alpha this way...the reason i was bringing this up is I wanted to have the general conversation about how we will manage branches in general, when the time comes

greg.haskins (Fri, 03 Mar 2017 18:59:11 GMT):
I want to avoid what happened last time, as a lessons-learned kind of endeavor ;)

greg.haskins (Fri, 03 Mar 2017 18:59:37 GMT):
so, perhaps its later rather than sooner, and that is a good thing as it gives us more time to plan

greg.haskins (Fri, 03 Mar 2017 18:59:49 GMT):
(assuming we have branches eventually)

greg.haskins (Fri, 03 Mar 2017 19:00:50 GMT):
the basic problem, as I see it, was we had several branches (v0.6, v1.0 and master) to which devs were, for the most part, focused only on one

greg.haskins (Fri, 03 Mar 2017 19:01:12 GMT):
so, they would submit CRs against whatever stream was the most important to them, and be done with it

greg.haskins (Fri, 03 Mar 2017 19:01:52 GMT):
this isnt to say everyone did this..there were some that we diligent about submitting CRs to all the relevant places, and I thank them for that

greg.haskins (Fri, 03 Mar 2017 19:01:52 GMT):
this isnt to say everyone did this..there were some that were diligent about submitting CRs to all the relevant places, and I thank them for that

greg.haskins (Fri, 03 Mar 2017 19:02:31 GMT):
but anyway, where I am going with this is: how do we reduce/eliminate human error/apathy going forward

greg.haskins (Fri, 03 Mar 2017 19:03:18 GMT):
I want to avoid the 125 patch mega-merge party that @muralisr and I had to untangle last time

greg.haskins (Fri, 03 Mar 2017 19:04:06 GMT):
one thought I had is minimally we could have a jenkins job that simply detects when merges are required and goes "red" until its fixed

greg.haskins (Fri, 03 Mar 2017 19:05:05 GMT):
at least we would detect it happening and could berate^h^h^h^h^hencourage the delinquent^h^h^h^h^h^h^hdev until they submitted a fix

greg.haskins (Fri, 03 Mar 2017 19:05:27 GMT):
other ideas would be some kind of automated merge process

greg.haskins (Fri, 03 Mar 2017 19:05:27 GMT):
other ideas would be some kind of automated merge process that only goes red if it cant automate the merge

greg.haskins (Fri, 03 Mar 2017 19:06:06 GMT):
im curious how LF has perhaps dealt with this in other projects @rjones @jwagantall

mastersingh24 (Fri, 03 Mar 2017 19:18:48 GMT):
I'm with ya @greg.haskins - and I also like the rules that some projects like Kafka have about deciding when to declare releases - e.g. when does v1.0.0-rc3 become v1.0.0 ;)

greg.haskins (Fri, 03 Mar 2017 19:19:23 GMT):
@mastersingh24 I am not sure how they do it, but I am very curious

greg.haskins (Fri, 03 Mar 2017 19:20:21 GMT):
if we had a really awesome UAT pipeline we could just release every time a merge ran the UAT gauntlet

greg.haskins (Fri, 03 Mar 2017 19:20:31 GMT):
but I think we have a bit of work to do to get there ;)

mastersingh24 (Fri, 03 Mar 2017 19:20:39 GMT):
they actually "vote"

mastersingh24 (Fri, 03 Mar 2017 19:20:59 GMT):
the maintainers that is on when to declare a major release

greg.haskins (Fri, 03 Mar 2017 19:21:34 GMT):
ah...we do have a degree of that, by virtue of maintainers voting on CRs and we use CRs to cut a release

greg.haskins (Fri, 03 Mar 2017 19:21:40 GMT):
but I suspect you are talking about something a bit different

mastersingh24 (Fri, 03 Mar 2017 19:43:40 GMT):
I guess we kinda have it to a degree

mastersingh24 (Fri, 03 Mar 2017 19:44:06 GMT):
but as you said, we do need to add some "maturity" around this

alexrosen (Fri, 03 Mar 2017 20:16:00 GMT):
Has joined the channel.

alexrosen (Fri, 03 Mar 2017 20:20:21 GMT):
I posted a proposal to create a Hyperledger Fabric Splash Page for the community. Please review. (https://wiki.hyperledger.org/community/proposals | https://docs.google.com/document/d/1lU37T90VvWAB2tK1Bvhj99IvfVm2MD8NJk96aqI5z64/edit#)

weeds (Fri, 03 Mar 2017 21:05:02 GMT):
@cbf are proposals supposed to be posted to the tsc channel? see above ^^

cbf (Fri, 03 Mar 2017 21:05:30 GMT):
no, that is just fabric

cbf (Fri, 03 Mar 2017 21:05:49 GMT):
and frankly it should just be a gerrit changeset to fabric repo

cbf (Fri, 03 Mar 2017 21:05:59 GMT):
we don't want to create a new repo unnecesarily

rrader (Sat, 04 Mar 2017 12:59:19 GMT):
Has joined the channel.

rrader (Sat, 04 Mar 2017 12:59:36 GMT):
Error creating connection to peer address https://github.com/IBM-Blockchain/fabric-images/issues/25

JonathanLevi (Sat, 04 Mar 2017 14:07:30 GMT):
"Internal" discussions amongst the maintainers of Hyperledger Fabric

JonathanLevi (Sat, 04 Mar 2017 14:09:37 GMT):
"Internal" discussions amongst the maintainers of Hyperledger Fabric. BTW: please use #fabric-pr-review for pull request's (PR) reviews

WeDoIoE (Tue, 07 Mar 2017 00:17:10 GMT):
Has joined the channel.

JonathanLevi (Wed, 08 Mar 2017 11:14:02 GMT):
All, please @ tag (me) next time the *master* branch is broken.

JonathanLevi (Wed, 08 Mar 2017 11:14:02 GMT):
All, please @ tag (me and others here) next time the *master* branch is broken/does not compile. It is important enough.

C0rWin (Wed, 08 Mar 2017 11:14:47 GMT):
well, one need to discover it's broken first

greg.haskins (Wed, 08 Mar 2017 13:25:42 GMT):
@JonathanLevi in theory, the -merge jobs do this for you automatically...its purely a function of whether someone notices that they are red

greg.haskins (Wed, 08 Mar 2017 13:26:04 GMT):
to that point, we could probably do a better job of notifications

JonathanLevi (Wed, 08 Mar 2017 14:33:02 GMT):
We should auto-revert breaking merges, IMO

greg.haskins (Wed, 08 Mar 2017 15:14:12 GMT):
at the very least, we should halt subsequent merges if they are not rebased against HEAD and work

greg.haskins (Wed, 08 Mar 2017 15:15:01 GMT):
but I like that idea @JonathanLevi...i wonder if gerrit can handle that

greg.haskins (Wed, 08 Mar 2017 15:15:13 GMT):
just bounce it back into an open status

greg.haskins (Wed, 08 Mar 2017 15:16:06 GMT):
it would all need to be done carefully however...for instance, what if other merges had gone in before the -merge job detects it

greg.haskins (Wed, 08 Mar 2017 15:17:40 GMT):
i think this could all be solved with perhaps another tier in the repo

greg.haskins (Wed, 08 Mar 2017 15:17:53 GMT):
today we have gerrit->gh

greg.haskins (Wed, 08 Mar 2017 15:18:15 GMT):
I wonder if this could be structured like gerrit-reviews -> gerrit-merges -> gh instead

greg.haskins (Wed, 08 Mar 2017 15:18:55 GMT):
IOW, hitting "submit" submits the patch to gerrit-reviews, but it still has to pass the -merge job to get merged to gerrit-merges

greg.haskins (Wed, 08 Mar 2017 15:19:07 GMT):
IOW, the second tier is another gate, but an automated one

greg.haskins (Wed, 08 Mar 2017 15:19:26 GMT):
it only needs a V+1 from Jenkins to pass

greg.haskins (Wed, 08 Mar 2017 15:19:58 GMT):
that automated layer could ensure that every patch has passed CI and was rebased to latest

greg.haskins (Wed, 08 Mar 2017 15:20:16 GMT):
(Today we cant say that with the one tier model...patches could be submitted against some really old SHA)

JonathanLevi (Wed, 08 Mar 2017 15:33:41 GMT):
This is what we usually do: [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=QLdfpThg4otJdryWJ) @greg.haskins

JonathanLevi (Wed, 08 Mar 2017 15:34:21 GMT):
We merge to a snapshot of HEAD, compile and run everything against that merged version...

JonathanLevi (Wed, 08 Mar 2017 15:34:39 GMT):
... and only after everything is OK, we merge "up".

JonathanLevi (Wed, 08 Mar 2017 15:35:14 GMT):
It's just a proposal, and probably not for the coming days/weeks... but it is something to keep in mind.

JonathanLevi (Wed, 08 Mar 2017 15:35:50 GMT):
The gerrit -> gh will follow that "up" merge.

JonathanLevi (Wed, 08 Mar 2017 15:36:43 GMT):
There are some cons to it, I know - e.g., that extra step may be time consuming, etc.

JonathanLevi (Wed, 08 Mar 2017 15:37:13 GMT):
BUT, it will force us to have a cleaner log (for example), than what we have now.

JonathanLevi (Wed, 08 Mar 2017 15:37:40 GMT):
---

JonathanLevi (Wed, 08 Mar 2017 15:38:06 GMT):
Not sure if you remember our discussion a few days prior to us cutting the v0.6 dev-preview "cut".

JonathanLevi (Wed, 08 Mar 2017 15:39:21 GMT):
About a *staging* branch, etc... where you some want to have (*the ability of an immediate deploy, using*) a master branch that is guaranteed to be clear at every single point in time.

JonathanLevi (Wed, 08 Mar 2017 15:40:03 GMT):
Again, it's all a matter of requirements/priorities, but I thought I'd drop that option here for a discussion/brainstorming.

greg.haskins (Wed, 08 Mar 2017 15:43:28 GMT):
I am fine if its branches vs repos, and in fact that makes more sense...but my only request be that it should be automated

Suma (Wed, 08 Mar 2017 15:43:40 GMT):
Has joined the channel.

greg.haskins (Wed, 08 Mar 2017 15:44:23 GMT):
i.e. I see human-approval (2+2) and V+1 as the first stage, but beyond that, it should be an automated process that can kick it back to the first level if it doesnt pass

JonathanLevi (Wed, 08 Mar 2017 15:55:18 GMT):
Yes, certainly automated. Auto-snapshotted, auto-tested, auto-upmerged or auto-auto-rejected ;-)

JonathanLevi (Wed, 08 Mar 2017 15:56:36 GMT):
We can discuss options. I'm trying to also be pragmatic (and not too academic), it's just that it really takes a long cycle for a build cycle... so when we "up merge" now, sometimes people do not wait (say, late at night) for the results.

JonathanLevi (Wed, 08 Mar 2017 15:56:36 GMT):
We can discuss options. I'm trying to also be pragmatic (and not too academic), it's just that it really takes a long time to complete a build cycle... so when we "up merge" now, sometimes people do not wait (say, late at night) for the results.

JonathanLevi (Wed, 08 Mar 2017 15:57:02 GMT):
Automated and super deterministic.

greg.haskins (Wed, 08 Mar 2017 17:32:23 GMT):
Yes, I agree. @yacovm what happened to that effort to parallelize the unit-tests?

greg.haskins (Wed, 08 Mar 2017 17:32:35 GMT):
IIRC, it showed promise (~20 minute runs IIRC)

yacovm (Wed, 08 Mar 2017 17:34:54 GMT):
well, I wanted to test it more thoroughly and then got swamped with gossip work. Do you want to continue from where I left?

yacovm (Wed, 08 Mar 2017 17:34:54 GMT):
well, I wanted to test it more thoroughly and then got swamped with gossip work. Do you want to continue from where I left? @greg.haskins

yacovm (Wed, 08 Mar 2017 17:34:54 GMT):
well, I wanted to test it more thoroughly and then got swamped with gossip work.

yacovm (Wed, 08 Mar 2017 17:35:24 GMT):
the commit is still there https://gerrit.hyperledger.org/r/#/c/5549/

yacovm (Wed, 08 Mar 2017 17:35:24 GMT):
the commit is still there https://gerrit.hyperledger.org/r/#/c/5549/ I got swamped by gossip work so couldn't complete it

greg.haskins (Wed, 08 Mar 2017 17:51:53 GMT):
@yacovm ty

troyronda (Wed, 08 Mar 2017 22:37:37 GMT):
cross-posted from #tsc: I am wondering about next steps for the [Go SDK proposal]

binhn (Thu, 09 Mar 2017 18:26:41 GMT):
The proposed alpha content is on the Hyperledger wiki https://wiki.hyperledger.org/projects/proposedv1alphacontent I'd like you to help review and discuss here. We also need to decide whether to branch or just tag the master branches of all related repos (sdk, ca, fabric). Branching would allow us to fix any serious bugs (if we want to), but otherwise, all testing and defect resolution will be on the master branch.

jimthematrix (Thu, 09 Mar 2017 18:28:46 GMT):
@mastersingh24 @yacovm @C0rWin @binhn I'm trying out the tls support in https://gerrit.hyperledger.org/r/#/c/7075 ```peer3 | 2017-03-09 18:10:14.200 UTC [msp] DeserializeIdentity -> INFO 00f Obtaining identity peer3 | 2017-03-09 18:10:14.200 UTC [msp] Validate -> INFO 010 MSP Org2MSP validating identity peer3 | panic: runtime error: invalid memory address or nil pointer dereference peer3 | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x932a7b] peer3 | peer3 | goroutine 1 [running]: peer3 | panic(0xc26f00, 0xc420014050) peer3 | /opt/go/src/runtime/panic.go:500 +0x1a1 peer3 | github.com/hyperledger/fabric/gossip/integration.newConfig(0xc420218db0, 0xf, 0x0, 0x0, 0xc4201d0be0, 0x1, 0x1, 0xc4202a38c0) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/integration/integration.go:43 +0x61b peer3 | github.com/hyperledger/fabric/gossip/integration.NewGossipComponent(0xc4201ba900, 0x300, 0x300, 0xc420218db0, 0xf, 0xc420088870, 0x12f1ca0, 0x133e720, 0x1300ba0, 0xc4201cfa40, ...) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/integration/integration.go:75 +0xa1 peer3 | github.com/hyperledger/fabric/gossip/service.InitGossipServiceCustomDeliveryFactory.func1() peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/service/gossip_service.go:138 +0x65f peer3 | sync.(*Once).Do(0x133e7d0, 0xc42018b680) peer3 | /opt/go/src/sync/once.go:44 +0xdb peer3 | github.com/hyperledger/fabric/gossip/service.InitGossipServiceCustomDeliveryFactory(0xc4201ba900, 0x300, 0x300, 0xc420218db0, 0xf, 0xc420088870, 0x12f1ba0, 0x133e720, 0x1300ba0, 0xc4201cfa40, ...) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/service/gossip_service.go:149 +0xb9 peer3 | github.com/hyperledger/fabric/gossip/service.InitGossipService(0xc4201ba900, 0x300, 0x300, 0xc420218db0, 0xf, 0xc420088870, 0x1300ba0, 0xc4201cfa40, 0xc4201d0be0, 0x1, ...) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/service/gossip_service.go:106 +0xd7 peer3 | github.com/hyperledger/fabric/peer/node.serve(0xc420235ab0, 0x0, 0x1, 0x0, 0x0) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:202 +0x633 peer3 | github.com/hyperledger/fabric/peer/node.glob..func1(0x12e8440, 0xc420235ab0, 0x0, 0x1, 0x0, 0x0) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:80 +0x3f peer3 | github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x12e8440, 0xc420235a90, 0x1, 0x1, 0x12e8440, 0xc420235a90) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234 peer3 | github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x12e8cc0, 0xf, 0xc420012055, 0x7) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367 peer3 | github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x12e8cc0, 0x57, 0xc420012055) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b peer3 | main.main() peer3 | /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 +0x52d ```

jimthematrix (Thu, 09 Mar 2017 18:28:46 GMT):
@mastersingh24 @yacovm @C0rWin @binhn I'm trying out the tls support in https://gerrit.hyperledger.org/r/#/c/7075 so i can build the sdk support, the peers are crashing like below: ```peer3 | 2017-03-09 18:10:14.200 UTC [msp] DeserializeIdentity -> INFO 00f Obtaining identity peer3 | 2017-03-09 18:10:14.200 UTC [msp] Validate -> INFO 010 MSP Org2MSP validating identity peer3 | panic: runtime error: invalid memory address or nil pointer dereference peer3 | [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x932a7b] peer3 | peer3 | goroutine 1 [running]: peer3 | panic(0xc26f00, 0xc420014050) peer3 | /opt/go/src/runtime/panic.go:500 +0x1a1 peer3 | github.com/hyperledger/fabric/gossip/integration.newConfig(0xc420218db0, 0xf, 0x0, 0x0, 0xc4201d0be0, 0x1, 0x1, 0xc4202a38c0) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/integration/integration.go:43 +0x61b peer3 | github.com/hyperledger/fabric/gossip/integration.NewGossipComponent(0xc4201ba900, 0x300, 0x300, 0xc420218db0, 0xf, 0xc420088870, 0x12f1ca0, 0x133e720, 0x1300ba0, 0xc4201cfa40, ...) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/integration/integration.go:75 +0xa1 peer3 | github.com/hyperledger/fabric/gossip/service.InitGossipServiceCustomDeliveryFactory.func1() peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/service/gossip_service.go:138 +0x65f peer3 | sync.(*Once).Do(0x133e7d0, 0xc42018b680) peer3 | /opt/go/src/sync/once.go:44 +0xdb peer3 | github.com/hyperledger/fabric/gossip/service.InitGossipServiceCustomDeliveryFactory(0xc4201ba900, 0x300, 0x300, 0xc420218db0, 0xf, 0xc420088870, 0x12f1ba0, 0x133e720, 0x1300ba0, 0xc4201cfa40, ...) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/service/gossip_service.go:149 +0xb9 peer3 | github.com/hyperledger/fabric/gossip/service.InitGossipService(0xc4201ba900, 0x300, 0x300, 0xc420218db0, 0xf, 0xc420088870, 0x1300ba0, 0xc4201cfa40, 0xc4201d0be0, 0x1, ...) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/gossip/service/gossip_service.go:106 +0xd7 peer3 | github.com/hyperledger/fabric/peer/node.serve(0xc420235ab0, 0x0, 0x1, 0x0, 0x0) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:202 +0x633 peer3 | github.com/hyperledger/fabric/peer/node.glob..func1(0x12e8440, 0xc420235ab0, 0x0, 0x1, 0x0, 0x0) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:80 +0x3f peer3 | github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x12e8440, 0xc420235a90, 0x1, 0x1, 0x12e8440, 0xc420235a90) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234 peer3 | github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x12e8cc0, 0xf, 0xc420012055, 0x7) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367 peer3 | github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x12e8cc0, 0x57, 0xc420012055) peer3 | /opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b peer3 | main.main() peer3 | /opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:111 +0x52d ```

jimthematrix (Thu, 09 Mar 2017 18:29:25 GMT):
this is how i configure each peer:

jimthematrix (Thu, 09 Mar 2017 18:29:41 GMT):
```peer0: container_name: peer0 image: hyperledger/fabric-peer environment: - CORE_PEER_ADDRESSAUTODETECT=true - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock - CORE_PEER_NETWORKID=peer0 - CORE_PEER_GOSSIP_ORGLEADER=true - CORE_NEXT=true - CORE_PEER_ENDORSER_ENABLED=true - CORE_PEER_ID=peer0 - CORE_PEER_PROFILE_ENABLED=true - CORE_PEER_LOCALMSPID=Org1MSP - CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/configtx/crypto-config/peerOrganizations/peerOrg1/peers/peerOrg1Peer1/ - CORE_PEER_TLS_ENABLED=true - CORE_PEER_TLS_KEY_FILE=/etc/hyperledger/tls-config/Org1-server1-key.pem - CORE_PEER_TLS_CERT_FILE=/etc/hyperledger/tls-config/Org1-server1-cert.pem - CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/tls-config/caroots/Org1-cert.pem working_dir: /opt/gopath/src/github.com/hyperledger/fabric command: peer node start --peer-defaultchain=false ports: - 7051:7051 - 7053:7053 volumes: - /var/run/:/host/var/run/ - ./:/etc/hyperledger/configtx - ../config/tls:/etc/hyperledger/tls-config depends_on: - orderer```

binhn (Thu, 09 Mar 2017 18:44:31 GMT):
@jimthematrix thanks -- looking

yacovm (Thu, 09 Mar 2017 18:44:31 GMT):
Jim i'm not at home but maybe the tls cert wasnt loaded correctly?

C0rWin (Thu, 09 Mar 2017 18:53:40 GMT):
Yeah, it comes down to the line where it tries to load the certificate ``` *cert, err = tls.LoadX509KeyPair(viper.GetString("peer.tls.cert.file"), viper.GetString("peer.tls.key.file"))```

C0rWin (Thu, 09 Mar 2017 18:53:40 GMT):
Yeah, it comes down to the line where it tries to load the certificate:

C0rWin (Thu, 09 Mar 2017 18:53:51 GMT):
``` *cert, err = tls.LoadX509KeyPair(viper.GetString("peer.tls.cert.file"), viper.GetString("peer.tls.key.file"))```

C0rWin (Thu, 09 Mar 2017 18:54:08 GMT):
wondering what is the value for ```"peer.tls.cert.file"```

C0rWin (Thu, 09 Mar 2017 18:54:08 GMT):
wondering what is the value for `"peer.tls.cert.file"`

C0rWin (Thu, 09 Mar 2017 18:54:08 GMT):
wondering what is the value for `"peer.tls.cert.file"`?

jimthematrix (Thu, 09 Mar 2017 18:54:54 GMT):
it's PEM encoded cert, like below: ```-----BEGIN CERTIFICATE----- MIIB/DCCAaGgAwIBAgIRANHBGVHQ24Z7DyTeCJy0hkAwCgYIKoZIzj0EAwIwWDEL MAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG cmFuY2lzY28xDTALBgNVBAoTBE9yZzExDTALBgNVBAMTBE9yZzEwHhcNMTcwMzA5 MTIxODQwWhcNMjcwMzA3MTIxODQwWjBlMQswCQYDVQQGEwJVUzETMBEGA1UECBMK Q2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEVMBMGA1UEChMMT3Jn MS1zZXJ2ZXIxMRIwEAYDVQQDEwlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjO PQMBBwNCAAQK2y+RWueR/DA1azaTAOCWg2V5OQvaV/Z5w5eM0pnxFNigvL2M2587 K9TyIko/q/FSugFcRlpwqluOfRNrS/pgoz8wPTAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAwCgYIKoZI zj0EAwIDSQAwRgIhAOCcZX387r7wcIhGjugCa30FLfNt+JuzVmI1u6mQlyAhAiEA hHaqckAlaGrf2RZ22JfuruIeBFspvynLo/R8wnWUgTU= -----END CERTIFICATE----- ```

C0rWin (Thu, 09 Mar 2017 18:55:16 GMT):
@jimthematrix thanks, will try it out

jimthematrix (Thu, 09 Mar 2017 18:55:30 GMT):
ok

jimthematrix (Thu, 09 Mar 2017 18:55:58 GMT):
and here's the corresponding private key: ```-----BEGIN EC PRIVATE KEY----- MHcCAQEEIFs7jdTFvAvefiEmo/l12AxECeajntSHWIEBWITL4TbloAoGCCqGSM49 AwEHoUQDQgAECtsvkVrnkfwwNWs2kwDgloNleTkL2lf2ecOXjNKZ8RTYoLy9jNuf OyvU8iJKP6vxUroBXEZacKpbjn0Ta0v6YA== -----END EC PRIVATE KEY----- ```

binhn (Thu, 09 Mar 2017 18:57:27 GMT):
@C0rWin we should insert more debug log before the panic

C0rWin (Thu, 09 Mar 2017 19:07:32 GMT):
@binhn sure.

C0rWin (Thu, 09 Mar 2017 19:07:43 GMT):
@jimthematrix going to take a look on this

C0rWin (Thu, 09 Mar 2017 19:31:26 GMT):
@jimthematrix @binh, here is the fix https://gerrit.hyperledger.org/r/#/c/7083/ for above problem

C0rWin (Thu, 09 Mar 2017 19:31:26 GMT):
@jimthematrix @binh , here is the fix https://gerrit.hyperledger.org/r/#/c/7083/ for above problem

C0rWin (Thu, 09 Mar 2017 19:31:26 GMT):
@jimthematrix @binhn , here is the fix https://gerrit.hyperledger.org/r/#/c/7083/ for above problem

JonathanLevi (Thu, 09 Mar 2017 20:06:15 GMT):
Can we add a test for it?

JonathanLevi (Thu, 09 Mar 2017 20:06:30 GMT):
(I'll merge the fix for the NPE, of course)

jimthematrix (Thu, 09 Mar 2017 20:09:00 GMT):
@C0rWin great, let me give it a try

JonathanLevi (Thu, 09 Mar 2017 20:51:18 GMT):
@C0rWin: Merged.

smithbk (Thu, 09 Mar 2017 23:17:18 GMT):
The following fabric-ca change sets still need review. Thanks

smithbk (Thu, 09 Mar 2017 23:17:20 GMT):
1) https://gerrit.hyperledger.org/r/6921 2) https://gerrit.hyperledger.org/r/6943

kuangchao (Fri, 10 Mar 2017 02:38:28 GMT):
Has joined the channel.

hgabre (Fri, 10 Mar 2017 10:14:10 GMT):
@smithbk I added 1 little comment to the first

hgabre (Fri, 10 Mar 2017 10:14:13 GMT):
but generally OK

JonathanLevi (Fri, 10 Mar 2017 10:56:32 GMT):
@smithbk: please use the #fabric-pr-review channel... and stop reviewing your own CRs.

JonathanLevi (Fri, 10 Mar 2017 10:59:38 GMT):
@smithbk: Sorry to be repeating myself, repeatedly: please use the #fabric-pr-review channel for PRs... and stop reviewing CRs that have your own code/you are an author of.

binhn (Fri, 10 Mar 2017 13:33:49 GMT):
re `We also need to decide whether to branch or just tag the master branches of all related repos (sdk, ca, fabric). Branching would allow us to fix any serious bugs (if we want to), but otherwise, all testing and defect resolution will be on the master branch.` I saw some discussion between @greg.haskins and @mastersingh24 seem to prefer tag on master rather than branch. I am fine with that and certainly less work for developers, who might have to submit a CR in 2 branches instead of 1. Any thoughts from others?

yacovm (Fri, 10 Mar 2017 13:49:27 GMT):
I think tagging is best idea in light of previous events (that convergence branch)

jimthematrix (Fri, 10 Mar 2017 15:41:26 GMT):
trying to add node sdk support for tls, getting the following error when talking to the peers: ```E0310 10:06:24.292485000 123145329672192 ssl_transport_security.c:947] Handshake failed with fatal error SSL_ERROR_SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure.```

jimthematrix (Fri, 10 Mar 2017 15:42:57 GMT):
does anybody know what the error is saying? I couldn't find a way to turn on the handshake trace (grpc_trace=true doesn't give you that)

yacovm (Fri, 10 Mar 2017 15:43:08 GMT):
Can the peers do TLS v3?

jimthematrix (Fri, 10 Mar 2017 15:43:28 GMT):
that's what i'm wondering, why are they talking in sslv3 at all?

yacovm (Fri, 10 Mar 2017 15:43:53 GMT):
no idea, but I'd check if our *old* vendor folder even has TLS 1.3

yacovm (Fri, 10 Mar 2017 15:44:08 GMT):
but I guess that TLS 1.3 client should support a 1.2 server

JatinderBali (Fri, 10 Mar 2017 15:44:44 GMT):
Has joined the channel.

jimthematrix (Fri, 10 Mar 2017 16:58:18 GMT):
note that the above error is from trying to connect to the event stream, @binhn @muralisr @mastersingh24 @jeffgarratt has that (event producer) been tested with TLS?

jeffgarratt (Fri, 10 Mar 2017 16:58:50 GMT):
@jiu

jeffgarratt (Fri, 10 Mar 2017 16:58:50 GMT):
@jimthematrix I have not yet connected events

jeffgarratt (Fri, 10 Mar 2017 16:59:08 GMT):
in behave

muralisr (Fri, 10 Mar 2017 17:03:43 GMT):
@jimthematrix the events grpc uses the same TLS setup as peer

muralisr (Fri, 10 Mar 2017 17:03:57 GMT):
but no, has not been tested

muralisr (Fri, 10 Mar 2017 17:04:24 GMT):
but if the connection to the peer worked, I'd expect the same setup to work for events too....

muralisr (Fri, 10 Mar 2017 17:04:57 GMT):
will try as soon as I can ...

jimthematrix (Fri, 10 Mar 2017 17:13:54 GMT):
ok cool, that's what I'd expected, just double checking, I'll continue to dig into the client code about that...

rickr (Fri, 10 Mar 2017 17:22:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=79uvmiBoeQLmBo36h) @binhn I think you always can create a branch from a tag if you decided later you want to provided fixes

JonathanLevi (Fri, 10 Mar 2017 18:04:26 GMT):
I think we should tag what we release, yes. (as in "a pointer in time").

JonathanLevi (Fri, 10 Mar 2017 18:04:58 GMT):
We many end up though, with needing to create branches in the future.

JonathanLevi (Fri, 10 Mar 2017 18:04:58 GMT):
We many end up, though, needing to create branches in the future.

JonathanLevi (Fri, 10 Mar 2017 18:06:04 GMT):
In this point in time, we were all trying to avoid working with too many versions on the code in parallel, which is why we push so much work into *master*...

JonathanLevi (Fri, 10 Mar 2017 18:06:04 GMT):
At this point in time, we were all trying to avoid working with too many versions on the code in parallel, which is why we push so much work into *master*...

JonathanLevi (Fri, 10 Mar 2017 18:06:36 GMT):
But say once people deploy v1.0 and then we will have a v1.2 that has some new features/API changes, etc.

JonathanLevi (Fri, 10 Mar 2017 18:06:36 GMT):
But say once people deploy v1.0 and then we will have a v1.2 (branch/version in development) that has some new features/API changes, etc.

JonathanLevi (Fri, 10 Mar 2017 18:07:13 GMT):
Then we need to patch/fix/update v1.0 to (heaven forbid! :) v1.0.1, v1.0.2 or so...

JonathanLevi (Fri, 10 Mar 2017 18:07:13 GMT):
Then, for example, should we need to patch/fix/update v1.0 and call/version it as (heaven forbid! :) v1.0.1, v1.0.2 or so...

JonathanLevi (Fri, 10 Mar 2017 18:07:13 GMT):
Then, for example, should we need to patch/fix/update v1.0 and call/version/mark these as [heaven forbid! :)] `v1.0.1`, `v1.0.2` or so...

JonathanLevi (Fri, 10 Mar 2017 18:08:06 GMT):
... these patches/updates/bug-fixes/improvements, may not be relevant on that v1.2 code base (which is where I envision us branching).

JonathanLevi (Fri, 10 Mar 2017 18:08:06 GMT):
... these patches/updates/bug-fixes/improvements, may not be relevant to that v1.2 code-base (which is where I envision us branching).

JonathanLevi (Fri, 10 Mar 2017 18:08:07 GMT):
---

JonathanLevi (Fri, 10 Mar 2017 18:09:01 GMT):
Long story short `+2 for me for tagging` (v1.0-alpha, and subsequent related versions), at least until the next formal `release`.

JonathanLevi (Fri, 10 Mar 2017 18:09:01 GMT):
Long story short `+2 for me for tagging` (v1.0-alpha, and subsequent related versions), at least until the/our next formal `release`.

JonathanLevi (Fri, 10 Mar 2017 18:09:01 GMT):
Long story short, I agree with @binhn: `+2 for me for tagging` (v1.0-alpha, and subsequent related versions), at least until the/our next formal `release`.

jimthematrix (Fri, 10 Mar 2017 18:13:58 GMT):
@muralisr @jeffgarratt @binhn are you guys testing orderer with tls enabled? i didn't think that's enabled yet right? (pretty evident from orderer/main.go: line 73-77)

jimthematrix (Fri, 10 Mar 2017 18:14:47 GMT):
however when orderer is not TLS enabled, getting this error in the peer logs: ```peer0 | 2017-03-10 17:55:47.446 UTC [deliveryClient] NewDeliverService -> ERRO 031 Cannot dial to orderer:7050, because of grpc: transport credentials are set for an insecure connection (grpc.WithTransportCredentials() and grpc.WithInsecure() are both called)```

yacovm (Fri, 10 Mar 2017 18:17:15 GMT):
ah that's a easy to fix @jimthematrix

yacovm (Fri, 10 Mar 2017 18:17:37 GMT):
https://github.com/hyperledger/fabric/blob/master/core/deliverservice/deliveryclient.go#L112

yacovm (Fri, 10 Mar 2017 18:17:56 GMT):
Just remove the `grpc.WithInsecure()`

muralisr (Fri, 10 Mar 2017 18:19:48 GMT):
also it is interesting that we do this

muralisr (Fri, 10 Mar 2017 18:19:59 GMT):
``` if comm.TLSEnabled() { dialOpts = append(dialOpts, grpc.WithTransportCredentials(comm.InitTLSForPeer())) } else { dialOpts = append(dialOpts, grpc.WithInsecure()) } ```

jimthematrix (Fri, 10 Mar 2017 18:21:00 GMT):
is this logic correct though?

muralisr (Fri, 10 Mar 2017 18:21:14 GMT):
ie, basically says "orderer is enabled for peer if and only if peer is enabled for TLS"

jimthematrix (Fri, 10 Mar 2017 18:21:15 GMT):
comm.TLSEnabled() is for the peer server

jimthematrix (Fri, 10 Mar 2017 18:21:25 GMT):
but this is the client to the ordering service

yacovm (Fri, 10 Mar 2017 18:21:41 GMT):
yeah it could be more fine grained I agree

yacovm (Fri, 10 Mar 2017 18:21:47 GMT):
but that will fix your bug, no?

jimthematrix (Fri, 10 Mar 2017 18:22:07 GMT):
i don't think it'll fix my bug

JonathanLevi (Fri, 10 Mar 2017 18:22:13 GMT):
:-)

jimthematrix (Fri, 10 Mar 2017 18:22:22 GMT):
comm.TLSEnabled() will always return true

jimthematrix (Fri, 10 Mar 2017 18:22:28 GMT):
on the peer that has tls enabled

jimthematrix (Fri, 10 Mar 2017 18:22:38 GMT):
so it can't talk to the ordering service

jimthematrix (Fri, 10 Mar 2017 18:23:26 GMT):
actually

yacovm (Fri, 10 Mar 2017 18:23:28 GMT):
the problem, as I see is that you try to use a gRPC connection with transport credentials, but that slice has already `withInsecure`

jimthematrix (Fri, 10 Mar 2017 18:23:34 GMT):
i think you meant to remove it from the line above

yacovm (Fri, 10 Mar 2017 18:23:37 GMT):
so it's a contradiction

yacovm (Fri, 10 Mar 2017 18:23:40 GMT):
yeah that's what I said

jimthematrix (Fri, 10 Mar 2017 18:23:55 GMT):
``` dialOpts := []grpc.DialOption{grpc.WithInsecure(), grpc.WithTimeout(3 * time.Second), grpc.WithBlock()} ```

yacovm (Fri, 10 Mar 2017 18:24:00 GMT):
yep

jimthematrix (Fri, 10 Mar 2017 18:24:02 GMT):
ok that makes sense

yacovm (Fri, 10 Mar 2017 18:24:46 GMT):
You can try it: https://gerrit.hyperledger.org/r/#/c/7123/

yacovm (Fri, 10 Mar 2017 18:25:18 GMT):
if that works I'll add a test when I get back (gotta go)

jimthematrix (Fri, 10 Mar 2017 18:31:07 GMT):
so there's still a fundamental logic problem, as mentioned above, `comm.TLSEnabled()` doesn't tell you if the orderer is tls enabled

jimthematrix (Fri, 10 Mar 2017 18:31:17 GMT):
so the dial options are still wrong

yacovm (Fri, 10 Mar 2017 18:32:37 GMT):
The idea (i believe was that if the peer uses tls so does the orderer)

yacovm (Fri, 10 Mar 2017 18:32:37 GMT):
The idea (i believe was) that if the peer uses tls so does the orderer

jimthematrix (Fri, 10 Mar 2017 18:35:46 GMT):
i think that's reasonable but it also means we need to enable tls on the orderer at the same time

jimthematrix (Fri, 10 Mar 2017 18:36:03 GMT):
let me try that

jimthematrix (Fri, 10 Mar 2017 18:37:29 GMT):
i don't think it'll work though: orderer/main.go: 73-77 ``` // Create GRPC server - return if an error occurs secureConfig := comm.SecureServerConfig{ UseTLS: conf.General.TLS.Enabled, } grpcServer, err := comm.NewGRPCServerFromListener(lis, secureConfig) ```

jimthematrix (Fri, 10 Mar 2017 18:37:50 GMT):
it crashes complaining that the server key and certs are missing

jimthematrix (Fri, 10 Mar 2017 18:52:54 GMT):
@binhn @yacovm @mastersingh24 @muralisr we need to decide what to do for the alpha

jimthematrix (Fri, 10 Mar 2017 18:53:23 GMT):
my suggestion is something like this: ```--- a/core/deliverservice/deliveryclient.go +++ b/core/deliverservice/deliveryclient.go @@ -106,9 +106,9 @@ func NewDeliverService(gossip blocksprovider.GossipServiceAdapter, endpoints []s for _, idx := range indices { logger.Infof("Creating delivery service to get blocks from the ordering service, %s", endpoints[idx]) - dialOpts := []grpc.DialOption{grpc.WithInsecure(), grpc.WithTimeout(3 * time.Second), grpc.WithBlock()} + dialOpts := []grpc.DialOption{grpc.WithTimeout(3 * time.Second), grpc.WithBlock()} - if comm.TLSEnabled() { + if false { dialOpts = append(dialOpts, grpc.WithTransportCredentials(comm.InitTLSForPeer())) } else { dialOpts = append(dialOpts, grpc.WithInsecure()) ```

jimthematrix (Fri, 10 Mar 2017 18:53:43 GMT):
to get around the issue for now

jimthematrix (Fri, 10 Mar 2017 18:54:20 GMT):
aka 1) keep orderer tls-disabled 2) deliver service always assume the orderer is not tls enabled

jimthematrix (Fri, 10 Mar 2017 18:54:59 GMT):
unless @jyellick thinks the orderer can be tls enabled in the next couple of hours (and tested)

kostas (Fri, 10 Mar 2017 18:56:55 GMT):
May I ask what is the issue with enabling TLS on the orderer?

jyellick (Fri, 10 Mar 2017 18:57:26 GMT):
@jimthematrix The orderer is using all the same code as the peer for TLS ( @mastersingh24 's TLS server), I see you describe a crash, but that seems to me like misconfiguration, that it cannot find the TLS certs

kostas (Fri, 10 Mar 2017 18:59:11 GMT):
(@jimthematrix: This is your config file for the orderer. https://github.com/hyperledger/fabric/blob/master/orderer/orderer.yaml#L26)

jimthematrix (Fri, 10 Mar 2017 19:03:25 GMT):
@kostas @jyellick i used the orderer.yaml as reference to add env variables to the docker compose

jimthematrix (Fri, 10 Mar 2017 19:03:55 GMT):
but i think the grpcserver code that Gari added used different var paths (thus the crash)

jimthematrix (Fri, 10 Mar 2017 19:04:05 GMT):
will investigate a bit more again

muralisr (Fri, 10 Mar 2017 19:04:14 GMT):
there are two issues ...(1) we can have TLS enabled for both or for neither ... other two combinations are not possible. (comm.TLSEnabled() basically says its enabled for both) and (2) need to use comm.NewClientConnectionWithAddress instead of dial directly

jyellick (Fri, 10 Mar 2017 19:06:02 GMT):
@jimthematrix Could you outline how you are trying to test? I would be happy to try to reproduce and help debug

jimthematrix (Fri, 10 Mar 2017 19:07:25 GMT):
``` - ORDERER_GENERAL_TLS_ENABLED=true - ORDERER_GENERAL_TLS_PRIVATEKEY=/etc/hyperledger/tls-config/Org1-server1-key.pem - ORDERER_GENERAL_TLS_CERTIFICATE=/etc/hyperledger/tls-config/Org1-server1-cert.pem - ORDERER_GENERAL_TLS_ROOTCAs=/etc/hyperledger/tls-config/caroots.pem ```

jyellick (Fri, 10 Mar 2017 19:07:56 GMT):
Is this the orderer docker image? What commit are you trying this as?

jyellick (Fri, 10 Mar 2017 19:07:56 GMT):
Is this the orderer docker image? What commit are you trying this at?

jimthematrix (Fri, 10 Mar 2017 19:09:17 GMT):
I think I pulled last night

jimthematrix (Fri, 10 Mar 2017 19:10:42 GMT):
key and cert are from the core/comm/testdata folder, caroots.pem is Org1-cert and Or2-cert concatenated

jimthematrix (Fri, 10 Mar 2017 19:11:58 GMT):
if I used these env var names instead then the orderer doesn't crash: ``` - ORDERER_PEER_TLS_ENABLED=true - ORDERER_PEER_TLS_KEY_FILE=/etc/hyperledger/tls-config/Org1-server1-key.pem - ORDERER_PEER_TLS_CERT_FILE=/etc/hyperledger/tls-config/Org1-server1-cert.pem - ORDERER_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/tls-config/caroots/Org1-cert.pem ```

jimthematrix (Fri, 10 Mar 2017 19:12:24 GMT):
again due to Gari's code using a different var hierarchy than what's described in orderer.yaml

jyellick (Fri, 10 Mar 2017 19:15:16 GMT):
Ah, I see now, let me see if I can put a quick fix together

jyellick (Fri, 10 Mar 2017 19:55:44 GMT):
@jimthematrix I did a very quick hack to appropriately set the `SecureServerConfig` stuff, but @sanchezl is the one who implemented the yaml decode hooks for the cert stuff, so I am passing it off to him to test.

jyellick (Fri, 10 Mar 2017 19:56:33 GMT):
The yaml hooks he wrote are actually pretty neat because it allows us to specify cert literals or file paths, and the config gets populated in the right way in both cases without two code paths.

jimthematrix (Fri, 10 Mar 2017 20:00:02 GMT):
sounds good. i've got local hacks so i'm not blocked, but battled with this error when submitting from node sdk: ```Handshake failed with fatal error SSL_ERROR_SSL: error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number```

jimthematrix (Fri, 10 Mar 2017 20:00:42 GMT):
i'm pretty sure i'm forcing tls v1.2 on both sides but still can't get past this when contacting the orderer

muralisr (Fri, 10 Mar 2017 20:01:18 GMT):
(as an aside, @jimthematrix are you having issue with events client as well ?)

jyellick (Fri, 10 Mar 2017 20:02:21 GMT):
http://gerrit.hyperledger.org/r/7129 <- this is the hack to get it working, @sanchezl will verify the fix, and post correct parameters here

binhn (Fri, 10 Mar 2017 20:45:57 GMT):
@jimthematrix i saw in @muralisr 's test, he sets this on peer CORE_PEER_PKI_TLS_SERVERHOSTOVERRIDE=dummy, but i don't see that variable on orderer.yaml

jyellick (Fri, 10 Mar 2017 20:47:55 GMT):
It seems that through some interaction, the peer config parsing is being triggered when running the orderer, that is why the other overrides are working.

muralisr (Fri, 10 Mar 2017 21:15:02 GMT):
@jyellick will try as well, do I need to a patch on orderer to test ?

jyellick (Fri, 10 Mar 2017 21:16:08 GMT):
7129 above fixes the variable conventions, though it can apparently can be hacked around with the peer vars according to @jimthematrix

muralisr (Fri, 10 Mar 2017 21:20:19 GMT):
ok

muralisr (Fri, 10 Mar 2017 21:20:32 GMT):
let me try

jyellick (Fri, 10 Mar 2017 21:23:24 GMT):
@muralisr Do keep in mind, to reference a file for those orderer vars, you must use a sub-tag `file`, @sanchezl should hopefully have a working configuration he can post here shortly

muralisr (Fri, 10 Mar 2017 21:24:25 GMT):
thanks Jason.. will do the needful

binhn (Fri, 10 Mar 2017 21:52:58 GMT):
2 CR's to cherrypick and test TLS: https://gerrit.hyperledger.org/r/#/c/7127/ and https://gerrit.hyperledger.org/r/#/c/7133/ (note the flag in core.yaml `skipHandshake: true`

sanchezl (Fri, 10 Mar 2017 23:00:12 GMT):
@jimthematrix , @jyellick , @muralisr The latest patch set for change http://gerrit.hyperledger.org/r/7129 should ensure that the TLS configuration get read when appending `_FILE` to the environment variables in order to read the values from a file. e.g.: ``` ORDERER_GENERAL_TLS_PRIVATEKEY_FILE=/etc/hyperledger/tls-config/Org1-server1-key.pem ORDERER_GENERAL_TLS_CERTIFICATE_FILE=/etc/hyperledger/tls-config/Org1-server1-cert.pem ORDERER_GENERAL_TLS_ROOTCAS_FILE=/etc/hyperledger/tls-config/caroots.pem etc... ```

sanchezl (Fri, 10 Mar 2017 23:00:12 GMT):
@jimthematrix , @jyellick , @muralisr The latest patch set for change http://gerrit.hyperledger.org/r/7129 should ensure that the TLS configuration is read when appending `_FILE` to the environment variables in order to read the values from a file. e.g.: ``` ORDERER_GENERAL_TLS_PRIVATEKEY_FILE=/etc/hyperledger/tls-config/Org1-server1-key.pem ORDERER_GENERAL_TLS_CERTIFICATE_FILE=/etc/hyperledger/tls-config/Org1-server1-cert.pem ORDERER_GENERAL_TLS_ROOTCAS_FILE=/etc/hyperledger/tls-config/caroots.pem etc... ```

mychewcents (Wed, 15 Mar 2017 12:29:26 GMT):
Has joined the channel.

JonathanLevi (Wed, 15 Mar 2017 17:00:05 GMT):
---

JonathanLevi (Wed, 15 Mar 2017 17:00:12 GMT):
Shall we announce a CODE FREEZE widely?

binhn (Wed, 15 Mar 2017 17:40:43 GMT):
@greg.haskins waiting for 2 more small Cr's to go through then we tackle https://jira.hyperledger.org/browse/FAB-2764

binhn (Wed, 15 Mar 2017 17:41:35 GMT):
we were talking about tagging the master or branching, whichever is fine

binhn (Wed, 15 Mar 2017 19:01:26 GMT):
question on tagging a new release: 1) the first CR changes the makefile to `BASE_VERSION = 1.0-alpha` and `IS_RELEASE = true` 2) the second CR changes the makefile to `BASE_VERSION = 1.0` and `IS_RELEASE = false` is that correct?

greg.haskins (Wed, 15 Mar 2017 19:04:20 GMT):
@binhn off the phone...correct

greg.haskins (Wed, 15 Mar 2017 19:04:46 GMT):
the first component is the release commits, as you have indicated above

greg.haskins (Wed, 15 Mar 2017 19:05:15 GMT):
they should go back to back (i.e.merged together) so that there are no gaps where mulltiple commits have IS_RELEASE=true

greg.haskins (Wed, 15 Mar 2017 19:05:26 GMT):
(e.g. if you merged the first and then a week later merged the second)

greg.haskins (Wed, 15 Mar 2017 19:06:16 GMT):
the second aspect is, once these CRs are merged, I can push a tag against the commit-id of the IS_RELEASE=true...this tag will of course tag it in gerrit/gh, but it also serves to kick jenkins to build/push the release out to dockerhub

greg.haskins (Wed, 15 Mar 2017 19:06:34 GMT):
the last component is deciding if a branch is needed

greg.haskins (Wed, 15 Mar 2017 19:07:21 GMT):
iff we want to create a one-off (meaning there is not likely to be a follow up release based on the first), we can opt to simply do this against HEAD without a branch

greg.haskins (Wed, 15 Mar 2017 19:08:01 GMT):
BUT, if future patches are anticipated, OR if the tag is against something in the past (i.e. not HEAD), we should also create a branch point from the IS_RELEASE CR

greg.haskins (Wed, 15 Mar 2017 19:08:11 GMT):
that above sums it up

greg.haskins (Wed, 15 Mar 2017 19:08:11 GMT):
that about sums it up

binhn (Wed, 15 Mar 2017 19:08:29 GMT):
@greg.haskins thanks -- creating them now The label of the first CR is "Release 1.0-alpha"

greg.haskins (Wed, 15 Mar 2017 19:09:11 GMT):
cool...usually I name the second one "preparing for XX release" where "XX" is whatever would make a best guess to the next release ID

binhn (Wed, 15 Mar 2017 19:09:13 GMT):
i think we can create a branch later if we need to patch, right?

greg.haskins (Wed, 15 Mar 2017 19:09:27 GMT):
yes, we can branch off the release CR at any time

binhn (Wed, 15 Mar 2017 19:09:42 GMT):
ok, let's do that then

greg.haskins (Wed, 15 Mar 2017 19:09:44 GMT):
the only time you should really create a branch first is if you want to release a past CR

greg.haskins (Wed, 15 Mar 2017 19:09:59 GMT):
sorry, the only time you are _forced_ to create a branch first

binhn (Wed, 15 Mar 2017 19:10:30 GMT):
ok

greg.haskins (Wed, 15 Mar 2017 19:11:42 GMT):
do you anticipate this is the one/only alpha release?

greg.haskins (Wed, 15 Mar 2017 19:12:01 GMT):
if not, I suggest a sub version id, like "1.0-alpha-1"

binhn (Wed, 15 Mar 2017 19:13:48 GMT):
yes, it'll be the only alpha release

greg.haskins (Wed, 15 Mar 2017 19:18:20 GMT):
i like your confidence ;)

binhn (Wed, 15 Mar 2017 19:33:16 GMT):
:fingers_crossed:

binhn (Wed, 15 Mar 2017 20:23:54 GMT):
Please approve these CR's tagging for alpha release: release 1.0-alpha https://gerrit.hyperledger.org/r/#/c/7241/ release 1.0 https://gerrit.hyperledger.org/r/#/c/7243/

binhn (Wed, 15 Mar 2017 20:24:38 GMT):
@greg.haskins @mastersingh24 @muralisr @JonathanLevi

mastersingh24 (Wed, 15 Mar 2017 20:59:09 GMT):
@binhn - can we use 3 digit version - 1.0.0-alpha and 1.0.0?

binhn (Wed, 15 Mar 2017 21:02:27 GMT):
sure, let me push a patch

mastersingh24 (Wed, 15 Mar 2017 21:02:31 GMT):
thx

binhn (Wed, 15 Mar 2017 21:09:53 GMT):
@mastersingh24 done

binhn (Wed, 15 Mar 2017 21:11:04 GMT):
@greg.haskins we don't have the same procedure for other fabric repos, like fabric-ca and fabric-sdk, so i think we should just manually tag them with 1.0.0-alpha, right?

mastersingh24 (Wed, 15 Mar 2017 21:12:57 GMT):
+2'd

binhn (Wed, 15 Mar 2017 21:53:09 GMT):
i don't seem to have authority to create tags on other repos. someone can help tag fabric-ca and fabric-skd-node with "1.0.0-alpha"

greg.haskins (Wed, 15 Mar 2017 22:08:44 GMT):
@binhn we cant/shouldnt tag until the CR is merged

greg.haskins (Wed, 15 Mar 2017 22:08:54 GMT):
what are you trying to tag?

greg.haskins (Wed, 15 Mar 2017 22:10:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=hAnoJJ8aLTnXJWocX) @binhn at least fabric-ca has the same mechanism

greg.haskins (Wed, 15 Mar 2017 22:10:35 GMT):
i think for sdk, we should follow the same basic practice but I think the version number would be configured in the package.json rather than a makefile

greg.haskins (Wed, 15 Mar 2017 22:11:53 GMT):
to summarize: both fabric and fabric-ca should use the "two CRs against IS_RELEASE in the Makefile approach"

greg.haskins (Wed, 15 Mar 2017 22:12:21 GMT):
sdk should also have a two CR process, but the difference is it would be against updating the version number in package.json(s)

greg.haskins (Wed, 15 Mar 2017 22:15:27 GMT):
@binhn we should confirm with @jimthematrix but I think the SDK process needs two files updated

greg.haskins (Wed, 15 Mar 2017 22:15:29 GMT):
https://github.com/hyperledger/fabric-sdk-node/blob/3afcb0aee1826f21c000f5226e74ef309f73be73/fabric-client/package.json#L3

greg.haskins (Wed, 15 Mar 2017 22:15:49 GMT):
https://github.com/hyperledger/fabric-sdk-node/blob/3afcb0aee1826f21c000f5226e74ef309f73be73/fabric-ca-client/package.json#L3

greg.haskins (Wed, 15 Mar 2017 22:16:20 GMT):
those should be changed to "1.0.0-alpha" in the first CR, and then something like "1.0.0-snapshot" in the second

greg.haskins (Wed, 15 Mar 2017 22:16:54 GMT):
(there is no "IS_RELEASE" analogy in the sdk build, so the snapshot tag needs to be explicit)

dave.enyeart (Wed, 15 Mar 2017 22:19:41 GMT):
@mastersingh24 @greg.haskins @binhn we haven't declared an alpha yet have we?

dave.enyeart (Wed, 15 Mar 2017 22:19:53 GMT):
we just found that the instructions don't account for the recent TLS changes

greg.haskins (Wed, 15 Mar 2017 22:20:17 GMT):
@dave.enyeart apparently, though I wasnt involved in the decision, I am just assisting in the process

dave.enyeart (Wed, 15 Mar 2017 22:20:44 GMT):
apparently we declared an alpha? or not yet?

greg.haskins (Wed, 15 Mar 2017 22:20:53 GMT):
apparently we declared one

greg.haskins (Wed, 15 Mar 2017 22:21:09 GMT):
https://gerrit.hyperledger.org/r/#/c/7241/

greg.haskins (Wed, 15 Mar 2017 22:21:22 GMT):
thats the proposed fabric release, I think fabric-ca and sdk are still pending

JonathanLevi (Wed, 15 Mar 2017 22:24:21 GMT):
Shall we update the title?

mastersingh24 (Wed, 15 Mar 2017 22:44:58 GMT):
I'm not so worried about being able to make doc updates - I feel those are going to be a work in progress anyway over the next couple of weeks as people actually start using the images

greg.haskins (Wed, 15 Mar 2017 22:51:02 GMT):
I think doc updates post release is fine too

JonathanLevi (Wed, 15 Mar 2017 22:51:46 GMT):
I agree. I think we are also good with `fabric-ca`

JonathanLevi (Wed, 15 Mar 2017 22:52:25 GMT):
(In the meantime, I have asked around, just in case - but things look good)

jimthematrix (Thu, 16 Mar 2017 00:03:05 GMT):
@greg.haskins @binhn @mastersingh24 I drafted an automatically triggered release process similar to what fabric uses in this JIRA task: https://jira.hyperledger.org/browse/FAB-2802

AdnanC (Thu, 16 Mar 2017 00:16:52 GMT):
Has joined the channel.

jimthematrix (Thu, 16 Mar 2017 00:20:30 GMT):
as far as creating the tag, are we waiting for something?

greg.haskins (Thu, 16 Mar 2017 00:23:47 GMT):
@jimthematrix normally I would say we are waiting for the CR pair that tickles the is-release property as in your JIRA

greg.haskins (Thu, 16 Mar 2017 00:24:53 GMT):
btw: the flag itself might not be strictly necessary if you want to emulate fabric/fabric-ca...the flag in those contexts is more about auto-managing the version than it is about the actual release

greg.haskins (Thu, 16 Mar 2017 00:25:07 GMT):
the release process is actually triggered by pushing a git tag

greg.haskins (Thu, 16 Mar 2017 00:25:54 GMT):
(because we add -snapshot-$gitsha to the version if its not a release)

greg.haskins (Thu, 16 Mar 2017 00:26:59 GMT):
if you dont have that opportunity in nodejs, you might just want to manage it manually in the package.json by adding a "-snapshot" suffix

greg.haskins (Thu, 16 Mar 2017 00:27:52 GMT):
then sdk release process would just be submit an un-suffixed version CR as release, + a re-suffixed+bumped CR

jimthematrix (Thu, 16 Mar 2017 00:30:07 GMT):
_we add -snapshot-$gitsha to the version if its not a release_, is the -snapshot-$gitsha tracked in a file?

greg.haskins (Thu, 16 Mar 2017 00:30:25 GMT):
not sure what you mean

greg.haskins (Thu, 16 Mar 2017 00:31:05 GMT):
we synthesize it based on your environment: https://github.com/hyperledger/fabric/blob/14055d70d9593e99295c7846076fc9dcfb1e052e/Makefile#L42

greg.haskins (Thu, 16 Mar 2017 00:31:40 GMT):
essentially its formed by Makefile::IS_RELEASE=false and `git rev-parse`

jimthematrix (Thu, 16 Mar 2017 00:32:11 GMT):
i see

greg.haskins (Thu, 16 Mar 2017 00:34:06 GMT):
for lack of a better option, I still thinking just manually augmenting the version with "-snapshot" except for when cutting a release is not a bad idea

greg.haskins (Thu, 16 Mar 2017 00:34:42 GMT):
its better than allowing multiple builds emit with the same tag (as it does today)

greg.haskins (Thu, 16 Mar 2017 00:35:04 GMT):
(IMO)

jimthematrix (Thu, 16 Mar 2017 00:38:08 GMT):
agree, i'll revise the proposal

jimthematrix (Thu, 16 Mar 2017 00:57:35 GMT):
https://jira.hyperledger.org/browse/FAB-2802 (revised, @greg.haskins )

greg.haskins (Thu, 16 Mar 2017 01:01:21 GMT):
looks good

greg.haskins (Thu, 16 Mar 2017 01:02:06 GMT):
you might want to consider tagging as part of the flow: e.g. you have two basic options as I see it

greg.haskins (Thu, 16 Mar 2017 01:02:32 GMT):
1) follow what fabric does and trigger on the tag push, not on the contents of the repo

greg.haskins (Thu, 16 Mar 2017 01:02:54 GMT):
2) alternatively, still process the repo, but add the ability to have the CI generate a tag when it passes

greg.haskins (Thu, 16 Mar 2017 01:03:13 GMT):
the most important part, ultimately, is that there is a tag on the release one way or the other

AdnanC (Thu, 16 Mar 2017 01:47:20 GMT):
https://gerrit.hyperledger.org/r/#/c/7251/ fix for the end2end instructions to account for required TLS flags. Is it too late to review and merge?

AdnanC (Thu, 16 Mar 2017 01:47:55 GMT):
People has began to look at the document and started using it, including CouchDB instructions. It'd be helpful to them.

mastersingh24 (Thu, 16 Mar 2017 09:56:03 GMT):
@AdnanC - 2 things - I don't think there are issues updating the readme - but frankly why are we not including this in the readthedocs as well? (which are likely going to need to be updated)

AdnanC (Thu, 16 Mar 2017 12:20:50 GMT):
@mastersingh24 yes, there is a separate changeset by Nick waiting for review that does that (taking this doc and including it in readthedocs)

binhn (Thu, 16 Mar 2017 12:44:29 GMT):
@greg.haskins I felt sick last night and this morning is terrible... so i think we should merge 1.0.0-alpha to kick off the process

greg.haskins (Thu, 16 Mar 2017 12:44:59 GMT):
@binhn its critical to merge both CRs together

greg.haskins (Thu, 16 Mar 2017 12:45:19 GMT):
so, if we fix up the other, and the other maintainers agree its the right call, they can go in

greg.haskins (Thu, 16 Mar 2017 12:45:48 GMT):
(also, sorry you are not feeling well)

binhn (Thu, 16 Mar 2017 12:46:10 GMT):
thanks -- "if we fix up the other" meaning fabric-ca and sdk ?

greg.haskins (Thu, 16 Mar 2017 12:46:30 GMT):
no, i mean 7241/7243 must go as a set

greg.haskins (Thu, 16 Mar 2017 12:46:45 GMT):
(but yes, it would make sense to also release ca/sdk too)

greg.haskins (Thu, 16 Mar 2017 12:47:18 GMT):
I just want to avoid the situation where we have 7241 merge without 7243, else we end up with a potential for confusion

greg.haskins (Thu, 16 Mar 2017 12:47:18 GMT):
I just want to avoid the situation where we have 7241 merged without 7243, else we end up with a potential for confusion

greg.haskins (Thu, 16 Mar 2017 12:48:24 GMT):
when its ready, and I have no opinion one way or the other, both should be committed in one fell swoop

binhn (Thu, 16 Mar 2017 12:49:06 GMT):
ok, makes sense yesterday, i thought that since we don't have the same process yet on ca and sdk, we could just tag them, and work on the process after, but it looks like Jim has started on sdk

greg.haskins (Thu, 16 Mar 2017 12:49:26 GMT):
i dont think that is true

greg.haskins (Thu, 16 Mar 2017 12:49:46 GMT):
fabric-ca uses the exact mechanism as fabric afaict, and I think we can do it on sdk as well

greg.haskins (Thu, 16 Mar 2017 12:49:59 GMT):
just slightly different for sdk

greg.haskins (Thu, 16 Mar 2017 12:50:19 GMT):
sdk doesnt have "IS_RELEASE" but the same dual-CR+tag approach should work

binhn (Thu, 16 Mar 2017 12:50:57 GMT):
what about fabric-ca? could we just copy the process from fabric over

greg.haskins (Thu, 16 Mar 2017 12:51:07 GMT):
what might not exist for ca/sdk is the CI push of the image

greg.haskins (Thu, 16 Mar 2017 12:51:21 GMT):
fabric-ca def has the IS_RELEASE logic

binhn (Thu, 16 Mar 2017 12:52:22 GMT):
ok, i 'll ask Ramesh about the ci push of the image

greg.haskins (Thu, 16 Mar 2017 12:53:23 GMT):
I can stage the CRs for the other two repos if you'd like

binhn (Thu, 16 Mar 2017 12:54:43 GMT):
yes please do

binhn (Thu, 16 Mar 2017 12:55:42 GMT):
i didn't something wrong yesterday; i merged alpha CR and 1.0.0 is in conflict that i have to rebase; i thought i created them on top of each other

greg.haskins (Thu, 16 Mar 2017 12:59:04 GMT):
https://gerrit.hyperledger.org/r/#/c/7265/

greg.haskins (Thu, 16 Mar 2017 13:04:46 GMT):
https://gerrit.hyperledger.org/r/#/c/7269/

greg.haskins (Thu, 16 Mar 2017 13:05:25 GMT):
@binhn it would appear that you refreshed 7241 without also refreshing 7243, should be easy to fix

greg.haskins (Thu, 16 Mar 2017 13:06:10 GMT):
@jimthematrix @JonathanLevi @smithbk note CRs above ^^^^

greg.haskins (Thu, 16 Mar 2017 13:06:30 GMT):
notably the stacks at 7265 and 7269

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup...

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup... so do we want to change that title of https://gerrit.hyperledger.org/r/#/c/7243 ?

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup... so do we want to change that title of https://gerrit.hyperledger.org/r/#/c/7243 ? Rather than calling it the full-blown Release? Last thing I/we need is somebody writing up a wrong blog about the right project, just at the wrong time :D

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup... so do we want to change that title of https://gerrit.hyperledger.org/r/#/c/7243 ? Rather than calling it the full-blown Release? Last thing I/we need is somebody writing up a `wrong` blog about the `right` project, just at the `wrong` time :D

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup... so do we want to change that title of https://gerrit.hyperledger.org/r/#/c/7243 ? Rather than calling it the full-blown Release? Last thing I/we need is somebody writing up an `inaccurate blog` about the `right project`, just at the `wrong time` :D

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup... so do we want to change that title of https://gerrit.hyperledger.org/r/#/c/7243 ? Rather than calling it the full-blown Release? Last thing I/we need is somebody writing up an `inaccurate blog` post about the `right project`, just at the `wrong time` :D

JonathanLevi (Thu, 16 Mar 2017 13:06:32 GMT):
Yup... so do we want to change that title of https://gerrit.hyperledger.org/r/#/c/7243 ? Rather than calling it the full-blown Release? Last thing I/we need is somebody writing up an `inaccurate blog post` about the `right project`, just at the `wrong time` :D

JonathanLevi (Thu, 16 Mar 2017 13:13:13 GMT):
Working under the assumption that we will have a post-alpha Release.

JonathanLevi (Thu, 16 Mar 2017 13:13:13 GMT):
Working under the assumption that we will have a follow up with a non-alpha Release ^^^^.

jimthematrix (Thu, 16 Mar 2017 13:17:15 GMT):
@greg.haskins thanks for creating the two CRs for node sdk, look right to me. we don't have the CI updated to handle the trigger yet ( discussed with @rameshthoomu last night about this and he'll work on that, but don't believe it's in place yet)

binhn (Thu, 16 Mar 2017 13:17:34 GMT):
@greg.haskins I got a weird error when pushing my rebase, so new CR for fabric to reset the release https://gerrit.hyperledger.org/r/#/c/7271/

timblankers (Thu, 16 Mar 2017 13:17:48 GMT):
Has joined the channel.

jimthematrix (Thu, 16 Mar 2017 13:17:50 GMT):
I suggest giving Ramesh a few hours to work this out so sdk release might lag behind fabric for a little bit

antoniovassell (Thu, 16 Mar 2017 13:18:17 GMT):
Has joined the channel.

JonathanLevi (Thu, 16 Mar 2017 13:19:57 GMT):
@binhn Don't we want to call it Release 1.0.0-alpha in https://gerrit.hyperledger.org/r/#/c/7271 ?

JonathanLevi (Thu, 16 Mar 2017 13:19:57 GMT):
@binhn Don't you/we want to call it Release 1.0.0-alpha in https://gerrit.hyperledger.org/r/#/c/7271 ?

JonathanLevi (Thu, 16 Mar 2017 13:20:21 GMT):
(no need to restart the build, of course)

JonathanLevi (Thu, 16 Mar 2017 13:20:21 GMT):
(no need to restart the build, of course - just the title/Commit Msg)

binhn (Thu, 16 Mar 2017 13:21:45 GMT):
@JonathanLevi no since this is a follow on to 7241, so bump the base_version

binhn (Thu, 16 Mar 2017 13:22:09 GMT):
assuming 1.0.0 after alpha

mrkiouak (Thu, 16 Mar 2017 13:29:29 GMT):
Has joined the channel.

davidkel (Thu, 16 Mar 2017 13:33:12 GMT):
Has joined the channel.

rikmoedt (Thu, 16 Mar 2017 13:34:07 GMT):
Has joined the channel.

vriffier (Thu, 16 Mar 2017 13:42:09 GMT):
Has joined the channel.

greg.haskins (Thu, 16 Mar 2017 13:47:04 GMT):
@mastersingh24 @binhn not sure what happened, but the first CRs were merged without the second

greg.haskins (Thu, 16 Mar 2017 13:47:22 GMT):
please fix this by either merging the second CR or reverting the first

greg.haskins (Thu, 16 Mar 2017 13:47:42 GMT):
(otherwise all commits that go in between the two will have IS_RELEASE=true set

greg.haskins (Thu, 16 Mar 2017 13:48:10 GMT):
also, please halt merging anything else until the above is addressed

mastersingh24 (Thu, 16 Mar 2017 13:50:23 GMT):
did we actually create a build - i.e. publish images?

mastersingh24 (Thu, 16 Mar 2017 13:51:00 GMT):
@greg.haskins - you gave https://gerrit.hyperledger.org/r/#/c/7271/ a -1

mastersingh24 (Thu, 16 Mar 2017 13:52:41 GMT):
ok - I edited https://gerrit.hyperledger.org/r/#/c/7271/2

greg.haskins (Thu, 16 Mar 2017 13:52:47 GMT):
the name needs to be changed...cool

mastersingh24 (Thu, 16 Mar 2017 13:52:59 GMT):
but now I can't approve ;)

greg.haskins (Thu, 16 Mar 2017 13:53:10 GMT):
generally what I would suggest is for these releases: commit the top-level as a stack

mastersingh24 (Thu, 16 Mar 2017 13:53:39 GMT):
makes sense

mastersingh24 (Thu, 16 Mar 2017 13:53:58 GMT):
@JonathanLevi - can you approve https://gerrit.hyperledger.org/r/#/c/7271/2 along with @greg.haskins

mastersingh24 (Thu, 16 Mar 2017 13:54:04 GMT):
then we should be on track

JonathanLevi (Thu, 16 Mar 2017 13:54:45 GMT):
Shall I merge?

JonathanLevi (Thu, 16 Mar 2017 13:54:57 GMT):
I'm happy with it.

asadhayat (Thu, 16 Mar 2017 13:55:07 GMT):
Has joined the channel.

JonathanLevi (Thu, 16 Mar 2017 13:55:54 GMT):
@mastersingh24: done

greg.haskins (Thu, 16 Mar 2017 13:56:45 GMT):
I will push the tag for fabric.git, which should trigger the dockerhub push

greg.haskins (Thu, 16 Mar 2017 14:05:40 GMT):
https://github.com/hyperledger/fabric/releases/tag/v1.0.0-alpha

greg.haskins (Thu, 16 Mar 2017 14:06:54 GMT):
https://jenkins.hyperledger.org/job/fabric-app-image-release-docker-x86_64/

jimthematrix (Thu, 16 Mar 2017 14:16:09 GMT):
@greg.haskins I added an additional step in the sdk's release process (https://jira.hyperledger.org/browse/FAB-2802) for tagging, to be done at the very end manually. Ideally it should be done by the CI (like you said in option 2) but it'll require the CI account to be a maintainer/admin. so it can always be improved later.

rameshthoomu (Thu, 16 Mar 2017 15:04:53 GMT):
@greg.haskins CI failed to push images to dockerhub..

rameshthoomu (Thu, 16 Mar 2017 15:05:27 GMT):
seems dockerhub credentials issue..

greg.haskins (Thu, 16 Mar 2017 16:25:32 GMT):
@rameshthoomu ok, ill leave it to you to sort that out...the tag is pushed so just work from that

rameshthoomu (Thu, 16 Mar 2017 16:26:46 GMT):
sure we are working on it..

greg.haskins (Thu, 16 Mar 2017 16:26:50 GMT):
ty

binhn (Thu, 16 Mar 2017 18:08:43 GMT):
could someone approve these release CRs for fabric-ca https://gerrit.hyperledger.org/r/#/c/7263/ https://gerrit.hyperledger.org/r/#/c/7265/

binhn (Thu, 16 Mar 2017 18:09:26 GMT):
@JonathanLevi @mastersingh24 @muralisr @jyellick @jimthematrix

mastersingh24 (Thu, 16 Mar 2017 18:13:18 GMT):
is fabric-ca even set to trigger a publish off of this type of commit?

jyellick (Thu, 16 Mar 2017 18:17:47 GMT):
@binhn +2-ed but did not submit, pending Gari's question

binhn (Thu, 16 Mar 2017 18:21:44 GMT):
@mastersingh24 @rameshthoomu is working on the ci push so we need the CRs to mark the location to build and push

mastersingh24 (Thu, 16 Mar 2017 18:23:24 GMT):
so he'll trigger it manually but pulling a commit level?

mastersingh24 (Thu, 16 Mar 2017 18:23:40 GMT):
since clearly merging this will not trigger it as this point

mastersingh24 (Thu, 16 Mar 2017 18:24:22 GMT):
ok - I merged both of them

JonathanLevi (Thu, 16 Mar 2017 18:25:10 GMT):
And I have reviewed them ;-)

binhn (Thu, 16 Mar 2017 18:25:59 GMT):
@mastersingh24 yes, thanks

rameshthoomu (Thu, 16 Mar 2017 18:37:52 GMT):
@mastersingh24 @binhn Are we creating v1.0.0-alpha tag for fabric-ca repo?

binhn (Thu, 16 Mar 2017 18:38:34 GMT):
yes, 7263 is to do that

greg.haskins (Thu, 16 Mar 2017 18:39:37 GMT):
@binhn I suspect he means the literal git-tag...ill create that now since 726[35] has been merged

binhn (Thu, 16 Mar 2017 18:41:00 GMT):
@greg.haskins ah, thanks

greg.haskins (Thu, 16 Mar 2017 18:41:57 GMT):
done

greg.haskins (Thu, 16 Mar 2017 18:42:52 GMT):
https://github.com/hyperledger/fabric-ca/releases/tag/v1.0.0-alpha

rameshthoomu (Thu, 16 Mar 2017 18:56:34 GMT):
Thanks @greg.haskins

rameshthoomu (Thu, 16 Mar 2017 18:56:50 GMT):
CI job triggered..

rameshthoomu (Thu, 16 Mar 2017 18:57:08 GMT):
will update once images are published

jimthematrix (Thu, 16 Mar 2017 19:35:12 GMT):
v1.0.0-alpha has been tagged in fabric-sdk-node

jimthematrix (Thu, 16 Mar 2017 19:35:52 GMT):
now there's a v1.0-alpha branch that I created back in Feb for the SF hackfest. should I delete it to avoid confusion?

rameshthoomu (Thu, 16 Mar 2017 19:36:10 GMT):
All, published v1.0.0-alpha images to hyperledger dockerhub account

binhn (Thu, 16 Mar 2017 19:38:24 GMT):
@rameshthoomu yes, let's remove that v1.0-alpha branch

mastersingh24 (Thu, 16 Mar 2017 21:06:37 GMT):
@rameshthoomu - anyone tried the e2ecli with the images?

rameshthoomu (Thu, 16 Mar 2017 21:07:19 GMT):
will test now.. working on npm module publish..

rameshthoomu (Thu, 16 Mar 2017 21:07:25 GMT):
will update here in some time..

rameshthoomu (Thu, 16 Mar 2017 21:39:45 GMT):
@mastersingh24 : Tested e2e (CLI) with TLS and couchdb ... It all worked as expected

rameshthoomu (Thu, 16 Mar 2017 21:40:55 GMT):
testing node (e2e) and Java (e2e) .. will update status once done..

rameshthoomu (Thu, 16 Mar 2017 23:15:49 GMT):
@mastersingh24 tested e2e using published images on latest fabric-sdk-node and fabric-sdk-java commits..

rameshthoomu (Thu, 16 Mar 2017 23:15:56 GMT):
it's all working as expected..

rameshthoomu (Thu, 16 Mar 2017 23:16:16 GMT):
posted commit levels and image references in #fabric-ci channel

RahulBagaria (Fri, 17 Mar 2017 04:02:39 GMT):
Has joined the channel.

mastersingh24 (Fri, 17 Mar 2017 11:05:22 GMT):
@rjones @cbf - do we have any place to host html-based sites? the fabric-node-sdk currently generates some very nice HTML documentation, but we have not where that we know of to host it. Here's what it look like using git pages: https://mastersingh24.github.io/fabric-sdk-node/index.html

cbf (Fri, 17 Mar 2017 11:06:23 GMT):
nexus?

mastersingh24 (Fri, 17 Mar 2017 11:07:05 GMT):
I figured out how to generate markdown compatible with readthedocs - but it's not as sexy - http://singh-docs.readthedocs.io/en/latest/ca

cbf (Fri, 17 Mar 2017 11:07:22 GMT):
either that or stand up ngnix on the lf cloud hosting

cbf (Fri, 17 Mar 2017 11:07:53 GMT):
could host html or md via github pages

mastersingh24 (Fri, 17 Mar 2017 11:13:18 GMT):
I imagine we'll want to do the same thing for the Javadoc as well

rjones (Fri, 17 Mar 2017 11:29:16 GMT):
we don't have anything in general. I have a request to stand up an S3 bucket for the slack log export. I suspect I could ask IT to make this a canned item where we can publish static documents more regularly. As cbf noted we could also publish to nexus2 after some jiggling

rjones (Fri, 17 Mar 2017 11:29:32 GMT):
_notes @rjones is still on leave and is not really here :)_

cbf (Fri, 17 Mar 2017 12:50:08 GMT):
please be sure that all change requests have JIRA references, please

greg.haskins (Fri, 17 Mar 2017 13:59:52 GMT):
_hides from @cbf _

cbf (Fri, 17 Mar 2017 14:00:03 GMT):
;-)

jimthematrix (Fri, 17 Mar 2017 16:03:28 GMT):
@rjones (or your deputy while you are on vacation) can we get the web server for hosting docs soon? i totally hate the readthedocs styling and i think it'll be a pity not to use great styling provided by tools like jsdoc3 (for instance this: jimthematrix.github.io), with the added benefit that it allows content written in jsdoc syntax and .md syntax all be integrated via the @tutorial support in jsdoc

jwagantall (Fri, 17 Mar 2017 21:42:01 GMT):
@jimthematrix yes... we can work on that.. I will bring this with Ry so that we can talk to IT about all the needs we have for this server

mastersingh24 (Fri, 17 Mar 2017 22:12:20 GMT):
@jwagantall - unless there's a better option / suggestion, it might be nice if we had a `hyperledger.github.io` git pages. Basically we just need some from the hyperledger github organization to create a repository name `hyperledger.github.io` and then we can publish the carious docs to sub-folders as required ;) that would be my suggestion

rjones (Fri, 17 Mar 2017 22:13:00 GMT):
@mastersingh24 I started to do that once but was pulled back as that apparently needs TSC approval.

rjones (Fri, 17 Mar 2017 22:13:40 GMT):
I'm not for or against it (well, compared to setting up other hosting, I'm for it) but just letting you know the bar is a little higher than I expected

mastersingh24 (Fri, 17 Mar 2017 22:24:13 GMT):
@rjones (who's really not here) - yeah - I can believe that. But if we just need TSC approval and no one vehemently disagrees with the approach, should we come up with a proposal?

rjones (Fri, 17 Mar 2017 23:28:42 GMT):
@mastersingh24 sure. would this be a superset of the fabric documentation reorg?

mastersingh24 (Fri, 17 Mar 2017 23:39:39 GMT):
Yeah - I believe so

lehors (Sun, 19 Mar 2017 17:29:10 GMT):
@rjones @mastersingh24 I have to admit not to really see why such a thing would need TSC approval, but if that is the case I would expect this to be easily done

rjones (Sun, 19 Mar 2017 22:48:21 GMT):
@lehors perhaps I mis-remember. @rameshthoomu asked me to enable this some time ago and it was shot down.

mgk (Wed, 22 Mar 2017 13:13:43 GMT):
Has joined the channel.

rrader (Wed, 22 Mar 2017 19:58:47 GMT):
hi, I am trying to registrar v0.6, and I am getting this vp0_1 | 19:44:48.855 [rest] Register -> INFO 02c REST client login... vp0_1 | 19:44:48.856 [rest] Register -> INFO 02d Local data store for client loginToken: /var/hyperledger/production/client/ vp0_1 | 19:44:48.856 [rest] Register -> INFO 02e Logging in user 'test_vp0' on REST interface... vp0_1 | 19:44:48.856 [crypto] RegisterClient -> INFO 02f Registering client [test_vp0] with name [test_vp0]... vp0_1 | 19:44:48.866 [crypto] Errorf -> ERRO 030 [client.test_vp0] Failed invoking CreateCertficatePair [rpc error: code = 2 desc = Identity or token does not match.]. vp0_1 | 19:44:48.866 [crypto] Errorf -> ERRO 031 [client.test_vp0] Failed getting enrollment certificate [id=test_vp0]: [rpc error: code = 2 desc = Identity or token does not match.] vp0_1 | 19:44:48.866 [crypto] Errorf -> ERRO 032 [client.test_vp0] Failed retrieving enrollment data [rpc error: code = 2 desc = Identity or token does not match.]. vp0_1 | 19:44:48.866 [crypto] Errorf -> ERRO 033 [client.test_vp0] Failed registering node crypto engine [rpc error: code = 2 desc = Identity or token does not match.]. vp0_1 | 19:44:48.867 [crypto] Errorf -> ERRO 034 [client.test_vp0] Failed registering client [test_vp0]: [rpc error: code = 2 desc = Identity or token does not match.] vp0_1 | 19:44:48.867 [crypto] RegisterClient -> ERRO 035 Failed registering client [test_vp0] with name [test_vp0] [rpc error: code = 2 desc = Identity or token does not match.]. vp0_1 | 19:44:48.867 [rest] Register -> ERRO 036 Error on client login: rpc error: code = 2 desc = Identity or token does not match. can someone say why I can't registrar?

JonathanLevi (Thu, 23 Mar 2017 01:06:49 GMT):
Hello @rrader, this is not the right channel I am afraid. Please can you try any of #fabric-ca, #fabric-dev, #fabric-questions, ... ?

JonathanLevi (Thu, 23 Mar 2017 01:06:49 GMT):
Hello @rrader, this is not the right channel I am afraid. Please can you try any of #fabric-ca, #fabric-dev-env, #fabric-questions, ... ?

matanyahu (Thu, 23 Mar 2017 10:57:53 GMT):
Has joined the channel.

cbf (Thu, 23 Mar 2017 16:30:26 GMT):
@rjones @mastersingh24 etc I think that a hyperledger.github.io page would be good, but it should just have links to other stuff, and we need to probably assign maintainers from all the top level projects to ensure that the content remains neutral etc

rickr (Thu, 23 Mar 2017 23:28:53 GMT):
In JIRA can we add a blocked to the workflow so that shows up as it's status ?

yacovm (Thu, 23 Mar 2017 23:35:13 GMT):
You can specify that an issue is blocked by another issue

rickr (Fri, 24 Mar 2017 12:06:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=F9wimBGREg7ioSEnY) Sure but it that doesn't show up in the report status

mastersingh24 (Fri, 24 Mar 2017 14:19:13 GMT):
[One thing we were hoping to solve by using git pages was to be able to host HTML docs content like those generated by jsdoc and I'd assume javadoc as well ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Xs45ytuzwQ34Thmrh) @cbf

mastersingh24 (Sat, 25 Mar 2017 15:21:47 GMT):
so does anyone here know anything about https://nexus.hyperledger.org and what/how we can use it to host files, etc? I am think about how to host binaries, maybe versioned samples, etc

rjones (Sat, 25 Mar 2017 21:06:16 GMT):
@mastersingh24 https://nexus.hyperledger.org/ will primarily be for hosting log files. https://nexus3.hyperledger.org/ is for publishing artifacts. @rameshthoomu has done work on publishing, for instance, docker images.

rjones (Sat, 25 Mar 2017 21:06:16 GMT):
@mastersingh24 nexus will primarily be for hosting log files. https://nexus3.hyperledger.org/ is for publishing artifacts. @rameshthoomu has done work on publishing, for instance, docker images.

mastersingh24 (Sat, 25 Mar 2017 23:36:35 GMT):
ah - cool. thanks @rjones

rjones (Sun, 26 Mar 2017 05:31:14 GMT):
@mastersingh24 to answer your unasked question - timing. We couldn't get nexus.h.o upgraded to nexus 3 fast enough, and nexus 3 had a bug that prevented anonymous log serving, so we couldn't just replace nexus 2 with nexus 3. The plan is to eventually move logshipping to nexus 3 and use DNS trickery to retire nexus2, but that's a q3 or q4 thing. logs.h.o is a DNS alias, but we haven't discussed making for instance a docker.h.o alias for example.

mastersingh24 (Sun, 26 Mar 2017 10:58:24 GMT):
thanks @rjones . we are now at a point where publishing binary and file artifacts seems like the best path in terms of consumability (rather than telling standard users to clone repos and compile code when they simply want to use it) . So that's why I've been so laser focused ;)

rjones (Sun, 26 Mar 2017 10:59:25 GMT):
seems reasonable. I know Ramesh had some docs in the hopper about how to pull the docker images from us; don't know if they're merged yet

rjones (Sun, 26 Mar 2017 10:59:54 GMT):
https://gerrit.hyperledger.org/r/#/c/7381/

rjones (Sun, 26 Mar 2017 11:01:52 GMT):
OK, I was right, https://gerrit.hyperledger.org/r/#/c/7381/ is the change with the script. It still requires cloning the repo, though

mastersingh24 (Sun, 26 Mar 2017 13:32:21 GMT):
am I the only one seeing test failures with anything based on https://gerrit.hyperledger.org/r/#/c/6795/ or later?

C0rWin (Sun, 26 Mar 2017 13:59:43 GMT):
@mastersingh24 rebased CR https://gerrit.hyperledger.org/r/#/c/7405/ for several times recently didn't experienced test failures

cbf (Sun, 26 Mar 2017 17:01:02 GMT):
@mastersingh24 @rjones we shouldn't (IMO) be encouraging end users to be d/l images from Nexus - should be focusing them on dockerhub - Nexus images are by definition unstable until we release them

mastersingh24 (Sun, 26 Mar 2017 18:48:12 GMT):
not Docker images

mastersingh24 (Sun, 26 Mar 2017 18:48:35 GMT):
command line binaries - e.g. configtxgen, peer cli, compose files, etc

mastersingh24 (Sun, 26 Mar 2017 18:49:09 GMT):
we need a place to publish tested, certified binaries and artifacts which we can link to from our documentation

mastersingh24 (Sun, 26 Mar 2017 18:49:36 GMT):
we can't be telling users to clone github and build tools and we will be changing / updating versions, etc

mastersingh24 (Sun, 26 Mar 2017 18:49:48 GMT):
take a look at the new getting started

mastersingh24 (Sun, 26 Mar 2017 18:50:05 GMT):
the doc is fine EXCEPT we require people to still build tools from the repo

mastersingh24 (Sun, 26 Mar 2017 18:50:30 GMT):
that's unacceptable and non-consumable for someone who simply wants to use fabric

muralisr (Sun, 26 Mar 2017 20:54:39 GMT):
esp. as ongoing dev. would make such command line binaries out of sync with the dependent, pre-built peer, orderer images... all dependent binraries could be put in one of the images

cbf (Sun, 26 Mar 2017 21:13:45 GMT):
ok agree on binaries, but we should just expose tarballs on release page for various platforms

cbf (Sun, 26 Mar 2017 21:14:26 GMT):
the end user should not be directly exposed to the source object store

rjones (Sun, 26 Mar 2017 22:22:39 GMT):
I have no opinion on this. Ramesh checked in a change (a script) for people external to the CI system to download docker from nexus.

rickr (Sun, 26 Mar 2017 22:29:27 GMT):
Do we now have on docker hub or elsewhere where all users can pull specific commit levels of the Fabric/ca from ?

rjones (Sun, 26 Mar 2017 22:32:11 GMT):
https://hub.docker.com/r/hyperledger/fabric-ca/tags/ says "I don't think so"

mastersingh24 (Sun, 26 Mar 2017 22:35:02 GMT):
@rickr - are you asking about internal (e.g. people doing development of SDKs like yourself)?

mastersingh24 (Sun, 26 Mar 2017 22:35:19 GMT):
normal users should not need to pull images by commit level

mastersingh24 (Sun, 26 Mar 2017 22:36:12 GMT):
@rameshthoomu definitely publishes non-release type images somewhere I believe

rickr (Sun, 26 Mar 2017 22:37:03 GMT):
nope all ... right now we still have in our README.md how to build the fabric/ca to use with the HLJSDK :( It be so nice to just have a DC file that would just pull it down

mastersingh24 (Sun, 26 Mar 2017 22:55:53 GMT):
why doesn't the JSDK work with the 1.0.0-alpha images?

mastersingh24 (Sun, 26 Mar 2017 22:56:07 GMT):
that's what we are telling people to pull down in general

mastersingh24 (Sun, 26 Mar 2017 22:56:39 GMT):
(really I do know why)

rickr (Mon, 27 Mar 2017 01:20:58 GMT):
We probably do now and should just do that. But going forward the _latest_ may not always be compatible (and that's been the case at times for both SDKs :) ) For me the _ideal_ case for those wanting to be on the bleeding edge would after and SDK passes FIT e2e publish docker hub fabric/ca docker images with tag hlXjdk_snapshot and publish the sdk to npm/maven repos'

mastersingh24 (Mon, 27 Mar 2017 09:26:28 GMT):
I agree with you @rickr that we should have a "bleeding" edge release stream which includes both Docker images and the various SDKs and tools

cgrecu (Mon, 27 Mar 2017 13:45:09 GMT):
Has joined the channel.

JonathanLevi (Mon, 27 Mar 2017 16:00:52 GMT):
Good morning! (sorry I'm the last to wake up, timezone-wise)

JonathanLevi (Mon, 27 Mar 2017 16:01:37 GMT):
We should probably start working out an integration plan for all those items we put on hold close to the *v1.0.0-alpha* cut.

JonathanLevi (Mon, 27 Mar 2017 16:01:37 GMT):
We should probably start working out an integration plan for all those items we put on hold close to the `v1.0.0-alpha` cut.

JonathanLevi (Mon, 27 Mar 2017 16:01:37 GMT):
We should probably start working out an integration plan for all those items we put on hold close to the `v1.0-alpha` cut.

JonathanLevi (Mon, 27 Mar 2017 16:02:48 GMT):
It was good to have that "soft" code-freeze/feature-freeze, but I bet that most of us here are getting direct requests for things that we could not have merged in March.

JonathanLevi (Mon, 27 Mar 2017 16:03:43 GMT):
---- While also giving people enough time to report issues against the current `v1.0-alpha` baseline.

yacovm (Mon, 27 Mar 2017 16:05:34 GMT):
you mean report *and fix* right? ;)

JonathanLevi (Mon, 27 Mar 2017 16:06:55 GMT):
Right. But at this point, just getting people reporting issues, will be a bit step (data-point/input) that will allow us to see where we stand... and plan accordingly.

JonathanLevi (Mon, 27 Mar 2017 16:06:55 GMT):
Right. But at this point, just/even getting people reporting issues, will be a big step (data-point/input) that will allow us to see where we stand... and plan accordingly.

JonathanLevi (Mon, 27 Mar 2017 16:07:46 GMT):
There is a lot that's going on these days. A few projects porting to fabric-1.0, etc. We should (plan to) accommodate these.

JonathanLevi (Mon, 27 Mar 2017 16:08:35 GMT):
But that's true. If we have some severe issues that we are aware of, in 1.0-alpha, we should prioritize their *fix* over introducing more (new/promised) features.

JonathanLevi (Mon, 27 Mar 2017 16:08:35 GMT):
But that's true. If we have some severe issues that we are aware of (/or become aware of), in 1.0-alpha, we should prioritize their *fix* over introducing more (new/promised) features.

JonathanLevi (Mon, 27 Mar 2017 16:09:34 GMT):
But that's true. If we have some severe issues that we are aware of (/or become aware of), in 1.0-alpha, we should prioritize their *fix* over introducing more (new/promised) features.

greg.haskins (Tue, 28 Mar 2017 11:47:52 GMT):
cd ..

greg.haskins (Tue, 28 Mar 2017 13:56:36 GMT):
@rickr @mastersingh24 @rjones @mrkiouak regarding above conversation about ca:latest

greg.haskins (Tue, 28 Mar 2017 13:57:13 GMT):
we should probably unify things: the :latest tag is not applied consistently and I am of the opinion we should just drop it from the places that have it

greg.haskins (Tue, 28 Mar 2017 13:57:39 GMT):
it currently is, at best, false advertising, since its not actually the latest but v0.6

greg.haskins (Tue, 28 Mar 2017 13:57:59 GMT):
it was left at the time of the v0.6 release to deal with shotcomings in client-toolings

greg.haskins (Tue, 28 Mar 2017 13:58:38 GMT):
if for some reason people feel strongly it needs to stay, we should at least a) move it forward so it actually is latest and b) apply it consistently across all of the repos

greg.haskins (Tue, 28 Mar 2017 14:06:27 GMT):
@rjones @cbf unless anyone objects, I suggest we take the temporary conservative approach of moving the :latest tag to all x86-v1.0.0-alpha

greg.haskins (Tue, 28 Mar 2017 14:06:48 GMT):
we can decide whether to remove it after broader discussion

greg.haskins (Tue, 28 Mar 2017 14:07:17 GMT):
@cbf what is the status of that work to get the multi-arch support in docker in genera?

cbf (Tue, 28 Mar 2017 14:07:20 GMT):
hmm

cbf (Tue, 28 Mar 2017 14:09:39 GMT):
anyone playing with v0.6 will be disrupted

cbf (Tue, 28 Mar 2017 14:10:27 GMT):
we should pre-announce and warn ppl on chat and email

greg.haskins (Tue, 28 Mar 2017 14:46:21 GMT):
i hadnt thought of that, good point

greg.haskins (Tue, 28 Mar 2017 14:46:38 GMT):
not sure anyone is, or at least, is relying on :latest for that though

greg.haskins (Tue, 28 Mar 2017 14:47:09 GMT):
generally speaking, if you are relying on :latest you should expect it to move from time to time ;)

rjones (Tue, 28 Mar 2017 14:50:56 GMT):
certainly the x86-v1.0.0-alpha bits are more widespread than the v0.6 ones

rjones (Tue, 28 Mar 2017 14:50:56 GMT):
certainly the x86-v1.0.0-alpha bits are more widespread within dockerhub than the v0.6 ones

markparz (Tue, 28 Mar 2017 17:11:14 GMT):
Here is a list of items that didn't make the Alpha release, notice we've moved proposed items to the right on the roadmap. Please provide any feedback. There is no new content, this is stabilization, testing, clean up of existing items. I will update FAB-37 with this information as well.

markparz (Tue, 28 Mar 2017 17:11:14 GMT):
See Fab-37 list of items that didn't make the Alpha release, notice we've moved proposed items to the right on the roadmap. Please provide any feedback. There is no new content, this is stabilization, testing, clean up of existing items. I will update FAB-37 with this information as well.

kostas (Wed, 29 Mar 2017 01:07:34 GMT):
Just a heads up: if you own a Mac do not install the latest Xcode update or you will be unable to build/run/test your Go code locally.

kostas (Wed, 29 Mar 2017 01:07:41 GMT):

Message Attachments

kostas (Wed, 29 Mar 2017 01:08:19 GMT):
See https://github.com/golang/go/issues/19734 for a description of the problem and workarounds.

kostas (Wed, 29 Mar 2017 01:08:19 GMT):
See https://github.com/golang/go/issues/19734 for a description of the problem and workarounds. (Either downgrade Xcode to 8.2 or run everything with `-ldflags -s`.)

greg.haskins (Wed, 29 Mar 2017 01:14:49 GMT):
@kostas ty for the heads up

weeds (Wed, 29 Mar 2017 01:23:43 GMT):
@markparz should we maybe re-lable pluggable crypto to application crypto library?

markparz (Wed, 29 Mar 2017 01:26:19 GMT):
I think that was for clean up but will revisit

markparz (Wed, 29 Mar 2017 01:27:25 GMT):
@kostas I was literally installing today and it was taking so long I cancelled ... you saved me!

mastersingh24 (Wed, 29 Mar 2017 10:46:24 GMT):
[who owns the content of the hyperledger dockerhub org page? ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=pGiPY3Jbpdutr3h6o) @greg.haskins

mastersingh24 (Wed, 29 Mar 2017 10:47:59 GMT):
we really need to get some better material there and/or point people to readthedocs from there (well first we need to make sue readthedocs is updated, but if I just go to the hyperledger dockerhub repos today, it tells me nothing)

greg.haskins (Wed, 29 Mar 2017 11:28:40 GMT):
@mastersingh24 I believe LF/@ry

rjones (Wed, 29 Mar 2017 15:41:36 GMT):
@mastersingh24 @greg.haskins I can edit it, please tell me what to put where

mastersingh24 (Wed, 29 Mar 2017 15:52:40 GMT):
great. thx @rjones - we'll work up something and get back to you

aybekbuka (Thu, 30 Mar 2017 03:30:31 GMT):
Has joined the channel.

rickr (Thu, 30 Mar 2017 20:16:23 GMT):
@rjones Seeing a chopped off menu in gerrit due to top banners

rickr (Thu, 30 Mar 2017 20:16:48 GMT):

Message Attachments

rjones (Thu, 30 Mar 2017 20:18:34 GMT):
browser?

rickr (Thu, 30 Mar 2017 20:18:48 GMT):
FF

rjones (Thu, 30 Mar 2017 20:19:01 GMT):
also, let's take this to #ci-pipeline

rickr (Thu, 30 Mar 2017 20:19:09 GMT):
sure

cbf (Fri, 31 Mar 2017 11:06:49 GMT):
hmmm FF was fine for me, only chrome had chopped off header

binhn (Fri, 31 Mar 2017 15:37:45 GMT):
It looks like v1.0.0-alpha been quite popular, so next month we are moving into code hardening (security, performance, hygiene) and documentation. I am thinking about wrapping up around April 21st and publishing a beta image by May 1st. Depending on defect rate, we could look at end of May 1.0 release or sometime in June. Around the beta time, we want to branch 1.0.0 to keep on quality work but open up the master branch for new work post 1.0. Thoughts?

binhn (Fri, 31 Mar 2017 15:38:30 GMT):
@channel ^^^

cbf (Fri, 31 Mar 2017 15:49:31 GMT):
@binh so, I presume that this means no new functionality? Or, is there a process for having the maintainers agree on any new function before it is added/merged?

cbf (Fri, 31 Mar 2017 15:50:13 GMT):
seems to me that the exclusive focus should be on running current and new tests, fixing bugs, lather, rinse, repeat

mastersingh24 (Fri, 31 Mar 2017 16:00:36 GMT):
@cbf - there are a few things which were not completed (e.g. channel config transactions, buttoning up chaincode packaging and lifecycle (e.g. upgrade) and a few security items related to chaincode).

binhn (Fri, 31 Mar 2017 16:20:01 GMT):
@cbf @mastersingh24 right, these and known code hardening items are in sprint 15 on jira

cbf (Fri, 31 Mar 2017 17:24:17 GMT):
we need to clearly mark and maintainers need to check against that list

lehors (Fri, 31 Mar 2017 18:32:40 GMT):
hi there, has Windows been officially dropped from the supported platforms?

lehors (Fri, 31 Mar 2017 18:33:35 GMT):
it seems like no effort is still being made to keep vagrant working anymore

lehors (Fri, 31 Mar 2017 18:34:05 GMT):
I saw Chris's suggesting to drop the vagrant section from the getting started doc

lehors (Fri, 31 Mar 2017 18:34:28 GMT):
and on trying I just found that we have some code that makes installing a chaincode fail on vagrant

lehors (Fri, 31 Mar 2017 18:34:58 GMT):
I don't think this should be something that gets decided based on personal preference

lehors (Fri, 31 Mar 2017 18:35:19 GMT):
and I haven't seen any discussion on dropping vagrant support

VipinB (Fri, 31 Mar 2017 18:36:10 GMT):
@lehors + 1

yacovm (Fri, 31 Mar 2017 18:39:19 GMT):
if you run vagrant a windows host, there is an issue related to file `x` (executable) permissions that the peer cli doesn't like. It's because the $GOPATH is on a shared folder. The solution is to create a directory on somewhere else, i.e `/tmp/src/` and then do `export GOPATH=/tmp:$GOPATH` and put the chaincode there.

yacovm (Fri, 31 Mar 2017 18:39:19 GMT):
if you run vagrant on a windows host, there is an issue related to file `x` (executable) permissions that the peer cli doesn't like. It's because the $GOPATH is on a shared folder. The solution is to create a directory on somewhere else, i.e `/tmp/src/` and then do `export GOPATH=/tmp:$GOPATH` and put the chaincode there.

lehors (Fri, 31 Mar 2017 18:40:13 GMT):
yes, that's one solution

lehors (Fri, 31 Mar 2017 18:40:42 GMT):
but it means 'getting started' doesn't work on windows+vagrant

lehors (Fri, 31 Mar 2017 18:41:40 GMT):
this sucks

muralisr (Fri, 31 Mar 2017 18:47:40 GMT):
`and on trying I just found that we have some code that makes installing a chaincode fail on vagrant` @lehors what did you run into ?

lehors (Fri, 31 Mar 2017 18:48:11 GMT):
vagrant exposes all windows files with filemode 777

muralisr (Fri, 31 Mar 2017 18:48:22 GMT):
that was what I was typing :-)

muralisr (Fri, 31 Mar 2017 18:49:19 GMT):
I see people once a while get that error ...I remember @rameshthoomu was struggling with that a while back

muralisr (Fri, 31 Mar 2017 18:49:36 GMT):
@rameshthoomu do you remember what the resolution was please ?

lehors (Fri, 31 Mar 2017 18:50:41 GMT):
there seems to be 2 workarounds: 1) patch the code to remove the test, 2) install a chaincode that's not in a shared folder in vagrant so that it can be given the expect filemode

muralisr (Fri, 31 Mar 2017 18:50:55 GMT):
ok

lehors (Fri, 31 Mar 2017 18:51:07 GMT):
neither is really satisfying

muralisr (Fri, 31 Mar 2017 18:51:12 GMT):
chmod was overridden by vagrant ?

yacovm (Fri, 31 Mar 2017 18:51:23 GMT):
more like it has no effect

lehors (Fri, 31 Mar 2017 18:51:27 GMT):
yes, that's a known problem with vagrant

lehors (Fri, 31 Mar 2017 18:51:44 GMT):
all files are exposed as 777 and there is no way to change that

rameshthoomu (Fri, 31 Mar 2017 18:53:00 GMT):
@muralisr still struggling with the same error.. I tried few attempts but getting the same error..

muralisr (Fri, 31 Mar 2017 18:53:13 GMT):
rebooting help at all ?

JonathanLevi (Fri, 31 Mar 2017 19:05:16 GMT):
Hi guys, not sure why but I'm a bit under the weather. Maybe all these flashlights from InterConnect.

JonathanLevi (Fri, 31 Mar 2017 19:05:19 GMT):
:-)

JonathanLevi (Fri, 31 Mar 2017 19:05:58 GMT):
So I have a workaround for that vagrant issue @rameshthoomu, @lehors - but it's really not that pretty.

JonathanLevi (Fri, 31 Mar 2017 19:06:26 GMT):
We had to end up editing the vagrant file manually...

JonathanLevi (Fri, 31 Mar 2017 19:06:50 GMT):
Like adding hese lines to vagrant file after the line: config.vm.synced_folder "..", "/opt/gopath/src/github.com/hyperledger/fabric": config.vm.synced_folder "../examples", "/opt/gopath/src/github.com/hyperledger/fabric/examples", mount_options: ["dmode=777", "fmode=666"]

JonathanLevi (Fri, 31 Mar 2017 19:06:50 GMT):
Like adding these lines to vagrant file after the line: config.vm.synced_folder "..", "/opt/gopath/src/github.com/hyperledger/fabric": config.vm.synced_folder "../examples", "/opt/gopath/src/github.com/hyperledger/fabric/examples", mount_options: ["dmode=777", "fmode=666"]

JonathanLevi (Fri, 31 Mar 2017 19:06:58 GMT):
---

JonathanLevi (Fri, 31 Mar 2017 19:07:25 GMT):
I think it's horrible, but that's the only way it has worked for us...

lehors (Fri, 31 Mar 2017 19:07:32 GMT):
ah

lehors (Fri, 31 Mar 2017 19:07:45 GMT):
that's easier than doing a local copy to /tmp

JonathanLevi (Fri, 31 Mar 2017 19:07:48 GMT):
Yeah, you see what I mean, right?

lehors (Fri, 31 Mar 2017 19:07:56 GMT):
which has to be done within the cli container

lehors (Fri, 31 Mar 2017 19:08:06 GMT):
totally

JonathanLevi (Fri, 31 Mar 2017 19:08:12 GMT):
Oh, of course ;-) that wasn't an option.

lehors (Fri, 31 Mar 2017 19:08:13 GMT):
that's a better workaround

lehors (Fri, 31 Mar 2017 19:08:57 GMT):
I will try that now

lehors (Fri, 31 Mar 2017 19:09:10 GMT):
sorry to hear about your condition, hope you get better soon!

JonathanLevi (Fri, 31 Mar 2017 19:09:32 GMT):
Nope, that's fine. Just apologizing for now being online earlier.

JonathanLevi (Fri, 31 Mar 2017 19:09:32 GMT):
Nope, that's fine. Just/mainly apologizing for not being online earlier.

JonathanLevi (Fri, 31 Mar 2017 19:09:54 GMT):
Now as for @Binhn's question... I have been meaning to bring that up.

JonathanLevi (Fri, 31 Mar 2017 19:09:54 GMT):
------------ Now as for @Binhn's question... I have been meaning to bring that up.

JonathanLevi (Fri, 31 Mar 2017 19:10:18 GMT):
We really need to have a "freeze" step in the process.

JonathanLevi (Fri, 31 Mar 2017 19:11:16 GMT):
I know I'm going on and on about it... but an API freeze, feature freeze, and code freeze (where we allow only show-stoppers in....), will really let us get a clear picture of where we stand.

JonathanLevi (Fri, 31 Mar 2017 19:11:16 GMT):
I know I'm going on and on about it... but an *API freeze, feature freeze*, and *code freeze* (where we allow only show-stoppers in....), will really let us get a clear picture of where we stand.

JonathanLevi (Fri, 31 Mar 2017 19:12:02 GMT):
I know that we were very busy during Feb/March, pre the alpha tag... but I think that we should really plan for it now.

JonathanLevi (Fri, 31 Mar 2017 19:12:02 GMT):
I know that we were very busy during Feb/March, prior to the alpha tag... but I think that we should really plan for it now.

lehors (Fri, 31 Mar 2017 19:12:46 GMT):
and we should plan to have the doc in sync (at least a minimum) as part of the freeze

lehors (Fri, 31 Mar 2017 19:13:04 GMT):
releasing like we just did with the getting started doc completely outdated is not good

JonathanLevi (Fri, 31 Mar 2017 19:20:02 GMT):
Yes, I agree - we can incorporate a few lessons learned - for the next round, really.

lehors (Fri, 31 Mar 2017 19:22:20 GMT):
we ought to - it's one thing to screw up it's another to repeat the same mistakes

lehors (Fri, 31 Mar 2017 19:23:17 GMT):
yeay, your vagrant trick works! good to know

JonathanLevi (Fri, 31 Mar 2017 19:23:55 GMT):
I'm happy to push this fix...

lehors (Fri, 31 Mar 2017 19:24:13 GMT):
btw, there is a new problem with the latest version of vagrant: 1.9.3

lehors (Fri, 31 Mar 2017 19:24:21 GMT):
beware

JonathanLevi (Fri, 31 Mar 2017 19:24:56 GMT):
The thing is, I'm not using vagrant at all. We have a client that runs these, and wanted to run the alpha in parallel...

lehors (Fri, 31 Mar 2017 19:25:30 GMT):
well, that's the thing, some people will want/need to use vagrant

JonathanLevi (Fri, 31 Mar 2017 19:25:30 GMT):
This is how we got into it. All I know is that I should probably never update my good ol' vagrant ;-)

JonathanLevi (Fri, 31 Mar 2017 19:25:54 GMT):
Yes, exactly. I know. Especially, btw, as the documentation "recommended" it.

lehors (Fri, 31 Mar 2017 19:26:11 GMT):
used to

JonathanLevi (Fri, 31 Mar 2017 19:26:35 GMT):
I think it's still there in some placed (that's why we had to "fix" this)

lehors (Fri, 31 Mar 2017 19:26:55 GMT):
the alternative is to make everything compile and work on Windows natively

lehors (Fri, 31 Mar 2017 19:27:05 GMT):
fabric-ca does

lehors (Fri, 31 Mar 2017 19:27:38 GMT):
I haven't tried in a while to do the same with fabric but when I tried before it was really ugly

JonathanLevi (Fri, 31 Mar 2017 19:27:54 GMT):
Honestly, I would rather have us building/running/deploying natively.

lehors (Fri, 31 Mar 2017 19:28:50 GMT):
you'd think with go it's doable but we have a lot of external dependencies that don't

lehors (Fri, 31 Mar 2017 19:28:59 GMT):
that's the problem

JonathanLevi (Fri, 31 Mar 2017 19:29:52 GMT):
You know, we talked about it the other day last week, even on the "z"s... it makes so much more sense to me, that if someone is buying/investing in such a system...they should certainly (I believe) work natively.

JonathanLevi (Fri, 31 Mar 2017 19:30:10 GMT):
Yes, it comes with a bag of ... . I know.

JonathanLevi (Fri, 31 Mar 2017 19:30:43 GMT):
But hopefully we should stabilize things, in terms of external dependencies, as time goes by - one hopes?

JonathanLevi (Fri, 31 Mar 2017 19:31:08 GMT):
We were/things were a lot more volatile back in the good ol' 0.5 days... I recall ;-)

JonathanLevi (Fri, 31 Mar 2017 19:31:58 GMT):
If people would like (or have no objection), we can explore building a few "native" binaries as part of the process.

JonathanLevi (Fri, 31 Mar 2017 19:32:14 GMT):
*Maybe not during every CI round* though! ;-)

lehors (Fri, 31 Mar 2017 19:34:30 GMT):
right :)

greg.haskins (Fri, 31 Mar 2017 20:22:35 GMT):
all maintainers: https://docs.google.com/document/d/1sAsa389InUieQ0DsnVaw9qsPAWoJKZeUwBVf6R2dCD4/edit?usp=sharing

greg.haskins (Fri, 31 Mar 2017 20:23:16 GMT):
in talking with @cbf, thought this "live document" might make the most sense to frame the conversation about how to approach managing the v1.0 release

greg.haskins (Fri, 31 Mar 2017 20:23:32 GMT):
let me know what you think, or better yet, make some edits!

cbf (Fri, 31 Mar 2017 23:20:58 GMT):
@greg.haskins thanks for kicking that off! @mastersingh24 @binhn @JonathanLevi @muralisr @jyellick @hgabre @TamasBlummer @sheehan @jimthematrix please weigh in ^^

mastersingh24 (Sat, 01 Apr 2017 11:21:35 GMT):
[ https://github.com/docker/docker/tree/master/project](https://chat.hyperledger.org/channel/fabric-maintainers?msg=hcGEsYPGcvcAvXNRf) @cbf

mastersingh24 (Sat, 01 Apr 2017 11:21:50 GMT):
I like the Docker strategy ;)

mastersingh24 (Sat, 01 Apr 2017 11:47:45 GMT):
ALSO - I think I have some type of limited admin access to JIRA, but things would be MUCH better if we had fields like "target release" available as well as always showed "fixed version" etc

mastersingh24 (Sat, 01 Apr 2017 11:48:07 GMT):
of course we would need to actually use these fields

binhn (Sat, 01 Apr 2017 14:24:50 GMT):
@mastersingh24 we could use the Label field for that "1.0.0-beta", "1.0.0"

mastersingh24 (Sat, 01 Apr 2017 14:25:53 GMT):
sure - we just need to be consistent - the field "fixed version" does exist as well

mastersingh24 (Sat, 01 Apr 2017 14:26:12 GMT):
I'm ok with using labels as long as they are applied consistently

mastersingh24 (Sat, 01 Apr 2017 14:26:32 GMT):
but frankly JIRA should have a better way to handle these things with a little customization

binhn (Sat, 01 Apr 2017 14:47:18 GMT):
it looks like i can change the "Fix Version/s:" field

rickr (Sat, 01 Apr 2017 14:59:46 GMT):
Maybe the name is bad but why do need something other than `Fix Version` ?

rickr (Sat, 01 Apr 2017 15:02:20 GMT):
I've been on projects were bug tracking endup with dozens of labels tags severity et al at the end of the day few could tell the state of releases and branches . _which maybe was the goal_ :)

mastersingh24 (Sat, 01 Apr 2017 15:41:08 GMT):
Fix Version is probably fine - I would have preferred having a "Target Version" and then you use "Fix Version" when it is complete, but I suppose a combination of "Done" and "Fix Version" would suffice

mastersingh24 (Sat, 01 Apr 2017 15:41:18 GMT):
FWIW - I've been using "Fix Version"

cbf (Sat, 01 Apr 2017 18:29:59 GMT):
there is version and fix version, IIRC... Clayton worked with Ry to add and I think I might be able to as well... None of us is JIRA maven

mastersingh24 (Sat, 01 Apr 2017 18:54:51 GMT):
we have "affected version" for bugs and then "fix version" for most other types (hopefully for all)

mastersingh24 (Sat, 01 Apr 2017 18:55:43 GMT):
we have not done a consistent job of using them in the past, but "fix version" seems to be set to "1.0.0*" for many items which is good

mihaig (Mon, 03 Apr 2017 09:21:22 GMT):
Has joined the channel.

cbf (Mon, 03 Apr 2017 15:52:57 GMT):
agreed... I just closed all of the FixVersion: WONTFIX that were for v0.6 issues

cbf (Mon, 03 Apr 2017 15:53:55 GMT):
but now we still have a bunch of issues tagged with FixVersion: v0.6 that I believe we should triage to determine valid for 1.0-alpha, and if not, should be closed as WONTFIX

cbf (Mon, 03 Apr 2017 15:54:28 GMT):
(I actually think that FixVersion should just be versions and WONTFIX should be a state == DONE

JonathanLevi (Mon, 03 Apr 2017 15:59:01 GMT):
Yes, I agree. FixVersion should be the "target" version against which the feature/story/bug is opened/resolved. WONTFIX is the state for things we agree to not fix.

JonathanLevi (Mon, 03 Apr 2017 15:59:01 GMT):
Yes, I agree. *FixVersion* should be the "target" version against which the feature/story/bug is opened/resolved. *WONTFIX* is the state for things we agree to not fix.

dave.enyeart (Mon, 03 Apr 2017 16:15:32 GMT):
Verification is failing today due to a merge this morning of changeset that conflicted with another recent merge: https://gerrit.hyperledger.org/r/#/c/7191/ I'm trying to fix in https://gerrit.hyperledger.org/r/#/c/7653, but Verification failed due to Gossip tests

dave.enyeart (Mon, 03 Apr 2017 16:16:15 GMT):
@yacovm Any idea why Gossip tests fail?

yacovm (Mon, 03 Apr 2017 16:18:45 GMT):
Yeah

yacovm (Mon, 03 Apr 2017 16:19:25 GMT):
``` 15:35:25 unit-tests_1 | fatal error: concurrent map read and map write 15:35:25 unit-tests_1 | 15:35:25 unit-tests_1 | goroutine 17962 [running]: 15:35:25 unit-tests_1 | runtime.throw(0x9fe207, 0x21) ``` It's because we have a test that sets viper properties, and gossip reads viper properties, and viper isn't thread safe

dave.enyeart (Mon, 03 Apr 2017 16:19:39 GMT):
ok, so my reverify should resolve it

yacovm (Mon, 03 Apr 2017 16:19:48 GMT):
yeah. it's a pretty rare case

yacovm (Mon, 03 Apr 2017 16:19:52 GMT):
Almost never happens

dave.enyeart (Mon, 03 Apr 2017 17:35:07 GMT):
This changeset fixes the CI verification errors that we've seen today: https://gerrit.hyperledger.org/r/#/c/7653/

dave.enyeart (Mon, 03 Apr 2017 17:54:44 GMT):
Thanks for merging quickly!

JasonD (Tue, 04 Apr 2017 02:58:46 GMT):
Has joined the channel.

pd93 (Tue, 04 Apr 2017 08:40:51 GMT):
Has joined the channel.

aguchi (Tue, 04 Apr 2017 23:55:24 GMT):
Has joined the channel.

ryokawajp (Wed, 05 Apr 2017 01:16:06 GMT):
Has joined the channel.

greg.haskins (Fri, 07 Apr 2017 13:17:47 GMT):
please weigh in on the following: https://jira.hyperledger.org/browse/FAB-2999

greg.haskins (Fri, 07 Apr 2017 13:18:16 GMT):
I've fielded many confused new users who download the project and do "make" only to be surprised

greg.haskins (Fri, 07 Apr 2017 13:18:46 GMT):
for instance, their system isnt configured to do native builds (missing deps, like libtool), or the behave tests fail

greg.haskins (Fri, 07 Apr 2017 13:19:21 GMT):
what i am suggesting is we structure the documentation and "default" mode to basically do the docker oriented flow (e.g. "make docker" is the default

greg.haskins (Fri, 07 Apr 2017 13:19:35 GMT):
we can bury the vagrant stuff in some advanced part of the doc

greg.haskins (Fri, 07 Apr 2017 13:20:19 GMT):
IOW: "Getting started" should be boiled down to "install make git golang docker && make

greg.haskins (Fri, 07 Apr 2017 13:20:26 GMT):
thoughts?

greg.haskins (Fri, 07 Apr 2017 13:20:59 GMT):
this is all part of the broader effort in https://jira.hyperledger.org/browse/FAB-1185

rickr (Fri, 07 Apr 2017 15:13:30 GMT):
Just a side comment on Vagrant. I hope we don't give on supporting it .. as much as I didn't like it initially, working down stream I have often needed to _quickly_bounce back a forth between different version of the fabric/ca and Vagrant seems the easiest way for that.

greg.haskins (Fri, 07 Apr 2017 16:16:26 GMT):
@rickr the intent is not to give up on vagrant...rather, just to recognize that the conditions that precipitated the need for a baseimage have since passed and we can maintain it as a more traditional "os-distro + provisioner" script

greg.haskins (Fri, 07 Apr 2017 16:17:03 GMT):
that, and I think we could use clarity for users on "getting started", and I think the docker flow presents fewer hurdles

greg.haskins (Fri, 07 Apr 2017 16:17:17 GMT):
so, therefore, I suggest we simplify the guides/defaults

greg.haskins (Fri, 07 Apr 2017 16:17:37 GMT):
right now, I think we have too much or "you can do this, OR this, OR this, OR this, OR this"

greg.haskins (Fri, 07 Apr 2017 16:18:33 GMT):
I suggest we simplify that to just "do this" from a "getting started" perspective, and then have a section on how to use vagrant as an alternative option

greg.haskins (Fri, 07 Apr 2017 16:28:21 GMT):
@rickr that said, note that I have a vested interest in keeping vagrant alive myself...my primary workstation is a 2009 MacPro tower, incapable of running docker-for-mac

greg.haskins (Fri, 07 Apr 2017 16:28:27 GMT):
so I rely on vagrant devenv day to day

greg.haskins (Fri, 07 Apr 2017 16:29:02 GMT):
(docker-for-mac requires 2011+ macs on account of design decisions made at the hypervisor level

greg.haskins (Fri, 07 Apr 2017 16:29:58 GMT):
bottom line: dont worry... just want to streamline (both onboarding new users, as well as myself...(maintaining the vagrant baseimage by hand is a PITA)

JonathanLevi (Fri, 07 Apr 2017 16:46:11 GMT):
Even though I am aware of some maintainers who swore to never use vagrant! I have a strong feeling that I should never upgrade that good ol' vagrant installation that I set up back in the day. Just in case ;-)

JonathanLevi (Fri, 07 Apr 2017 16:46:11 GMT):
( Even though I am aware of some maintainers who swore to never use vagrant! ) I have a strong feeling that I should never upgrade that good ol' vagrant installation that I set up back in the day. Just in case ;-)

JonathanLevi (Fri, 07 Apr 2017 16:46:11 GMT):
( Even though I am aware of some maintainers who swore to never use vagrant! ) I have a strong feeling that I, too, should never upgrade or remove that good ol' vagrant installation that I set up back in the day. Just in case ;-)

JonathanLevi (Fri, 07 Apr 2017 16:47:24 GMT):
But a smooth(er) docker based set-up might indeed be very useful on some of the "key" supported platforms.

rbuysse (Fri, 07 Apr 2017 17:23:28 GMT):
Has joined the channel.

greg.haskins (Fri, 07 Apr 2017 21:48:36 GMT):
@cbf @mastersingh24 @binhn is it known that the e2e scripts do not appear to work on the latest tree?

yacovm (Fri, 07 Apr 2017 22:36:54 GMT):
They do

greg.haskins (Sat, 08 Apr 2017 01:55:01 GMT):
perhaps I should ask a different way: how are people testing these days?

greg.haskins (Sat, 08 Apr 2017 01:55:28 GMT):
i tried to stand up a test only to have it fall over in what I assume is a lack of channel configuration

greg.haskins (Sat, 08 Apr 2017 01:55:56 GMT):
therefore, I was hoping to use the e2e_cli flow to stand up an environment that is bootstrapped with genesis+channel

greg.haskins (Sat, 08 Apr 2017 01:56:04 GMT):
however, e2e falls flat on its face

greg.haskins (Sat, 08 Apr 2017 01:56:09 GMT):
so not dead in the water

greg.haskins (Sat, 08 Apr 2017 01:56:09 GMT):
so now dead in the water

troyronda (Sat, 08 Apr 2017 02:52:17 GMT):
fyi - CI scripts are now setup for the Go SDK.

yacovm (Sat, 08 Apr 2017 07:03:01 GMT):
Greg, e2e works for me these days and today....

yacovm (Sat, 08 Apr 2017 07:03:01 GMT):
Greg, e2e works for me these days and yesterday....

matanyahu (Sat, 08 Apr 2017 19:07:13 GMT):
@greg.haskins : e2e works fine for me too without vagrant :-)

greg.haskins (Sat, 08 Apr 2017 19:34:35 GMT):
@matanyahu @yacovm I get this: https://jira.hyperledger.org/browse/FAB-3042

greg.haskins (Sat, 08 Apr 2017 19:35:21 GMT):
this happens regardless of whether I use the scripts to download the 1.0.0-alpha images, or build the images from source

yacovm (Sat, 08 Apr 2017 19:36:04 GMT):
``` Error connecting: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure Error: rpc error: code = 14 desc = grpc: RPC failed fast due to transport failure ``` This usually happens because of TLS...

yacovm (Sat, 08 Apr 2017 19:36:30 GMT):
are the peers behaving well? what do their docker logs say?

greg.haskins (Sat, 08 Apr 2017 19:39:04 GMT):
not sure, the e2e buries them

greg.haskins (Sat, 08 Apr 2017 19:39:08 GMT):
ill have to look, standby

greg.haskins (Sat, 08 Apr 2017 19:47:43 GMT):
heres one of the peers

greg.haskins (Sat, 08 Apr 2017 19:47:43 GMT):
https://pastebin.com/gCK2biWd

greg.haskins (Sat, 08 Apr 2017 19:47:50 GMT):
this was with running HEAD

greg.haskins (Sat, 08 Apr 2017 19:47:59 GMT):
I didnt capture the log with alpha, but I can

mychewcents (Sun, 09 Apr 2017 12:08:45 GMT):
Has left the channel.

cbf (Mon, 10 Apr 2017 13:13:03 GMT):
@here as we are approaching v1.0, one of the things we want to be able to do is provide automated (as much as possible) release notes. We've been a little lax in policing commit messages for JIRA items. This needs to be more ruthlessly enforced not only for the release notes, but also so that we can check the JIRA to be sure that there's agreement that it should be included in the release (now and going forward from here)

cbf (Mon, 10 Apr 2017 13:13:36 GMT):
I am tempted to see if we cannot make this an automated check as part of the git-review scripting

greg.haskins (Mon, 10 Apr 2017 13:14:23 GMT):
i am all for this @cbf, but one question about your comment above: does this predicate the use of git-review, or is this something that could be done on the gerrit backend?

greg.haskins (Mon, 10 Apr 2017 13:14:30 GMT):
i ask because, I dont use git-review

greg.haskins (Mon, 10 Apr 2017 13:14:37 GMT):
im old-school ;)

cbf (Mon, 10 Apr 2017 13:15:01 GMT):
however, in the interim, please be sure that all CRs that are +2ed have in the title of the commit message a link to the corresponding JIRA item either naked 'e.g. FAB-nnnn' or in brackets 'e.g. [FAB-nnnn]'. Thanks

cbf (Mon, 10 Apr 2017 13:15:18 GMT):
I can explore the back end

greg.haskins (Mon, 10 Apr 2017 13:15:57 GMT):
git hooks would work fine...i just dont use the git-review tooling

cbf (Mon, 10 Apr 2017 13:16:09 GMT):
@greg.haskins note that I also discovered that JIRA will compile release notes

cbf (Mon, 10 Apr 2017 13:16:14 GMT):
so we have a few options

greg.haskins (Mon, 10 Apr 2017 13:16:19 GMT):
oh, nice

JonathanLevi (Mon, 10 Apr 2017 13:17:33 GMT):
So a few steps, maybe, from the end to the beginning: 1. Gerrit CR has a JIRA ticket 2. JIRA ticket has the requirements + (Fix, or otherwise) version 3. Such JIRA tickets (say for 1.0-release) will be approved* somehow

JonathanLevi (Mon, 10 Apr 2017 13:18:06 GMT):
(by somehow, I mean, process/step is yet TBD...)

JonathanLevi (Mon, 10 Apr 2017 13:18:06 GMT):
(by somehow, I mean, process/step is yet TBD...). Does this make sense?

cbf (Mon, 10 Apr 2017 13:18:17 GMT):
@here also, on CRs that are > 300 LOC, we really need to start being a bit more ruthless as well... it simply isn't acceptable practice as it increases the blast radius of a change and obviously take longer to review properly

JonathanLevi (Mon, 10 Apr 2017 13:18:19 GMT):
Does this make sense?

cbf (Mon, 10 Apr 2017 13:18:44 GMT):
@JonathanLevi +1

cbf (Mon, 10 Apr 2017 13:19:23 GMT):
on CR size, there can obviously be exceptions

greg.haskins (Mon, 10 Apr 2017 13:19:41 GMT):
yes, I agree with this...small atomic changesets please unless there is some technical reason

cbf (Mon, 10 Apr 2017 13:19:48 GMT):
but they should be exceptional - not just whining that it is too much work to decompose a change

JonathanLevi (Mon, 10 Apr 2017 13:19:49 GMT):
Of course! It is more a general guideline. [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=WnJPhGYgLkSEhP9ow) @cbf

greg.haskins (Mon, 10 Apr 2017 13:20:19 GMT):
for instance, protobuf recompilation or tree refactor might blow out LOC but being atomic is more important

cbf (Mon, 10 Apr 2017 13:20:27 GMT):
+1

JonathanLevi (Mon, 10 Apr 2017 13:21:14 GMT):
It feels like we should be worried about the two ends of the spectrum. Too big/large will really increase the blast radius. Way too granular, with 20 dependencies.... will be at least as bad.

greg.haskins (Mon, 10 Apr 2017 13:21:25 GMT):
im not sure how the git-review flow works, but I use stgit back from when I used to do kernel work...it makes it very easy to manage a stack of small changes

JonathanLevi (Mon, 10 Apr 2017 13:21:47 GMT):
@greg.haskins: the *pb* is a `great` example for an exception. I completely agree.

greg.haskins (Mon, 10 Apr 2017 13:22:07 GMT):
@JonathanLevi if done right, i dont think the small-atomic series is hard to manage

greg.haskins (Mon, 10 Apr 2017 13:22:12 GMT):
ive been doing it for years

greg.haskins (Mon, 10 Apr 2017 13:22:36 GMT):
its never a case that you have deps all over the place..its always linear

JonathanLevi (Mon, 10 Apr 2017 13:22:38 GMT):
As long as we can underline the `if done right`... I am with you.

greg.haskins (Mon, 10 Apr 2017 13:22:43 GMT):
hehe, yes

greg.haskins (Mon, 10 Apr 2017 13:23:07 GMT):
the most important thing, imo, is to develop the code this way

greg.haskins (Mon, 10 Apr 2017 13:23:16 GMT):
dont create a megapatch and then try to break it up

JonathanLevi (Mon, 10 Apr 2017 13:23:33 GMT):
Don't know if you guys saw what happened last week in fabric-ca... where we ended up with a huge dependency trail, that was not really linear and actually added more overhead.

JonathanLevi (Mon, 10 Apr 2017 13:23:56 GMT):
@greg.haskins: I also think that it's easier to also "think" this way.

greg.haskins (Mon, 10 Apr 2017 13:24:06 GMT):
right

JonathanLevi (Mon, 10 Apr 2017 13:24:10 GMT):
Step1, test, merge

JonathanLevi (Mon, 10 Apr 2017 13:24:14 GMT):
Step2, test, merge

JonathanLevi (Mon, 10 Apr 2017 13:24:15 GMT):
Etc.

greg.haskins (Mon, 10 Apr 2017 13:24:37 GMT):
it doesnt even have to be gated on "merge"

JonathanLevi (Mon, 10 Apr 2017 13:24:40 GMT):
Utilizing (what we used-to-call) the "overnight" testing... of the integration as well.

greg.haskins (Mon, 10 Apr 2017 13:24:46 GMT):
this is my tree for example

greg.haskins (Mon, 10 Apr 2017 13:25:01 GMT):
```$ stg series - minimize-thirdparty-containers - fab-1185-remove-reliance-on - fab-2865-set-the-chaincode - fab-2984-use-testenv-for-cli - fab-2493-package-up-golang - add-support-for-docker_ns - chaincode-proto-overhaul - disable-devmode-in-compose - converge-deployment-spec - upgrade-to-chaincode-v0-10-3 - consolidate-ccenv - fab-678-pull-missing-images - do-not-commit - version-2-compose```

JonathanLevi (Mon, 10 Apr 2017 13:25:17 GMT):
I love the `do-not-commit` ! ;-)

greg.haskins (Mon, 10 Apr 2017 13:25:22 GMT):
so the first 5 are patches I am currently upstreaming....the othes arent ready yet

JonathanLevi (Mon, 10 Apr 2017 13:25:38 GMT):
Nice, yes, I see.

greg.haskins (Mon, 10 Apr 2017 13:25:57 GMT):
so at any given point in time, I might have 5-15 patches in queue, but I might be only actively proposing 2-5 of them on gerrit

greg.haskins (Mon, 10 Apr 2017 13:26:21 GMT):
heh, yeah, thats usually where I add my debug hacks

greg.haskins (Mon, 10 Apr 2017 13:26:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=PBD27BQvzsa9Guy7C) @JonathanLevi heh, yeah, thats usually where I add my debug hacks

JonathanLevi (Mon, 10 Apr 2017 13:27:44 GMT):
Yes, the more sophisticated *.gitignore* ;-)

greg.haskins (Mon, 10 Apr 2017 13:28:02 GMT):
anyway, the main point is: I am always working in a patch stream and then pushing the ones that are ready...not doing a bunch of work and then trying to break it up for review/inclusion

greg.haskins (Mon, 10 Apr 2017 13:28:43 GMT):
i would advocate this as a sane way to achieve the end result @cbf is looking for

JonathanLevi (Mon, 10 Apr 2017 13:29:26 GMT):
I agree, but I'm not (yet) entirely sure how we should express/formulate this.

JonathanLevi (Mon, 10 Apr 2017 13:29:36 GMT):
I will show you an example of what I mean.

greg.haskins (Mon, 10 Apr 2017 13:29:38 GMT):
same here

JonathanLevi (Mon, 10 Apr 2017 13:29:47 GMT):

Message Attachments

JonathanLevi (Mon, 10 Apr 2017 13:30:17 GMT):
(of course, this is not fully anonymized.... but the point here, is *not* to bash the submitter)

JonathanLevi (Mon, 10 Apr 2017 13:30:17 GMT):
(of course, this is not fully anonymized.... but the point here, is *not* to bash the submitter - but rather to think about how we express the guidelines, so that it is clearer to committers/submitters)

JonathanLevi (Mon, 10 Apr 2017 13:30:40 GMT):
This started as a very large CR, that Chris wanted broken down.

JonathanLevi (Mon, 10 Apr 2017 13:31:11 GMT):
It is broken down.... but ended up being much more work, for the reviewers (and the committers)

JonathanLevi (Mon, 10 Apr 2017 13:31:11 GMT):
It is broken down (to very/too many small CRs) and ended up being much more work, for the reviewers (and the committer, probably)

greg.haskins (Mon, 10 Apr 2017 13:31:16 GMT):
i dont know the details here, but im guessing part of the problem that this is not really a logical series of small atomic changes, but rather a retroactive split of one very large atomic change

JonathanLevi (Mon, 10 Apr 2017 13:31:27 GMT):
EXACTLY.

JonathanLevi (Mon, 10 Apr 2017 13:31:38 GMT):
That's why I put the "merge" step there.

cbf (Mon, 10 Apr 2017 13:31:42 GMT):
so they should not have been submitted as a stack

greg.haskins (Mon, 10 Apr 2017 13:31:47 GMT):
and it comes back to: dont try to retroactive splot

greg.haskins (Mon, 10 Apr 2017 13:31:52 GMT):
split

cbf (Mon, 10 Apr 2017 13:31:55 GMT):
if a bug fix is independent, submit independently

greg.haskins (Mon, 10 Apr 2017 13:32:02 GMT):
exactly

cbf (Mon, 10 Apr 2017 13:32:09 GMT):
not rocket science

JonathanLevi (Mon, 10 Apr 2017 13:32:10 GMT):
Yup, they should have been split into the groups/buckets of dependencies...

greg.haskins (Mon, 10 Apr 2017 13:32:40 GMT):
i really dont like it described as "dependencies" though..it implies a graph

JonathanLevi (Mon, 10 Apr 2017 13:32:45 GMT):
@cbf, I agree. Maximize independencies, while keeping the size reasonable.

JonathanLevi (Mon, 10 Apr 2017 13:32:45 GMT):
@cbf, I agree. Maximize independencies (minimize dependencies - or however we want to "term" this), while keeping the size reasonable.

greg.haskins (Mon, 10 Apr 2017 13:32:51 GMT):
if done right, its linear

JonathanLevi (Mon, 10 Apr 2017 13:33:00 GMT):
If done right - it's linear.

greg.haskins (Mon, 10 Apr 2017 13:33:51 GMT):
and btw: this isnt to imply I get the granularity right every single time...i often have to go back and tease out a small part that should be done on its own

greg.haskins (Mon, 10 Apr 2017 13:34:08 GMT):
but the main point is: tease out independent changes early

greg.haskins (Mon, 10 Apr 2017 13:34:22 GMT):
develop it as a series from the beginning

greg.haskins (Mon, 10 Apr 2017 13:34:41 GMT):
then, I think everything else naturally falls into place in a manner that @cbf is looking for

greg.haskins (Mon, 10 Apr 2017 13:35:36 GMT):
the criteria I apply is: if someone randomly git-bisected to this patch, would the tree make sense (and would it build, pass tests, etc)

JonathanLevi (Mon, 10 Apr 2017 13:39:54 GMT):
So, here is one thing that is consistent with the way you @cbf, @greg.haskins (and also @mastersingh24, @jyellick, ...) think and work (and I'm trying to give you a "by-stander" perspective...):

JonathanLevi (Mon, 10 Apr 2017 13:40:13 GMT):
*You get the requirements-analysis step right*

JonathanLevi (Mon, 10 Apr 2017 13:40:27 GMT):
I believe that this is actually the key.

JonathanLevi (Mon, 10 Apr 2017 13:41:25 GMT):
When you know what the "feature" should do, and really understand it - it is a lot easier to model it, and break it down to parts - that you can develop and apply as a series...

JonathanLevi (Mon, 10 Apr 2017 13:41:41 GMT):
... while not forgetting "where you want to be".

JonathanLevi (Mon, 10 Apr 2017 13:42:41 GMT):
That is, whether it is 2 patchsets or 5.... it is clear, even without all the implementation details in advance: *what the thing should do*.

JonathanLevi (Mon, 10 Apr 2017 13:43:04 GMT):
If this step is done right, then indeed, things fall into place.

JonathanLevi (Mon, 10 Apr 2017 13:43:19 GMT):
If you start with "Oh, I need to change the config file"

JonathanLevi (Mon, 10 Apr 2017 13:43:19 GMT):
If you/one/someone starts with only - "Oh, I need to change the config file", `adding it, will solve everything`. - Easy, *git commit, git push*. - "OMG, forgot to open a JIRA ticket". Damn it! Open ticket: "[FAB-1111] Add xParam to config file" Desc: `adding it, will solve everything.`

JonathanLevi (Mon, 10 Apr 2017 13:43:42 GMT):
"Maybe I should add this parameter, xParam"

JonathanLevi (Mon, 10 Apr 2017 13:43:57 GMT):
"oh, sorry, the SDK does not have that value"

JonathanLevi (Mon, 10 Apr 2017 13:44:15 GMT):
"right, as small patch, to have the SDK calling it with a default value"

JonathanLevi (Mon, 10 Apr 2017 13:44:31 GMT):
"OMG, Gossip needed the other value", please can we merge this

JonathanLevi (Mon, 10 Apr 2017 13:44:55 GMT):
Hold on, BCCSP now needs some MSP that is respects that xParam...

JonathanLevi (Mon, 10 Apr 2017 13:44:55 GMT):
Hold on, BCCSP now needs some value that the MSP should have now that that xParam value was set to "XYZ".

JonathanLevi (Mon, 10 Apr 2017 13:44:59 GMT):
....

JonathanLevi (Mon, 10 Apr 2017 13:45:38 GMT):
And the whole workflow is getting these circular dependencies with patches over patches, that are very difficult to coherently review.

JonathanLevi (Mon, 10 Apr 2017 13:47:30 GMT):
--- Which brings me to suggest that we have more of the discussions at the JIRA ticket (stage/step/realm), and help ourselves/contributors agree/disagree/discuss at a much earlier stage, before we even get to the code/gerrit submission(s)/reviews.

JonathanLevi (Mon, 10 Apr 2017 13:47:55 GMT):
--- Which brings me to suggest that we should have more of the discussions at the JIRA ticket (stage/step/realm), and help ourselves/contributors agree/disagree/discuss at a much earlier stage, before we even get to the code/gerrit submission(s)/reviews.

JonathanLevi (Mon, 10 Apr 2017 13:48:22 GMT):
This way, I believe that we can also *help* others to work closer to the way you @greg.haskins (and @cbf) suggest/recommend.

JonathanLevi (Mon, 10 Apr 2017 13:49:38 GMT):
Sorry if this is a longer version of `+1` ;-) but I'm trying to (also) think-out-loud about what cause these symptoms that we are trying to help avoiding...

JonathanLevi (Mon, 10 Apr 2017 13:49:38 GMT):
Sorry if this is a longer version of `+1` ;-) but I'm trying to (also) think-out-loud about what causes these symptoms that we are trying to help avoiding... such as them HUGE CRs, less granular, so that people indeed, *tease out independent changes early*...

JonathanLevi (Mon, 10 Apr 2017 13:49:38 GMT):
Sorry if this is a longer version of `+1` ;-) but I'm trying to (also) think-out-loud about what causes these symptoms that we are trying to help avoiding... such as them HUGE CRs that are less granular, so that people indeed, *tease out independent changes early*...

aso (Mon, 10 Apr 2017 13:55:56 GMT):
Has joined the channel.

zian (Mon, 10 Apr 2017 13:59:25 GMT):
Has joined the channel.

cbf (Mon, 10 Apr 2017 14:04:52 GMT):
I certainly think that we need more maintainer control over JIRA

cbf (Mon, 10 Apr 2017 14:05:31 GMT):
we could start with Epics and aside from bug fixes, stories should relate to an Epic etc

JonathanLevi (Mon, 10 Apr 2017 14:37:10 GMT):
Yes, I'm down for it too. It will be a bit more work/head-ache in the short-term (cleaning it up first, etc.)... but it's probably well worth it, in the longer run.

rjones (Mon, 10 Apr 2017 15:12:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Jm2Z9nXjE8Lre4bHP) @cbf I would love to devolve control of JIRA to maintainers

cbf (Mon, 10 Apr 2017 16:11:34 GMT):
@JonathanLevi the cleanup has been on-going for a number of days

cbf (Mon, 10 Apr 2017 16:11:43 GMT):
still much to be done

cbf (Mon, 10 Apr 2017 16:12:15 GMT):
and we are (IMNSHO) no closer to "these stories must be completed for us to declare code-complete for v1.0"

cbf (Mon, 10 Apr 2017 18:46:45 GMT):
so, @JonathanLevi @mastersingh24 @greg.haskins @sheehan @binhn @jimthematrix @yacovm @jyellick @hgabre @muralisr @tamas Gari and I feel strongly that we should not be merging new function until we settle the release process. Bug fixes and additional tests are fine. Optimization is not a bug fix

cbf (Mon, 10 Apr 2017 18:47:19 GMT):
there are very few items in flight and we will try to identify which JIRAs they are so we can carefully track

greg.haskins (Mon, 10 Apr 2017 18:47:27 GMT):
some stablization would be welcome

cbf (Mon, 10 Apr 2017 18:47:32 GMT):
amen

cbf (Mon, 10 Apr 2017 18:48:15 GMT):
we can discuss creating a release branch (as we have been in the google doc) but let's hold off until we know what we have

cbf (Mon, 10 Apr 2017 18:48:41 GMT):
and sort out the process (eg do we merge fixes to master or release nd then cherrypick?

cbf (Mon, 10 Apr 2017 18:50:39 GMT):
this guidance applies to fabric, fabric-ca, and fabric-sdk-node

binhn (Mon, 10 Apr 2017 19:04:00 GMT):
we need to get a few more in otherwise things are not operational, including cc install packaging, config update, and ACL -- these have been submitted and in various state of review

mastersingh24 (Mon, 10 Apr 2017 19:08:34 GMT):
we need the config stuff for sure

vdods (Mon, 10 Apr 2017 19:32:33 GMT):
Has joined the channel.

greg.haskins (Mon, 10 Apr 2017 20:22:27 GMT):
I think whatever approach we adopt, cherry-pick should be an exception not a rule

greg.haskins (Mon, 10 Apr 2017 20:23:17 GMT):
e.g. either we dont branch until we cut 1.0, or we branch 1.0 and automate merges from 1.0 to master

greg.haskins (Mon, 10 Apr 2017 20:23:46 GMT):
cherry-pick would only be used when something that was targeted at master but deemed in retrospect as appropriate for 1.0

greg.haskins (Mon, 10 Apr 2017 20:23:54 GMT):
but this should be rare

shanlusun (Tue, 11 Apr 2017 02:23:30 GMT):
Has joined the channel.

baohua (Tue, 11 Apr 2017 07:11:28 GMT):
Has joined the channel.

cbf (Tue, 11 Apr 2017 15:45:32 GMT):
@here I sent a lengthy email on the release approach discussion to the hyperledger-fabric list - please weigh in

JonathanLevi (Tue, 11 Apr 2017 18:05:05 GMT):
https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-April/000725.html

JonathanLevi (Tue, 11 Apr 2017 18:05:05 GMT):
Here is that email, FWIW: https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-April/000725.html

cbf (Tue, 11 Apr 2017 19:13:31 GMT):
thx

Lin-YiTang (Tue, 11 Apr 2017 21:18:27 GMT):
Has joined the channel.

weeds (Wed, 12 Apr 2017 14:25:54 GMT):
fyi- we invited people to join our scrum today and took notes on fabric-peer-endorser-comitter channel

kelvinzhong (Thu, 13 Apr 2017 08:27:34 GMT):
Has joined the channel.

JonathanLevi (Fri, 14 Apr 2017 18:19:58 GMT):
Hello fella maintainers, We really need to make a call regarding whether we should cut another branch soon. Please see my questions here: https://chat.hyperledger.org/channel/fabric-release?msg=AbTncx9op7ie7K95t , until here: https://chat.hyperledger.org/channel/fabric-release?msg=FJkzZtjpJDDXkyuej

JonathanLevi (Fri, 14 Apr 2017 18:21:59 GMT):
I wanted to collect all the feedback from Troy and see who else may be interested in focusing on the next fabric version, with features that are not part of `fabric 1.0` in the coming weeks.

JonathanLevi (Fri, 14 Apr 2017 18:23:26 GMT):
While I know that @binhn suggested to hold off the `2 branches` work for 2 weeks - I feel that if no maintainer objects - we should all work on `master` in the coming `4` weeks actually.

JonathanLevi (Fri, 14 Apr 2017 18:23:26 GMT):
While I know that @binhn suggested to hold off the `2 branches` work for 2 weeks (that was during Sprint 16) - I feel that if no maintainer objects - we should all work on `master` in the coming `4` weeks actually.

JonathanLevi (Fri, 14 Apr 2017 18:23:26 GMT):
While I know that @binhn suggested to hold off the `2 branches` work at least for 2 weeks (that was during Sprint 16) - I feel that if no maintainer objects - we should all work on `master` in the coming `4` (if not `6`) weeks actually.

JonathanLevi (Fri, 14 Apr 2017 18:24:41 GMT):
We can of course vote - but as it stands, no for 2 weeks, I haven't heard/read any maintainer (so far) that suggested working in parallel on 1.0 and 1.1 (in the coming, say 4-6 weeks).

JonathanLevi (Fri, 14 Apr 2017 18:24:41 GMT):
We can of course vote - but as it stands, now for about 2 weeks, I haven't heard/read any maintainer (so far) that suggested working in parallel on 1.0 and 1.1 (in the coming, say 4-6 weeks).

JonathanLevi (Fri, 14 Apr 2017 18:26:34 GMT):
I can't tell if we are all simply traumatized from the issues we had with the `0.6` -> `1.0` work... or whether each of us is aware of enough issues and work that is still needed in `1.0`, for it to serve as a better `baseline for 1.1`.

JonathanLevi (Fri, 14 Apr 2017 18:27:55 GMT):
My guess is probably the latter, but please chime in if you know anyone else *who else wants/needs/plans on working on features that he believes should be part of `fabric 1.1` and not part of `fabric 1.0` in the coming 4-6 weeks?*

JonathanLevi (Fri, 14 Apr 2017 18:27:55 GMT):
My guess is probably the latter, but please chime in if you know *who else wants/needs/plans on working on features that he believes should be part of `fabric 1.1` and not part of `fabric 1.0` in the coming 4-6 weeks?*

JonathanLevi (Fri, 14 Apr 2017 18:28:43 GMT):
My guess is probably the latter, but please chime in if you know *who else wants/needs/plans on working on features that he believes should be part of `fabric 1.1` and not part of `fabric 1.0` in the coming 4-6 weeks?*

JonathanLevi (Fri, 14 Apr 2017 18:32:34 GMT):
We really need to make a call regarding whether we should cut another branch soon. Please see my questions here: https://chat.hyperledger.org/channel/fabric-release?msg=AbTncx9op7ie7K95t

JonathanLevi (Fri, 14 Apr 2017 18:32:43 GMT):
https://chat.hyperledger.org/channel/fabric-release?msg=FJkzZtjpJDDXkyuej

greg.haskins (Fri, 14 Apr 2017 19:48:58 GMT):
my take is, while there is plenty of interesting things to consider beyond 1.0, having the system be stable and usable is far more important (to me and my team) right now

greg.haskins (Fri, 14 Apr 2017 19:49:40 GMT):
so, i would love to focus on exciting new stuff, but if 1.0 doesnt become viable for deployment none of that will matter

greg.haskins (Fri, 14 Apr 2017 19:50:32 GMT):
therefore my energy will be focused on 1.0

muralisr (Fri, 14 Apr 2017 23:44:15 GMT):
if I may add one thing @greg.haskins ... `stable and usable` - usable includes doc and examples

greg.haskins (Fri, 14 Apr 2017 23:45:56 GMT):
Yep, I agree

greg.haskins (Fri, 14 Apr 2017 23:46:06 GMT):
and tests passing

muralisr (Fri, 14 Apr 2017 23:50:29 GMT):
and tests passing

binhn (Sat, 15 Apr 2017 14:39:35 GMT):
@JonathanLevi my pref is 2 weeks at a time; and toward the end of the second week, we know whether we're there or not to decide on branch. I agreed with @greg.haskins @cbf @many-others to focus on 1.0

weeds (Mon, 17 Apr 2017 14:11:14 GMT):
we are doing peer scrum right now and took notes on fabric-peer-endorser-committer channel... there is one deicision to be made relative to Java SDK

weeds (Mon, 17 Apr 2017 14:11:19 GMT):
that Jim will post here

mffrench (Mon, 17 Apr 2017 16:32:30 GMT):
Has joined the channel.

mffrench (Mon, 17 Apr 2017 16:39:51 GMT):
Hi there, I'd like to add the configtxgen binary inside peer and orderer containers (I can push some code to review on gerrit for that). So this is a small improvement request which seems to me too small to be treated through the fabric requirements pipeline (requirements-wg) and I was thinking this could be considered like a bug - ie: I can open directly a JIRA ticket for it. Can someone tell me a little more when we have to follow the fabric requirements pipeline and when we can open a direct JIRA ticket ?

JonathanLevi (Mon, 17 Apr 2017 17:33:22 GMT):
Hello Mathilde! ;-) It's not really the right channel for it. #fabric is probably better. Please open a ticket at jira.hyperledger.org, and we (the maintainers, but no just) can (and will) look into it...

JonathanLevi (Mon, 17 Apr 2017 17:33:22 GMT):
Hello Mathilde! ;-) This not really the right channel for it. #fabric is probably better. But sure, please can you open a ticket at jira.hyperledger.org with more details, and we (the maintainers, but not just/only) can (and will) look into it...

JonathanLevi (Mon, 17 Apr 2017 17:34:09 GMT):
While we are working on hardening/solidifying the 1.0 release, if it is a bug - then we may include it.

yacovm (Mon, 17 Apr 2017 17:37:02 GMT):
I don't think it's a request that is too small to be included. We're talking about changing the docker image of the peer and the ordering service

JonathanLevi (Mon, 17 Apr 2017 17:37:18 GMT):
While we are working on hardening/solidifying the 1.0 release, if it is a bug - then we may include it - whether it will get into 1.0 or 1.1 - contributions are really welcome, so thanks in advance!

JonathanLevi (Mon, 17 Apr 2017 17:37:18 GMT):
While we are working on hardening/solidifying the 1.0 release, if it is a bug - then we may include/merge it even now. That said, whether it will get into 1.0 or 1.1 in one form or another - contributions are really welcome, so thanks in advance! (no commitment but will be happy to assist with the "leg work", prioritization, discussions, etc.) @mffrench

mffrench (Mon, 17 Apr 2017 19:01:53 GMT):
Hello @JonathanLevi , thank you for this answer... :)

elli-androulaki (Tue, 18 Apr 2017 19:14:45 GMT):
Hi, could one take a look at this one? https://gerrit.hyperledger.org/r/#/c/6279/

rjones (Tue, 18 Apr 2017 19:17:11 GMT):
@elli-androulaki please ask in #fabric-pr-review thank you :)

elli-androulaki (Tue, 18 Apr 2017 19:18:25 GMT):
Oops, will do. Thanks!

dhuseby (Tue, 18 Apr 2017 20:23:36 GMT):
Has joined the channel.

greg.haskins (Tue, 18 Apr 2017 20:33:16 GMT):
is anyone working on cryptogen atm?

greg.haskins (Tue, 18 Apr 2017 20:33:40 GMT):
ive found a problem and I think I understand what the solution is, but I dont want to duplicate efforts

weeds (Wed, 19 Apr 2017 13:01:44 GMT):
please note that we will have scrum call at 9:30 AM EST 1-888-426-6840 / 33682113)

weeds (Wed, 19 Apr 2017 13:02:02 GMT):
I think in the call people wanted to go through JIRa items the thought needed to get into release as an FYI where maintainers may have comments

weeds (Wed, 19 Apr 2017 14:37:05 GMT):
for awareness- there may need to be some comments on what I posted on peer-endorser-comitter- but highlighted mastersing24 name at those points since could not get all maintainers out fast in my typing

weeds (Wed, 19 Apr 2017 14:40:45 GMT):
so places where i pust mastersingh24 name may need comments from maintainers

cbf (Wed, 19 Apr 2017 15:25:38 GMT):
@mastersingh24 @jyellick @sheehan @tamas @hgabre @muralisr @binhn @JonathanLevi @greg.haskins @yacovm @jimthematrix https://gerrit.hyperledger.org/r/#/c/8235/

cbf (Wed, 19 Apr 2017 15:25:54 GMT):
I've nominated @kostas to be Fabric maintainer

elli-androulaki (Wed, 19 Apr 2017 15:47:01 GMT):
@cbf, may you take another look at this one ? https://gerrit.hyperledger.org/r/#/c/7853/ @aso seems to have addressed your comment!

elli-androulaki (Wed, 19 Apr 2017 15:47:01 GMT):
@cbf, may you take another look at this one ? https://gerrit.hyperledger.org/r/#/c/7853/ @aso seems to have addressed your comment! Thanks

binhn (Wed, 19 Apr 2017 17:46:36 GMT):
hi folks, I noticed the post from golang 1.7 refresh "go1.7.5 (released 2017/01/26) includes fixes to the compiler, runtime, and the crypto/x509 and time packages." that seems important for us, especially crypto/x509

binhn (Wed, 19 Apr 2017 17:46:59 GMT):
I propose we update our golang version to 1.7.5

greg.haskins (Wed, 19 Apr 2017 19:01:08 GMT):
@binhn fine by me...if someone can push a CR to baseimage, ill include it with the next drop

binhn (Wed, 19 Apr 2017 19:06:33 GMT):
@greg.haskins i don't remember what needs to be changed? i did a search and found devenv/setup.sh is already at 1.7.5

binhn (Wed, 19 Apr 2017 19:07:20 GMT):
and vagrantfile is `Vagrant.require_version ">= 1.7.4"`

greg.haskins (Wed, 19 Apr 2017 19:08:05 GMT):
note that vagrantfile version is unrelated

tkuhrt (Wed, 19 Apr 2017 19:09:01 GMT):
Has joined the channel.

greg.haskins (Wed, 19 Apr 2017 19:09:02 GMT):
this is what is used in baseos/baseimage: https://github.com/hyperledger/fabric-baseimage/blob/master/scripts/common/setup.sh#L31

greg.haskins (Wed, 19 Apr 2017 19:09:29 GMT):
which ultimately is what is used in anything in docker (including chaincode)

JonathanLevi (Wed, 19 Apr 2017 19:55:18 GMT):
BTW: How do we feel with Go 1.8?

JonathanLevi (Wed, 19 Apr 2017 19:55:18 GMT):
BTW: How do we feel wrt Go 1.8?

JonathanLevi (Wed, 19 Apr 2017 19:55:47 GMT):
We still have a few months until the end of June...

binhn (Wed, 19 Apr 2017 20:32:55 GMT):
@greg.haskins ok, i'll submit a CR

binhn (Wed, 19 Apr 2017 20:33:49 GMT):
@JonathanLevi i haven't read up the changes on 1.8, but i know 1 thing that we want to exploit is the pluggable module

yacovm (Wed, 19 Apr 2017 20:35:34 GMT):
What about vendor folders of gRPC implementation and protobuf ? ours are pretty old from what I know

greg.haskins (Wed, 19 Apr 2017 20:36:23 GMT):
@JonathanLevi IIRC, there was a compatibility issue with go 1.8

kostas (Wed, 19 Apr 2017 20:36:52 GMT):
1.8.1 is out

kostas (Wed, 19 Apr 2017 20:36:52 GMT):
1.8.1 is out FYI

greg.haskins (Wed, 19 Apr 2017 20:36:53 GMT):
someone tried it ( @yacovm ?) and there were errors

cbf (Wed, 19 Apr 2017 21:02:42 GMT):
congrats @kostas!

cbf (Wed, 19 Apr 2017 21:02:44 GMT):
https://gerrit.hyperledger.org/r/#/c/8235/

yacovm (Wed, 19 Apr 2017 21:04:24 GMT):
@greg.haskins what do you mean?

greg.haskins (Wed, 19 Apr 2017 21:06:10 GMT):
someone tried upgrading golang to v1.8 and fabric had issues compiling with it

greg.haskins (Wed, 19 Apr 2017 21:06:10 GMT):
@yacovm someone tried upgrading golang to v1.8 and fabric had issues compiling with it

greg.haskins (Wed, 19 Apr 2017 21:06:16 GMT):
i thought it might have been you, but maybe not

greg.haskins (Wed, 19 Apr 2017 21:06:23 GMT):
@kostas perhaps?

yacovm (Wed, 19 Apr 2017 21:07:32 GMT):
no, I tried upgrading the gRPC version but ran into problems and didn't have time to resolve them

kostas (Wed, 19 Apr 2017 21:29:19 GMT):
@cbf: Thank you!

kostas (Wed, 19 Apr 2017 21:29:25 GMT):
@greg.haskins: Go 1.8 wouldn't play nicely out of the box for those of us on a Mac w/ anything Go-related, not Fabric in particular (see: https://chat.hyperledger.org/channel/fabric-maintainers?msg=u37mzqpRLEg6BpYau). But 1.8.1 takes care of that.

greg.haskins (Wed, 19 Apr 2017 21:29:44 GMT):
@kostas ah, ok

greg.haskins (Wed, 19 Apr 2017 21:29:46 GMT):
thats good news

mastersingh24 (Wed, 19 Apr 2017 21:49:37 GMT):
there are also tests that fail under Go 1.8 - they once again changed how strict they are about checking certificates for usage extensions and other things (and changed some of the errors)

mastersingh24 (Thu, 20 Apr 2017 13:09:18 GMT):
folks - https://gerrit.hyperledger.org/r/#/c/8301/ - clearly I missed this in JIRA as part of the sprint, but I gave it a -2 because I don't think we should be doing this now (or maybe ever). But wanted to throw this out to see what others think

yacovm (Thu, 20 Apr 2017 13:12:30 GMT):
So, what is the benefit of customizable hash function?

mastersingh24 (Thu, 20 Apr 2017 13:18:44 GMT):
the ONLY benefit I see for the internal stuff is if there was some standard change or government industry requirement

mastersingh24 (Thu, 20 Apr 2017 13:19:24 GMT):
I just think adding yet another config option to an already complex beast spells trouble

yacovm (Thu, 20 Apr 2017 13:23:29 GMT):
but - if there is such a requirement, IMO then we need to have a hardcoded *constant( in the code for that, and then we can simply use that

yacovm (Thu, 20 Apr 2017 13:23:29 GMT):
but - if there is such a requirement, IMO then we need to have a hardcoded *constant* in the code for that, and then we can simply use that

yacovm (Thu, 20 Apr 2017 13:24:16 GMT):
but specifying such stuff in a configuration file - might make it that clients would change that and then no hash verification would work

yacovm (Thu, 20 Apr 2017 13:24:16 GMT):
but specifying such stuff in a configuration file - might make it that clients would change that and then no hash verification would work (across peers)

JonathanLevi (Thu, 20 Apr 2017 15:59:20 GMT):
I agree. Let's see/address if & when such requirement comes up.

JonathanLevi (Thu, 20 Apr 2017 16:00:07 GMT):
I believe that simplified configurations, especially for the crypto/integration, should be a/our priority these days (, or, coming weeks, to be more precise).

JonathanLevi (Thu, 20 Apr 2017 16:00:07 GMT):
In general, I believe that simplified configurations, especially for the crypto/integration, should be a/our priority these days (, or, coming weeks, to be more precise). My 2 cents.

yacovm (Thu, 20 Apr 2017 16:03:01 GMT):
The problem is that if you use a different hash there is no way of knowing that someone else uses a different hash because I don't think we write the hash algo anywhere, do we?

dave.enyeart (Thu, 20 Apr 2017 16:10:32 GMT):
Sorry to post here, but I'm not getting any action in fabric-pr-review. Need to highlight the concern to the maintainers:

dave.enyeart (Thu, 20 Apr 2017 16:10:42 GMT):
Still need reviews for these aging ledger items. They have been out there for review for a couple weeks. They have been peer reviewed, under the recommended lines of code, tested end-to-end, and rebased to ensure they are still valid. Please help! https://gerrit.hyperledger.org/r/#/c/7687 Switch QueryResult to protobuf to enable java chaincode https://gerrit.hyperledger.org/r/#/c/7787 Switch gob encoding to enable java chaincode https://gerrit.hyperledger.org/r/#/c/7255 Fix chaincode result set paging https://gerrit.hyperledger.org/r/#/c/7099 Provide CouchDB default config (security) https://gerrit.hyperledger.org/r/#/c/6793 Benchmark test framework for ledger (large… but it’s a test harness not production code) https://gerrit.hyperledger.org/r/#/c/7975 Create CouchDB system databases https://gerrit.hyperledger.org/r/#/c/8139 History enablement in core.yaml

JonathanLevi (Thu, 20 Apr 2017 16:14:01 GMT):
Thank you @dave.enyeart, we'll (jointly) try to unblock you today...

dave.enyeart (Thu, 20 Apr 2017 16:14:10 GMT):
thx much!

JonathanLevi (Thu, 20 Apr 2017 16:15:01 GMT):
@yacovm: Yes, that would be a big change...

yacovm (Fri, 21 Apr 2017 07:57:08 GMT):
end-to-end is currently broken due to access control in system chaincode doing its job https://gerrit.hyperledger.org/r/#/c/8343 Can anyone please merge?

yacovm (Fri, 21 Apr 2017 08:11:36 GMT):
@jimthematrix I guess that also effects the node-sdk tests (are they passing now? I don't remember what is the status of them). Should we change the PEM material there too, or are they already admins?

yacovm (Fri, 21 Apr 2017 11:01:32 GMT):
The e2e_cli joins a channel by iterating over all peer numbers from 0 to 3. The patch that @adc pushed made all 4 peers org admins. I think it's better to have only 2 peers admins and have the script only use join channel with admin of org0 and admin of org1 *while at the same time* using invoke/query with other peer signing identities, in order to be sure that we do not use *over privileged* credentials when we don't need to (because this can mask bugs related to policies) What do you think?

yacovm (Fri, 21 Apr 2017 11:01:32 GMT):
The e2e_cli joins a channel by iterating over all peer numbers from 0 to 3. The patch that @adc pushed made all 4 peers org admins (otherwise, the e2e fails) I think it's better to have only 2 peers admins and have the script only use join channel with admin of org0 and admin of org1 *while at the same time* using invoke/query with other peer signing identities, in order to be sure that we do not use *over privileged* credentials when we don't need to (because this can mask bugs related to policies) What do you think?

adc (Fri, 21 Apr 2017 12:04:34 GMT):
it makes sense to me. This will require then to have the signing keys of the administrator available

yacovm (Fri, 21 Apr 2017 12:10:23 GMT):
no, it won't. All I'm saying is to fine-grain the usage of peer signing identities - use only admin signing identity for "privileged" operations, and use non-admin peer signing identities for other

greg.haskins (Fri, 21 Apr 2017 12:11:35 GMT):
I have two comments

greg.haskins (Fri, 21 Apr 2017 12:12:36 GMT):
1) perhaps this should be modeled similarly to how cryptogen handles it: that is, make an independent Admin credential that is separate from the peers and use that

greg.haskins (Fri, 21 Apr 2017 12:13:24 GMT):
2) This system of granting entitlements via local directory hierarchy strikes me as an odd design

greg.haskins (Fri, 21 Apr 2017 12:13:59 GMT):
for instance, how is this expected to be managed over time w.r.t. provision/deprovision

greg.haskins (Fri, 21 Apr 2017 12:15:18 GMT):
what strikes me as particularly odd is that its in the context of "member services" to begin with. Shouldn't those entitlements be managed in-band to the MSP system (such as an x509 attribute and CRL mechanism)?

greg.haskins (Fri, 21 Apr 2017 12:15:38 GMT):
can anyone speak to the rationale there?

yacovm (Fri, 21 Apr 2017 12:17:32 GMT):
1) Yeah, that's a much better idea. Ideally we should do this. The only reason I proposed it, is that the peers in the org are "symmetrical" in all other aspects than the MSP material. 2) Of course. The idea is- operations that are "bootstrap"-related, you need to trust your administrator. You trust your administrator because you have its certificate in your local config on your file system, because you trust your file system. Now, after the bootstrap "permissions" have been set, you have extended ones (channel related) that they are defined by the entities that are considered privileged by your bootstrap permissions

greg.haskins (Fri, 21 Apr 2017 12:18:10 GMT):
ok, if its a bootstrapping, this makes sense

greg.haskins (Fri, 21 Apr 2017 12:18:15 GMT):
thank you for the explaination

yacovm (Fri, 21 Apr 2017 12:18:16 GMT):
Now, this https://gerrit.hyperledger.org/r/#/c/8273/ explains it all very well, this whole setup

greg.haskins (Fri, 21 Apr 2017 12:18:54 GMT):
I was afraid I was going to have to manage .pem distribution to the cluster

yacovm (Fri, 21 Apr 2017 12:18:59 GMT):
I'll give you an example

yacovm (Fri, 21 Apr 2017 12:19:14 GMT):
when you install a CC you touch the peer's file system

yacovm (Fri, 21 Apr 2017 12:20:46 GMT):
For this you need (if I recall) org admin privileges. But when you install- you set the instantiation policy

yacovm (Fri, 21 Apr 2017 12:20:59 GMT):
and in the instantiation of the CC you set the endorsement policy

yacovm (Fri, 21 Apr 2017 12:21:23 GMT):
so basically every "step" that requires AC defines the AC of the next "step"

yacovm (Fri, 21 Apr 2017 12:22:06 GMT):
Now, regarding `.pem` files- the tough part is only to collect them all in order to make a new channel

yacovm (Fri, 21 Apr 2017 12:22:20 GMT):
but you only need, for example- to collect the PEMs of the root CAs of the orgs

yacovm (Fri, 21 Apr 2017 12:22:26 GMT):
not of the peers (gossip disseminates it for you ;) )

greg.haskins (Fri, 21 Apr 2017 12:22:28 GMT):
the bootstrap through instantiate makes sense

greg.haskins (Fri, 21 Apr 2017 12:23:05 GMT):
well, wait, it sounds like you are saying two different things

yacovm (Fri, 21 Apr 2017 12:23:11 GMT):
why?

greg.haskins (Fri, 21 Apr 2017 12:23:50 GMT):
is "admincert" an admin identity or a CA with authority to sign admin identities

greg.haskins (Fri, 21 Apr 2017 12:24:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=efLBedF6dwyNXfXqD) @yacovm in reference to

yacovm (Fri, 21 Apr 2017 12:24:33 GMT):
admin cert is a cert that the root CA signed it, + it is found in the file system of the peer in a folder that "just admin certs are there"

yacovm (Fri, 21 Apr 2017 12:24:52 GMT):
ah but Greg, this is for channel creation

yacovm (Fri, 21 Apr 2017 12:25:00 GMT):
admin cert is something intra-organizational

greg.haskins (Fri, 21 Apr 2017 12:25:41 GMT):
im confused about your statements above...."tough part is only to collect them all in order to make a new channel" and "you only need, for example- to collect the PEMs of the root CAs"

greg.haskins (Fri, 21 Apr 2017 12:26:02 GMT):
it sounded like you were saying you only needed to manage the rootca.pems

yacovm (Fri, 21 Apr 2017 12:26:26 GMT):
so, if you're orgA and you want to create a channel with you *and* orgB, you need orgB's root CA certs

greg.haskins (Fri, 21 Apr 2017 12:26:33 GMT):
but I took your earlier statement that I needed to grant a specific identity (or identities) channel-creation entitlements by putting them in admincerts

yacovm (Fri, 21 Apr 2017 12:26:34 GMT):
there is no going around it

greg.haskins (Fri, 21 Apr 2017 12:26:49 GMT):
I understand the rootca requirement

greg.haskins (Fri, 21 Apr 2017 12:27:17 GMT):
whats not clear is whether admincerts is a trust-root or identity

yacovm (Fri, 21 Apr 2017 12:27:35 GMT):
ah, so it's an identity

yacovm (Fri, 21 Apr 2017 12:27:41 GMT):
I'll give you an example

yacovm (Fri, 21 Apr 2017 12:28:35 GMT):
https://github.com/hyperledger/fabric/tree/master/examples/e2e_cli/crypto/peer/peer0/localMspConfig The certs in the `admincerts` define the admins. They are of course signed by the root CA that their certs are in `cacerts`.

greg.haskins (Fri, 21 Apr 2017 12:29:51 GMT):
ok, so cacerts establishes the trust-roots, and admincerts grants identities rooted in cacerts the privilege of channel-creation

yacovm (Fri, 21 Apr 2017 12:30:45 GMT):
I'd say not channel creation but channel join-ing

yacovm (Fri, 21 Apr 2017 12:30:54 GMT):
since a peer doesn't create the channel, but the ordering service.

greg.haskins (Fri, 21 Apr 2017 12:30:59 GMT):
ah, right

greg.haskins (Fri, 21 Apr 2017 12:31:20 GMT):
i assume theres a similar "admincert" type bootstrap for the orderer w.r.t. channel creation?

yacovm (Fri, 21 Apr 2017 12:33:11 GMT):
it's a bit more complex than that, because the peer is bootstrapped to a single org, while the OS is "bootstrapped" already to know all orgs. https://github.com/hyperledger/fabric/blob/master/common/configtx/tool/configtx.yaml defines the organizations, and it also needs the root CA certs.

yacovm (Fri, 21 Apr 2017 12:33:11 GMT):
it's a bit more complex than that, because the peer is bootstrapped to a single org, while the OS is "bootstrapped" already to know all orgs. https://github.com/hyperledger/fabric/blob/master/common/configtx/tool/configtx.yaml can be used to generate a "block" that defines the organizations, and it also needs the root CA certs.

greg.haskins (Fri, 21 Apr 2017 12:33:33 GMT):
how is per-channel granularity handled?

greg.haskins (Fri, 21 Apr 2017 12:33:55 GMT):
for instance, say I have Org1 and Org2 that want to join a channel Chan1

yacovm (Fri, 21 Apr 2017 12:33:56 GMT):
wdym?

greg.haskins (Fri, 21 Apr 2017 12:34:22 GMT):
so i have org1.pem and org2.pem in cacerts

yacovm (Fri, 21 Apr 2017 12:34:33 GMT):
ah you have to get the root CA certs of both orgs, and have 1 of them mix them together and serve that to the OS

yacovm (Fri, 21 Apr 2017 12:34:39 GMT):
and the latter returns you a block

greg.haskins (Fri, 21 Apr 2017 12:34:43 GMT):
and I have admin-org1.pem and admin-org2.pem in admincerts

yacovm (Fri, 21 Apr 2017 12:34:45 GMT):
which you give each of the peers :/

yacovm (Fri, 21 Apr 2017 12:34:58 GMT):
in the future we hopefully have a less complex mechanism

yacovm (Fri, 21 Apr 2017 12:35:10 GMT):
an "identity channel"

yacovm (Fri, 21 Apr 2017 12:35:24 GMT):
so you'll just need to specify the orgs instead of having their PEM or something like that

greg.haskins (Fri, 21 Apr 2017 12:35:38 GMT):
hear me out

greg.haskins (Fri, 21 Apr 2017 12:35:48 GMT):
im confused about one thing

greg.haskins (Fri, 21 Apr 2017 12:36:08 GMT):
what defines the group that allowed to join a channel?

greg.haskins (Fri, 21 Apr 2017 12:36:14 GMT):
thats what not clear

yacovm (Fri, 21 Apr 2017 12:36:20 GMT):
the channel creator!

greg.haskins (Fri, 21 Apr 2017 12:36:47 GMT):
ah, the orgs in the configtx

yacovm (Fri, 21 Apr 2017 12:36:54 GMT):
if you collect a certain set of root CA certs, the channel's "name" is then owned by these orgs

greg.haskins (Fri, 21 Apr 2017 12:38:06 GMT):
ok, so someone sets up org1+org2 and generates a genesis block, fires it through the OS, and now we have group established for the channel

greg.haskins (Fri, 21 Apr 2017 12:38:31 GMT):
next, an admin (as defined by valid certs in admincerts) on Org1 needs to join org1 to the channel

greg.haskins (Fri, 21 Apr 2017 12:38:36 GMT):
likewise for org2

yacovm (Fri, 21 Apr 2017 12:38:47 GMT):
almost- it fires a transaction that makes the OS create the block ;)

greg.haskins (Fri, 21 Apr 2017 12:39:02 GMT):
right, ok

yacovm (Fri, 21 Apr 2017 12:39:18 GMT):
and yeah exactly as you said after that

greg.haskins (Fri, 21 Apr 2017 12:39:27 GMT):
ok, got it

greg.haskins (Fri, 21 Apr 2017 12:39:46 GMT):
i assume that only the anchor-peer needs to be told to join?

greg.haskins (Fri, 21 Apr 2017 12:39:55 GMT):
the others will learn via gossip?

yacovm (Fri, 21 Apr 2017 12:39:57 GMT):
no. all peers you want

greg.haskins (Fri, 21 Apr 2017 12:40:07 GMT):
i mean intra-org?

yacovm (Fri, 21 Apr 2017 12:40:13 GMT):
the anchor peers are just endpoints for peers from different orgs to find each other

greg.haskins (Fri, 21 Apr 2017 12:40:26 GMT):
so I have to do "peer channel join" for each peer?

yacovm (Fri, 21 Apr 2017 12:40:40 GMT):
also intra-org you need manually to have peers join a channel

greg.haskins (Fri, 21 Apr 2017 12:42:26 GMT):
ok, i just studied e2e, it does look like each peer is explicitly joined

greg.haskins (Fri, 21 Apr 2017 12:42:42 GMT):
i think I understand now, thank you for the details

yacovm (Fri, 21 Apr 2017 12:42:45 GMT):
np

jimthematrix (Fri, 21 Apr 2017 13:55:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=6AMwiiEm477pRhPDw) @greg.haskins golang 1.8 didn't work with cryptogen, had to upgrade to 1.8.1 to make that work. other than that I've been using 1.8 for a long time and haven't had any issues

greg.haskins (Fri, 21 Apr 2017 13:59:39 GMT):
@jimthematrix thats good news

greg.haskins (Fri, 21 Apr 2017 14:00:06 GMT):
would like to look at ubuntu 17.04, golang 1.8, protobuf 3.2, etc, after the release

greg.haskins (Fri, 21 Apr 2017 14:00:26 GMT):
(basically a sweep of all deps)

greg.haskins (Fri, 21 Apr 2017 14:00:49 GMT):
(one debate would be, do we want to only use Ubuntu LTS

kostas (Fri, 21 Apr 2017 15:34:45 GMT):
Latest master (tip: `441b3085`) failing again?

kostas (Fri, 21 Apr 2017 15:34:59 GMT):
`github.com/hyperledger/fabric/core/chaincode` fails with a panic.

troyronda (Fri, 21 Apr 2017 15:39:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=HkLQdomv6vjdWsKJQ) I had thought at some point, there was also the ideas of limiting which peers listened to the ordering service. Is this also the anchor peers?

muralisr (Fri, 21 Apr 2017 15:44:52 GMT):
@kostas in CI ?

muralisr (Fri, 21 Apr 2017 15:45:15 GMT):
if local... do you have log or stack trace handy ?

kostas (Fri, 21 Apr 2017 15:55:32 GMT):
@muralisr: Locally. Tried twice. Here you go: https://gist.github.com/kchristidis/4d0073ef4a9c4fd8a22bb47796002a85

kostas (Fri, 21 Apr 2017 15:56:16 GMT):
@troyronda: That would be the leader peer, see last paragraph here: https://github.com/hyperledger/fabric/blob/3181e78c3ecf4d5d7f3745d34906f44e8f3436f6/docs/source/gossip.rst#gossip-protocol

muralisr (Fri, 21 Apr 2017 15:57:31 GMT):
thans

muralisr (Fri, 21 Apr 2017 15:57:31 GMT):
thanks

troyronda (Fri, 21 Apr 2017 15:57:32 GMT):
@kostas - ah cool, thanks. are the leader peers configured similar to anchor peers then?

troyronda (Fri, 21 Apr 2017 15:57:32 GMT):
@kostas - ah cool, thanks.

muralisr (Fri, 21 Apr 2017 15:58:11 GMT):

Message Attachments

muralisr (Fri, 21 Apr 2017 15:59:15 GMT):
the map chaincode crashed

muralisr (Fri, 21 Apr 2017 16:01:32 GMT):
@dave.enyeart any ideas ? this is in the "map" chaincode when executing TestQueries (I wouldnt expect timing so would expect to see this in CI too...)

dave.enyeart (Fri, 21 Apr 2017 16:04:06 GMT):
@muralisr I will investigate

dave.enyeart (Fri, 21 Apr 2017 16:04:06 GMT):
@muralisr I investigated - haven't been able to reproduce on latest master.

JonathanLevi (Fri, 21 Apr 2017 18:35:45 GMT):
Yup, Dave, please do not post here.

JonathanLevi (Fri, 21 Apr 2017 18:35:49 GMT):
(point taken)

JonathanLevi (Fri, 21 Apr 2017 18:41:55 GMT):
@dave.enyeart: Please post these on #fabric-pr-review first... we do not wish to make "escalating to this channel" a habit... (or yours or others). Thank you.

JonathanLevi (Fri, 21 Apr 2017 18:42:07 GMT):
(Hope you understand)

JonathanLevi (Fri, 21 Apr 2017 18:42:26 GMT):
(hope you'd understand where we are coming from)

dave.enyeart (Fri, 21 Apr 2017 18:42:57 GMT):
Indeed, I give it at least a week before escalating here :)

JonathanLevi (Fri, 21 Apr 2017 20:40:10 GMT):
I'm sorry it takes time to merge 6+ issues at this stage, during a code freeze, with a few maintainers being away, etc. We did merge all the of the list you asked for yesterday (https://chat.hyperledger.org/channel/fabric-pr-review?msg=pEct4mwzYbibyv6MK) other than one that I have temporarily veto'ed due to some (minor) licensing. Still, this is not the right channel for escalating. Thanks.

JonathanLevi (Fri, 21 Apr 2017 20:41:32 GMT):
____ There are many ongoing discussions these days, mostly around what gets into 1.0, planning and ETAs. Please, everyone who reads this channel, the release and the iterations over the mailing lists - please take note of it.

JonathanLevi (Fri, 21 Apr 2017 20:47:29 GMT):
____ As some of you have noticed the (several) ongoing discussions these days around what gets into 1.0, planning and ETAs. Please, everyone who reads this channel, the #fabric-release one and the various threads/iterations over the mailing lists - please take note that some of the PRs/CRs take a bit longer to "auto-merge" as we are working out on solidifying the "strategy" first.

JonathanLevi (Fri, 21 Apr 2017 20:47:53 GMT):
[This is not really a note to the maintainers - but for those who still read this channel]

mastersingh24 (Sat, 22 Apr 2017 14:38:40 GMT):
so how do we want to deal with https://gerrit.hyperledger.org/r/#/c/8311/ ? I think it's actually a good (and important) change, but it conflicts with 17 other change sets

mastersingh24 (Sat, 22 Apr 2017 14:39:24 GMT):
we should also get this one from @greg.haskins https://gerrit.hyperledger.org/r/#/c/7963/ (hopefully it's just a rebase)

yacovm (Sat, 22 Apr 2017 15:08:00 GMT):
There is no escaping death, income tax, and costumizable per package logging levels for fabric

mastersingh24 (Sat, 22 Apr 2017 17:46:16 GMT):
I thought I paid all of my taxes on April 18 :(

mastersingh24 (Sat, 22 Apr 2017 17:46:38 GMT):
I hear ya

mastersingh24 (Sat, 22 Apr 2017 17:47:13 GMT):
I'm giving https://gerrit.hyperledger.org/r/#/c/8311/ a +2

yacovm (Sat, 22 Apr 2017 17:52:56 GMT):
hmmm

yacovm (Sat, 22 Apr 2017 17:52:59 GMT):
I'm a bit afraid

yacovm (Sat, 22 Apr 2017 17:53:24 GMT):
I pulled the change set and seems like gossip's logging is set to INFO in the tests

yacovm (Sat, 22 Apr 2017 17:53:24 GMT):
I pulled the change set and seems like gossip's logging is set to INFO in the tests (I think that before the change it was on WARN)

yacovm (Sat, 22 Apr 2017 17:54:12 GMT):
but at the same time it passed CI so I guess it's not too verbose for CI

muralisr (Sun, 23 Apr 2017 00:59:32 GMT):
@mastersingh24 agree ...given the breadth of changes better get in https://gerrit.hyperledger.org/r/#/c/7963 first or it would lead to perpetual rebases .. so just like https://gerrit.hyperledger.org/r/#/c/8311 better get 7963 in and others can rebase IMO

cbf (Sun, 23 Apr 2017 15:17:24 GMT):
@greg.haskins @mastersingh24 we should coordinate getting https://gerrit.hyperledger.org/r/#/c/7963/ merged... it will need a rebase and almost immediate review/merge so we don't succumb to another merge conflict. I think it has been reviewed to death, suggest that we rebase, not wait for Jenkins and just +2 and merge... What say ye?

greg.haskins (Sun, 23 Apr 2017 16:06:30 GMT):
@cbf sounds good to me: I am mobile and won't be at a computer until tonight at the earliest. However if the gerrit rebate is enough, I support this

greg.haskins (Sun, 23 Apr 2017 16:07:27 GMT):
We should expect the following: some number of other patches will go naturally into "Merge conflict" and require explicit action

cbf (Sun, 23 Apr 2017 16:07:31 GMT):
let's aim for tomorrow

greg.haskins (Sun, 23 Apr 2017 16:08:01 GMT):
Others will need a rebase but this won't be apparent if they are just merged

greg.haskins (Sun, 23 Apr 2017 16:08:28 GMT):
So we should ideally rebase any outstanding CRs a

greg.haskins (Sun, 23 Apr 2017 16:08:48 GMT):
that are not in conflict status to be sure

greg.haskins (Sun, 23 Apr 2017 16:09:00 GMT):
Or just deal with the CI fallout

greg.haskins (Sun, 23 Apr 2017 16:09:23 GMT):
It's typically a one liner fix, but FYI

greg.haskins (Sun, 23 Apr 2017 16:10:29 GMT):
This is the typical conflict: https://gerrit.hyperledger.org/r/#/c/7963/18/core/committer/txvalidator/txvalidator_test.go

greg.haskins (Sun, 23 Apr 2017 16:10:58 GMT):
People have been adding those calls like mad this week.

greg.haskins (Sun, 23 Apr 2017 16:11:45 GMT):
Tomorrow works for me.

greg.haskins (Sun, 23 Apr 2017 16:12:34 GMT):
I think this will go smoothest if we can coordinate a merge freeze window for an hour or so

jojocheung (Mon, 24 Apr 2017 07:14:40 GMT):
@greg.haskins hi, your latest commit 8ce1073 is referring to a missing file `/bin/true`

greg.haskins (Mon, 24 Apr 2017 12:29:21 GMT):
@jojocheung what platform are you running?

jojocheung (Mon, 24 Apr 2017 12:32:33 GMT):
Mac

greg.haskins (Mon, 24 Apr 2017 12:35:57 GMT):
@jojocheung indeed...i see that too...i developed it in vagrant/linux

greg.haskins (Mon, 24 Apr 2017 12:36:04 GMT):
pls file JIRA and assign to me

greg.haskins (Mon, 24 Apr 2017 12:36:46 GMT):
looks like its /usr/bin/true on OSX

greg.haskins (Mon, 24 Apr 2017 12:37:11 GMT):
for the time being, you can edit it to that locally to unblock you

cbf (Mon, 24 Apr 2017 13:43:54 GMT):
hi @greg.haskins - is that you rebasing all the CRs in the pipeline?

greg.haskins (Mon, 24 Apr 2017 13:44:08 GMT):
yeah, or a select number

greg.haskins (Mon, 24 Apr 2017 13:44:17 GMT):
did I mess something up?

greg.haskins (Mon, 24 Apr 2017 13:45:05 GMT):
basically any that were in a V+1 and not Merge Conflict, I rebased to ensure they were built against CR 7963

greg.haskins (Mon, 24 Apr 2017 13:45:25 GMT):
(otherwise we had the risk that we wouldnt see their conflict until after merge, because of how gerrit works

cbf (Mon, 24 Apr 2017 13:45:27 GMT):
no, did your patch get merged then?

greg.haskins (Mon, 24 Apr 2017 13:45:41 GMT):
yeah, it looks like someone did over night

greg.haskins (Mon, 24 Apr 2017 13:45:44 GMT):
let me look

greg.haskins (Mon, 24 Apr 2017 13:46:11 GMT):
it was @JonathanLevi and @muralisr

greg.haskins (Mon, 24 Apr 2017 13:46:13 GMT):
https://gerrit.hyperledger.org/r/#/c/7963/

greg.haskins (Mon, 24 Apr 2017 13:46:23 GMT):
I had rebased before going to bed

cbf (Mon, 24 Apr 2017 13:48:44 GMT):
ok cool

cbf (Mon, 24 Apr 2017 13:48:50 GMT):
thanks for the rebasing then

dhuseby (Mon, 24 Apr 2017 17:45:08 GMT):
I just broke out the branching model proposal into its own document: https://goo.gl/H3M8XN

dhuseby (Mon, 24 Apr 2017 17:45:13 GMT):
it now has pictures too : )

jojocheung (Tue, 25 Apr 2017 01:25:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=4bLrJPdK4RX5LLJZ9) @greg.haskins Sure thanks!

JonathanLevi (Tue, 25 Apr 2017 04:02:56 GMT):
Hello fellow maintainers, Just a quick heads-up, as some of us are working in different time-zones. So Chris Ferris and I, Jonathan, had an open session at the DC Hackfest at 3pm today (https://docs.google.com/document/d/1rz1HsUwqIesSgj1fvKWTaNHuYKl7320iGpAX2l2NqBA) regarding *Hyperledger Fabric 1.0 Release Status, Plan, Upcoming Schedule*, which was mostly around how do we go from here: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104 to a 1.0 Release. I bet you have all seen Sharon's (@weeds) nots on the #fabric channel. In addition to all of the things said/discussed, one of topics/suggestion that came up was *how shall we prioritize, deal with show stoppers, coordinate better, etc.* - which naturally lead to a discussion around having a designated *Release Manager*. There are several ways to go about it, but two initial points: - I (personally suggested), that we should probably have 2 such Release Managers - or at least more than one. - Another suggestion/discussion was that we actually have a rotation, so that several maintainers can share the privilege along with the burden/responsibility that comes with it vs. having the Release Manager(s) selected from now until the 1.0 release. Either way, the maintainers should have a saying about this, and especially given the significance/importance of the 1.0 release - we should probably officially vote over it. I’m going to post this on the #fabric channel tomorrow (Tuesday), which is where we left it (https://chat.hyperledger.org/channel/fabric?msg=knKg5bBWj5pPD6TLk) - however, before doing so, I wanted to initially run it here, and quickly see whether there is any strong objection anyone is vehemently opposed to the *Release Manager* idea - or whether there is more input/feedback, before I put together the first (short) draft proposal for the vote. Good night (/morning), J

JonathanLevi (Tue, 25 Apr 2017 04:03:36 GMT):
Hello fellow maintainers, Just a quick heads-up, as some of us are working in different time-zones.

JonathanLevi (Tue, 25 Apr 2017 04:03:43 GMT):
So Chris Ferris and I, Jonathan, had an open session at the DC Hackfest at 3pm today (https://docs.google.com/document/d/1rz1HsUwqIesSgj1fvKWTaNHuYKl7320iGpAX2l2NqBA) regarding *Hyperledger Fabric 1.0 Release Status, Plan, Upcoming Schedule*, which was mostly around how do we go from here: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104 to a 1.0 Release. I bet you have all seen Sharon's (@weeds) nots on the #fabric channel.

JonathanLevi (Tue, 25 Apr 2017 04:03:53 GMT):
In addition to all of the things said/discussed, one of topics/suggestion that came up was *how shall we prioritize, deal with show stoppers, coordinate better, etc.* - which naturally lead to a discussion around having a designated *Release Manager*.

JonathanLevi (Tue, 25 Apr 2017 04:04:01 GMT):
There are several ways to go about it, but two initial points: - I (personally suggested), that we should probably have 2 such Release Managers - or at least more than one. - Another suggestion/discussion was that we actually have a rotation, so that several maintainers can share the privilege along with the burden/responsibility that comes with it vs. having the Release Manager(s) selected from now until the 1.0 release.

JonathanLevi (Tue, 25 Apr 2017 04:04:01 GMT):
There are several ways to go about it, but two initial points: - I (personally) suggested, that we should probably have 2 such Release Managers - or at least more than one. - Another suggestion/discussion was that we actually have a rotation, so that several maintainers can share the privilege along with the burden/responsibility that comes with it vs. having the Release Manager(s) selected from now until the 1.0 release.

JonathanLevi (Tue, 25 Apr 2017 04:04:01 GMT):
There are several ways to go about it, but two initial points: - I (personally) suggested, that we should probably have 2 such Release Managers - or at least more than one. - Another suggestion/point was that we actually have a rotation, so that several maintainers can share the privilege along with the burden/responsibility that comes with it vs. having the Release Manager(s) selected from now until the 1.0 release.

JonathanLevi (Tue, 25 Apr 2017 04:04:11 GMT):
Either way, the maintainers should have a saying about this, and especially given the significance/importance of the 1.0 release - we should probably officially vote over it.

JonathanLevi (Tue, 25 Apr 2017 04:04:19 GMT):
I’m going to post this on the #fabric channel tomorrow (Tuesday), which is where we left it (https://chat.hyperledger.org/channel/fabric?msg=knKg5bBWj5pPD6TLk) - however, before doing so, I wanted to initially run it here, and quickly see whether there is any strong objection anyone is vehemently opposed to the *Release Manager* idea - or whether there is more input/feedback, before I put together the first (short) draft proposal for the vote.

JonathanLevi (Tue, 25 Apr 2017 04:04:26 GMT):
Good night (/morning), J

JonathanLevi (Tue, 25 Apr 2017 04:07:44 GMT):
I’m going to post this on the #fabric channel tomorrow (Tuesday), which is where we left it (https://chat.hyperledger.org/channel/fabric?msg=knKg5bBWj5pPD6TLk) today.

JonathanLevi (Tue, 25 Apr 2017 04:08:06 GMT):
However, before doing so, I wanted to initially run it here, and quickly see whether there is any strong objection anyone is vehemently opposed to the *Release Manager* idea - or whether there is more input/feedback, before I put together the first (short) draft proposal for the vote.

JonathanLevi (Tue, 25 Apr 2017 04:08:06 GMT):
However, before doing so, I wanted to initially run it here, and quickly see whether there is any strong objection [or if] anyone is vehemently opposed to the *Release Manager* idea - or whether there is more input/feedback, before I put together the first (short) draft proposal for the vote.

JonathanLevi (Tue, 25 Apr 2017 04:11:21 GMT):
I’m going to post this here and on the #fabric, #fabric-release channels tomorrow (Tuesday), and support it via email to the project mailing list... which is exactly where we left it (https://chat.hyperledger.org/channel/fabric?msg=knKg5bBWj5pPD6TLk) today, at the end of the session. FYI.

JonathanLevi (Tue, 25 Apr 2017 04:11:21 GMT):
I’m going to post this here and on the #fabric, #fabric-release channels tomorrow (Tuesday), and support it via email to the project's mailing list... which is exactly where we left it (https://chat.hyperledger.org/channel/fabric?msg=knKg5bBWj5pPD6TLk) today, at the end of the session. FYI.

mastersingh24 (Tue, 25 Apr 2017 16:08:32 GMT):
[ :thumbsup:](https://chat.hyperledger.org/channel/fabric-maintainers?msg=8iFmvjuyp8gbECPvz) @JonathanLevi

cbf (Tue, 25 Apr 2017 17:48:17 GMT):
I've just added two new maintainer nominations for @smithbk and @dave.enyeart

cbf (Tue, 25 Apr 2017 17:48:28 GMT):
https://gerrit.hyperledger.org/r/#/c/8517/

cbf (Tue, 25 Apr 2017 17:48:42 GMT):
https://gerrit.hyperledger.org/r/#/c/8519/

cbf (Wed, 26 Apr 2017 11:30:29 GMT):
congrats to @smithbk and @dave.enyeart on being the latest Fabric maintainers

smithbk (Wed, 26 Apr 2017 11:31:51 GMT):
thanks everyone :-)

dave.enyeart (Wed, 26 Apr 2017 11:54:22 GMT):
looking forward to it!

weeds (Wed, 26 Apr 2017 13:32:58 GMT):
scrum call starting- we will go to fabric-peer-endorser-comitter

weeds (Wed, 26 Apr 2017 14:36:29 GMT):
@rjones Ry- can we get the permissions for Keith Smith and Dave as maintainers so they can start +2ing? I think they tried already this morning and it's not quite working yet. Thanks! (see above from cbf)

weeds (Wed, 26 Apr 2017 14:36:47 GMT):
scrum concluded, but again all notes are sitting in fabric-peer-endorser-comitter

jimthematrix (Wed, 26 Apr 2017 15:34:16 GMT):
@mastersingh24 @binhn I have a question on what to do with https://gerrit.hyperledger.org/r/#/c/8263/ (NodeSDK - update channel), so the configtxgen tool as it stands now seems to be only for developers to get started ( @kostas @jyellick correct me if wrong ) because it: - only generates default policies (Readers - any memebers, Writers - any members, Admins - any admins, "AcceptAllPolicy") - doesn't allow custom policies to be defined - doesn't enable a workflow to members to sign over the config_update content and include their signatures inside the ConfigUpdateEnvelop to send for update whereas with 8263 (which builds on the create channel support that's already in node SDK), you can: - build channel update raw bytes: `client.buildChannelConfigUpdate()` - (for each member org to) sign the new channel config: `client.signChannelConfig()` - sign and submit the channel update: `client.updateChannel()`

jimthematrix (Wed, 26 Apr 2017 15:34:16 GMT):
@mastersingh24 @binhn I have a question on what to do with https://gerrit.hyperledger.org/r/#/c/8263/ (NodeSDK - update channel), so the configtxgen tool as it stands now seems to be only for developers to get started ( @kostas @jyellick correct me if wrong ) because it: - only generates default policies (Readers - any memebers, Writers - any members, Admins - any admins, "AcceptAllPolicy") - doesn't allow custom policies to be defined - doesn't enable a workflow to members to sign over the config_update content and include their signatures inside the ConfigUpdateEnvelop to send for update whereas with 8263 (which builds on the create channel support that's already in node SDK), you can: - build channel update raw bytes: `client.buildChannelConfigUpdate()` - (for each member org to) sign the new channel config: `client.signChannelConfig()` - collect those signatures and integrate them into a ConfigUpdateEnvelop, then sign and submit the channel update: `client.updateChannel()`

jimthematrix (Wed, 26 Apr 2017 15:38:00 GMT):
will the list of pending CRs from Jason related to this area address the above issues without 8263?

rjones (Wed, 26 Apr 2017 16:19:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=4QNgaFfSsBTiLbsx6) @weeds done

rjones (Wed, 26 Apr 2017 16:20:24 GMT):
@cbf @weeds in the future please add me as a reviewer to the changeset for maintainer nominations so I get email automagically when the merge happens :)

kostas (Wed, 26 Apr 2017 16:26:59 GMT):
@jimthematrix None of these issues are addressed by the pending changeset stack.

JonathanLevi (Wed, 26 Apr 2017 16:38:39 GMT):
--- Fellow maintainers... got stuck in DC last night due to the weather/ground hold in NYC. To simplify the above discussion regarding the release, I suggest we use this doc to track and list who would like to put his name down as a *Release Manager*, for now, for Fabric 1.0. If we see that nobody comes forward, we will just "roll a dice, or 3 in our case" ;-)

JonathanLevi (Wed, 26 Apr 2017 16:39:01 GMT):
If there are too many, we can have a "lead" RM and possibly 2 helpers... just keep in mind that it is a big commitment and responsibility - which is why I still believe we should have a few (or at least more than one).

JonathanLevi (Wed, 26 Apr 2017 16:39:16 GMT):
https://docs.google.com/a/hacera.com/document/d/1Vvo4GwGe3G2BA14czPVAk2b89OWfbdQG91SYMbjBwyY/edit?usp=sharing

JonathanLevi (Wed, 26 Apr 2017 16:40:08 GMT):
Please kindly authenticate yourself so that we have a better auditing. Whatever we come up with, I'll work to also put on the wiki.

JonathanLevi (Wed, 26 Apr 2017 16:40:08 GMT):
Please kindly authenticate yourself so that we have a better auditing trail. Whatever we come up with, I'll work to also put on the wiki.

JonathanLevi (Wed, 26 Apr 2017 16:40:46 GMT):
Note: please do not worry about the "ordering", this is not a first-comes first-served. We are simply collecting some data ;-)

JonathanLevi (Wed, 26 Apr 2017 16:42:45 GMT):
Note: please do not worry about the "ordering", this is not a first-comes first-served. We are simply collecting some data to enable a decision/see where we stand on this. Thanks.

jimthematrix (Wed, 26 Apr 2017 16:48:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=mpFdiF9mm4WDb7Zy4) @kostas thanks for confirming that, then I think we'll need to merge 8263 (once it gets past build errors) because we already allow customers to have full control on the channel configuration during creation via the node SDK, but then they will not be able to update it unless 1) configtxgen is updated or 2) 8263 gets merged

kostas (Wed, 26 Apr 2017 16:48:43 GMT):
@jimthematrix Roger that. /cc @binhn

kostas (Wed, 26 Apr 2017 16:57:56 GMT):
@jimthematrix: Has 8263 been tested against this stack https://gerrit.hyperledger.org/r/#/c/7315/?

gabrielpsilva (Wed, 26 Apr 2017 17:30:13 GMT):
Has joined the channel.

dave.enyeart (Wed, 26 Apr 2017 18:16:53 GMT):
For new maintainers like @smithbk and myself, are there some merge guidelines we should know about? Tips, best practices, etc? Take for instance /8255. It has two +2 already. Is there a reason it is not merged?

yacovm (Wed, 26 Apr 2017 18:19:27 GMT):
Because it's based on other CRs that were not +2ed

dave.enyeart (Wed, 26 Apr 2017 18:19:45 GMT):
So gerrit is not smart enough to tell me that? I have to go look at all of them?

yacovm (Wed, 26 Apr 2017 18:19:47 GMT):
but I think the whole chain can now be batch-merged

yacovm (Wed, 26 Apr 2017 18:20:02 GMT):
it does, it's just that now you don't see it

yacovm (Wed, 26 Apr 2017 18:20:12 GMT):
usually the "submit along with parents" is grayed out

yacovm (Wed, 26 Apr 2017 18:20:21 GMT):
now it's blue (ready)

dave.enyeart (Wed, 26 Apr 2017 18:20:26 GMT):
ok, so if "submit along with parents" is enabled it is free game to merge

kostas (Wed, 26 Apr 2017 18:20:27 GMT):
@dave.enyeart 8255 is part of a stack and none of the previous changesets have been merged either FWIW. If the question is, why isn't the first changeset of that stack (also two +2's) merged, it's because we're waiting for 8513 to be merged.

kostas (Wed, 26 Apr 2017 18:21:17 GMT):
Our intention would have probably been clearer if we had +1'd, instead of +2'd.

yacovm (Wed, 26 Apr 2017 18:21:23 GMT):
I think you have the wrong number kostas

yacovm (Wed, 26 Apr 2017 18:21:25 GMT):
8513 ?

kostas (Wed, 26 Apr 2017 18:21:48 GMT):
Yes.

kostas (Wed, 26 Apr 2017 18:21:55 GMT):
Per what we discussed on the call today.

yacovm (Wed, 26 Apr 2017 18:21:57 GMT):
`[FAB-3324] - Upgrade Getting Started` ?

yacovm (Wed, 26 Apr 2017 18:22:03 GMT):
that's 8513

kostas (Wed, 26 Apr 2017 18:22:11 GMT):
Yes.

yacovm (Wed, 26 Apr 2017 18:22:38 GMT):
ok.

yacovm (Wed, 26 Apr 2017 18:22:43 GMT):
you can simply put it on top of them

yacovm (Wed, 26 Apr 2017 18:22:52 GMT):
and then cascading-merge everything, no?

yacovm (Wed, 26 Apr 2017 18:22:59 GMT):
the effect is the same, since it's an RST

yacovm (Wed, 26 Apr 2017 18:23:03 GMT):
there is no code dependency

dave.enyeart (Wed, 26 Apr 2017 18:23:41 GMT):
so technically /8255 could be merged now, we just made a decision to hold it out for doc?

kostas (Wed, 26 Apr 2017 18:24:01 GMT):
I am aware, but if we put it at the bottom of the stack (because of the reasons explained in the call today -- it needs to go in first), we will be triggering CI builds yet again on the 10 or so changesets sitting on top.

kostas (Wed, 26 Apr 2017 18:24:30 GMT):
@dave.enyeart: Yes.

kostas (Wed, 26 Apr 2017 18:26:00 GMT):
As I noted in the call, the doc is irrelevant and doesn't cover the changes that will go in anyway, but per @binhn's comment, we need to move a doc that no longer instructs the users to git clone. (Otherwise, they'll have to deal with the consortium concept, etc.)

kostas (Wed, 26 Apr 2017 18:26:00 GMT):
As I noted in the call, the doc is irrelevant and doesn't cover the changes that will go in anyway, but per @binhn's comment, we need to switch to a doc that no longer instructs the users to git clone. (Otherwise, they'll have to deal with the consortium concept, etc.)

dave.enyeart (Wed, 26 Apr 2017 18:31:03 GMT):
Next stupid question - can we trust the Rebase button? Will it fail if there are conflicts that cant be resolved? Or is it always recommended to download, rebase, re-push?

yacovm (Wed, 26 Apr 2017 18:31:43 GMT):
You mean, does the rebase button do an authentic rebase?

dave.enyeart (Wed, 26 Apr 2017 18:31:48 GMT):
right

yacovm (Wed, 26 Apr 2017 18:32:04 GMT):
well I think it does because you many times look at the diffs between change sets

yacovm (Wed, 26 Apr 2017 18:32:24 GMT):
and you can then see that in the diff, the new code from master was "added"

dave.enyeart (Wed, 26 Apr 2017 18:32:26 GMT):
i've always been scared of it since i didnt know how it would handle conflicts

yacovm (Wed, 26 Apr 2017 18:32:39 GMT):
ah if there will be a conflict

yacovm (Wed, 26 Apr 2017 18:32:49 GMT):
it will be red with "merge conflict" and the rebase wouldn't be possible

kostas (Wed, 26 Apr 2017 18:32:57 GMT):
@rjones trusts the Rebase button IIRC, but I don't :)

yacovm (Wed, 26 Apr 2017 18:32:59 GMT):
But it's only a change set, who cares if it falls?

yacovm (Wed, 26 Apr 2017 18:33:05 GMT):
it's not the master

yacovm (Wed, 26 Apr 2017 18:33:45 GMT):
on the contrary - if you rebase and the change set crashes CI, that's good because you have found out that the change set cannot be trusted

dave.enyeart (Wed, 26 Apr 2017 18:34:33 GMT):
i assume the etiquette is to not rebase other's stuff without asking them? Rebasing on behalf of my squad members would be ok but probably not other squad's CRs?

kostas (Wed, 26 Apr 2017 18:34:55 GMT):
^^ I would suggest so.

yacovm (Wed, 26 Apr 2017 18:35:08 GMT):
depends. If the rebase erases a +1 then yes

yacovm (Wed, 26 Apr 2017 18:35:13 GMT):
otherwise if it has -1 from jenkins

yacovm (Wed, 26 Apr 2017 18:35:18 GMT):
where is the problem?

binhn (Wed, 26 Apr 2017 18:35:20 GMT):
@dave.enyeart @kostas I put a -2 on the base CR, but since it has 2 +2s, the button is enabled. We are waiting for Nick to finish up the doc @nickgaski https://gerrit.hyperledger.org/r/#/c/8513

nickgaski (Wed, 26 Apr 2017 18:35:20 GMT):
Has joined the channel.

dave.enyeart (Wed, 26 Apr 2017 18:35:59 GMT):
ok thanks everyone. let me know if there are more 'lessons learned' from maintainers

yacovm (Wed, 26 Apr 2017 18:36:00 GMT):
also if the rebase erases a +2 then don't :)

yacovm (Wed, 26 Apr 2017 18:36:07 GMT):
these are hard to come by

dave.enyeart (Wed, 26 Apr 2017 18:36:16 GMT):
i've learned that already

yacovm (Wed, 26 Apr 2017 18:36:18 GMT):
Especially for gossip code :(

dave.enyeart (Wed, 26 Apr 2017 18:37:06 GMT):
BTW, for now I will focus maintainer duty on ledger area, but feel free to ping me if you think there are others I should look at

nickgaski (Wed, 26 Apr 2017 18:38:07 GMT):
it is pushed

cbf (Wed, 26 Apr 2017 18:38:10 GMT):
regarding the release manager discussion above, https://chat.hyperledger.org/channel/fabric-maintainers?msg=uWLicRfiwRa79WhYk I thought that for v1.0.0 that @JonathanLevi and I were sort of volunteered ;-)

dave.enyeart (Wed, 26 Apr 2017 18:38:34 GMT):
I will +2 that one :)

cbf (Wed, 26 Apr 2017 18:38:48 GMT):
;-)

yacovm (Wed, 26 Apr 2017 18:40:25 GMT):
makes sense to me

JonathanLevi (Wed, 26 Apr 2017 19:17:16 GMT):
@dave.enyeart: *I considered you a friend...*

JonathanLevi (Wed, 26 Apr 2017 19:17:58 GMT):
@cbf: Yes, that's also the impression I had - which is why I rushed to share the privilege here ;-)

dave.enyeart (Wed, 26 Apr 2017 19:19:27 GMT):
@JonathanLevi I considered you Release Manager material. Feel free to share some burden if not title. :)

cbf (Wed, 26 Apr 2017 19:27:33 GMT):
@dave.enyeart I think that the burden sharing is across all the maintainers but thanks!

cbf (Wed, 26 Apr 2017 19:27:46 GMT):
we have a ton of work to get through

jimthematrix (Wed, 26 Apr 2017 19:28:27 GMT):
@binhn https://gerrit.hyperledger.org/r/#/c/8263 verified properly locally, I added "+2" and "+1 verified", so it's ready to merge

jimthematrix (Wed, 26 Apr 2017 19:28:48 GMT):
...if we can't wait for the latest build to finish

binhn (Wed, 26 Apr 2017 19:29:51 GMT):
@jimthematrix greatly appreciate

binhn (Wed, 26 Apr 2017 19:31:03 GMT):
Jonathan release manager? congrats @JonathanLevi +100

jimthematrix (Wed, 26 Apr 2017 19:31:54 GMT):
just succeeded in the build (https://jenkins.hyperledger.org/job/fabric-sdk-node-verify-x86_64/904): ```19:30:57 1..765 19:30:57 # tests 765 19:30:57 # pass 765 19:30:57 19:30:57 # ok

cbf (Wed, 26 Apr 2017 19:32:18 GMT):
jim, you need someone to merge?

cbf (Wed, 26 Apr 2017 19:33:01 GMT):
@jimthematrix ^^

cbf (Wed, 26 Apr 2017 19:33:09 GMT):
because it is ready to submit

cbf (Wed, 26 Apr 2017 19:33:18 GMT):
just wondering why you didn't push the button

jimthematrix (Wed, 26 Apr 2017 19:33:29 GMT):
note that I overrode the "+1" myself

cbf (Wed, 26 Apr 2017 19:33:36 GMT):
I see that

jimthematrix (Wed, 26 Apr 2017 19:33:36 GMT):
the x86 build finished successfully

jimthematrix (Wed, 26 Apr 2017 19:33:41 GMT):
but s390 hasn't started

binhn (Wed, 26 Apr 2017 19:33:45 GMT):
@cbf don't merge, i need to merge some other CRs

jimthematrix (Wed, 26 Apr 2017 19:33:48 GMT):
i don't think we need to hold for that

cbf (Wed, 26 Apr 2017 19:34:09 GMT):
I won't touch

jimthematrix (Wed, 26 Apr 2017 19:34:12 GMT):
@binhn "that" means waiting for s390 build

jimthematrix (Wed, 26 Apr 2017 19:34:21 GMT):
our messages crossed ;-)

cbf (Wed, 26 Apr 2017 19:35:30 GMT):
but while I may sound like a broken record - please let's stop submitting 1k LOC patches - pretty please

yacovm (Wed, 26 Apr 2017 19:40:19 GMT):
@cbf I have 1 that is a lot but that's just because everything there is unit tests. You guys did want 85% CC https://gerrit.hyperledger.org/r/#/c/8495/

jimthematrix (Wed, 26 Apr 2017 19:41:45 GMT):
@cbf we definitely need to get better at it, I let this one slide because it's got 75% test code in it

cbf (Wed, 26 Apr 2017 19:43:10 GMT):
it does have lots of tests, and that is goodness, but tests can be contributed piecemeal too;-)

jimthematrix (Wed, 26 Apr 2017 19:43:55 GMT):
agreed, will stress this with the squad again

greg.haskins (Thu, 27 Apr 2017 01:55:12 GMT):
all: I would like to propose @harrijk be considered as a maintainer for the fabric-baseimage project.....John has been helping me out curating that image for about as long as I can remember: providing patches, reviews, access to hardware, running tests, etc. He is more than competent, helpful, friendly, and perhaps most importantly, patient since I am sometimes slow getting around to attending to baseimage tasks. On that front, I could really use his help ;)

greg.haskins (Thu, 27 Apr 2017 01:55:53 GMT):
im not quite sure what an official proposal would look like here since the current MAINTAINERS.md indicates its currently governed by the broader fabric maintainership

greg.haskins (Thu, 27 Apr 2017 01:55:58 GMT):
but I wanted to throw it out there

greg.haskins (Thu, 27 Apr 2017 01:57:56 GMT):
I should also mention, he has been a liason for the P/Z architecture support, and really should have -2 veto power for changes there just as much as I do

JonathanLevi (Thu, 27 Apr 2017 04:10:56 GMT):
BTW: https://gerrit.hyperledger.org/r/#/c/8615/

yacovm (Thu, 27 Apr 2017 09:39:14 GMT):
Does end to end work for you guys?

yacovm (Thu, 27 Apr 2017 09:39:25 GMT):
I think the ordering service shuts down upon startup

yacovm (Thu, 27 Apr 2017 09:39:29 GMT):
due to configuration

yacovm (Thu, 27 Apr 2017 09:39:44 GMT):
`2017-04-27 09:38:59.197 UTC [orderer/multichain] newLedgerResources -> CRIT 041 Error creating configtx manager and handlers: Error creating group Consortiums: Disallowed channel group: Consortiums `

marek.dapps (Thu, 27 Apr 2017 10:18:25 GMT):
Has joined the channel.

dave.enyeart (Thu, 27 Apr 2017 11:06:46 GMT):
Andbody know why Verifications aren't getting kicked off the last 10 hours?

dave.enyeart (Thu, 27 Apr 2017 11:07:09 GMT):
I pinged ramesh on #fabric-ci as well

dave.enyeart (Thu, 27 Apr 2017 11:07:09 GMT):
I pinged ramesh and ry on #fabric-ci as well

dave.enyeart (Thu, 27 Apr 2017 13:59:15 GMT):
verifications have resumed.

dave.enyeart (Thu, 27 Apr 2017 14:00:17 GMT):
next question - for gerrit CRs where we have decided to defer to 1.1, I assume we should 'abandon', put the link in Jira, and then recover them when we start working on 1.1?

cbf (Thu, 27 Apr 2017 15:17:39 GMT):
congrats @C0rWin on becoming the latest maintainer!

C0rWin (Thu, 27 Apr 2017 15:18:59 GMT):
:beers: :metal:

rjones (Thu, 27 Apr 2017 16:15:42 GMT):
@C0rWin you've been added to LDAP. You should have your +2 now :)

kostas (Thu, 27 Apr 2017 17:03:32 GMT):
Going back to @yacovm's question above, can someone confirm whether it works for them? It does here at this tip:

kostas (Thu, 27 Apr 2017 17:03:32 GMT):
Going back to @yacovm's question above, can someone confirm whether the end-to-end works for them? It does here at this tip:

kostas (Thu, 27 Apr 2017 17:03:35 GMT):
`it lg | head -n1 * ca3a1a2c - (HEAD -> master, origin/master, origin/HEAD) Merge "Nominate Artem Barger as a Fabric maintainer" (2 hours ago) `

kostas (Thu, 27 Apr 2017 17:03:35 GMT):
```git lg | head -n1 * ca3a1a2c - (HEAD -> master, origin/master, origin/HEAD) Merge "Nominate Artem Barger as a Fabric maintainer" (2 hours ago) ```

kostas (Thu, 27 Apr 2017 17:04:36 GMT):
But I had bumped into issues a couple of days ago, and I'm curious to see if Yacov is hitting those as well here. So, if someone can run the E2E on the latest master, let us know.

yacovm (Thu, 27 Apr 2017 17:05:30 GMT):
What are you talking about, the thing i said in consensus?

kostas (Thu, 27 Apr 2017 17:05:52 GMT):
The thing you wrote 10 lines above: https://chat.hyperledger.org/channel/fabric-maintainers?msg=F9zwKBa2yYz3JDvAs

yacovm (Thu, 27 Apr 2017 17:06:03 GMT):
Ah

kostas (Thu, 27 Apr 2017 17:06:09 GMT):
(Updated the message as well.)

HubertYoung (Thu, 27 Apr 2017 17:09:11 GMT):
Has joined the channel.

yacovm (Thu, 27 Apr 2017 19:48:38 GMT):
@kostas ok looks like it works now (or also before?)

kostas (Thu, 27 Apr 2017 19:49:40 GMT):
@yacovm I think it must have been working all along, based on my own tests last night on a bunch of intermediate commit levels.

kostas (Thu, 27 Apr 2017 19:50:11 GMT):
But there is something odd going on with the `sampleconfig.tar.bz` file not updated at all times, can reproduce this deterministically yet.

kostas (Thu, 27 Apr 2017 19:50:11 GMT):
But there is something odd going on with the `sampleconfig.tar.bz2` file not updated at all times, can reproduce this deterministically yet.

kostas (Thu, 27 Apr 2017 19:50:11 GMT):
But there is something odd going on with the `sampleconfig.tar.bz2` file not updated at all times, can't reproduce this deterministically yet.

kostas (Thu, 27 Apr 2017 19:50:22 GMT):
So if you bump into more issues, let me know.

kostas (Thu, 27 Apr 2017 19:50:22 GMT):
Can anyone help me figure out the right regular expression that will alert me whenever a changeset is added that touches anything on the `fabric/orderer` path?

lehors (Thu, 27 Apr 2017 21:45:01 GMT):
hello dear maintainers :-)

JonathanLevi (Thu, 27 Apr 2017 21:45:44 GMT):
Hello dear Arnaud :-)

lehors (Thu, 27 Apr 2017 21:45:57 GMT):
are you guys aware that our doc claims that you will review submitted bugs within 24h??

lehors (Thu, 27 Apr 2017 21:46:02 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#reporting-bugs

lehors (Thu, 27 Apr 2017 21:46:31 GMT):
"One of the project’s maintainers should respond to your issue within 24 hours. If not, please bump the issue with a comment and request that it be reviewed."

lehors (Thu, 27 Apr 2017 21:46:41 GMT):
isn't that setting the bar a bit high? :)

JonathanLevi (Thu, 27 Apr 2017 21:52:33 GMT):
Yes, it is high. But to be fair, some of us are/were trying to prioritize tickets/items from "newcommers".

JonathanLevi (Thu, 27 Apr 2017 21:53:53 GMT):
It is achievable while a bit high, though. Would you rather not have the 24 indication?

JonathanLevi (Thu, 27 Apr 2017 21:53:53 GMT):
It is achievable while a bit high, though. Would you rather not have the 24 hours indication?

JonathanLevi (Thu, 27 Apr 2017 21:55:16 GMT):
I mean, 14 days is a bit on the long side, I would have thought ;-)

lehors (Thu, 27 Apr 2017 21:58:48 GMT):
:)

lehors (Thu, 27 Apr 2017 21:59:21 GMT):
it is your ass that's on the line so if you guys are fine with it it's all right with me :)

JonathanLevi (Thu, 27 Apr 2017 22:01:17 GMT):
I can rephrase it to something that's a bit more PC...

lehors (Thu, 27 Apr 2017 22:02:08 GMT):
be my guest ;-)

JonathanLevi (Thu, 27 Apr 2017 22:02:54 GMT):
"We strive to respond to ... within ..., however, during ... we may experience ... "...

lehors (Thu, 27 Apr 2017 22:03:11 GMT):
oh, I thought you meant my statement LOL

JonathanLevi (Thu, 27 Apr 2017 22:03:19 GMT):
Or something along these lines. Good point

lehors (Thu, 27 Apr 2017 22:03:38 GMT):
yeah, that would probably set a more reasonable expectation

lehors (Thu, 27 Apr 2017 22:04:55 GMT):
I thought you said my statement wasn't PC, and I was going to say that with Gari in the project that's not something I fear ;-)

JonathanLevi (Thu, 27 Apr 2017 22:06:26 GMT):
No, I have given up on trying to paint your statements in a PC or even remotely compliant form of speech - especially not close to incidents relating to vagrant on Windows!

JonathanLevi (Thu, 27 Apr 2017 22:06:32 GMT):
I am afraid ;-)

lehors (Thu, 27 Apr 2017 22:06:50 GMT):
lol

JonathanLevi (Thu, 27 Apr 2017 22:07:04 GMT):
We just take the raw form/message, and update our docs accordingly ;-)

JonathanLevi (Thu, 27 Apr 2017 22:07:11 GMT):
Ha ha.

lehors (Thu, 27 Apr 2017 22:07:31 GMT):
SGTM! ;-)

lehors (Thu, 27 Apr 2017 22:08:00 GMT):
all right, bedtime for me

lehors (Thu, 27 Apr 2017 22:08:02 GMT):
take care

JonathanLevi (Thu, 27 Apr 2017 22:08:11 GMT):
GN

mskim (Fri, 28 Apr 2017 07:28:02 GMT):
Has joined the channel.

mastersingh24 (Fri, 28 Apr 2017 11:57:52 GMT):
[You are on my list now @lehors ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=cM2XB47jfYZsEMksd) @lehors

mastersingh24 (Fri, 28 Apr 2017 11:58:19 GMT):
[:zzz: ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=zwdoqvgvtc6N2SzeX) @lehors

lehors (Fri, 28 Apr 2017 11:59:50 GMT):
:-)

bmos299 (Fri, 28 Apr 2017 14:02:48 GMT):
@jimthematrix and I were chatting. We currently have many docker-compose.yaml files in many directories (fabric, fabric-ca, fabric-sdk-*). This can cause confusion as there are point in time considerations, configuration considerations, and env var consideratoins, etc. Should we establish some type of naming convention to communicate which docker-compose is being used? For example, docker-compose-V1-node.yaml, or docker-compose-V1-fabric-e2e_cli.yaml.

yacovm (Fri, 28 Apr 2017 14:04:35 GMT):
But, you can derive the context from the directory they reside in, and from their name, no?

bmos299 (Fri, 28 Apr 2017 15:41:54 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ABkgFBRgpFwYRNzfb) @yacovm yes, but sometimes we don't know this information and if the name is self-explanatory, it eliminates the need to ask questions for SRE's moving forward, especially if an docker-compose in a given directory has changed and someone is using an older version of the docker-compose itself.

kostas (Fri, 28 Apr 2017 16:18:12 GMT):
Looking at this screen here:

jimthematrix (Fri, 28 Apr 2017 16:18:40 GMT):
@here I have need to release a hotfix for node SDK alpha

jimthematrix (Fri, 28 Apr 2017 16:18:57 GMT):
I think the only way to make it work is first create a branch based on the alpha tag

jimthematrix (Fri, 28 Apr 2017 16:19:07 GMT):
I'm going to call it `v1.0.0-alpha.hotfix`

greg.haskins (Fri, 28 Apr 2017 16:19:14 GMT):
@jimthematrix thats correct

jimthematrix (Fri, 28 Apr 2017 16:19:17 GMT):
does that sound right to everybody?

greg.haskins (Fri, 28 Apr 2017 16:19:17 GMT):
well, hold on

greg.haskins (Fri, 28 Apr 2017 16:19:34 GMT):
the branch itself doesnt need to be version specific per se, and I dont advise this

jimthematrix (Fri, 28 Apr 2017 16:19:35 GMT):
i'm listening ;-)

jimthematrix (Fri, 28 Apr 2017 16:19:58 GMT):
so we can re-use it right?

greg.haskins (Fri, 28 Apr 2017 16:20:05 GMT):
make it "stream oriented"....iow, name the branch after the stream that it represents

greg.haskins (Fri, 28 Apr 2017 16:20:16 GMT):
in this case, it sounds like its a general alpha stream

jimthematrix (Fri, 28 Apr 2017 16:20:55 GMT):
what would be the "stream"?

greg.haskins (Fri, 28 Apr 2017 16:21:02 GMT):
since we already named the alpha "1.0.0-alpha", a stream of subsequent releases might be "1.0.0-alpha.x"

jimthematrix (Fri, 28 Apr 2017 16:21:13 GMT):
ah

jimthematrix (Fri, 28 Apr 2017 16:21:24 GMT):
was going to call it `v1.0.0-alpha.1`

greg.haskins (Fri, 28 Apr 2017 16:21:28 GMT):
and we can tag the new one 1.0.0-alpha.1 or .2 or something

jimthematrix (Fri, 28 Apr 2017 16:21:44 GMT):
ok so we are thinking the same then

greg.haskins (Fri, 28 Apr 2017 16:21:54 GMT):
suggest branch -> ".x" and release ".1" or ".2"

greg.haskins (Fri, 28 Apr 2017 16:21:59 GMT):
y

jimthematrix (Fri, 28 Apr 2017 16:22:08 GMT):
so `v1.0.0-alpha.1` it is then

greg.haskins (Fri, 28 Apr 2017 16:22:18 GMT):
for the tag, right?

greg.haskins (Fri, 28 Apr 2017 16:22:36 GMT):
for the branch, i would literally name it with ".x"

jimthematrix (Fri, 28 Apr 2017 16:22:40 GMT):
oh you mean literally the branch is `v1.0.0-alpha.x`

greg.haskins (Fri, 28 Apr 2017 16:22:43 GMT):
because you dont know if you will need .2

greg.haskins (Fri, 28 Apr 2017 16:22:45 GMT):
yes

jimthematrix (Fri, 28 Apr 2017 16:23:13 GMT):
got it, that makes sense, so we can re-use it for all hotfixes on alpha

greg.haskins (Fri, 28 Apr 2017 16:23:19 GMT):
thats just my opinion, but its how ive always done it

jimthematrix (Fri, 28 Apr 2017 16:23:26 GMT):
will do

greg.haskins (Fri, 28 Apr 2017 16:23:35 GMT):
right...the notion being we cant really predict if we will need .2, .3, etc

greg.haskins (Fri, 28 Apr 2017 16:23:42 GMT):
and why muddy up the namespace

jimthematrix (Fri, 28 Apr 2017 16:23:43 GMT):
you sound very authoritative so... ;-)

greg.haskins (Fri, 28 Apr 2017 16:24:19 GMT):
if my kids only agreed ;)

cbf (Fri, 28 Apr 2017 16:41:44 GMT):
@lehors @JonathanLevi it says *should* and that's how it SHOULD be... and it also says: "if not, bump the issue" - we could change that to suggest that they post to a chat channel if it is important

cbf (Fri, 28 Apr 2017 16:42:03 GMT):
I don't see it as a bar - I see it as an aspirational goal that we SHOULD be striving towards

lehors (Fri, 28 Apr 2017 16:46:56 GMT):
I know it says should, but it sets an expectation, especially with the following note on bumping, that seems unrealistic to me. If you think you can live up to it that's fine with me though.

cbf (Fri, 28 Apr 2017 17:04:09 GMT):
I don't think so

kostas (Fri, 28 Apr 2017 17:20:05 GMT):
Has anyone figured out the right regular expression so that we get notified when a changeset that touches component "foo" (say `fabric/orderer/*`) is uploaded?

kostas (Fri, 28 Apr 2017 17:20:14 GMT):

Message Attachments

kostas (Fri, 28 Apr 2017 17:20:23 GMT):
I'm looking at this screen in Gerrit ^^

yahtoo (Sun, 30 Apr 2017 07:41:03 GMT):
Has joined the channel.

mastersingh24 (Sun, 30 Apr 2017 20:15:06 GMT):
@kostas - looks like `project:fabric file:"^protos/.*"` works in the normal search bar so you might want to try `file:"^protos/.*"` for Only If

sideshowbarker (Mon, 01 May 2017 08:25:45 GMT):
Has joined the channel.

sideshowbarker (Mon, 01 May 2017 08:27:34 GMT):
Howdy. At https://github.com/hyperledger/fabric/blob/master/docs/source/getting_startedv2.rst#curl-the-artifacts-and-binaries the docs say to do this:

sideshowbarker (Mon, 01 May 2017 08:27:53 GMT):
`curl -L https://logs.hyperledger.org/sandbox/vex-yul-hyp-jenkins-2/fabric-verify-x86_64_1/5/release.tar.gz -o release.tar.gz 2> /dev/null; tar -xvf release.tar.gz`

sideshowbarker (Mon, 01 May 2017 08:28:10 GMT):
but `https://logs.hyperledger.org/sandbox/vex-yul-hyp-jenkins-2/fabric-verify-x86_64_1/5/release.tar.gz` is 404

sideshowbarker (Mon, 01 May 2017 08:28:42 GMT):
in fact the whole `https://logs.hyperledger.org/sandbox/` directory seems to be empty

sideshowbarker (Mon, 01 May 2017 08:30:55 GMT):
and seems to be the same in the upstream sources https://gerrit.hyperledger.org/r/gitweb?p=fabric.git;a=blob;f=docs/source/getting_startedv2.rst;h=2e6dcb7d195fd22c813cc1fcf32b0d573f5e52a4;hb=refs/heads/master#l44

yacovm (Mon, 01 May 2017 08:37:31 GMT):
@sideshowbarker could please write this message in the #fabric channel and not here? This isn't the right place for this ;)

yacovm (Mon, 01 May 2017 08:37:31 GMT):
@sideshowbarker could please write this message in the #fabric or #fabric-quality channel and not here? This isn't the right place for this ;)

sideshowbarker (Mon, 01 May 2017 08:43:34 GMT):
@yacovm OK yeah I posted also in #fabric already but the reason I posted here was I subsequently read https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#reporting-bugs

sideshowbarker (Mon, 01 May 2017 08:44:19 GMT):
which explicitly mentions posting to this channel for bug reports

yacovm (Mon, 01 May 2017 08:44:23 GMT):
@JonathanLevi :arrow_double_up:

yacovm (Mon, 01 May 2017 08:44:38 GMT):
understood, @sideshowbarker

sideshowbarker (Mon, 01 May 2017 08:45:16 GMT):
cheers & thanks, will follow up on #fabric

JonathanLevi (Mon, 01 May 2017 08:45:36 GMT):
@sideshowbarker, @yacovm: great timing. I'll also update that page accordingly.

JonathanLevi (Mon, 01 May 2017 08:45:51 GMT):
(thanks & good night)

greg.haskins (Mon, 01 May 2017 12:31:44 GMT):
I have two topics: the new consortium stuff, and ABI breakage

greg.haskins (Mon, 01 May 2017 12:32:38 GMT):
consortium first: is there a design overview somewhere?

greg.haskins (Mon, 01 May 2017 12:32:57 GMT):
I am finding the configtx.yaml relationships confusing

greg.haskins (Mon, 01 May 2017 12:35:18 GMT):
ABI breakage: we need a plan for 1.0 to ensure we have a cohesive and stable offering for at least some period of time (e.g. 1.x will not break compatibility) across all relative facilities (SDKs, shims, grpcs/protos, databases, etc)

greg.haskins (Mon, 01 May 2017 12:36:57 GMT):
Trying to do anything on top of 1.0 right now is, to be frank...horrible. I'm constantly trying to bring my applications up to date with the latest ABI to only find the target has moved again.....I understand why, we are trying to get 1.0 "right" and this is fine, and ABI breakage is to be expected

greg.haskins (Mon, 01 May 2017 12:37:22 GMT):
but we also need to make sure this _stops_ after 1.0 ships, at least for some clearly communicated period of time

greg.haskins (Mon, 01 May 2017 12:38:07 GMT):
if I am frustrated, think about how new users feel

greg.haskins (Mon, 01 May 2017 12:43:45 GMT):
so, I wanted to brainstorm on what kind of policies and governance we will put in place to help with this

mastersingh24 (Mon, 01 May 2017 12:58:45 GMT):
@greg.haskins - it was unfortunate that the merging of the final orderer config features broke things - but that should be it as far as I'm concerned (other than issues which come up trying to use it)

greg.haskins (Mon, 01 May 2017 12:59:42 GMT):
I just want to coordinate a few things surrounding this

greg.haskins (Mon, 01 May 2017 13:00:12 GMT):
1) that we are all on the same page as far as the what/when of breaking changes

greg.haskins (Mon, 01 May 2017 13:00:42 GMT):
2) that we decide how we can govern it going forward (just careful code reviews, CI integration, etc)

greg.haskins (Mon, 01 May 2017 13:02:37 GMT):
@mastersingh24 do you understand how the new consortium stuff is supposed to work, though?

greg.haskins (Mon, 01 May 2017 13:03:13 GMT):
im a little confused about the orderer/genesis vs the peer/channel relationship

weeds (Mon, 01 May 2017 13:05:54 GMT):
FYI peer scrum will start at 9:30 EST (1-888-426-6840 / 33682113)- I will post notes as usual in the fabric-peer-endorser-comitter channel

greg.haskins (Mon, 01 May 2017 13:45:46 GMT):
can anyone at least tell me what this error means:

greg.haskins (Mon, 01 May 2017 13:45:52 GMT):
```2017-05-01 13:31:13.931 UTC [orderer/common/broadcast] Handle -> WARN 1ac Rejecting CONFIG_UPDATE because: Error authorizing update: Error validating DeltaSet: Policy for [Groups] /Channel/Application not satisfied: Failed to reach implicit threshold of 1 sub-policies, required 1 remaining```

greg.haskins (Mon, 01 May 2017 13:46:13 GMT):
what is a sub-policy? and how do I define one?

kostas (Mon, 01 May 2017 15:08:07 GMT):
@greg.haskins: I can help, but the explanation may be a long one. I'll take this to #fabric. There is a document explaining the consortiums concept BTW, in `source/configtx.rst`.

greg.haskins (Mon, 01 May 2017 15:08:52 GMT):
@kostas ty, I saw that, but it wasnt easy to follow particularly w.r.t. driving configuration with configtx.yaml

kostas (Mon, 01 May 2017 15:09:15 GMT):
Oh I'm with you on that one.

greg.haskins (Mon, 01 May 2017 15:09:29 GMT):
@mastersingh24 pointed me down a path which I am exploring right now

greg.haskins (Mon, 01 May 2017 15:10:00 GMT):
I think the issue is one of permissions...(e.g. my channel-create is getting rejected for lack of permission

greg.haskins (Mon, 01 May 2017 15:10:12 GMT):
investigating, it looks like my genesis block is messed up

greg.haskins (Mon, 01 May 2017 15:10:15 GMT):
not sure why yet

greg.haskins (Mon, 01 May 2017 15:10:41 GMT):
it appears that both my OrdererMSP and PeerMSP have the same CA

greg.haskins (Mon, 01 May 2017 15:15:54 GMT):
@kostas im guessing that this is related to the fact that the genesis block is formed with only access to the OrdererMSP

greg.haskins (Mon, 01 May 2017 15:16:10 GMT):
how should I be generating this so that the proper MSP are accessible and included?

greg.haskins (Mon, 01 May 2017 15:17:07 GMT):
(and I just noticed you wanted to switch to #fabric

greg.haskins (Mon, 01 May 2017 15:17:11 GMT):
we can continue there

kostas (Mon, 01 May 2017 15:17:19 GMT):
(No worries, typing the response here.)

bmkor (Mon, 01 May 2017 16:35:13 GMT):
Has joined the channel.

weeds (Mon, 01 May 2017 20:41:08 GMT):
We had a good discussion on some tests we need to add to CI- we posted a lot of good information in fabric- quality

weeds (Mon, 01 May 2017 20:41:51 GMT):
these are system test harness code and some system type testing we can run for version 1.0 for Hypyerledger-Fabric

weeds (Mon, 01 May 2017 22:57:18 GMT):
FYI- The unit-test-coverage enhancement related CRs of the crypto squad are the following ones (elli sent to me in a note- so just adding here as fyi) 8709 - [FAB-3485] improve test coverage for msp 8707 - [FAB-3441] bccsp/sw AES test coverage 8629 - [FAB-3441] bccsp/signer test coverage 8701 - [FAB-3441] bccsp/sw test coverage 8703 - [FAB-3485] improve test coverage for msp/mgmt

MartinC (Tue, 02 May 2017 14:26:22 GMT):
Has joined the channel.

MartinC (Tue, 02 May 2017 14:30:23 GMT):
Hi folks, last week I posted to the mailing list and to #fabric-sdk about some work a colleague and I are doing on a REST API for Fabric for FAB-156. I was asked to post here as well to ensure you all were aware of it and have the opportunity to influence the design.

MartinC (Tue, 02 May 2017 14:30:57 GMT):
The design can be found here https://docs.google.com/document/d/1Kafw06IwtBbKFrUm8Hnwk8XYW7SyuqVbWad5VrPmvb8/edit?usp=sharing We are looking for feedback from the community on our design so far, to ensure that it meets your requirements. At this point validation of the use cases we have identified and feedback on the style of REST endpoints we are proposing would help us to refine the design. Please make your comments in the Google doc or ask us questions on rocketchat. Thanks

JonathanLevi (Tue, 02 May 2017 17:00:46 GMT):
@MartinC: Not sure who asked you to post this in this channel (which is for "internal" discussions amongst the maintainers...etc.), but thanks.

JonathanLevi (Tue, 02 May 2017 17:01:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=smSuMJYxXpmfHwaEq) @greg.haskins: I am with you, 100%.

JonathanLevi (Tue, 02 May 2017 17:03:01 GMT):
I really think we need to `stop` (yes, `stop`) and stabilize.

JonathanLevi (Tue, 02 May 2017 17:04:07 GMT):
We can probably "aim low" and simply work to get a good getting started guide (which Nick has and is putting together) and making sure that any new user can follow.

JonathanLevi (Tue, 02 May 2017 17:04:07 GMT):
We can probably "aim low" and simply work to get a good getting started guide (which Nick has and is putting together) and work to make sure that any new user can follow.

JonathanLevi (Tue, 02 May 2017 17:05:15 GMT):
We really need to fix the build, the e2e, and probably have a few days of just "fixing" what's not working for new users, and merge things that stabilize the build - e.g,., unit- and integration-tests.

greg.haskins (Tue, 02 May 2017 17:10:51 GMT):
@JonathanLevi yep

JonathanLevi (Tue, 02 May 2017 17:11:15 GMT):
We really have too many moving parts. It is a little bit "out of control".

greg.haskins (Tue, 02 May 2017 17:11:24 GMT):
I also think we need to stop using "rogue URLs" in the guides

greg.haskins (Tue, 02 May 2017 17:11:43 GMT):
I understand why they were used, and I am not pointing fingers

greg.haskins (Tue, 02 May 2017 17:12:37 GMT):
but things in the getting started guide need to have just as much release-engineering scrutiny as any other release or we risk creating a fragile offering, at least from the perspective of someone trying to follow it

JonathanLevi (Tue, 02 May 2017 17:13:24 GMT):
Yes, let alone that it is a terrible "first impression"

greg.haskins (Tue, 02 May 2017 17:13:51 GMT):
this means minimally stable URLs, semver (or semver-like) versioning, and, ideally, release approval by whatever governance is appropriate

JonathanLevi (Tue, 02 May 2017 17:14:12 GMT):
... it also creates so much work, where users/others report bugs/issues/ask for support - where the least we can do is making sure that the basic worked (& works!)

greg.haskins (Tue, 02 May 2017 17:14:59 GMT):
in my mind, the pain point is really "we dont want users to need to build the code", but until we have a release, thats really the only option

greg.haskins (Tue, 02 May 2017 17:15:30 GMT):
if we have a release, then we have a release, and make it a first class one with release engineering principles applied, and then use that one

JonathanLevi (Tue, 02 May 2017 17:15:41 GMT):
Right, sure.

JonathanLevi (Tue, 02 May 2017 17:16:09 GMT):
But at the moment, when they try to build it, and we have issues with, for example: `FABRIC_CFG_PATH` ...

JonathanLevi (Tue, 02 May 2017 17:16:22 GMT):
... it does not look good, to say the least.

greg.haskins (Tue, 02 May 2017 17:16:51 GMT):
when you say "build it", do you mean buildign from source, or following the getting-started guide ?

greg.haskins (Tue, 02 May 2017 17:17:06 GMT):
(I agree, any snag is a black eye)...

greg.haskins (Tue, 02 May 2017 17:17:17 GMT):
now I just want to understand which issue you are referring to

JonathanLevi (Tue, 02 May 2017 17:17:46 GMT):
"Not pointing fingers"... but even the basic configuration does not always work.

JonathanLevi (Tue, 02 May 2017 17:18:06 GMT):
(This particular case, came up from the getting started guide)

JonathanLevi (Tue, 02 May 2017 17:18:27 GMT):
But only yesterday, the `master` branch was broken.

greg.haskins (Tue, 02 May 2017 17:18:38 GMT):
ok...I know I have new team members who were trying to follow the guide and it wasnt working

JonathanLevi (Tue, 02 May 2017 17:18:42 GMT):
Currently, the `e2e` tests fail, etc.

JonathanLevi (Tue, 02 May 2017 17:19:07 GMT):
I think we need a few days (or, say a week), just to stabilize the current state.

greg.haskins (Tue, 02 May 2017 17:19:23 GMT):
yeah, agree

JonathanLevi (Tue, 02 May 2017 17:19:30 GMT):
[Sorry I'm not mincing words. We are not in a good "state"]

JonathanLevi (Tue, 02 May 2017 17:21:17 GMT):
I see more risk in merging new stuff at this point, and would rather hold off merging new-super-fancy-cool stuff until we can stabilize and get another stable "tagged" version.

JonathanLevi (Tue, 02 May 2017 17:21:55 GMT):
@binhn @mastersingh24 @cbf, ... WDYT ?

JonathanLevi (Tue, 02 May 2017 17:22:43 GMT):
(We did mention it last week in DC, that we wanted another tag. Maybe we work to get it even next week, if we stop merging so much, say for a week?)

JonathanLevi (Tue, 02 May 2017 17:22:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=savaPPy2DmxWDk2vL)

greg.haskins (Tue, 02 May 2017 17:29:01 GMT):
so what was the issue with FABRIC_CFG_PATH ?

greg.haskins (Tue, 02 May 2017 17:29:01 GMT):
@JonathanLevi: so what was the issue with FABRIC_CFG_PATH ?

greg.haskins (Tue, 02 May 2017 17:29:33 GMT):
I wrote the basic patch that added that, but it went in over a week ago IIRC so I wouldnt have expected a breakage in master yesterday

JonathanLevi (Tue, 02 May 2017 17:36:03 GMT):
I think Nick has updated/fixed it here: https://gerrit.hyperledger.org/r/#/c/8591

markparz (Tue, 02 May 2017 17:59:05 GMT):
Yea, we just need ^^ merged

markparz (Tue, 02 May 2017 17:59:51 GMT):
the URL was changed... we can change locations and such in the future, but let's just get the e2e working again quickly

weeds (Tue, 02 May 2017 19:24:46 GMT):
Agree with all above-- I think it would really help the community.

JonathanLevi (Tue, 02 May 2017 19:28:15 GMT):
--- BTW: As an aside, @rjones has informed me that `[ci skip] is removed and until someone re-implements it, [ci skip] won't be back`

JonathanLevi (Tue, 02 May 2017 19:28:52 GMT):
---

yacovm (Tue, 02 May 2017 19:29:34 GMT):
I think that implementing it in the unit test script is pretty easy - just go a `git show` and grep for the pattern.

yacovm (Tue, 02 May 2017 19:30:00 GMT):
the downside is - the environment is still built

yacovm (Tue, 02 May 2017 19:30:00 GMT):
the downside is - the environment is still built. But even back then- jenkins would've spin up a VM anyway, just to be "self-aborted"

cbf (Tue, 02 May 2017 20:21:15 GMT):
+1000 on @JonathanLevi and @greg.haskins dialog

JonathanLevi (Wed, 03 May 2017 01:23:02 GMT):
--- BTW: Do we see any issue with getting this merged https://gerrit.hyperledger.org/r/#/c/8591 (given the follow-ups that Greg has asked for, of course) ? I've `+2`'ed it, but I may have missed something. Thanks.

JonathanLevi (Wed, 03 May 2017 01:23:56 GMT):
--- And... thank you Chris for the above.

weeds (Wed, 03 May 2017 11:23:27 GMT):
@rameshthoomu @bmoss209 Team- wanted you aware that Ramesh/Barry agreed to have a daily run in the morning EST time and post the results of the build/CI tests every day whether they fail/pass on the fabric-ci channel (typically they had only posted when they passed. When they are failures- they have been opening "highest" bugs). I think this should help everyone with a bit more clarity. Meanwhile. @Ratnakar is working to get us to a single set of compose scripts/docker image that we can utilize in the CI so our results are more consistent when we run all the tests- he's comparing what he's done with what Greg Haskins has done to see if he missed anything. Once that is done, @rameshtoomu will include in the daily run.

Ratnakar (Wed, 03 May 2017 11:23:27 GMT):
Has joined the channel.

weeds (Wed, 03 May 2017 11:24:01 GMT):
if there is any input on this- please let Ramesh/Barry or Ratnakar know. Thanks!

JonathanLevi (Wed, 03 May 2017 12:24:01 GMT):
@weeds Was this supposed to be posted in the fabric-maintainers channel?

JonathanLevi (Wed, 03 May 2017 12:25:37 GMT):
[ I have posted it in #fabric-quality https://chat.hyperledger.org/channel/fabric-quality?msg=QXD3uorpW8ywEKgGy ]

JonathanLevi (Wed, 03 May 2017 12:25:53 GMT):
[ I have posted it in #fabric-quality ]

mrkiouak (Wed, 03 May 2017 13:13:34 GMT):
I should think the maintainers consider whether or not the build breaks when approving CRs. There are reason to break builds and approve a CR, but there are also obviously reasons to wait on approving until after a break will be avoided. Speaking as a consumer of the project, more consistency and clarity in what constitutes latest, and what constitutes latest working (inc. cross project e.g. node-sdk to fabric) is *greatly* needed.

JonathanLevi (Wed, 03 May 2017 13:16:10 GMT):
@mrkiouak, first and foremost, I completely agree with you. In fact, gerrit does not allow us to submit/merge CRs where the build is breaking.

JonathanLevi (Wed, 03 May 2017 13:16:10 GMT):
@mrkiouak, first and foremost, `I completely agree with you`. In fact, gerrit does not allow us to submit/merge CRs where the build is breaking.

JonathanLevi (Wed, 03 May 2017 13:16:10 GMT):
@mrkiouak, first and foremost, `I completely agree with you. In fact, gerrit does not allow us to submit/merge CRs if the build is broken/tests did not pass.

JonathanLevi (Wed, 03 May 2017 13:16:10 GMT):
@mrkiouak, first and foremost, `I completely agree with you`. In fact, gerrit does not allow us to submit/merge CRs if the build is broken/tests did not pass.

JonathanLevi (Wed, 03 May 2017 13:16:55 GMT):
That said, we have a few (known!) issues that we are currently working on. One of them is better coverage. We don't have good coverage.

JonathanLevi (Wed, 03 May 2017 13:16:55 GMT):
That said, we have a few (known!) issues that we are currently working on. One of them is better coverage. We don't have *good test coverage*.

JonathanLevi (Wed, 03 May 2017 13:16:55 GMT):
That said, we have a few (known!) issues that we are currently working on. One of them is better coverage. We don't have *good test coverage*... so, given that, code compiling + tests passing is `a necessary but not sufficient` criteria.

JonathanLevi (Wed, 03 May 2017 13:18:45 GMT):
(Please kindly note that I haven't used *enough*, for a reason. In the past, we had some threshold for test coverage, but that wasn't sufficient, at all)

JonathanLevi (Wed, 03 May 2017 13:18:45 GMT):
(Please note that I haven't used *enough*, for a reason. In the past, we had some threshold for test coverage, but that wasn't sufficient, at all)

JonathanLevi (Wed, 03 May 2017 13:19:54 GMT):
As for the second part of you paragraph, the things we should probably push to improve is much better *communication*, especially when it comes to "breaking" changes, such as what we had here with the configuration...

JonathanLevi (Wed, 03 May 2017 13:20:54 GMT):
Along with, a more well-defined policy (that will be well-communicated), but first, we need to have that policy/guidelines, e.g., for merges.

JonathanLevi (Wed, 03 May 2017 13:20:54 GMT):
Along with, a `well-defined policy` (that will be well-communicated), but first, we need to have that policy/guidelines, e.g., for merges [where we highlight when we are working under `feature freeze`, `API freeze`, `merge freeze`, ... etc.]

JonathanLevi (Wed, 03 May 2017 13:23:41 GMT):
Now as for your final sentence, regarding consistency and clarity regarding what's the "latest", there are 2 things "in the making":

JonathanLevi (Wed, 03 May 2017 13:23:41 GMT):
Now as for your final sentence, regarding consistency and clarity regarding what's the `latest`, there are 2 things "in the making":

JonathanLevi (Wed, 03 May 2017 13:23:41 GMT):
Now wrt your final sentence, regarding consistency and clarity regarding what's the `latest`, there are 2 things "in the making":

JonathanLevi (Wed, 03 May 2017 13:24:03 GMT):
1) We are about to change [subject to a quick vote] our branching strategy... that is, we are going to have an `always-building` `master` branch, and release/tag branches that branch off it.

JonathanLevi (Wed, 03 May 2017 13:25:23 GMT):
2) We are considering another tag next week, that will align / make "ends meet", especially WRT "cross project"/"sub project" versionnining

JonathanLevi (Wed, 03 May 2017 13:25:23 GMT):
2) We are considering another `tagged` release, early next week, that will align / make "ends meet", especially WRT "cross project"/"sub project" versionining

JonathanLevi (Wed, 03 May 2017 13:27:14 GMT):
Pardon my long answer, but I didn't want to simply reply with "I agree" ;-)

JonathanLevi (Wed, 03 May 2017 13:27:14 GMT):
Pardon my long answer, but I didn't want to simply reply with `I completely agree with you` ;-)

JonathanLevi (Wed, 03 May 2017 13:28:10 GMT):
I'm going to send out an email to the entire list with the above, as I am under the impressions that there are more people that are in agreement with what you wrote above.

JonathanLevi (Wed, 03 May 2017 13:31:29 GMT):
N.B. Please kindly note, though, to be fair to others, that while `probably not as well communicated as it could have been', that we were aware/informed that some merges will put the SDKs a bit behind, and the Node SDK has just caught up with them recent config changes. This does not take away from how much I'm in agreement with you, though.

JonathanLevi (Wed, 03 May 2017 13:31:29 GMT):
____ N.B. Please kindly note, though, to be fair to others, that while *probably not as well communicated as it could have been*, that we were aware/informed that some merges will put the SDKs a bit behind (while Node SDK has just caught up with them recent config changes). This does not take away from how much I'm in agreement with you, though!

weeds (Wed, 03 May 2017 14:54:03 GMT):
+++ on Jonathan's comment.

greg.haskins (Wed, 03 May 2017 16:51:58 GMT):
I think @mrkiouak and @JonathanLevi are talking about two slightly different points above

JonathanLevi (Wed, 03 May 2017 16:52:17 GMT):
Please go ahead Greg.

JonathanLevi (Wed, 03 May 2017 16:53:09 GMT):
[We did end up with a relatively follow up chat, but I think we should discuss all matters relevant]

greg.haskins (Wed, 03 May 2017 16:53:20 GMT):
point 1) ABI breakages: these may or may not be something that show up as a CI failure, but impact users...better automation around integration testing may help identify when this happens accidentally...we may also know ahead of time that this is the case and are making an educated decision to merge it anyway

greg.haskins (Wed, 03 May 2017 16:54:08 GMT):
point 2) gerrit allowing us to merge CRs which fail tests...we have psuedo coverage here, but its not perfect

greg.haskins (Wed, 03 May 2017 16:54:31 GMT):
for instance, we employ what I would classify as a "single tier" system

greg.haskins (Wed, 03 May 2017 16:55:07 GMT):
that is, someone submits a CR, CI verifies that CR in a vacuum....and if approved, its merged into the final tree

greg.haskins (Wed, 03 May 2017 16:55:33 GMT):
most of the time, the -verify check and -merge check align, but they dont always

greg.haskins (Wed, 03 May 2017 16:56:02 GMT):
(for instance, if something else was merged after the CR was sumitted but before it was merged, its conflict may not be detected until we run -merge job

greg.haskins (Wed, 03 May 2017 16:56:49 GMT):
to address point 2, I think we should design/build what I would classify as a multi-tiered pipeline

greg.haskins (Wed, 03 May 2017 16:57:17 GMT):
that is, the gerrit front end is the human approval and front-line -verify pipe-stage

greg.haskins (Wed, 03 May 2017 16:58:13 GMT):
once approved through gerrit, it may move on to a subsequent stage (effectively what we do with -merge today), with the difference being it only shows up in master after it passes that stage

greg.haskins (Wed, 03 May 2017 16:58:56 GMT):
so "gerrit submit" becomes more like "human approved for merge consideration" rather than "merge it and pray" like we have today

greg.haskins (Wed, 03 May 2017 17:00:05 GMT):
I think there are two basic short comings w.r.t. point 2

greg.haskins (Wed, 03 May 2017 17:00:37 GMT):
we have no way to keep those bad merges out of the HEAD, and we have a poor notification system when those bad merges occur

greg.haskins (Wed, 03 May 2017 17:01:11 GMT):
today, it just shows up as a V-1 in the CR after the merge...which is fine if you happen to look back at gerrit or happen to have a better email filter than I do and notice it

greg.haskins (Wed, 03 May 2017 17:02:11 GMT):
but what would be better (IMO) is a big giant red FAIL on a jenkins dashboard with appropriate notices going out, as well as the ability to prevent it from being promoted to HEAD

greg.haskins (Wed, 03 May 2017 17:02:26 GMT):
thats all @JonathanLevi , im done

JonathanLevi (Wed, 03 May 2017 17:03:03 GMT):
Ha ha, thanks ;-)

JonathanLevi (Wed, 03 May 2017 17:03:53 GMT):
A few things then: I really wanted (and still want) to put an *API freeze* state.

JonathanLevi (Wed, 03 May 2017 17:04:13 GMT):
If you recall, this included the config and ABI (in "my world")

greg.haskins (Wed, 03 May 2017 17:04:21 GMT):
yep, i agree

JonathanLevi (Wed, 03 May 2017 17:04:34 GMT):
This is to me, a good measure (or some indication) of stability.

greg.haskins (Wed, 03 May 2017 17:04:48 GMT):
lets call it more general: compatibility freeze or ABI freeze

greg.haskins (Wed, 03 May 2017 17:05:06 GMT):
it would include anything that impacts disparate components ability to communicate

greg.haskins (Wed, 03 May 2017 17:05:14 GMT):
config files, wire protocols, APIs, etc

JonathanLevi (Wed, 03 May 2017 17:05:37 GMT):
Fine with me. I can adapt to that term *ABI freeze*... no problem.

JonathanLevi (Wed, 03 May 2017 17:07:16 GMT):
Second, we can still allow a change in extreme cases, when such a "freeze" is broken... but it will require us to make a lot of "noise" around it, from testing, to release notes and close to 1.0 (and definitely after it)... to start thinking about *deprecation procedure*... (e.g., support both APIs for 2 versions, etc.)

JonathanLevi (Wed, 03 May 2017 17:07:16 GMT):
Second, we can still allow a change in extreme cases, when such a "freeze" is broken... but it will require us to make a lot of "noise" around it, from testing, to release notes and close to 1.0 (and definitely after it)... to start thinking about an *API change and/or deprecation procedure*... (e.g., support both APIs for 2 versions, etc.)

yacovm (Wed, 03 May 2017 17:08:10 GMT):
There is something you overlook here @JonathanLevi and that is - access control change has a very similar effect on what you describe.

yacovm (Wed, 03 May 2017 17:08:10 GMT):
There is something you overlook here @JonathanLevi and that is - access control change sets have a very similar effect on what you describe.

greg.haskins (Wed, 03 May 2017 17:08:31 GMT):
I think in earlier steps, it can be "decide+noise" and longer term it needs to be a deterministic policy

yacovm (Wed, 03 May 2017 17:08:48 GMT):
You can "break the build" with introducing an AC enforcement without changing anything in the API/ABI

JonathanLevi (Wed, 03 May 2017 17:08:49 GMT):
Yes, I agree Greg. I don't want to suggest/employ it "too soon".

greg.haskins (Wed, 03 May 2017 17:08:53 GMT):
for example, golang community is fairly strict about ABI compatibility across 1.x

greg.haskins (Wed, 03 May 2017 17:09:27 GMT):
at some point, we will need to offer some kind of guarantee as well (1.x, 1.0.x, whatever)

JonathanLevi (Wed, 03 May 2017 17:09:31 GMT):
Yacov, a broken build is completely out of question (in this scenario). We are talking about a passing build, while "under the radar" the ABI changes and we don't notify thers.

JonathanLevi (Wed, 03 May 2017 17:10:24 GMT):
Yes, Greg. I agree. To be honest, this stuff really costs a lot (financially), let's alone the nerves, sleepless nights and hairloss, in my case.

JonathanLevi (Wed, 03 May 2017 17:10:35 GMT):
:-)

JonathanLevi (Wed, 03 May 2017 17:11:26 GMT):
It affects so many of us, who build stuff on top of fabric... and such changes make it hard/difficult for all of us to meet deadlines and set up plans/budgets, etc.

greg.haskins (Wed, 03 May 2017 17:11:47 GMT):
the downside to the notion of a freeze is it tends to precipitate the exact opposite leading up to the freeze ;)

greg.haskins (Wed, 03 May 2017 17:11:57 GMT):
which is where we find ourselves now, i think

greg.haskins (Wed, 03 May 2017 17:12:08 GMT):
("quick get $X in!"

JonathanLevi (Wed, 03 May 2017 17:12:36 GMT):
Yes, a "merge-merge-merge" kind of freeze ;-)

greg.haskins (Wed, 03 May 2017 17:13:18 GMT):
but I agree....ive been slogging through one breaking change after another for months now, and I am still not caught up

JonathanLevi (Wed, 03 May 2017 17:13:57 GMT):
How can we help? What do you suggest we do better? I want us to start converging.

greg.haskins (Wed, 03 May 2017 17:14:02 GMT):
UX spiraled down for me starting with CR5555 back in Feb and I still havent recovered

JonathanLevi (Wed, 03 May 2017 17:14:13 GMT):
I'm really happy to "close the gate" for a while, and just stabilize, really.

JonathanLevi (Wed, 03 May 2017 17:14:23 GMT):
I don't see it as a set-back. It will pay off.

greg.haskins (Wed, 03 May 2017 17:14:36 GMT):
I agree, and I know why its happening

JonathanLevi (Wed, 03 May 2017 17:14:41 GMT):
There is more risk now, with so many moving parts...

greg.haskins (Wed, 03 May 2017 17:15:01 GMT):
my bigger concern isnt so much what happened between v0.6 and now, but what will happen once v1.0 is cut

JonathanLevi (Wed, 03 May 2017 17:15:09 GMT):
.. while at the same time, we get a lot *less feedback*, as people are giving up trying.

greg.haskins (Wed, 03 May 2017 17:15:34 GMT):
e.g. will we have the sufficient discipline, policy, and monitoring to ensure that all stops, as appropriate

JonathanLevi (Wed, 03 May 2017 17:15:44 GMT):
So many people write to me (personally) and ask me, "so, shall we get back to farbic now, is it better?"

JonathanLevi (Wed, 03 May 2017 17:16:40 GMT):
I think both: 1. From now to 1.0 2. From 1.0 onwards (even 1.0 - 1.1.0 and 1.2.0 ... with 1.0.3 and 1.1.2)

JonathanLevi (Wed, 03 May 2017 17:16:40 GMT):
I think both: 1. From now to 1.0 2. From 1.0 onwards (even 1.0.0 - 1.1.0 and 1.2.0 ... with 1.0.3 and 1.1.2)

JonathanLevi (Wed, 03 May 2017 17:17:04 GMT):
Imagine us branching without a strong enough API...

JonathanLevi (Wed, 03 May 2017 17:17:09 GMT):
Or policy

JonathanLevi (Wed, 03 May 2017 17:17:33 GMT):
(Assume we suddenly "ace" the *discipline* part)

JonathanLevi (Wed, 03 May 2017 17:18:34 GMT):
--- Here's a "bomb": do we really not need API versioning?

JonathanLevi (Wed, 03 May 2017 17:18:43 GMT):
[I know you are going to jump ;-)]

JonathanLevi (Wed, 03 May 2017 17:19:06 GMT):
We know we really need it.... when do we get it in? Where do we test? etc.

greg.haskins (Wed, 03 May 2017 17:19:16 GMT):
can you clarify what you mean? because that can be interpreted different ways

JonathanLevi (Wed, 03 May 2017 17:19:32 GMT):
Assume we expose stuff in version 1.0

JonathanLevi (Wed, 03 May 2017 17:20:01 GMT):
And one starts consuming it. And you have a cluster (or network) with different versions installed.

JonathanLevi (Wed, 03 May 2017 17:20:12 GMT):
1. How do you know that? ;-)

JonathanLevi (Wed, 03 May 2017 17:20:22 GMT):
2. What do we support (backward/foward)

JonathanLevi (Wed, 03 May 2017 17:20:22 GMT):
2. What do we support (backward/forward)

JonathanLevi (Wed, 03 May 2017 17:20:43 GMT):
Can be peers/orderers and/or any given function

JonathanLevi (Wed, 03 May 2017 17:20:53 GMT):
Provided/consumed.

greg.haskins (Wed, 03 May 2017 17:20:58 GMT):
so in this case, it sounds like we are talking about protobuf/grpc/wireprotocol kinds of detail

JonathanLevi (Wed, 03 May 2017 17:21:25 GMT):
Say tomorrow, we have an urgent patch, creating a v1.0.1

JonathanLevi (Wed, 03 May 2017 17:21:49 GMT):
Or REST API, or anything really. But yes, gRPC is a good example

JonathanLevi (Wed, 03 May 2017 17:22:25 GMT):
I think we need to think about how we can stabilize the API, in that sense too.

greg.haskins (Wed, 03 May 2017 17:22:35 GMT):
i think the notion of compatibility is going to get really complex in a network like this (for instance, chaincode/shim/golang, peer/orderer, etc, etc, but lets ignore that for a minute

JonathanLevi (Wed, 03 May 2017 17:22:39 GMT):
As part of the convergence.

JonathanLevi (Wed, 03 May 2017 17:22:45 GMT):
Sure, go on.

greg.haskins (Wed, 03 May 2017 17:22:57 GMT):
lets just talk about general wire-protocol compatiblity between say, peer v1.0.0 and v1.0.1

greg.haskins (Wed, 03 May 2017 17:23:44 GMT):
at that level of the conversation, the way I have designed any protocol of that nature could be describe as having the following traits

JonathanLevi (Wed, 03 May 2017 17:23:47 GMT):
Yup. That's the first thing that sprang to mind when you mentioned "what will happen once v1.0 is cut"

greg.haskins (Wed, 03 May 2017 17:24:34 GMT):
1) some kind of version/magic combo negotiated at the core of the protocol....incongruence with version/magic means the protocol is incompatible

greg.haskins (Wed, 03 May 2017 17:25:10 GMT):
2) some kind of backwards/forwards compatibility mechanism (such as protobufs) for the basic transport

greg.haskins (Wed, 03 May 2017 17:25:22 GMT):
and 3) never ever ever change(1) unless you really have no other choice

greg.haskins (Wed, 03 May 2017 17:26:26 GMT):
so, assuming v1.0.0 -> v1.0.1 could be handled in a protobuf like manner (extending the message fields, etc), that would be the default modus operandi

greg.haskins (Wed, 03 May 2017 17:27:32 GMT):
and if for whatever extreme circumstances might preclude this from being possible/advised, bump the version/magic and at least rest assured that you will have a nice deterministic response to a heterogenous network

greg.haskins (Wed, 03 May 2017 17:28:16 GMT):
(as opposed to whatever madness may ensue if you just allow the incongruence to go undetected and result in hard to diagnose failures)

greg.haskins (Wed, 03 May 2017 17:29:01 GMT):
for rest, this might simply mean all apis are rooted under a versioned path, like /api/v1, /api/v2, etc

greg.haskins (Wed, 03 May 2017 17:29:30 GMT):
for protobufs, I tend to build a "message Negotiate" object that is negotiated as part of a handshake, etc

greg.haskins (Wed, 03 May 2017 17:30:10 GMT):
@JonathanLevi EOM

JonathanLevi (Wed, 03 May 2017 17:31:36 GMT):
I'm with you with the preference for 2), the REST API with the rooted version and the msg negotiate.

JonathanLevi (Wed, 03 May 2017 17:32:24 GMT):
I don't know how much of this is already done, documented and tested, to be honest... for us to feel comfortable that we can cut a *beta* with a frozen API as early as next week.

JonathanLevi (Wed, 03 May 2017 17:33:21 GMT):
That's my main concern. I don't want to declare "success" to early and then end up in a mess. The `alpha` tag was not that bad, but it became very clear that we need some "freeze" phase, for collecting input/feedback.

JonathanLevi (Wed, 03 May 2017 17:33:21 GMT):
That's my main concern. I don't want to declare "success" to early and then end up in a mess. The *1.0.0-alpha* tag was OK/not that bad, but it became very clear that we need some "freeze" phase, for collecting input/feedback.

JonathanLevi (Wed, 03 May 2017 17:34:15 GMT):
We merged a lot very close to that tag.

greg.haskins (Wed, 03 May 2017 17:34:50 GMT):
yes, same that is happening now

JonathanLevi (Wed, 03 May 2017 17:35:04 GMT):
Yes, exactly - and I would like us to slow down somehow, in order to converge...

JonathanLevi (Wed, 03 May 2017 17:35:15 GMT):
I feel that the API/ABI freeze is really key.

greg.haskins (Wed, 03 May 2017 17:35:22 GMT):
personally, i dont see harm in snapping -alpha2

greg.haskins (Wed, 03 May 2017 17:35:55 GMT):
and yes, collectively strategizing/agreeing on what goes in next, with a mind on convergence/stability

JonathanLevi (Wed, 03 May 2017 17:49:35 GMT):
Let's do this...

JonathanLevi (Wed, 03 May 2017 17:49:35 GMT):
I'm with you. How about we do this:

JonathanLevi (Wed, 03 May 2017 17:50:06 GMT):
I will try to collect all/most of the feedback, and we will work towards a `1.0.0-alpha-stable`...

JonathanLevi (Wed, 03 May 2017 17:50:14 GMT):
Even early next week.

JonathanLevi (Wed, 03 May 2017 17:50:52 GMT):
I don't really mind the name of the tag. I have just heard about some objections to alpha2 last week. Honestly, no tag/name will keep me up at night - I have 0 preferences.

JonathanLevi (Wed, 03 May 2017 17:51:19 GMT):
I would rather us declare a `beta` though, when we all feel that that the API/ABI is a lot more stable.

mrkiouak (Wed, 03 May 2017 17:51:44 GMT):
I just want to add my 2 cents that I agree api should be stable prior to calling it a beta

JonathanLevi (Wed, 03 May 2017 17:51:46 GMT):
That first step, will allow us to 'align" everything, "quickly".

JonathanLevi (Wed, 03 May 2017 17:52:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yuDdd2eWXmwThciuN) Thank you Matt.

JonathanLevi (Wed, 03 May 2017 17:52:23 GMT):
Yes, I am really trying to follow "conventions", as much as possible.

JonathanLevi (Wed, 03 May 2017 17:53:02 GMT):
We have pushed in so much between the alpha and today... that we could all use a soft "rebase"

JonathanLevi (Wed, 03 May 2017 17:53:30 GMT):
Even at the cost of merging "less" [with G-d's help! ;-)] for a few days.

JonathanLevi (Wed, 03 May 2017 17:54:09 GMT):
In a way, it's amazing how merging less is more difficult than the other way around - but I think we should really be disciplined and push for it.

JonathanLevi (Wed, 03 May 2017 17:58:21 GMT):
---

greg.haskins (Wed, 03 May 2017 17:59:16 GMT):
I dont really understand the rationale against "alpha2" unless its simply because its felt we are ready for the next step (beta)

greg.haskins (Wed, 03 May 2017 18:00:09 GMT):
what I would discourage in general, however, is something that paints us in a corner (making subsequent releases hard) or something that needs explaination

JonathanLevi (Wed, 03 May 2017 18:00:27 GMT):
It was something around some pre-agreed naming that people have discussed. I agree - I don't feel like we are *beta-ready*

greg.haskins (Wed, 03 May 2017 18:00:38 GMT):
e.g. "alpha-stable" is kind of the former....what if something isnt right and we need to hotfix it

JonathanLevi (Wed, 03 May 2017 18:01:17 GMT):
I hear you. We still plan on a beta, RC1 and RC2. I'm fine with other name suggestions.

JonathanLevi (Wed, 03 May 2017 18:01:33 GMT):
(I can speak/type for myself)

greg.haskins (Wed, 03 May 2017 18:02:15 GMT):
im fine with the notion of pre-agreed tags (rcX, beta, alpha, etc) but I see absolutely nothing wrong with version qualifying them either

greg.haskins (Wed, 03 May 2017 18:02:30 GMT):
e.g. alpha, alpha2, whatever...just like rc1 rc2

greg.haskins (Wed, 03 May 2017 18:03:00 GMT):
i think its a bit presumptuous to assume you'll absolutely, positively, never need to hotfix it either

greg.haskins (Wed, 03 May 2017 18:03:14 GMT):
my experience is the opposite ;)

JonathanLevi (Wed, 03 May 2017 18:03:42 GMT):
I'll try to come up with something less *stable* then... OK ;-)

JonathanLevi (Wed, 03 May 2017 18:03:46 GMT):
BTW: I have to head out (but others, please chime in), in the meantime, just to quickly bring it up here, are there any objection to this proposed new branching model from @dhuseby ("Coach Dave") ? https://docs.google.com/document/d/1Lb-TjMTdG9wEG1QlkjxyWN2FYeWYLaUGdpEUdV8-hEw/edit

greg.haskins (Wed, 03 May 2017 18:05:27 GMT):
theres nothing wrong with the model...its pretty much the way ive run most projects ive worked on...but I would point out that we need some retooling of the CI process to make that successful

greg.haskins (Wed, 03 May 2017 18:05:50 GMT):
without that, that model will work poorly

cbf (Wed, 03 May 2017 18:19:54 GMT):
alpha2 is fine I guess

JonathanLevi (Wed, 03 May 2017 23:02:10 GMT):
So as I/we don't hear/read any objections to this, I am going to compose a quick/formal email and pass it around... [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=xDzYihPM7bR4C3zGq)

JonathanLevi (Wed, 03 May 2017 23:02:57 GMT):
We really need to get cracking on this, if we proceed to work towards an *alpha-working* or so tag - next week.

JonathanLevi (Wed, 03 May 2017 23:32:13 GMT):
---

JonathanLevi (Wed, 03 May 2017 23:32:57 GMT):
--- Amigos, I'm breaking the above to a few steps. Let's start with this: https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/000833.html please?

greg.haskins (Wed, 03 May 2017 23:44:51 GMT):
Lets please backburner the branching discussion until 1.0 is cut...I suspect its actually a big deal to implement the changes to CI and I dont think we can afford the distraction

greg.haskins (Wed, 03 May 2017 23:45:05 GMT):
for now, KISS...we have one branch and stablize it

greg.haskins (Wed, 03 May 2017 23:45:05 GMT):
for now, KISS...we have one branch and stabilize it

tkuhrt (Thu, 04 May 2017 00:24:12 GMT):
Regarding semantic versioning, I pulled the following from semver.org: ```Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.```

tkuhrt (Thu, 04 May 2017 00:26:46 GMT):
Regarding the branches, would it be difficult to create the `master` branch from the previous `1.0.0-alpha` tag and make the `current master` branch the new `dev` branch? This would allow us to move to the branch strategy suggested by @dhuseby while still allowing stabilization.

JonathanLevi (Thu, 04 May 2017 01:02:53 GMT):
It's not difficult. The thing is that a lot of stuff has been merged between that *1.0.0-alpha* and the current *master*.

JonathanLevi (Thu, 04 May 2017 01:03:34 GMT):
But even with that in mind, we can probably "split" to develop and master, within a day or two... say, by the end of the week - I believe.

JonathanLevi (Thu, 04 May 2017 01:04:18 GMT):
Initially, we can simply just "clone" the CI jobs to run on both, parallel.

JonathanLevi (Thu, 04 May 2017 01:04:32 GMT):
(Being super pragmatic here)

JonathanLevi (Thu, 04 May 2017 01:05:17 GMT):
So that it gives others time to get the right pipeline/workflow between *develop* and *master*... and the "up/down merging" steps.

JonathanLevi (Thu, 04 May 2017 01:06:19 GMT):
The current *master* looks a lot better after the recent changes/last few days (including the Node SDK stuff, and other fixes).

JonathanLevi (Thu, 04 May 2017 01:09:29 GMT):
The current *master* looks a lot better after the recent changes/last few days (off the top of my head: it now includes the Node SDK stuff, and other fixes/features TLS, org, genesis block, configs... and a few older ones for Vagrant fixes, input validations/tests)... but again, we really need to test more, etc.

JonathanLevi (Thu, 04 May 2017 01:11:01 GMT):
Thoughts? [@mastersingh24, @cbf, @binhn, others, ...] It will not be the "full shebang" with the auto-reverting CI, etc... but it will give us some separation.

JonathanLevi (Thu, 04 May 2017 01:11:01 GMT):
Thoughts? [ @mastersingh24, @cbf, @binhn, @yacov, @jimthematrix , others, ...?] It will not be the "full shebang" with the auto-reverting CI, etc... but it will give us some separation.

JonathanLevi (Thu, 04 May 2017 01:11:51 GMT):
Thoughts? [ @mastersingh24, @cbf, @binhn, @yacovm , @jimthematrix , others, ...?] It will not be the "full shebang" with the auto-reverting CI, etc... but it will give us some separation.

JonathanLevi (Thu, 04 May 2017 01:13:04 GMT):
--- BTW: *1.0.0-alpha.1* sounds good to me as well...

JonathanLevi (Thu, 04 May 2017 01:13:42 GMT):
(which also gives us room for .2, .3, if push comes to shove]

jimthematrix (Thu, 04 May 2017 02:08:04 GMT):
@JonathanLevi @greg.haskins enlightening discussions above, thanks for typing it out your thoughts, I agree with an `alpha2` release but have a slight suggestion to the concrete naming: instead of `1.0.0-alpha.1`, `1.0.0-alpha.2` etc., let's call it `1.0.0-alpha2`, `1.0.0-alpha3` etc.

jimthematrix (Thu, 04 May 2017 02:08:04 GMT):
@JonathanLevi @greg.haskins enlightening discussions above, thanks for typing out your thoughts, I agree with an `alpha2` release but have a slight suggestion to the concrete naming: instead of `1.0.0-alpha.1`, `1.0.0-alpha.2` etc., let's call it `1.0.0-alpha2`, `1.0.0-alpha3` etc.

jimthematrix (Thu, 04 May 2017 02:08:43 GMT):
this allows us to put out hotfixes to each alpha releases, by using the `.n` suffix

jimthematrix (Thu, 04 May 2017 02:10:30 GMT):
because by semver syntax: ```1.0.0-alpha < 1.0.0-alpha.1 <1.0.0-alpha1 < 1.0.0-alpha1.1 < 1.0.0-alpha2 ...```

jimthematrix (Thu, 04 May 2017 02:11:09 GMT):
node SDK already released a hotfix to 1.0.0-alpha release, and is called 1.0.0-alpha.1

jimthematrix (Thu, 04 May 2017 02:11:28 GMT):
it was due to `grpc` update breaking backward compatibility

jimthematrix (Thu, 04 May 2017 02:17:38 GMT):
of course the hotfixes should be reserved to only those absolutely critical and really easy fixes (easy as in time consumption so time is not taken away from hardening the main release stream)

jimthematrix (Thu, 04 May 2017 02:20:55 GMT):
same for beta and rc: `1.0.0-beta`, `1.0.0-beta2`, `1.0.0-rc`, `1.0.0-rc2`, etc

greg.haskins (Thu, 04 May 2017 02:21:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=soJRvFEsk45cSYuyW) @jimthematrix Actually this is exactly what I was suggesting

greg.haskins (Thu, 04 May 2017 02:21:30 GMT):
first release, -alpha2, hotfixes -alpha2.x

greg.haskins (Thu, 04 May 2017 02:21:43 GMT):
also agree, aim to not need them

greg.haskins (Thu, 04 May 2017 02:21:54 GMT):
i just like to plan ahead, just in case

jimthematrix (Thu, 04 May 2017 02:22:51 GMT):
totally, need to plan ahead, to allow us the room for possible need, considering our track record so far ;-)

greg.haskins (Thu, 04 May 2017 02:23:41 GMT):
it was nothing specific to our project, I think its just a fact of software engineering

jimthematrix (Thu, 04 May 2017 02:24:30 GMT):
it's release engineering best practice

greg.haskins (Thu, 04 May 2017 02:24:37 GMT):
but you can see the phenomenon on almost any project

jimthematrix (Thu, 04 May 2017 02:24:45 GMT):
so let's make use of it

greg.haskins (Thu, 04 May 2017 02:24:47 GMT):
heres chaintool's most recent history: https://github.com/hyperledger/fabric-chaintool/releases

greg.haskins (Thu, 04 May 2017 02:25:03 GMT):
most cuts tend to have 0-2 hotfixes

greg.haskins (Thu, 04 May 2017 02:25:55 GMT):
depending on your release strategy, you could have many more...my main point is 0-2 "oops" i think is minimal

greg.haskins (Thu, 04 May 2017 02:26:01 GMT):
so why not leave room for them

greg.haskins (Thu, 04 May 2017 02:28:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=BSR7v3jwqWsE5qBjR) @JonathanLevi Please dont do this

greg.haskins (Thu, 04 May 2017 02:29:12 GMT):
its not that the branching is hard, its the pipeline to manage the branches from going out of sync that worries me

greg.haskins (Thu, 04 May 2017 02:29:38 GMT):
I still have PTSD from trying to straighten out the mess we had with v0.6 and 1.0

greg.haskins (Thu, 04 May 2017 02:29:38 GMT):
I still have PTSD from trying to straighten out the mess we had between v0.6 and 1.0

greg.haskins (Thu, 04 May 2017 02:30:33 GMT):
I would argue getting the pipeline "right" must come first, before we cut over to the model, and I would also argue that having that pipeline distraction _now_ is bad timing

greg.haskins (Thu, 04 May 2017 02:31:30 GMT):
I think one of the fundamental problems is that model proposed is antithetical to how gerrit operates

greg.haskins (Thu, 04 May 2017 02:31:51 GMT):
gerrit likes to be CR/patch oriented, not branch oriented

greg.haskins (Thu, 04 May 2017 02:35:24 GMT):
My main concerns are that we need things to remain truly continuously integrated (in whatever makes sense for the context) and that we don't leave merging to humans

greg.haskins (Thu, 04 May 2017 02:36:49 GMT):
I think we've already proven that on a project of this type/size, you'll get inconsistent results at best if left to humans

cbf (Thu, 04 May 2017 10:01:11 GMT):
vM.m.p-alphaN.h seems quite reasonable to me

cbf (Thu, 04 May 2017 10:02:21 GMT):
I agree we need to get the pipeline in place, fortunately, I have someone who will be able to help joining us shortly.

JonathanLevi (Thu, 04 May 2017 10:56:32 GMT):
Ha ha. Good morning - feels like we have still have the PTSD symptoms...!

JonathanLevi (Thu, 04 May 2017 10:57:09 GMT):
:-) Sounds good. Let's adopt that then. Seems like most of us support that...

JonathanLevi (Thu, 04 May 2017 10:57:09 GMT):
:-) Sounds good. Let's adopt that [naming scheme] then. Seems like most of us support that...

JonathanLevi (Thu, 04 May 2017 10:57:09 GMT):
:-) Sounds good. Let's adopt that [naming scheme] then. Seems like most of us support that notion...

JonathanLevi (Thu, 04 May 2017 10:57:09 GMT):
:-) Sounds good. Let's adopt that [naming scheme] then. Seems like most of us support that notion... - will formalize it a little bit to check that we are all in agreement. Again, I do/did not mind how we call it, as long as we don't claim that it's *beta* (yet).

JonathanLevi (Thu, 04 May 2017 10:58:26 GMT):
I'll also try to find out how much work is required for the CI retooling, and what can be the minimal though sufficient enough work that we can accomplish within a few days.

JonathanLevi (Thu, 04 May 2017 10:58:55 GMT):
I agree with Greg. We should not trust *them humans* ;-)

JonathanLevi (Thu, 04 May 2017 11:00:01 GMT):
More seriously, the more manual work we do, the less we automate, the more inconsistent, by "design", things may (and will) be.

himansri (Thu, 04 May 2017 11:32:53 GMT):
Has joined the channel.

weeds (Thu, 04 May 2017 12:03:18 GMT):
@binhn please make sure you take note of comments here up above- realize you are still recovering

JonathanLevi (Thu, 04 May 2017 12:16:17 GMT):
Sharon, *all the maintainers* are going to have a vote over these. I am/we are just trying to gather/collect what we can agree on first (e.g., the naming, the parts of branching/steps, and today I would like to really define the upcoming "freeze" until we are stable...).

mastersingh24 (Thu, 04 May 2017 12:22:50 GMT):
FWIW - I think that the next "cut" should be tagger as "beta" and not "alpha.N"

weeds (Thu, 04 May 2017 12:25:09 GMT):
++ Jonathan-

JonathanLevi (Thu, 04 May 2017 12:29:02 GMT):
@mastersingh24 Are we happy to freeze API/ABI very soon? Do you feel we are ready?

JonathanLevi (Thu, 04 May 2017 12:29:43 GMT):
(really asking)

JonathanLevi (Thu, 04 May 2017 12:30:04 GMT):
At some point, we will have to "veto" changes...

mastersingh24 (Thu, 04 May 2017 12:30:10 GMT):
Well we should be ready - I guess we won't know if we need to change anything until more people start using it but I am not currently aware of any planned changes

mastersingh24 (Thu, 04 May 2017 12:30:53 GMT):
Meaning we should only change something if we really screwed up or missed soemthing at this point. I don't know of any planned changes to existing APIs

JonathanLevi (Thu, 04 May 2017 12:31:22 GMT):
Yes, what we "softly" defined as "show stoppers" (without which we can't ship)

mastersingh24 (Thu, 04 May 2017 12:31:25 GMT):
I could see that we might need to ADD some to make some configuration(s) easier, but again we'll need to get feedback

mastersingh24 (Thu, 04 May 2017 12:31:42 GMT):
and those MUST NOT break existing ABI/API

greg.haskins (Thu, 04 May 2017 12:50:34 GMT):
I am going to try to tackle working with the SDK against the latest fabric/ca with full security on, etc.

greg.haskins (Thu, 04 May 2017 12:51:31 GMT):
I suspect there will be some awkwardness w.r.t. configuring an SDK client to use all the certs, etc....we will have to decide to fix or live with it

greg.haskins (Thu, 04 May 2017 12:53:42 GMT):
that would be the most obvious ABI change i can think of

JonathanLevi (Thu, 04 May 2017 12:54:01 GMT):
Let's all give it a day (or two) ?

JonathanLevi (Thu, 04 May 2017 12:55:16 GMT):
Declaring an *ABI freeze* will really be a huge (and super welcome!) step...

JonathanLevi (Thu, 04 May 2017 12:59:16 GMT):
I just don't want to do it too early (and definitely not too late/not do it for one reason or another). Ref: "making noise when we need to break it/if we must" above.

greg.haskins (Thu, 04 May 2017 13:05:46 GMT):
i suspect we may need to consider (probably for 1.1 at this point) some kind of "channel discovery" protocol

greg.haskins (Thu, 04 May 2017 13:06:31 GMT):
perhaps its as simple as GetChannelConfig(name string) -> channel.tx

greg.haskins (Thu, 04 May 2017 13:07:14 GMT):
it seems to be that requiring the SDK clients to know all the peers and all the orderers will be both awkward and fragile

greg.haskins (Thu, 04 May 2017 13:07:59 GMT):
(unless we already have that?)

binhn (Thu, 04 May 2017 13:10:56 GMT):
there 's api to get channels, but the caller must have access

yacovm (Thu, 04 May 2017 13:11:36 GMT):
Greg I have deja-vu :)

yacovm (Thu, 04 May 2017 13:11:52 GMT):
I remember we discussed this in this channel in the past

yacovm (Thu, 04 May 2017 13:11:52 GMT):
I remember we discussed this in this channel in the past with regard to "know all the peers"

binhn (Thu, 04 May 2017 13:12:03 GMT):
look at lscc

binhn (Thu, 04 May 2017 13:12:03 GMT):
look at cscc https://github.com/hyperledger/fabric/blob/master/core/scc/cscc/configure.go#L134

jimthematrix (Thu, 04 May 2017 14:19:22 GMT):
sorry to be the party pooper but I don't think the SDKs are ready for API freeze yet. @mastersingh24 @JonathanLevi @greg.haskins @cbf @binhn

jimthematrix (Thu, 04 May 2017 14:20:06 GMT):
it'd like to propose for fabric and fabric-ca to be declared as `beta` but node and java SDK to be `alpha2`

jimthematrix (Thu, 04 May 2017 14:20:45 GMT):
both SDKs need some time to review the API designs and I already know there are places we'd like to adjust so they make more sense

jimthematrix (Thu, 04 May 2017 14:22:25 GMT):
we have been swamped by trying to keep up with fabric and fabric-ca (breaking) changes and haven't got a chance to really sweep the APIs for bad designs

cbf (Thu, 04 May 2017 15:42:35 GMT):
nothing is ready for beta

cbf (Thu, 04 May 2017 15:43:13 GMT):
I think that the SDKs can continue to evolve, but we need to put something out that people can work with now

cbf (Thu, 04 May 2017 15:43:35 GMT):
so SDK needs to catch up to recent changes?

jimthematrix (Thu, 04 May 2017 15:46:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=sWMAR4yanrxjt35z9) @greg.haskins the SDKs (node and java at least) attempt to support this from chain.initialize() so that you only need to tell it where one of the orderers is and it'll discover all the information relevant to that channel. although as far as peers are concerned, the only possibly useful information in the channel config is `AnchorPeers` which are optional and don't necessary completely overlap with the `endorser` peers. but the ability is there as an option if the network setup supports it

jimthematrix (Thu, 04 May 2017 15:49:37 GMT):
@cbf we've basically caught up as of yesterday so are now focusing on tying up a few loose ends (some are affecting APIs) and starting to address critical bugs

jimthematrix (Thu, 04 May 2017 15:50:16 GMT):
in the meanwhile I'm also trying to review the APIs and I'm almost 100% sure there will need to be API adjustments in both node and Java

greg.haskins (Thu, 04 May 2017 15:56:57 GMT):
@jimthematrix that is great news

greg.haskins (Thu, 04 May 2017 15:57:02 GMT):
do you have a working example?

greg.haskins (Thu, 04 May 2017 15:57:29 GMT):
i mean, a best-practices example? the e2e isnt well suited to demonstrating to users how to write a client

greg.haskins (Thu, 04 May 2017 15:58:05 GMT):
and in any case, last I looked, it was still structured around very explicit configuration of the orderers/peers

JonathanLevi (Thu, 04 May 2017 16:58:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=qACisWwtMtvQbF5kC) Jim, no need to apologize, we are all just trying to get in synch.

JonathanLevi (Thu, 04 May 2017 16:58:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=qACisWwtMtvQbF5kC) Jim, no need to apologize ;-), we are all just trying to get in synch... get a realistic status.

JonathanLevi (Thu, 04 May 2017 16:58:17 GMT):
Let's align everything. No point in different tags for different (sub-projects).

JonathanLevi (Thu, 04 May 2017 16:58:17 GMT):
Let's align everything. No point in different tags for different (sub-) projects... I would rather wait:

JonathanLevi (Thu, 04 May 2017 17:01:08 GMT):
Since/as we would like to help others provide us with more feedback... we should make it really simple to work against a unified tag/version... and report issues with/against it.

jimthematrix (Thu, 04 May 2017 17:13:18 GMT):
so just to be clear, I do support putting another release out (early) next week which I think is a higher priority than getting all sub-projects aligned. so I already know node and Java SDK will be `alpha2` for that. but if for fabric and fabric-ca we believe it's already ABI frozen then it should be called `beta` with the benefit of encouraging early adopters to start banging hard on it, which I think they would hesitate to do on an alpha

cbf (Thu, 04 May 2017 17:31:01 GMT):
might I remind maintainers that when they submit a CR for merge, that they please also update the corresponding JIRA accordingly. Not all transition to Done, so read carefully. However, right now, the JIRA items are not closed automatically

cbf (Thu, 04 May 2017 17:31:53 GMT):
as for the release, I'd like it sooner rather than next week. Tomorrow if possible

cbf (Thu, 04 May 2017 17:32:19 GMT):
@jimthematrix you are hinting that you won't be ready then?

jimthematrix (Thu, 04 May 2017 17:35:56 GMT):
node SDK can have a cut tomorrow. but java SDK won't likely be ready. Rick spent the last 4 days recovering from all the breaking changes and https://gerrit.hyperledger.org/r/#/c/8471/ is being reviewed (it's huge but it's one of those that has to contain all the necessary changes to get green again)

Nishi (Thu, 04 May 2017 17:46:03 GMT):
Has joined the channel.

JonathanLevi (Thu, 04 May 2017 17:50:27 GMT):
I am happy to focus *all efforts* these coming days and go for an 'alpha2' across all project, so that we that we have a working baseline.

JonathanLevi (Thu, 04 May 2017 17:50:27 GMT):
I am happy to focus *all efforts* (that is, not merging any else until we get there) these coming days and go for an 'alpha2' across all project, so that we that we have a working baseline.

JonathanLevi (Thu, 04 May 2017 17:50:27 GMT):
I am happy to focus *all efforts* (that is, not merging anything else until we get there) these coming days and go for a *1.0.0-alpha2* tag across all (sub-) projects, so that we that we have a working baseline.

JonathanLevi (Thu, 04 May 2017 17:51:10 GMT):
Who can provide an estimate for the Java SDK readiness? (Again, estimate, ballpark, ...)

cbf (Thu, 04 May 2017 19:34:44 GMT):
FWIW, I asked the IBM team for a list of CRs that were MUST HAVE for an alpha2... still have not seen that

cbf (Thu, 04 May 2017 21:49:55 GMT):
@here https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/000842.html

cbf (Thu, 04 May 2017 21:50:11 GMT):
I just posted to the mailing list a draft set of exit criteria for a release

cbf (Thu, 04 May 2017 21:50:20 GMT):
please flame away

cbf (Thu, 04 May 2017 21:51:05 GMT):
I have had input from @JonathanLevi and @mastersingh24 but would welcome suggested improvements (or tell me I am full of it)

cbf (Thu, 04 May 2017 21:51:38 GMT):
@dhuseby @tkuhrt ^^

cbf (Thu, 04 May 2017 21:52:18 GMT):
Dave, if you have specific static or dynamic scanning requirements, it would help to be explicit about those

ashutosh_kumar (Fri, 05 May 2017 02:07:19 GMT):
This is not a channel for me to chime in , but I thought let me put my 2 cents. Dynamic scan does not fall into the development activities bucket. For static scan , we have very limited support. There is no tool in the market which does static scan of Go source code and same is applicable to Node js as well. We can scan Node js code as client side javascript . Not sure how much effective that would be.

muralisr (Fri, 05 May 2017 11:39:20 GMT):
@cbf I suppose samples are included under ``` documentation sufficient to ensure that users/operators have clear guidance on how to get started and how to configure and operate. The operational aspects need to be correct and independently user tested,``` ? would it make sense to have an explicit samples to go with the doc ?

muralisr (Fri, 05 May 2017 11:39:20 GMT):
@cbf I suppose samples are included under ```documentation sufficient to ensure that users/operators have clear guidance on how to get started and how to configure and operate. The operational aspects need to be correct and independently user tested``` ? would it make sense to have an explicit samples to go with the doc ?

cbf (Fri, 05 May 2017 11:46:17 GMT):
@muralisr I think that falls under documentation, yes

muralisr (Fri, 05 May 2017 11:51:30 GMT):
Ok. good sample is worth a ton of doc right.. hence the suggestion to explicitly look out for those in submissions, but yes, they are "doc" in the end

muralisr (Fri, 05 May 2017 11:52:07 GMT):
and its hard to enforce "samples" I suppose

cbf (Fri, 05 May 2017 12:32:30 GMT):
y

cbf (Fri, 05 May 2017 12:32:51 GMT):
@greg.haskins thoughts?

cbf (Fri, 05 May 2017 12:32:51 GMT):
@greg.haskins thoughts on the exit criteria email?

greg.haskins (Fri, 05 May 2017 12:33:25 GMT):
reviewing

greg.haskins (Fri, 05 May 2017 12:34:04 GMT):
@cbf are you tasking about your exit criteria, or @muralisr's comment on samples?

greg.haskins (Fri, 05 May 2017 12:34:04 GMT):
@cbf are you asking about your exit criteria, or @muralisr's comment on samples?

cbf (Fri, 05 May 2017 12:34:47 GMT):
email generally and any of the comments

cbf (Fri, 05 May 2017 12:35:47 GMT):
@here and of course, anyone else - would like to nail this down today

muralisr (Fri, 05 May 2017 12:37:22 GMT):
FWIW @cbf, I like it a lot overall... especially after @mastersingh24 comment on "intent"

muralisr (Fri, 05 May 2017 12:37:26 GMT):
```- produce releases which solve real use cases - produce releases which can be easily consumed by new and old users alike - the developers feel confident that their code does what it says it does / is supposed to do - releases which can confidently be used in production scenarios```

cbf (Fri, 05 May 2017 12:37:48 GMT):
yes, I will add that when we publish for sure

greg.haskins (Fri, 05 May 2017 12:37:55 GMT):
overall I thought the list looked good...really my only concern would be not with the merit of the line items, but our ability to execute on them in the short term as a gate to the release

muralisr (Fri, 05 May 2017 12:37:57 GMT):
my only (perhaps naive) question is ... how easy is it to enforce this

greg.haskins (Fri, 05 May 2017 12:38:07 GMT):
for instance, security scans...do we have this capability?

cbf (Fri, 05 May 2017 12:39:36 GMT):
@greg.haskins IBM does these for our offerings, and I am working with Dave H on LF side of things, to nail down tools and/or services we should be using

muralisr (Fri, 05 May 2017 12:39:54 GMT):
(sorry to jump in @greg.haskins ...but let me amend that last comment.... how do make sure to enforce it in a natural non process-heavy way)...

cbf (Fri, 05 May 2017 12:40:09 GMT):
the thing missing from IBM's tools is golang static security scanning

cbf (Fri, 05 May 2017 12:40:16 GMT):
so I am researching what is available

cbf (Fri, 05 May 2017 12:40:45 GMT):
@muralisr enforcement is US - the maintainers

muralisr (Fri, 05 May 2017 12:42:17 GMT):
right @cbf ... will read again and think about that aspect. but again, fwiw, my +1

smithbk (Fri, 05 May 2017 13:14:08 GMT):
@cbf What about load and performance testing?

cbf (Fri, 05 May 2017 13:58:32 GMT):
I think that scale and performance testing, and long-running and chaotic testing are also important long term. It is likely these will get done. I think that the question comes down to - if push comes to shove, are those required or nice to have at this point. At some point, it will be important we don't regress in scale and performance (eg v1.1) but I wonder if we want to include that now

cbf (Fri, 05 May 2017 13:58:36 GMT):
welcome other's input

JonathanLevi (Fri, 05 May 2017 14:33:58 GMT):
In all fairness, we do not have baseline numbers/performance results.

JonathanLevi (Fri, 05 May 2017 14:34:35 GMT):
So other than things that are obviously prohibitive... it is really important to get the right functionality out.

JonathanLevi (Fri, 05 May 2017 14:35:13 GMT):
The correct functionality and good test coverage, at this point, seem to me the priority.

yacovm (Fri, 05 May 2017 14:36:06 GMT):
@cbf I have a setup that has been running for months and I opened some bugs that are related to things that can only be discovered when the peers run for a long period of time such as file descriptor leakage, and also: https://jira.hyperledger.org/browse/FAB-3525 w.r.t performance I'm also (slowly but surely) building something that enables to measure the gossip network performance (block dissemination metrics)

JonathanLevi (Fri, 05 May 2017 14:37:12 GMT):
@yacovm, do you think you will be able to produce numbers that we should be use to define the exit criteria 1.0 (at this point) ?

JonathanLevi (Fri, 05 May 2017 14:37:12 GMT):
@yacovm, do you think you will be able to produce numbers that we should use to define the exit criteria 1.0 (at this point) ?

yacovm (Fri, 05 May 2017 14:37:23 GMT):
Depends when ;)

cbf (Fri, 05 May 2017 14:37:53 GMT):
note that Scott and Dongming are also working on transferring their performance test framework to Fabric

yacovm (Fri, 05 May 2017 14:38:19 GMT):
But the biggest problem I see w.r.t performance is that the model itself is very dependent on transactions having different RWsets due to MVCC. In order to achieve high throughput of total transactions you'll need to lie to yourself and have a bizarre test that updates lots of keys but not the same ones.

yacovm (Fri, 05 May 2017 14:38:19 GMT):
But the biggest problem I see w.r.t performance is that the validation model itself is very dependent on transactions having different RWsets due to MVCC. In order to achieve high throughput of total transactions you'll need to lie to yourself and have a bizarre test that updates lots of keys but not the same ones.

JonathanLevi (Fri, 05 May 2017 14:38:30 GMT):
Yes and there are a few more measures that being defined this days (e.g., the new wg from last week...)

cbf (Fri, 05 May 2017 14:39:09 GMT):
again, I don't at all disagree that this is important or useful, just not a requirement for v1.0 necessarily if we want to deliver in < 2 months

JonathanLevi (Fri, 05 May 2017 14:39:38 GMT):
My take is that setting these up as a strict criteria (with very well defined software + hardware specifications)... is dangerous.

JonathanLevi (Fri, 05 May 2017 14:40:31 GMT):
This bit *In all fairness, we do not have baseline numbers/performance results.* from above.

JonathanLevi (Fri, 05 May 2017 14:41:24 GMT):
We can should definitely look at these (I can tell you that in HACERA we definitely measure a lot of our performance on top of fabric)... but I would be very cautious regarding setting a hard/strict perf. requirement right now.

JonathanLevi (Fri, 05 May 2017 14:42:15 GMT):
This includes loads, size/shape of clusters, etc. A lot of things are very new here. While careful with words, I'm also being realistic.

greg.haskins (Fri, 05 May 2017 15:00:06 GMT):
https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/000863.html

VipinB (Fri, 05 May 2017 21:19:10 GMT):
Interesting paper on fuzz testing in Communications of the ACM. It is very practical with tools to generate ASNs and use ASN to generate fuzz tests to probe weaknesses of MongoDB (in particular); but this can be generalized to test any platform or interface. The title is "MongoDB's JavaScript Fuzzer" In Communications Of the ACM 05-2017, maybe this will help with setting up test frameworks for Fabric/Iroha/STL. Maybe you guys already have such frameworks and would like to expand-iterate on those.

VipinB (Fri, 05 May 2017 21:19:25 GMT):
Copied from tsc channel to this

JonathanLevi (Fri, 05 May 2017 21:56:36 GMT):
Thanks @VipinB. FYI, our main frameworks for testing fabric (other than Golang's unit-test framework, Ginkgo/Gomega...) is a BDD framework (Behave) integration tests suites, and other tests that are using the SDKs.

JonathanLevi (Fri, 05 May 2017 21:57:07 GMT):
Thanks @VipinB. FYI, our main frameworks for testing fabric (other than Golang's unit-test framework, Ginkgo/Gomega...) is a BDD framework (Behave) integration tests suite, and other tests that are using the SDKs.

JonathanLevi (Fri, 05 May 2017 21:57:07 GMT):
Thanks @VipinB FYI, our main frameworks for testing fabric (other than Golang's unit-test framework, Ginkgo/Gomega...) is a BDD framework (Behave) integration tests suite, and other tests that are using the SDKs.

JonathanLevi (Fri, 05 May 2017 22:49:10 GMT):
@VipinB ^^^

greg.haskins (Sat, 06 May 2017 02:00:32 GMT):
so, what is this I heard about no tcerts in 1.0?

greg.haskins (Sat, 06 May 2017 02:01:08 GMT):
@lehors ^^^

greg.haskins (Sat, 06 May 2017 02:01:30 GMT):
is that accurate?

greg.haskins (Sat, 06 May 2017 02:02:39 GMT):
if so, what is the signature mechanism that replaced it?

yacovm (Sat, 06 May 2017 08:08:03 GMT):
@greg.haskins you heard right

greg.haskins (Sat, 06 May 2017 12:30:32 GMT):
@yacovm we are signing with something though, right (ecerts, perhaps)?

greg.haskins (Sat, 06 May 2017 12:30:46 GMT):
or do we have no signatures at all?

yacovm (Sat, 06 May 2017 12:58:11 GMT):
yeah

yacovm (Sat, 06 May 2017 12:58:20 GMT):
the proposal is signed @greg.haskins

greg.haskins (Sat, 06 May 2017 13:00:29 GMT):
@yacovm ok, good.. I can live with ecert signature. Having no signature at all would be a deal breaker ;) Thanks for clarifying

yacovm (Sat, 06 May 2017 13:02:04 GMT):
We do check access control with the signature: ``` func (e *Endorser) checkACL(signedProp *pb.SignedProposal, chdr *common.ChannelHeader, shdr *common.SignatureHeader, hdrext *pb.ChaincodeHeaderExtension) error { return e.policyChecker.CheckPolicy(chdr.ChannelId, policies.ChannelApplicationWriters, signedProp) } ```

cbf (Sat, 06 May 2017 16:15:02 GMT):
@here https://wiki.hyperledger.org/projects/fabric/release_exit_criteria draft with feedback incorporated added to wiki

JonathanLevi (Mon, 08 May 2017 11:41:25 GMT):
Wait, why don't we use the TCert to sign ?

yacovm (Mon, 08 May 2017 11:43:30 GMT):
I guess because it's not implemented

weeds (Mon, 08 May 2017 12:17:24 GMT):
@here Announcement: We hold a quick scrum call on Monday, Wednesday, Friday for Hyperledger-Fabric. The dial in for today at 9:30 EST is 1-888-426-6840 with passcode 33682113. We review what has passed or failed out of the daily build from CI, the highest priority bugs that must be addressed, CR's that need special attention from maintainers, unit test coverage, and serviceability. Also at the end of the call, developers sometimes talk about additional technical questions that should be addressed to stabilizing release where interlock needs to occur. We also try to take notes as best we can in the fabric-peer-endorser-comitter channel for those that are not able to attend or are in a geographical location that is not a good time for them to dial in.

yacovm (Mon, 08 May 2017 13:13:04 GMT):
I have something very important to discuss. The full details are in the JIRA item below. https://jira.hyperledger.org/browse/FAB-3359 The short version is: 1) In gossip we have a handshake that associates a TLS connection with a peer's identity. In the past a security-related binding between the TLS session and the identity of the peer that used TLS-Unique (a TLS session binding) 2) After a while it was decided to ditch that and to rely and mutual TLS since it's more safe (more bytes in the hash of a cert than in the TLS-Unique bytes) 3) when TLS was introduced (but without mutual) I had to add a flag that overrides the check in case the client peer doesn't send the certificate (since no mutual TLS) otherwise gossip would be broken. And since then we always use SKIP_HANDSHALE=true in all the docker-compose files.... 3) It's almost time for V1.0 to be released and mutual TLS isn't going to happen anytime soon. 4) Therefore I conclude that we *must* go back to the past implementation of the handshake. The change that is requires is only to change 1 method (the handshake method) and its corresponding unit test + add a field to the protobuff message. Opinions are welcome: @mastersingh24 @C0rWin @elli-androulaki

zupan (Mon, 08 May 2017 13:45:33 GMT):
Has joined the channel.

greg.haskins (Mon, 08 May 2017 18:49:11 GMT):
I don't understand the challenges with mutual auth. Anyone know why we can't just enable that?

mastersingh24 (Mon, 08 May 2017 18:59:54 GMT):
[We struggle enough with getting people comfortable with one way TLS ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yzS6NnpcuDN62iJ58) @greg.haskins

mastersingh24 (Mon, 08 May 2017 19:00:46 GMT):
Although I don't have an issue doing it for the official v1.0.0 release - requires a few changes in the core/comm package (since the version of grpc we use does not provide access to the auth info - aka client cert :( )

greg.haskins (Mon, 08 May 2017 19:16:58 GMT):
To be clear, I am primarily thinking of p2p

greg.haskins (Mon, 08 May 2017 19:17:52 GMT):
Mutual auth for p2p is generally no more complex than standard TLS since the PKI covers the full mesh anyway

greg.haskins (Mon, 08 May 2017 19:19:08 GMT):
If we want to stick with one way TLS at the edge, that's fine

yacovm (Mon, 08 May 2017 19:20:16 GMT):
Yeah but Gari has a point-we have so many users that complain they cant connect with tls. What will happen if we introduce also that now they need to configure the client certs too and they will be the same(?) Certs?

yacovm (Mon, 08 May 2017 19:20:42 GMT):
I am on the fence here but i twll you that we have to change *somerhing*

greg.haskins (Mon, 08 May 2017 19:21:13 GMT):
I suppose we should clarify terms. For the p2p I am thinking of, we already have the certs

yacovm (Mon, 08 May 2017 19:21:20 GMT):
(On mobile. Exxcuse typos)

greg.haskins (Mon, 08 May 2017 19:21:28 GMT):
(Same)

greg.haskins (Mon, 08 May 2017 19:22:27 GMT):
Generally speaking you can build a mutual auth peer-to-peer mesh with one key pair per node

greg.haskins (Mon, 08 May 2017 19:22:48 GMT):
It's just a matter of config

greg.haskins (Mon, 08 May 2017 19:23:26 GMT):
So there wouldn't be any extra cents. Peers already have them for one way

yacovm (Mon, 08 May 2017 19:24:33 GMT):
Config is the hardest part of using fabric :expressionless:

greg.haskins (Mon, 08 May 2017 19:36:36 GMT):
Agreed. What I meant specifically though is the code configuration of the socket, not client facing per se

kostas (Mon, 08 May 2017 19:39:21 GMT):
I've pulled the latest master (tip: 8f4b6a96 - (HEAD -> master, origin/master, origin/HEAD) Merge "[FAB-3258] fwk test chaincode functionality Part2" (58 minutes ago) and it seems that the E2E CLI test is broken.

kostas (Mon, 08 May 2017 19:39:21 GMT):
I've pulled the latest master (tip: `8f4b6a96 - (HEAD -> master, origin/master, origin/HEAD) Merge "[FAB-3258] fwk test chaincode functionality Part2" (58 minutes ago)`) and it seems that the E2E CLI test is broken.

kostas (Mon, 08 May 2017 19:39:24 GMT):
Two quick questions:

kostas (Mon, 08 May 2017 19:39:30 GMT):
1. Are we aware of this

kostas (Mon, 08 May 2017 19:39:50 GMT):
2. Why did we merge the breaking change to begin with

muralisr (Mon, 08 May 2017 19:47:58 GMT):
@kostas that CR passed both e2e cli and UT (look for "=============E2E TEST PASSED==========" in the CI console for the CR)

mastersingh24 (Mon, 08 May 2017 19:50:46 GMT):
@kostas - https://gerrit.hyperledger.org/r/#/c/9103/

kostas (Mon, 08 May 2017 19:55:06 GMT):
@muralisr: As far as I can tell, CI reports an E2E failure on this CR: https://gerrit.hyperledger.org/r/#/c/9045/

muralisr (Mon, 08 May 2017 19:56:22 GMT):
it does... but if you dig in, you should see

muralisr (Mon, 08 May 2017 19:56:23 GMT):
=============E2E TEST PASSED==========

muralisr (Mon, 08 May 2017 19:56:41 GMT):
so he E2E CLI passed but other e2e failed

muralisr (Mon, 08 May 2017 19:56:41 GMT):
so the E2E CLI passed but other e2e failed

kostas (Mon, 08 May 2017 19:57:11 GMT):
git fetch ssh://kchristidis@gerrit.hyperledger.org:29418/fabric refs/changes/03/9103/1 && git checkout FETCH_HEAD

kostas (Mon, 08 May 2017 19:57:21 GMT):
https://jenkins.hyperledger.org/job/fabric-merge-end-2-end-x86_64/447/console

kostas (Mon, 08 May 2017 19:57:34 GMT):
Am I looking at the wrong place? I'm grepping for that string and come up empty.

muralisr (Mon, 08 May 2017 19:57:52 GMT):
click on "full log" on top of page

muralisr (Mon, 08 May 2017 19:58:04 GMT):
and search for "E2E TEST PASSED"

kostas (Mon, 08 May 2017 19:58:48 GMT):
I do not see a "full log" option.

muralisr (Mon, 08 May 2017 19:59:24 GMT):
looks like this in my browser

muralisr (Mon, 08 May 2017 19:59:43 GMT):

Message Attachments

kostas (Mon, 08 May 2017 20:01:37 GMT):
(Got it now, thank you.)

muralisr (Mon, 08 May 2017 20:01:47 GMT):
sure thing

mastersingh24 (Mon, 08 May 2017 22:46:29 GMT):
[OK - so I added some comments to https://jira.hyperledger.org/browse/FAB-3359 but the TLDR is that I think we should go with Yacov's proposal to use both tls-unique and client certificates for p2p with gossip ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yzS6NnpcuDN62iJ58) @greg.haskins

mastersingh24 (Mon, 08 May 2017 22:46:29 GMT):
[OK - so I added some comments to https://jira.hyperledger.org/browse/FAB-3359 but the TLDR is that I think we should go with Yacov's proposal to use both tls-unique and client certificates for p2p with gossip. If we pick one, I'd go with mutual TLS ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yzS6NnpcuDN62iJ58) @greg.haskins

mastersingh24 (Mon, 08 May 2017 22:46:29 GMT):
[OK - so I added some comments to https://jira.hyperledger.org/browse/FAB-3359 but the TLDR is that I think we should go with client certificates for p2p with gossip. ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yzS6NnpcuDN62iJ58) @greg.haskins

mastersingh24 (Mon, 08 May 2017 22:46:50 GMT):
Please add your votes / dissents / comments to the JIRA

greg.haskins (Tue, 09 May 2017 01:18:02 GMT):
@mastersingh24 You guys obviously have a handle on the issues between tls-unique and proxy considerations. However, one thing that didn't make sense to me was your comment "having the peer(s) use their MSP signing cert as their client certificate"

greg.haskins (Tue, 09 May 2017 01:18:27 GMT):
why wouldnt you simply use the same TLS keys for both client and server?

greg.haskins (Tue, 09 May 2017 01:18:58 GMT):
thats how I've always built mesh applications

greg.haskins (Tue, 09 May 2017 01:19:19 GMT):
to be clear: i am referring to roles on one node

greg.haskins (Tue, 09 May 2017 01:19:26 GMT):
not two nodes: that would be dumb, heh

greg.haskins (Tue, 09 May 2017 01:20:32 GMT):
meaning, why can you simply use the TLS .crt/.key material that is configured for _receiving_ connections also for your outbound connections?

greg.haskins (Tue, 09 May 2017 01:20:32 GMT):
meaning, why can't you simply use the TLS .crt/.key material that is configured for _receiving_ connections also for your outbound connections?

greg.haskins (Tue, 09 May 2017 01:22:41 GMT):
I dont really know the internal peer/gossip topology, so perhaps that has something to do with it

greg.haskins (Tue, 09 May 2017 01:23:01 GMT):
my assumption is these things form a mesh-like structure, but perhaps it looks different

mastersingh24 (Tue, 09 May 2017 07:03:14 GMT):
[actually we should be able to do that and I probably should have written that ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=CEgQ7e7aZMDNvronY) @greg.haskins

mastersingh24 (Tue, 09 May 2017 07:04:25 GMT):
And that's pretty much how I was doing things in some of the peer tests already

yacovm (Tue, 09 May 2017 07:10:27 GMT):
If you have an org A you'll have to configure the TLS cert pool of the reverse proxy of orgA to accept TLS certs of other orgs (i.e org B) up-front, right? (I don't think nghttpx understand config blocks)

yacovm (Tue, 09 May 2017 07:10:27 GMT):
@mastersingh24 If you have an org A you'll have to configure the TLS cert pool of the reverse proxy of orgA to accept TLS certs of other orgs (i.e org B ) up-front, right? (I don't think nghttpx understand config blocks)

yacovm (Tue, 09 May 2017 07:12:06 GMT):
Also- since we'll have mutual TLS - so if a peer from orgA "dials" to orgB, then orgB's reverse proxy would need to share the cert and private key with the peer in orgA no?

yacovm (Tue, 09 May 2017 07:13:26 GMT):
Another question - this is for TLS proxy-ing, but what about termination? I thought that in termination the peers don't even see TLS? How would that work?

mastersingh24 (Tue, 09 May 2017 07:21:22 GMT):
[ OrgB's reverse proxy would need to have a cert issued by the CA in OrgB's MSP but the proxy and the peer need not share the same key/cert pair ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=zvhyYihbKefSjWfPd) @yacovm

mastersingh24 (Tue, 09 May 2017 07:21:54 GMT):
But we'll need to write all of this up and try it out

mastersingh24 (Tue, 09 May 2017 07:22:06 GMT):
The trust issue will be tricky for reverse proxies

yacovm (Tue, 09 May 2017 07:22:18 GMT):
Hmm so for that you'll need to add support in the code to make the certificate of the initiating peer to be passed to the responding peer via HTTP headers?

yacovm (Tue, 09 May 2017 07:22:38 GMT):
and vice-versa?

yacovm (Tue, 09 May 2017 07:22:52 GMT):
because the gossip code signs the message that contains the cert hash

mastersingh24 (Tue, 09 May 2017 07:23:00 GMT):
If we terminate TLS at the proxy, we'll have to pass the client cert to the peer via a header

mastersingh24 (Tue, 09 May 2017 07:23:45 GMT):
If we use SSL/TLS bridging (common for load balancers) which operates at layer 2/3, then the proxy actually does not need any crypto material as termination would happen at the peer

mastersingh24 (Tue, 09 May 2017 07:24:09 GMT):
But anything at Layer 4 or above would be termination

mastersingh24 (Tue, 09 May 2017 07:24:51 GMT):
A true reverse proxy is Layer 7 so that's the case we will have to deal with in terms of describing how to get it working

yacovm (Tue, 09 May 2017 07:30:08 GMT):
I also don't understand why can't the customers always use passthrough? (just TCP forwarding?)

mastersingh24 (Tue, 09 May 2017 07:34:58 GMT):
Depends on what you are trying to achieve. For example, in the Bluemix service for v0.6, we actually used reverse proxies to do host header based routing - which meant we needed to terminate at the proxy

yacovm (Tue, 09 May 2017 07:35:00 GMT):
> If we use SSL/TLS bridging (common for load balancers) which operates at layer 2/3, then the proxy actually does not need any crypto material as termination would happen at the peer So the client connects to the proxy server and it decrypts and then re-encrypts the traffic, but on the receiver peer side it expects the TLS cert of the initiator peer, but instead it would see the TLS cert of the proxy? Or should we write (in the future) in the code that we may accept that the cert would appear in the headers?

yacovm (Tue, 09 May 2017 07:35:26 GMT):
> we actually used reverse proxies to do host header based routing - which meant we needed to terminate at the proxy Ah right, gorouter

mastersingh24 (Tue, 09 May 2017 07:35:36 GMT):
``` Or should we write (in the future) in the code that we may accept that the cert would appear in the headers? ``` Yeah - this is what I meant

yacovm (Tue, 09 May 2017 07:35:42 GMT):
understood

mastersingh24 (Tue, 09 May 2017 07:35:44 GMT):
Yeah - gorouter from cf

yacovm (Tue, 09 May 2017 07:35:45 GMT):
thanks

JonathanLevi (Tue, 09 May 2017 07:39:24 GMT):
BTW, as an aside, SSL/TLS is considered a layer 5 or 6 (subject to the interpretation of a Session in the original OSI).

JonathanLevi (Tue, 09 May 2017 07:40:34 GMT):
It certainly sits on top of TCP/IP which is considered layer 4 by itself... (which is why BMX needed the rev-proxy ...).

JonathanLevi (Tue, 09 May 2017 07:41:43 GMT):
Once the secure socket / secure transport is established, the handshake is completed and there is less room to maneuver...

JonathanLevi (Tue, 09 May 2017 07:46:03 GMT):
----

JonathanLevi (Tue, 09 May 2017 07:46:32 GMT):
I suspect I misinterpret SSL/TLS bridging?

JonathanLevi (Tue, 09 May 2017 07:47:38 GMT):
Are we talking about a VPN/tunneling? A Cisco-like routing with their "Deep Packet Insp."?

yacovm (Tue, 09 May 2017 07:55:23 GMT):
No, I think it's just to decrypt your TLS traffic, perform some access control, and then re-encrypt it and pass it to the server peer

rock_martin (Tue, 09 May 2017 10:27:50 GMT):
Has joined the channel.

rock_martin (Tue, 09 May 2017 11:31:04 GMT):

Message Attachments

ashutosh_kumar (Tue, 09 May 2017 12:42:53 GMT):
In typical enterprise customer scenario ,you do TLS bridging where TLS is terminated at reverse proxy and another TLS session starts from Reverse Proxy to back end. So , from client perspective , the mutual auth TLS terminates at reverse proxy. I think , we should design TLS mutual auth , the way it is being usually implemented. Providing customization over top of it does not seems to be required.

tkuhrt (Tue, 09 May 2017 18:42:04 GMT):
Do we have a documented process that specifies how the maintainers and the +2/-2 works for pull requests?

JonathanLevi (Tue, 09 May 2017 19:00:23 GMT):
Hi Tracy, I believe this document (which could use updating), while mentioning maintainers and links to Gerrit is focused a lot more on contribution from users...

JonathanLevi (Tue, 09 May 2017 19:00:29 GMT):
https://github.com/hyperledger/fabric/blob/master/docs/source/CONTRIBUTING.rst

JonathanLevi (Tue, 09 May 2017 19:02:47 GMT):
In the sense that it explains the PR process, with links/info regarding Gerrit, but we could probably elaborate a lot more regarding the 2 +2 requirement, etc

JonathanLevi (Tue, 09 May 2017 19:03:15 GMT):
@tkuhrt

tkuhrt (Tue, 09 May 2017 19:17:38 GMT):
@JonathanLevi : I found that, and I didn't see any real details about how a contribution gets approved. That is what drove my question. I was under the impression that each PR requires two +2 requirements, but I saw one today that was merged with only a single +2.

tkuhrt (Tue, 09 May 2017 19:17:38 GMT):
@JonathanLevi : I found that, and I didn't see any real details about how a contribution gets approved. That is what drove my question. I was under the impression that each PR requires two +2 before being merged, but I saw one today that was merged with only a single +2.

yacovm (Tue, 09 May 2017 19:19:25 GMT):
@tkuhrt so in node SDK we merge with only 1

yacovm (Tue, 09 May 2017 19:19:34 GMT):
in fabric with 2

tkuhrt (Tue, 09 May 2017 19:19:45 GMT):
Ah...that is confusing. :)

tkuhrt (Tue, 09 May 2017 19:20:30 GMT):
Is the system set up to recognize the difference for the different repositories?

yacovm (Tue, 09 May 2017 19:20:34 GMT):
also in java SDK

yacovm (Tue, 09 May 2017 19:20:34 GMT):
also in java SDK (only 1)

yacovm (Tue, 09 May 2017 19:20:44 GMT):
yes

tkuhrt (Tue, 09 May 2017 19:20:58 GMT):
Okay...thanks, @yacovm.

yacovm (Tue, 09 May 2017 19:21:28 GMT):
np. Also in fabric-ca we need 2 +2, for celli is 1 +2

yacovm (Tue, 09 May 2017 19:21:28 GMT):
np. Also in fabric-ca we need 2 +2, for cello is 1 +2

tkuhrt (Tue, 09 May 2017 19:22:06 GMT):
Wow...okay. Is there a way for me to find out the rules from looking at Gerrit?

yacovm (Tue, 09 May 2017 19:23:10 GMT):
yeah that's what I did for java and for cello

yacovm (Tue, 09 May 2017 19:23:27 GMT):
https://gerrit.hyperledger.org/r/#/q/status:merged

yacovm (Tue, 09 May 2017 19:23:39 GMT):
now you can just open by project and see

rjones (Tue, 09 May 2017 19:23:48 GMT):
@tkuhrt not directly. You could check out each project, then checkout meta/config and look at rules.pl http://www.lowlevelmanager.com/2012/09/modify-submit-type-for-gerrit-project.html

tkuhrt (Tue, 09 May 2017 19:24:48 GMT):
Thanks, @rjones

muralisr (Tue, 09 May 2017 21:29:06 GMT):
thought worth noting ..... all 3 CI jobs pass with https://gerrit.hyperledger.org/r/#/c/9153

muralisr (Tue, 09 May 2017 21:29:25 GMT):

Message Attachments

JonathanLevi (Tue, 09 May 2017 23:27:36 GMT):
@muralisr: thanks (& merged)

weeds (Wed, 10 May 2017 13:07:53 GMT):
Scrum meeting will start at 9:30AM EST (in 25 minutes). Following is the dial in which is the same that we sent out in the Hyperledger e-mail where we announced this will occur every Monday, Wednesday, and Friday: (1-888-426-6840 / 33682113). We will be posting notes on the fabric-peer-endorser-committer channel . Thank you

bkvellanki (Wed, 10 May 2017 14:23:48 GMT):
Has joined the channel.

cbf (Wed, 10 May 2017 16:23:02 GMT):
@here, please see my comment on https://jira.hyperledger.org/browse/FAB-3040

cbf (Wed, 10 May 2017 16:23:09 GMT):
we need to wrap this up

greg.haskins (Wed, 10 May 2017 17:25:02 GMT):
https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/000925.html

kelvinzhong (Thu, 11 May 2017 06:16:18 GMT):
hi all, i wonder is that possible to range query of the blockchain, as currently we only have chain.queryBlockByNumber(), but sometimes we might need to go through all the block sequentially to check all data, and query only one block at a time is too inefficient for that

muralisr (Thu, 11 May 2017 12:09:19 GMT):
@kelvinzhong copied the above to fabric-ledger channel

binhn (Thu, 11 May 2017 14:09:51 GMT):
@maintainers ( @greg.haskins @bmos299 @muralisr @jimthematrix @JonathanLevi @rjones @cbf ) In fabric repo, we have /test directory containing all integration tests that pulling in fabric-ca, fabric-sdk to compose the various testing environments. This is all working fine, but looking at the containment of repos, Barry @bmos299 and I thought we should move /test to its own repo -- fabric-test -- rather than burying it in fabric repo. Thoughts?

rickr (Thu, 11 May 2017 14:10:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Q9WpaStPRvbe2Pueo) You asked this in the #fabric-sdk-java I suggested opening up a JIRA

JonathanLevi (Thu, 11 May 2017 14:11:11 GMT):
Let's not use this channel for ^^^

cbf (Thu, 11 May 2017 14:11:17 GMT):
@binhn @bmos299 I think post alpha2 that would make sense

JonathanLevi (Thu, 11 May 2017 14:11:21 GMT):
@kelvinzhong ^^^

cbf (Thu, 11 May 2017 14:11:39 GMT):
however, let's not make churn at this delicate moment

binhn (Thu, 11 May 2017 14:12:48 GMT):
@cbf agreed to wait after alpha - thanks

jimthematrix (Thu, 11 May 2017 14:46:39 GMT):
@binhn agree with moving integration tests to their own repo, but would suggest calling it "fabric-integration" so it's clear all the unit tests still reside in fabric itself and this separate one is just for cross-component tests (aka integration)

rjones (Thu, 11 May 2017 15:42:02 GMT):
@binhn @cbf disagree - are any of the integration tests independent of the fabric repo? if not, I would leave it alone. Having to always check out _yet another repo_ to run integration tests seems non-optimal.

binhn (Thu, 11 May 2017 16:11:05 GMT):
@rjones yeah, agreed not optimal from operation, but my thought was on organization: the integration tests are pulling code from other repos (fabric-ca, fabric-node-sdk, fabric-java-sdk) into fabric base, which wouldn't seem right to me. Fabric-ca is an independent CA implementation even though we prefix it with fabric-, it has no run-time dependencies on fabric. Fabric-*-sdk are built for fabric and does depend on fabric for operations.

bmos299 (Thu, 11 May 2017 16:23:27 GMT):
@rjones im thinking if the test uses the cli we would leave in the /fabric/test folder. if it uses the sdk we move to the new fabric-integration repo. ....and i will say, i'd like to wait as we are totally heads down on creating test scenarios, getting the tools working and plugging into the CI

rjones (Thu, 11 May 2017 16:23:48 GMT):
@bmos299 agreed with waiting

cbf (Thu, 11 May 2017 17:20:38 GMT):
@rjones what do you mean "check out"? you mean if you are a developer you need to have another repo clone locally to run the tests?

rjones (Thu, 11 May 2017 17:20:57 GMT):
yes.

cbf (Thu, 11 May 2017 17:21:04 GMT):
boo hoo?

cbf (Thu, 11 May 2017 17:21:09 GMT):
;-)

rjones (Thu, 11 May 2017 17:21:30 GMT):
if they depend on fabric, I don't see the point unless they'll have a distinct maintainer list.

cbf (Thu, 11 May 2017 17:22:05 GMT):
in all seriousness, the intention for this would be to test against build artifacts (dockerhub or nexus hosted)

rjones (Thu, 11 May 2017 17:22:31 GMT):
ah, this makes much more sense. Objection withdrawn

cbf (Thu, 11 May 2017 17:22:33 GMT):
it would have dependencies on fabric, fabric-sdk-*, fabric-ca, and whatever comes next

cbf (Thu, 11 May 2017 17:23:16 GMT):
hence @jimthematrix suggestion 'fabric-integration' makes total sense

cbf (Fri, 12 May 2017 00:53:10 GMT):
@here https://gerrit.hyperledger.org/r/#/c/9267/ <- proposal for how we will handle feature/enhancement proposals - please review and +1 if maintainer ... let's see if we can get 5 or more +1s to merge

cbf (Fri, 12 May 2017 11:35:44 GMT):
@here I would suggest that until we cut the alpha2 branch, that we ONY merge the three remaining items proposed in the comment to FAB-3040

cbf (Fri, 12 May 2017 11:36:20 GMT):
Please do not submit any CRs until we have sorted things out

dave.enyeart (Fri, 12 May 2017 13:44:24 GMT):
@cbf @JonathanLevi I was a little confused by FAB-3040. Seems like the intent of FAB-3040 was for 1.0 GA master plan / checklist, but we are now using it for alpha2 items. Should we split it into two work items to make it more clear for everybody?

cbf (Fri, 12 May 2017 13:44:58 GMT):
@dave.enyeart just focus on the blockers please

cbf (Fri, 12 May 2017 13:45:08 GMT):
yes, confusing but ignore 1.0 for now

cbf (Fri, 12 May 2017 13:45:19 GMT):
blockers was what we were targeting for alpha2

cbf (Fri, 12 May 2017 13:45:40 GMT):
the discussion is currently happening in #fabric-release

dave.enyeart (Fri, 12 May 2017 13:45:42 GMT):
ok, just seemed a separate work item would be warranted for alpha2

cbf (Fri, 12 May 2017 13:45:53 GMT):
I created one

cbf (Fri, 12 May 2017 13:46:05 GMT):
https://jira.hyperledger.org/browse/FAB-3891

dave.enyeart (Fri, 12 May 2017 13:46:10 GMT):
cool

JonathanLevi (Fri, 12 May 2017 14:21:18 GMT):
https://chat.hyperledger.org/channel/fabric-release?msg=3NKJEcXdfxaFoPTRi

JonathanLevi (Fri, 12 May 2017 14:21:32 GMT):
Any objections to getting these merged? https://jira.hyperledger.org/browse/FAB-3737 generate changelog for v1.0.0-alpha2 https://gerrit.hyperledger.org/r/#/c/9167 https://jira.hyperledger.org/browse/FAB-3218 Sync Java/Golang ChaincodeStub interface https://gerrit.hyperledger.org/r/#/c/8529 https://jira.hyperledger.org/browse/FAB-3850 don't allow Java CC access for alpha2 as its not quite usable yet. https://gerrit.hyperledger.org/r/#/c/9245

cbf (Fri, 12 May 2017 14:23:16 GMT):
I just want Greg to look at https://gerrit.hyperledger.org/r/#/c/9167/

troyronda (Fri, 12 May 2017 20:37:20 GMT):
Hi all - a fabric feature proposal has been posted - Private Channel Data. Please see https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/000949.html for more information. Feedback welcome!

cbf (Fri, 12 May 2017 20:48:37 GMT):
thx

JonathanLevi (Sun, 14 May 2017 18:44:50 GMT):
Just to be clear, we are still in *CODE FREEZE*. No merging of anything other than stuff that is in agreement (in writing), until we have the release published and we declare otherwise.

greg.haskins (Mon, 15 May 2017 18:43:40 GMT):
maintainers: I request that you review this JIRA for consideration for 1.0: https://jira.hyperledger.org/browse/FAB-3118

greg.haskins (Mon, 15 May 2017 18:44:07 GMT):
without it, it will not be possible to support fabric for use with most docker orchestration engines

greg.haskins (Mon, 15 May 2017 18:44:41 GMT):
(not to mention, it makes the system much more awkward to use, even when a workaround is possible

greg.haskins (Mon, 15 May 2017 19:28:28 GMT):
also, we should talk about the mechanics/rules of such a proposal

greg.haskins (Mon, 15 May 2017 19:28:41 GMT):
for instance: use the JIRA vote? how many votes needed? etc

yacovm (Mon, 15 May 2017 19:32:36 GMT):
@greg.haskins isn't this sort of a bug fix?

yacovm (Mon, 15 May 2017 19:33:15 GMT):
This is a fix as a result of someone encountering an issue and having to do a workaround

greg.haskins (Mon, 15 May 2017 19:38:24 GMT):
It is def a bug fix...however, by my understanding, we want to have scrutiny over what does or doesnt go in to the tree right now

greg.haskins (Mon, 15 May 2017 19:38:58 GMT):
i understand some things are clearly a new feature, and some things are clearly a bug fix (such as this) but theres also the question of risk/reward/severity, etc

greg.haskins (Mon, 15 May 2017 19:40:21 GMT):
but to your point, perhaps this isnt the best example to give the "lets discuss and decide" policy a workout

yacovm (Mon, 15 May 2017 20:00:28 GMT):
1) I have to say that I cannot say if we can instead publish a workaround because I'm not a typical user of the project and therefore I do not know how people approach to install their *fabric-dev-env* for their use cases. I know that not all bugs are going to be fixed for v1.0 and some will have workarounds publishes instead. 2) I guess another thing to consider for this and in general is - given a bug fix, how confident are we that merging it doesn't break anything.

lehors (Mon, 15 May 2017 20:11:48 GMT):
could one of the maintainers please remove jobbuilder from https://gerrit.hyperledger.org/r/#/c/8887 ?

lehors (Mon, 15 May 2017 20:13:08 GMT):
I didn't have [ci-skip] in my initial push and it triggered the build, and does so everytime I patched my CR - it's no big deal but I feel bad wasting CPU...

C0rWin (Mon, 15 May 2017 20:13:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=xmWBofSQD72SW6Jpd) @lehors done

lehors (Mon, 15 May 2017 20:13:56 GMT):
thanks! :)

C0rWin (Mon, 15 May 2017 20:14:50 GMT):
yw, let's stop C02 pollution

lehors (Mon, 15 May 2017 20:15:59 GMT):
wait, it's still there?

lehors (Mon, 15 May 2017 20:16:44 GMT):
do I have my [ci-skip] in the wrong place?

lehors (Mon, 15 May 2017 20:16:49 GMT):
I thought it was anywhere

lehors (Mon, 15 May 2017 20:17:35 GMT):
I'm confused now :(

C0rWin (Mon, 15 May 2017 20:18:44 GMT):
I do not think that [ci-skip] works anymore

lehors (Mon, 15 May 2017 20:18:52 GMT):
oh

C0rWin (Mon, 15 May 2017 20:19:27 GMT):
just removed jobbuild second time, but it appears again

yacovm (Mon, 15 May 2017 20:19:37 GMT):
Even if it works, it spawns a new VM anyway. skip-ci works by having jenkins spin a new VM, read the commit message from the env var, and then abort the build.

C0rWin (Mon, 15 May 2017 20:19:39 GMT):
so I am not sure it's doable :/

C0rWin (Mon, 15 May 2017 20:20:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=q8pDbZqpWdvobBuZP) @yacovm such a waste

lehors (Mon, 15 May 2017 20:20:54 GMT):
oh well

C0rWin (Mon, 15 May 2017 20:21:23 GMT):
need to do more work to be greener :)

lehors (Mon, 15 May 2017 20:21:45 GMT):
yeah :)

lehors (Mon, 15 May 2017 20:22:14 GMT):
of course we could do worse and be working on bitcoin ;-)

rjones (Mon, 15 May 2017 20:28:32 GMT):
@lehors ci-skip was removed because the plugin is broken

lehors (Mon, 15 May 2017 20:29:29 GMT):
ok, good to know.

greg.haskins (Mon, 15 May 2017 20:58:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=SRf9HaiqFJdJdgaky) @yacovm With the caveat that "only a fool is certain", I am comfortable with the risk/reward ratio on this one

yacovm (Mon, 15 May 2017 21:02:40 GMT):
The reason I added (2) is that we have areas in the project that are seriously lacking in not only code coverage but in ability to write comprehensive and scenario-based unit tests, and on the other hand we have areas where it's possible to create custom made scenarios/flows in tests and this *should* be a part of the decision whether to merge something or not. I wasn't referring to whether one feels confident with his change set :)

yacovm (Mon, 15 May 2017 21:02:40 GMT):
The reason I added (2) is that we have areas in the project that are seriously lacking in not only code coverage but in ability to write comprehensive and scenario-based unit tests, and on the other hand we have areas where it's possible to create custom made scenarios/flows in tests and this *should* be a part of the decision whether to merge something or not at the end-game. I wasn't referring to whether one feels confident with his change set :)

yacovm (Mon, 15 May 2017 21:02:40 GMT):
The reason I added (2) is that we have areas in the project that are seriously lacking in not only code coverage but in ability to write comprehensive and scenario-based unit tests (*core/container/* is such an area), and on the other hand we have areas where it's possible to create custom made scenarios/flows in tests and this *should* be a part of the decision whether to merge something or not at the end-game. I wasn't referring to whether one feels confident with his change set :)

yacovm (Mon, 15 May 2017 21:02:40 GMT):
The reason I added (2) is that we have areas in the project that are seriously lacking in not only code coverage but in ability to write comprehensive and scenario-based unit tests ( *core/container/* is such an area), and on the other hand we have areas where it's possible to create custom made scenarios/flows in tests and this *should* be a part of the decision whether to merge something or not at the end-game. I wasn't referring to whether one feels confident with his change set :)

cbf (Tue, 16 May 2017 00:50:07 GMT):
@lehors [ci skip] has been disabled

cbf (Tue, 16 May 2017 00:50:22 GMT):
the plugin was broken and caused more trouble than it was worth

cbf (Tue, 16 May 2017 00:50:45 GMT):
it even triggered a moratorium on new plugins that aren't in the catalog

cbf (Tue, 16 May 2017 00:50:50 GMT):
and supported

cbf (Tue, 16 May 2017 00:51:47 GMT):
@here so, what can be merged is bug fixes, new or improved tests, and documentation improvements

cbf (Tue, 16 May 2017 00:52:15 GMT):
please when reviewing ensure that those things that are ostensibly bugs are in-fact bugs

cbf (Tue, 16 May 2017 00:52:31 GMT):
we should not be condoning enhanement by bug fix

cbf (Tue, 16 May 2017 00:52:31 GMT):
we should not be condoning enhancement by bug fix

cbf (Tue, 16 May 2017 00:53:20 GMT):
changes to code to support tests should be considered, but let's not let new code creep in under the radar, please

cbf (Tue, 16 May 2017 00:53:55 GMT):
also, addressing static analysis findings should be considered bug fixes

cbf (Tue, 16 May 2017 00:54:26 GMT):
that's my $0.02 - happy to entertain discussion on this

cbf (Tue, 16 May 2017 00:54:42 GMT):
@JonathanLevi ^^

jimthematrix (Tue, 16 May 2017 02:01:46 GMT):
_*let's not let new code creep in under the radar,*_ +2

JonathanLevi (Tue, 16 May 2017 10:21:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=wj7FDgHL2ALv62wK2) Good morning (and back to this):

JonathanLevi (Tue, 16 May 2017 10:21:55 GMT):
How do people feel about voting, indeed, in this sense: https://www.apache.org/foundation/voting.html

JonathanLevi (Tue, 16 May 2017 10:22:48 GMT):
People, as in, fellow maintainers (, free speech AND free beer)

JonathanLevi (Tue, 16 May 2017 10:24:16 GMT):
We don't want to rock the boat, and converge to a release... while at the same time, we don't want an unnecessary backlog of Good Things (tm) that are indeed welcome (such as the *test converage*, *logging* and the rest of *service-ability* and *tooling*).

C0rWin (Tue, 16 May 2017 10:27:05 GMT):
I think that in order to make progress decisions need to be taken

C0rWin (Tue, 16 May 2017 10:27:40 GMT):
IMO, the voting is very good way to converge with the quorum on certain direction

C0rWin (Tue, 16 May 2017 10:27:57 GMT):
rather than waiting some will make executive decision

C0rWin (Tue, 16 May 2017 10:27:57 GMT):
rather than waiting someone will make executive decision

JonathanLevi (Tue, 16 May 2017 10:29:04 GMT):
Just to note that we (yes, we) are the maintainers - we should make the decisions. What I'm trying to do, is to make us have the right information, in order to help us make the *right decisions*.

JonathanLevi (Tue, 16 May 2017 10:30:08 GMT):
Even though I have been blocking a few CRs in a row, while we are working out the release), I don't see the *Release Manager* role as a dictator. Benevolent, or otherwise ;-).

C0rWin (Tue, 16 May 2017 10:31:15 GMT):
so in given moment in time, how we should make decision of whenever to merge or not incoming changes?

C0rWin (Tue, 16 May 2017 10:31:35 GMT):
currently we keep queueing CR's

C0rWin (Tue, 16 May 2017 10:31:52 GMT):
which, IMO, will lead us into merge hell at some point

JonathanLevi (Tue, 16 May 2017 10:42:52 GMT):
That's why I suggest to take action (and vote). Answering Greg's question from above.

JonathanLevi (Tue, 16 May 2017 10:43:27 GMT):
It may be easier to have a set of things that are clearly good to merge (such as "tests")

JonathanLevi (Tue, 16 May 2017 10:43:49 GMT):
So that we don't need to vote on every move. I'm open to suggestions.

JonathanLevi (Tue, 16 May 2017 10:45:41 GMT):
Either end of the spectrum (making it so difficult to get anything merged, or the "merge-fest" [you read it first here! ;-)] ) is not right.

JonathanLevi (Tue, 16 May 2017 10:46:26 GMT):
Documentation, bug-fixes (but really bug-fixes, not a re-work of expected behaviour that results in adding 9 more features, as a fix), tests...

JonathanLevi (Tue, 16 May 2017 10:46:47 GMT):
These should really be straight-forward to merge. Would we agree?

JonathanLevi (Tue, 16 May 2017 10:47:38 GMT):
(again, we need judgement... I don't want a 50 page contract, with (re-)definitions of what's a feature, what's a test, etc.)

JonathanLevi (Tue, 16 May 2017 10:48:49 GMT):
More suggestions/feedback/input... ?

JonathanLevi (Tue, 16 May 2017 10:49:09 GMT):
(& thank you @C0rWin, of course. I agree.)

yacovm (Tue, 16 May 2017 10:50:27 GMT):
I think we can divide change sets into 3 groups: 1) Change sets that don't touch production code, that no voting is needed for them. 2) Change sets that touch production code and are critical bugs fixes and their solution isn't complex - that's not very well defined but I don't think we should wait for a vote on a critical bug fix. 3) The rest - we need voting at this point, the question is how and how much. I guess that we can vote in JIRA explicitly

mastersingh24 (Tue, 16 May 2017 10:55:01 GMT):
We also should not be getting into merge hell (other than the annoying rebase when required). UT improvements should not be crossing boundaries - if they are we have problems. I can see that for some bug fixes there MAY be collisions due to the tangled nature of some of the code, but again I would hope it is rare. Hopefully every component owner has prioritized bugs for their component(s) in JIRA? (Also - I feel like people think this is some type of race - hopefully that is not the case)

cbf (Tue, 16 May 2017 11:19:50 GMT):
https://gerrit.hyperledger.org/r/#/c/9267/ I've addressed the feedback on the proposal. Please +1 and when we have 5 it can be merged thanks

cbf (Tue, 16 May 2017 11:25:03 GMT):
Agree with @mastersingh24 UT improvements should be (for the most part) limited to _test.go files and they should not be crossing boundaries.

cbf (Tue, 16 May 2017 11:25:45 GMT):
Let's not have premature optimization of a problem we don't know we have. Worrying about "merge hell" is definitely premature

cbf (Tue, 16 May 2017 11:26:05 GMT):
as for fixes, I agree with Yacov's assessment and classification

cbf (Tue, 16 May 2017 11:27:26 GMT):
I think that we should define a sprint and for those JIRAs that fall into category 3 in @yacovm classification, we should be voting on adding to the current sprint

cbf (Tue, 16 May 2017 11:28:26 GMT):
we could have a twice-weekly assessment and maybe a label that we use to query those JIRAs that need assessment by maintainers

cbf (Tue, 16 May 2017 11:29:56 GMT):
thoughts?

cbf (Tue, 16 May 2017 11:30:39 GMT):
then, any JIRA in the current sprint is permitted to be merged, others need to be voted on and either added to the sprint or deferred

dave.enyeart (Tue, 16 May 2017 11:54:12 GMT):
I've just posted in #fabric-release that Getting Started instructions are broken. Please review the fixes mentioned there.

C0rWin (Tue, 16 May 2017 12:10:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=74ACXa6Zq8mofDLSu) @cbf I feel, that at least 80% of JIRA items created ad-hoc

yacovm (Tue, 16 May 2017 12:13:37 GMT):
Perhaps until V1 is out we can just do it once a day

yacovm (Tue, 16 May 2017 12:13:50 GMT):
twice a week is IMO a too low frequency

C0rWin (Tue, 16 May 2017 12:14:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=4uwZiM7X8SSzn56yY) @yacovm sounds reasonable

cbf (Tue, 16 May 2017 12:22:37 GMT):
@yacovm @C0rWin I do it every day now;-) that works for me, I suppose

C0rWin (Tue, 16 May 2017 12:24:25 GMT):
can you, please , share the query you are using to browse the JIRA and how I can find issues or be certain that given CR is fine to go?

kostas (Tue, 16 May 2017 13:26:35 GMT):
I'm going through the logs of the past few days and feel like I'm missing something.

kostas (Tue, 16 May 2017 13:26:41 GMT):
What has changed over the mode that we have been running on for the past month or so? With the exception of the consortium/config-related changes that introduced new functionality, haven't we just been merging bug fixes / tests / doc changes / polish+harderning changes all this time?

cbf (Tue, 16 May 2017 13:34:06 GMT):
so, the craziness attendant to cutting alpha2 disrupted the thread on the release exit criteria - I would like to finalize this @here and now...

cbf (Tue, 16 May 2017 13:34:07 GMT):
https://wiki.hyperledger.org/projects/fabric/release_exit_criteria

cbf (Tue, 16 May 2017 13:34:50 GMT):
please respond here TODAY with +2 or -1 on what I have published

cbf (Tue, 16 May 2017 13:34:53 GMT):
thanks

cbf (Tue, 16 May 2017 13:40:44 GMT):
@kostas yes, that has been a bit of an unwritten state of affairs

cbf (Tue, 16 May 2017 13:41:07 GMT):
want to make it more clear and a process for how we address borderline cases

cbf (Tue, 16 May 2017 13:41:38 GMT):
I have seen some fixes that were not bugs but enhancements

JonathanLevi (Tue, 16 May 2017 14:09:36 GMT):
We are basically (also) trying to check our "readiness"... if we really feel that our APIs are solid and really final, after enough usage/testing... then we'll proceed. It is a lot more difficult to do it under the "merging deluge" we had a few weeks ago...

cbf (Tue, 16 May 2017 14:12:23 GMT):
+1

cbf (Tue, 16 May 2017 14:26:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=tsq6WJTauSWWsbTkr) @cbf @muralisr @binhn @jyellick @kostas @JonathanLevi @greg.haskins @mastersingh24 @yacovm @C0rWin @dave.enyeart @jimthematrix @hgabre @TamasBlummer please weigh in on the release exit criteria

cbf (Tue, 16 May 2017 14:26:56 GMT):
https://wiki.hyperledger.org/projects/fabric/release_exit_criteria

muralisr (Tue, 16 May 2017 14:29:47 GMT):
@cbf there was discussion on `that there have been security scans (static and dynamic), code audit and penetration testing with all significant findings reported in JIRA,` ... I got the impression this could be a big one ? has this been finalized yet ?

C0rWin (Tue, 16 May 2017 14:32:03 GMT):
@cbf I think that release exit should be gradual, e.g. RM need declare release candidate -> code freeze -> compliance with exit criteria. Hence it probably worth splitting exit criteria into two phases: RC and GA.

yacovm (Tue, 16 May 2017 14:33:25 GMT):
> no open bugs that affect security of the system that cannot be mitigated by workaround, > all open bugs that affect security have workarounds published in release notes, These can be combined into 1 bullet (no open bugs that affect security unless a workaround has been published)

cbf (Tue, 16 May 2017 14:34:36 GMT):
@C0rWin yes, of course, that is not what this is about... this is about when is it ready for 1.0 (and beyond)

dhuseby (Tue, 16 May 2017 14:35:00 GMT):
@cbf crypto export scan must be complete too

dhuseby (Tue, 16 May 2017 14:35:05 GMT):
I have somebody already working on that

dhuseby (Tue, 16 May 2017 14:35:10 GMT):
let me follow up with them today

cbf (Tue, 16 May 2017 14:35:20 GMT):
@dhuseby please add to the wiki then if missing

dhuseby (Tue, 16 May 2017 14:35:28 GMT):
otherwise the exit criteria look good

dhuseby (Tue, 16 May 2017 14:35:47 GMT):
I don't think you need to specify that incoming bug counts are declining for 3 weeks

dhuseby (Tue, 16 May 2017 14:36:10 GMT):
that's not really a sign of readiness IMO

dhuseby (Tue, 16 May 2017 14:36:48 GMT):
because you can have 15 new bugs on week 1, 10 on week 2, and 5 on week 3, but on week 4 you could find 1 security critical bug that should hold up the whole release

JonathanLevi (Tue, 16 May 2017 14:37:43 GMT):
BTW: `critical` (== `show stopper`). Even a 0.5 x critical is a LOT. That is, we won't release with it.

JonathanLevi (Tue, 16 May 2017 14:37:52 GMT):
(without it getting fixed)

jyellick (Tue, 16 May 2017 14:40:08 GMT):
Release criteria looks good to me

cbf (Tue, 16 May 2017 14:40:43 GMT):
@dhuseby yes, but the sev1 critical bug would disqualify anyway

dhuseby (Tue, 16 May 2017 14:41:06 GMT):
sure, I guess, I just don't see new vs resolved declining for 3 weeks as a useful metric for anything

dhuseby (Tue, 16 May 2017 14:41:15 GMT):
and it is gamable

JonathanLevi (Tue, 16 May 2017 14:42:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=o7hEyZW2KW7cBpSZu) (sorry, that's what I meant above, yes)

cbf (Tue, 16 May 2017 14:42:06 GMT):
actually, someone asked that it be tweaked to indicate post a RC

cbf (Tue, 16 May 2017 14:42:44 GMT):
you don't want to publish a RC that meets all criteria and for which new bugs are coming in

cbf (Tue, 16 May 2017 14:42:55 GMT):
maybe 3 weeks too long... don't know

C0rWin (Tue, 16 May 2017 14:43:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=JoihQ8a6jTsWLPuQ3) @cbf got it, then it's fine with me

cbf (Tue, 16 May 2017 14:43:14 GMT):
we haven't got enough experience to determine

dhuseby (Tue, 16 May 2017 14:43:29 GMT):
why not? RC are release candidates no? Publishing one should spark a new round of bug reporting.

cbf (Tue, 16 May 2017 14:43:49 GMT):
maybe we just say that there is a minimum time for a RC to be public before we make it a formal release

dhuseby (Tue, 16 May 2017 14:43:59 GMT):
that sounds like better criteria

cbf (Tue, 16 May 2017 14:44:01 GMT):
yes

dhuseby (Tue, 16 May 2017 14:44:06 GMT):
because aren't we going to release when it is ready?

dhuseby (Tue, 16 May 2017 14:44:13 GMT):
that's how open source works

cbf (Tue, 16 May 2017 14:44:15 GMT):
yes

cbf (Tue, 16 May 2017 14:45:36 GMT):
@dhuseby "a release candidate will have been published for a minimum of two weeks"

cbf (Tue, 16 May 2017 14:45:38 GMT):
ok?

cbf (Tue, 16 May 2017 14:46:10 GMT):
actually, "the preceding release candidate will have been published for a minimum of two weeks"

muralisr (Tue, 16 May 2017 14:48:29 GMT):
@cbf except for my question on what the process for security scans will be and is formalized, looks good to me

muralisr (Tue, 16 May 2017 14:48:46 GMT):
the above could just be my ignorance of course

vdods (Tue, 16 May 2017 16:45:53 GMT):
Has left the channel.

cbf (Tue, 16 May 2017 18:32:21 GMT):
@muralisr @dhuseby is working on the security scans... we DO need details and plan, etc. IBM also runs such scans and we can see what we can share that makes sense (some will be more about our web interface than the actual fabric code)

cbf (Tue, 16 May 2017 18:32:39 GMT):
There are also a couple of JIRAs looking to add static scans to CI

dhuseby (Tue, 16 May 2017 18:33:31 GMT):
@cbf I have reached out to Softvision to ask about them doing security audits for us. I also have contacts at Rapid7, though I think they do pen testing more that code audits.

dhuseby (Tue, 16 May 2017 18:33:49 GMT):
right now I'm focusing on just the crypto export compliance stuff

cbf (Tue, 16 May 2017 18:33:52 GMT):
we do need both, no?

dhuseby (Tue, 16 May 2017 18:34:00 GMT):
I think we do

dhuseby (Tue, 16 May 2017 18:34:10 GMT):
CII requires it for each major release.

cbf (Tue, 16 May 2017 18:34:12 GMT):
can you please edit the wiki accordingly?

dhuseby (Tue, 16 May 2017 18:34:25 GMT):
I think the language is something like "a security code audit for each major release"

dhuseby (Tue, 16 May 2017 18:34:35 GMT):
but I take that to mean both static and dynamic analysis and penetration

dhuseby (Tue, 16 May 2017 18:34:48 GMT):
@cbf where in the wiki specifically?

dhuseby (Tue, 16 May 2017 18:34:54 GMT):
the exit criteria?

cbf (Tue, 16 May 2017 18:35:10 GMT):
https://wiki.hyperledger.org/projects/fabric/release_exit_criteria

dhuseby (Tue, 16 May 2017 18:35:18 GMT):
also, I've been meaning to ask you about the companies IBM usually uses for security audits and pen testing

dhuseby (Tue, 16 May 2017 18:35:30 GMT):
@cbf roger, yes, i'll edit

cbf (Tue, 16 May 2017 18:35:39 GMT):
pen testing we source to our security group

cbf (Tue, 16 May 2017 18:36:38 GMT):
security scans are also run in-house - @weeds may have details

cbf (Tue, 16 May 2017 18:37:17 GMT):
again, this would be against the deployed code, and most of the coverage pertains to the Web UI and any externally exposed APIs

weeds (Tue, 16 May 2017 18:50:57 GMT):
@markparz actually Mark has been chasing some of this, given he's worked this in past. He is not in today, but hopefully tomorrow he can share some details

weeds (Tue, 16 May 2017 18:52:01 GMT):
it would be good to understand what companies/runs we need to do specifically, given i know there are long lead times for some of the security work (things like pen testing are not always easy)

JonathanLevi (Tue, 16 May 2017 19:00:50 GMT):
--- Bring out the gimp ( that is, *let's get some UTs merged! * )

JonathanLevi (Tue, 16 May 2017 19:01:05 GMT):
---

mastersingh24 (Tue, 16 May 2017 20:38:25 GMT):
[ so tempted to post a link to the gimp - but I'm sure it violates the code of conduct](https://chat.hyperledger.org/channel/fabric-maintainers?msg=5RLAEN9c8aEfdH9q5) @JonathanLevi

jimthematrix (Tue, 16 May 2017 20:40:53 GMT):
the exit criteria looks good to me

tkuhrt (Tue, 16 May 2017 23:10:05 GMT):
A license scan has been run for all projects approaching 1.0. For the fabric* repositories, I have the output from our license scan. How would the Fabric maintainers like to receive this information? I can add a link to the results here or I can put them on the mailing list. Changes will be required to meet licensing requirements.

JonathanLevi (Tue, 16 May 2017 23:51:21 GMT):
Even a JIRA ticket with an output will do.

JonathanLevi (Tue, 16 May 2017 23:52:05 GMT):
@tkuhrt: we can make it a task that needs addressing, and add it to FAB-3040... (thank you)

JonathanLevi (Tue, 16 May 2017 23:52:58 GMT):
We will certainly prioritize licensing!

tkuhrt (Wed, 17 May 2017 00:26:43 GMT):
Thanks, Jonathan. I have added https://jira.hyperledger.org/browse/FAB-3963 to cover licensing

tkuhrt (Wed, 17 May 2017 00:26:56 GMT):
Please let me know if you have questions

lehors (Wed, 17 May 2017 11:12:24 GMT):
holy smoke

lehors (Wed, 17 May 2017 11:15:47 GMT):
wait, something isn't quite right with those results

lehors (Wed, 17 May 2017 11:16:50 GMT):
it's listing files like: fabric-test-resources/.git/config as not having a license

lehors (Wed, 17 May 2017 11:17:07 GMT):
fabric-test-resources/.git/HEAD

lehors (Wed, 17 May 2017 11:18:36 GMT):
surely we are not expected to have licenses in those files, right?

lehors (Wed, 17 May 2017 11:18:50 GMT):
@tkuhrt it looks like some cleanup needs to be done here

lehors (Wed, 17 May 2017 11:20:41 GMT):
and then there are files that were generated like fabric/bddtests/peer/admin_pb2.py

lehors (Wed, 17 May 2017 11:22:42 GMT):
so, between the vendoring and these it's not surprising the numbers are so large

JonathanLevi (Wed, 17 May 2017 11:24:43 GMT):
(Good morning)

JonathanLevi (Wed, 17 May 2017 11:25:23 GMT):
We also don't add license info/header to the shell scripts

yacovm (Wed, 17 May 2017 11:26:12 GMT):
we don't

greg.haskins (Wed, 17 May 2017 11:56:42 GMT):
@tkuhrt "Ideally, the repositories should not include any dependencies, but rather the build process should make sure to pull the latest version of any dependencies". I assume you were largely noting the vendored dependencies in the golang code? Normally I would agree with you, but note that this _is_ how you officially use dependencies in golang.

greg.haskins (Wed, 17 May 2017 11:58:22 GMT):
In my opinion, the golang architects completely screwed up the dependency system, and vendoring was added in the aftermath to deal with it around go v1.6 timeframe...but it is what it is, and we have to deal with it

weeds (Wed, 17 May 2017 13:00:38 GMT):
@JonathanLevi Beyond bringing out the gimp and getting UTs merged (grinning still at that) Can we also get some help to get what scottz and bmoss posted in pr channel-- we are trying to get that automated system test going, but stuff does need to get checked in to really do it right-- Thanks!

weeds (Wed, 17 May 2017 13:01:10 GMT):
(pr review channel that is)

cbf (Wed, 17 May 2017 13:09:31 GMT):
@here I'll take an AI to work with Tracy and Brian on the vendored bits. I agree with Arnaud that we need to exclude noise like git metadata files and generated content such as protobuf files.

greg.haskins (Wed, 17 May 2017 13:11:18 GMT):
@cbf first pass through I took that as "ill set up artificial intelligence to work on .... vendored bits"

greg.haskins (Wed, 17 May 2017 13:11:53 GMT):
seemed a bit extreme, but also interesting ;)

tkuhrt (Wed, 17 May 2017 13:31:26 GMT):
Why do we check in generated files?

tkuhrt (Wed, 17 May 2017 13:32:59 GMT):
I was under the impression that "go get ./.." pulls in dependencies before a build.

tkuhrt (Wed, 17 May 2017 13:36:17 GMT):
All script files are considered code and will need license information included

tkuhrt (Wed, 17 May 2017 13:50:22 GMT):
Found this article on dependencies: https://blog.gopheracademy.com/advent-2016/saga-go-dependency-management/. Looks like their is an alpha version of the dep tool that will remove the requirement of the vendor directory.

lehors (Wed, 17 May 2017 13:55:53 GMT):
dear maintainers, I just attended the fabric scrum call and there is confusion as to whether alpha2 is really cut yet or not

lehors (Wed, 17 May 2017 13:56:23 GMT):
will you guys post an announcement to the fabric mailing list when it is?

yacovm (Wed, 17 May 2017 14:00:23 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=fYgu9qS8Xrusg6Syr

JonathanLevi (Wed, 17 May 2017 14:04:31 GMT):
@here: We are still waiting on some final updates in order to announce the release. We improved things since the "tag", but we are still waiting for the Getting Started guide update. Otherwise, we are going to get so many complaints and questions.

JonathanLevi (Wed, 17 May 2017 14:04:31 GMT):
@here: We are still waiting on some final updates in order to announce the release. We improved things since the "tag", but we are still waiting for the *Getting Started* guide update. Otherwise, we are going to get so many complaints and questions.

JonathanLevi (Wed, 17 May 2017 14:05:08 GMT):
Otherwise, unless we find anything else (in the coming hours,...) that is out of sync, we'll be good to go.

lehors (Wed, 17 May 2017 14:05:35 GMT):
sounds reasonable but beware that this kind of situation is very confusing

JonathanLevi (Wed, 17 May 2017 14:05:37 GMT):
(And an email, indeed, will be sent out to announce)

lehors (Wed, 17 May 2017 14:05:54 GMT):
people see the images on dockerhub and the tag on github

lehors (Wed, 17 May 2017 14:06:03 GMT):
yet it's not announced

JonathanLevi (Wed, 17 May 2017 14:06:11 GMT):
@lehors: I appreciate it. I'm more concerned with people not able to follow the basic Getting Started (step by step)

lehors (Wed, 17 May 2017 14:06:35 GMT):
I agree with you, between the two I think you're making the right choice

lehors (Wed, 17 May 2017 14:06:58 GMT):
but this brings up again the question of "where does one find what the status is"

JonathanLevi (Wed, 17 May 2017 14:07:07 GMT):
The sooner we fix the last bits (and @lehors, I did merge the file paht corrections, etc. last night).... the better.

JonathanLevi (Wed, 17 May 2017 14:08:01 GMT):
Just to say, that we were actually surprised too. Otherwise, we would have "tagged" right after that fix.

cbf (Wed, 17 May 2017 14:08:30 GMT):
@lehors FAB-3040

JonathanLevi (Wed, 17 May 2017 14:08:45 GMT):
Yup, we also have it in the wiki.

JonathanLevi (Wed, 17 May 2017 14:09:09 GMT):
We are really working to make the "status" of everything a lot easier to find. (More) feedback welcome.

JonathanLevi (Wed, 17 May 2017 14:09:09 GMT):
We are really working to make the "status" of everything a lot easier to find. (More) feedback/suggestions regarding how to improve it more/better are aways welcome.

cbf (Wed, 17 May 2017 14:09:28 GMT):
we obviously can do more and better about keeping JIRA current, but that is where to look... the more we have people looking there, the more eyeballs and arms on keeping it current

dave.enyeart (Wed, 17 May 2017 14:10:08 GMT):
@JonathanLevi @greg.haskins @cbf @mastersingh24 I believe the next step for Getting Started is to push the Getting Started materials to nexus. This change has been in review: https://gerrit.hyperledger.org/r/#/c/8939/ https://jira.hyperledger.org/browse/FAB-2986. Greg, Chris, and Gari each have comments in there. I think we need you guys to clarify your comments and decide if the comments can be deferred for next time around, so that we dont hold up alpha2 announce further.

lehors (Wed, 17 May 2017 14:10:28 GMT):
sounds good but where is what Jonathan just said here about the status on that JIRA??

dave.enyeart (Wed, 17 May 2017 14:12:50 GMT):
why are we still using FAB-3040 (intended for 1.0 GA release) work item to manage alpha2 release work items?

dave.enyeart (Wed, 17 May 2017 14:13:32 GMT):
Last time I mentioned this, @cbf pointed us to a alpha2 work item, but it didnt have much content (and i cant find it now)

dave.enyeart (Wed, 17 May 2017 14:14:00 GMT):
I think we really need to have one Jira item as an umbrella for each 'release'

dave.enyeart (Wed, 17 May 2017 14:14:00 GMT):
I think we really need to have one Jira item as an umbrella per each 'release'

dave.enyeart (Wed, 17 May 2017 14:15:06 GMT):
then to lehors point, we can point people to that Jira item which would have a summary of status

dave.enyeart (Wed, 17 May 2017 14:15:06 GMT):
then to lehors point, we can point people to that Jira item which would have a summary of status for that 'release' e.g. alpha2

JonathanLevi (Wed, 17 May 2017 14:15:42 GMT):
Please note that we do need people to fill in the right information in JIRA in order for the "filtering" to work/make sense.

JonathanLevi (Wed, 17 May 2017 14:16:10 GMT):
I/we have been trying to amend and correct a lot of them...and posted the guidelines on the wiki... but for example:

JonathanLevi (Wed, 17 May 2017 14:16:11 GMT):
https://jira.hyperledger.org/browse/FAB-3947?jql=project%20%3D%20FAB%20AND%20fixVersion%20%3D%20v1.0.0-alpha2

JonathanLevi (Wed, 17 May 2017 14:16:30 GMT):
(If you click on the `alpha2` tag, this is what you should see)

JonathanLevi (Wed, 17 May 2017 14:17:35 GMT):
I believe that it will help if all of us (maintainers) will try to make sure that the *Fix Version/s* and *Affects Version/s* are up to date.

kostas (Wed, 17 May 2017 14:17:56 GMT):
Well, speaking of --

kostas (Wed, 17 May 2017 14:17:59 GMT):
> the JIRA item is complete in its description of the problem and the resolution, and is appropriately labeled, categorized and identifies the current release in Affects Version/s and the pending release in Fix Version/s

kostas (Wed, 17 May 2017 14:18:05 GMT):
Source: https://wiki.hyperledger.org/projects/fabric/release_exit_criteria

JonathanLevi (Wed, 17 May 2017 14:18:17 GMT):
Exactly ! Thank you @kostas

lehors (Wed, 17 May 2017 14:18:51 GMT):
yeah...

kostas (Wed, 17 May 2017 14:18:59 GMT):
Actually I have a question :slight_smile: All the JIRAs that we're working on now? How do we know what the right "fix version" value is? alpha-3? beta-1?

kostas (Wed, 17 May 2017 14:18:59 GMT):
Actually I have a question :slight_smile: All the JIRAs that we're working on now -- how do we know what the right "fix version" value is? alpha-3? beta-1?

yacovm (Wed, 17 May 2017 14:19:21 GMT):
I'd assume the fix version can be set when you finish the item?

yacovm (Wed, 17 May 2017 14:19:25 GMT):
and it's merged?

JonathanLevi (Wed, 17 May 2017 14:19:34 GMT):
For now, whatever is not for `v1.0.0-alpha2` is set to be `v1.0.0`

kostas (Wed, 17 May 2017 14:19:50 GMT):
@yacov: Even then, how do you know whether next version is going to be alpha-3 or beta-1?

kostas (Wed, 17 May 2017 14:19:50 GMT):
@yacovm: Even then, how do you know whether next version is going to be alpha-3 or beta-1?

yacovm (Wed, 17 May 2017 14:19:58 GMT):
v1

kostas (Wed, 17 May 2017 14:20:12 GMT):
Got it.

JonathanLevi (Wed, 17 May 2017 14:20:35 GMT):
When we are going to work on the next known milestone, and we agree on whether it is `v1.0.0-beta` or `v1.0.0-alpha3`... we will update accordingly, what should be in the upcoming release.

JonathanLevi (Wed, 17 May 2017 14:20:52 GMT):
Again (as always), opinions and suggestions welcome.

kostas (Wed, 17 May 2017 14:21:08 GMT):
So we'll need to go back to the items that were set as "fix version = v1" and update them accordingly?

JonathanLevi (Wed, 17 May 2017 14:21:34 GMT):
I hope that we will be able to clear all of FAB-3040 before the next "cut".

cbf (Wed, 17 May 2017 14:21:52 GMT):
@kostas you don't, but there is nothing else we can use to track atm

cbf (Wed, 17 May 2017 14:22:14 GMT):
it can be changed when actually completed, or when something gets kicked down the road

cbf (Wed, 17 May 2017 14:22:58 GMT):
@kostas fixVersion v1.0.0 is fine for now

kostas (Wed, 17 May 2017 14:22:59 GMT):
As I said, "when it's actually completed" doesn't quite make sense, because we may still not now what the next release is.

kostas (Wed, 17 May 2017 14:23:12 GMT):
The v1 fix version rule works though.

yacovm (Wed, 17 May 2017 14:23:42 GMT):
@cbf when and where can we talk about the 2 items - 3715 and 3359 ? I think they are (2) (critical security bugs) but I'd like to see them added to 3040 if that's possible

yacovm (Wed, 17 May 2017 14:23:42 GMT):
@cbf @JonathanLevi when and where can we talk about the 2 items - 3715 and 3359 ? I think they are (2) (critical security bugs) but I'd like to see them added to 3040 if that's possible

kostas (Wed, 17 May 2017 14:24:37 GMT):
Back to Dave's point: https://chat.hyperledger.org/channel/fabric-maintainers?msg=3m7GmgpYorhMaf7rQ

kostas (Wed, 17 May 2017 14:25:10 GMT):
Wouldn't it be prudent to create a new epic for the next release (name TBD), and link all newly completed items against it?

kostas (Wed, 17 May 2017 14:25:10 GMT):
Wouldn't it be prudent to create a new epic for the next release (name TBD) _now_, and link all newly completed items against it?

kostas (Wed, 17 May 2017 14:25:33 GMT):
Then when we decide that the next release is, say, beta-1, we just update the epic name and we have that good to go.

cbf (Wed, 17 May 2017 14:26:44 GMT):
@kostas possibly but let's please not change horses - we have an epic and we are tracking stuff there

cbf (Wed, 17 May 2017 14:27:05 GMT):
for now, we should just be fixing bugs, adding tests and improving docs

JonathanLevi (Wed, 17 May 2017 14:27:31 GMT):
We are really trying to simplify matters. It a New Thing(tm), so that people can easily find them.

cbf (Wed, 17 May 2017 14:27:34 GMT):
we have a policy for tracking things that need more review

cbf (Wed, 17 May 2017 14:27:44 GMT):
see bottom of release exit criteria page

kostas (Wed, 17 May 2017 14:29:35 GMT):
@cbf: Roger, and these are the kind of work items I'm talking about. What I still haven't figured out is: do we link all 1.0.0 (incl. alpha-2) related items against the 3040 epic? I thought that was the case, but Dave asked a few days back and he was told that we should be using the alpha-2 epic for this?

kostas (Wed, 17 May 2017 14:30:10 GMT):
So, do we have one mega 1.0 epic where every JIRA from every pre-1.0 cut gets linked, or not?

kostas (Wed, 17 May 2017 14:30:19 GMT):
I don't have a hard stand on this, and I can roll either way.

kostas (Wed, 17 May 2017 14:30:19 GMT):
I don't have a hard stand on this, and I can roll either way. But I'm getting slightly mixed signals on what we want to do.

yacovm (Wed, 17 May 2017 14:30:38 GMT):
Wait, alpha2 epic? I thought we are using 3040?

kostas (Wed, 17 May 2017 14:31:14 GMT):
Let me try to find the convo.

kostas (Wed, 17 May 2017 14:32:25 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=ij46WkWp6nBmr3Fby and https://chat.hyperledger.org/channel/fabric-maintainers?msg=c4H8CTG8CGfz8thP2 and the response below

cbf (Wed, 17 May 2017 14:32:47 GMT):
@kostas no, I don't think so... it made sense when we were coming down to the wire to track blockers

cbf (Wed, 17 May 2017 14:33:11 GMT):
not sure we need to do that throughout

kostas (Wed, 17 May 2017 14:33:48 GMT):
Got it, so just to confirm: link any completed JIRA from now on against 3040? (Until we cut 1.0)

cbf (Wed, 17 May 2017 14:35:47 GMT):
no, no need to

cbf (Wed, 17 May 2017 14:36:10 GMT):
we can track what has merged and what was completed

cbf (Wed, 17 May 2017 14:36:31 GMT):
I think that the only time we need to track something is if it MUST be in the next release

dave.enyeart (Wed, 17 May 2017 14:38:59 GMT):
can we get back to what we need to tactically do this morning in order to unleash alpha2. I believe the next step for Getting Started is to push the Getting Started materials to nexus. This would be a tarball including /example/e2e_cli, configtxgen, cryptogen. This change has been in review: https://gerrit.hyperledger.org/r/#/c/8939 https://jira.hyperledger.org/browse/FAB-2986. @cbf can you review/approve that one this morning?

dave.enyeart (Wed, 17 May 2017 14:39:33 GMT):
Then, after that is done, Nick will update Getting Started with the links to nexus and docker images, so that people can start working through Getting Started without having to make images

cbf (Wed, 17 May 2017 14:39:38 GMT):
I did, but mu issues was just technical nit

cbf (Wed, 17 May 2017 14:39:53 GMT):
and I cannot merge stuff there anyway

cbf (Wed, 17 May 2017 14:40:03 GMT):
all that jenkins stuff is greek to me

mastersingh24 (Wed, 17 May 2017 14:40:26 GMT):
@dave.enyeart - I had a question on 8939 - let me see if it was answered

mastersingh24 (Wed, 17 May 2017 14:41:03 GMT):
It's 100% unclear to me exactly what we are publishing and where it's going

dave.enyeart (Wed, 17 May 2017 14:41:29 GMT):
@rameshthoomu Please clarify Gari's questions on 8939

mastersingh24 (Wed, 17 May 2017 14:41:48 GMT):
I know which tools, etc - but no idea what the link(s) look like, etc. I also wanted to have a separate tarball per platform and it was a bit unclear if that is the case

dave.enyeart (Wed, 17 May 2017 14:42:26 GMT):
ok understood Gari. Do you want to work through those questions with Ramesh here, in fabric-release, or in 8939?

mastersingh24 (Wed, 17 May 2017 14:42:54 GMT):
Doesn't matter to me ;)

mastersingh24 (Wed, 17 May 2017 14:43:04 GMT):
fabric-release might be more appropriate?

rameshthoomu (Wed, 17 May 2017 14:43:12 GMT):
@mastersingh24 in production will post tarball per platform here https://nexus.hyperledger.org/content/repositories/releases/

dave.enyeart (Wed, 17 May 2017 14:43:14 GMT):
agreed, let's switch over there

rameshthoomu (Wed, 17 May 2017 14:43:42 GMT):
but will post the final link once I trigger the job..

dave.enyeart (Wed, 17 May 2017 14:44:59 GMT):
i mentioned gari and ramesh on #fabric-release to continue over there...

greg.haskins (Wed, 17 May 2017 15:28:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=EKgenTJHtfeP7uT6G) @tkuhrt In the early days, we didnt have a makefile and thus third-party compilation phases were hard to integrate

greg.haskins (Wed, 17 May 2017 15:29:08 GMT):
we could conceivably move to a JIT model now that we do have a makefile, but theres always the added complexity of build dependencies, etc, that you need to worry about

greg.haskins (Wed, 17 May 2017 15:29:29 GMT):
i think with our $(DRUN) facilities, it could be managed, so we can think about doing this again

greg.haskins (Wed, 17 May 2017 15:32:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=iAaWYXDzAn79HAFvf) @tkuhrt The problem with go-get is that it will generally pull HEAD of the dependency, not a specific version. There is a third-party solution at gopkg.in that adds a partial solution to the problem, but its not 100% reliable or available. The official mechanism for controlling versions is the vendoring system, at least to my knowledge

greg.haskins (Wed, 17 May 2017 15:33:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=dKokMCQ4e8TphsuAK) @JonathanLevi I have absolutely no problem cutting "alpha2.1" is that is appropriate..

greg.haskins (Wed, 17 May 2017 15:34:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=7JXfFMpLGvsmdGjcW) @tkuhrt I just remembered a different issue

greg.haskins (Wed, 17 May 2017 15:34:48 GMT):
we have to check in golang specific generated files because of how golang works

cbf (Wed, 17 May 2017 20:27:52 GMT):
@here I plan on putting out some draft UT guidelines, but for starters, I offer http://artofunittesting.com/definition-of-a-unit-test/

cbf (Wed, 17 May 2017 20:28:37 GMT):
one of the things that frustrates me is the fact that many of our unit tests aren't. They are integration tests. They have a requirement of some external process running, or some special setup.

cbf (Wed, 17 May 2017 20:28:53 GMT):
a unit test needs to be self-contained

cbf (Wed, 17 May 2017 20:29:20 GMT):
for Golang, one should be able to run 'go test' in any folder and have it run the unit tests successfully

cbf (Wed, 17 May 2017 20:29:44 GMT):
I should be able to place a watch on a folder whle I am developing and have the tests run automagically every time I change a file

muralisr (Wed, 17 May 2017 20:29:49 GMT):
@cbf `They are integration tests.` - I cringe (the chaincode tests) :-) ...

cbf (Wed, 17 May 2017 20:30:09 GMT):
YOU! I'm looking at YOU @muralisr (j/k)

cbf (Wed, 17 May 2017 20:30:14 GMT):
;-)

muralisr (Wed, 17 May 2017 20:30:24 GMT):
but do take a peek at https://gerrit.hyperledger.org/r/#/c/9395/ the shim side of it

muralisr (Wed, 17 May 2017 20:30:26 GMT):
I know :-)

muralisr (Wed, 17 May 2017 20:30:33 GMT):
reason I mention that is this

muralisr (Wed, 17 May 2017 20:30:44 GMT):
the work there can directly influence the peer side also

muralisr (Wed, 17 May 2017 20:31:11 GMT):
so we could remove the executetransaction_test.go and replace with proper UT using the same approach

cbf (Wed, 17 May 2017 20:31:42 GMT):
one thing I am thinking of is having an environment variable that we can check to run some "unit tests" when we are running integration testing

cbf (Wed, 17 May 2017 20:31:50 GMT):
or maybe in CI generally

muralisr (Wed, 17 May 2017 20:31:52 GMT):
right

cbf (Wed, 17 May 2017 20:32:08 GMT):
we may also want to have tests run only as smoke tests

muralisr (Wed, 17 May 2017 20:32:27 GMT):
these "integ. tests" are valuable in their own right (IMO anyway) ...and will be good to run periodically somehow

cbf (Wed, 17 May 2017 20:32:38 GMT):
of course

cbf (Wed, 17 May 2017 20:32:46 GMT):
not saying these are not valuable

cbf (Wed, 17 May 2017 20:33:04 GMT):
completely agree there, but as unit tests they are less valuable

muralisr (Wed, 17 May 2017 20:33:05 GMT):
no, right..I didn't mean that you did

cbf (Wed, 17 May 2017 20:33:09 GMT):
they take too long, for starters

muralisr (Wed, 17 May 2017 20:33:15 GMT):
agreed

muralisr (Wed, 17 May 2017 20:33:27 GMT):
they have served their purpose, and time to fix

muralisr (Wed, 17 May 2017 20:33:33 GMT):
totally agree

muralisr (Wed, 17 May 2017 20:34:13 GMT):
I really think I might be able to replace them with UT using the same approach as https://gerrit.hyperledger.org/r/#/c/9395/ ...

muralisr (Wed, 17 May 2017 20:34:17 GMT):
just need to get to it

cbf (Wed, 17 May 2017 20:34:45 GMT):
going to place a hit on @muralisr for dropping 1k patches

cbf (Wed, 17 May 2017 20:34:49 GMT):
;-)

cbf (Wed, 17 May 2017 20:35:03 GMT):
but first, I'll get that @mastersingh24 guy

muralisr (Wed, 17 May 2017 20:35:27 GMT):
whoa ... core/chaincode/shim/shim_test.go is the big one

muralisr (Wed, 17 May 2017 20:35:30 GMT):
its all test

muralisr (Wed, 17 May 2017 20:35:51 GMT):
one of the beuty of that UT is how little the core has changed

muralisr (Wed, 17 May 2017 20:36:56 GMT):

Message Attachments

muralisr (Wed, 17 May 2017 20:37:05 GMT):
thats the only code change

cbf (Wed, 17 May 2017 20:37:18 GMT):
bless you @muralisr !

cbf (Wed, 17 May 2017 20:37:19 GMT):
coverage: 70.3% of statements ok github.com/hyperledger/fabric/core/chaincode/shim 3.061s

muralisr (Wed, 17 May 2017 20:37:26 GMT):
:-)

muralisr (Wed, 17 May 2017 20:37:44 GMT):
if I may say so, feel quite good about that work

cbf (Wed, 17 May 2017 20:37:51 GMT):
well done

weeds (Wed, 17 May 2017 20:40:55 GMT):
people are trying =-)...

greg.haskins (Thu, 18 May 2017 00:25:51 GMT):
on another positive note: I successfully got my "alpha2 challenge" client working today with full e2e with security/tls enabled

greg.haskins (Thu, 18 May 2017 00:26:30 GMT):
and on another positive note, it was the fastest txn convergence I have ever observed, even with 4 peers and security enabled

greg.haskins (Thu, 18 May 2017 00:26:55 GMT):
(faster than what I was used to on v0.6 and earlier prototypes of v1.0 before I was working with full clusters

greg.haskins (Thu, 18 May 2017 00:27:11 GMT):
ill push an update later

greg.haskins (Thu, 18 May 2017 00:27:30 GMT):
still waiting for anyone else to join me with a PR though, hint hint

greg.haskins (Thu, 18 May 2017 01:40:46 GMT):
so, what is the consensus for the process in which we decide to accept CRs right now @here

greg.haskins (Thu, 18 May 2017 01:40:56 GMT):
for instance: https://gerrit.hyperledger.org/r/#/c/8889/ @cbf

greg.haskins (Thu, 18 May 2017 01:41:21 GMT):
CR 8889 touches .go code, so unclear on how to proceed

kostas (Thu, 18 May 2017 11:53:02 GMT):
`Logger` interface definition aside (which seems a bit too drastic and was caught in review), as far as I can tell (1) no new functionality was added, and (2) the refactoring in the `*.go` files was driven by the need to cover the code better via unit tests. It's a good opportunity for me to double-check as well, but these kind of edits should not be discouraged.

kostas (Thu, 18 May 2017 11:53:02 GMT):
`Logger` interface definition aside (which seems a bit too drastic and was caught in review), as far as I can tell (1) no new functionality was added, and (2) the refactoring in a non-test file was driven by the need to cover the code better via unit tests. It's a good opportunity for me to double-check as well, but these kind of edits should not be discouraged. @greg.haskins @cbf

kostas (Thu, 18 May 2017 11:53:02 GMT):
`Logger` interface definition aside (which seems a bit too drastic and was caught in review), as far as I can tell (1) no new functionality was added, and (2) the refactoring in a non-test file was driven by the need to cover the code better via unit tests. It's a good opportunity for me to double-check as well, but and yes, it'd be ideal if we could avoid them, but these kind of edits should not be forbidden. @greg.haskins @cbf

kostas (Thu, 18 May 2017 11:53:02 GMT):
`Logger` interface definition aside (which seems a bit too drastic and was caught in review), as far as I can tell (1) no new functionality was added, and (2) the refactoring in a non-test file was driven by the need to cover the code better via unit tests. It's a good opportunity for me to double-check as well, and yes it'd be ideal if we could avoid them, but these kind of edits should not be forbidden. @greg.haskins @cbf

cbf (Thu, 18 May 2017 11:56:40 GMT):
that was my take

cbf (Thu, 18 May 2017 11:56:55 GMT):
we should ask others

muralisr (Thu, 18 May 2017 12:05:03 GMT):
@greg.haskins `still waiting for anyone else to join me with a PR though, hint hint` ... hint taken up ... plan for by monday :-)

cbf (Thu, 18 May 2017 20:12:30 GMT):
@JonathanLevi you ok with https://gerrit.hyperledger.org/r/#/c/9199/16? I asked about this earlier. There is new code, but as Yacov explained it was needed to fix the bug. https://jira.hyperledger.org/browse/FAB-3109 this is one of the issues that is affecting CI. Suggest it be merged.

JonathanLevi (Thu, 18 May 2017 20:14:19 GMT):
Yes, I honestly don't mind the 200 LOC of production code, considering the fix + the tests in adds. Risk-wise, it makes sense. Give me a mo.

JonathanLevi (Thu, 18 May 2017 20:18:04 GMT):
Merged. Risk-return, I meant ;-)

JonathanLevi (Thu, 18 May 2017 20:18:04 GMT):
Merged. Risk-return-wise, I meant ;-)

muralisr (Fri, 19 May 2017 15:11:57 GMT):
a quick question on UT for examples/

muralisr (Fri, 19 May 2017 15:12:01 GMT):

Message Attachments

muralisr (Fri, 19 May 2017 15:13:11 GMT):
do we need to count these against UT coverage ? I'd say not... but what does everyone think ?

yacovm (Fri, 19 May 2017 16:15:12 GMT):
I concur

JonathanLevi (Fri, 19 May 2017 17:03:24 GMT):
Likewise. I agree with you @muralisr.

elli-androulaki (Fri, 19 May 2017 17:40:39 GMT):
Hi, regarding this https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=Sj9XDkR2gedne98dk Crypto squad's test coverage is already above 85%. We have no pending CRs associated to increasing test coverage in crypto components. Crypto related packages UT coverage is listed below: ``` 15:10:21 unit-tests_1 | ? github.com/hyperledger/fabric/bccsp [no test files] 15:10:29 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/factory 0.044s coverage: 87.3% of statements 15:10:30 unit-tests_1 | ? github.com/hyperledger/fabric/bccsp/mocks [no test files] 15:12:42 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/pkcs11 127.159s coverage: 61.4% of statements 15:12:44 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/signer 0.069s coverage: 100.0% of statements 15:14:06 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/sw 77.711s coverage: 90.1% of statements 15:14:06 unit-tests_1 | ? github.com/hyperledger/fabric/bccsp/sw/mocks [no test files] 15:14:08 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/utils 0.133s coverage: 87.0% of statements ``` github.com/hyperledger/fabric/bccsp/pkcs11 package is related to HSM work. @vpaprots is working on refactoring it (related CR https://gerrit.hyperledger.org/r/#/c/9441/), but tests for the refactored code would need to be added by @vpaprots afterwards. So far, @yacovm pointed out we should work on increasing test coverage for github.com/hyperledger/fabric/bccsp (the code there is very simple but we can still work on covering it). Would you have any other comment for crypto UT coverage so far?

cbf (Fri, 19 May 2017 17:55:34 GMT):
crypto is probably the most crucial area to have bug free

cbf (Fri, 19 May 2017 17:55:46 GMT):
what is holding us back from going further?

cbf (Fri, 19 May 2017 17:55:54 GMT):
85 is not a goal, it is a guideline

cbf (Fri, 19 May 2017 17:56:11 GMT):
@mastersingh24 what say you?

yacovm (Fri, 19 May 2017 18:11:09 GMT):
They are above 85% ``` 08:59:02 unit-tests_1 | ok github.com/hyperledger/fabric/msp 0.143s coverage: 85.6% of statements 08:59:19 unit-tests_1 | ok github.com/hyperledger/fabric/msp/mgmt 0.059s coverage: 87.8% of statements 15:10:29 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/factory 0.044s coverage: 87.3% of statements 15:12:44 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/signer 0.069s coverage: 100.0% of statements 15:14:06 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/sw 77.711s coverage: 90.1% of statements ``` I think that there are parts of fabric that are just as important as crypto because they hold all the access control, i.e `github.com/hyperledger/fabric/core/endorser 75.808s coverage: 77.4% of statements` and `github.com/hyperledger/fabric/core/scc/vscc 0.107s coverage: 85.7% of statements`

yacovm (Fri, 19 May 2017 18:11:09 GMT):
They are above 85% except the `bccsp` package which has no tests, but it is only interfaces and accessor methods ``` 08:59:02 unit-tests_1 | ok github.com/hyperledger/fabric/msp 0.143s coverage: 85.6% of statements 08:59:19 unit-tests_1 | ok github.com/hyperledger/fabric/msp/mgmt 0.059s coverage: 87.8% of statements 15:10:29 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/factory 0.044s coverage: 87.3% of statements 15:12:44 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/signer 0.069s coverage: 100.0% of statements 15:14:06 unit-tests_1 | ok github.com/hyperledger/fabric/bccsp/sw 77.711s coverage: 90.1% of statements ``` I think that there are parts of fabric that are just as important as crypto because they hold all the access control, i.e `github.com/hyperledger/fabric/core/endorser 75.808s coverage: 77.4% of statements` and `github.com/hyperledger/fabric/core/scc/vscc 0.107s coverage: 85.7% of statements`

vpaprots (Fri, 19 May 2017 18:11:56 GMT):
I will be getting `github.com/hyperledger/fabric/bccsp/pkcs11` up (well, @harrijk will be doing bulk of that, trying to spread some HSM knowledge), but @adc @elli-androulaki can we get the rest from you please?

weeds (Fri, 19 May 2017 18:23:47 GMT):
@cbf @mastersingh24 Murali posted question up above indicating that we might not need to tackle examples for UT- seems like Yacov/Jonathan-- are you ok with this? Do we need to post a proposal on this or is it ok to just agree across maintainers?

JonathanLevi (Fri, 19 May 2017 18:29:31 GMT):
BTW: We can/should move the non-maintainers discussions regarding the release exist-criteria, release quality thresholds to the #fabric-release or so.

JonathanLevi (Fri, 19 May 2017 18:29:31 GMT):
BTW: We can/should move the non-maintainers discussions regarding the release exit-criteria, release quality thresholds to the #fabric-release or so... (especially as many do not write on this channel...)

JonathanLevi (Fri, 19 May 2017 18:29:31 GMT):
BTW: We can/should move the non-maintainers' discussions regarding the release exit-criteria, release quality thresholds to the #fabric-release or so... (especially as many do not write on this channel...)

cbf (Fri, 19 May 2017 18:37:25 GMT):
UT coverage that matters is production code - examples don't fall into that category - but that does not mean that they should NOT have UT - they should

cbf (Fri, 19 May 2017 18:37:46 GMT):
especially if they are supposed to be real examples for our users

muralisr (Fri, 19 May 2017 20:32:44 GMT):
@cbf just posted following on the fabric-peer-endorser-committer channel

muralisr (Fri, 19 May 2017 20:32:46 GMT):
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=4rJFNn8vKEAEjEJ4m

muralisr (Fri, 19 May 2017 20:33:31 GMT):
we could add examples to the sub-tasks there once the main ones get completed

rjones (Fri, 19 May 2017 20:41:13 GMT):
Has left the channel.

C0rWin (Fri, 19 May 2017 21:23:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=5oaevRcnRaBAxRDjL) @muralisr FAB-4058 (sub-task of 4046), looks like an overkill, there nothing testable in there. :)

muralisr (Fri, 19 May 2017 23:41:31 GMT):
ah indeed :-)

muralisr (Fri, 19 May 2017 23:41:52 GMT):
feel free to assign to yourself and close ;-)

lehors (Sat, 20 May 2017 16:40:52 GMT):
@here, this is bad, the getting started doesn't work

lehors (Sat, 20 May 2017 16:51:20 GMT):
@cbf @mastersingh24 see https://chat.hyperledger.org/channel/fabric?msg=HFugez8GyQ5S5xKTS

lehors (Sat, 20 May 2017 16:51:37 GMT):
somebody needs to fix this stuff by uploading the latest tar balls in the right places

nickgaski (Sat, 20 May 2017 17:50:01 GMT):
https://gerrit.hyperledger.org/r/#/c/9619/ - URGENT

lehors (Sat, 20 May 2017 18:11:38 GMT):
See #fabric-release

cbf (Sat, 20 May 2017 19:08:49 GMT):
this is likely because they are being uploaded to log storage and that rotates

cbf (Sat, 20 May 2017 19:09:03 GMT):
@rameshthoomu this needs to be fixed please

cbf (Sat, 20 May 2017 19:09:23 GMT):
@rjones @jwagantall

rjones (Sat, 20 May 2017 19:09:23 GMT):
Has joined the channel.

rameshthoomu (Sat, 20 May 2017 19:09:30 GMT):
Done

cbf (Sat, 20 May 2017 19:09:34 GMT):
ok

rameshthoomu (Sat, 20 May 2017 19:09:43 GMT):
I have pushed to release url

rameshthoomu (Sat, 20 May 2017 19:10:18 GMT):
Nick is updating bootstrap script once basic testing is done

cbf (Sat, 20 May 2017 19:10:35 GMT):
do we have something in place to keep the content fresh? do we know the timing of the log rotation?

cbf (Sat, 20 May 2017 19:10:43 GMT):
can we disable during Consensus?

rameshthoomu (Sat, 20 May 2017 19:13:08 GMT):
Now seems we are good because I have pushed to release URL. Will check with ry on log rotation.. we have to keep content in release URL forever or atleast few months

nickgaski (Sat, 20 May 2017 19:41:21 GMT):
it is pushed

rjones (Sat, 20 May 2017 22:35:35 GMT):
@cbf the log urls are ephemeral and were never supposed to be used like this for exactly this reason. Anything that points to https://logs.hyp... that _isn't jenkins_ will break

cbf (Sun, 21 May 2017 12:23:59 GMT):
@rjones yes, I know, but as I said to @jwagantall the whole 'use maven' thing was a) misguided and b) not working after multiple repeated attempts... there is no reason we cannot just use the object store for raw storage and move on

kostas (Sun, 21 May 2017 12:33:03 GMT):
Not sure who's managing JIRA (@cbf?), but let's move v1.00-alpha2 to the "Released versions" section.

kostas (Sun, 21 May 2017 12:33:50 GMT):

Message Attachments

mastersingh24 (Sun, 21 May 2017 14:21:50 GMT):
@kostas - done - https://jira.hyperledger.org/projects/FAB?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=released

greg.haskins (Sun, 21 May 2017 15:08:32 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=EY59tjKbDhovaKskG) @cbf As one of the people who suggested it, I take responsibility if there were problems with that method...but I am not sure where the problem was but I suspect it was the approach

greg.haskins (Sun, 21 May 2017 15:08:51 GMT):
To be clear, I was suggesting that we use the deploy-file plugin: http://maven.apache.org/plugins/maven-deploy-plugin/usage.html

greg.haskins (Sun, 21 May 2017 15:09:16 GMT):
I didnt get the impression that was the approach that was tried...but if it was and it wasnt practical...apologies for the rat hole

greg.haskins (Sun, 21 May 2017 15:30:27 GMT):
heres a basic example

greg.haskins (Sun, 21 May 2017 15:30:32 GMT):
```$ mvn install:install-file -Dfile=release.tar.gz -DgroupId=org.hyperledger -DartifactId=fabric -Dversion=1.0.0-alpha2 -Dpackaging=tgz [INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building Maven Stub Project (No POM) 1 [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-install-plugin:2.5.2:install-file (default-cli) @ standalone-pom --- [INFO] Installing /home/ghaskins/sandbox/git/chaintool/examples/example02/client/release.tar.gz to /home/ghaskins/.m2/repository/org/hyperledger/fabric/1.0.0-alpha2/fabric-1.0.0-alpha2.tgz [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.663 s [INFO] Finished at: 2017-05-21T11:29:51-04:00 [INFO] Final Memory: 6M/153M [INFO] ------------------------------------------------------------------------```

greg.haskins (Sun, 21 May 2017 15:31:05 GMT):
this took "release.tar.gz" and surfaced it as a maven coordinate under org/hyperledger/fabric/1.0.0-alpha2

greg.haskins (Sun, 21 May 2017 15:32:16 GMT):
(note that install-file and deploy-file are related...where the former only installs to the local ~/.m2 repo and deploy installs to nexus

greg.haskins (Sun, 21 May 2017 15:32:38 GMT):
in any case, it should result in the raw artifact being accessible in the repo

greg.haskins (Sun, 21 May 2017 15:32:59 GMT):
in this case: org/hyperledger/fabric/1.0.0-alpha2/fabric-1.0.0-alpha2.tgz

greg.haskins (Sun, 21 May 2017 15:35:30 GMT):
note that there is no need for a pom.xml in the project itself

greg.haskins (Sun, 21 May 2017 15:35:43 GMT):
this can be driven strictly as an adjunct CI script

cbf (Mon, 22 May 2017 11:13:34 GMT):
somehow, it morphed into something else, then. I think that it had to do with the fact that someone at LF was insisting that there be a staging deploy of the unsigned tarball so that it could be signed and published after the fact (manually, because there is no HSM to store the keys, apparently).

cbf (Mon, 22 May 2017 11:13:41 GMT):
@greg.haskins ^^

cbf (Mon, 22 May 2017 11:14:47 GMT):
I suggested last week that we take necessary steps to publish the file as you described, and we can work on some sort of intermediated signing step afterwards.

cbf (Mon, 22 May 2017 11:15:13 GMT):
Frankly, I don't see how manually signing assures anyone that the bits have not been tampered;-)

greg.haskins (Mon, 22 May 2017 12:17:04 GMT):
right, it really doesn't afaict

greg.haskins (Mon, 22 May 2017 12:17:29 GMT):
in my mind, the only thing you really need to do is have the build pipeline sign in

greg.haskins (Mon, 22 May 2017 12:17:29 GMT):
in my mind, the only thing you really need to do is have the build pipeline sign them

greg.haskins (Mon, 22 May 2017 12:18:13 GMT):
e.g. if the artifacts were signed by jenkins@hyperledger.org, or whatever, that achieves the maximum purpose

greg.haskins (Mon, 22 May 2017 12:18:58 GMT):
(and that can wait post alpha2 ;)

greg.haskins (Mon, 22 May 2017 12:19:26 GMT):
at this stage, a stable URL is far more important

greg.haskins (Mon, 22 May 2017 12:22:48 GMT):
@cbf I think this is similar to deploy:deploy-file except includes GPG signatures: http://maven.apache.org/plugins/maven-gpg-plugin/sign-and-deploy-file-mojo.html

cbf (Mon, 22 May 2017 12:23:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=aD6fE5SdjsAAocStN) @greg.haskins exactly

greg.haskins (Mon, 22 May 2017 12:26:43 GMT):
@cbf I digress...apologies if the "misguided" comment was directed at me. I only aim to help but am not infallible

greg.haskins (Mon, 22 May 2017 12:30:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=7DnWx94b4YPwRwHxW) @rameshthoomu @rjones @jwagantall was this approach tried but failed?

rameshthoomu (Mon, 22 May 2017 13:23:17 GMT):
@greg.haskins we have used deploy:deploy-file plug in to push to nexus..

lehors (Mon, 22 May 2017 13:44:23 GMT):
@here, from now on I suggest we do not announce new releases on Friday unless people are around that weekend and committed to keep an eye on RC for cries for help from the community

dolanor (Mon, 22 May 2017 15:17:26 GMT):
Has joined the channel.

greg.haskins (Mon, 22 May 2017 15:34:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=P66F2Hkfifxhwv6Pq) @rameshthoomu I guess I do not understand how one could use deploy-file and end up with an unversioned artifact in an ephemeral respository

greg.haskins (Mon, 22 May 2017 15:34:46 GMT):
in my experience, that always pushed a stable coordinate to a stable repo

greg.haskins (Mon, 22 May 2017 15:35:05 GMT):
there must be some use of it that I am not aware of

rameshthoomu (Mon, 22 May 2017 15:41:50 GMT):
published 1.0.0-alpha2 as a version to these binaries? also, we have a script which does this task https://gerrit.hyperledger.org/r/#/c/8939/38/jjb/fabric/include-raw-fabric-push-fabric-binaries.sh

greg.haskins (Mon, 22 May 2017 15:43:02 GMT):
hmm, looks fine..so what was the problem

rameshthoomu (Mon, 22 May 2017 15:43:24 GMT):
I don't see any problem now..

greg.haskins (Mon, 22 May 2017 15:44:32 GMT):
im confused

cbf (Mon, 22 May 2017 15:46:05 GMT):
lol

greg.haskins (Mon, 22 May 2017 15:46:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=EY59tjKbDhovaKskG) @rameshthoomu I was responding to this

greg.haskins (Mon, 22 May 2017 15:46:53 GMT):
it sounded like that was not working and was believed to be untenable

greg.haskins (Mon, 22 May 2017 15:47:17 GMT):
is that the case, or is it working now/

greg.haskins (Mon, 22 May 2017 15:47:18 GMT):
?

jwagantall (Mon, 22 May 2017 15:52:05 GMT):
@greg.haskins sorry if i am just catching up to your questions... the reason why we were having issues is becuase fabric is not fully a maven repo and hence it doesnt have all artifacts recognized as maven targets... we tried to get help from the devs but it is not an easy task and probably not suitable for fabric... so we decided to use the plugin that just does a simple push of the tarball that contains the built artifacts

greg.haskins (Mon, 22 May 2017 15:53:00 GMT):
@jwagantall understood, and no apologies necessary..im just trying to understand what problem there is

greg.haskins (Mon, 22 May 2017 15:53:42 GMT):
to be clear: I fully support (and even suggested) that this should be a "deploy-file" scenario...as you pointed out, fabric is not a maven-managed project (nor do I think it should become one

rameshthoomu (Mon, 22 May 2017 15:55:00 GMT):
Initially we have used `mvn deploy` plugin to publish artificats from CI to nexus and we are able to publish to logs/snapshots/releases URL's later @jwagantall suggested we should not use this plugin and use `mvn staging deploy` plugin to push artifacts and we consistently failed to do that due some environment settings in sandbox.

greg.haskins (Mon, 22 May 2017 15:55:04 GMT):
if we have the scenario where something like "cryptogen" wants to be surfaced to users to download, using nexus to surface it should be a natural way to do it with good release engineering practices, like versioned URLs

rameshthoomu (Mon, 22 May 2017 15:55:43 GMT):
We finally come up with using `mvn deploy:deploy-file` plugin (without pom.xml) and successfully published artifacts to nexus..

greg.haskins (Mon, 22 May 2017 15:56:32 GMT):
I am not familiar with the staging plugin, but of everthing I do understand, this is a deploy-file use case

greg.haskins (Mon, 22 May 2017 15:56:55 GMT):
and it should be a straightforward one at that

jwagantall (Mon, 22 May 2017 15:58:03 GMT):
right @greg.haskins, the staging benefit of using maven2 is just suitable for fully maven repos which is not our case. That's what I was able to fully learn last week, so we should be good with the current approach we followed..

greg.haskins (Mon, 22 May 2017 15:58:19 GMT):
ok

cbf (Mon, 22 May 2017 16:09:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=JtizsZbqnoWoWTjpp) @greg.haskins +2

cbf (Mon, 22 May 2017 16:57:54 GMT):
@here https://gerrit.hyperledger.org/r/#/c/7741/14 needs agreement by maintainers to be merged... it LGTM but I would like 2-3 other maintainers to concur given the amount of code changed

cbf (Mon, 22 May 2017 20:10:17 GMT):
I've created a query that can be used to find the FABs that need to be agreed upon by maintainers

cbf (Mon, 22 May 2017 20:10:19 GMT):
https://jira.hyperledger.org/issues/?filter=10616

rickr (Mon, 22 May 2017 22:35:51 GMT):
@rjones very low priority but `WIP_fabric_v1` `fabric_v1` branches of JSDK are dead and never went anywhere. Just to keep things clean can we delete them in GIT repo? I've deleted them from gerrit but that I guess doesn't sync.

cbf (Tue, 23 May 2017 14:38:28 GMT):
@here just spoke to the legal folk at LF... they are encouraging projects to use the SPDX short identifier form of license header as it is easier to automate etc

cbf (Tue, 23 May 2017 14:38:34 GMT):
details here https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf

cbf (Tue, 23 May 2017 14:39:23 GMT):
I've reverted my changesets accordingly https://gerrit.hyperledger.org/r/#/c/9673/

cbf (Tue, 23 May 2017 14:39:30 GMT):
and updated the guidance

cbf (Tue, 23 May 2017 14:40:22 GMT):
please check license headers for this new form... I will address all files without a header, but we should start asking devs to make the change to the short form when they change source

yacovm (Tue, 23 May 2017 14:40:56 GMT):
Won't it cause conflicts though?

yacovm (Tue, 23 May 2017 14:41:12 GMT):
if 2 people change the same file and both update the license header

binhn (Tue, 23 May 2017 15:03:13 GMT):
@yacovm better to do that as we go to reduce merge conflicts

greg.haskins (Tue, 23 May 2017 15:36:20 GMT):
@yacovm @cbf @binhn I would think this type of change is highly conducive to automated find+replace...it might make sense to just tackle as many of them this way as possible to reduce merge conflicts and general codebase inconsistency

greg.haskins (Tue, 23 May 2017 15:36:40 GMT):
e.g. the .go files all probably have the same pattern

yacovm (Tue, 23 May 2017 15:36:52 GMT):
You mean - we should have a change set that only changes the license right?

greg.haskins (Tue, 23 May 2017 15:37:00 GMT):
@yacovm exactly

yacovm (Tue, 23 May 2017 15:37:07 GMT):
This is where I was getting at :)

greg.haskins (Tue, 23 May 2017 15:37:23 GMT):
at least in groups (e.g. all .go files, all .sh files, etc)

yacovm (Tue, 23 May 2017 15:37:29 GMT):
yeah

greg.haskins (Tue, 23 May 2017 15:37:32 GMT):
if someone doesnt tackle all patterns

binhn (Tue, 23 May 2017 15:38:38 GMT):
problem is with the merge conflicts of this massive cr

binhn (Tue, 23 May 2017 15:38:52 GMT):
we would need to coordinate

yacovm (Tue, 23 May 2017 15:38:59 GMT):
well if we do it as Greg said we won't have because it's going to be different lines

binhn (Tue, 23 May 2017 15:39:11 GMT):
and stop merging until this big one is in

yacovm (Tue, 23 May 2017 15:39:14 GMT):
the contention is line-based, rather than file based

binhn (Tue, 23 May 2017 15:40:40 GMT):
git doesn't work that well in my experience -- maybe we'd be lucky with this one

yacovm (Tue, 23 May 2017 15:40:44 GMT):
I'd say the problem is something else

yacovm (Tue, 23 May 2017 15:40:52 GMT):
you can't cover added files in pending CRs ;)

kostas (Tue, 23 May 2017 15:56:08 GMT):
Why isn't such a change the very last thing we tackle before we cut 1.0.0?

binhn (Tue, 23 May 2017 15:57:03 GMT):
@kostas yeah, my thought too

cbf (Tue, 23 May 2017 16:12:06 GMT):
@greg.haskins sure, it could be... but whenever you have these large changes, there can be hell to pay in terms of merge conflicts with existing CRs

cbf (Tue, 23 May 2017 16:12:26 GMT):
what I have already submitted is bad enough (though these did not have anything to replace)

cbf (Tue, 23 May 2017 16:13:09 GMT):
@yacovm even if last thing, still leaves any in-progress CRs needing to be rebased

cbf (Tue, 23 May 2017 16:13:17 GMT):
it is not urgent

cbf (Tue, 23 May 2017 16:13:32 GMT):
getting files with NO LICENSE HEADER is important

cbf (Tue, 23 May 2017 16:13:41 GMT):
but changing to SPDX could be a gradual change

greg.haskins (Tue, 23 May 2017 16:15:58 GMT):
@cbf fair point...though I suspect that the nature of the change would have smaller likelihood of git-conflicts than typical

greg.haskins (Tue, 23 May 2017 16:16:50 GMT):
e.g. only CRs which happened to change either the license comment or the first few lines of the file would conflict, and I doubt there would be many of those

greg.haskins (Tue, 23 May 2017 16:18:24 GMT):
IOW, git is pretty good at sorting this out as long as you are > +- 3 lines away from a competing change

greg.haskins (Tue, 23 May 2017 16:19:00 GMT):
in the end, agree its not high priority

cbf (Tue, 23 May 2017 19:46:35 GMT):
@here https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104#Filter-Results/10517 I added a gadget to the dashboard that lists the issues we need to agree on

cbf (Tue, 23 May 2017 19:47:02 GMT):
we had intended to "meet" daily... that isn't working out since Consensus but we should not let these fester long

cbf (Tue, 23 May 2017 19:47:24 GMT):
suggest we just vote for issues we are OKAY with (and their CR)

muralisr (Tue, 23 May 2017 19:56:59 GMT):
@cbf would like to add https://jira.hyperledger.org/browse/FAB-3618 to that list please

lehors (Tue, 23 May 2017 19:57:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=hXXTiRvykZxirNqRu) @cbf I didn't know about these standard identifiers but that's a very nice development.

yacovm (Tue, 23 May 2017 20:03:54 GMT):
I guess @vpaprots would like to add https://jira.hyperledger.org/browse/FAB-3968 to the list @cbf

cbf (Tue, 23 May 2017 20:09:32 GMT):
@yacovm just add 'review-needed' label to the issue

yacovm (Tue, 23 May 2017 20:09:42 GMT):
I tried

cbf (Tue, 23 May 2017 20:09:55 GMT):
you cannot edit?

yacovm (Tue, 23 May 2017 20:10:30 GMT):
ah nvm forget it

yacovm (Tue, 23 May 2017 20:10:53 GMT):
I thought it was a tag, not a label

baohua (Wed, 24 May 2017 14:11:19 GMT):
Has left the channel.

cbf (Thu, 25 May 2017 13:33:49 GMT):
as a gentle reminder to maintainers and anyone else creating defects in JIRA, please complete the affectedVersion and assign fixVersion to either 1.0.0 or Future if it can be deferred

cbf (Thu, 25 May 2017 13:33:55 GMT):
@here ^^

lehors (Thu, 25 May 2017 13:34:39 GMT):
ah, what is 1.1 for?

cbf (Thu, 25 May 2017 13:59:56 GMT):
or that

yacovm (Thu, 25 May 2017 14:23:04 GMT):
https://gerrit.hyperledger.org/r/#/c/9441/ has 4 votes so far. Should we start reviewing it?

jyellick (Thu, 25 May 2017 14:30:50 GMT):
@cbf For the configtx tool stuff I've been working on (FAB-1678) I'm finally ready to start exposing the function via a REST api. It seems that https://github.com/gorilla/mux is a popular option for REST support. 1. It is BSD3 licensed, is this okay? 2. Assuming 1678 is approved to go into v1, is adding a new vendored package going to cause problems?

binhn (Thu, 25 May 2017 14:58:46 GMT):
I want to have a group review on this large CR containing integration tests https://gerrit.hyperledger.org/r/#/c/9261/ [FAB-3559] Performance Traffic Engine. The author will walk through major modules and playback, then I want to make decision on merge it or not. I am thinking 10am EST Wed. 5/31. I need at least @jimthematrix @muralisr @kostas @smithbk @C0rWin to cover all key components of fabric. Let me know if the date time works for you. All are welcome of course.

cbf (Thu, 25 May 2017 15:30:21 GMT):
BSD shouldn't cause an issue

cbf (Thu, 25 May 2017 15:30:31 GMT):
@jyellick ^^

cbf (Thu, 25 May 2017 15:32:35 GMT):
@binhn let's not hold this up another week. Suggest it just be merged so that the team can begin the process of getting it into CI.

cbf (Thu, 25 May 2017 15:32:48 GMT):
we can always make changes

binhn (Thu, 25 May 2017 15:34:31 GMT):
good idea -- we can do that, and still hold the review next week so that folks comment

cbf (Thu, 25 May 2017 15:54:51 GMT):
+1

binhn (Thu, 25 May 2017 16:16:35 GMT):
@cbf could you merge please https://gerrit.hyperledger.org/r/#/c/9261/

jimthematrix (Thu, 25 May 2017 16:24:55 GMT):
just merged, (FYI @rameshthoomu @dongming )

dongming (Thu, 25 May 2017 16:24:55 GMT):
Has joined the channel.

dongming (Thu, 25 May 2017 19:09:39 GMT):
thx

yacovm (Thu, 25 May 2017 20:12:12 GMT):
@here So, I am wondering- is this a good idea that we can shutdown a peer remotely without access control checks via `peer node stop`? Shouldn't we prevent this?

yacovm (Thu, 25 May 2017 20:12:12 GMT):
@here So, I am wondering- is this a good idea that we can shutdown a peer remotely without access control checks via `peer node stop`? (because we can) Shouldn't we prevent this?

rbuysse (Thu, 25 May 2017 20:12:27 GMT):
Has left the channel.

yacovm (Thu, 25 May 2017 20:15:13 GMT):
https://github.com/hyperledger/fabric/blob/master/core/admin.go#L57-L66

C0rWin (Thu, 25 May 2017 21:33:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=bz2NatGbQZLk8aE44) @yacovm wondering why somebody would like to shutdown peer remotely.

C0rWin (Thu, 25 May 2017 21:33:48 GMT):
I think it should be disabled

yacovm (Thu, 25 May 2017 21:33:53 GMT):
I think that it can be very useful for adversaries though, no?

C0rWin (Thu, 25 May 2017 21:34:07 GMT):
if someone would like to take peer down, has to login and kill it

yacovm (Thu, 25 May 2017 21:35:12 GMT):
I think that the best thing is to subscribe to an OS signal such as SIGTERM and them gracefully shutdown

C0rWin (Thu, 25 May 2017 21:36:26 GMT):
yes, but at any case, I would vote to remove/disable the ability of stopping the peer via gRPC w/o any ACL

yacovm (Thu, 25 May 2017 21:38:27 GMT):
Yeah we probably need to deprecate that *v0.5* "feature"

yacovm (Thu, 25 May 2017 22:14:56 GMT):
@binhn @cbf @mastersingh24 :top:

cbf (Thu, 25 May 2017 22:18:30 GMT):
if someone gets access to docker - it's all over

cbf (Thu, 25 May 2017 22:18:51 GMT):
do we use this for operational management?

yacovm (Thu, 25 May 2017 22:22:39 GMT):
well currently you don't need access to docker to stop the peer

yacovm (Thu, 25 May 2017 22:22:48 GMT):
you can shut it down from another continent

yacovm (Thu, 25 May 2017 22:22:53 GMT):
via a gRPC call

C0rWin (Thu, 25 May 2017 22:24:32 GMT):
all you need is a peer IP

yacovm (Thu, 25 May 2017 22:25:29 GMT):
Exactly. and the admin server thing isn't even running on a different ports... it runs on 7051 as the rest of the peer API (events is 7053 by default)

yacovm (Thu, 25 May 2017 22:25:29 GMT):
Exactly. and the admin service isn't even running on a different ports... it runs on 7051 as the rest of the peer API (events is 7053 by default)

C0rWin (Thu, 25 May 2017 22:27:57 GMT):
One could sunset entire peer cluster with this

C0rWin (Thu, 25 May 2017 22:28:21 GMT):
going to open JIRA and suggest CR to deprecate it

cbf (Fri, 26 May 2017 00:34:39 GMT):
another gentle reminder that we agreed to review the set of review-needed items, daily https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104#Filter-Results/10517

cbf (Fri, 26 May 2017 00:34:46 GMT):
@here ^^

mastersingh24 (Fri, 26 May 2017 09:06:14 GMT):
@cbf - are people supposed to be using the "vote for this issue" (as well as any comments) to indicate approval?

cbf (Fri, 26 May 2017 11:13:21 GMT):
yep

cbf (Fri, 26 May 2017 11:14:01 GMT):
I've been voting or leaving a negative comment

mastersingh24 (Fri, 26 May 2017 11:20:40 GMT):
cool - that's what I did

bmalavan (Sat, 27 May 2017 15:46:29 GMT):
Has joined the channel.

mastersingh24 (Sat, 27 May 2017 20:42:46 GMT):
posting here as well as this needs some careful review: https://gerrit.hyperledger.org/r/#/c/9861/

yacovm (Sat, 27 May 2017 20:59:16 GMT):
Is there a max recv/send msg size for the client too?

mastersingh24 (Sun, 28 May 2017 18:14:50 GMT):
https://gerrit.hyperledger.org/r/#/c/9861/ (upgrade grpc-go ) should be ready for hopefully a final review

cbf (Mon, 29 May 2017 00:06:58 GMT):
@here as I'm looking at the Makefile - is there a reason we build the kafka, zookeeper and couchdb images as a function of Fabric? Could they not be built as a function of fabric-baseimage? Seems to me that they will change relatively infrequently - or, maybe just pull them out as independent builds and leverage tagged images for fabric etc

cbf (Mon, 29 May 2017 00:07:02 GMT):
thoughts?

muralisr (Mon, 29 May 2017 00:11:56 GMT):
can maintainers take a look at https://jira.hyperledger.org/browse/FAB-3948 please (pretty!!!). need this resolved so I can proceed with similar work on the chaincode side

muralisr (Mon, 29 May 2017 00:12:17 GMT):
the corresponding CR https://gerrit.hyperledger.org/r/#/c/9645/

muralisr (Mon, 29 May 2017 00:13:18 GMT):
it expands upon previously merged shim side UT by adding KEEPALIVE messages for more coverage and reorgs errors

muralisr (Mon, 29 May 2017 00:13:18 GMT):
it expands upon previously merged shim side UT by adding KEEPALIVE messages in the mock for more coverage and reorgs errors

muralisr (Mon, 29 May 2017 00:13:39 GMT):
should be fairly straightforward

greg.haskins (Mon, 29 May 2017 01:24:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=AxPGGgkX2MBm6MEfA) @cbf I have the exact same thought...wondering if we should perhaps have a fabric-thirdparty.git that can capture those plus openldap from fabric-ca

greg.haskins (Mon, 29 May 2017 01:25:17 GMT):
also suggest we adopt a versioning scheme for them that looks something like $UPSTREAM-$OURS

greg.haskins (Mon, 29 May 2017 01:26:22 GMT):
e.g. for zookeeper v3.4.9, we could have something like hyperledger/zookeeper:x86_64-3.4.9-1

greg.haskins (Mon, 29 May 2017 01:27:56 GMT):
and bump to -2, -3, as appropriate

greg.haskins (Mon, 29 May 2017 01:29:17 GMT):
(alternative to fabric-thirdparty is reuse something like fabric-baseimage...but I suggest a different repo because we currently have 1:1 with baseimage releases

greg.haskins (Mon, 29 May 2017 01:29:38 GMT):
I am thinking fabric-thirdparty wont really update on the same schedule

cbf (Mon, 29 May 2017 12:32:19 GMT):
@here interesting, Windows downloads outnumber mac https://goo.gl/#analytics/goo.gl/NIKLiU/all_time

lehors (Mon, 29 May 2017 12:32:39 GMT):
ah!

lehors (Mon, 29 May 2017 12:33:01 GMT):
who said we shouldn't ignore Windows users? ;-)

cbf (Mon, 29 May 2017 17:38:22 GMT):
@here https://jira.hyperledger.org/browse/FAB-4166 has met the threshold and has been approved for inclusion in 1.0 @C0rWin

C0rWin (Mon, 29 May 2017 17:41:27 GMT):
@cbf thanks, Chris. I have addressed @muralisr comment as well and disabled start function as no one actually uses it. I can revert this and keep disabling stop only.

C0rWin (Mon, 29 May 2017 17:42:11 GMT):
(Addressing your comment in JIRA)

cbf (Mon, 29 May 2017 17:46:10 GMT):
@C0rWin my concern/comment applied to a suggestion that the whole admin function be refactored/removed. I think we're trying to make as little change as possible given where we are. Every one agreed that it was a security issue to have remote stop.

C0rWin (Mon, 29 May 2017 17:47:06 GMT):
Well, removing start make sense for me since no one actually used it

C0rWin (Mon, 29 May 2017 17:47:34 GMT):
So if you think I need to take care of stop only

C0rWin (Mon, 29 May 2017 17:47:46 GMT):
I will revert back to it

cbf (Mon, 29 May 2017 17:48:14 GMT):
how do you know no one uses it?

C0rWin (Mon, 29 May 2017 17:48:42 GMT):
Well, how can you start peer via grpc?

C0rWin (Mon, 29 May 2017 17:49:47 GMT):
To start peer via grpc you have to have peer up and running, also used static analysis to find that only place making use of it is admin test

cbf (Mon, 29 May 2017 17:57:04 GMT):
@yacovm https://jira.hyperledger.org/browse/FAB-4085 has also met the criteria to be merged

cbf (Mon, 29 May 2017 17:58:19 GMT):
also this one https://jira.hyperledger.org/browse/FAB-4078

cbf (Mon, 29 May 2017 18:03:38 GMT):
@C0rWin https://jira.hyperledger.org/browse/FAB-4003 seems borderline in terms of the criteria for adding the item to the review-needed list.

cbf (Mon, 29 May 2017 18:05:08 GMT):
https://jira.hyperledger.org/browse/FAB-4002 needs one more vote - there have been no negative comments thus far

cbf (Mon, 29 May 2017 18:05:58 GMT):
https://jira.hyperledger.org/browse/FAB-3993 needs 2 more votes and has no negative comments

yacovm (Mon, 29 May 2017 18:07:15 GMT):
@cbf who uses the sample client in the latter FAB?

cbf (Mon, 29 May 2017 18:08:11 GMT):
the guy who submitted the patch;-)

yacovm (Mon, 29 May 2017 18:08:59 GMT):
so we have a merged toy client that only 1 person uses?

yacovm (Mon, 29 May 2017 18:08:59 GMT):
so we have a merged toy client that only 1 person uses? :rolling_eyes:

cbf (Mon, 29 May 2017 18:12:42 GMT):
https://jira.hyperledger.org/browse/FAB-3709 has also been approved for merging in 1.0

kostas (Mon, 29 May 2017 20:35:52 GMT):
RE: FAB-3993 -- The sample clients have been pretty useful when it comes to quick orderer testing. I also know that Barry's team was looking into writing something like this, which is why I encouraged Ben to submit it when he told me about it. This is a low priority changeset, outside of the hot path.

mastersingh24 (Mon, 29 May 2017 22:21:03 GMT):
RE: https://jira.hyperledger.org/browse/FAB-4002 - https://gerrit.hyperledger.org/r/#/c/9861/ is ready and waiting ;)

cbf (Mon, 29 May 2017 23:13:48 GMT):
@here ideally we need 1 more vote for 4002 above

muralisr (Mon, 29 May 2017 23:17:23 GMT):
@cbf I was pulling early versions of 9861 and testing

muralisr (Mon, 29 May 2017 23:17:49 GMT):
let me do that once more with latest and check it out ?

cbf (Mon, 29 May 2017 23:17:55 GMT):
kk thx

elli-androulaki (Tue, 30 May 2017 05:58:06 GMT):
Hi, may i kindly ask that you place your vote for this one ? https://jira.hyperledger.org/browse/FAB-3742

elli-androulaki (Tue, 30 May 2017 06:31:59 GMT):
And also for this one?

elli-androulaki (Tue, 30 May 2017 06:31:59 GMT):
And also for this one? https://jira.hyperledger.org/browse/FAB-3888

elli-androulaki (Tue, 30 May 2017 06:31:59 GMT):
And also for this one? https://jira.hyperledger.org/browse/FAB-3888 Thanks!

elli-androulaki (Tue, 30 May 2017 06:31:59 GMT):
And also for this one? https://jira.hyperledger.org/browse/FAB-3888 (It blocks https://gerrit.hyperledger.org/r/#/c/9275/ from getting merged). Thanks!

yacovm (Tue, 30 May 2017 07:24:56 GMT):
@elli-androulaki , I think it was decided to vote whether incorporation of error handling is for V1.0 or not, in [1]. I don't think we ever did... @cbf ? Should we vote on this to avoid confusion? [1] https://chat.hyperledger.org/channel/fabric?msg=jHEBo8S5xBaJSkxp6

elli-androulaki (Tue, 30 May 2017 07:38:13 GMT):
@yacovm thanks for pointing that out. So this one should also be voted for/against: https://gerrit.hyperledger.org/r/#/c/9279 (titled [FAB-3540] Error Handling in bccsp/signer)

yacovm (Tue, 30 May 2017 07:38:59 GMT):
well @JonathanLevi said "Removed my veto (-2) on that CR. Sure, we can re-consider it as part of daily review tomorrow. Thanks."

yacovm (Tue, 30 May 2017 07:39:09 GMT):
Whenever that happens I guess we would

bmkor (Tue, 30 May 2017 10:57:45 GMT):
Has left the channel.

mastersingh24 (Tue, 30 May 2017 12:33:14 GMT):
Folks - I added https://jira.hyperledger.org/browse/FAB-2493 to the review list this weekend. Please have a look. IMNSHO we need to do this one

muralisr (Tue, 30 May 2017 12:50:59 GMT):
@mastersingh24 voted +1 above given the usability impact

cbf (Tue, 30 May 2017 14:57:59 GMT):
@here https://jira.hyperledger.org/browse/FAB-4212 this is still WIP but began documenting what needs to be done for v1.0.0-beta - please feel free to suggest in comments what other tasks or blockers you feel need to be added

dave.enyeart (Tue, 30 May 2017 15:03:26 GMT):
thanks @cbf, it will surely be easier to track beta using a dedicated jira work item. there are other release tasks that I proposed in https://docs.google.com/document/d/1mPTMjXG_b-mgZd2_EUN9W-82ez0PrWoxIiPgcAAABwE/edit. Do you want to capture some of those in jira, or want me to add them? @mastersingh24 is also reviewing that list and is adding his perspective.

cbf (Tue, 30 May 2017 15:09:32 GMT):
let's add thoughts in comments for now

jimthematrix (Tue, 30 May 2017 19:34:05 GMT):
guys I need to bring up a debate that I and another maintainer are having regarding what kind of changes are allowed in the SDKs, so the other maintainers can weigh in. I have always operated under the assumption that the SDKs, being on the tail end of the chain of reactions with the rapid changes in the fabric and fabric-ca, should be allowed a "grace period" after the backend APIs are frozen, to do necessary house-cleaning mainly to review API designs, making adjustments so they would "totally makes sense". We have not been able to do that previously given the crazy daily churns where every day the SDKs got broken in some new ways. as a result we have some rather embarrassing API inconsistencies that reflects badly on the fabric as a whole. see https://jira.hyperledger.org/browse/FAB-2991 and https://jira.hyperledger.org/browse/FAB-4131 for examples.

jimthematrix (Tue, 30 May 2017 19:34:56 GMT):
I'd like to propose that API changes in the SDKs should still be allowed until beta

jimthematrix (Tue, 30 May 2017 19:38:05 GMT):
note that the kind of changes I'm looking for are not net new capabilities, even for FAB-4131 which may look large and complicated, it's mainly refactoring some tried-and-true code snippets and re-arrange them to make the API easier to follow and reason about

jimthematrix (Tue, 30 May 2017 19:39:15 GMT):
if you agree with my proposal, please add a :thumbsup: above

jimthematrix (Tue, 30 May 2017 19:41:40 GMT):
@C0rWin @binhn @cbf @dave.enyeart @mastersingh24 @greg.haskins @jyellick @JonathanLevi @smithbk @kostas @muralisr @yacovm ^^^

greg.haskins (Tue, 30 May 2017 19:47:01 GMT):
I think that there is some motivation to "get it right" at this point, because we will (or at least, should) be stuck with it for the support window of 1.0 once that is cut. That said, I can say first hand as someone who's apps were continuously broken because of this kind of activity that it should not be taken lightly

greg.haskins (Tue, 30 May 2017 19:47:27 GMT):
so my question really is: how is this any different than any other issue that should be decided on whether to allow?

greg.haskins (Tue, 30 May 2017 19:48:11 GMT):
and one aside: because of the pain-points to users, it should be clearly communicated (minimally in the release notes, probably each time it happens to the ML, etc)

greg.haskins (Tue, 30 May 2017 19:49:27 GMT):
so, i would say, if there is a proposal for an improvement, it should be documented in a standard way (describe the impact to accept and not accept) and voted on, just like any other issue that comes up

jimthematrix (Tue, 30 May 2017 19:51:36 GMT):
_*how is this any different than any other issue that should be decided on whether to allow*_ - agree that's the only question that matters at this point, I'd say the SDKs are "leaf nodes" and don't impact other components, and also the changes are not net new capabilities (untested code) but either re-arranging existing code or eliminating APIs that don't make sense any longer (e.g Chain.primaryPeer())

greg.haskins (Tue, 30 May 2017 19:52:09 GMT):
well, i would be careful with that thinking though

greg.haskins (Tue, 30 May 2017 19:52:38 GMT):
if I have an app that looks like clientapp -> sdk -> [peer, orderer, ca], its not really "leaf"

greg.haskins (Tue, 30 May 2017 19:52:53 GMT):
its an integral part of the stack, and breaking its ABI hurts me just as much as any other component

greg.haskins (Tue, 30 May 2017 19:53:27 GMT):
but that said, I dont see a proposal to change here as any different from any other proposal

jimthematrix (Tue, 30 May 2017 19:53:32 GMT):
understood and agree, but up till now "breaking its ABI hurts me" has been the norm right?

greg.haskins (Tue, 30 May 2017 19:53:35 GMT):
it should be understoood and decided on

jimthematrix (Tue, 30 May 2017 19:54:12 GMT):
this is the last chance for the SDKs to put a stop to it (as the backend APIs has finalize settled down)

jimthematrix (Tue, 30 May 2017 19:54:12 GMT):
this is the last chance for the SDKs to put a stop to it (as the backend APIs has finally settled down)

greg.haskins (Tue, 30 May 2017 19:54:20 GMT):
i agree with that

greg.haskins (Tue, 30 May 2017 19:54:40 GMT):
if its going to change, this is the time to change it

greg.haskins (Tue, 30 May 2017 19:55:04 GMT):
after 1.0, the barrier should be infinitely higher

greg.haskins (Tue, 30 May 2017 19:56:11 GMT):
to be clear, i am not saying we should introduce breaking changes willy nilly either...im just saying, they should be proposed and decided on, not blindly accepted or blindly rejected

greg.haskins (Tue, 30 May 2017 19:57:19 GMT):
if there is something that clearly improves the UX at the expense of alpha2 compat, lets talk about it

jimthematrix (Tue, 30 May 2017 20:02:28 GMT):
https://jira.hyperledger.org/browse/FAB-2991 and https://jira.hyperledger.org/browse/FAB-4131 are the outstanding ones at the moment

dave.enyeart (Tue, 30 May 2017 20:37:44 GMT):
One of the most important objectives of a 1.0 release is to get the client APIs 'right', meaning they are consistent, make sense for developers for years to come, and set a good precedent for future APIs. And one of the most important objectives of an alpha release is to gather community feedback to help get it right. Therefore, where alpha experience has shown us that some APIs are 'wrong', I agree that the right time to change them would be before a 1.0 beta release.

dave.enyeart (Tue, 30 May 2017 20:37:53 GMT):
I also agree that it is not black and white, and each change should be voted on like any other change.

dave.enyeart (Tue, 30 May 2017 20:37:53 GMT):
I also agree that it is not black and white, and not an license to make changes - each change should be well explained including risk of not doing it, and voted on by maintainers like any other change.

dave.enyeart (Tue, 30 May 2017 20:38:34 GMT):
@jimthematrix For each change, I suggest you mention if the change could be made later or not. That is, if the change came in 1.1, would it impact client applications that were written against 1.0. And clearly explain the risk of not doing it, so that maintainers can effectively balance the risk of doing it vs the risk of not doing it.

dave.enyeart (Tue, 30 May 2017 20:40:17 GMT):
I have voted for the former, but not the latter, until you can add that aspect

jimthematrix (Tue, 30 May 2017 20:40:44 GMT):
good suggestion, will give it some thought

jimthematrix (Tue, 30 May 2017 20:59:52 GMT):
https://jira.hyperledger.org/browse/FAB-4131 updated in response to your suggestion @dave.enyeart

binhn (Tue, 30 May 2017 21:03:55 GMT):
@jimthematrix I +1ed FAB-2991 - are there others like this one? we should also consider annoying naming like getX vs queryX, setX vs X, delete/delX vs removeX, etc.

cbf (Tue, 30 May 2017 23:38:40 GMT):
@jimthematrix since I am the one you had the argument with, I will weigh in and say that we simply cannot deliver a release if we are still making changes - full stop

cbf (Tue, 30 May 2017 23:39:10 GMT):
we have a bunch of defects that we need to clean up and having the sdk continue to evolve makes fixing bugs a moving target

cbf (Tue, 30 May 2017 23:40:01 GMT):
the time for API changes ended about 6 weeks ago when we published aplha

cbf (Tue, 30 May 2017 23:40:51 GMT):
how are we going to write documentation if the SDK is a moving target?

cbf (Tue, 30 May 2017 23:41:11 GMT):
how are we going to stabilize the samples?

jimthematrix (Wed, 31 May 2017 00:23:50 GMT):
The sdk only stopped having to react to breaking changes after alpha2. Since then we've been focusing on API reviews along with fixing defects, and responding to community feedback.

jimthematrix (Wed, 31 May 2017 00:28:22 GMT):
i've also started reviewing API docs and writing tutorials. I'd say the few adjustments pending will not impact the docs effort much.

jimthematrix (Wed, 31 May 2017 00:34:41 GMT):
And as I try to point out above, while I agree with your statements above on and abstract level, these specific changes should be considered "safe", because they are not net new code, but they have significant impact on the overall perception of the API quality

JonathanLevi (Wed, 31 May 2017 02:35:13 GMT):
A quick question: How come https://jira.hyperledger.org/browse/FAB-2991 surfaces up just now?

JonathanLevi (Wed, 31 May 2017 02:36:08 GMT):
It was opened/created on *04/Apr/17 8:29 PM* (like 2 months, minus a week).

JonathanLevi (Wed, 31 May 2017 02:37:28 GMT):
Just/mainly trying to understand how we have ended up with this, a few days before we are about to officially lock the API.

JonathanLevi (Wed, 31 May 2017 02:39:24 GMT):
Just to say in advance, that on one hand, of course we would like a better (unified) API... while at the same time, we should remember that the longer we delay any milestone of Fabric 1.0, the further away the Fabric 1.0 gets, and of course, the longer we will need to wait for 1.1, 1.2, etc...

JonathanLevi (Wed, 31 May 2017 02:40:49 GMT):
At the same time, we should strive to release an API that we are comfortable with - which bring me back to the question "what happened between 04-Apr-2017 and 30-May-2017 ?" And please pardon my date & time convention ;-)

rickr (Wed, 31 May 2017 03:39:08 GMT):
Wow I sooner deliver end of the year then to be stuck with an API that's bad forever.

rickr (Wed, 31 May 2017 03:42:49 GMT):
Once we declare 1.0 they'll be stacks of stack built on top of this if it's successful. Changing then and will never hear the end of the screams.

rickr (Wed, 31 May 2017 03:42:49 GMT):
Once we declare 1.0 they'll be stacks of stack built on top of this if it's successful. Changing then and we'll never hear the end of the screams.

rickr (Wed, 31 May 2017 03:53:33 GMT):
The SDKs spent well over 5 months putting a lot if not most of the effort reacting ( and yes we did some screaming too) to changes in the Fabric. Now the the Fabric is happy and it's all must come to a stop? Sorry if you didn't get a chance to really cleanup the APIs you've got.

dave.enyeart (Wed, 31 May 2017 04:06:38 GMT):
a coherent client api is critical, as is time to market. we can't be taken seriously without both. let's try not to be dogmatic on either side - asserting date trumps all, or api correctness trumps all, is not very constructive. let's be pragmatic on a case by case basis, by having the sdk team explain each proposed change, maintainers vote on it, and move on accordingly. As @greg.haskins previously mentioned, the existing review-needed process should be able to handle this. As a next step, could the SDK teams enumerate the list of proposed changes, as a list of distinct review-needed jira items? Ideally by end of day wednesday?

JonathanLevi (Wed, 31 May 2017 05:07:00 GMT):
Thank you Dave. Jim:

JonathanLevi (Wed, 31 May 2017 05:07:04 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=ybD87AokeKg6HJHAD

JonathanLevi (Wed, 31 May 2017 05:23:40 GMT):
First, I think that we should *all* take a (few) deep breath(s) and calm down.

JonathanLevi (Wed, 31 May 2017 05:23:40 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down.

JonathanLevi (Wed, 31 May 2017 05:23:43 GMT):
Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with.

JonathanLevi (Wed, 31 May 2017 05:25:23 GMT):
Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor portrays the correct message. To be clear, there is no "we, the SDKs" vs. "we, the good looking Fabric".

JonathanLevi (Wed, 31 May 2017 05:27:06 GMT):
Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on.

JonathanLevi (Wed, 31 May 2017 05:28:13 GMT):
Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion.

JonathanLevi (Wed, 31 May 2017 05:28:40 GMT):
Without it, and with the precise information about it - it is difficult for me to form an opinion.

JonathanLevi (Wed, 31 May 2017 05:29:48 GMT):
I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure.

JonathanLevi (Wed, 31 May 2017 05:31:09 GMT):
If anything, it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry some more API changes.

JonathanLevi (Wed, 31 May 2017 05:31:09 GMT):
If anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes.

JonathanLevi (Wed, 31 May 2017 05:32:22 GMT):
So again, despite the pressure from all direction (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and how do we go from here, objectively.

JonathanLevi (Wed, 31 May 2017 05:32:22 GMT):
___ So again, despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and how do we go from here, objectively.

JonathanLevi (Wed, 31 May 2017 05:33:33 GMT):
I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them.

JonathanLevi (Wed, 31 May 2017 05:34:18 GMT):
As the famous saying goes: "Screamers will scream". Or does it not go like that?! ;-)

JonathanLevi (Wed, 31 May 2017 05:34:55 GMT):
Again, let's all get some sleep (where applicable), collect the information needed, and evaluate what's the best way to handle this.

JonathanLevi (Wed, 31 May 2017 05:35:00 GMT):
--- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:25 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor portrays the correct message. To be clear, there is no "we, the SDKs" vs. "we, the good looking Fabric". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and with the precise information about it - it is difficult for me (and probably for others) to form an opinion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So again, despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor portrays the correct message. To be clear, there is no "we, the SDKs" vs. "we, the good looking Fabric". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and with the precise information about it - it is difficult for me (and probably for others) to form an opinion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So again, despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor portrays the correct message. To be clear, there is no "we, the SDKs" vs. "we, the good looking Fabric". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and w/o the full picture - it is difficult for me (and probably for others) to form an opinion or reach a conclusion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So again, despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor conveys the correct message. To be clear, there is *no* "we, the SDKs" vs. "we, the good looking Fabric". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and w/o the full picture - it is difficult for me (and probably for others) to form an opinion or reach a conclusion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So again, despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor conveys the correct message. To be clear, there is *no* " *we, the SDKs* " vs. " *we, the good looking Fabric* ". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and w/o the full picture - it is difficult for me (and probably for others) to form an opinion or reach a conclusion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So again, despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor conveys the correct message. To be clear, there is *no* " *we, the SDKs* " vs. " *we, the good looking Fabric* ". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and w/o the full picture - it is difficult for me (and probably for others) to form an opinion or reach a conclusion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. I can find people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor conveys the correct message. To be clear, there is *no* " *we, the SDKs* " vs. " *we, the good looking Fabric* ". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and w/o the full picture - it is difficult for me (and probably for others) to form an opinion or reach a conclusion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. Last, I/we can find a long list of people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, more seriously: we don't need more "camps" and more "sides" here... there is only one *we*. Please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

JonathanLevi (Wed, 31 May 2017 05:49:57 GMT):
First, I think/believe we should *all* take a (few) deep breath(s) and calm down. Second, if anyone here got the impression that I am jumping to conclusions too quickly, then please re-read what I wrote above. I tried to explain both sides of the equation: the implications of not locking the API sooner/postponing the next milestone further vs. cutting a beta version with an API that we are not happy with. Third, trying to color the situation/discussion/argument as a "fabric" vs. "the SDKs" neither helps nor conveys the correct message. To be clear, there is *no* " *we, the SDKs* " vs. " *we, the good looking Fabric* ". Mind you, if anything, then us making the SDKs the preferred API, front-, client-, or dev-facing entry to the world, makes it a key component that we *all* rely on. Fourth, I/we need more information regarding what happened and why, along with the implications of the API improvement tasks that are at the heart of the discussion. Without it, and w/o the full picture - it is difficult for me (and probably for others) to form an opinion or reach a conclusion. --- Now, I do appreciate that making so many (last minute) changes to fabric, required a lot of changes to the SDK(s), work that was delivered under a lot of pressure. But if anything, please take a quick look at https://jira.hyperledger.org/browse/FAB-4212 , and see that it took me just a few minutes to conclude this morning, for example, that we should hold off cutting a *v1.0.0-beta* while more tooling work is still in progress, just for the off-chance that it might carry/require some more API changes. --- So despite the pressure from all directions (and just to mention that we are under immense pressure to release a Fabric 1.0), let's again, calm down, and evaluate where we stand and where do we go/how do we proceed from here, objectively. Last, I/we can find a long list of people that will "scream", whether we cut a beta without the API changes to the SDKs, or whether we do wait for them. As the famous saying goes: *Screamers will scream*. Or is it not how the original thing goes?! 😉 --- Again, more seriously: we don't need more "camps" and more "sides" here... *AFAIC, there is only one we*. Please let's all get some sleep (where applicable, or a nice morning coffee), collect the information needed, and evaluate what's the best way to handle this. --- Good night.

yacovm (Wed, 31 May 2017 09:26:46 GMT):
Hi all. Please take a look at this JIRA issue that is related to migration from v1.0 to v1.x. It deals with the fact that we don't do time-based certificate validation in v1.0 but in v1.1 we will do. https://jira.hyperledger.org/browse/FAB-4203

mastersingh24 (Wed, 31 May 2017 09:35:22 GMT):
WOW! That's all I have to say. My assessment: we dance around the issue(s) / goals and try to fit them into neat little boxes. @JonathanLevi - you asked for facts / information and @dave.enyeart you are correct in stating that we should use the "review" process that we have in place. More or less agree on both points. Let me state some facts: 1) It should come as no surprise to anyone that there are still a few proposed changes to the SDK(s) in terms of external facing API. @jimthematrix was very clear about this when the alpha2 was cut and as a matter of fact he even stated that as a reason for not calling alpha2 a beta 2) BUT .... @jimthematrix did not do a great job of outlining the JIRA items which needed to be addressed and we did not have a clear list of things for "job done" for the SDKs - meaning there is only so much time and we do need a finite list of things else we'll never be done. Of course part of this is that not everyone is involved with using the SDKs on a daily basis and everyone does not track all the work being done. So no fault(s) here - just a fact. 3) @JonathanLevi @cbf - You both ask why these things come up now - it's really quite simple - the SDK teams spent / spend all their time catching up with fabric changes (mainly all of the security stuff which really had a major impact on their efforts) and therefore it is only now that anyone can look at the actual APIs rather than just trying to keep the SDKs working So what do we do: - As @dave.enyeart said, let's get the list of proposed improvements for the SDKs established. This includes all of them - not just the Node SDKs - ASAP - i.e TODAY - Vote on the list (as per usual process) although honestly I think we do need to have the main SDK developers and users weigh in the most

mastersingh24 (Wed, 31 May 2017 09:38:52 GMT):
Last point: next release (e.g. beta, RC, whatever). PLEASE PLEASE PLEASE - let's not get into the same crisis mode we did putting out alpha2. It did not go well IMHO. @JonathanLevi @cbf - you are our release managers - I see that there is a JIRA entry, but we really need to also make sure that we do go through a checklist to ensure everything is in place and in sync. Once we cut a BETA and/or RC - there can be NO external facing changes to existing APIs at that point. This includes all components. I will also state that we try to follow a process, but then we still rush everything at the end. Not sure why that keeps happening but we should be able to do better this time around

mastersingh24 (Wed, 31 May 2017 10:37:52 GMT):
[ https://jira.hyperledger.org/browse/FAB-4203?focusedCommentId=24742&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24742](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Ts8f6pY88z7qrPeKR) @yacovm @muralisr

mastersingh24 (Wed, 31 May 2017 10:40:01 GMT):
[https://jira.hyperledger.org/browse/FAB-4203?focusedCommentId=24742&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24742 ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Ts8f6pY88z7qrPeKR) @yacovm

mastersingh24 (Wed, 31 May 2017 10:40:11 GMT):
@muralisr ^^^^^

yacovm (Wed, 31 May 2017 10:44:19 GMT):
hmm but Gari the code that is related to time-based certificate is not in the VSCC

yacovm (Wed, 31 May 2017 10:44:28 GMT):
but rather deep inside the `mspimpl.go`

yacovm (Wed, 31 May 2017 10:44:28 GMT):
but rather deep inside in the `mspimpl.go`

yacovm (Wed, 31 May 2017 10:44:56 GMT):
so it's global in the peer and not per VSCC

yacovm (Wed, 31 May 2017 10:47:09 GMT):
I answered in the JIRA item

cbf (Wed, 31 May 2017 11:20:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=TZJbK6jFGEYhbRqvJ) @JonathanLevi +2

cbf (Wed, 31 May 2017 11:23:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=6gRJtNKLSJK8f5LeX) @mastersingh24 agree we need to go through a checklist... that is what I have been trying to establish as part of FAB-4212 - and have expressly invited people to weigh in and advocate for the CRs that MUST BE LANDED, just as we did so successfully (not) for alpha2.

cbf (Wed, 31 May 2017 11:25:29 GMT):
What I want to have us do is review these COLLECTIVELY. Thoroughly. To test manually and automated and agree we are done. That cannot be "well, SDK can keep changing while we do this, right?"

cbf (Wed, 31 May 2017 11:27:37 GMT):
IFF we are to add function to the SDK, then IMNSHO we need to be adding the barest minimum to achieve MVP. We cannot keep pushing out to get perfection. We can add function post 1.0.0 just as for the main Fabric code. We can limit the scope of 1.1 (which we should do, regardless) and deliver 1.1 in say 3 months.

cbf (Wed, 31 May 2017 11:28:05 GMT):
Or, we can muddle along seeking perfection while the world moves on past us.

dave.enyeart (Wed, 31 May 2017 12:06:49 GMT):
As has been said above, @jimthematrix is not talking about adding new function or muddling along. He's talking about fixing a limited number of incoherent aspects of the sdk api, and making them coherent. A client API is not something that can simply be changed in 1.1. It needs to be coherent in 1.0. Why is it incoherent? Because it grew organically during a fast-paced project in response to fabric changes. Let's pause and give Jim the benefit of proposing (today) the (limited) set of specific changes he thinks are required for MVP.

jimthematrix (Wed, 31 May 2017 12:22:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=efi4C3eBwsowBdZAv) @rickr @JonathanLevi the "grace period" I'm talking about is I'm asking for one release after the fabric/fabric-ca APIs finally settled down (which in reality is alpha2, not alpha), because the SDKs have been spending all the bandwidth keeping up with the backend and chasing breaks. FAB-2991 is really simple changes (for that matter so is FAB-4131) but we didn't feel comfortable doing it before alpha2 because changes in the backend could impact our decision

jimthematrix (Wed, 31 May 2017 12:22:49 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=efi4C3eBwsowBdZAv) @JonathanLevi the "grace period" I'm talking about is I'm asking for one release after the fabric/fabric-ca APIs finally settled down (which in reality is alpha2, not alpha), because the SDKs have been spending all the bandwidth keeping up with the backend and chasing breaks. FAB-2991 is really simple changes (for that matter so is FAB-4131) but we didn't feel comfortable doing it before alpha2 because changes in the backend could impact our decision. @rickr 's comment well summarize the reason

jimthematrix (Wed, 31 May 2017 12:49:02 GMT):
@dave.enyeart @mastersingh24 @cbf @JonathanLevi @rickr thanks for weighing in on the discussion, wow I felt that was a fantastic thread of discussions and we were converging on many fronts.

jimthematrix (Wed, 31 May 2017 12:51:24 GMT):
Rick and I will do another pass through the SDKs code today and make sure all remaining changes will be recorded in JIRA items and tagged for review. we have done a pass and I don't believe we have more than FAB-2991 and 4131 but will do another pass to make sure

weeds (Wed, 31 May 2017 12:53:40 GMT):
@jimthematrix I also think one key question i do have for you- for any of these changes- are the JUST for the SDK- or are there fundamental changes that must go into the core fabric? I think that is very important to understand.

weeds (Wed, 31 May 2017 12:53:40 GMT):
@jimthematrix I also think one key question i do have for you- for any of these changes- are they JUST for the SDK- or are there fundamental changes that must go into the core fabric? I think that is very important to understand.

weeds (Wed, 31 May 2017 12:55:20 GMT):
@cbf @JonathanLevi I like the fact we are putting what we need to do in the JIRA, but I also feel some of the "steps" are repeated processes (obviously we need to automate)... but I think you as release managers are pulling together a big checklist at least that we have to do every round. I'm wondering ultimately if we need a wiki of here is the checklist so future release managers won't miss things that we may have done in previous alpha... yes, we would still use JIRA to track the specifics, but I wonder if that might help in the future?

weeds (Wed, 31 May 2017 12:55:20 GMT):
@cbf @JonathanLevi For cutting the beta release (or release candidate,etc,.), I like the fact we are putting what we need to do in the JIRA, but I also feel some of the "steps" are repeated processes (obviously we need to automate)... but I think you as release managers are pulling together a big checklist at least that we have to do every round. I'm wondering ultimately if we need a wiki of here is the checklist so future release managers won't miss things that we may have done in previous alpha... yes, we would still use JIRA to track the specifics, but I wonder if that might help in the future?

weeds (Wed, 31 May 2017 12:55:34 GMT):
this is for cutting alpha, cutting alpha 2, cutting beta,etc,..

weeds (Wed, 31 May 2017 12:55:40 GMT):
I also wonder if it may help other projects

cbf (Wed, 31 May 2017 12:59:35 GMT):
@weeds a wiki is not what we need

cbf (Wed, 31 May 2017 12:59:54 GMT):
we cannot fragment our approach

jimthematrix (Wed, 31 May 2017 13:04:03 GMT):
Maintainers please give https://jira.hyperledger.org/browse/FAB-2991 and https://jira.hyperledger.org/browse/FAB-4131 another look and cast your votes. and thanks for those who have already voted

jimthematrix (Wed, 31 May 2017 13:04:58 GMT):
@cbf I responded to your question in he comment to 4131 (and thanks for the concerns)

cbf (Wed, 31 May 2017 13:05:15 GMT):
as for the whole SDK kerfuffle, it certainly feels like creep to me. The SDK changes have not been isolated fixes. https://jira.hyperledger.org/browse/FAB-4131 is a case in point. The CR actually goes beyond the scope of the enhancement. The description actually makes the case that the change could be introduced post 1.0. So, why would we make a change that affects over 600 LOC in the SDK code at this point, when it COULD be introduced after?

cbf (Wed, 31 May 2017 13:06:07 GMT):
note that the change also does not include the documentation changes necessary to inform the user as to how to leverage the feature, etc

cbf (Wed, 31 May 2017 13:11:49 GMT):
IMO, we need to take a cue from @JonathanLevi and take a breath. We all want the best for Fabric, no doubt. However, we need to all consider the whole, not just parts. We also need to make tough decisions about when it is soup. We could noodle on this for the next year and not release in an effort to make it perfect. However, we need to recognize that nothing is perfect and we need to be willing to accept that we will get TONS of user feedback that will result in changes as Fabric evolves from 1.0 to 1.1 and beyond.

cbf (Wed, 31 May 2017 13:12:53 GMT):
Further, unless we succumb to throwing in the kitchen sink (as we sort of did for 1.0, you must admit) we should be able to get a 1.1 out quickly, to address the most pressing new features, and to improve the SDK experience.

cbf (Wed, 31 May 2017 13:15:37 GMT):
So, what is the best way to get the software in user's hands? Get the release out and start working on the feedback. Deliver incremental improvement constantly and quickly. It's been almost a year since 0.6. We should not be thinking it will be another year for 1.1, so we should not be bent out of shape if something doesn't make the cut.

cbf (Wed, 31 May 2017 13:16:31 GMT):
Further, our subsequent releases will need strive for backwards compatibility of clients, so that application code need not be refactored except in extreme cases.

cbf (Wed, 31 May 2017 15:58:35 GMT):
@here https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104#Filter-Results/10517 I added # votes to the dashboard gadget

weeds (Wed, 31 May 2017 16:12:58 GMT):
@cbf- i went into your link and this is the error i got: The filter configured for this gadget could not be retrieved. Please verify it is still valid on the issue navigator.

weeds (Wed, 31 May 2017 16:12:58 GMT):
@cbf i went into look at your link and this is the error i got: The filter configured for this gadget could not be retrieved. Please verify it is still valid on the issue navigator.

cbf (Wed, 31 May 2017 16:18:59 GMT):
can you see it here https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104#

cbf (Wed, 31 May 2017 16:19:11 GMT):
second tier of gadgets on the left

weeds (Wed, 31 May 2017 17:07:36 GMT):
@cbf yes that works

weeds (Wed, 31 May 2017 17:07:51 GMT):
wait no- that does not work- same message

weeds (Wed, 31 May 2017 17:08:11 GMT):
here is error right above the bubble chart- The filter configured for this gadget could not be retrieved. Please verify it is still valid on the issue navigator.

cbf (Wed, 31 May 2017 17:10:23 GMT):
huh

JonathanLevi (Wed, 31 May 2017 17:10:53 GMT):

Message Attachments

JonathanLevi (Wed, 31 May 2017 17:12:16 GMT):
Just took a look in a browser that is not logged on to JIRA - there is only one "Gadget" that needs (re)configuration, I believe. The rest seems fine.

JonathanLevi (Wed, 31 May 2017 17:12:16 GMT):
OK, I have a repro: Just took a look from a browser that is not logged on to JIRA - there is only one "Gadget" that needs (re)configuration, I believe. The rest seems fine.

cbf (Wed, 31 May 2017 17:12:19 GMT):
weird, someone changed visibility from public to the set of maintainers

cbf (Wed, 31 May 2017 17:12:32 GMT):
should work now

JonathanLevi (Wed, 31 May 2017 17:13:04 GMT):
Indeed. Now it works even when I'm not logged in. @weeds ?

cbf (Wed, 31 May 2017 17:36:05 GMT):
so tiresome https://jira.hyperledger.org/browse/FAB-3618?focusedCommentId=24817&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-24817

kostas (Wed, 31 May 2017 17:56:48 GMT):
You'll see this during the "review-needed" rounds, but I might as well bring it up here: https://jira.hyperledger.org/browse/FAB-4121?focusedCommentId=24824&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-24824

kostas (Wed, 31 May 2017 17:57:34 GMT):
TL;DR the critical bug in https://jira.hyperledger.org/browse/FAB-4136 may need some `orderer.yaml` changes, so review and consensus will be needed

kostas (Wed, 31 May 2017 17:58:58 GMT):
Open to workarounds, and we can be flexible (as long as we're willing to pay the necessary price). Let's discuss this in FAB-4121.

weeds (Wed, 31 May 2017 18:53:05 GMT):
@cbf works now-- i have a problem with JIRA right now that i'm getting Ry to help with unfortunately- which explains why i saw it differently

dave.enyeart (Wed, 31 May 2017 18:57:16 GMT):
I reviewed the beta work items identified by @cbf in https://jira.hyperledger.org/browse/FAB-4212 - great start on a beta blocking list and checklist. I compared notes with @mastersingh24 relative to what else is needed for beta. Where there is work required to modify/finalize release artifacts, I've added 'release artifact' work items to the blocking list. These are things that needed to be discussed in Jira, picked up or assigned, and worked asap, in preparation for an upcoming beta (we could decide to defer a few until RC1, but that would not be ideal and should be an explicit decision). I've also added several subtasks to the release 'checklist' for the actual beta delivery.

dave.enyeart (Wed, 31 May 2017 18:57:45 GMT):
The Jira list supersedes the Google document that I had started: https://docs.google.com/document/d/1mPTMjXG_b-mgZd2_EUN9W-82ez0PrWoxIiPgcAAABwE/edit#

cbf (Wed, 31 May 2017 19:06:03 GMT):
@dave.enyeart thanks!

cbf (Wed, 31 May 2017 19:06:17 GMT):
one of the issues is also deciding on a release notes format

cbf (Wed, 31 May 2017 19:06:19 GMT):
https://jira.hyperledger.org/browse/FAB-3054?focusedCommentId=24842&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-24842

dave.enyeart (Wed, 31 May 2017 19:07:23 GMT):
for each of the 'release artifacts' in the blocking list - do you think we should tag with review-needed in order to stimulate some maintainer discussion in each jira item?

JonathanLevi (Wed, 31 May 2017 19:11:38 GMT):
Dave, this is great. Thanks. Please let's use clickable URLs ?

JonathanLevi (Wed, 31 May 2017 19:12:18 GMT):
One option is to group some of these in JIRA indeed, so that each sub-task/item's will auto-update...

JonathanLevi (Wed, 31 May 2017 19:12:18 GMT):
One option is to group some of these in JIRA indeed, so that each sub-task/item's will be auto-updated...

weeds (Wed, 31 May 2017 19:14:30 GMT):
@cbf by the way- this is something Clayton and I noticed. If you are not logged into JIRA, the numbers on your dashboard are different (something I ran into first thin in the AM yesterday and had not realized i was not logged in yet)... if you want to try this out yourself- look at fabric 1.0 open bugs chart in the lower left corner: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104

weeds (Wed, 31 May 2017 19:14:30 GMT):
@cbf by the way- this is something Clayton and I noticed. If you are not logged into JIRA, the numbers on your dashboard are different (something I ran into first thing in the AM yesterday and had not realized i was not logged in yet)... if you want to try this out yourself- look at fabric 1.0 open bugs chart in the lower left corner: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104

JonathanLevi (Wed, 31 May 2017 19:17:01 GMT):
-----

JonathanLevi (Wed, 31 May 2017 19:17:20 GMT):
How many people here believe that we are ready to cut a *beta* in a day or two?

kostas (Wed, 31 May 2017 19:17:27 GMT):
Not me.

weeds (Wed, 31 May 2017 19:17:49 GMT):
Do we have to have Beta or could we go to release candidate? this has not been clear to me

JonathanLevi (Wed, 31 May 2017 19:18:02 GMT):
We need to lock APIs.

JonathanLevi (Wed, 31 May 2017 19:18:12 GMT):
However we call it.

mastersingh24 (Wed, 31 May 2017 19:18:12 GMT):
what's an API?

JonathanLevi (Wed, 31 May 2017 19:18:23 GMT):
Oh no. Not again ;-)

mastersingh24 (Wed, 31 May 2017 19:18:28 GMT):
Is that some marketing term?

JonathanLevi (Wed, 31 May 2017 19:18:33 GMT):
API/ABI and configs.

mastersingh24 (Wed, 31 May 2017 19:18:53 GMT):
API, ABI OH MY ;) (ok I'm done now)

dave.enyeart (Wed, 31 May 2017 19:18:56 GMT):
for your clicking pleasure - here are the release artifacts that I think we need to finalize prior to beta:

dave.enyeart (Wed, 31 May 2017 19:18:57 GMT):
https://jira.hyperledger.org/browse/FAB-4267 Release artifacts - Finalize release binaries build, distribution, installation approach (for non-Docker artifacts) https://jira.hyperledger.org/browse/FAB-4269 Release artifacts - Finalize e2e sample approach https://jira.hyperledger.org/browse/FAB-4270 Release artifacts - Finalize docker compose approach https://jira.hyperledger.org/browse/FAB-4271 Release artifacts - Finalize fabric-client and fabric-ca-client node sdk approach for publishing to NPM https://jira.hyperledger.org/browse/FAB-4272 Release artifacts - Finalize fabric-sdk-java distribution approach https://jira.hyperledger.org/browse/FAB-4273 Release artifacts - Finalize nexus release location, structure, and download approach https://jira.hyperledger.org/browse/FAB-4275 Release artifacts - Automated test to download/test release artifacts across platforms

dave.enyeart (Wed, 31 May 2017 19:18:57 GMT):
https://jira.hyperledger.org/browse/FAB-4267 Release artifacts - Finalize release binaries build, distribution, installation approach (for non-Docker artifacts) https://jira.hyperledger.org/browse/FAB-4269 Release artifacts - Finalize e2e sample approach and artifacts https://jira.hyperledger.org/browse/FAB-4270 Release artifacts - Finalize docker compose approach and artifacts https://jira.hyperledger.org/browse/FAB-4271 Release artifacts - Finalize fabric-client and fabric-ca-client node sdk approach for publishing to NPM https://jira.hyperledger.org/browse/FAB-4272 Release artifacts - Finalize fabric-sdk-java distribution approach https://jira.hyperledger.org/browse/FAB-4273 Release artifacts - Finalize nexus release location, structure, and download approach https://jira.hyperledger.org/browse/FAB-4275 Release artifacts - Automated test to download/test release artifacts across platforms

weeds (Wed, 31 May 2017 19:19:45 GMT):
API gravity, is a measure of how heavy or light a petroleum liquid is compared to water.

weeds (Wed, 31 May 2017 19:19:53 GMT):
ha ha

weeds (Wed, 31 May 2017 19:20:07 GMT):
i feel that the petroleum is quite heavy right now

weeds (Wed, 31 May 2017 19:20:07 GMT):
i feel that the petroleum is quite heavy right now. I couldn't resist.

dave.enyeart (Wed, 31 May 2017 19:21:43 GMT):
I did not include the actual fabric docker images and publishing to dockerhub, as I think that is pretty well figured out, but if people think there is more to do there, then we can create a 'release artifact' jira item for that as well

JonathanLevi (Wed, 31 May 2017 19:22:13 GMT):
OK. Dave, let's add *all* of these to the google doc. We should try to get people assigned to each and an ETA.

dave.enyeart (Wed, 31 May 2017 19:22:58 GMT):
in my mind, the google doc was for initial brainstorming, and i've now encoded into jira for discussion and execution going forward

JonathanLevi (Wed, 31 May 2017 19:23:50 GMT):
OK. My take is: 1) We are clearly not ready for a beta 2) We have a set of milestones that we have committed to. 3) We may need to re-review some of these, when we have ETAs, add them up and see what is a must.

JonathanLevi (Wed, 31 May 2017 19:24:50 GMT):
As an aside, we should really have *one source* of information/status. It's difficult to follow and get the actual status / latest state of affairs.

JonathanLevi (Wed, 31 May 2017 19:25:08 GMT):
And of of course, thanks a lot for your help @dave.enyeart.

dave.enyeart (Wed, 31 May 2017 19:26:29 GMT):
I think FAB-4212 is the *one source* for beta status. It has a list of blockers (including my items above), as well as a list of subtasks for actual execution/checklist.

fbenhamo (Wed, 31 May 2017 19:27:59 GMT):
Has joined the channel.

JonathanLevi (Wed, 31 May 2017 19:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Jgictwj4EgvBd4vow) As you all know, I'm not a good marketing person ;-)

JonathanLevi (Wed, 31 May 2017 19:43:32 GMT):
@dave.enyeart Added your doc to https://jira.hyperledger.org/browse/FAB-4212, thanks.

cbf (Wed, 31 May 2017 19:47:52 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ELnErLNZMmfMfTCKT) @weeds I don't think we can or should go directly to RC TBH

cbf (Wed, 31 May 2017 19:54:31 GMT):
FWIW, I do not think we should overload review-needed - it has a specific purpose

weeds (Wed, 31 May 2017 20:06:17 GMT):
@cbf so do we need 2 weeks between beta and release candidate? that was not really outlined in the exit criteria- I know we need release candidate and then cut to release with 2 weeks in between at minimum along with exit criteria achieved

JonathanLevi (Wed, 31 May 2017 20:10:53 GMT):
I know that some people don't always like me saying it, but *in general*, I'd rather cut "features" than *testing time* including giving enough time to provide us with (early) feedback.

JonathanLevi (Wed, 31 May 2017 20:11:59 GMT):
One way "out" is to release a super solid RC1, which may prove to everybody that *this version of fabric is SO, SO good... come on, let's ship it already*.

JonathanLevi (Wed, 31 May 2017 20:13:04 GMT):
I don't believe anyone here will ask us not to have a GA/cut, if we can collect enough good feedback, regarding the maturity and the readiness of the latest, say *rc1* cut.

JonathanLevi (Wed, 31 May 2017 20:13:49 GMT):
For getting there, I believe that we'd need a lot of discipline and very open/transparent communication - especially when we have issues (that we are aware of).

JonathanLevi (Wed, 31 May 2017 20:14:42 GMT):
---- BTW: @dave.enyeart , as an aside, I have "upgraded" your (temporary) brainstorm document so that we have the option to re-use it, going forward. Hope I didn't butcher the formatting too much.

JonathanLevi (Wed, 31 May 2017 20:14:49 GMT):
https://docs.google.com/document/d/1mPTMjXG_b-mgZd2_EUN9W-82ez0PrWoxIiPgcAAABwE/edit?usp=sharing

weeds (Wed, 31 May 2017 20:15:51 GMT):
I agree @jonathanLevi there is nothing like having people stand up "using" the product and saying it's good-- so ++

weeds (Wed, 31 May 2017 20:15:51 GMT):
I agree @JonathanLevi there is nothing like having people stand up "using" the product and saying it's good-- so ++

JonathanLevi (Wed, 31 May 2017 20:17:12 GMT):
Yup. At the same time, I am trying to find out if we could simply have yet another "cut" sooner/-ish... rather than in mid June (if my ability to add ETAs is still working)

weeds (Wed, 31 May 2017 20:17:58 GMT):
ok

JonathanLevi (Wed, 31 May 2017 20:18:15 GMT):
BTW: I do believe that the more (often) we release, the better we'd all get at it....

JonathanLevi (Wed, 31 May 2017 20:19:06 GMT):
And once we get really good at it, I'd propose to open a new "#drama" channel, to remind us all of the good ol' days ;-)

weeds (Wed, 31 May 2017 20:43:45 GMT):
chuckling

weeds (Wed, 31 May 2017 20:43:59 GMT):
also- if i were to really highlight the biggest risk areas- in my opinion of course it would be:

weeds (Wed, 31 May 2017 20:44:35 GMT):
defect backlog- but more in the areas of peer and consensus (the consensus bugs are usually very painful to fix)

weeds (Wed, 31 May 2017 20:44:58 GMT):
what results may come out of thte system test going on (ie performance, scale, concurrency, long run,etc,.)

weeds (Wed, 31 May 2017 20:45:33 GMT):
the results of the pen testing-- which i don't think has started (chris is supposed to be prodding linux foundation on that)

weeds (Wed, 31 May 2017 20:45:41 GMT):
pen testing can "sometimes" find some nasty bugs

weeds (Wed, 31 May 2017 20:46:01 GMT):
there is the whole list of things- but this is where I worry the most... i am driving team internally on the defects hard btw

weeds (Wed, 31 May 2017 20:46:22 GMT):
but telling them highest, high... and being careful not to add features (although you see sometimes there is a line they don't all get)

jimthematrix (Wed, 31 May 2017 20:55:03 GMT):
just created https://jira.hyperledger.org/browse/FAB-4283 and tagged `review-needed` to follow up from this morning's discussions. that'll be all for node SDK. not so much API changes as removing unimplemented methods or unneeded methods/properties.

jimthematrix (Wed, 31 May 2017 20:56:43 GMT):
for Java SDK nothing planned at the moment, but under the cover it's at a different state (as in "we don't know if any would be needed until we get more feedback from usage")

jimthematrix (Wed, 31 May 2017 20:56:43 GMT):
for Java SDK nothing planned at the moment beyond cleanup of unused code, but under the cover it's at a different state (as in "we don't know if any API changes would be needed until we get more feedback from usage")

JonathanLevi (Wed, 31 May 2017 20:59:04 GMT):
Thank you @jimthematrix . Do we have a rough estimate as for how much more work will be required (assuming we don't find anything new/given what we know today) for the Node SDK ?

JonathanLevi (Wed, 31 May 2017 20:59:27 GMT):
Is it a matter of days ?

JonathanLevi (Wed, 31 May 2017 21:00:08 GMT):
( *not* trying to apply any pressure, or hint at anything. An ETA will help with planning, more than anything)

jimthematrix (Wed, 31 May 2017 21:00:23 GMT):
outstanding work include https://jira.hyperledger.org/browse/FAB-2787, and the two that are in review list

jimthematrix (Wed, 31 May 2017 21:00:46 GMT):
should be a matter of a day or two

JonathanLevi (Wed, 31 May 2017 21:01:52 GMT):
Got you. Thanks !

jimthematrix (Wed, 31 May 2017 21:02:26 GMT):
also https://jira.hyperledger.org/browse/FAB-4226, still in a day or two

jimthematrix (Wed, 31 May 2017 21:02:34 GMT):
(sample app upgrade)

JonathanLevi (Wed, 31 May 2017 21:03:08 GMT):
One of my tasks in the coming days should probably to "let you guys work" rather than participate in all these "dramatic" discussions.

JonathanLevi (Wed, 31 May 2017 21:03:40 GMT):
One of my tasks in the coming days should probably be to try and "let you guys work" rather than participate in all these "dramatic" discussions ;-)

JonathanLevi (Wed, 31 May 2017 21:04:02 GMT):
Let's see how it goes. Thanks again.

JonathanLevi (Wed, 31 May 2017 21:05:25 GMT):
Just to quickly say, that if we can really push some of these out (for review), we may work on a "cut" next week. The idea is not to apply more pressure, but rather to check that our process is getting better.

JonathanLevi (Wed, 31 May 2017 21:06:12 GMT):
I will formulate some of the opinions/views that are shared with me. One of which, is that we should simply start thinking/working on regular/frequent "builds".

JonathanLevi (Wed, 31 May 2017 21:06:12 GMT):
I will formulate/combine some of the opinions/views that are/were shared with me and others, on several occasions. One of which, is that we should simply start thinking/working on regular/frequent "builds".

JonathanLevi (Wed, 31 May 2017 21:06:12 GMT):
[UPDATED:] I will formulate/formalize/combine some of the opinions/views that are/were shared with me and others, on several occasions. One of which, is that we should simply start thinking/working on regular/frequent "builds".

JonathanLevi (Wed, 31 May 2017 21:07:01 GMT):
So that we have a "train", leaving, say, every X weeks. Whatever is onboard, is getting released, whatever's not there - will not be part of it.

JonathanLevi (Wed, 31 May 2017 21:07:43 GMT):
This way, we should all be clear about "what's coming" and when. Again, more about this later. For now, let's just all see where we stand.

cbf (Wed, 31 May 2017 21:25:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=96T6fzw6nKnntfh5Q) @JonathanLevi this has been my point all along... cut a release every 2 weeks

cbf (Wed, 31 May 2017 21:25:44 GMT):
get the practice

greg.haskins (Wed, 31 May 2017 21:58:06 GMT):
+1 for frequent releases

greg.haskins (Wed, 31 May 2017 21:59:11 GMT):
It should be painless, so if it's not, doing them more often will help get us there

mastersingh24 (Wed, 31 May 2017 22:16:29 GMT):
no pain no gain

mastersingh24 (Wed, 31 May 2017 22:16:47 GMT):
I gotta stop living in the 80's

JonathanLevi (Wed, 31 May 2017 22:20:30 GMT):
Hold on, we didn't have Win32 in the 80's ! ;-)

JonathanLevi (Wed, 31 May 2017 22:22:17 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=T92897iyPhK3QSzHd) Yes, that's true. Same for @greg.haskins and some others (maintainers, or just good ol' timers ;-)).

JonathanLevi (Wed, 31 May 2017 22:22:17 GMT):
___ @cbf: [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=T92897iyPhK3QSzHd) Yes, that's true. Same for @greg.haskins and some others (maintainers, or just good ol' timers ;-)).

rickr (Wed, 31 May 2017 23:25:45 GMT):
There was DOS . can't we get this all running in 640K ?

tkuhrt (Wed, 31 May 2017 23:44:13 GMT):
So, I am just catching up with this channel since Consensus. I noticed that @cbf mentioned that we should use SPDX for license identifiers. This is true; however, we should not change any existing files that already have the license information in the header. This is from the folks at The Linux Foundation. Not sure if I am too late, but if you have not already made the change of existing license text to SPDX, please don't.

greg.haskins (Thu, 01 Jun 2017 01:24:12 GMT):
@tkuhrt I think the short answer is, the vast majority are still unmodified...but that said, do you have an understanding the the rationale?

greg.haskins (Thu, 01 Jun 2017 01:24:59 GMT):
it strikes me as beneficial to convert for the sake of conformance testing in the linter task, and I can't imaging why it would matter otherwise

greg.haskins (Thu, 01 Jun 2017 01:24:59 GMT):
it strikes me as beneficial to convert for the sake of conformance testing in the linter task, and I can't imagine why it would matter otherwise

cbf (Thu, 01 Jun 2017 09:45:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=X77skmSDxf6s5E3iR) @tkuhrt why? We will have to undo a bunch.

dave.enyeart (Thu, 01 Jun 2017 10:51:30 GMT):
Could somebody remind me what the criteria is for a passed Verification?

dave.enyeart (Thu, 01 Jun 2017 10:51:38 GMT):
Looking at: https://gerrit.hyperledger.org/r/#/c/9287/

dave.enyeart (Thu, 01 Jun 2017 10:52:32 GMT):
verify for x86_64 and z both passed. only verify for behave failed. This results in a -1 Verification.

dave.enyeart (Thu, 01 Jun 2017 10:53:10 GMT):
The behave failures have nothing to do with the change. Can I (as a maintainer) override the -1 Verification manually in these cases?

yacovm (Thu, 01 Jun 2017 10:54:11 GMT):
well notice the behave succeeded before

yacovm (Thu, 01 Jun 2017 10:54:14 GMT):
right?

yacovm (Thu, 01 Jun 2017 10:54:28 GMT):
so it's not that your change set failed behave

dave.enyeart (Thu, 01 Jun 2017 10:55:34 GMT):
So I (as a maintainer) can use my judgement in these cases and manually change it to a +1 right?

yacovm (Thu, 01 Jun 2017 10:55:46 GMT):
yeah I believe so

dave.enyeart (Thu, 01 Jun 2017 10:59:10 GMT):
ok done. this one is ready for a 2nd +2 review then: https://gerrit.hyperledger.org/r/#/c/9287

yacovm (Thu, 01 Jun 2017 11:00:00 GMT):
Don't forget to remove the vote of the job builder

dave.enyeart (Thu, 01 Jun 2017 11:00:22 GMT):
done

cbf (Thu, 01 Jun 2017 11:32:16 GMT):
@dave.enyeart yes, you can use your best judgement and remove the jenkins vote IFF the failure is a known failure and the change is unrelated. Please don't abuse, of course.

greg.haskins (Thu, 01 Jun 2017 12:31:50 GMT):
@dave.enyeart @cbf I would also add that a) this should be very rare, and b) it should be accompanied with a decent note on the what/where/why

cbf (Thu, 01 Jun 2017 12:32:03 GMT):
+1

weeds (Thu, 01 Jun 2017 16:10:17 GMT):
@cbf I meant to ask- do you know if Linux team has started pen testing or when it officially starts?

sstone1 (Thu, 01 Jun 2017 16:10:55 GMT):
Has joined the channel.

cbf (Thu, 01 Jun 2017 17:46:01 GMT):
no, last email (today) suggests that Dave has call with the contractor tomorrow and others are invited to join in (though I have not seen the invite)

cbf (Thu, 01 Jun 2017 17:46:10 GMT):
@weeds ^^

weeds (Thu, 01 Jun 2017 17:48:34 GMT):
feel free to add me- I would love to learn the process they use

JonathanLevi (Thu, 01 Jun 2017 18:03:10 GMT):
Internal discussions amongst the maintainers of Hyperledger Fabric. BTW: please use #fabric-pr-review for pull request's (PR) reviews

JonathanLevi (Thu, 01 Jun 2017 18:05:01 GMT):
@rickr, @weeds, etc... please let's move all the "non-internal" discussions, comments, questions, to other channels. E.g., most of the latest topical stuff, that is not "amongst the maintainers, by maintainers, for maintainers", regarding the release, should take place in #fabric-release (that is widely open both to questions, discussions, comments, etc.)

JonathanLevi (Thu, 01 Jun 2017 18:05:31 GMT):
I have updated the room topic above.

JonathanLevi (Thu, 01 Jun 2017 18:06:13 GMT):
Internal discussions amongst the maintainers of Hyperledger Fabric. BTW: please use #fabric-pr-review for pull requests' (PR) reviews, #fabric-release for release related stuff, etc.

yacovm (Thu, 01 Jun 2017 18:11:06 GMT):
BTW?

muralisr (Thu, 01 Jun 2017 18:19:12 GMT):
maintainers, this has 4 votes https://jira.hyperledger.org/browse/FAB-3199

muralisr (Thu, 01 Jun 2017 18:19:37 GMT):
and has a CR out there https://gerrit.hyperledger.org/r/#/c/8403

muralisr (Thu, 01 Jun 2017 18:20:33 GMT):
if you have not taken a look, could you please ?

tkuhrt (Thu, 01 Jun 2017 18:23:03 GMT):
@cbf , @greg.haskins : Regarding removal of license text and replacing with SPDX short form identifiers, here is what I got from the experts at The Linux Foundation: * Some open source licenses are phrased such that they might not permit removing existing license text. Just as an example, the 3-clause BSD license (https://spdx.org/licenses/BSD-3-Clause.html) has a condition that "Redistributions of source code must *retain* the above copyright notice, this list of conditions and the following disclaimer" (emphasis added). * Because of that - and it's something that a developer would likely want to discuss with their own legal counsel - in general our recommendation would be not to delete existing notices in third-party files. * That said, this is specific to third-party files where a different party holds the copyright. If the developer or their employer is the copyright holder for a particular file, then they can feel free to decide whether to retain the text for their own license in the file, or whether to replace it with just the short-form SPDX identifier. * In any event, developers will not want to remove copyright notices (e.g., "Copyright (c) 2016 XYZ Company"). Copyright notices are related to, but separate from, the license text itself -- and copyright notices should not be stripped out of files.

tkuhrt (Thu, 01 Jun 2017 18:23:03 GMT):
@cbf , @greg.haskins : Regarding removal of license text and replacing with SPDX short form identifiers, here is what I got from the experts at The Linux Foundation: - Some open source licenses are phrased such that they might not permit removing existing license text. Just as an example, the 3-clause BSD license (https://spdx.org/licenses/BSD-3-Clause.html) has a condition that "Redistributions of source code must *retain* the above copyright notice, this list of conditions and the following disclaimer" (emphasis added). - Because of that - and it's something that a developer would likely want to discuss with their own legal counsel - in general our recommendation would be not to delete existing notices in third-party files. - That said, this is specific to third-party files where a different party holds the copyright. If the developer or their employer is the copyright holder for a particular file, then they can feel free to decide whether to retain the text for their own license in the file, or whether to replace it with just the short-form SPDX identifier. - In any event, developers will not want to remove copyright notices (e.g., "Copyright (c) 2016 XYZ Company"). Copyright notices are related to, but separate from, the license text itself -- and copyright notices should not be stripped out of files.

JonathanLevi (Thu, 01 Jun 2017 18:25:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=rQkv797FrAhXjkAAz) @muralisr Added my vote to the JIRA. Artem, is this still WIP (as note in the Commit MSG) ? Thanks.

JonathanLevi (Thu, 01 Jun 2017 18:25:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=rQkv797FrAhXjkAAz) @muralisr Added my vote to the JIRA. As for the CR, Artem, is this still WIP (as per the note in the Commit MSG) ? Thanks.

muralisr (Thu, 01 Jun 2017 18:26:12 GMT):
@C0rWin ^^^

muralisr (Thu, 01 Jun 2017 18:41:00 GMT):
an easy CR https://gerrit.hyperledger.org/r/#/c/8873/ that has been languishing for a month

cbf (Thu, 01 Jun 2017 18:44:58 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=vF76ZzFAakmkPMG4B) @tkuhrt I have thus far only changed the ASL licensed files we created

cbf (Thu, 01 Jun 2017 18:45:16 GMT):
I will clarify the guidance though - I get the point

cbf (Thu, 01 Jun 2017 18:45:53 GMT):
and as noted, I have NOT nor was I planning on changing any 3rd party license headers

cbf (Thu, 01 Jun 2017 18:46:42 GMT):
btw, we could probably do with another scan of fabric ... I still need to go through the others

greg.haskins (Thu, 01 Jun 2017 19:16:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=MKfhvxi6pPt7zRu7f) @cbf @tkuhrt thanks for explaining...this makes sense.....I agree that we should not (nor was I planning to) change third party

greg.haskins (Thu, 01 Jun 2017 19:18:16 GMT):
@cbf for what its worth, you have my blessing convert any of the files to SPDX that I or my employer have copyright on.

greg.haskins (Thu, 01 Jun 2017 19:18:16 GMT):
@cbf for what its worth, you have my blessing to convert any of the files to SPDX that I or my employer have copyright on.

cbf (Thu, 01 Jun 2017 20:05:08 GMT):
thanks

C0rWin (Thu, 01 Jun 2017 22:31:33 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=vgP4NsdaTWYbdf59M) @JonathanLevi Thanks, I've removed WIP from the title while forgot to change commit message body. Going to update it.

elli-androulaki (Fri, 02 Jun 2017 00:25:38 GMT):
Hi @jimthematrix , @C0rWin have you concluded on this one ? https://jira.hyperledger.org/browse/FAB-3888

mastersingh24 (Fri, 02 Jun 2017 15:09:47 GMT):
Folks - I marked https://jira.hyperledger.org/browse/FAB-4305 as needs review just to be cautious so please take some time and have a look. The corresponding CR is https://gerrit.hyperledger.org/r/#/c/10071/

muralisr (Fri, 02 Jun 2017 15:30:41 GMT):
@mastersingh24 just posted a dumb. q on https://jira.hyperledger.org/browse/FAB-4305

mastersingh24 (Fri, 02 Jun 2017 15:47:01 GMT):
@muralisr - answered - but basically - yeah - we still need this - the grpc upgrade provided the feature and this exploits it

muralisr (Fri, 02 Jun 2017 15:55:52 GMT):
thanks, @mastersingh24

yacovm (Fri, 02 Jun 2017 21:11:28 GMT):
Is there a JIRA item for items post V1.0?

cbf (Sat, 03 Jun 2017 00:20:57 GMT):
just set fixVersion as Future or v1.1

cbf (Sat, 03 Jun 2017 00:21:09 GMT):
not sure what you mean for an item

cbf (Sat, 03 Jun 2017 00:21:13 GMT):
do you mean an epic?

cbf (Sat, 03 Jun 2017 00:21:20 GMT):
multiples of those I suspect

yacovm (Sat, 03 Jun 2017 07:53:07 GMT):
I'm asking- let's say someone wants to propose an addition to fabric for v1.1, how would he/she drive this? I assume open a JIRA item + send to the mailing list, but I was wondering if there is a JIRA item that consolidates features for v1.1.

mastersingh24 (Sat, 03 Jun 2017 09:37:49 GMT):
@yacovm - for now, if someone want's to propose something for the next release, they can use v1.1 as the fix version. Of course we will need to go through everything marked as v1.1 or Future as we start planning the next version(s)

yacovm (Sat, 03 Jun 2017 10:38:04 GMT):
Understood. Thanks @mastersingh24 and @cbf

cbf (Sat, 03 Jun 2017 12:02:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=LfTBu7yX4QSMbyGq8) @yacovm https://github.com/hyperledger/fabric/blob/master/docs/source/CONTRIBUTING.rst#making-featureenhancement-proposals

yacovm (Sat, 03 Jun 2017 12:04:15 GMT):
ok, thanks

cbf (Sat, 03 Jun 2017 12:06:40 GMT):
we merged that a month or more ago as our process. As for collecting them up in a single JIRA, let's explore that for post 1.0. We could, I suppose, use a specific label as we did with the 'review-needed' label as the means of identifying JIRAs that are seeking support. Of course, we could also use the 'Feature' JIRA issue type as a means of tracking new or improved feature proposals and adopt a model of voting on those. In the proposal linked above, I offered "3 or more maintainers" as a lower threshold for embarking on new feature development. We could up the ante, but that might stifle innovation.

cbf (Sat, 03 Jun 2017 12:07:52 GMT):
another thought is we might want to have a higher threshold for API/ABI changes that break fwd/bkwd compatibility

yacovm (Sat, 03 Jun 2017 12:16:06 GMT):
What is the threshold for changes that unknowingly break API/ABI compatibility? ;)

yacovm (Sat, 03 Jun 2017 12:16:06 GMT):
What is the threshold for changes that unknowingly break API/ABI compatibility? ;) x2 i guess...

mastersingh24 (Sat, 03 Jun 2017 12:50:33 GMT):
@cbf - I assume our releases will follow semantic versioning per http://semver.org ? MAJOR:MINOR:PATCH and IF we allowed incompatible / breaking API/ABI changes they would have to go in a MAJOR release?

greg.haskins (Sat, 03 Jun 2017 13:12:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=KS3TiwzRfEn5bjAz4) @yacovm We should be checking for this in a CI integration test

tkuhrt (Sun, 04 Jun 2017 16:06:54 GMT):
@mastersingh24 : Yes. All Hyperledger projects should follow semver.org. See https://wiki.hyperledger.org/community/release_taxonomy for details. This was agreed by TSC sometime in the past.

yacovm (Mon, 05 Jun 2017 08:03:05 GMT):
So... e2e is broken on master, I think. commit hash `5e6b08be8dbb1a0783d3436da01d4f056ff27a85` passes but latest doesn't

yacovm (Mon, 05 Jun 2017 08:03:05 GMT):
So... e2e is broken on master, I think. commit hash `5e6b08be8dbb1a0783d3436da01d4f056ff27a85` passes but the next one `ae71b2f3dc5e10c8f9729418d28acff4481cd62b` breaks it: ``` goroutine 1 [running]: panic(0x8fb1c0, 0xc420014120) /home/yacovm/OBC/go/src/runtime/panic.go:500 +0x1a1 github.com/hyperledger/fabric/common/configtx/tool/localconfig.translatePaths(0xc42013f200, 0x51, 0xc420250060) /home/yacovm/OBC/shared/gopath/src/github.com/hyperledger/fabric/common/configtx/tool/localconfig/config.go:268 +0x61 github.com/hyperledger/fabric/common/configtx/tool/localconfig.(*Profile).completeInitialization(0xc42024e810, 0xc42013f200, 0x51) /home/yacovm/OBC/shared/gopath/src/github.com/hyperledger/fabric/common/configtx/tool/localconfig/config.go:217 +0x13e github.com/hyperledger/fabric/common/configtx/tool/localconfig.Load(0x7fff8cdb1cfc, 0xe, 0x0) /home/yacovm/OBC/shared/gopath/src/github.com/hyperledger/fabric/common/configtx/tool/localconfig/config.go:195 +0x63f main.main() /home/yacovm/OBC/shared/gopath/src/github.com/hyperledger/fabric/common/configtx/tool/configtxgen/main.go:328 +0x4fa ```

yacovm (Mon, 05 Jun 2017 08:08:34 GMT):
I think it's because the e2e uses `release/linux-amd64/bin/cryptogen`

yacovm (Mon, 05 Jun 2017 08:17:11 GMT):
I opened FAB-4360, it's because the `release/linux-amd64/bin/configtxgen` needs to be updated

yacovm (Mon, 05 Jun 2017 08:17:11 GMT):
I opened https://jira.hyperledger.org/browse/FAB-4360, it's because the `release/linux-amd64/bin/configtxgen` needs to be updated

yacovm (Mon, 05 Jun 2017 08:19:10 GMT):
When someone does `make clean` it doesn't do `release-clean` and I think that's the reason it fails

cbf (Mon, 05 Jun 2017 10:46:11 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=PQGpvaRdMqRQ7H668) @tkuhrt we have been all along

mastersingh24 (Mon, 05 Jun 2017 11:11:54 GMT):
[I'll take a look at this one ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ErqtWdAPEEu54Q8uT) @yacovm

yacovm (Mon, 05 Jun 2017 11:14:46 GMT):
sure

mastersingh24 (Mon, 05 Jun 2017 11:20:06 GMT):
@yacovm - https://jira.hyperledger.org/browse/FAB-4360?focusedCommentId=25316&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-25316

yacovm (Mon, 05 Jun 2017 11:22:11 GMT):
That's what I said Gari https://chat.hyperledger.org/channel/fabric-maintainers?msg=TtTQxWHiDazGWMhMv

mastersingh24 (Mon, 05 Jun 2017 11:42:07 GMT):
Right - just updating the JIRA to reflect the conversation

mastersingh24 (Mon, 05 Jun 2017 11:42:31 GMT):
So you'd concur that adding `release-clean` to the `clean` target will suffice?

yacovm (Mon, 05 Jun 2017 11:52:14 GMT):
yeah

tzipih0 (Mon, 05 Jun 2017 14:14:08 GMT):
Has joined the channel.

cbf (Mon, 05 Jun 2017 14:14:58 GMT):
https://chat.hyperledger.org/channel/fabric-release?msg=YKXDWzMJJvwsXS8Zf

jyellick (Mon, 05 Jun 2017 15:03:34 GMT):
@kostas From a config tool perspective and defect perspective, I see fabric-orderer as likely ready for a Tuesday freeze with Thursday release. What do you think from a Kafka perspective?

kostas (Mon, 05 Jun 2017 15:10:37 GMT):
The critical bug for Kafka has had an ETA of 6/9 for 4 days now, so I'm not sure why we're gunning for Thursday. I haven't seen any votes on either FAB-4121 or FAB-4184 (besides yours), so in theory even the path forward hasn't been agreed to by the maintainers. (I say "in theory", because I'm actually working towards these fixes nonetheless — unless someone says stop — since we don't have the luxury of time.)

kostas (Mon, 05 Jun 2017 15:10:37 GMT):
The critical bug for Kafka has had an ETA of 6/9 for 4 days now, so I'm not sure why we're gunning for Thursday. I haven't seen any votes on either FAB-4121 or FAB-4184 (besides yours), so technically even the path forward hasn't been agreed on by the maintainers. (I'm actually working towards these fixes nonetheless — unless someone says stop — since we don't have the luxury of time.)

kostas (Mon, 05 Jun 2017 15:10:37 GMT):
The critical bug for Kafka has had an ETA of 6/9 for 4 days now, so I'm not sure why we're gunning for Thursday. I haven't seen any votes on either ~FAB-4121~ FAB-4357 or FAB-4184 (besides yours), so technically even the path forward hasn't been agreed on by the maintainers. (I'm actually working towards these fixes nonetheless — unless someone says stop — since we don't have the luxury of time.)

kostas (Mon, 05 Jun 2017 15:12:14 GMT):
So yeah, the Thursday goal seems a bit off to me. Will we try to make it? Sure. Will we make it for sure? Who knows.

kostas (Mon, 05 Jun 2017 15:14:12 GMT):
Also note: https://jira.hyperledger.org/browse/FAB-4155 which requires an extension of the ChainSupport interface, and modifications in `orderer/common/deliver` and the orderer plugins.

cbf (Mon, 05 Jun 2017 15:18:30 GMT):
@kostas well, we aren't going to cut a release on a friday, and if we push this to say Tuesday next week, we completely throw out any possibility of having even a RC published in June IMO. I thought that the plan B was doable by tomorrow?

greg.haskins (Mon, 05 Jun 2017 15:20:14 GMT):
I personally am less worried about the class of release (alpha/beta/rc) and more worried about the ceremony of release at this point

kostas (Mon, 05 Jun 2017 15:20:15 GMT):
I don't recall ever giving an ETA for tomorrow even for plan B. The plan B was that — whether we merge the Kafka refactor CR or not — we'll try to have the fix in by the end of the week.

greg.haskins (Mon, 05 Jun 2017 15:20:24 GMT):
so I would suggest perhaps alpha3 _right now_

cbf (Mon, 05 Jun 2017 15:20:53 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Bez7iBGFdtq6EcHyS) @kostas ok I misunderstood

greg.haskins (Mon, 05 Jun 2017 15:20:54 GMT):
and if that means we wait for @kostas fix for a beta1 early next week, i am cool with that

kostas (Mon, 05 Jun 2017 15:21:03 GMT):
As for the rest of your observations, I see them and FWIW I share them.

greg.haskins (Mon, 05 Jun 2017 15:22:11 GMT):
I think we could benefit from having more frequent releases until we hit GA

mastersingh24 (Mon, 05 Jun 2017 15:41:44 GMT):
we should have releases to ensure that we can actually do them propoerly

mastersingh24 (Mon, 05 Jun 2017 15:41:44 GMT):
we should have releases to ensure that we can actually do them properly - at least the most basic pieces

yacovm (Mon, 05 Jun 2017 15:42:51 GMT):
@cbf regarding gossip - I have FAB-3359 (Re-introduce usage of TLS-Unique in gossip handshake) that currently isn't working (trying to figure out why), no idea about ETA

yacovm (Mon, 05 Jun 2017 15:42:51 GMT):
@cbf regarding gossip - I have FAB-3359 (Re-introduce usage of TLS-Unique in gossip handshake) that currently isn't working (I mean, it's working - just preventing all peers to communicate so I guess it is working just not in the way I want it. It did work when I did the change set back then... ) (trying to figure out why), no idea about ETA

yacovm (Mon, 05 Jun 2017 15:42:51 GMT):
@cbf regarding gossip - ~ I have FAB-3359 (Re-introduce usage of TLS-Unique in gossip handshake) that currently isn't working (I mean, it's working - just preventing all peers to communicate so I guess it is working just not in the way I want it. It did work when I did the change set back then... ) (trying to figure out why), no idea about ETA ~

yacovm (Mon, 05 Jun 2017 15:43:06 GMT):
Also not sure when it should be included (for what release)

mastersingh24 (Mon, 05 Jun 2017 15:43:14 GMT):
and frankly there should not be a fight at this point as to what is in / what is not in. sure - we can debate what tag we use (alpha3 versus beta) but then we should set proper fix versions for items to the appropriate tag so we know what we feel is mandatory for any given release target

mastersingh24 (Mon, 05 Jun 2017 15:43:53 GMT):
We are supposed to be able to push out releases at any point - so let's try and only argue about the milestone tag if anything

mastersingh24 (Mon, 05 Jun 2017 15:45:09 GMT):
And lastly, we should simply do a release soon for the sake of doing a release without a mad scramble as seems to happen everytime. And FWIW - I don't actually believe that every single piece can be 100% automated without same human sanity checks

mastersingh24 (Mon, 05 Jun 2017 15:45:24 GMT):
Automating a bad process just makes bad things happen faster

cbf (Mon, 05 Jun 2017 15:55:51 GMT):
@mastersingh24 +100

cbf (Mon, 05 Jun 2017 15:56:07 GMT):
so, alpha3 then?

cbf (Mon, 05 Jun 2017 15:56:25 GMT):
I'd like beta to be 0 highest defects

muralisr (Mon, 05 Jun 2017 16:54:27 GMT):
+1 for alpha3, would be nice to have 0 high defects for beta

weeds (Mon, 05 Jun 2017 17:03:36 GMT):
Chris - I'd like to understand a little about requirements for alpha3 versus beta. Is beta really a statement that we won't be changing apis? is Kostas defect changing APIs? where did the requirement of zero highest defects come out? just trying to understand, or are maintainers just trying to decide that it's a new requirement to have zero?

weeds (Mon, 05 Jun 2017 17:03:36 GMT):
@cbf Chris - I'd like to understand a little about requirements for alpha3 versus beta. Is beta really a statement that we won't be changing apis? is Kostas defect changing APIs? where did the requirement of zero highest defects come out? just trying to understand, or are maintainers just trying to decide that it's a new requirement to have zero?

weeds (Mon, 05 Jun 2017 17:04:22 GMT):
And if we cut Alpha3- would target for beta be next week or ? just trying to understand the "time" frame for these things.

weeds (Mon, 05 Jun 2017 17:17:19 GMT):
or do we have to have 2 weeks between alpha3/beta? and then another 2 weeks betwen beta/release candidate? and then another 2 weeks between release candidate/ final cut of 1.0 (all dependent on defects obviously)?

weeds (Mon, 05 Jun 2017 17:18:46 GMT):
@muralisr Chris said Highest defects- did you really mean high defects Murali?

weeds (Mon, 05 Jun 2017 17:18:46 GMT):
@muralisr Right Murali I think this is why I really wanted Chris to chime in to provide insight, as I continue to be unclear on this. And @kostas to see if we have a real api change if we bring in the highest defect he's working on (ie fab 4136)

muralisr (Mon, 05 Jun 2017 17:19:19 GMT):
so @weeds I was thinking we cut alpha3 keep testing and working the alpha3 and when the other defects (say @kostas 's ) come in, test those and do beta when ready ...basically a rolling, continuous test

muralisr (Mon, 05 Jun 2017 17:19:38 GMT):
right ...sorry, I meant whatever the criteria was

muralisr (Mon, 05 Jun 2017 17:19:38 GMT):
right @weeds ...sorry, I meant whatever the criteria was

muralisr (Mon, 05 Jun 2017 17:22:25 GMT):
my point being if we are going to beta on the heals of alpha3 (basically beta-) do we need 2 week gap between alpha3 and beta ?

greg.haskins (Mon, 05 Jun 2017 18:04:53 GMT):
I dont have an opinion on whether there should be a mandatory time period, but I do think more frequent releases between now and GA would be a good thing

greg.haskins (Mon, 05 Jun 2017 18:05:15 GMT):
they should be painless...if they are not, we should fix that...and doing more of them will shake those issues out

greg.haskins (Mon, 05 Jun 2017 18:05:45 GMT):
that all said, I think another release is overdue if but the fact that I fixed a couple of important things post-alpha2

greg.haskins (Mon, 05 Jun 2017 18:05:45 GMT):
that all said, I think another release is overdue if but for the fact that I fixed a couple of important things post-alpha2

binhn (Mon, 05 Jun 2017 18:11:16 GMT):
maintainers, please vote on the remaining 3 items please https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104 I'd like to have a resolution for them by end of today so we can wrap them up for the beta hopefully this week

JonathanLevi (Mon, 05 Jun 2017 18:19:52 GMT):
BTW: I, too, believe that there are many good reasons for releasing *v1.0.0-alpha3* in the coming days.

JonathanLevi (Mon, 05 Jun 2017 18:21:06 GMT):
We should (all) really practice more frequent releases... along with an "axe" that says: "No more changes. The new good stuff will get packaged and shipped in the next round."

JonathanLevi (Mon, 05 Jun 2017 18:21:36 GMT):
Without that being interpreted as a "bad thing".

JonathanLevi (Mon, 05 Jun 2017 18:40:12 GMT):
FYI: https://jira.hyperledger.org/browse/FAB-4212

troyronda (Mon, 05 Jun 2017 18:51:40 GMT):
hey guys with the relabel from beta to alpha3, are there anticipated changes that would affect SDK development?

weeds (Mon, 05 Jun 2017 19:06:48 GMT):
i think doing a release is good- I just can't tell is it really alpha3 or is it beta? and why?

weeds (Mon, 05 Jun 2017 19:07:56 GMT):
this is why my question up above

mastersingh24 (Mon, 05 Jun 2017 19:29:02 GMT):
[There better not be! ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=XJbAvXm83opekMMWv) @troyronda

mastersingh24 (Mon, 05 Jun 2017 19:30:37 GMT):
@troyronda - the only thing I can think of is https://jira.hyperledger.org/browse/FAB-4136 which would not be a major change as it's better handling of potential issues with the orderer, kafka and channel(s)

markparz (Mon, 05 Jun 2017 19:52:52 GMT):
can someone merge Arnaud's https://gerrit.hyperledger.org/r/#/c/9469/ for https://jira.hyperledger.org/browse/FAB-3906

markparz (Mon, 05 Jun 2017 19:53:03 GMT):
@simsc^^ that's what you want?

simsc (Mon, 05 Jun 2017 20:14:46 GMT):
sorry should be on fabric-pr-review channel (i gave you wrong channel)

simsc (Mon, 05 Jun 2017 20:14:53 GMT):
i posted it there on your behalf

cbf (Mon, 05 Jun 2017 20:42:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=hd2ihxjg5dvTa2eLm) @weeds YES, Absolutely.. NO MORE API/ABI changes after beta

cbf (Mon, 05 Jun 2017 20:43:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=WXEPYoypMwEYmEFuZ) @weeds assuming we could get the Kafka changes in and there was some progress on the docs/e2e work, I think beta the following week is doable

cbf (Mon, 05 Jun 2017 20:44:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=uHLvhPcg23fxpybYv) @weeds the release criteria only stipulate 2 weeks since last RC release for 1.0.0

cbf (Mon, 05 Jun 2017 20:47:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=XJbAvXm83opekMMWv) @troyronda I believe, but @jimthematrix needs to verify, that all the SDK changes are accounted for

cbf (Mon, 05 Jun 2017 20:48:13 GMT):
hence there should be no SDK changes aside from bug fixes and those should not affect the API

joe-alewine (Mon, 05 Jun 2017 20:52:12 GMT):
Has joined the channel.

weeds (Mon, 05 Jun 2017 21:13:06 GMT):
@cbf So i saw on Fabric-release we plan to cut a release this week- but in your post you put alpha 3 and beta- can you clarify?

weeds (Mon, 05 Jun 2017 21:13:12 GMT):
Also are we trying to cut tomorrow or end of week?

weeds (Mon, 05 Jun 2017 21:15:19 GMT):
i will post this in the other channel also

cbf (Mon, 05 Jun 2017 21:50:50 GMT):
We will cut a release this week - whether we call it alpha3 or beta TBD

cbf (Mon, 05 Jun 2017 22:50:32 GMT):
@here have been going back and forth on the topic of "alpha3" or "beta" this week, and if alpha3 when will we cut beta?

cbf (Mon, 05 Jun 2017 22:51:23 GMT):
Talking it over with a few folk, including @mastersingh24 and @JonathanLevi and @greg.haskins seems like there is broad consensus we should do frequent releases for the practice

cbf (Mon, 05 Jun 2017 22:52:06 GMT):
also general concern that we aren't really at beta - we have a couple of "highest" defects outstanding and the docs/getting started still not ready

cbf (Mon, 05 Jun 2017 22:52:06 GMT):
also general concern that we aren't really at beta - we have a couple of "highest" defects outstanding and the new docs/getting started still not ready

cbf (Mon, 05 Jun 2017 22:52:22 GMT):
SO...

cbf (Mon, 05 Jun 2017 22:53:55 GMT):
I say we cut alpha3 Thursday - with a merge freeze after tomorrow EOB lasting through Wednesday, and push the release on Thursday early, giving ourselves time to address any issues... Gerrit merging can resume after the release is cut

cbf (Mon, 05 Jun 2017 22:53:55 GMT):
I propose we cut alpha3 Thursday - with a merge freeze after tomorrow EOB lasting through Wednesday, and push the release on Thursday early, giving ourselves time to address any issues... Gerrit merging can resume after the release is cut

cbf (Mon, 05 Jun 2017 22:55:17 GMT):
then, I propose that we push HARD to prepare for beta NEXT Thursday with the same pattern - merge freeze Tuesday EOB through release (in both cases, excepting emergency patches agreed by 5 or more maintainers)

cbf (Mon, 05 Jun 2017 22:55:48 GMT):
this means we need the kafka fixes and we need to have a reworked GS and e2e by NEXT TUESDAY

cbf (Mon, 05 Jun 2017 22:57:44 GMT):
I don't think we have any must-have patches for alpha3 except the release notes and release tasks - though I think that IFF we are going to merge the Kafka test coverage (cough) CR we should do so for alpha3 so we can get some hard core testing on it

cbf (Mon, 05 Jun 2017 22:57:59 GMT):
@here who's in agreement?

mastersingh24 (Mon, 05 Jun 2017 22:59:20 GMT):
@cbf - works for me

yacovm (Mon, 05 Jun 2017 23:00:36 GMT):
> reworked GS ?

cbf (Mon, 05 Jun 2017 23:01:17 GMT):
@yacovm see @odowdaibm plan in #fabric-documentation

odowdaibm (Mon, 05 Jun 2017 23:01:17 GMT):
Has joined the channel.

C0rWin (Mon, 05 Jun 2017 23:08:29 GMT):
@cbf are we going to have weekly releases?

cbf (Mon, 05 Jun 2017 23:08:44 GMT):
we will see

cbf (Mon, 05 Jun 2017 23:09:01 GMT):
we SHOULD be able to do that and maybe without the merge freeze part

C0rWin (Mon, 05 Jun 2017 23:09:53 GMT):
do we have indication of successful release?

C0rWin (Mon, 05 Jun 2017 23:11:30 GMT):
I understand why we'd better to release more frequently, I guess one obvious reason to be able to run it smoothly over time

C0rWin (Mon, 05 Jun 2017 23:12:08 GMT):
but how we define successful release?

cbf (Mon, 05 Jun 2017 23:19:36 GMT):
one that isn't broken out the gate?

odowdaibm (Tue, 06 Jun 2017 08:17:05 GMT):
@yacovm hi gimme a ping when you're next online, and we can chat - thx

paapighoda (Tue, 06 Jun 2017 10:30:56 GMT):
Has joined the channel.

mastersingh24 (Tue, 06 Jun 2017 11:56:04 GMT):
[ GS = getting started ;)](https://chat.hyperledger.org/channel/fabric-maintainers?msg=SG9cmE9cJkg6Q2jnG) @yacovm

mastersingh24 (Tue, 06 Jun 2017 11:56:04 GMT):
[ GS = getting started ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=SG9cmE9cJkg6Q2jnG) @yacovm

yacovm (Tue, 06 Jun 2017 11:56:29 GMT):
Yeah thanks, @odowdaibm already told me in PM

mastersingh24 (Tue, 06 Jun 2017 11:57:07 GMT):
It also equals "Gari Singh" but that project is beyond rework ;)

cbf (Tue, 06 Jun 2017 11:57:31 GMT):
hehe

yacovm (Tue, 06 Jun 2017 11:57:34 GMT):
haha

dave.enyeart (Tue, 06 Jun 2017 12:32:42 GMT):
I've just submitted maintainer nomination for Manish Sethi: https://gerrit.hyperledger.org/r/#/c/10209/ Manish has been the principal developer of the Fabric ledger in 0.6 and 1.0 releases. Manish consistently performs deep and thorough code reviews and coaches junior members of the community. I think Manish would be a great addition.

dave.enyeart (Tue, 06 Jun 2017 12:34:47 GMT):
I will be out of office for a couple key periods of 1.0 release. Manish will be a wonderful steward of ledger component.

binhn (Tue, 06 Jun 2017 13:22:30 GMT):
@cbf we should work out a process such that we don't have to freeze for days -- could everything be built off the release tag?

cbf (Tue, 06 Jun 2017 13:28:31 GMT):
@binhn we've been there before and had a huge debate and agreed to defer post 1.0

cbf (Tue, 06 Jun 2017 13:29:05 GMT):
no one said anything about freeze for days, I asked for a DAY

binhn (Tue, 06 Jun 2017 13:30:09 GMT):
i don't mean another branch, but would the tag be enough to drive the scripts

cbf (Tue, 06 Jun 2017 13:30:24 GMT):
that would be a change to CI

cbf (Tue, 06 Jun 2017 13:30:24 GMT):
no

markparz (Tue, 06 Jun 2017 13:32:04 GMT):
@nickgaski can u get with @yacovm on getting started I know u already have done a lot there too

yacovm (Tue, 06 Jun 2017 13:32:51 GMT):
what?

cbf (Tue, 06 Jun 2017 13:32:54 GMT):
@markparz maybe wrong channel?

yacovm (Tue, 06 Jun 2017 13:33:02 GMT):
I didn't do anything on GS @markparz

markparz (Tue, 06 Jun 2017 13:33:23 GMT):
@yacovm the rework u did or r doing is that for alpha3? @nickgaski is working the component by component bring up for a new network

yacovm (Tue, 06 Jun 2017 13:33:47 GMT):
I am not doing anything of this kind

markparz (Tue, 06 Jun 2017 13:33:49 GMT):
I saw GS convo above

yacovm (Tue, 06 Jun 2017 13:33:49 GMT):
you're mistaken

markparz (Tue, 06 Jun 2017 13:34:17 GMT):
What is GS... is it Gari Singh?

markparz (Tue, 06 Jun 2017 13:34:19 GMT):
Lol

markparz (Tue, 06 Jun 2017 13:35:07 GMT):
Ignore then I got bad info and misread

markparz (Tue, 06 Jun 2017 13:35:18 GMT):
If u aren't

markparz (Tue, 06 Jun 2017 13:35:22 GMT):
No worries

dave.enyeart (Tue, 06 Jun 2017 13:54:52 GMT):
@cbf There is a field in Jira called Security Level with a value like "Not a security issue". We don't seem to be able to edit this field to indicate if a bug is in fact a security issue. For example https://jira.hyperledger.org/browse/FAB-4252

dave.enyeart (Tue, 06 Jun 2017 13:55:07 GMT):
can you check on how to edit this field?

cbf (Tue, 06 Jun 2017 13:55:19 GMT):
ask @rjones

cbf (Tue, 06 Jun 2017 13:55:44 GMT):
I believe it is so that when set, only a select few can see the issue

cbf (Tue, 06 Jun 2017 13:55:51 GMT):
(well, I am actually positive)

cbf (Tue, 06 Jun 2017 13:56:00 GMT):
how it is set and by whom I don't know

cbf (Tue, 06 Jun 2017 13:56:38 GMT):
@mastersingh24 is on the security review team - maybe he can set it, but again, when/if he does, only he and a select few can see the issue

FenglianXu (Tue, 06 Jun 2017 14:12:24 GMT):
Has joined the channel.

binhn (Tue, 06 Jun 2017 15:36:35 GMT):
only 1 item left on the voting board https://jira.hyperledger.org/browse/FAB-4357 that needs 1 more vote

rjones (Tue, 06 Jun 2017 18:13:42 GMT):
@dave.enyeart is 4252 a security issue? do you need to watch it?

dave.enyeart (Tue, 06 Jun 2017 18:29:42 GMT):
I don't need to watch 4252, it does not require extra attention. But it is a security related defect, and therefore we wanted to understand how to change it away from "Not a security issue"

dave.enyeart (Tue, 06 Jun 2017 18:29:42 GMT):
@rjones I don't need to watch 4252, it does not require extra attention. But it is a security related defect, and therefore we wanted to understand how to change it away from "Not a security issue"

rjones (Tue, 06 Jun 2017 18:35:12 GMT):
@dave.enyeart the person that filed it could have set that

dave.enyeart (Tue, 06 Jun 2017 18:35:57 GMT):
ok, i'll ask them to update it. for future reference, who else can update it (if the submitter does not respond)?

rjones (Tue, 06 Jun 2017 18:36:35 GMT):
I think cbf and our security maven have edit permissions, I would need to look

dave.enyeart (Tue, 06 Jun 2017 18:37:19 GMT):
no rush, just wanted to make sure we understood operating procedures as we enter critical 1.0 release period

dave.enyeart (Tue, 06 Jun 2017 18:38:06 GMT):
i suspect security related bugs will require special attention during shutdown phase and in release notes

rickr (Tue, 06 Jun 2017 19:30:22 GMT):
Hi @cbf What is the status of Java SDK in regard to things like voting ? It has it's own set of maintainers like GO and python SDKs so for any voting on features changes that should be the maintainers ? I've never voted in any Fabric Node SDKs seeing I'm not a maintainer in those projects.

JonathanLevi (Tue, 06 Jun 2017 19:33:15 GMT):
@rickr, please don't write in this channel.

rickr (Tue, 06 Jun 2017 19:42:32 GMT):
Hi @cbf What are the rules for voting ? I'm not a maintainer of the Fabric or Node SDK so never voted on issues there. Similarly like GO or Python SDK I think the maintainers of those project should do the voting on issues concerning their projects like what feature and changes should still go in.

JonathanLevi (Tue, 06 Jun 2017 19:46:24 GMT):
BTW: Can we please this maintainers channel, as intended?

JonathanLevi (Tue, 06 Jun 2017 19:46:24 GMT):
BTW: Can we please use this maintainers channel, as it is intended?

JonathanLevi (Tue, 06 Jun 2017 19:46:36 GMT):
You can use the release channel, the fabric channel, or write to Chris directly.

JonathanLevi (Tue, 06 Jun 2017 19:46:46 GMT):
@rickr

JonathanLevi (Tue, 06 Jun 2017 19:46:46 GMT):
@rickr, it's not the first time this is being asked.

JonathanLevi (Tue, 06 Jun 2017 19:47:51 GMT):
But to answer your question: yes, the project is managed and maintained by the maintainers.

rickr (Tue, 06 Jun 2017 19:48:10 GMT):
I guess that answer my questions .. Not allowed here :)

JonathanLevi (Tue, 06 Jun 2017 19:48:16 GMT):
Everyone can chime in, e.g., on JIRA tickets, the (other, ahem ;-) channels

JonathanLevi (Tue, 06 Jun 2017 19:48:16 GMT):
Everyone can chime in, e.g., on JIRA tickets, the (other, ahem ;-) ) channels

JonathanLevi (Tue, 06 Jun 2017 19:48:37 GMT):
But at the end of the day, yes, that's correct. The project is governed by elected set of maintainers.

JonathanLevi (Tue, 06 Jun 2017 19:50:18 GMT):
I don't know if people missed that, there are many cases where even the maintainers do not all agree unequivocally... in these cases we simply vote.

rickr (Tue, 06 Jun 2017 19:50:21 GMT):
thx you've answered my question .. I apologize for the spam :flushed:

JonathanLevi (Tue, 06 Jun 2017 19:50:57 GMT):
No problem. This is not spam, it's just a "maintainer's channel" as advertised above.

JonathanLevi (Tue, 06 Jun 2017 19:50:57 GMT):
No problem. This is not spam, it's just that *this is the only* "maintainer's channel" as advertised above.

JonathanLevi (Tue, 06 Jun 2017 19:51:31 GMT):
We do have that "governance model" advertised in several places - on the wiki, etc.

JonathanLevi (Tue, 06 Jun 2017 19:52:12 GMT):
Trying to keep this channel more of an open channel for others to read...

cbf (Tue, 06 Jun 2017 20:46:27 GMT):
@here ok, so where are we? do we release a beta or alpha3 - I think that the argument that beta demonstrates progress makes some sense

C0rWin (Tue, 06 Jun 2017 20:46:56 GMT):
I think we still in alpha stage

C0rWin (Tue, 06 Jun 2017 20:47:41 GMT):
So I've vote for alpha3 rather than beta, while IMO naming is no so important as delivered content

C0rWin (Tue, 06 Jun 2017 20:47:41 GMT):
So I'd vote for alpha3 rather than beta, while IMO naming is no so important as delivered content

mastersingh24 (Tue, 06 Jun 2017 21:00:58 GMT):
My vote is for "beta" because I honestly think we need to demonstrate progress and we need to be serious about moving on to release candidates and not allow further churn

mastersingh24 (Tue, 06 Jun 2017 21:01:19 GMT):
I know we are behind on a few things for a proper beta, but I don't think we need an alpha3

yacovm (Tue, 06 Jun 2017 21:12:23 GMT):
I have a gut feeling, that we don't really know at what stage we are at this point. Every day, new bugs are discovered. Can't we delay the decision for a few days?

yacovm (Tue, 06 Jun 2017 21:15:22 GMT):
> My vote is for "beta" because I honestly think we need to demonstrate progress Let's say we release beta. How do we show progress? What is the proof of progress? BTW - Do we have a full guide on how to deploy and customize fabric from scratch? (I honestly don't know) Not a guide that says: "copy paste these commands and this would run a script that does something" I mean a full, descriptive guide that after reading it, one can setup an environment on his/her own.

rjones (Tue, 06 Jun 2017 21:16:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=EcadLkmEfRpsmN3uS) @yacovm I would expect something shaped like a gate or a bug bar that dictates project status (alpha, beta, etc).

cbf (Tue, 06 Jun 2017 21:18:04 GMT):
@here we can defer the decision on what we call it until tomorrow afternoon - I tend to think that at this point, calling it beta would be fine --- I have been thinking about this a lot

cbf (Tue, 06 Jun 2017 21:18:13 GMT):
if we have major issues, we do another beta

cbf (Tue, 06 Jun 2017 21:18:30 GMT):
we have done a good job driving down the defect count

cbf (Tue, 06 Jun 2017 21:18:37 GMT):
though they are still coming in

cbf (Tue, 06 Jun 2017 21:18:51 GMT):
but maybe beta will draw more people to try the current rev

dave.enyeart (Tue, 06 Jun 2017 21:19:03 GMT):
wikipedia says : Beta phase generally begins when the software is feature complete but likely to contain a number of known or unknown bugs.

dave.enyeart (Tue, 06 Jun 2017 21:19:09 GMT):
so i would agree with label beta

cbf (Tue, 06 Jun 2017 21:19:36 GMT):
yes, and trust me, we ARE feature complete people

cbf (Tue, 06 Jun 2017 21:19:46 GMT):
even if we aren't (wink wink)

cbf (Tue, 06 Jun 2017 21:21:14 GMT):
so, we have @mastersingh24 @dave.enyeart @JonathanLevi @cbf for beta

cbf (Tue, 06 Jun 2017 21:21:35 GMT):
@C0rWin alpha3, @yacovm on the fence

C0rWin (Tue, 06 Jun 2017 21:22:03 GMT):
Actually I do not mind how we call it

yacovm (Tue, 06 Jun 2017 21:22:18 GMT):
Yep, exactly. I'm good both ways, just concerned that we have something, somewhere that we don't know about and we will release beta and then "uh oh".

cbf (Tue, 06 Jun 2017 21:22:31 GMT):
@muralisr @jyellick @kostas @binhn ?

C0rWin (Tue, 06 Jun 2017 21:22:36 GMT):
I'm for moving into rapid and painless releases and decent content

cbf (Tue, 06 Jun 2017 21:22:43 GMT):
indeed me too

muralisr (Tue, 06 Jun 2017 21:23:23 GMT):
beta - as long as we are rolling fixes and tests

kostas (Tue, 06 Jun 2017 21:23:30 GMT):
Good both ways. Beta doesn't seem too far fetched.

cbf (Tue, 06 Jun 2017 21:23:32 GMT):
@greg.haskins ?

greg.haskins (Tue, 06 Jun 2017 21:24:13 GMT):
im fine with whatever you guys decide

greg.haskins (Tue, 06 Jun 2017 21:24:24 GMT):
i just want a new tag to reference

cbf (Tue, 06 Jun 2017 21:24:28 GMT):
;-)

cbf (Tue, 06 Jun 2017 21:25:18 GMT):
@jimthematrix ?

cbf (Tue, 06 Jun 2017 21:25:35 GMT):
@smithbk ?

C0rWin (Tue, 06 Jun 2017 21:26:04 GMT):
is that possible to define groups in rocket chat like in slack?

cbf (Tue, 06 Jun 2017 21:26:11 GMT):
I really wish there was aliasing eg @maintainers

jimthematrix (Tue, 06 Jun 2017 21:26:24 GMT):
hi Chris

C0rWin (Tue, 06 Jun 2017 21:26:26 GMT):
so to say reference with @maintainers and everyone in the list will got notified?

jimthematrix (Tue, 06 Jun 2017 21:26:34 GMT):
need me to vote on something?

cbf (Tue, 06 Jun 2017 21:26:43 GMT):
alpha3 or beta?

jimthematrix (Tue, 06 Jun 2017 21:27:22 GMT):
oh i think beta to get it over with

cbf (Tue, 06 Jun 2017 21:27:29 GMT):
heh

jimthematrix (Tue, 06 Jun 2017 21:27:32 GMT):
we can also do beta2, beta3 if needed right?

cbf (Tue, 06 Jun 2017 21:27:37 GMT):
yep

jimthematrix (Tue, 06 Jun 2017 21:28:09 GMT):
i think it sends the right signal to the community

jimthematrix (Tue, 06 Jun 2017 21:28:31 GMT):
have been hearing ppl anxiously waiting for a beta and jump in

jimthematrix (Tue, 06 Jun 2017 21:28:54 GMT):
it'd be good for collecting better feedback if more ppl are jumping in

cbf (Tue, 06 Jun 2017 21:29:09 GMT):
ok, sounds like a plan

dave.enyeart (Tue, 06 Jun 2017 21:29:10 GMT):
yep, beta says "we are feature complete, please provide feedback"

jimthematrix (Tue, 06 Jun 2017 21:29:41 GMT):
right

cbf (Tue, 06 Jun 2017 21:31:16 GMT):
I will need to rejigger my release notes.... @jimthematrix @smithbk @binhn please review the prose in my open CRs for alpha3 ... I'll submit new patchsets changing the name

cbf (Tue, 06 Jun 2017 21:31:44 GMT):
https://gerrit.hyperledger.org/r/#/c/10153/

jimthematrix (Tue, 06 Jun 2017 21:31:56 GMT):
will do

cbf (Tue, 06 Jun 2017 21:31:58 GMT):
https://gerrit.hyperledger.org/r/#/c/10157/

cbf (Tue, 06 Jun 2017 21:32:02 GMT):
https://gerrit.hyperledger.org/r/#/c/10159/

cbf (Tue, 06 Jun 2017 21:32:06 GMT):
https://gerrit.hyperledger.org/r/#/c/10161/

cbf (Tue, 06 Jun 2017 21:32:32 GMT):
we need ppl testing and reviewing the docs etc tomorrow

cbf (Tue, 06 Jun 2017 21:32:38 GMT):
that needs to be our focus

C0rWin (Tue, 06 Jun 2017 21:45:06 GMT):
is there any code freeze involved now?

C0rWin (Tue, 06 Jun 2017 21:45:57 GMT):
should we have more restrictive policies to have CRs in?

yacovm (Tue, 06 Jun 2017 21:52:23 GMT):
I thought we are continuing with the 3-types- strategy?

smithbk (Tue, 06 Jun 2017 21:53:04 GMT):
beta seems OK to me, given there may be multiple

yacovm (Tue, 06 Jun 2017 21:54:22 GMT):
@smithbk is fabric-ca feature complete ?

yacovm (Tue, 06 Jun 2017 21:54:34 GMT):
I saw a very large amount of change sets there

yacovm (Tue, 06 Jun 2017 21:54:50 GMT):
The churn seemed higher than fabric lately

smithbk (Tue, 06 Jun 2017 21:55:20 GMT):
yes, it is feature complete

smithbk (Tue, 06 Jun 2017 21:56:23 GMT):
all have been for bugs

lehors (Tue, 06 Jun 2017 22:05:18 GMT):
@cbf small question: does the change to calling the release beta means FAB-4212 is renamed and so is FAB-4379 or do you close the former and switch to the latter?

lehors (Tue, 06 Jun 2017 22:05:29 GMT):
either way some update needs to be made

cbf (Tue, 06 Jun 2017 22:05:41 GMT):
yes, will be renaming that for rc1 or whatever comes next

cbf (Wed, 07 Jun 2017 00:17:22 GMT):
https://jira.hyperledger.org/browse/FAB-4379 beta task updated

cbf (Wed, 07 Jun 2017 00:17:34 GMT):
FAB-4212 closed

JonathanLevi (Wed, 07 Jun 2017 04:42:15 GMT):
https://gerrit.hyperledger.org/r/#/c/10247

JonathanLevi (Wed, 07 Jun 2017 04:42:46 GMT):
There is an update here to the CONTRIBUTING.rst - please can we all take a look.

JonathanLevi (Wed, 07 Jun 2017 04:43:08 GMT):
(Do not want to make a big "scene"... but just let us know if there's an issue there, please)

kelvinzhong (Wed, 07 Jun 2017 06:55:31 GMT):
hi all, during my coding of the chaincode, i found that the implementation of range query is quite not convenient for using, as the range query could not set a limitation for the return set, neither could get the return set in ascending or descending order. For most of time, we have no idea how many instance exist between the start key to end key for the range query, (e.g. if the key structure like "user id+user transaction id", and we need to get all user transactions, currently we could use range query start from "user id" to "user id + ZZZ", but what if the user have ten thousand of transactions? It's bad to return such a large value at one time, unless we add a counter inside the key like "user id + counter + transaction id", so we could get thirty transaction by query start from "userA-00-" to "userA-30-", but this is awful if we need to do that in application level!)

mastersingh24 (Wed, 07 Jun 2017 08:45:53 GMT):
[ I moved this to the #fabric-ledger channel](https://chat.hyperledger.org/channel/fabric-maintainers?msg=5uYXJBKmgg75TiqSm) @kelvinzhong

kelvinzhong (Wed, 07 Jun 2017 08:46:33 GMT):
@mastersingh24 many thanks~

cbf (Wed, 07 Jun 2017 09:23:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=NMtBMJeJumw8JqLmj) @JonathanLevi just moved a file to make the structure flatter - I went in to change the GS per the JIRA but there was a lot of placeholder content that just cluttered things and then there was also a lot of obsolete content

yacovm (Wed, 07 Jun 2017 09:24:16 GMT):
Hi all. I think that https://gerrit.hyperledger.org/r/#/c/9087/ needs a review-needed label, what do you think?

cbf (Wed, 07 Jun 2017 09:26:34 GMT):
review-needed for mainline code... this is an example ... it needs review and careful scrutiny but not much risk to the code base

yacovm (Wed, 07 Jun 2017 09:31:55 GMT):
but it changes e2e @cbf

yacovm (Wed, 07 Jun 2017 09:32:01 GMT):
and we use e2e for everything

yacovm (Wed, 07 Jun 2017 09:32:06 GMT):
starting from CI to QA

cbf (Wed, 07 Jun 2017 09:32:21 GMT):
in CI it is in a different folder

yacovm (Wed, 07 Jun 2017 09:32:48 GMT):
so it won't be eventually copied there?

cbf (Wed, 07 Jun 2017 09:32:58 GMT):
that I don't know

yacovm (Wed, 07 Jun 2017 09:33:14 GMT):
all right then

cbf (Wed, 07 Jun 2017 09:33:36 GMT):
but that said, we are in merge lockdown ... i was just about to send a note

cbf (Wed, 07 Jun 2017 09:33:53 GMT):
think that there's the build failure to resolve and then the items for the release only

yacovm (Wed, 07 Jun 2017 09:35:01 GMT):
since when we are in a merge lockdown?

yacovm (Wed, 07 Jun 2017 09:35:14 GMT):
and how can we be in a merge lockdown? We're supposed to bring the bug count in our components to 0

mastersingh24 (Wed, 07 Jun 2017 09:43:35 GMT):
[ I gave it a -2 - been meaning to do that. It does not belong in the e2e - especially the one we use for our "sample" ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=pZYi9h4fFnP5gJA5d) @yacovm

mastersingh24 (Wed, 07 Jun 2017 09:43:35 GMT):
[ I gave it a -2 - been meaning to do that. It does not belong in the e2e - especially the one we use for our sample ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=pZYi9h4fFnP5gJA5d) @yacovm

mastersingh24 (Wed, 07 Jun 2017 09:45:58 GMT):
@yacovm - we are trying to put out a release. holding off merges for a bit should not hurt anything. of course you can still fix bugs - they just won't be merged until we cut a release tag ;)

mastersingh24 (Wed, 07 Jun 2017 09:46:06 GMT):
(as you know)

cbf (Wed, 07 Jun 2017 09:50:57 GMT):
@yacov just for the day to settle CI and prepare for the beta

yacovm (Wed, 07 Jun 2017 09:51:02 GMT):
yeah I'm ok with that. we have no more interesting/critical bugs anyway

yacovm (Wed, 07 Jun 2017 09:51:17 GMT):
But what about the kafka issue?

cbf (Wed, 07 Jun 2017 09:51:30 GMT):
first things first, fix CI

cbf (Wed, 07 Jun 2017 09:51:31 GMT):
sigh

mastersingh24 (Wed, 07 Jun 2017 09:59:30 GMT):
@yacovm - by Kafka, you mean this one: https://jira.hyperledger.org/browse/FAB-4136

yacovm (Wed, 07 Jun 2017 10:00:14 GMT):
This + the one with the 503 and failing over to another OSN when OSN is having problems

mastersingh24 (Wed, 07 Jun 2017 10:00:30 GMT):
https://jira.hyperledger.org/browse/FAB-4155

yacovm (Wed, 07 Jun 2017 10:00:51 GMT):
On 2nd thought, it's just HA, I guess we can do a beta without it

mastersingh24 (Wed, 07 Jun 2017 10:01:29 GMT):
Indeed and most people are using Solo anyway (which should be the case since people are still in development mode anyway)

C0rWin (Wed, 07 Jun 2017 10:01:53 GMT):
@yacovm is this https://jira.hyperledger.org/browse/FAB-4155?jql=reporter%20=%20ptippett%20 a second one you referred?

yacovm (Wed, 07 Jun 2017 10:02:07 GMT):
yeah

mastersingh24 (Wed, 07 Jun 2017 10:29:27 GMT):
@cbf - do we want this one in if it passes CI - https://gerrit.hyperledger.org/r/#/c/10239/ (the final piece in all tools being able to print version info)

mastersingh24 (Wed, 07 Jun 2017 10:30:18 GMT):
I've verified it locally already

cbf (Wed, 07 Jun 2017 10:36:24 GMT):
possibly, yes will need to get @JonathanLevi buyin

JonathanLevi (Wed, 07 Jun 2017 13:14:43 GMT):
Regarding https://gerrit.hyperledger.org/r/#/c/10239 - I'm in.

cbf (Wed, 07 Jun 2017 14:29:56 GMT):
+1

dave.enyeart (Wed, 07 Jun 2017 15:02:15 GMT):
It looks like Manish has the required maintainer votes: https://gerrit.hyperledger.org/r/#/c/10209/ @cbf @rjones can we merge and flip the switch (assuming it doesn't interfere with other release activities that is)

weeds (Wed, 07 Jun 2017 15:02:49 GMT):
Congrats @manish-sethi

manish-sethi (Wed, 07 Jun 2017 15:02:49 GMT):
Has joined the channel.

manish-sethi (Wed, 07 Jun 2017 15:03:47 GMT):
Thanks @weeds

jyellick (Wed, 07 Jun 2017 15:22:55 GMT):
Bugs reported against `configtxgen` and `configtxlator` are usually being filed against the `fabric-orderer` component. I was thinking that these should really be being filed against `fabric-tools`, does anyone object to this?

jimthematrix (Wed, 07 Jun 2017 15:31:19 GMT):
i think that makes sense Jason

jimthematrix (Wed, 07 Jun 2017 15:43:07 GMT):
congrats @manish-sethi

manish-sethi (Wed, 07 Jun 2017 15:47:15 GMT):
Thanks @jimthematrix

rjones (Wed, 07 Jun 2017 15:59:18 GMT):
@dave.enyeart once it's merged I'll edit the LDAP group

rjones (Wed, 07 Jun 2017 20:23:59 GMT):
could I get one more +2 and a merge for this trivial bookkeeping change? https://gerrit.hyperledger.org/r/#/c/10293

yacovm (Wed, 07 Jun 2017 20:26:03 GMT):
@JonathanLevi ^

rjones (Wed, 07 Jun 2017 20:27:18 GMT):
thank you @manish-sethi :)

JonathanLevi (Wed, 07 Jun 2017 20:27:34 GMT):
Yes, done. @manish-sethi - welcome to the jungle ;-)

manish-sethi (Wed, 07 Jun 2017 20:32:15 GMT):
Thanks @rjones and @JonathanLevi

silliman (Thu, 08 Jun 2017 14:56:38 GMT):
Has left the channel.

cbf (Thu, 08 Jun 2017 23:11:31 GMT):
Why are there Improvements in 'review-needed'? There are no more code changes that aren't a) bug fixes or b) new tests and review-needed tag is for evaluating those that modify production code

cbf (Thu, 08 Jun 2017 23:12:41 GMT):
There are ONLY to be "Improvements" to documentation and tests - we agreed to this

cbf (Thu, 08 Jun 2017 23:12:59 GMT):
so why are there all of a sudden 3 improvements in review-needed???

cbf (Thu, 08 Jun 2017 23:13:04 GMT):
@here ^^

kelvinzhong (Fri, 09 Jun 2017 02:19:54 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/

kelvinzhong (Fri, 09 Jun 2017 02:20:04 GMT):
seems the read the docs is broken

weeds (Fri, 09 Jun 2017 07:39:48 GMT):
Agree- we need to be extremely careful

cbf (Fri, 09 Jun 2017 10:20:15 GMT):
@here merging may be resumed

weeds (Fri, 09 Jun 2017 11:20:42 GMT):
Thanks Chris and Jonathan for leading the release effort- lots of hard work got put in,.. and appreciate it!

greg.haskins (Fri, 09 Jun 2017 13:09:25 GMT):

Message Attachments

greg.haskins (Fri, 09 Jun 2017 13:11:12 GMT):
Im struggling to figure out how to quantify what those vulneabilities are, but they seem to originate in the base image (https://hub.docker.com/r/hyperledger/fabric-baseos/tags/) so I am guessing its an upstream ubuntu/debian issue

greg.haskins (Fri, 09 Jun 2017 13:11:43 GMT):
@tkuhrt ^^^

greg.haskins (Fri, 09 Jun 2017 13:12:32 GMT):
I can try rebuilding+updating baseos and pushing it to my local namespace and see if those errors go away

greg.haskins (Fri, 09 Jun 2017 13:13:13 GMT):
if I had to guess, I would guess that whatever they are are not likely to actually impact us though

greg.haskins (Fri, 09 Jun 2017 13:13:49 GMT):
(e.g. if base ubuntu had a known CVE in sshd, but we dont run it, does it matter?

tkuhrt (Fri, 09 Jun 2017 13:31:31 GMT):
@greg.haskins : I cannot see the scan results as a non-logged in user. I will need to get @rjones to add my account (once I create one) on docker to have access to what you are seeing. Does the interface tell you more about the vulnerabilities?

greg.haskins (Fri, 09 Jun 2017 15:04:57 GMT):
@tkuhrt the interface is not very forthcoming about specifics

greg.haskins (Fri, 09 Jun 2017 15:05:14 GMT):
nothing is clickable, so I have no idea what its upset about..perhaps I lack sufficient permission

greg.haskins (Fri, 09 Jun 2017 15:06:24 GMT):
im guessing that minimally I probably need an "apt-get upgrade" cycle to pull in the latest...which we should probably do (at least when IS_RELEASE=true)

greg.haskins (Fri, 09 Jun 2017 15:07:05 GMT):
@cbf does this sound reasonable to you (add a os-update cycle to the build when its a release build)

mastersingh24 (Fri, 09 Jun 2017 15:34:23 GMT):
@greg.haskins - is this about the docker scans?

mastersingh24 (Fri, 09 Jun 2017 15:34:28 GMT):
You can see the details

greg.haskins (Fri, 09 Jun 2017 15:34:39 GMT):
@mastersingh24 yes, and how?

mastersingh24 (Fri, 09 Jun 2017 15:34:41 GMT):
but they are all from the ubuntu:xenial

greg.haskins (Fri, 09 Jun 2017 15:34:51 GMT):
yeah, i figured that

mastersingh24 (Fri, 09 Jun 2017 15:34:56 GMT):
oh - I wonder if you do not have access

mastersingh24 (Fri, 09 Jun 2017 15:35:07 GMT):
but basically looking at ubuntu:xenial will answer the question

mastersingh24 (Fri, 09 Jun 2017 15:35:11 GMT):
I compared them

mastersingh24 (Fri, 09 Jun 2017 15:35:12 GMT):
;)

greg.haskins (Fri, 09 Jun 2017 15:35:27 GMT):
BUT, I do wonder if its "its xenials problem, nothing we can do", or "its xenials problem, but apt-get upgrade fixes it"

greg.haskins (Fri, 09 Jun 2017 15:35:35 GMT):
because the latter is our problem

mastersingh24 (Fri, 09 Jun 2017 15:35:59 GMT):
there are some things which are definitely xenial issues

mastersingh24 (Fri, 09 Jun 2017 15:36:05 GMT):
and apt-upgrade does not fix them

mastersingh24 (Fri, 09 Jun 2017 15:36:12 GMT):
at least not yet

greg.haskins (Fri, 09 Jun 2017 15:36:15 GMT):
ok, thats my primary concern

greg.haskins (Fri, 09 Jun 2017 15:36:48 GMT):
(not that i am cavalier about CVEs...its just CVEs that are related to fabric processes would be actionable

mastersingh24 (Fri, 09 Jun 2017 15:36:53 GMT):
I honestly don't see the issue really - most of the issues are not applicable

greg.haskins (Fri, 09 Jun 2017 15:37:04 GMT):
ok

greg.haskins (Fri, 09 Jun 2017 15:37:26 GMT):
i was just something I saw today that I never noticed before, so figured escalation was the appropriate response

mastersingh24 (Fri, 09 Jun 2017 15:37:34 GMT):
if we really want to avoid any scan issues, we need to move to Alpine

greg.haskins (Fri, 09 Jun 2017 15:37:52 GMT):
im all for that, if it werent for P/Z ;)

mastersingh24 (Fri, 09 Jun 2017 15:38:36 GMT):
I found images for P and Z, but we could also have different images anyway if we wanted?

mastersingh24 (Fri, 09 Jun 2017 15:38:56 GMT):
I've built Alpine images already

yacovm (Fri, 09 Jun 2017 15:39:00 GMT):
Exactly - golang is a binary, so the peer/orderer doesn't really need anything other than the binary itself

yacovm (Fri, 09 Jun 2017 15:39:00 GMT):
Exactly - golang products are a binary, so the peer/orderer doesn't really need anything other than the binary itself

mastersingh24 (Fri, 09 Jun 2017 15:39:01 GMT):
I like them ;)

jyellick (Fri, 09 Jun 2017 16:03:19 GMT):
https://jira.hyperledger.org/browse/FAB-3831 This has 4 votes, and is a "High" priority defect, if anyone else would care to take a look

yacovm (Fri, 09 Jun 2017 16:10:13 GMT):
I just don't understand why all the sub tasks are related to this @jyellick

yacovm (Fri, 09 Jun 2017 16:10:25 GMT):
`Fix cauthdsl potential nil pointer dereference` is a bug

yacovm (Fri, 09 Jun 2017 16:10:34 GMT):
`Fix configtx manager potential nil dereference` also

jyellick (Fri, 09 Jun 2017 16:10:34 GMT):
Yes, that could be elevated to bug

yacovm (Fri, 09 Jun 2017 16:11:18 GMT):
No, I mean - why are they sub-tasks? Can you please describe in 1-2 sentences how (where) is the fix? I guess it's in the common/configtx no?

yacovm (Fri, 09 Jun 2017 16:11:27 GMT):
and not in the configtxlator tool

jyellick (Fri, 09 Jun 2017 16:12:32 GMT):
They are only subtasks because i happened to discover them via tests in `configtxlator`. They are bugs. I made them sub-tasks, because they are prereqs for the later subtasks

jyellick (Fri, 09 Jun 2017 16:12:59 GMT):
But we can switch them from sub-task to bug, as they are independent of 3831, beyond being a blocker for it

jyellick (Fri, 09 Jun 2017 16:13:51 GMT):
> Can you please describe in 1-2 sentences how (where) is the fix? I guess it's in the common/configtx no? I'm not sure what you mean, the CR is there, you can see the check and a test

yacovm (Fri, 09 Jun 2017 16:14:51 GMT):
https://gerrit.hyperledger.org/r/#/c/10341/?

jyellick (Fri, 09 Jun 2017 16:16:00 GMT):
Yes, those tests revealed those two bugs you mentioned. So, I created separate issues for them, in case 10341 is not merged.

yacovm (Fri, 09 Jun 2017 16:16:32 GMT):
well what I don't understand is - why is the sanity check in configtxlator and not in common/configtx ?

jyellick (Fri, 09 Jun 2017 16:18:05 GMT):
Ah. Because something can look 'not sane', but still be permissible. Also, because modifying complex core production code this close to release is a bad idea, so pushing it into a tool is safer.

yacovm (Fri, 09 Jun 2017 16:18:43 GMT):
yeah that's correct

jyellick (Fri, 09 Jun 2017 16:18:45 GMT):
If you read the discussion in the issue, you will see the change was originally proposed for the core configtx stuff, but I pushed back because it is a complicated change in core code which is probably not appropriate for v1. The tool option was a compromise

yacovm (Fri, 09 Jun 2017 16:19:40 GMT):
ok, you got my vote

tkuhrt (Fri, 09 Jun 2017 16:33:15 GMT):
@greg.haskins @mastersingh24 : Trying to find out more about the security vulnerabilities...I found this on the Docker Hub documentation: "If the vulnerability is in a base layer you might not be able to correct the issue in the image. In this case, you might switch to a different version of the base layer, or you might find an equivalent, less vulnerable base layer. You might also decide that the vulnerability or exposure is acceptable." It looks like you are deciding that the vulnerability or exposure is acceptable. Is that correct? We probably want to make sure that @dhuseby takes a look at this when he gets back from vacation.

yacovm (Fri, 09 Jun 2017 16:37:00 GMT):
Now when we have beta - should we have an "affected version - beta" in JIRA?

mastersingh24 (Fri, 09 Jun 2017 16:37:08 GMT):
@tkuhrt - Agreed - @dhuseby should take a look and worth a conversation at that point. I don't see this as an exposure with how our images work and what is exposed. In general, there are any images out there based on ubuntu:xenial and there are several debates about the scans.

mastersingh24 (Fri, 09 Jun 2017 16:37:16 GMT):
@yacovm - correct

mastersingh24 (Fri, 09 Jun 2017 16:37:57 GMT):
We have v1.0.0-beta which would be the Affects Version and we have v1.0.0-rc1 and v1.0.0 for fix version

greg.haskins (Fri, 09 Jun 2017 17:37:25 GMT):
@tkuhrt fwiw, I suspect most things in that image that might trip up a scan probably have 0 real world imact because of how we run the container

greg.haskins (Fri, 09 Jun 2017 17:37:43 GMT):
not saying we shouldnt check/understand, either

greg.haskins (Fri, 09 Jun 2017 17:38:34 GMT):
the gotchas would be something like libssl.so, etc, that might link into the peer process

yacovm (Sat, 10 Jun 2017 13:18:40 GMT):
https://wiki.hyperledger.org/projects/fabric/release_process_notes?&#weekly_release_cadence_-_cbf @cbf > ensure Daily and Weekly tests are run, force repeated CR CI passes of each repositor 1) Do we have weekly tests? where are they and what do they do? 2) I think we are *very* lacking in the integration tests area. - e2e tests that run in CI is the testing a naive green path that is like 20% of so of the real production flow. golang UTs stop you from submitting a change that breaks everything but we have discovered in the last weeks numerous bugs that were only caught via: - QA manual tests - Stuff developers did and saw suspicious prints in the log files / exceptions If we don't have good integration tests that: - Spin up a new environment from scratch - install everything needed - test non trivial stuff, i.e with killing peers, bringing up new peers, etc. etc. How do we know that we haven't introduced new bugs in that week?

yacovm (Sat, 10 Jun 2017 13:18:40 GMT):
https://wiki.hyperledger.org/projects/fabric/release_process_notes?&#weekly_release_cadence_-_cbf @cbf > ensure Daily and Weekly tests are run, force repeated CR CI passes of each repositor 1) Do we have weekly tests? where are they and what do they do? 2) I think we are *very* lacking in the integration tests area. - e2e tests that run in CI are testing a naive green path that is like 20% of so of the real production flow. golang UTs stop you from submitting a change that breaks everything but we have discovered in the last weeks numerous bugs that were only caught via: - QA manual tests - Stuff developers did and saw suspicious prints in the log files / exceptions If we don't have good integration tests that: - Spin up a new environment from scratch - install everything needed - test non trivial stuff, i.e with killing peers, bringing up new peers, etc. etc. How do we know that we haven't introduced new bugs in that week?

yacovm (Sat, 10 Jun 2017 13:18:40 GMT):
https://wiki.hyperledger.org/projects/fabric/release_process_notes?&#weekly_release_cadence_-_cbf @cbf > ensure Daily and Weekly tests are run, force repeated CR CI passes of each repositor 1) Do we have weekly tests? where are they and what do they do? 2) I think we are *very* lacking in the integration tests area. - e2e tests that run in CI are testing a naive green path that is like 20% or so of the real production flow. golang UTs stop you from submitting a change that breaks everything but we have discovered in the last weeks numerous bugs that were only caught via: - QA manual tests - Stuff developers did and saw suspicious prints in the log files / exceptions If we don't have good integration tests that: - Spin up a new environment from scratch - install everything needed - test non trivial stuff, i.e with killing peers, bringing up new peers, etc. etc. How do we know that we haven't introduced new bugs in that week?

muralisr (Sat, 10 Jun 2017 15:24:56 GMT):
@yacovm actually sometimes I'm pleasantly surprised with the stability... running stress with couchdb, kafka, multiple peers etc. We must be doing something right. Given more scrutiny in what goes in and limiting what goes in will help maintain the trend now that the focus on UT is set. But agree with you, in that incremental work, we could also use some integ. testing focus, especially with "feature" submissions

muralisr (Sat, 10 Jun 2017 15:26:55 GMT):
caveat - of course, the above optimistic stability statement is only w.r.t green paths. don't about path with rand failure (network, peer/orderer outages, etc) :-)

muralisr (Sat, 10 Jun 2017 15:26:55 GMT):
caveat - of course, the above optimistic stability statement is only w.r.t green paths. don't know about path with rand failure (network, peer/orderer outages, etc) :-)

cbf (Sat, 10 Jun 2017 15:33:23 GMT):
@yacovm @muralisr there are tests but they aren't running in CI yet (I keep beating @bmos299 up about this ;-) with any luck these will be running soon. The Dailies are also not running just yet (in CI, though they are running in the IBM lab environment - again, to my disappointment).

muralisr (Sat, 10 Jun 2017 15:34:36 GMT):
@cbf woohoo!

yacovm (Sat, 10 Jun 2017 15:38:32 GMT):
is there a list of what scenarios these tests do?

yacovm (Sat, 10 Jun 2017 15:38:32 GMT):
@cbf is there a list of what scenarios these tests do?

yacovm (Sat, 10 Jun 2017 15:38:37 GMT):
what do these tests check?

yacovm (Sat, 10 Jun 2017 15:40:34 GMT):
> actually sometimes I'm pleasantly surprised with the stability... running stress with couchdb, kafka, multiple peers etc What is the blocks/second or transaction/second that these stability tests impose?

yacovm (Sat, 10 Jun 2017 15:43:01 GMT):
> Given more scrutiny in what goes in and limiting what goes in will help maintain the trend now that the focus on UT is set That's not enough. I've seen changes that fixed bugs and change only 1 file (not including test files) and they were reviewed for half a day by 2 leading developers of a component and yet they introduced bugs. We can't catch all bugs in CR stage, and we don't have anything that catches them in the macro level (integrations)

muralisr (Sat, 10 Jun 2017 17:00:47 GMT):
@yacovm if bugs go past component owners scrutiny - when we are limiting what goes in at the same time - then we have a problem. Its hard to replace the eyes and brains of component owners and subject experts with new "integration tests" (in addition to UT). Won't scale

yacovm (Sat, 10 Jun 2017 17:13:56 GMT):
this has nothing to do with brains or eyes, people introduce bugs - such is life.You can't rely on good CR as a means of not introducing bugs.

yacovm (Sat, 10 Jun 2017 17:13:56 GMT):
this has nothing to do with brains or eyes, people introduce bugs - such is life. You can't rely on good CR as a means of not introducing bugs.

muralisr (Sat, 10 Jun 2017 18:25:46 GMT):
everyone has to know the whole system and has to keep writing integration tests for CR is not very scalable. People who review have to have a sense of integration so such bugs are minimized (right, bugs will creep in regardless...such is life indeed). I'm not saying we don't do away with integ. tests. Its just that the approach to that has to be different (from a UT for instance )

muralisr (Sat, 10 Jun 2017 18:26:42 GMT):
having a different body of people than those submitting CRs doing that would be one way

yacovm (Sat, 10 Jun 2017 18:45:53 GMT):
I didn't say that everyone would right integration tests for CR. I said that we need good, thorough integration tests in order to know we don't introduce regression if we want to do frequent releases

yacovm (Sat, 10 Jun 2017 18:45:53 GMT):
I didn't say that everyone would write integration tests for CR. I said that we need good, thorough integration tests in order to know we don't introduce regression if we want to do frequent releases

cbf (Sat, 10 Jun 2017 19:45:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=RiXPnPznGfifNjPwZ) @yacovm look in JIRA under the fabric-quality component

cbf (Sat, 10 Jun 2017 19:47:21 GMT):
@yacov if you ask me, having different people writing tests, whether UT or FT etc is silly - I would never run a team like that... better to have the developers writing the tests if you ask me - but of course, that means that the developers need to learn how to write tests.

cbf (Sat, 10 Jun 2017 19:47:21 GMT):
@yacovm if you ask me, having different people writing tests, whether UT or FT etc is silly - I would never run a team like that... better to have the developers writing the tests if you ask me - but of course, that means that the developers need to learn how to write tests.

Michal Malka (Mon, 12 Jun 2017 06:36:28 GMT):
Has joined the channel.

mastersingh24 (Mon, 12 Jun 2017 11:43:54 GMT):
Fellow maintainers - https://jira.hyperledger.org/browse/FAB-3762 / https://gerrit.hyperledger.org/r/#/c/9173/3 - any reason not to push this out post v1.0.0?

yacovm (Mon, 12 Jun 2017 12:10:08 GMT):
this isn't a bug IIUC so yeah, post v1.0

cbf (Mon, 12 Jun 2017 12:49:41 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=urqwSBpg8QTn2eREZ) @mastersingh24 +2

C0rWin (Mon, 12 Jun 2017 13:11:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=urqwSBpg8QTn2eREZ) @mastersingh24 I would vote to deprecate this default chaincode name

C0rWin (Mon, 12 Jun 2017 13:11:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=urqwSBpg8QTn2eREZ) @mastersingh24 I would vote to deprecate this default chain name

yacovm (Mon, 12 Jun 2017 13:17:50 GMT):
You mean the default chain name ;)

muralisr (Mon, 12 Jun 2017 14:04:49 GMT):
@mastersingh24 +2 the changes span too many files I think

muralisr (Mon, 12 Jun 2017 14:18:04 GMT):
This one changes a few files too - but all CLI . It cleans up command reporting (haven't tested it out yet) https://jira.hyperledger.org/browse/FAB-2167 https://gerrit.hyperledger.org/r/#/c/10463/

binhn (Mon, 12 Jun 2017 14:18:15 GMT):
@mastersingh24 i am ok deferring it, but we need the default channel for devmode

binhn (Mon, 12 Jun 2017 14:18:56 GMT):
next iteration, we should pull the default channel out of the peer code

muralisr (Mon, 12 Jun 2017 14:19:56 GMT):
@binhn I thought dev mode requires one to create channel too, no ?

binhn (Mon, 12 Jun 2017 14:21:54 GMT):
the example doc does take the user through a couple of channels, but i'd like the default that i don't have to do anything with channel, just install/instantiate chaincode and go, we can pull the default channel into the cli later

muralisr (Mon, 12 Jun 2017 14:23:33 GMT):
ok

muralisr (Mon, 12 Jun 2017 14:24:52 GMT):
I'll play with testchainid a bit too

JonathanLevi (Mon, 12 Jun 2017 15:07:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=urqwSBpg8QTn2eREZ) +2

jyellick (Mon, 12 Jun 2017 15:58:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=urqwSBpg8QTn2eREZ) +2 as well

kostas (Mon, 12 Jun 2017 18:51:47 GMT):
For the release checklist, can we add this item: Mark released version as errr, released version in JIRA?

kostas (Mon, 12 Jun 2017 18:51:55 GMT):

Message Attachments

kostas (Mon, 12 Jun 2017 18:51:58 GMT):
^^ @cbf

kostas (Mon, 12 Jun 2017 18:52:04 GMT):
(If you point me to the JIRA I can add it.)

kostas (Mon, 12 Jun 2017 18:52:04 GMT):
(If you point me to the JIRA issue I can add it.)

cbf (Mon, 12 Jun 2017 19:05:13 GMT):
not sure what you need?

cbf (Mon, 12 Jun 2017 19:05:46 GMT):
I honestly don't know how to make a version a "released version"

kostas (Mon, 12 Jun 2017 19:15:01 GMT):
@cbf: There is a knob/page somewhere in JIRA that allows you to mark versions as released. We had missed this step when `alpha-2` was cut, and when I requested the update here, @mastersingh24 did it.

kostas (Mon, 12 Jun 2017 19:15:14 GMT):
I am guessing this should be another item in the release checklist.

kostas (Mon, 12 Jun 2017 19:15:50 GMT):
And IIRC you maintain a JIRA with the release checklist items. I was asking for the link to that JIRA so I could add that item there.

kostas (Mon, 12 Jun 2017 19:40:35 GMT):
@cbf: https://jira.hyperledger.org/projects/FAB?selectedItem=com.atlassian.jira.jira-projects-plugin:release-page&status=released-unreleased

cbf (Mon, 12 Jun 2017 19:45:21 GMT):
@kostas https://jira.hyperledger.org/browse/FAB-4518

manish-sethi (Tue, 13 Jun 2017 12:09:52 GMT):
@channel - review-needed for https://jira.hyperledger.org/browse/FAB-2487

yacovm (Tue, 13 Jun 2017 12:17:32 GMT):
so if the current implementation has a lossy transformation is means that you can effectively create a channel and it over-writes other namespaces? @manish-sethi

yacovm (Tue, 13 Jun 2017 12:17:32 GMT):
so if the current implementation has a lossy transformation is means that you can effectively create a channel with some other name that creates a conflict and it over-writes other namespaces? @manish-sethi

manish-sethi (Tue, 13 Jun 2017 12:36:34 GMT):
yes @yacovm

yacovm (Tue, 13 Jun 2017 12:37:10 GMT):
+1 then

mastersingh24 (Tue, 13 Jun 2017 15:22:13 GMT):
isn't this a bug? what are we voting on? are we voting whether or not to defer?

yacovm (Tue, 13 Jun 2017 15:23:29 GMT):
I was under the impression we were voting on whether it's a bug or not

muralisr (Tue, 13 Jun 2017 17:20:21 GMT):
bleeding data from one channel to another because of namespace folding ... right ? sounds severe enough to be fixed immediately

muralisr (Tue, 13 Jun 2017 17:23:22 GMT):
from a few days back

muralisr (Tue, 13 Jun 2017 17:23:23 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=wZtuszorAQfj6YLkb

muralisr (Tue, 13 Jun 2017 17:24:12 GMT):
the above has had some reviews and appears good to go... it touches the CLI side only and makes the help more user friendly

muralisr (Tue, 13 Jun 2017 17:27:54 GMT):
pretty low risk and helps usability... can we get that in or do we need "review-needed" voting ?

cbf (Tue, 13 Jun 2017 19:09:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=cjQPqGvZzoJeXxPhT) @muralisr +1

cbf (Tue, 13 Jun 2017 19:09:40 GMT):
if we can get some good solid testing I'm ok making usability improvement here

muralisr (Tue, 13 Jun 2017 19:16:15 GMT):
@cbf thanks much

binhn (Tue, 13 Jun 2017 20:34:23 GMT):
@JonathanLevi @cbf given the new info from @chris.elder re https://jira.hyperledger.org/browse/FAB-4243, I propose to lower priority on this defect and remove it from the required items on https://jira.hyperledger.org/browse/FAB-4518

cbf (Tue, 13 Jun 2017 21:27:39 GMT):
seems reasonable

cbf (Tue, 13 Jun 2017 21:29:33 GMT):
we still have 2 high/highest (one of which is a security issue) that are not build related. I am also concerned that we don't have documentation updates

muralisr (Tue, 13 Jun 2017 22:07:01 GMT):
https://gerrit.hyperledger.org/r/#/c/10121/ ( JIRA https://jira.hyperledger.org/browse/FAB-4473) was broken out of discussion in https://jira.hyperledger.org/browse/FAB-3742 . It uses chaincode-independent minimal cache while the original implementation used the entire chaincode package. Basically memory savings for large chaincodes. It is an implementation detail that does not bleed out of ccprovider package.... can we get this in please ?

greg.haskins (Wed, 14 Jun 2017 11:57:06 GMT):
@muralisr can you describe what the cache does?

greg.haskins (Wed, 14 Jun 2017 11:57:13 GMT):
I am not familiar

muralisr (Wed, 14 Jun 2017 11:57:30 GMT):
@greg.haskins certainly

muralisr (Wed, 14 Jun 2017 11:57:40 GMT):
one moment

muralisr (Wed, 14 Jun 2017 11:58:59 GMT):
first let me get comments from the original cache implementation

muralisr (Wed, 14 Jun 2017 11:59:04 GMT):
``` // we have the info from the fs, check that the policy // matches the one on the file system if one was specified; // this check is required because the admin of this peer // might have specified instantiation policies for their // chaincode, for example to make sure that the chaincode // is only instantiated on certain channels; a malicious // peer on the other hand might have created a deploy // transaction that attempts to bypass the instantiation // policy. This check is there to ensure that this will not // happen, i.e. that the peer will refuse to invoke the // chaincode under these conditions. More info on // https://jira.hyperledger.org/browse/FAB-3156```

muralisr (Wed, 14 Jun 2017 12:00:17 GMT):
basically every invoke needed to check for whether the chaincode that is installed on that peer is the same as the one that was instantiated

muralisr (Wed, 14 Jun 2017 12:00:58 GMT):
to do this we need to access the installed chaincode on FS

muralisr (Wed, 14 Jun 2017 12:01:25 GMT):
to avoid FS access on every invoke, the first access caches the data

muralisr (Wed, 14 Jun 2017 12:02:06 GMT):
the original implementation cached the entire chaincode ..the above CR just caches the the part that's needed

greg.haskins (Wed, 14 Jun 2017 12:02:08 GMT):
the entire chaincode package?

greg.haskins (Wed, 14 Jun 2017 12:02:15 GMT):
i see

greg.haskins (Wed, 14 Jun 2017 12:02:31 GMT):
where is it cached?

greg.haskins (Wed, 14 Jun 2017 12:02:58 GMT):
in memory?

muralisr (Wed, 14 Jun 2017 12:03:04 GMT):
core/common/ccprovider/ccinfocache.go in memory

muralisr (Wed, 14 Jun 2017 12:05:24 GMT):
actually with your minimal chaincode work, it alleviated the memory pressure considerably

muralisr (Wed, 14 Jun 2017 12:05:52 GMT):
however we just don't need chaincode size in the cache equation at all

greg.haskins (Wed, 14 Jun 2017 12:07:48 GMT):
right

greg.haskins (Wed, 14 Jun 2017 12:08:17 GMT):
I still dont fully understand the function/threat-model, but this metadata reduction makes sense to me in general

cbf (Wed, 14 Jun 2017 12:19:04 GMT):
seems like the build is broken

cbf (Wed, 14 Jun 2017 12:19:05 GMT):
https://gerrit.hyperledger.org/r/#/c/10577/

muralisr (Wed, 14 Jun 2017 12:21:39 GMT):
@greg.haskins just saw a comment from @jiangyaoguo about something I missed when I rebased

muralisr (Wed, 14 Jun 2017 12:22:44 GMT):
the original code where the new cache model was used was refactored and rebase pulled that in

muralisr (Wed, 14 Jun 2017 12:23:09 GMT):
I'll have to apply my fix to that code as well

muralisr (Wed, 14 Jun 2017 12:23:15 GMT):
will push the fix shortly

muralisr (Wed, 14 Jun 2017 12:45:19 GMT):
@greg.haskins pushed

JonathanLevi (Wed, 14 Jun 2017 15:45:50 GMT):
Chris and I have just merged https://gerrit.hyperledger.org/r/#/c/10565/

JonathanLevi (Wed, 14 Jun 2017 15:46:13 GMT):
We believe it should fix the build... but please reach out if it does not.

JonathanLevi (Wed, 14 Jun 2017 15:46:22 GMT):
Worked (for Chris) locally.

leoleo (Thu, 15 Jun 2017 13:06:14 GMT):
Has joined the channel.

greg.haskins (Fri, 16 Jun 2017 16:24:38 GMT):
@here I know every one is busy, but reminder: https://github.com/ghaskins/hyperledger-fabric-alpha2-challenge

greg.haskins (Fri, 16 Jun 2017 16:24:53 GMT):
part of the point is: it shouldnt be hard

greg.haskins (Fri, 16 Jun 2017 16:25:09 GMT):
if you cant crank this out in an hour or two, we are doing something wrong ;)

kellyo (Fri, 16 Jun 2017 17:31:25 GMT):
Has joined the channel.

muralisr (Fri, 16 Jun 2017 20:51:06 GMT):
@greg.haskins I also tried to take this up a notch with ACLs etc and have it languishing ... but not forgotten ... in the side

muralisr (Fri, 16 Jun 2017 20:52:14 GMT):
but i do need to intend to complete it

jimthematrix (Mon, 19 Jun 2017 05:04:22 GMT):
fellow maintainers, I'll be on vacation starting 6/19 until 7/10, with a significant part in China (and as such be out of reach during the EDT day time). please direct any questions and discussions regarding the node SDK to @bretharrison while I'm away. I'll make my best attempt to check rocket.chat but no guarantee on responsiveness. also as you know @mastersingh24 knows the code base pretty well too, and @greg.haskins on a significant portion so they are your other sources of truth too

bretharrison (Mon, 19 Jun 2017 05:04:22 GMT):
Has joined the channel.

sfukazu (Mon, 19 Jun 2017 06:35:35 GMT):
Has joined the channel.

cbf (Mon, 19 Jun 2017 07:40:44 GMT):
while we're on the letting ppl know we're on vacation - I'll be off the grid 7/2-7/12 wandering around the Iceland landscape

cbf (Mon, 19 Jun 2017 07:40:57 GMT):
I will not be monitoring RC or email;-)

roj (Mon, 19 Jun 2017 10:45:54 GMT):
Has joined the channel.

greg.haskins (Mon, 19 Jun 2017 12:32:32 GMT):
I will be out in a similar timeframe as @cbf, i think 7/1 to 7/13 or so

stanacton (Mon, 19 Jun 2017 14:16:03 GMT):
Has joined the channel.

stanacton (Mon, 19 Jun 2017 14:19:55 GMT):
Hello.. Newbie question here. I hear that Java chaincode support won't be in the GA release. How would I find out what is left to do to get it ready? I know there's Jira, do I just search for Java tasks? Sorry to ask such a trivial question.

muralisr (Mon, 19 Jun 2017 15:01:37 GMT):
@stanacton posting your question in java chaincode and will add pointers there

muralisr (Mon, 19 Jun 2017 15:02:15 GMT):
@stanacton never mind...see you have already done that

jimthematrix (Mon, 19 Jun 2017 15:53:55 GMT):
have a question on windows support: we have not been able to get much testing done on windows with node SDK at all (I had a tester spending time on it but she wasn't able to get much done), and windows-specific bugs came up from time to time, like this one https://jira.hyperledger.org/browse/FAB-4847. we also don't have a windows based CI either, which in hindsight is an oversight on my part

jimthematrix (Mon, 19 Jun 2017 15:55:36 GMT):
I'm thinking the right thing to do is document that windows support is "as-is" or "YMMV", since it's a developer's platform anyway (I don't think anybody have production deployments on windows servers)

jimthematrix (Mon, 19 Jun 2017 15:55:36 GMT):
I'm thinking the right thing to do is document that windows support is "as-is" or "YMMV" as a developer's platform anyway, and "not supported" for production deployments on windows servers)

jimthematrix (Mon, 19 Jun 2017 15:56:24 GMT):
of course, this is specific to SDKs only

jimthematrix (Mon, 19 Jun 2017 15:57:49 GMT):
any objections?

lehors (Mon, 19 Jun 2017 16:02:43 GMT):
@jimthematrix I will give it another shot but in the past when I tried I got stuck getting it running at all on my Windows 7 box :-(

lehors (Mon, 19 Jun 2017 16:03:39 GMT):
I'll let you know if I get anywhere but don't count on it

lehors (Mon, 19 Jun 2017 16:03:59 GMT):
I think your suggestion is totally reasonable

jimthematrix (Mon, 19 Jun 2017 17:26:56 GMT):
Thanks Arnaud

cbf (Mon, 19 Jun 2017 21:58:39 GMT):
@here can we please vote or comment on https://jira.hyperledger.org/browse/FAB-4853

cbf (Mon, 19 Jun 2017 21:58:56 GMT):
if we do this, I want to get it done for the release candidate

muralisr (Mon, 19 Jun 2017 23:50:50 GMT):
@here there was a discussion on the fabric-scrum on https://jira.hyperledger.org/browse/FAB-4751. This deals with a hole in chaincode framework that allows an external chaincode to register and take over another chaincode's stream that's being launched. https://gerrit.hyperledger.org/r/#/c/10747/ reduces that vulnerability by not allowing external chaincode to register in the first place (unless in devmode). With that fix in place, a attacker would have to inject an external registration in between the launch of a chaincode and its registration. Optionally for 1.0, it is proposed to reduce that risk even further by having a separate chaincode listener port for internal use (ie, a private port that can be protected). This would not reduce ease of use for dev/test but allow the port to be internal when necessary. *Further, post 1.0, the proposal is to enhance the fix with verification over the TLS connection between the peer and the chaincode. * Can maintainers chime in on this proposal please ?

muralisr (Mon, 19 Jun 2017 23:50:50 GMT):
@here there was a discussion on the fabric-scrum on https://jira.hyperledger.org/browse/FAB-4751. This deals with a hole in chaincode framework that allows an external chaincode to register and take over another chaincode's stream that's being launched. https://gerrit.hyperledger.org/r/#/c/10747/ reduces that vulnerability by not allowing external chaincode to register in the first place (unless in devmode). With that fix in place, a attacker would have to inject an external registration in between the launch of a chaincode and its registration. Optionally for 1.0, it is proposed to reduce that risk even further by having a separate chaincode listener port for internal use (ie, a private port that can be protected). This would not affect ease of use for dev/test but allow the port to be internal when necessary. *Further, post 1.0, the proposal is to enhance the fix with verification over the TLS connection between the peer and the chaincode. * Can maintainers chime in on this proposal please ?

muralisr (Mon, 19 Jun 2017 23:52:04 GMT):
@greg.haskins @cbf @bin

muralisr (Mon, 19 Jun 2017 23:52:04 GMT):
@greg.haskins @binh @cbf @mastersingh24

muralisr (Mon, 19 Jun 2017 23:52:04 GMT):
@greg.haskins @binhn @cbf @mastersingh24

muralisr (Mon, 19 Jun 2017 23:52:04 GMT):
@greg.haskins @binhn @cbf @mastersingh24 based on your comments on the scrum and CRs would be helpful if you commented (and other maintainers of course)

muralisr (Mon, 19 Jun 2017 23:52:04 GMT):
@greg.haskins @binhn @cbf @mastersingh24 @JonathanLevi based on your comments on the scrum and CRs would be helpful if you commented (and other maintainers of course)

cbf (Tue, 20 Jun 2017 08:13:34 GMT):
I'd really like to see us get the docs and the samples merged (chaincode, first network and first app) but we need the first app code merged into the tutorial and we need eyes on the first network and chaincode tutorials

cbf (Tue, 20 Jun 2017 08:14:28 GMT):
I'd also like to see https://gerrit.hyperledger.org/r/#/c/10583/ merged so that the peer binary is available for cli

cbf (Tue, 20 Jun 2017 08:15:34 GMT):
we need to then verify that the binaries tarfile is being created correctly and test with the samples repo

cbf (Tue, 20 Jun 2017 08:16:36 GMT):
and we should try to merge any remaining open bug fix CRs today... if we can get through that, then I think we will be ready for beta2 or rc1 depending on what defects remain

dongqi (Tue, 20 Jun 2017 08:38:00 GMT):
Has joined the channel.

weeds (Tue, 20 Jun 2017 12:18:40 GMT):
looks like 10583 is merged already

muralisr (Tue, 20 Jun 2017 12:19:39 GMT):
@cbf will spend time going over docs with @nickgaski help

rickr (Tue, 20 Jun 2017 13:28:15 GMT):
Hi Jim and I are the only _active maintainers_ on the Java SDK. During his two weeks absents I'd like to submit my own code -- I will _try_ to get a least one non maintainer to do a review before submitting. Once his return we can go back status quo.

weeds (Tue, 20 Jun 2017 13:29:51 GMT):
@cbf i did ask Binh, Barry's team, Kostas, and Dave Enyeart to help on looking at some of the doc submissions

binhn (Tue, 20 Jun 2017 13:29:57 GMT):
@rickr i am sure folks still remember java, me included, so we'll help

mastersingh24 (Tue, 20 Jun 2017 13:33:14 GMT):
@rickr - your proposal is good to me. we'll try to pitch in

scottz (Tue, 20 Jun 2017 16:10:33 GMT):
Has joined the channel.

scottz (Tue, 20 Jun 2017 16:23:40 GMT):
Please take a look at the updated Hyperledger-Fabric System Verification Test (SVT) report for v1.0, available @here : https://docs.google.com/spreadsheets/d/1E3-PXchMOWm6DC5xq6RN-NT2YmngKNcG_zQqW0ireY4/edit?usp=sharing It shows the system test summary on first tab, plus a breakdown by "Test Area" in the following tabs which contain individual testcases. We even created Jira tasks to describe each testcase. This report does NOT include everything such as Unit Tests or other manual tests done by various community members, but hopefully it satisfies questions about system test coverage.

JonathanLevi (Tue, 20 Jun 2017 16:29:58 GMT):
Can we please do not have *non-fabric* maintainers posting in this channel?

JonathanLevi (Tue, 20 Jun 2017 16:30:11 GMT):
Do I need to kick people out? I don't understand.

JonathanLevi (Tue, 20 Jun 2017 16:30:28 GMT):
Let alone using that @ *here* thing...

JonathanLevi (Tue, 20 Jun 2017 16:31:15 GMT):
To be clear, *this* channel is for *these* people: https://github.com/hyperledger/fabric/blob/master/docs/source/MAINTAINERS.rst

JonathanLevi (Tue, 20 Jun 2017 16:31:15 GMT):
Please, to be clear, *this* channel is for *these* people: https://github.com/hyperledger/fabric/blob/master/docs/source/MAINTAINERS.rst

scottz (Tue, 20 Jun 2017 16:44:27 GMT):
Has left the channel.

cbf (Wed, 21 Jun 2017 20:26:14 GMT):
https://gerrit.hyperledger.org/r/#/c/10835/

muralisr (Wed, 21 Jun 2017 20:33:49 GMT):
abandoned above.... https://gerrit.hyperledger.org/r/#/c/10959 is a better CR as it highlights recent contributions

muralisr (Wed, 21 Jun 2017 20:34:03 GMT):
(sorry for the confusion @cbf)

cbf (Thu, 22 Jun 2017 01:31:40 GMT):
congrats @jiangyaoguo ! welcome to the Fabric maintainers!

jiangyaoguo (Thu, 22 Jun 2017 01:43:20 GMT):
Thank you all. Will continue to contribute to Fabric and evangelism in china. @muralisr @cbf

dave.enyeart (Thu, 22 Jun 2017 02:32:02 GMT):
Congratulations @jiangyaoguo . And I'm so sorry @yacovm :-)

dave.enyeart (Thu, 22 Jun 2017 02:32:06 GMT):
See https://gerrit.hyperledger.org/r/#/c/10959/1/docs/source/MAINTAINERS.rst

dave.enyeart (Thu, 22 Jun 2017 02:34:26 GMT):
must be a LRU cache

dave.enyeart (Thu, 22 Jun 2017 02:34:26 GMT):
must be a LRU cache :-)

jiangyaoguo (Thu, 22 Jun 2017 02:50:23 GMT):
Thanks @dave.enyeart . yaoguo and yacovm look similar. @yacovm :relaxed:

yacovm (Thu, 22 Jun 2017 05:22:04 GMT):
It actually does

yacovm (Thu, 22 Jun 2017 05:22:28 GMT):
No one could tell the difference :wink:

fbenhamo (Thu, 22 Jun 2017 06:13:23 GMT):
Has left the channel.

yacovm (Thu, 22 Jun 2017 07:20:14 GMT):
@dave.enyeart I like the LRU reference, nicely said. These graphs still chase me in my dreams

yacovm (Thu, 22 Jun 2017 07:20:14 GMT):
@dave.enyeart I like the LRU reference, nicely said. These graphs of peer memory consumption still chase me in my dreams

rjones (Thu, 22 Jun 2017 08:20:47 GMT):
please review and merge https://gerrit.hyperledger.org/r/#/c/10993/

paapighoda (Thu, 22 Jun 2017 09:18:03 GMT):
Has left the channel.

mastersingh24 (Thu, 22 Jun 2017 13:56:04 GMT):
Folks - https://gerrit.hyperledger.org/r/#/c/11005/ is a CR for the Java SDK - but does not actually change any code. It enables the SDK integration tests to works with separate TLS and signing certs. Need to get this in (as well as https://gerrit.hyperledger.org/r/10999 for the NodeSDK). Also - anyone have an issue with @rickr merging his own CRs for the Java SDK (only while Jim is out)?

greg.haskins (Thu, 22 Jun 2017 13:57:47 GMT):
@mastersingh24 did you guys test that CA change with examples/cluster?

greg.haskins (Thu, 22 Jun 2017 13:57:53 GMT):
that change looks concerning

mastersingh24 (Thu, 22 Jun 2017 14:02:12 GMT):
@greg.haskins - so nothing is broken yet because I have not yet submitted a CR for https://jira.hyperledger.org/browse/FAB-4904 (although it is ready to go). I did modify examples/e2e_cli to work as part of the CR. Let me check on examples/cluster as well

greg.haskins (Thu, 22 Jun 2017 14:02:24 GMT):
ty

greg.haskins (Thu, 22 Jun 2017 14:02:40 GMT):
i havent wrapped my head around whether this will require a client change as well

greg.haskins (Thu, 22 Jun 2017 14:03:02 GMT):
but for now, just ensuring examples/cluster itself doesnt break is a start

rickr (Thu, 22 Jun 2017 14:07:35 GMT):
https://gerrit.hyperledger.org/r/#/c/11005 looks good ran all test .. going to merge

mastersingh24 (Thu, 22 Jun 2017 14:46:24 GMT):
@greg.haskins - as far as I can tell, the client still explicitly specify the trusted certs for TLS connections

mastersingh24 (Thu, 22 Jun 2017 14:46:42 GMT):
But in the end, using the artifacts we generate it's pretty transparent

greg.haskins (Thu, 22 Jun 2017 14:46:54 GMT):
@mastersingh24 right, but also note that examples/cluster generates a file build/client.config

greg.haskins (Thu, 22 Jun 2017 14:47:03 GMT):
and I am not sure it will work with the new scheme

mastersingh24 (Thu, 22 Jun 2017 14:47:17 GMT):
I'll make it work for you. Fear not my friend

greg.haskins (Thu, 22 Jun 2017 14:47:24 GMT):
you are awesome

greg.haskins (Thu, 22 Jun 2017 14:47:25 GMT):
ty

mastersingh24 (Thu, 22 Jun 2017 19:52:04 GMT):
@greg.haskins https://gerrit.hyperledger.org/r/#/c/11021/

mastersingh24 (Thu, 22 Jun 2017 19:52:35 GMT):
just a few small tweaks, but the cluster example is working in the new world ;)

mastersingh24 (Thu, 22 Jun 2017 19:53:13 GMT):
At fellow maintainers - we have an issue which I think I've directly / indirectly mentioned a few times

mastersingh24 (Thu, 22 Jun 2017 19:53:40 GMT):
With Jim Zhang out, Rick is the only active maintainer for the Java SDK

mastersingh24 (Thu, 22 Jun 2017 19:53:47 GMT):
And he can't merge his own changes

mastersingh24 (Thu, 22 Jun 2017 19:53:48 GMT):
:(

mastersingh24 (Thu, 22 Jun 2017 19:55:00 GMT):
So we can 1) Ask Ry to change this so he can merge his own code (I think it's possible) 2) Add some of us as maintainers - I'm happy to do it and help out

jyellick (Thu, 22 Jun 2017 19:55:47 GMT):
My vote would be for (2). Hopefully we are at a stage where the changes should be small and easily reviewed, even for a newcomer to the codebase

mastersingh24 (Thu, 22 Jun 2017 19:56:57 GMT):
Yeah - that would be my choice as well

yacovm (Thu, 22 Jun 2017 20:06:39 GMT):
I think that (2)

C0rWin (Thu, 22 Jun 2017 20:07:19 GMT):
I'm for (2) as well

rjones (Thu, 22 Jun 2017 20:09:54 GMT):
(2) is the way you need to go

rjones (Thu, 22 Jun 2017 20:10:25 GMT):
furthermore it's just NACR so you could review and +1 changes and Rick could merge them with no governance changes

rjones (Thu, 22 Jun 2017 20:12:09 GMT):
holding an election to replace Jim will be outside the project's ability right now - the TSC would need to vote on that

mastersingh24 (Thu, 22 Jun 2017 20:28:53 GMT):
@rjones - so Rick can merge his own changes with a +1 from someone else?

mastersingh24 (Thu, 22 Jun 2017 20:29:04 GMT):
or we can make it that way?

rjones (Thu, 22 Jun 2017 20:34:00 GMT):
@mastersingh24 if he gets one +1 he should be able to merge his changes. that's the way NACR works

kostas (Thu, 22 Jun 2017 20:34:13 GMT):
What's does NACR stand for?

kostas (Thu, 22 Jun 2017 20:34:13 GMT):
What does NACR stand for?

rjones (Thu, 22 Jun 2017 20:34:38 GMT):
non author code review, sorry for being opaque

mastersingh24 (Thu, 22 Jun 2017 20:35:54 GMT):
@rjones - sorry - but who has the ability to do "non author code review"? I only had access to code review for https://gerrit.hyperledger.org/r/#/c/10945/

rjones (Thu, 22 Jun 2017 20:38:17 GMT):
@mastersingh24 you are correct. I guess NACR requires the other review come from a committer :(

mastersingh24 (Thu, 22 Jun 2017 20:38:36 GMT):
:(

rjones (Thu, 22 Jun 2017 20:45:03 GMT):

Message Attachments

rjones (Thu, 22 Jun 2017 20:45:24 GMT):
so there are five committers, only one is unavailable.

mastersingh24 (Thu, 22 Jun 2017 20:50:52 GMT):
The others seem to be no shows

jyellick (Thu, 22 Jun 2017 20:51:32 GMT):
Last commits I see for each are: ``` Muhammad Altaf : Thu Feb 2 08:34:15 2017 +1100 Pardha Vishnumolakala : Wed Jan 4 19:08:46 2017 +0000 Satheesh Kathamuthu : Tue Feb 14 19:40:35 2017 +0530 ```

rjones (Thu, 22 Jun 2017 20:51:41 GMT):
but they can be asked to step up or leave.

rjones (Thu, 22 Jun 2017 20:52:18 GMT):
committer shouldn't be some honorary role (imho) the point isn't to collect commit bits on your linkedin cheevos list the point is to help the project

mastersingh24 (Thu, 22 Jun 2017 20:53:50 GMT):
100% agree

mastersingh24 (Thu, 22 Jun 2017 20:54:09 GMT):
We probably should have added some other maintainers earlier

mastersingh24 (Thu, 22 Jun 2017 20:54:26 GMT):
they were active in the past but have basically left all the work to Rick

rjones (Thu, 22 Jun 2017 20:54:28 GMT):
the project has 5. hassle the 3 dropouts for some votes

mastersingh24 (Thu, 22 Jun 2017 20:54:42 GMT):
Will do

rjones (Thu, 22 Jun 2017 20:55:12 GMT):
like, hold an election. the situation is not dire. Rick needs to nominate some active people, and get two more votes to expand the pool

rjones (Thu, 22 Jun 2017 20:55:59 GMT):
I thought the governance situation was a lot worse when I was on my phone. With five committers, as long as you can find two more, you can hold an election within the rules and change everything.

rjones (Thu, 22 Jun 2017 20:57:14 GMT):
or self-nominate. I think someone should nominate enough people to get an majority of active users, then ask the inactive committers to step down, but I'm a hardass

rjones (Thu, 22 Jun 2017 20:58:03 GMT):
do one nomination with everyone in this channel that will commit to being active, which will amount to a sea change in control of the project

cbf (Thu, 22 Jun 2017 22:42:00 GMT):
+1 this is what I suggested to Rick

rickr (Thu, 22 Jun 2017 23:53:01 GMT):
I've seen others doing self commits. All I asked for was during this short piece of time to allow self commits with others doing +1 for a peer review. For better or worse I wrote probably 80% of the code there -- I honestly find it a bit insulting that I can't be trusted to the point that we need rubber stamp the approval of another maintainer. Not going to do that.

JonathanLevi (Fri, 23 Jun 2017 00:06:48 GMT):
I still don't understand why we are using this channel for the above.

JonathanLevi (Fri, 23 Jun 2017 00:07:39 GMT):
Happy to discuss, and vote to "change the rule", but trying the same input against the same rule and the rule-engine is a bit...

cbf (Fri, 23 Jun 2017 04:27:08 GMT):
where have you seen that on this project? it is an anti-pattern. All I am asking is that you vote in some new blood like binh or gari

cbf (Fri, 23 Jun 2017 17:37:31 GMT):
https://chat.hyperledger.org/channel/fabric-release?msg=QjN8AHYrGTgS4WTCd

JonathanLevi (Fri, 23 Jun 2017 17:49:27 GMT):
In other words, announcing MERGE FREEZE *BEGIN*

JonathanLevi (Sat, 24 Jun 2017 01:24:19 GMT):
MERGE FREEZE *END*

JonathanLevi (Sat, 24 Jun 2017 01:24:44 GMT):
A.k.a, *what's tagged is tagged* ;-)

JonathanLevi (Sat, 24 Jun 2017 01:24:53 GMT):
Back to normal.

kostas (Sat, 24 Jun 2017 07:56:45 GMT):
This went relatively smooth this time didn't it?

mastersingh24 (Sat, 24 Jun 2017 09:32:48 GMT):
I'd say so

mastersingh24 (Sat, 24 Jun 2017 09:32:52 GMT):
(so far ;) )

dave.enyeart (Mon, 26 Jun 2017 15:13:42 GMT):
@cbf Given the introduction of fabric-samples /first-network, do you envision /examples/e2e_cli getting removed? I mean, for the next release candidate...

dave.enyeart (Mon, 26 Jun 2017 15:14:05 GMT):
There is a proposed update to the docker-compose for next time around, and we need to know whether to keep up dual maintenance in /examples/e2e_cli.

cbf (Mon, 26 Jun 2017 15:14:17 GMT):
@dave.enyeart unlikely as it is used in a number of integration tests

cbf (Mon, 26 Jun 2017 15:14:45 GMT):
we may want to move it from examples into the test directories

mastersingh24 (Mon, 26 Jun 2017 15:33:58 GMT):
we should modify the e2e_cli to be part of tests and add also add a make target for it

mastersingh24 (Mon, 26 Jun 2017 15:34:08 GMT):
I was going to create a JIRA for it post v1.0.0

cbf (Mon, 26 Jun 2017 17:13:54 GMT):
+1

JonathanLevi (Mon, 26 Jun 2017 17:55:56 GMT):
+1

JonathanLevi (Mon, 26 Jun 2017 17:57:11 GMT):
Just for the formality, is there anyone here who has any information/data/knowledge of issues that should stop us from announcing the 1.0.0-rc1 publicly/widely?

JonathanLevi (Mon, 26 Jun 2017 17:58:51 GMT):
Just to say that we are/were *pleasantly surprised* with how much smoother last version, pre-release tests went...

JonathanLevi (Mon, 26 Jun 2017 17:58:51 GMT):
Just to say that we are/were *pleasantly surprised* with how much smoother last version's pre-release tests went...

mastersingh24 (Mon, 26 Jun 2017 18:38:13 GMT):
I think we'll be helping folks by announcing it given it looks like the fabric-samples and tutorials works pretty well with rc1

JonathanLevi (Mon, 26 Jun 2017 19:15:25 GMT):
Off we go:

JonathanLevi (Mon, 26 Jun 2017 19:15:26 GMT):
https://lists.hyperledger.org/pipermail/hyperledger-announce/2017-June/000010.html

JonathanLevi (Mon, 26 Jun 2017 19:15:47 GMT):
https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-June/001246.html

JonathanLevi (Mon, 26 Jun 2017 19:16:02 GMT):
Thanks everyone for all the hard work!

binhn (Tue, 27 Jun 2017 13:23:41 GMT):
it maybe appropriate time for us to continue the discussion on branching or not branching for release vs dev stream as some of us are starting to look post 1.0

cbf (Tue, 27 Jun 2017 13:26:29 GMT):
yes

dave.enyeart (Tue, 27 Jun 2017 13:37:31 GMT):
For reference, I believe the last discussion of that topic was here: Branching Model Final Thread https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-May/thread.html

binhn (Tue, 27 Jun 2017 13:52:21 GMT):
thanks @dave.enyeart

mastersingh24 (Tue, 27 Jun 2017 14:46:51 GMT):
You may find it interesting to know that the people who build gerrit use release branches and then tags within the release branches for fix versions ;) https://gerrit.googlesource.com/gerrit/

yacovm (Tue, 27 Jun 2017 14:49:02 GMT):
what did they use before the first version came out though? :thinking:

mastersingh24 (Tue, 27 Jun 2017 14:57:10 GMT):
puzzling

mastersingh24 (Tue, 27 Jun 2017 14:57:28 GMT):
How did Docker use Docker to build Docker before there was Docker?

mastersingh24 (Tue, 27 Jun 2017 14:59:04 GMT):
https://cdn.meme.am/cache/instances/folder383/53830383.jpg

binhn (Tue, 27 Jun 2017 15:25:17 GMT):
it looks like we left off at 2 main branches: master and dev, where master is always production ready (tip of master is the current release); short-live feature branches merged into dev; hot-fix branches merged into master and dev. The outstanding question is whether the current CI work with this.

yacovm (Tue, 27 Jun 2017 15:31:29 GMT):
also will it work with gerrit or not

cbf (Tue, 27 Jun 2017 15:54:17 GMT):
we can make the default branch the release branch and master be development (meaning no change to gerrit needed, we just change GH's default branch

cbf (Tue, 27 Jun 2017 16:05:46 GMT):
I would propose a master and release branch and we can tag the latest release on the release branch

cbf (Tue, 27 Jun 2017 16:06:27 GMT):
I would also note that in CF we migrated from master to develop branch strategy and it was a mess for a couple months

yacovm (Tue, 27 Jun 2017 16:08:36 GMT):
so release branch is "frozen" almost all the time and master branch is active development and features are merged to the master branch like in the last year, right?

cbf (Tue, 27 Jun 2017 16:48:05 GMT):
yes, and periodically a ff merge of master into release

yacovm (Tue, 27 Jun 2017 17:35:59 GMT):
if the releases would be frequent I think we can pull this off

dhuseby (Tue, 27 Jun 2017 17:41:09 GMT):
@mastersingh24 the same way the rust programmers built the rust compiler in rust.

dhuseby (Tue, 27 Jun 2017 17:41:20 GMT):
and the same way the first C compiler was written in C

dhuseby (Tue, 27 Jun 2017 17:42:48 GMT):
@cbf if you make the master branch the release branch it has the nice feature of "subscribing" to the project on github means they will receive a notification whenever a new release merge is made

dhuseby (Tue, 27 Jun 2017 17:43:51 GMT):
@cbf why was the move to a development branch a mess?

dhuseby (Tue, 27 Jun 2017 17:44:31 GMT):
the argument in support of having the master branch be the development branch is that doing a git clone gives you the development branch by default

dhuseby (Tue, 27 Jun 2017 17:44:38 GMT):
and merging into the release branch takes real work

dhuseby (Tue, 27 Jun 2017 17:44:51 GMT):
both things that help minimize the "oops" factor

greg.haskins (Tue, 27 Jun 2017 20:07:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=6Y2HCMzPszNQfG93R) @dhuseby Didn't we cover this ad nauseam before? ;)

greg.haskins (Tue, 27 Jun 2017 20:08:31 GMT):
I would summarize it by saying gerrit in general, and the LF policies applied to gerrit in particular made it branch hostile

greg.haskins (Tue, 27 Jun 2017 20:08:54 GMT):
I think this is by design, though...gerrit uses a different model from, say, gitflow style branching

greg.haskins (Tue, 27 Jun 2017 20:09:10 GMT):
gerrit reminds me much more of LKML style git

greg.haskins (Tue, 27 Jun 2017 20:09:39 GMT):
effectively, each CR is basically a development branch

rjones (Tue, 27 Jun 2017 20:34:56 GMT):
don't let GKH hear you say that, @greg.haskins

greg.haskins (Tue, 27 Jun 2017 20:35:56 GMT):
that gerrit is like LKML?

rjones (Tue, 27 Jun 2017 20:37:36 GMT):
he's been on an anti-gerrit tear since forever.

greg.haskins (Tue, 27 Jun 2017 20:54:12 GMT):
ah, thats fine...I am not for nor against, just noting the similarities in the style

greg.haskins (Tue, 27 Jun 2017 20:54:33 GMT):
submitting a gerrit CR feels sort of like a web interface on the concept of a patch submitted to a ML

greg.haskins (Tue, 27 Jun 2017 20:55:14 GMT):
as opposed to, say, a team with git push access, who might do a gitflow type thing with branches

cbf (Tue, 27 Jun 2017 23:48:09 GMT):
please vote https://jira.hyperledger.org/browse/FAB-5043

greg.haskins (Wed, 28 Jun 2017 00:05:16 GMT):
@cbf done

cbf (Wed, 28 Jun 2017 00:20:16 GMT):
thx

cbf (Wed, 28 Jun 2017 13:07:07 GMT):
gentle reminder to please review and comment or vote on https://jira.hyperledger.org/browse/FAB-5043 to create a Homebrew tap repo for Fabric

binhn (Wed, 28 Jun 2017 13:31:55 GMT):
voted

cbf (Wed, 28 Jun 2017 13:32:24 GMT):
thx

binhn (Wed, 28 Jun 2017 13:34:53 GMT):
re branches, it looks like we are at master and release branch, where master is the dev branch -- do we need a vote on this or we just go ahead and create the release 1.0 branch early next week?

cbf (Wed, 28 Jun 2017 13:35:32 GMT):
just to document, I'll put a JIRA up to vote on ok?

binhn (Wed, 28 Jun 2017 13:35:53 GMT):
sounds good, thanks @cbf

cbf (Wed, 28 Jun 2017 13:47:22 GMT):
https://jira.hyperledger.org/browse/FAB-5050

cbf (Wed, 28 Jun 2017 15:40:38 GMT):
need one more for https://jira.hyperledger.org/browse/FAB-5043 please

dhuseby (Wed, 28 Jun 2017 17:32:15 GMT):
@cbf unless you do all new feature work in feature branches and only merge new features into master once they are baked, documented, and covered with tests (i.e. ready for the next release candidate) you're never going to be able to FF merge master into release

dhuseby (Wed, 28 Jun 2017 17:32:24 GMT):
if you don't use feature branches for all new feature work

dhuseby (Wed, 28 Jun 2017 17:32:28 GMT):
and you FF merge master into release

dhuseby (Wed, 28 Jun 2017 17:32:46 GMT):
the release branch will pick up all of the half-baked, untested features in master

dhuseby (Wed, 28 Jun 2017 17:33:04 GMT):
I think that's the exact opposite of what you want

dhuseby (Wed, 28 Jun 2017 17:33:19 GMT):
that's why the branching proposal I made has feature branches

dhuseby (Wed, 28 Jun 2017 17:33:24 GMT):
if you don't want to do feature branches

dhuseby (Wed, 28 Jun 2017 17:33:31 GMT):
then you need three main branches

dhuseby (Wed, 28 Jun 2017 17:33:35 GMT):
dev, beta, release

dhuseby (Wed, 28 Jun 2017 17:33:46 GMT):
all new feature work would be done on dev

dhuseby (Wed, 28 Jun 2017 17:34:01 GMT):
fully baked, documented, and tested features would be cherry picked over to beta

dhuseby (Wed, 28 Jun 2017 17:34:22 GMT):
beta would always be in a state of building and would only contain fully baked features that are ready for the next release candidate

dhuseby (Wed, 28 Jun 2017 17:34:43 GMT):
then you can tag RC's on the beta branch, test and harden, and then FF from beta to release

dhuseby (Wed, 28 Jun 2017 17:34:48 GMT):
those are the two choices

dhuseby (Wed, 28 Jun 2017 17:35:01 GMT):
three branches, or two branches with feature branches

dhuseby (Wed, 28 Jun 2017 17:35:32 GMT):
if you don't do one of those two things, then you will never be able to FF merge to release without release being filled with half-baked code

dhuseby (Wed, 28 Jun 2017 17:36:12 GMT):
the only other option is to mandate that all half-baked code be behind a runtime switch but that brings on "oops, forgot" syndrome a lot harder and faster than any other approach (IMO)

jyellick (Wed, 28 Jun 2017 17:39:48 GMT):
Assuming we follow the same pattern we did for v1. Master could be feature frozen, and stabilized for a period of time before the FF merge. In general, it seems like we only need a feature branch if we are convinced we need to do feature development during this freeze period.

dhuseby (Wed, 28 Jun 2017 17:56:05 GMT):
@jyellick that's is true, but the reason for feature branches or a separate dev branch is to isolate the releasable code from the development code so that nothing half-baked--even if disabled--ever gets into a release version. The primary reason for this is security.

dhuseby (Wed, 28 Jun 2017 17:56:37 GMT):
half-baked code--even if disabled--can be the source of security vulnerabilities.

dhuseby (Wed, 28 Jun 2017 17:57:11 GMT):
the end goal for high-assurance software is that *only* fully baked, fully documented, and fully tested code is ever in the released version of software.

yacovm (Wed, 28 Jun 2017 18:05:10 GMT):
For the security part I think that we can simply have a simple rule: - Never ever create a commit that introduces a security vulnerability

yacovm (Wed, 28 Jun 2017 18:05:42 GMT):
That means - if feature X needs a security functionality / capability- it doesn't get into gerrit *at all* until the security capability is *in master*

yacovm (Wed, 28 Jun 2017 18:05:42 GMT):
That means - if feature X needs a security functionality / capability- it doesn't get into gerrit *at all* until the security capability is *in master*, and no commits with "// TODO: handle ACL here"

jyellick (Wed, 28 Jun 2017 18:07:03 GMT):
I think the nightmare which is fresh in everyone's mind is when we branched a feature branch for v1 and allowed development on the stable v0.5/v0.6 in master. Despite heroic efforts from @muralisr, @greg.haskins and others, the rate of changes in the two parallel branches was too high to keep up. And it was turning into a full time job, simply merging from one to the other.

greg.haskins (Wed, 28 Jun 2017 20:42:58 GMT):
From my perspective, the issue isn't that the benefits of the proposed branches aren't understood...its that the current Gerrit setup uses a different model than a traditional branch model

greg.haskins (Wed, 28 Jun 2017 20:43:40 GMT):
and unless the proposal takes that into consideration, we are at the risk of repeating the hard to manage setup that existed in the v0.6->v1.0 branch timeframe

greg.haskins (Wed, 28 Jun 2017 20:44:55 GMT):
there are various ways we can approach it: however, the simple approach of "just start using branches" won't do

rezamt (Thu, 29 Jun 2017 04:23:40 GMT):
Has joined the channel.

JonathanLevi (Thu, 29 Jun 2017 14:44:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Es2qu5KMgJ2mPgPoJ)

JonathanLevi (Thu, 29 Jun 2017 14:44:30 GMT):
@rickr - sorry, I didn't have time to deal with this last week (the release, a conference, etc.)

JonathanLevi (Thu, 29 Jun 2017 14:45:19 GMT):
My 2 cents, and it may be a bit (more) general. I can just tell you how things look from my end.

JonathanLevi (Thu, 29 Jun 2017 14:46:07 GMT):
You mention that you feel that you *find it a bit insulting* that XYZ ...

JonathanLevi (Thu, 29 Jun 2017 14:47:03 GMT):
Now let's denote XYZ == "you can't be trusted to the point that we need another approval of another maintainer"

JonathanLevi (Thu, 29 Jun 2017 14:47:54 GMT):
Let me start by stating the "normal" and "dry" answer (that makes me feel like a high-school teacher, but that's fine)

JonathanLevi (Thu, 29 Jun 2017 14:48:54 GMT):
*The way the/our governance models works is that there are a few selected project maintainers that define the rules*, etc. The more formal version of this is posted on the wiki.

JonathanLevi (Thu, 29 Jun 2017 14:49:07 GMT):
So that are two parts to these.

JonathanLevi (Thu, 29 Jun 2017 14:49:25 GMT):
1. Setting the rules and guidelines, by vote.

JonathanLevi (Thu, 29 Jun 2017 14:49:41 GMT):
2. Enforcing them

JonathanLevi (Thu, 29 Jun 2017 14:50:46 GMT):
3. (which is more like 1.b.): Re-examine, (re-)evaluate the rules in 1, see how we perform/what are the results - amend/update as needed.

JonathanLevi (Thu, 29 Jun 2017 14:50:51 GMT):
---

JonathanLevi (Thu, 29 Jun 2017 14:51:47 GMT):
Now, the minute we agree on the rules, and as long as we are not at phase 1 or phase 3... we are at the "enforcement" phase.

JonathanLevi (Thu, 29 Jun 2017 14:52:18 GMT):
So once we set the rules, I, for instance, work like a "dry" rule-engine.

JonathanLevi (Thu, 29 Jun 2017 14:52:55 GMT):
An input is being received, I apply the set of rules over that input, and then I "spit out" an Approve/Reject.

JonathanLevi (Thu, 29 Jun 2017 14:53:17 GMT):
It's like a predicate: *evaluate(input, rules) -> boolean*

JonathanLevi (Thu, 29 Jun 2017 14:54:33 GMT):
And this is how most maintainers (should )work/operate. Some are more vocal/direct, others more passive - but we also have different personalities in this project, which I believe is a great thing.

JonathanLevi (Thu, 29 Jun 2017 14:54:37 GMT):
---

JonathanLevi (Thu, 29 Jun 2017 14:55:33 GMT):
Now, don't take what I'm about to type here in a negative way. It's just some feedback, from my angle.

JonathanLevi (Thu, 29 Jun 2017 14:55:44 GMT):
Here are my observations

JonathanLevi (Thu, 29 Jun 2017 14:55:52 GMT):
1. You care a lot about this project.

JonathanLevi (Thu, 29 Jun 2017 14:56:14 GMT):
2. You contribute a lot (especially in your specific area)

JonathanLevi (Thu, 29 Jun 2017 14:56:26 GMT):
3. We (or at least, I) really appreciate it.

JonathanLevi (Thu, 29 Jun 2017 14:56:28 GMT):
---

JonathanLevi (Thu, 29 Jun 2017 14:56:43 GMT):
Now, here is what I think we should (all) do better

JonathanLevi (Thu, 29 Jun 2017 14:57:22 GMT):
Now, with that in mind, here is my other observation:

JonathanLevi (Thu, 29 Jun 2017 14:57:58 GMT):
If you do not agree with some "rule"/"law"/"agreed upon working assumption" or "practice" that we apply...

JonathanLevi (Thu, 29 Jun 2017 14:58:17 GMT):
... then the first thing to do, is to *strive to amend the rule*.

JonathanLevi (Thu, 29 Jun 2017 14:59:13 GMT):
If *you do not agree with some "rule"/"law"/"agreed upon working assumption" or "practice"* or you believe that *"something does not make sense"* with some existing rule that is being enforces/applied...

JonathanLevi (Thu, 29 Jun 2017 15:00:10 GMT):
... then the first thing to do, is to *strive to amend the rule*, by point it out, and trying to see if *you can convince and get the support of other maintainers first*

JonathanLevi (Thu, 29 Jun 2017 15:00:28 GMT):
... so that we can work to *change the rule/law*.

JonathanLevi (Thu, 29 Jun 2017 15:00:32 GMT):
---

JonathanLevi (Thu, 29 Jun 2017 15:01:18 GMT):
instead, when you keep on providing the same input to the same rule-engine (without any changes to the rules), it feels like you are banging your head against the wall.

JonathanLevi (Thu, 29 Jun 2017 15:01:36 GMT):
And I can clearly see how/that it frustrates you (and possibly others).

JonathanLevi (Thu, 29 Jun 2017 15:02:11 GMT):
I wasn't involved with all the details that lead to your posting the above statement here.... but I can give you a very simple example.

JonathanLevi (Thu, 29 Jun 2017 15:02:38 GMT):
We, the maintainers, agreed on a rule that this is going to be a maintainers only channel. Right?

JonathanLevi (Thu, 29 Jun 2017 15:03:42 GMT):
It wasn't even my suggestion, but *when we have agreed upon it - and decided that this is the accepted guideline/rule/"law" *, then we started applying this rule.

JonathanLevi (Thu, 29 Jun 2017 15:04:01 GMT):
I pointed out to you several times. Right?

JonathanLevi (Thu, 29 Jun 2017 15:04:30 GMT):
But you kept posting here, and I kept remind you of the guidelines, and you kept posting here, yada yada yada.

JonathanLevi (Thu, 29 Jun 2017 15:05:20 GMT):
From some of what you said, I got the impression that you believe that *the rule does not make sense* - which is totally fine!

JonathanLevi (Thu, 29 Jun 2017 15:05:58 GMT):
*But, instead of keeping on posting here, I kept wondering: why are not making a formal proposal/suggestion to change that rule?*

JonathanLevi (Thu, 29 Jun 2017 15:06:13 GMT):
Honestly, that's what I kept asking myself every time you posted here.

JonathanLevi (Thu, 29 Jun 2017 15:06:42 GMT):
I/we were pretty busy with whatever (the release, prioritization, or whatever, right?)...

JonathanLevi (Thu, 29 Jun 2017 15:07:34 GMT):
You could have easily posted the request that we should all consider that, for example, *the maintainers of the fabric SDK should be allowed to write in this channel*

JonathanLevi (Thu, 29 Jun 2017 15:08:27 GMT):
... *naturally, had I seen it, I would have supported it, and would even ask others if they believe we should add the fabric Composer maintainers*, etc.

JonathanLevi (Thu, 29 Jun 2017 15:10:09 GMT):
But again, I could live with the current "rule" and my time/priorities/head were elsewhere. So again, instead of complaining/imploding/getting increasingly-bitter about a rule/practice, first, make a case and put it forward, *way, way earlier*. That's my advice.

JonathanLevi (Thu, 29 Jun 2017 15:11:23 GMT):
To be clear, I'm not suggesting that everything you propose will be accepted. For example, I would not have agreed that a few days before a release-candidate, we will allow a single person to merge changes to the master branch, and I would have explained my reasoning.

JonathanLevi (Thu, 29 Jun 2017 15:12:16 GMT):
But hey, that would have been only one (Jonathan's) vote. If you make a good case and the majority approves it - then, BOOM, you have made fabric great again! (joking ;-))

JonathanLevi (Thu, 29 Jun 2017 15:13:24 GMT):
I know that this governance model has some overheads, etc., but that same model would not allow us to disable a rule temporarily just because another SDK maintainer (Jim, in this case) is/was away for a week or two.

JonathanLevi (Thu, 29 Jun 2017 15:13:33 GMT):
---

JonathanLevi (Thu, 29 Jun 2017 15:14:22 GMT):
Anyway, I felt that I should spend enough time to relate to that post of yours here, when I have a change.

JonathanLevi (Thu, 29 Jun 2017 15:14:35 GMT):
Mainly because of https://chat.hyperledger.org/channel/fabric-maintainers?msg=FoxhiD8QpjegZ88ST

JonathanLevi (Thu, 29 Jun 2017 15:14:51 GMT):
Hope you see what I mean.

JonathanLevi (Thu, 29 Jun 2017 15:18:21 GMT):
====== On the other topic:

JonathanLevi (Thu, 29 Jun 2017 15:18:29 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=znqRuEjRBBHuQucQ8)

JonathanLevi (Thu, 29 Jun 2017 15:18:59 GMT):
I tend to agree with @jyellick and @greg.haskins

JonathanLevi (Thu, 29 Jun 2017 15:19:30 GMT):
Another data point that we should not forget to take into a consideration... it is very plausible that one we "open the gate" and allow people to contribute to the next version (v1.1)... we are going to have several more companies/organizations/groups and individuals that have been waiting (sometimes, patiently) for us to stabilize the *master* brach (1.0, which will serve as the baseline).

JonathanLevi (Thu, 29 Jun 2017 15:20:41 GMT):
There have been so many requests that we have postponed following the maintainers' agreement on not doing anything before we stabilize the master branch (for 1.0)... these did not go away.

JonathanLevi (Thu, 29 Jun 2017 15:21:27 GMT):
What I'm basically saying is that we should really think the (development) branching proposal carefully.

JonathanLevi (Thu, 29 Jun 2017 15:23:26 GMT):
BTW: As a reminder, if part of the suggestion/proposal will be that we want to work with a branching model that is easier on Github, much more so than in Gerrit... by all means, let's list it as part of the things we should consider.

JonathanLevi (Thu, 29 Jun 2017 15:24:16 GMT):
We did put some of these "on hold" when we were in the "midst of stabilizing" the master branch, but these arguments were not forgotten...

cbf (Thu, 29 Jun 2017 16:30:06 GMT):
I'm willing to take a fresh look at GitHUb, but I don't believe that it will yield the same level of support for reviews. Maybe there are add-ons we could leverage. Also, I don't believe that GH Issues are adequate, either. However, I will go into it with an open mind. Of course, I am also mindful as @JonathanLevi said that there is a lot of pent up demand and we should not slow that down any longer than we already have.

greg.haskins (Fri, 30 Jun 2017 11:38:58 GMT):
@cbf I dont think we need to abandon gerrit per se, at least not for that reason

greg.haskins (Fri, 30 Jun 2017 11:39:28 GMT):
for example: even if we switched back to GH, we would have to decide how branches are handled

greg.haskins (Fri, 30 Jun 2017 11:41:03 GMT):
e.g. do we expect users to push (I doubt it)? Would maintainers be responsible for merging development branch stuff out manually and they push? Would we have automation to merge stuff out when it passes some criteria?

greg.haskins (Fri, 30 Jun 2017 11:41:23 GMT):
and I would point out, options B and C would not be predicated on moving away from gerrit

greg.haskins (Fri, 30 Jun 2017 11:42:07 GMT):
for B, we could enable the merging in gerrit again (there are a few challenges with how this works that we need to be careful of)

greg.haskins (Fri, 30 Jun 2017 11:42:27 GMT):
for C, we could have that automation work against either GH or Gerrit, it wouldnt matter

greg.haskins (Fri, 30 Jun 2017 11:42:49 GMT):
and all I have ever really pushed for was something like C

greg.haskins (Fri, 30 Jun 2017 11:42:55 GMT):
(because B sucks ;)

greg.haskins (Fri, 30 Jun 2017 11:43:13 GMT):
but in addition to C, I also said that we shouldnt cut to the branch model until C is in place

greg.haskins (Fri, 30 Jun 2017 11:44:07 GMT):
with regards to ideas on what this might look like: I imagine it like a CICD pipeline where the _front_ end of the pipeline is the gerrit approval

greg.haskins (Fri, 30 Jun 2017 11:45:21 GMT):
and that kicks off a process which runs the patch through a rigorous process, the end result being a merge to some "stable" branch

greg.haskins (Fri, 30 Jun 2017 11:48:00 GMT):
so, basically, CRs are "feature branches" (they really are when you think about it), and some other branch (like "master") is your stable branch

greg.haskins (Fri, 30 Jun 2017 11:48:59 GMT):
and things only move to stable via a combination of human review/approval (gerrit) and an automated test suite (jenkins)

greg.haskins (Fri, 30 Jun 2017 11:49:40 GMT):
then, if we want to have a second level (to move stable to release, etc) we could just repeat that template

cbf (Fri, 30 Jun 2017 11:49:50 GMT):
they are, but we also have a policy of keeping CRs limited in size so that they can be reviewed

greg.haskins (Fri, 30 Jun 2017 11:49:58 GMT):
agreed

greg.haskins (Fri, 30 Jun 2017 11:50:07 GMT):
and I also agree that is important

cbf (Fri, 30 Jun 2017 11:50:12 GMT):
a code dump of 5kLOC for a new feature would be a good long weekend of review

greg.haskins (Fri, 30 Jun 2017 11:50:17 GMT):
(and actually, kind of one of my main points

greg.haskins (Fri, 30 Jun 2017 11:50:49 GMT):
if we can take anything away from the CICD concept, its that branching is the antithesis

greg.haskins (Fri, 30 Jun 2017 11:51:10 GMT):
small verifiable changes to a small stream, so you can do integration/verification

cbf (Fri, 30 Jun 2017 11:51:19 GMT):
I think we should start requiring feature flags for new features/function that are then developed iteratively

yacovm (Fri, 30 Jun 2017 11:51:35 GMT):
It's not only that. If you have 2 feature branches that have conflicts - when 1 of them is merged the other one will have lots of refactoring (sort of merge conflict resolution) to do, and that is very error prone

yacovm (Fri, 30 Jun 2017 11:52:37 GMT):
In contrast- if you use the gerrit "flow" - you move in small steps and if there is a regression it's pretty easy to identify the problem.

greg.haskins (Fri, 30 Jun 2017 11:52:47 GMT):
@yacovm right, and that is always going to be the case no matter which model...so if you try to keep things as small changes with true "continuous integration" you can avoid the worst effects of that

yacovm (Fri, 30 Jun 2017 11:52:48 GMT):
with merging of feature branches it's going to be very hard.

greg.haskins (Fri, 30 Jun 2017 11:52:55 GMT):
agreed

greg.haskins (Fri, 30 Jun 2017 11:53:06 GMT):
the world is moving away from big-branch-development

greg.haskins (Fri, 30 Jun 2017 11:53:18 GMT):
and more to single-stream delivery

cbf (Fri, 30 Jun 2017 11:53:19 GMT):
right, hence why I am pushing for more and more testing beyond the UT we have

cbf (Fri, 30 Jun 2017 11:53:50 GMT):
including nightly and weekly tests, destructive and long-running tests etc

yacovm (Fri, 30 Jun 2017 11:53:57 GMT):
so I think that Dave Huseby had a point regarding the 3 branches- (master, release and pre-release that is in between)

yacovm (Fri, 30 Jun 2017 11:54:05 GMT):
I think though that it's possible to have only 2 branches

greg.haskins (Fri, 30 Jun 2017 11:54:06 GMT):
so based on this, I do not think the gerrit model is "bad"...i just think we need more plumbing on the output ;)

yacovm (Fri, 30 Jun 2017 11:54:10 GMT):
and create some branch in between

yacovm (Fri, 30 Jun 2017 11:54:16 GMT):
when doing the "shift"

cbf (Fri, 30 Jun 2017 11:54:30 GMT):
well, yes agree... and we DO need a better process for release cutting

cbf (Fri, 30 Jun 2017 11:54:45 GMT):
because currently, we cannot test a release until it is cut

greg.haskins (Fri, 30 Jun 2017 11:55:12 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=MLu6hRYYN5ZkKaSwA) @cbf yeah, agree with all of that

cbf (Fri, 30 Jun 2017 11:55:29 GMT):
so we need a process NOT based on a tag, but based on a commit

greg.haskins (Fri, 30 Jun 2017 11:55:53 GMT):
right

yacovm (Fri, 30 Jun 2017 11:56:00 GMT):
I strongly agree on the plumbing. We have e2e and it's stable, right? I believe that we *can* get eventually to a state where we have good integration tests

yacovm (Fri, 30 Jun 2017 11:56:04 GMT):
it's just a matter of work hours

cbf (Fri, 30 Jun 2017 11:56:10 GMT):
yes

greg.haskins (Fri, 30 Jun 2017 11:56:24 GMT):
each build produces artifacts that can be reference by the build-id, and if its "good", then its a candidate for tagging

greg.haskins (Fri, 30 Jun 2017 11:57:42 GMT):
ill just throw one more thing out there: if we did this "right", there would be no need to make a distinction between master and release

greg.haskins (Fri, 30 Jun 2017 11:58:28 GMT):
for a sufficiently rigorous verification pipeline, each commit that passes could be considered a release...just like how a CICD pipeline promotes a deployment

greg.haskins (Fri, 30 Jun 2017 11:58:47 GMT):
but in our case, a "deployment" is just release artifacts and a commit to a branch

greg.haskins (Fri, 30 Jun 2017 11:59:06 GMT):
the rub is in the "sufficiently rigorous verification pipeline", which we arent there yet

cbf (Fri, 30 Jun 2017 12:00:03 GMT):
yes, but we are a ways off from that state of CD

greg.haskins (Fri, 30 Jun 2017 12:00:11 GMT):
agreed

greg.haskins (Fri, 30 Jun 2017 12:00:50 GMT):
so, for the time being, we could take that approach but with a few tiers

cbf (Fri, 30 Jun 2017 12:01:56 GMT):
because there is also a certain degree of discipline about that such that there is provision for live upgrades between commits (not just releases) and a maturity of consumption that is willing and able to consume at that rate

muralisr (Fri, 30 Jun 2017 12:03:16 GMT):
`, there would be no need to make a distinction between master and release` - if we enforce the discipline of introduction of new features incrementally, why wouldn't we treat each new feature as a series of simple CRs that can just be pushed to master

muralisr (Fri, 30 Jun 2017 12:03:41 GMT):
is it because its hard to enforce that discipline ?

cbf (Fri, 30 Jun 2017 12:08:15 GMT):
@muralisr we currently do... what we haven't done is feature flags that enable/disable the new feature

cbf (Fri, 30 Jun 2017 12:08:33 GMT):
can be enabled for testing and disabled for release until it is fully baked

muralisr (Fri, 30 Jun 2017 12:31:41 GMT):
@cbf so basically what we are saying is till such time we do the above we need an alternate branch strategy ? (get the feeling this might have all been discussed .. :-) )

cbf (Fri, 30 Jun 2017 12:36:42 GMT):
@muralisr no, we are deliberating 2 or 3 branch strategy presently

cbf (Fri, 30 Jun 2017 12:36:55 GMT):
the proposal we agreed to uses two

cbf (Fri, 30 Jun 2017 12:37:00 GMT):
master and release

cbf (Fri, 30 Jun 2017 12:37:19 GMT):
@dhuseby suggests we also need pre-release branch

cbf (Fri, 30 Jun 2017 12:38:09 GMT):
the point has some merit but what we were discussing is that we need to change the whole process by which we cut a release to be independent of tag anyway

cbf (Fri, 30 Jun 2017 12:38:20 GMT):
a third pre-release branch might serve that need

cbf (Fri, 30 Jun 2017 12:38:46 GMT):
but we could also use master for this

cbf (Fri, 30 Jun 2017 12:39:55 GMT):
what I believe, though, is that we should cut over to a two branch model soon so that we can unleash post 1.0 development again - BUT that we do that in a disciplined manner

cbf (Fri, 30 Jun 2017 12:41:01 GMT):
eg breaking changes should be disallowed to be merged unless we get maintainer consensus agreement that we will release a new major release

yacovm (Fri, 30 Jun 2017 12:41:10 GMT):
The question is - how often do we release and do we allow code in the release branch to exist even though it's not in use?

cbf (Fri, 30 Jun 2017 12:41:26 GMT):
my preference would be release about every 3 months

yacovm (Fri, 30 Jun 2017 12:41:31 GMT):
i.e a squad develops feature X via merging to master a change set at a time, and this code isn't "activated"

cbf (Fri, 30 Jun 2017 12:41:37 GMT):
2 if we can push it

yacovm (Fri, 30 Jun 2017 12:41:39 GMT):
and let's say they don't make it in time to the release

yacovm (Fri, 30 Jun 2017 12:41:45 GMT):
what happens to the code that's in master?

cbf (Fri, 30 Jun 2017 12:41:50 GMT):
the integration tests need to be more robust I think for that

yacovm (Fri, 30 Jun 2017 12:41:57 GMT):
I think as long as it's not "activated" it's not that bad that it's there no?

cbf (Fri, 30 Jun 2017 12:41:58 GMT):
feature flag

cbf (Fri, 30 Jun 2017 12:42:04 GMT):
right

cbf (Fri, 30 Jun 2017 12:42:18 GMT):
and we make clear in release notes it is NOT supported

cbf (Fri, 30 Jun 2017 12:42:24 GMT):
use at your own risk

yacovm (Fri, 30 Jun 2017 12:42:35 GMT):
but at the same time we removed the whole sBFT code from the release

yacovm (Fri, 30 Jun 2017 12:42:38 GMT):
not just the YAML annotations

cbf (Fri, 30 Jun 2017 12:42:59 GMT):
yes, we'll restore that soon

cbf (Fri, 30 Jun 2017 12:43:12 GMT):
we also hard coded disabling of javacc

yacovm (Fri, 30 Jun 2017 12:43:20 GMT):
ok

jyellick (Fri, 30 Jun 2017 12:46:16 GMT):
One problem with this would seem to be maintaining the (IMO) somewhat artificial code coverage metrics. If we allow for not fully tested function into the release, I expect we'll see those numbers plummet. For instance adding SBFT back in alone will have a significant effect.

cbf (Fri, 30 Jun 2017 12:47:17 GMT):
@jyellick yes, well... certainly from my POV, tests SHOULD be merged WITH code not after the fact;-)

jyellick (Fri, 30 Jun 2017 12:52:12 GMT):
Agreed, though that does not help us in the SBFT case, and although I realize unit test is not for integration test, a feature which isn't fully implemented necessarily may not yet be able to pass tests for that feature. I'd much rather have a unit test which covers a real code flow than great coverage numbers which just test for existing bugs.

greg.haskins (Fri, 30 Jun 2017 12:54:32 GMT):
@jyellick ideally, we dont have any massive commit to the code base...just a stream of small, easy to review, fully meeting quality/lint/coverage standards CRs that may or may not be "active" by default

greg.haskins (Fri, 30 Jun 2017 12:54:54 GMT):
and ideally, for each inactive feature, a CI matrix which still tests them enabled but does not gate the release flow

greg.haskins (Fri, 30 Jun 2017 12:55:23 GMT):
in that ideal, something like SBFT would be trickled in as a CR series

jyellick (Fri, 30 Jun 2017 12:56:32 GMT):
+1 to not bring SBFT back in wholesale and instead breaking it into a CR series

cbf (Fri, 30 Jun 2017 13:00:34 GMT):
agreed that would be ideal

cbf (Fri, 30 Jun 2017 13:01:43 GMT):
and of course, by definition it is a plugin and so we could construct the release such that it was excluded in the release artifacts, no?

cbf (Fri, 30 Jun 2017 13:01:55 GMT):
(without removing the code)

jyellick (Fri, 30 Jun 2017 13:03:41 GMT):
Certainly. Would you expect this to be an automated process or a manual one?

jyellick (Fri, 30 Jun 2017 13:07:42 GMT):
I know there has been some talk of moving to go 1.8. I hear the dynamic linking is not great, but we could potentially use this to achieve that goal without resorting to dynamic code generation.

cbf (Fri, 30 Jun 2017 14:25:44 GMT):
I think like we have done with pkcs11 make it a build option

cbf (Fri, 30 Jun 2017 19:34:30 GMT):
Please review and vote https://jira.hyperledger.org/browse/FAB-4542?focusedCommentId=27723&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-27723

mrkiouak (Sat, 01 Jul 2017 21:04:53 GMT):
So, I'm seeing a ton of churn in code again... the ca certs vs tls certs, plus move of examples out of some repositories--- these do not seem at all like the sorts of changes that should be happening after a release-candidate tag. I'm not a maintainer, but I'm having deja vue to February or so when the install, instantiate change was made, TLS was first introduced etc. At that time my sense was that was recognized as a necessary evil by the maintaining team in order to get the last major changes in in a run up to a v1 release. My initial sense of looking over the https://jira.hyperledger.org/browse/FAB-4626 and fabric-samples creation is that its dis-ingenuous to be marking these beta, let alone release candidates. I do not expect rcs to have this many api breakages and changes... Anyways, again I'm not a maintainer, but I hope a conversation could be had on this. I don't see any documented reference to the ca cert vs tls ca certs in getting started or first network and did not see any documentation included in the above linked issues & associated CRs at first glance. I think its critically important that fabric have the stability and associated documentation and examples to easily understand and stand up on release, and I think these sorts of changes are counter productive to this goal, particularly while announcing exit of incubation and release candidates progress.

cbf (Sat, 01 Jul 2017 21:49:37 GMT):
moving examples isn't churn, we did that to make them more accessible without the entire code base

cbf (Sat, 01 Jul 2017 21:51:48 GMT):
one of the main foci has been improving the documentation and the initial developer experience

cbf (Sat, 01 Jul 2017 21:52:32 GMT):
if you have feedback on things we could add to the documentation to improve it, we would welcome it gladly

mrkiouak (Sat, 01 Jul 2017 22:01:21 GMT):
a client that previously used it's ca cert for tls no longer functions. the fabric/example/cluster emits a client.config that should provide all that a client needs in order to communicate with a peer (or at least, this is how the example has functioned since it was added). with the recent split of ca cerrts and tls certs, the examples from e.g. fabric-chaintool/examples (any, but example02 for sake of conversation) no longer work

mrkiouak (Sat, 01 Jul 2017 22:01:46 GMT):
theres currently no client documentation (that i can find) for any of the sdks that describe how their api supports the new ca cert plus tlsca cert format

mrkiouak (Sat, 01 Jul 2017 22:02:34 GMT):
i don't think its unreasonable to expect examples that are part of the core fabric repo to no longer support a given client interaction they previously have-- perhaps this is related to the fabric-samples move

mrkiouak (Sat, 01 Jul 2017 22:12:39 GMT):
the addition of a startup option to use ca certs as tls cert also seems like an appropriate part of this change particularly considering its inclusion in rc stage-- this would have allowed for the, admittedly important, separation of ca certs and tls certs and corresponding management, while not breaking any existing behavior in a final beta, early rc stage.

JonathanLevi (Sat, 01 Jul 2017 22:52:38 GMT):
Hello @mrkiouak ! 1. Thanks for these ^^^ 2. Can we move this discussion to #fabric-release? 3. Will you be kind enough to create/open detailed JIRA tickets?

greg.haskins (Sun, 02 Jul 2017 13:33:21 GMT):
Hi all, FYI I am on family holiday until the 17th. Availability will be spotty at best

JonathanLevi (Sun, 02 Jul 2017 20:41:43 GMT):
Have a good time @greg.haskins !

alburt (Mon, 03 Jul 2017 10:49:44 GMT):
Has joined the channel.

paapighoda (Mon, 03 Jul 2017 15:12:48 GMT):
Has joined the channel.

greg.haskins (Wed, 05 Jul 2017 02:47:33 GMT):
@mastersingh24 https://jira.hyperledger.org/browse/FAB-5177

greg.haskins (Wed, 05 Jul 2017 02:49:45 GMT):
https://jira.hyperledger.org/browse/FAB-4883

greg.haskins (Wed, 05 Jul 2017 02:50:10 GMT):
@mastersingh24 Those are the issues we spoke of the other day privately

greg.haskins (Wed, 05 Jul 2017 02:50:35 GMT):
@cbf @JonathanLevi ^^^ Those two need to be addressed before cutting v1.0 IMO

greg.haskins (Wed, 05 Jul 2017 02:53:10 GMT):
FAB-4883 is solved here: https://gerrit.hyperledger.org/r/#/c/10967/...the WIP tag is because I wanted to clean up the comments/commit-msg

greg.haskins (Wed, 05 Jul 2017 02:53:10 GMT):
FAB-5177 doesnt have a CR but the solution is simple: We just need to stop packing the shim into the ccenv (via the Makefile) and also adjust the "peer package" logic to not filter the shim out any more

greg.haskins (Wed, 05 Jul 2017 02:54:15 GMT):
given that I am on holiday and I unfortunately/fortunately (depending on who you ask) didn't bring my work laptop with me it will be a little tough for me to crank those out

greg.haskins (Wed, 05 Jul 2017 02:54:59 GMT):
i do have a little meager MacBook Air with me, currently devoid of Hyperledger tools, but ill see what I can do

greg.haskins (Wed, 05 Jul 2017 02:56:10 GMT):
also, if we decide to move on 5177, ill need to update chaintool to match...though I think we can safely move on this is a point release after v1.0

greg.haskins (Wed, 05 Jul 2017 02:56:22 GMT):
e.g. v1.0.1 has a chaintool update

JonathanLevi (Wed, 05 Jul 2017 09:11:44 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=sh465rsdgcNsWpFfv) I agree.

JonathanLevi (Wed, 05 Jul 2017 09:11:45 GMT):
---

JonathanLevi (Wed, 05 Jul 2017 09:11:57 GMT):
Is the e2e test/build failing ?

JonathanLevi (Wed, 05 Jul 2017 09:12:24 GMT):
https://jenkins.hyperledger.org/view/fabric/job/fabric-merge-end-2-end-x86_64/930/

JonathanLevi (Wed, 05 Jul 2017 09:13:06 GMT):
https://jenkins.hyperledger.org/view/fabric/job/fabric-merge-end-2-end-x86_64/ Failed Build #930 (Jul 4, 2017 7:29:33 PM) is red.

JonathanLevi (Wed, 05 Jul 2017 09:13:06 GMT):
https://jenkins.hyperledger.org/view/fabric/job/fabric-merge-end-2-end-x86_64/ Failed Build #930 (Jul 4, 2017 7:29:33 PM) (It is red since the last merge, I believe)

yacovm (Wed, 05 Jul 2017 10:01:45 GMT):
@cbf @JonathanLevi I would like to get https://jira.hyperledger.org/browse/FAB-5165 in. It's a minimal change - just adding 8 lines and removing 20 lines and it fixes a very deep performance problem in gossip

JonathanLevi (Wed, 05 Jul 2017 10:22:51 GMT):
I agree and so does @mastersingh24. Any objections here?

JonathanLevi (Wed, 05 Jul 2017 10:23:31 GMT):
For formality, let's add a vote quickly?

JonathanLevi (Wed, 05 Jul 2017 10:23:43 GMT):
https://jira.hyperledger.org/browse/FAB-5165

sstone1 (Wed, 05 Jul 2017 10:35:09 GMT):
@JonathanLevi are you considering an RC2 after all these changes go in?

JonathanLevi (Wed, 05 Jul 2017 10:35:56 GMT):
I'm not 100% sure yet. I am actually waiting on an external security analysis report/results...

JonathanLevi (Wed, 05 Jul 2017 10:36:36 GMT):
External, meaning, being carried by a third party...

sstone1 (Wed, 05 Jul 2017 10:36:50 GMT):
ah okay

sstone1 (Wed, 05 Jul 2017 10:37:38 GMT):
FAB-5177 worries me a bit - is there any impact to existing applications installing chaincode using the Node.js SDK?

sstone1 (Wed, 05 Jul 2017 10:38:01 GMT):
you might not know, so I'll @greg.haskins on that one ;)

sstone1 (Wed, 05 Jul 2017 10:38:31 GMT):
we don't vendor the shim so I'm thinking probably not, and the auto vendor magic will take care of it for us

JonathanLevi (Wed, 05 Jul 2017 10:38:32 GMT):
Yes, yes, I'm well aware of these.

JonathanLevi (Wed, 05 Jul 2017 10:38:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=FxJu7aFricdQPqxyg)

sstone1 (Wed, 05 Jul 2017 10:39:00 GMT):
ah, i forget, you know everything ;)

JonathanLevi (Wed, 05 Jul 2017 10:39:12 GMT):
At least, everything that's posted here ;-)

JonathanLevi (Wed, 05 Jul 2017 10:39:51 GMT):
Trying to, at the very least. Speaking of which, would you object to 5177 ?

JonathanLevi (Wed, 05 Jul 2017 10:40:09 GMT):
Or would you suggest that if we merge it, we should add another milestone?

sstone1 (Wed, 05 Jul 2017 10:40:20 GMT):
i don't object to it but it seems a big change to sneak into the 1.0 final release, which is why i wondered if you were cutting an rc2

JonathanLevi (Wed, 05 Jul 2017 10:40:42 GMT):
We should probably move these discussions to the #fabric-release channel. I first wanted to hear back from the maintainters...

JonathanLevi (Wed, 05 Jul 2017 10:40:57 GMT):
OK, noted. @sstone1.

JonathanLevi (Wed, 05 Jul 2017 10:41:45 GMT):
In a line: we don't know yet whether we are going for an RC2. Trying to collect "all" info today and tomorrow...

sstone1 (Wed, 05 Jul 2017 10:42:00 GMT):
:+1: ok, thanks - will keep my eye out for updates

JonathanLevi (Wed, 05 Jul 2017 10:42:09 GMT):
Thank you.

JonathanLevi (Wed, 05 Jul 2017 11:04:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=8kPj8XnSkkgNEyGB6) @sstone1, can you pls do me a favor?

sstone1 (Wed, 05 Jul 2017 11:04:28 GMT):
depends

JonathanLevi (Wed, 05 Jul 2017 11:04:32 GMT):
Can you please post this comment of yours on the JIRA ticket?

sstone1 (Wed, 05 Jul 2017 11:04:35 GMT):
sure

JonathanLevi (Wed, 05 Jul 2017 11:05:37 GMT):
Something along the lines of "I would caution against getting this merged right now if we are still on track to releasing the "ga" version very soon, skipping the v1.0.0-rc2"

JonathanLevi (Wed, 05 Jul 2017 11:06:17 GMT):
Or something along these lines. Mind you, I have lived outside on London for so many years... these carefully worded "reservations" do not come as natural to me as they used to ;-)

JonathanLevi (Wed, 05 Jul 2017 11:06:17 GMT):
Or something along these lines. Mind you, I have lived outside of London for so many years... these carefully worded "reservations" do not come as natural to me as they used to ;-)

sstone1 (Wed, 05 Jul 2017 11:08:03 GMT):
done

JonathanLevi (Wed, 05 Jul 2017 11:08:37 GMT):
Thank you. This way, everybody can see this (voting maintainers and others). Cheers.

sstone1 (Wed, 05 Jul 2017 11:09:10 GMT):
np

muralisr (Wed, 05 Jul 2017 12:14:50 GMT):
@greg.haskins The autovendoring that's currently in place is technically not "wrong"... https://gerrit.hyperledger.org/r/#/c/10967 makes it nicer but code as it stands works as well I think. Agree ? I had added a comment to https://jira.hyperledger.org/browse/FAB-4883 with details

muralisr (Wed, 05 Jul 2017 12:15:45 GMT):
@JonathanLevi @mastersingh24 ^^ just FYI... will pull https://gerrit.hyperledger.org/r/#/c/10967 and test so we can go with that if thats what we want to do

yacovm (Wed, 05 Jul 2017 12:17:16 GMT):
Is there a workaround for the vendoring issue?

greg.haskins (Wed, 05 Jul 2017 12:37:55 GMT):
@muralisr no, CR 10967 is not cosmetic. @C0rWin pointed out an issue where a chaincode that is written under fabric/examples/chaincode would autovendor wrong

greg.haskins (Wed, 05 Jul 2017 12:38:16 GMT):
it turned out the problem was more generic than fabric/examples

greg.haskins (Wed, 05 Jul 2017 12:39:07 GMT):
Basically the current code assumes $pkg and $pkg/vendor should not auto-vendor

greg.haskins (Wed, 05 Jul 2017 12:39:52 GMT):
The CR fixes that assumption so that the vendor folder is not assumed to be in the final $pkg/vendor location

muralisr (Wed, 05 Jul 2017 12:40:19 GMT):
@greg.haskins I used @C0rWin chaincode under "github.com/hyperledger/fabric/mycc" and deployed it successfully

muralisr (Wed, 05 Jul 2017 12:40:32 GMT):
(before the fix)

greg.haskins (Wed, 05 Jul 2017 12:40:56 GMT):
Try one with a deeper hierarchy

muralisr (Wed, 05 Jul 2017 12:40:58 GMT):
and also vaguely recall discussing the multiple "vendor" scenario

greg.haskins (Wed, 05 Jul 2017 12:41:37 GMT):
But try this scenario:

greg.haskins (Wed, 05 Jul 2017 12:41:56 GMT):
Chaincode pkg foo/bar/baz

greg.haskins (Wed, 05 Jul 2017 12:42:25 GMT):
Vendor some things in GOPATH/src/foo/vendor

greg.haskins (Wed, 05 Jul 2017 12:43:12 GMT):
What should happen is that "foo/vendor/$dep" remains unchanged

muralisr (Wed, 05 Jul 2017 12:43:32 GMT):
right

muralisr (Wed, 05 Jul 2017 12:43:50 GMT):
the chaincode's original vendoring should remain

muralisr (Wed, 05 Jul 2017 12:43:59 GMT):
and it doesn't ?

greg.haskins (Wed, 05 Jul 2017 12:44:02 GMT):
But mainline will auto vendor that was foo/bar/baz/vendor/foo/vendor/$dep

greg.haskins (Wed, 05 Jul 2017 12:44:27 GMT):
This CR will fix that scenario

muralisr (Wed, 05 Jul 2017 12:44:30 GMT):
oh wait I misunderstood

muralisr (Wed, 05 Jul 2017 12:44:36 GMT):
will experiment

muralisr (Wed, 05 Jul 2017 12:44:50 GMT):
I was going by @C0rWin original scenario

greg.haskins (Wed, 05 Jul 2017 12:45:30 GMT):
The basic gist is mainline doesn't understand that golang censoring can happen at any level of the package

greg.haskins (Wed, 05 Jul 2017 12:45:45 GMT):
Vendoring not censoring

greg.haskins (Wed, 05 Jul 2017 12:45:53 GMT):
Autocorrect

muralisr (Wed, 05 Jul 2017 12:45:57 GMT):
:-)

muralisr (Wed, 05 Jul 2017 12:46:49 GMT):
foo/bar/baz/vendor/foo/vendor/$dep would work just as well, or wouldn't it ?

greg.haskins (Wed, 05 Jul 2017 12:46:55 GMT):
Afaik, the only thing missing in CR 10967 is good comments/commit messagr

muralisr (Wed, 05 Jul 2017 12:47:14 GMT):
just that it would become chaincode's vendor

greg.haskins (Wed, 05 Jul 2017 12:48:07 GMT):
I suspect it might, if but look strange. But I also recall that @C0rWin found this because something was failing

muralisr (Wed, 05 Jul 2017 12:48:20 GMT):
ok

greg.haskins (Wed, 05 Jul 2017 12:48:51 GMT):
The more critical decision for 1.0 is the shim/no-shim decision

muralisr (Wed, 05 Jul 2017 12:49:03 GMT):
I didn't read that it failed for him (just that it looked strange)

muralisr (Wed, 05 Jul 2017 12:49:03 GMT):
I didn't read that it failed for him (just that it looked strange) ... but could be wrong about this

muralisr (Wed, 05 Jul 2017 12:49:09 GMT):
but will definitely experiment

greg.haskins (Wed, 05 Jul 2017 12:49:51 GMT):
There seem to be way too much fragility in pre-including the shim

muralisr (Wed, 05 Jul 2017 12:49:57 GMT):
ok

greg.haskins (Wed, 05 Jul 2017 12:50:27 GMT):
Play with the shim time stamp interface and I think you will see what I mean

yacovm (Wed, 05 Jul 2017 12:50:54 GMT):
Isn't there a workaround for the issue, Greg?

greg.haskins (Wed, 05 Jul 2017 12:50:54 GMT):
Iirc

greg.haskins (Wed, 05 Jul 2017 12:51:16 GMT):
@yacovm which?

yacovm (Wed, 05 Jul 2017 12:51:29 GMT):
Can't you just put the imports according to what the shim would "see"

yacovm (Wed, 05 Jul 2017 12:51:34 GMT):
although it doesn't compile in the IDE?

yacovm (Wed, 05 Jul 2017 12:51:41 GMT):
it's stupid but won't it work?

greg.haskins (Wed, 05 Jul 2017 12:51:43 GMT):
Not that I am aware of

yacovm (Wed, 05 Jul 2017 12:52:03 GMT):
but if you think of it - the chaincode shim gets files in some way, right?

greg.haskins (Wed, 05 Jul 2017 12:52:17 GMT):
Besides even if true, that's hacky. Let's get this right before 1.0

yacovm (Wed, 05 Jul 2017 12:52:18 GMT):
can't you "predit" this file structure

yacovm (Wed, 05 Jul 2017 12:52:35 GMT):
and then write the CC in the way it would work when it would be compiled in the container?

greg.haskins (Wed, 05 Jul 2017 12:55:45 GMT):
I'm not sure. But I am of the opinion that the mechanism of pre-including the deps is fragile in general, and of less value now that we can auto vendor... therefore the more conservative step is to eliminate the feature for 1.0 and we can revisit optimization in a future release

greg.haskins (Wed, 05 Jul 2017 12:56:37 GMT):
It's not just the time stamp thing. There is a good deal of other fragility that I have seen come across my desk

greg.haskins (Wed, 05 Jul 2017 12:58:16 GMT):
Therefore, the proposal would be to stop assuming the ABI at the shim/golang level (which is poorly managed) and shift to relying on the protobuf/grpc level (which was designed for this)

greg.haskins (Wed, 05 Jul 2017 12:59:47 GMT):
I also think we should shift SDK thinking to only support "peer package" / "chaintool package" outputs, rather than trying to replicate the packagers

greg.haskins (Wed, 05 Jul 2017 13:00:09 GMT):
Which, with auto vendoring especially, are not trivial

muralisr (Wed, 05 Jul 2017 13:02:06 GMT):
`I also think we should shift SDK thinking to only support "peer package" / "chaintool package" outputs, rather than trying to replicate the packagers` ... agree with that (but can be done post 1.0). Will also make it easy to keep all SDKs uniform

greg.haskins (Wed, 05 Jul 2017 13:02:32 GMT):
Agree SDK can be post release

greg.haskins (Wed, 05 Jul 2017 13:02:56 GMT):
The decision to stop packaging the shim should not wait though

muralisr (Wed, 05 Jul 2017 13:02:58 GMT):
but if we don't include the shim now we can't use the APIs (such as timestamp) it exposes

muralisr (Wed, 05 Jul 2017 13:03:03 GMT):
true ?

muralisr (Wed, 05 Jul 2017 13:03:19 GMT):
ie it will break existing aps

greg.haskins (Wed, 05 Jul 2017 13:04:08 GMT):
Well, the idea would be that the auto vendor logic would package whatever version of the shim/timestamp-lib the chaincode author used

greg.haskins (Wed, 05 Jul 2017 13:04:23 GMT):
Not that it couldn't be used

greg.haskins (Wed, 05 Jul 2017 13:05:24 GMT):
Right now the dep is stripped from the package with the assumption that ccenv will satisfy it

greg.haskins (Wed, 05 Jul 2017 13:06:26 GMT):
Which is proving to be unreliable given the way golang, GOPATH, vendoring, and ABI differences work

muralisr (Wed, 05 Jul 2017 13:06:32 GMT):
right

muralisr (Wed, 05 Jul 2017 13:06:37 GMT):
```import ( "github.com/golang/protobuf/ptypes/timestamp" "github.com/hyperledger/fabric/protos/ledger/queryresult" pb "github.com/hyperledger/fabric/protos/peer" )```

muralisr (Wed, 05 Jul 2017 13:06:53 GMT):
those are the deps in the interfaces

muralisr (Wed, 05 Jul 2017 13:08:24 GMT):
let me make sure I understand Greg... so basically this would mean two things (1) remove ccenv and (2) change autovendoring to add those if found

greg.haskins (Wed, 05 Jul 2017 13:08:55 GMT):
Not quite: we still want ccenv

greg.haskins (Wed, 05 Jul 2017 13:09:39 GMT):
Change would be to stop injecting the goshim.tar.gz into it, and to stop filtering the shim from the packager

muralisr (Wed, 05 Jul 2017 13:09:51 GMT):
oops I meant remove shim from ccenv

greg.haskins (Wed, 05 Jul 2017 13:09:57 GMT):
Right

muralisr (Wed, 05 Jul 2017 13:10:00 GMT):
and

muralisr (Wed, 05 Jul 2017 13:10:03 GMT):
``` // -------------------------------------------------------------------------------------- // Remove any imports that are provided by the ccenv or system // -------------------------------------------------------------------------------------- var provided = map[string]bool{ "github.com/hyperledger/fabric/core/chaincode/shim": true, "github.com/hyperledger/fabric/protos/peer": true, }```

muralisr (Wed, 05 Jul 2017 13:10:21 GMT):
remove ^^^ as we will pick up dependencies via autovendoring

greg.haskins (Wed, 05 Jul 2017 13:10:29 GMT):
Right. Just remove the notion of "provided"

greg.haskins (Wed, 05 Jul 2017 13:10:52 GMT):
Other filters like system deps should remain

muralisr (Wed, 05 Jul 2017 13:11:11 GMT):
seems drastic at this stage... but will yield the floor...

greg.haskins (Wed, 05 Jul 2017 13:11:48 GMT):
I think code wise, it's simple. Concept wise, it's more drastic yes, but so is inaction

greg.haskins (Wed, 05 Jul 2017 13:12:25 GMT):
A big problem seems to be that people are not testing bigger chaincode apps as part of the CI

mastersingh24 (Wed, 05 Jul 2017 13:12:34 GMT):
Let's break this down to the "common" problem(s) that keep(s) creeping up - and they are mostly when using the "peer chaincode package" and "peer chaincode install -p" commands

mastersingh24 (Wed, 05 Jul 2017 13:12:34 GMT):
Let's break this down to the "common" problem(s) that keep(s) creeping up - and they are mostly when using the `peer chaincode package` and `peer chaincode install -p` commands

greg.haskins (Wed, 05 Jul 2017 13:13:07 GMT):
So the problem is probably not as apparent to maintainers as I suspect it really is

mastersingh24 (Wed, 05 Jul 2017 13:13:30 GMT):
I don't see this when using the NodeSDK to package and install chaincode

mastersingh24 (Wed, 05 Jul 2017 13:13:55 GMT):
The problem is we made some bad decisions along the way (but let's leave those for now)

yacovm (Wed, 05 Jul 2017 13:14:14 GMT):
I thought there was some unwritten consensus that peer cli isn't a "production tool" ?

greg.haskins (Wed, 05 Jul 2017 13:14:16 GMT):
That's interesting, but note that the SDK also doesn't auto-vendor

greg.haskins (Wed, 05 Jul 2017 13:14:27 GMT):
(Yet)

greg.haskins (Wed, 05 Jul 2017 13:14:50 GMT):
So not sure what that means inthis context

mastersingh24 (Wed, 05 Jul 2017 13:15:16 GMT):
Common issues: - need to use protos within chaincode (e.g. to parse the results of GetCreator() or GetHistoryForKey() ) - use of proto Timestamp

greg.haskins (Wed, 05 Jul 2017 13:16:04 GMT):
Agreed that was a poor design decision to expose proto timestamp. Abstracting that would have mitigated here

muralisr (Wed, 05 Jul 2017 13:17:14 GMT):
I'm missing someting...regardless of whether we use CLI or SDK, both use ccenv in the end an both would have same issues no @mastersingh24 ?

mastersingh24 (Wed, 05 Jul 2017 13:17:58 GMT):
nope

mastersingh24 (Wed, 05 Jul 2017 13:18:25 GMT):
gimme a sec to explain

greg.haskins (Wed, 05 Jul 2017 13:18:31 GMT):
That's what's confusing me: you either have a dep and include it, or you don't. The SDK will not help you include it but that shouldn't change whether your apps deps are satisfied in a way that compiles

greg.haskins (Wed, 05 Jul 2017 13:19:11 GMT):
If simply not including the dep solves the problem, the auto vendoring sounds broken

greg.haskins (Wed, 05 Jul 2017 13:22:09 GMT):
Sorry @mastersingh24 , you have the floor

greg.haskins (Wed, 05 Jul 2017 13:22:24 GMT):
On mobile so easy to miss posts

JonathanLevi (Wed, 05 Jul 2017 13:22:36 GMT):
[ @mastersingh24 is very shy these days, isn't he? ]

JonathanLevi (Wed, 05 Jul 2017 13:23:05 GMT):
@mastersingh24, pray continue...

greg.haskins (Wed, 05 Jul 2017 13:25:45 GMT):
Gotta run. TBC

mastersingh24 (Wed, 05 Jul 2017 13:35:18 GMT):
OK - sorry - I am back

mastersingh24 (Wed, 05 Jul 2017 14:21:16 GMT):
Sorry - been testing a few things here

mastersingh24 (Wed, 05 Jul 2017 14:23:05 GMT):
As far as I can tell, the only package we seem to have an issue with is `github.com/golang/protobuf/ptypes/timestamp`

mastersingh24 (Wed, 05 Jul 2017 14:24:13 GMT):
To be clear, what I am doing is actually "vendoring" all other dependencies within my chaincode package

mastersingh24 (Wed, 05 Jul 2017 14:24:39 GMT):
(that is - I'm not using the `peer chaincode package` to handle my dependencies for me

mastersingh24 (Wed, 05 Jul 2017 14:24:39 GMT):
(that is - I'm not using the `peer chaincode package` to handle my dependencies for me)

mastersingh24 (Wed, 05 Jul 2017 14:26:00 GMT):
In order to explicitly import and use `github.com/golang/protobuf/ptypes/timestamp`, I'm force to vendor `github.com/hyperledger/fabric/core/chaincode/shim` as well as `github.com/golang/protobuf/ptypes/timestamp`

greg.haskins (Wed, 05 Jul 2017 15:32:31 GMT):
@mastersingh24 interesting. As an experiment could you remove the "provided" filter from the packager and see if that vendors the shim in a similar way?

mastersingh24 (Wed, 05 Jul 2017 15:37:57 GMT):
sure thing

mastersingh24 (Wed, 05 Jul 2017 20:18:40 GMT):
I'd like to propose that we update the minimum Docker version to `17.03.0-ce` (basically Docker 1.13.1 with Docker's new version scheme). The fabcar sample already requires Docker 1.13 or later, so we might as well go with `17.03.0-ce` (ideally I'd love to prereq the newest Docker version - `17.06.0-ce` - but it might be too soon for that)

jyellick (Wed, 05 Jul 2017 20:22:20 GMT):
Not sure if maybe we should open up a JIRA for a formal vote, but sounds reasonable to me

mastersingh24 (Wed, 05 Jul 2017 20:29:42 GMT):
We should - was just being lazy and checking here first before opening one up ;)

MartinC (Thu, 06 Jul 2017 12:09:51 GMT):
Has left the channel.

shimos (Thu, 06 Jul 2017 16:24:36 GMT):
Has joined the channel.

JonathanLevi (Thu, 06 Jul 2017 20:25:43 GMT):
Hello, we have some pressing issue here: https://jira.hyperledger.org/browse/FAB-5188

JonathanLevi (Thu, 06 Jul 2017 20:26:05 GMT):
Just to draw some attention. No panic, but suggestions welcome.

JonathanLevi (Fri, 07 Jul 2017 03:28:34 GMT):
@jimthematrix are you around?

weeds (Fri, 07 Jul 2017 08:45:57 GMT):
Jim doesn't get back until Monday

weeds (Fri, 07 Jul 2017 08:46:17 GMT):
If there is an SDK item you want us to look at I can ask Brett- let me know

JonathanLevi (Fri, 07 Jul 2017 12:45:34 GMT):
We are good. We have contained the situation.

JonathanLevi (Fri, 07 Jul 2017 13:09:00 GMT):
@here: How does everybody feel about this? https://jira.hyperledger.org/browse/FAB-5177 Let's agree on the right course of action, if others want to join the discussion/exchanges there, please .

mastersingh24 (Fri, 07 Jul 2017 13:09:37 GMT):
Added my comment to the JIRA on testing @muralisr and I did yesterday

mastersingh24 (Fri, 07 Jul 2017 13:09:48 GMT):
Needless to say, I think we are good to go without it

muralisr (Fri, 07 Jul 2017 13:14:47 GMT):
+1 @mastersingh24 @JonathanLevi ... I did make progress with `assuming they are broken, see if stuffing a vendored shim into the package solves the problem despite the dep being available in the ccenv.` comment from @greg.haskins to make sure if we really wanted to override the shim by vendoring it in the chaincode on top of ccenv

muralisr (Fri, 07 Jul 2017 13:14:47 GMT):
+1 @mastersingh24 @JonathanLevi ... I did make progress with `assuming they are broken, see if stuffing a vendored shim into the package solves the problem despite the dep being available in the ccenv.` comment from @greg.haskins in FAB-5177 to make sure if we really wanted to override the shim by vendoring it in the chaincode on top of ccenv

muralisr (Fri, 07 Jul 2017 13:15:07 GMT):
I did not complete it (got distracted) but got far enough to know that push come to shove we can do that

mastersingh24 (Fri, 07 Jul 2017 13:21:21 GMT):
I tested the above several times

binhn (Fri, 07 Jul 2017 13:22:04 GMT):
@muralisr if you're on the beach now, have fun... it sounds like you asserted that we can vendor the stuff that's already in ccenv, so i don't think we have a problem except documenting it.

muralisr (Fri, 07 Jul 2017 13:23:24 GMT):
@binhn not yet but shortly leaving ..

mastersingh24 (Fri, 07 Jul 2017 13:23:28 GMT):
And so far, the only reason to vendor the shim is if you are deadset on doing the following: var ts *timestamp.Timestamp ts, _ = stub.GetTxTimestamp() (which there is no reason to do BTW)

muralisr (Fri, 07 Jul 2017 13:24:26 GMT):
right, you could do `ts, _ := stub.GetTxTimestamp()` if you want to use the type used by shim

binhn (Fri, 07 Jul 2017 13:24:50 GMT):
@mastersingh24 could you comment on fab-5177 the instruction that @nickgaski should take to document

muralisr (Fri, 07 Jul 2017 13:25:58 GMT):
also `please, please don't put chaincode under fabric/`

mastersingh24 (Fri, 07 Jul 2017 13:26:00 GMT):
The question is whether or not we want to "recommend" that people vendor the shim or not

mastersingh24 (Fri, 07 Jul 2017 13:26:06 GMT):
Right

binhn (Fri, 07 Jul 2017 13:27:15 GMT):
is it true or not that we should only vendor the shim if we use timestamp as above?

mastersingh24 (Fri, 07 Jul 2017 13:27:38 GMT):
For now, other than that case, I have not found any other reason to vendor it

C0rWin (Fri, 07 Jul 2017 13:27:45 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=CNFzECyP73ero89Mh) @muralisr you might have project vedored protobuf and you chaincode is a part of this project, resides in one of the folders

mastersingh24 (Fri, 07 Jul 2017 13:27:47 GMT):
I used BCCSP, proto, msp, etc

binhn (Fri, 07 Jul 2017 13:31:02 GMT):
ok, i think we know what to document at this point -- do we need to UT to complete 5177?

binhn (Fri, 07 Jul 2017 14:31:40 GMT):
@mastersingh24 @greg.haskins @muralisr @C0rWin @JonathanLevi I added the summary in fab-5177, so if nothing else, we'll proceed with document

mastersingh24 (Fri, 07 Jul 2017 15:16:20 GMT):
So is this the last one: https://gerrit.hyperledger.org/r/#/c/11437

jyellick (Fri, 07 Jul 2017 15:18:02 GMT):
This was a good catch by the test team. There is a real risk of replay without the fix.

mastersingh24 (Fri, 07 Jul 2017 15:38:57 GMT):
Right

yacovm (Fri, 07 Jul 2017 16:40:10 GMT):
@here we all agree on merging https://gerrit.hyperledger.org/r/#/c/11437 right?

jyellick (Fri, 07 Jul 2017 16:40:52 GMT):
As the submitter, not sure my vote counts, but obviously I believe its inclusion is necessary.

tkuhrt (Fri, 07 Jul 2017 16:54:24 GMT):
Question for the maintainers...will there be another RC? My understanding of good practice is that the only difference between an RC and the final version is the version number (From Karl Fogel https://www.boundless.com/users/280030/textbooks/1st-study/packaging-releasing-and-daily-development-7/testing-and-releasing-52/candidate-releases-195-14372/ : "that is, the only difference between the last candidate release and the real release is the removal of the qualifier from the version number."

jyellick (Fri, 07 Jul 2017 17:23:42 GMT):
@tkuhrt This channel is for discussions amonst the maintainers of fabric. Please use #fabric-release for release related questions.

JonathanLevi (Fri, 07 Jul 2017 19:50:27 GMT):
Dear fellow maintainers, 1. I would like to declare a *CODE_FREEZE* (at least over the weekend, but) potentially longer/until a further announcement. If anyone has any objections, please let me know ASAP... but I would really like us all to get into that mindset of "this codebase is getting close to becoming the real deal". 2. In addition I will schedule a meeting with all of us maintainers on Monday (most likely at 10am EST), to discuss where we stand and also consider/take into an account the above question from (Tracy) @tkuhrt . We should be ready by Monday to make a final call on whether we work on another release-candidate *rc2*, or move ahead with the . 3. I have been getting flooded recently with a lot of direct messages. From requests asking whether something is a "bug", "feature" or an "improvement", all the way to people reporting to me a few potential show stoppers that we have managed to tackle. Still, should anything come up, please either write here "@ tagging" me, write to me directly or email me (jonathan@hacera.com) - when in doubt, just reach out - I would rather have more information, than less. Thank you, Jonathan

JonathanLevi (Fri, 07 Jul 2017 19:50:27 GMT):
Dear fellow maintainers, 1. I would like to declare a *CODE_FREEZE* (at least over the weekend, but) potentially longer/until a further announcement. If anyone has any objections, please let me know ASAP... but I would really like us all to get into that mindset of "this codebase is getting close to becoming the real deal". 2. In addition I will schedule a meeting with all of us maintainers on Monday (most likely at 10am EST), to discuss where we stand and also consider/take into an account the above question from (Tracy) @tkuhrt . We should be ready by Monday to make a final call on whether we work on another release-candidate *1.0.0-rc2*, or move ahead with *1.0.0* 3. I have been getting flooded recently with a lot of direct messages. From requests asking whether something is a "bug", "feature" or an "improvement", all the way to people reporting to me a few potential show stoppers that we have managed to tackle. Still, should anything come up, please either write here "@ tagging" me, write to me directly or email me (jonathan@hacera.com) - when in doubt, just reach out - I would rather have more information, than less. Thank you, Jonathan

JonathanLevi (Fri, 07 Jul 2017 19:50:27 GMT):
Dear fellow maintainers, 1. I would like to declare a *CODE_FREEZE* (at least over the weekend, but) potentially longer/until a further announcement. If anyone has any objections, please let me know ASAP... but I would really like us all to get into that mindset of "this codebase is getting close to becoming the real deal". 2. In addition I will schedule a meeting with all of us maintainers on Monday (most likely at 10am EST), to discuss where we stand and also consider/take into an account the above question from (Tracy) @tkuhrt . We should be ready by Monday to make a final call on whether we work on another release-candidate *1.0.0-rc2*, or go ahead with *1.0.0* 3. I have been getting flooded recently with a lot of direct messages. From requests asking whether something is a "bug", "feature" or an "improvement", all the way to people reporting to me a few potential show stoppers that we have managed to tackle. Still, should anything come up, please either write here "@ tagging" me, write to me directly or email me (jonathan@hacera.com) - when in doubt, just reach out - I would rather have more information, than less. Thank you, Jonathan

greg.haskins (Sun, 09 Jul 2017 12:38:32 GMT):
I agree with the issue @tkuhrt raised...if there were more merges since -rc1, we should probably have an -rc2, and only a -ga when no more merges occur

greg.haskins (Sun, 09 Jul 2017 12:40:30 GMT):
I also think we should not ignore my warning in FAB-5177. Don't let release pressure obscure thinking here, please, as getting the ABI right is important.

muralisr (Sun, 09 Jul 2017 13:56:52 GMT):
@greg.haskins just added a comment to FAB-5177 with an alternative.... what do you think ?

HuangLijun (Mon, 10 Jul 2017 02:41:17 GMT):
Has joined the channel.

cbf (Mon, 10 Jul 2017 09:33:52 GMT):
I think we need to look at WHAT was changed... I have been MIA but weren't the changes largely doc test or samples only?

cbf (Mon, 10 Jul 2017 09:34:42 GMT):
if we fixed core code gor defects, maybe a rc2 is warranted. but have we made core changes/fixes?

C0rWin (Mon, 10 Jul 2017 10:26:38 GMT):
https://gerrit.hyperledger.org/r/#/c/11429/ https://gerrit.hyperledger.org/r/#/c/10967/ https://gerrit.hyperledger.org/r/#/c/11437/

C0rWin (Mon, 10 Jul 2017 10:28:24 GMT):
These was some fixes which related to core at some level, not sure whenever they could be counted as severe to propose rc2. @cbf

JonathanLevi (Mon, 10 Jul 2017 10:54:58 GMT):
the 10am EST call today should be very interesting. That's for sure.

kostas (Mon, 10 Jul 2017 11:29:17 GMT):
Have the details for the 10am EST call been sent out?

JonathanLevi (Mon, 10 Jul 2017 11:55:49 GMT):
I would not dream of sending it out without copying you @kostas ! ;-)

JonathanLevi (Mon, 10 Jul 2017 11:56:24 GMT):
[Finalizing the time, now that people are waking up in the East Cost. It may end up being at 11am... I will inform everybody]

kostas (Mon, 10 Jul 2017 11:58:36 GMT):
Ah gotcha, thank you.

greg.haskins (Mon, 10 Jul 2017 12:36:55 GMT):
@JonathanLevi I am still on vacation this week and wont make the call

JonathanLevi (Mon, 10 Jul 2017 12:41:13 GMT):
@greg.haskins, oh no! ;-) Actually, I envy you. Fair enough.

JonathanLevi (Mon, 10 Jul 2017 12:41:25 GMT):
Greg, we may end up needing to vote.

greg.haskins (Mon, 10 Jul 2017 12:41:38 GMT):
understood

JonathanLevi (Mon, 10 Jul 2017 12:41:55 GMT):
I can instead put things in writing and we'll allow everybody to opine and vote.

greg.haskins (Mon, 10 Jul 2017 12:42:00 GMT):
fwiw, I still think we are making a potential mistake not considering 5177

JonathanLevi (Mon, 10 Jul 2017 12:42:15 GMT):
Yes, that's what I want us all to vote on.

greg.haskins (Mon, 10 Jul 2017 12:42:17 GMT):
ok, that would be good

JonathanLevi (Mon, 10 Jul 2017 12:43:49 GMT):
We have 2 things. Considering RC2 (Tracy's proposal from Friday)...

JonathanLevi (Mon, 10 Jul 2017 12:43:49 GMT):
We have 2 things. 1. Considering RC2 (Tracy's proposal from Friday)...

JonathanLevi (Mon, 10 Jul 2017 12:44:16 GMT):
Also in the context of what has actually changed, the ramifications/risk.

JonathanLevi (Mon, 10 Jul 2017 12:44:50 GMT):
And the second item is indeed your proposal/request to include 5177 (or a flavor of it) in 1.0.

muralisr (Mon, 10 Jul 2017 12:45:09 GMT):
@greg.haskins @JonathanLevi I've been thinking about 5177 ...was thinking of responding to Gregs last comment

muralisr (Mon, 10 Jul 2017 12:59:37 GMT):
do you want to wait for that or do we have enough info to vote ?

greg.haskins (Mon, 10 Jul 2017 13:12:37 GMT):
@muralisr please contribute your comment

greg.haskins (Mon, 10 Jul 2017 13:13:02 GMT):
FYI, I've queued: https://gerrit.hyperledger.org/r/#/c/11471/ and https://gerrit.hyperledger.org/r/#/c/11445/ related to the conversation

greg.haskins (Mon, 10 Jul 2017 13:13:27 GMT):
11445 currently fails because the e2e would need to be adapted to include the shim

greg.haskins (Mon, 10 Jul 2017 13:13:38 GMT):
but given my vacation, i have not had a chance to dig into that one

greg.haskins (Mon, 10 Jul 2017 13:14:04 GMT):
but they are queued should a decision be made should someone want to run with it

muralisr (Mon, 10 Jul 2017 13:14:35 GMT):
typing up the comment @greg.haskins

yacovm (Mon, 10 Jul 2017 13:21:55 GMT):
I have a question regarding the CC packaging. So before https://gerrit.hyperledger.org/r/#/c/6991/ was merged - what did the `ccenv` contain? Did it contain the shim? Did we have this problem we have now?

yacovm (Mon, 10 Jul 2017 13:27:35 GMT):
@greg.haskins @muralisr ^

greg.haskins (Mon, 10 Jul 2017 13:33:29 GMT):
Had the shim for a long time. 6991 didn't change that or introduce the problem. 6991 simply makes it easier to swallow if we remove the shim

greg.haskins (Mon, 10 Jul 2017 13:33:53 GMT):
Since it hides the need that include in manually

muralisr (Mon, 10 Jul 2017 13:39:27 GMT):
@greg.haskins might as well talk here as we are all here... (plus on cell so having a hard time with posts)

JonathanLevi (Mon, 10 Jul 2017 13:58:00 GMT):
OK, several people have written to me directly regarding the (un)availability to hop on a quick call.

JonathanLevi (Mon, 10 Jul 2017 13:58:00 GMT):
OK, several people have written to me directly regarding their (un)availability/inability to hop on a quick call - some are overworked, others are on vacations.

JonathanLevi (Mon, 10 Jul 2017 13:58:50 GMT):
So I'm not scheduling a call for 10am, but you will hear back from me (aka, "I will be back" ;-))

albrandt (Mon, 10 Jul 2017 18:50:52 GMT):
Has joined the channel.

JonathanLevi (Tue, 11 Jul 2017 11:18:45 GMT):
Can somebody take a look at: https://gerrit.hyperledger.org/r/#/c/11473

JonathanLevi (Tue, 11 Jul 2017 11:19:21 GMT):
And https://gerrit.hyperledger.org/r/#/c/11447 as well please.

JonathanLevi (Tue, 11 Jul 2017 12:03:32 GMT):
@rameshthoomu, please close them JIRAs

rameshthoomu (Tue, 11 Jul 2017 12:03:42 GMT):
on it

rameshthoomu (Tue, 11 Jul 2017 12:06:27 GMT):
done

JonathanLevi (Tue, 11 Jul 2017 13:01:05 GMT):
Fellow maintainers, please can you take a close look at:

JonathanLevi (Tue, 11 Jul 2017 13:01:06 GMT):
https://gerrit.hyperledger.org/r/#/c/11523/1/CHANGELOG.md

greg.haskins (Tue, 11 Jul 2017 13:10:20 GMT):
@JonathanLevi on a related note: spoke with Brian/Gari/Sharon yesterday regarding FAB-5177

greg.haskins (Tue, 11 Jul 2017 13:10:55 GMT):
I'll try to summarize the agreement: its probably an important issue to fix (TBD by maintainers) but we wont block the release over it

greg.haskins (Tue, 11 Jul 2017 13:11:17 GMT):
rather, lets add the issue to the ERRATA/Release-notes and make it a priority to fix ASAP (e.g. v1.0.1

greg.haskins (Tue, 11 Jul 2017 13:11:40 GMT):
because we are noting it in the ERRATA, if an ABI breakage is required, we are covered

greg.haskins (Tue, 11 Jul 2017 13:11:53 GMT):
that said, Gari and I agree that we can likely fix it without breakage

greg.haskins (Tue, 11 Jul 2017 13:12:09 GMT):
@mastersingh24 anything to add?

binhn (Tue, 11 Jul 2017 13:20:02 GMT):
@JonathanLevi the changelog looks good to me

JonathanLevi (Tue, 11 Jul 2017 13:23:29 GMT):
@greg.haskins, here we go: https://gerrit.hyperledger.org/r/#/c/11523/1/docs/source/releases.rst

JonathanLevi (Tue, 11 Jul 2017 13:23:47 GMT):
(that's from Gari, who is out for about an hour)

JonathanLevi (Tue, 11 Jul 2017 13:23:47 GMT):
(I completely agree - that's from Gari, who is out for about an hour)

JonathanLevi (Tue, 11 Jul 2017 13:24:02 GMT):
Can I have your blessings there?

greg.haskins (Tue, 11 Jul 2017 13:29:19 GMT):
I suggest that in addition to that, we also mention that we reserve the right to change the ccenv in the future, yada yada yada

greg.haskins (Tue, 11 Jul 2017 13:29:37 GMT):
and perhaps mention the 5177 issue or something

greg.haskins (Tue, 11 Jul 2017 13:29:44 GMT):
that would give the coverage that Brian mentioned

greg.haskins (Tue, 11 Jul 2017 13:30:03 GMT):
have to run..

JonathanLevi (Tue, 11 Jul 2017 13:30:17 GMT):
OK, let me do these two things: 1. mention "that we reserve the right to change the ccenv in the future" 2. include the 5177

JonathanLevi (Tue, 11 Jul 2017 13:30:23 GMT):
Cool?

mastersingh24 (Tue, 11 Jul 2017 14:13:09 GMT):
I'm back for a bit

mastersingh24 (Tue, 11 Jul 2017 14:13:20 GMT):
I'll update the CR - forgot a file as well

binhn (Tue, 11 Jul 2017 14:13:21 GMT):
@JonathanLevi on releases.rst, should we mentioned the remaining bugs ?

binhn (Tue, 11 Jul 2017 14:13:21 GMT):
@JonathanLevi on releases.rst, should we mentioned the known remaining bugs ?

JonathanLevi (Tue, 11 Jul 2017 14:13:45 GMT):
Please take a look, I just pushed: https://gerrit.hyperledger.org/r/#/c/11523/

mastersingh24 (Tue, 11 Jul 2017 14:13:51 GMT):
ah -ok

mastersingh24 (Tue, 11 Jul 2017 14:17:14 GMT):
release_notes/v1.0.0.txt

JonathanLevi (Tue, 11 Jul 2017 14:19:04 GMT):
Yup

JonathanLevi (Tue, 11 Jul 2017 14:19:47 GMT):
@binhn, @muralisr Care to take a/nother/quick look at https://gerrit.hyperledger.org/r/#/c/11523

binhn (Tue, 11 Jul 2017 14:20:09 GMT):
on it

mastersingh24 (Tue, 11 Jul 2017 14:24:54 GMT):
And then please https://gerrit.hyperledger.org/r/#/c/11529/

mastersingh24 (Tue, 11 Jul 2017 14:25:16 GMT):
Actually, would be good to approve both and submit 11529 (whose parent is 11523)

JonathanLevi (Tue, 11 Jul 2017 14:25:25 GMT):
Yes, please

mastersingh24 (Tue, 11 Jul 2017 14:25:25 GMT):
Then we are nice and clean

JonathanLevi (Tue, 11 Jul 2017 14:25:54 GMT):
Not worried at all about known bugs (that are "not functional"... at least by looking at the list we currently have)

mastersingh24 (Tue, 11 Jul 2017 14:27:10 GMT):
Honestly, even calling out 5177 as a Known Issue was only to appease Greg

mastersingh24 (Tue, 11 Jul 2017 14:27:10 GMT):
Honestly, even calling out 5177 as a Known Issue was only to appease Greg ;)

JonathanLevi (Tue, 11 Jul 2017 14:27:30 GMT):
Kids, not now! ;-)

mastersingh24 (Tue, 11 Jul 2017 14:27:31 GMT):
Just checking on Greg!

JonathanLevi (Tue, 11 Jul 2017 14:27:36 GMT):
We need another +2

mastersingh24 (Tue, 11 Jul 2017 14:27:39 GMT):
Seeing if he is paying attention

mastersingh24 (Tue, 11 Jul 2017 14:27:59 GMT):
No - I like the new text for 5177 in the release notes - we are now covered well

JonathanLevi (Tue, 11 Jul 2017 14:28:01 GMT):
So Greg already gave his green light (officially) above... should I include the changes he requested.

mastersingh24 (Tue, 11 Jul 2017 14:28:12 GMT):
Ah - cool

JonathanLevi (Tue, 11 Jul 2017 14:28:14 GMT):
Yes, added at his behest, really.

mastersingh24 (Tue, 11 Jul 2017 14:28:23 GMT):
Missed that piece - but the changes make sense to me

JonathanLevi (Tue, 11 Jul 2017 14:28:31 GMT):
@mastersingh24 please see above: https://chat.hyperledger.org/channel/fabric-maintainers?msg=6Ydhw7AkhSMkE4uZA

mastersingh24 (Tue, 11 Jul 2017 14:28:42 GMT):
Yeah - that was a good call

JonathanLevi (Tue, 11 Jul 2017 14:29:01 GMT):
I agree. Another maintainer, please. Gari and I cannot touch the release notes.

JonathanLevi (Tue, 11 Jul 2017 14:29:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=h9cG5LXwMcYFRPxiB)

JonathanLevi (Tue, 11 Jul 2017 14:29:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=MTPRNwxSxm6W4gtpJ)

jyellick (Tue, 11 Jul 2017 14:29:37 GMT):
Ah, can do

JonathanLevi (Tue, 11 Jul 2017 14:29:50 GMT):
Thank you @jyellick

mastersingh24 (Tue, 11 Jul 2017 14:30:01 GMT):
This is a lesson learned which Greg always reminds us to do - submit the release equals true and set it back to false back to back

JonathanLevi (Tue, 11 Jul 2017 14:30:46 GMT):
Yup

mastersingh24 (Tue, 11 Jul 2017 14:31:09 GMT):
SO let's surprise him by actually doing it!

mastersingh24 (Tue, 11 Jul 2017 14:31:40 GMT):
https://gerrit.hyperledger.org/r/#/c/11529/ can be merged - it as 2 +2

mastersingh24 (Tue, 11 Jul 2017 14:31:40 GMT):
https://gerrit.hyperledger.org/r/#/c/11529/ can be merged - it has 2 +2

JonathanLevi (Tue, 11 Jul 2017 14:31:41 GMT):
OK, yeah, we *should indeed* make him proud ;-)

JonathanLevi (Tue, 11 Jul 2017 14:31:51 GMT):
We need another thing from binhn.

JonathanLevi (Tue, 11 Jul 2017 14:31:55 GMT):
FAB-4844 fabric-ca-client enroll doesn't store msp/intermediatecerts FAB-5048 "package.json" of fabric-client does not include some necessary modules FAB-5177 peer/ccenv should not include the shim FAB-5246 gossip rejects join channel unless used with leader election

mastersingh24 (Tue, 11 Jul 2017 14:32:24 GMT):
????

mastersingh24 (Tue, 11 Jul 2017 14:32:35 GMT):
4844 and 5048 are not fabric

dave.enyeart (Tue, 11 Jul 2017 14:44:44 GMT):
I assume for the 1.0.0 release we are following the Jira task and the subtasks mentioned: https://jira.hyperledger.org/browse/FAB-5065

binhn (Tue, 11 Jul 2017 14:45:23 GMT):
adding a couple of note-worthy known bugs to the release notes https://gerrit.hyperledger.org/r/#/c/11531/

binhn (Tue, 11 Jul 2017 14:46:12 GMT):
ah, just saw gari's msg above, 4844 is not fabric

binhn (Tue, 11 Jul 2017 14:46:18 GMT):
pushing another one

JonathanLevi (Tue, 11 Jul 2017 14:48:57 GMT):
Gents, please

JonathanLevi (Tue, 11 Jul 2017 14:48:57 GMT):
https://gerrit.hyperledger.org/r/#/c/11535/

simsc (Tue, 11 Jul 2017 14:49:29 GMT):
uh

JonathanLevi (Tue, 11 Jul 2017 14:49:43 GMT):
@dave.enyeart of course we are. We need to quickly prioritize the sub-projects and release notes.

JonathanLevi (Tue, 11 Jul 2017 14:53:48 GMT):
@smithbk Here?

binhn (Tue, 11 Jul 2017 14:53:57 GMT):
https://gerrit.hyperledger.org/r/#/c/11531

binhn (Tue, 11 Jul 2017 14:54:10 GMT):
release note changes

dave.enyeart (Tue, 11 Jul 2017 15:01:29 GMT):
shouldn't we tag the 1.0.0 release BEFORE incrementing the makefiles to 1.0.1?

dave.enyeart (Tue, 11 Jul 2017 15:02:30 GMT):
i dont understand why https://gerrit.hyperledger.org/r/#/c/11529/ (increment to 1.0.1) was merged prior to tagging 1.0.0

jyellick (Tue, 11 Jul 2017 15:03:05 GMT):
https://gerrit.hyperledger.org/r/#/c/11523/3 Was submitted with it?

dave.enyeart (Tue, 11 Jul 2017 15:06:49 GMT):
I guess when we tag doesn't matter, as long as we tag the commit that changed the makefiles to 1.0.0

binhn (Tue, 11 Jul 2017 15:07:01 GMT):
where are we? tagged?

rameshthoomu (Tue, 11 Jul 2017 15:07:17 GMT):
Fabric is done

rameshthoomu (Tue, 11 Jul 2017 15:07:22 GMT):
Release jobs are triggered

binhn (Tue, 11 Jul 2017 15:08:07 GMT):
ok, so my cr on release notes won't get in then

smithbk (Tue, 11 Jul 2017 15:10:08 GMT):
+2'ed https://gerrit.hyperledger.org/r/#/c/11535

rameshthoomu (Tue, 11 Jul 2017 15:14:30 GMT):
I see tag v1.0.0 is created on wrong commit number

rameshthoomu (Tue, 11 Jul 2017 15:15:17 GMT):
It should be on `commit# b17afeb` not on latest `commit # e50ca0c `

rameshthoomu (Tue, 11 Jul 2017 15:15:17 GMT):
It should be on `commit# e4b4704` not on latest `commit # e50ca0c `

dave.enyeart (Tue, 11 Jul 2017 15:16:26 GMT):
exactly my point previously... we should increment makefile to 1.0.0, tag it, and then increment makefile to 1.0.1

dave.enyeart (Tue, 11 Jul 2017 15:16:50 GMT):
is it possible to delete a tag and retag it?

rameshthoomu (Tue, 11 Jul 2017 15:19:23 GMT):
fabric images are messed up with version

JonathanLevi (Tue, 11 Jul 2017 15:26:43 GMT):
Yes!

JonathanLevi (Tue, 11 Jul 2017 15:26:47 GMT):
Tell me about it.

rameshthoomu (Tue, 11 Jul 2017 15:28:32 GMT):
I think we have to delete the existing `v1.0.0` tag and go back to `commit # b17afeb` (1.0.0 release CR Commit) and then publish the v1.0.0 tag again

rameshthoomu (Tue, 11 Jul 2017 15:30:32 GMT):
FYI: I stopped fabric x86 and power release CI jobs after seeing pushing the wrong version.. So only s390x docker images version is messed up now.. . Will ask @rjones or @jwagantall to delete these `s390x-1.0.1-snapshot-e50ca0c` images from docker hub..

JonathanLevi (Tue, 11 Jul 2017 15:36:59 GMT):
Stop!

JonathanLevi (Tue, 11 Jul 2017 16:08:00 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=eurs2QmcMoPRzFhit)

JonathanLevi (Tue, 11 Jul 2017 16:08:27 GMT):
The correct commit level is *e4b4704*

rameshthoomu (Tue, 11 Jul 2017 16:09:10 GMT):
yes that's the right commit number

JonathanLevi (Tue, 11 Jul 2017 16:10:33 GMT):
:-)

jimthematrix (Tue, 11 Jul 2017 16:28:52 GMT):
@mastersingh24 want to make sure I don't step on your toes: https://jira.hyperledger.org/browse/FAB-5068 was assigned to you but I just grabbed it to handle it, as well as https://jira.hyperledger.org/browse/FAB-5072

JonathanLevi (Tue, 11 Jul 2017 16:37:59 GMT):
Come on

JonathanLevi (Tue, 11 Jul 2017 16:38:08 GMT):
If I'm asking anyone to do something, please just do it.

JonathanLevi (Tue, 11 Jul 2017 16:38:35 GMT):
@jimthematrix please go ahead

JonathanLevi (Tue, 11 Jul 2017 16:39:37 GMT):
@dave.enyeart please can you take a look at https://gerrit.hyperledger.org/r/#/c/11543/

JonathanLevi (Tue, 11 Jul 2017 16:41:11 GMT):
@here

dave.enyeart (Tue, 11 Jul 2017 16:41:13 GMT):
looking

JonathanLevi (Tue, 11 Jul 2017 16:41:20 GMT):
Can anyone please approve https://gerrit.hyperledger.org/r/#/c/11543/

JonathanLevi (Tue, 11 Jul 2017 16:44:07 GMT):
Thanks M

dave.enyeart (Tue, 11 Jul 2017 16:44:10 GMT):
it looks good, but we are verifying with @rameshthoomu that the sdk 'version' can handle no suffix

JonathanLevi (Tue, 11 Jul 2017 16:44:22 GMT):
Merged already. Dave, seriously...

dave.enyeart (Tue, 11 Jul 2017 16:45:11 GMT):
Ramesh's scripts parse the version, just double checking

rameshthoomu (Tue, 11 Jul 2017 16:46:45 GMT):
yes..

JonathanLevi (Tue, 11 Jul 2017 16:51:32 GMT):
There are NO issues with the CI

JonathanLevi (Tue, 11 Jul 2017 16:51:54 GMT):
Guys, a script in a CI does not dictate how we work, tag or refer to builds.

JonathanLevi (Tue, 11 Jul 2017 16:52:07 GMT):
Just a note... that I'm *sure* we'll revisit.

binhn (Tue, 11 Jul 2017 17:37:02 GMT):
good news: `./byfn.sh -m up` ran successfully on my mac

JonathanLevi (Tue, 11 Jul 2017 17:38:25 GMT):
Nice, same for @dave.enyeart.

JonathanLevi (Tue, 11 Jul 2017 17:38:25 GMT):
Nice, same for @dave.enyeart

rameshthoomu (Tue, 11 Jul 2017 17:38:57 GMT):
I did on `x`, `p` and `z` platforms and it worked as expected

JonathanLevi (Tue, 11 Jul 2017 17:39:07 GMT):
Can others can spend some time with sdk-node?

JonathanLevi (Tue, 11 Jul 2017 17:39:07 GMT):
Can others please spend some time with sdk-node?

JonathanLevi (Tue, 11 Jul 2017 17:39:15 GMT):
We are packaging the sdk-java

JonathanLevi (Tue, 11 Jul 2017 17:41:30 GMT):
Jim has confirmed (of course, otherwise, I would not have asked him), but it would not hurt to have others at it...

JonathanLevi (Tue, 11 Jul 2017 17:41:30 GMT):
Jim has confirmed (of course, otherwise, I would not have asked here), but it would not hurt to have others at it...

JonathanLevi (Tue, 11 Jul 2017 17:41:50 GMT):
Jim has confirmed (of course, otherwise, I would not have asked here), but it would not hurt to have others at it...

jyellick (Tue, 11 Jul 2017 17:58:29 GMT):
`byfn.sh` is likewise happy on my local Linux setpu

jyellick (Tue, 11 Jul 2017 17:58:29 GMT):
`byfn.sh` is likewise happy on my local Linux setup

C0rWin (Tue, 11 Jul 2017 17:59:28 GMT):
Same here build your first network passed on my mac

JonathanLevi (Tue, 11 Jul 2017 18:01:11 GMT):
Thanks everyone. Last bit probably.

JonathanLevi (Tue, 11 Jul 2017 18:01:24 GMT):
We are just publishing the npms

JonathanLevi (Tue, 11 Jul 2017 18:01:44 GMT):
I know that not everybody is super familiar with the SDKs

JonathanLevi (Tue, 11 Jul 2017 18:14:09 GMT):
----- OK, things look good. Let's take some time and review things carefully back again...

JonathanLevi (Tue, 11 Jul 2017 18:14:32 GMT):
Binaries are built and published, and others are working to push the Java bits.

JonathanLevi (Tue, 11 Jul 2017 18:14:53 GMT):
Can you guys take a look at this, please: https://gerrit.hyperledger.org/r/#/c/11555

JonathanLevi (Tue, 11 Jul 2017 18:15:15 GMT):
Now, back to "normal mode", not "war-zone mode" ;-)

JonathanLevi (Tue, 11 Jul 2017 18:20:08 GMT):
-----

JonathanLevi (Tue, 11 Jul 2017 18:20:22 GMT):
Another thing, that's a nice-to-have is: https://jira.hyperledger.org/browse/FAB-5040

JonathanLevi (Tue, 11 Jul 2017 18:20:45 GMT):
A few hours to test, I know :-(... thank you @jimthematrix

JonathanLevi (Tue, 11 Jul 2017 18:35:34 GMT):
Thank you @binhn

binhn (Tue, 11 Jul 2017 18:43:08 GMT):
@JonathanLevi well done !

JonathanLevi (Tue, 11 Jul 2017 18:43:51 GMT):
Thanks everyone (including those that write to me directly)

JonathanLevi (Tue, 11 Jul 2017 18:43:51 GMT):
Thanks everyone (including those who write/wrote to me directly)

JonathanLevi (Tue, 11 Jul 2017 18:44:15 GMT):
Still a few final bits before we can finally declare success...

JonathanLevi (Tue, 11 Jul 2017 18:45:11 GMT):
Waiting for the full-fledged regression tests that we run against the release

JonathanLevi (Tue, 11 Jul 2017 18:45:54 GMT):
And a few more final bits. I will keep you posted, as I'd need a few more eyes on things...

JonathanLevi (Tue, 11 Jul 2017 18:47:04 GMT):
But really, over an hour ago, binaries were pushed successfully, and things look great. I don't want to jinx it, so I'd stop here ;-)

JonathanLevi (Tue, 11 Jul 2017 18:47:04 GMT):
But really, over an hour ago, binaries were pushed successfully, and things look great. I don't want to jinx it, so I'd stop here, for now.

JonathanLevi (Tue, 11 Jul 2017 18:54:32 GMT):
@jimthematrix https://gerrit.hyperledger.org/r/#/c/11559/

JonathanLevi (Tue, 11 Jul 2017 18:54:36 GMT):
Is this OK ?

JonathanLevi (Tue, 11 Jul 2017 18:55:07 GMT):
I'd "all for" versioned dependencies...in any environment.

JonathanLevi (Tue, 11 Jul 2017 18:55:07 GMT):
I'm "all in for" versioned dependencies...in any environment.

jimthematrix (Tue, 11 Jul 2017 19:06:00 GMT):
@JonathanLevi @dave.enyeart just +2'ed 11559

JonathanLevi (Tue, 11 Jul 2017 19:07:29 GMT):
Merged. Thanks.

markparz (Tue, 11 Jul 2017 19:40:30 GMT):
If folks could look at 11561 -> Fab-5257 for updating Docs from RC1 to v1.0. Thanks @jimthematrix for the +2 already

dave.enyeart (Tue, 11 Jul 2017 19:45:43 GMT):
Merged

JonathanLevi (Tue, 11 Jul 2017 19:53:46 GMT):
---

JonathanLevi (Tue, 11 Jul 2017 19:53:50 GMT):
https://gerrit.hyperledger.org/r/#/c/11563/

JonathanLevi (Tue, 11 Jul 2017 19:53:56 GMT):
A quick CR from me ^^^

JonathanLevi (Tue, 11 Jul 2017 19:54:00 GMT):
2 +2

JonathanLevi (Tue, 11 Jul 2017 19:54:27 GMT):
Fixing the link from the public announcement.

JonathanLevi (Tue, 11 Jul 2017 19:55:37 GMT):
@muralisr @jyellick

jyellick (Tue, 11 Jul 2017 19:55:56 GMT):
Done

JonathanLevi (Tue, 11 Jul 2017 19:56:20 GMT):
Super, pushed, thanks

JonathanLevi (Tue, 11 Jul 2017 19:56:46 GMT):
You guys are witnessing the *best practice* from a trading desk here. Sorry

JonathanLevi (Tue, 11 Jul 2017 19:57:44 GMT):
practices! ;-)

sstone1 (Tue, 11 Jul 2017 20:06:44 GMT):
Great job guys - we've picked up the 1.0.0 builds (Docker + Node.js SDK) in Composer and everything is working just fine :+1:

jimthematrix (Tue, 11 Jul 2017 20:19:03 GMT):
https://gerrit.hyperledger.org/r/#/c/11205 has been updated caught up to v1.0.0 and tested locally, @JonathanLevi @dave.enyeart

JonathanLevi (Tue, 11 Jul 2017 20:24:54 GMT):
Yes, that's a long one.

JonathanLevi (Tue, 11 Jul 2017 20:25:21 GMT):
Please, all, let's review it carefully. I'm a bit too tired, to go over it & dealing with some other issue ATM.

JonathanLevi (Tue, 11 Jul 2017 20:25:28 GMT):
Thanks Jim!

JonathanLevi (Tue, 11 Jul 2017 20:29:59 GMT):
---

JonathanLevi (Tue, 11 Jul 2017 20:30:10 GMT):
For Docker, we can use 'https://github.com/hyperledger/fabric/blob/master/scripts/bootstrap-1.0.0.sh` or `curl -sSL https://goo.gl/iX9dek | bash` these scripts.. it will pull 1.0.0 docker images and re-tag it as latest

jimthematrix (Tue, 11 Jul 2017 20:54:31 GMT):
also along with the changes in 11205, updates are needed in RTD, I found https://gerrit.hyperledger.org/r/#/c/11159 and made comments there, not sure if it's the right CR to use though, as it has a lot of changes and is going through a long review process. @nickgaski suggestions?

JonathanLevi (Tue, 11 Jul 2017 20:56:48 GMT):
The formatting is not a priority and people are tired.

JonathanLevi (Tue, 11 Jul 2017 20:56:56 GMT):
Up to you guys, your call.

JonathanLevi (Tue, 11 Jul 2017 20:57:17 GMT):
I'd rather make sure/double and triple check stuff while we can still "see" ;-)

lehors (Tue, 11 Jul 2017 22:02:09 GMT):
sorry I couldn't get to this earlier but I just tried first-network and it worked on Windows 7

lehors (Tue, 11 Jul 2017 22:02:43 GMT):
there is a problem with fabric-samples which contains files with names that are too long for Windows though

lehors (Tue, 11 Jul 2017 22:03:08 GMT):
nothing dramatic but beware:

lehors (Tue, 11 Jul 2017 22:05:27 GMT):
error: unable to create file balance-transfer/artifacts/channel/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/keystore/2fb065725bf1b7e2811c0e8ca8d37f5a951fc4cd1162a47 aad8accf9ddd10291_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/ordererOrganizations/example.com/users/Admin@example.com/msp/keystore/db670eed8487a93c35ae448b9f84c2f241a7a8c87df0544fc1dc 08baf7832aa0_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore/27db82c96b1482480baa1c75f80e5cce249beaab27b70 c741bb0e2554355957e_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp/keystore/fdee12a3510fde3155c37128cfec26090ae249bfbca28 f884e60c21338493edd_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/5890f0061619c06fb29dea8cb304edecc020fe63f41a6 db109f1e227cc1cb2a8_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/users/User1@org1.example.com/msp/keystore/73cdc0072c7203f1ec512232c780fc84acc9752ef30eb c16be1f4666c02b614b_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/keystore/0d9f72608133ee627b570b6af6877666bc8f365746f93 29d6dd8a5f54e53e2ab_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/msp/keystore/27ccb54a06020260c66c65bec91f91e1c9043e3076d3d 6128692e7271c4c7a2c_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/keystore/1995b11d6573ed3be52fcd7a5fa477bc0f183e1f5f398 c8281d0ce7c2c75a076_sk: Filename too long error: unable to create file balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/users/User1@org2.example.com/msp/keystore/585175c83bac91fc0c1ce8f9d0ff9aefa47c565678f10 0ca8673db249ee785ac_sk: Filename too long D balance-transfer/artifacts/channel/crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp/keystore/2fb065725bf1b7e2811c0e8ca8d37f5a951fc4cd1162a47aad8accf9ddd10291_sk D balance-transfer/artifacts/channel/crypto-config/ordererOrganizations/example.com/users/Admin@example.com/msp/keystore/db670eed8487a93c35ae448b9f84c2f241a7a8c87df0544fc1dc08baf7832aa0_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp/keystore/27db82c96b1482480baa1c75f80e5cce249beaab27b70c741bb0e2554355957e_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/msp/keystore/fdee12a3510fde3155c37128cfec26090ae249bfbca28f884e60c21338493edd_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp/keystore/5890f0061619c06fb29dea8cb304edecc020fe63f41a6db109f1e227cc1cb2a8_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org1.example.com/users/User1@org1.example.com/msp/keystore/73cdc0072c7203f1ec512232c780fc84acc9752ef30ebc16be1f4666c02b614b_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/peers/peer0.org2.example.com/msp/keystore/0d9f72608133ee627b570b6af6877666bc8f365746f9329d6dd8a5f54e53e2ab_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/peers/peer1.org2.example.com/msp/keystore/27ccb54a06020260c66c65bec91f91e1c9043e3076d3d6128692e7271c4c7a2c_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/users/Admin@org2.example.com/msp/keystore/1995b11d6573ed3be52fcd7a5fa477bc0f183e1f5f398c8281d0ce7c2c75a076_sk D balance-transfer/artifacts/channel/crypto-config/peerOrganizations/org2.example.com/users/User1@org2.example.com/msp/keystore/585175c83bac91fc0c1ce8f9d0ff9aefa47c565678f100ca8673db249ee785ac_sk

JonathanLevi (Tue, 11 Jul 2017 22:06:10 GMT):
Please open a JIRA @lehors

JonathanLevi (Tue, 11 Jul 2017 22:06:21 GMT):
We can move this to the #fabric-release channel

lehors (Tue, 11 Jul 2017 22:06:24 GMT):
ok

JonathanLevi (Tue, 11 Jul 2017 22:06:43 GMT):
Thank you and thanks for the input/feedback!

JonathanLevi (Tue, 11 Jul 2017 22:37:52 GMT):
We have a workaround for the above. See https://chat.hyperledger.org/channel/fabric-release?msg=T2bMdD7JwCzTAHzLb

C0rWin (Tue, 11 Jul 2017 22:51:27 GMT):
`make license` leads to following output error

C0rWin (Tue, 11 Jul 2017 22:51:43 GMT):
``` Checking committed files for SPDX-License-Identifier headers ... The following files are missing SPDX-License-Identifier headers: orderer/multichain/manager.go orderer/multichain/manager_test.go Please replace the Apache license header comment text with: SPDX-License-Identifier: Apache-2.0 make: *** [license] Error 1 ```

C0rWin (Tue, 11 Jul 2017 22:52:41 GMT):
files have old copyrights comments:

C0rWin (Tue, 11 Jul 2017 22:52:47 GMT):
```/* Copyright IBM Corp. 2016 All Rights Reserved. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */```

C0rWin (Tue, 11 Jul 2017 22:54:06 GMT):
btw, isn't license check part of the release process?

C0rWin (Tue, 11 Jul 2017 23:07:01 GMT):
https://gerrit.hyperledger.org/r/#/c/11577/

C0rWin (Tue, 11 Jul 2017 23:07:17 GMT):
^^^ a fix just in case

dave.enyeart (Tue, 11 Jul 2017 23:13:32 GMT):
I reviewed https://gerrit.hyperledger.org/r/#/c/11205. The Write Your First App SDK sample does indeed work now given the updates from @jimthematrix. But I have a concern on one of the scripts, please see my gerrit comment.

dave.enyeart (Tue, 11 Jul 2017 23:13:32 GMT):
I reviewed https://gerrit.hyperledger.org/r/#/c/11205. The Write Your First App SDK sample does indeed work now given the updates from @jimthematrix . But I have a concern on one of the scripts, please see my gerrit comment.

JonathanLevi (Wed, 12 Jul 2017 00:02:45 GMT):
========== BTW: To be clear, the release is not complete. Stuff is still being sync, and as you see, there are bits and pieces everywhere that are being ironed out (from minor things all the way to legal). But regardless, this is just a reminder that we are still in *CODE FREEZE* mode. Feel free to +2 whatever you deem appropriate, but please let's have @cbf, @mastersingh24 or I, Jonathan, merging things while we are at it. ==========

JonathanLevi (Wed, 12 Jul 2017 00:02:45 GMT):
========== BTW: To be clear, the release is not complete. Stuff is still being sync'd, and as you see, there are bits and pieces everywhere that are being ironed out (from minor things all the way to legal). But regardless, this is just a reminder that we are still in *CODE FREEZE* mode. Feel free to +2 whatever you deem appropriate, but please let's have @cbf, @mastersingh24 or I, Jonathan, merging things while we are at it. ==========

JonathanLevi (Wed, 12 Jul 2017 00:30:53 GMT):
========== BTW: To be clear, the release is not complete. Stuff is still being sync'd, and as you see, there are bits and pieces everywhere that are being ironed out (from minor things all the way to legal). But regardless, this is just a reminder that we are still in *CODE FREEZE* mode. Feel free to +2 whatever you deem appropriate, but please let's have @cbf, @mastersingh24 or I, Jonathan, merging things while we are at it. That is, please, do not hit *Submit* in gerrit. Thanks in advance. Final steps, and we are done. We're not far acutally... ==========

lehors (Wed, 12 Jul 2017 00:44:13 GMT):
@C0rWin eventually license check will be part of CI but we aren't quite there yet

lehors (Wed, 12 Jul 2017 00:45:31 GMT):
the script anticipates that we use SPDX everywhere but we aren't there yet

lehors (Wed, 12 Jul 2017 01:02:26 GMT):
it is unfortunate that it is part of the default make target

lehors (Wed, 12 Jul 2017 01:27:31 GMT):
actually, I don't know what happened here but I remember Chris had made the script return 0 in all cases to make it informative and avoid the build to fail in such a case. I see the script is back to doing exit 1

naohide (Wed, 12 Jul 2017 01:35:32 GMT):
Has joined the channel.

mastersingh24 (Wed, 12 Jul 2017 03:45:16 GMT):
Unless I am missing something, `make license` is not run by default. The idea was that as we modified files, we would modify the license header - so when you run say `make desk-check` (which only runs against your changes) it will run `make license` to remind you to also modify the license header in any files you've changed

mastersingh24 (Wed, 12 Jul 2017 03:58:55 GMT):
[ Sorry - was on a plane - thanks Jim!](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ZP3EjWFDCHGtFWTMQ) @jimthematrix

jimthematrix (Wed, 12 Jul 2017 13:09:01 GMT):
@dave.enyeart addressed your comment in 11205. thanks

dave.enyeart (Wed, 12 Jul 2017 13:24:47 GMT):
@jimthematrix +2ed 11205. @JonathanLevi it is ready to merge now.

JonathanLevi (Wed, 12 Jul 2017 13:57:46 GMT):
Merged, thanks.

JonathanLevi (Wed, 12 Jul 2017 13:57:52 GMT):
Thoughts on this, please: https://gerrit.hyperledger.org/r/#/c/11573/

JonathanLevi (Wed, 12 Jul 2017 13:58:13 GMT):
Going forward all these "tags" should in one, uno, single, file !

JonathanLevi (Wed, 12 Jul 2017 14:00:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=2ieZHf3289ikxHcTe) Yes,

JonathanLevi (Wed, 12 Jul 2017 14:00:25 GMT):
Totally ^^^

C0rWin (Wed, 12 Jul 2017 14:31:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=dafCXdRiScGPk3Jm9) @JonathanLevi having this goal as part of 'make all', guess we need to at some point to enforce it to avoid confusion

lehors (Wed, 12 Jul 2017 16:19:28 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=2ieZHf3289ikxHcTe) @mastersingh24 that's not what I'm seeing though, for fabric make all includes the license target

lehors (Wed, 12 Jul 2017 16:23:43 GMT):
I think the way to fix it though is to simply change the Makefile to ignore (for now) errors reported by the license check

paapighoda (Thu, 13 Jul 2017 05:48:20 GMT):
Has left the channel.

cbf (Thu, 13 Jul 2017 16:42:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ydJidrck2ecEKhsbp) @C0rWin IMO, we should EXCUDE the year, it is immaterial

cbf (Thu, 13 Jul 2017 16:42:57 GMT):
and we should be using the SPDX-License-Identifier header. However, we should be changing over only as we change files

cbf (Thu, 13 Jul 2017 16:43:03 GMT):
no sense in a mass update

C0rWin (Thu, 13 Jul 2017 16:54:46 GMT):
@cbf wasn't suggesting mass update, but IMO if the goal is to update license header as we making changes we need to enforce it at CI level, to prevent such failures in the future

lehors (Thu, 13 Jul 2017 17:32:28 GMT):
@cbf, did you want change the script back to fail (exit 1)?

lehors (Thu, 13 Jul 2017 17:33:09 GMT):
I actually think that's what it should do but I would change the Makefile target to ignore with a -

cbf (Thu, 13 Jul 2017 19:24:05 GMT):
@lehors we could, yes

lehors (Thu, 13 Jul 2017 21:58:51 GMT):
ok

rjones (Thu, 13 Jul 2017 21:59:54 GMT):
Excluding the year is the way to go. Putting a year into headers makes for goofy arguments that are long lasting and not interesting.

cbf (Thu, 13 Jul 2017 22:11:21 GMT):
+1

cbf (Fri, 14 Jul 2017 14:59:23 GMT):
ok, @JonathanLevi @rjones and I created the release branches for each of the repos EXCEPT fabric-sdk-java

cbf (Fri, 14 Jul 2017 15:00:23 GMT):
so, with that out of the way, think we can release the hounds (eg. remove the merger freeze) for all but fabric-sdk-java

cbf (Fri, 14 Jul 2017 15:00:31 GMT):
@JonathanLevi agree?

JonathanLevi (Fri, 14 Jul 2017 15:01:24 GMT):
To be clear, we are creating a *release* branch for each, using the HEAD fabric, fabric-ca, fabric-sdk-node, ...

cbf (Fri, 14 Jul 2017 15:01:41 GMT):
s/are creating/created/

JonathanLevi (Fri, 14 Jul 2017 15:02:14 GMT):
And we will be making the releases going forward off of these *release* branches

jyellick (Fri, 14 Jul 2017 15:05:08 GMT):
Is the plan to always cut releases from master? Or will will fork off a 1.0.1 release branch and cherry-pick desired commits onto it?

JonathanLevi (Fri, 14 Jul 2017 15:05:43 GMT):
Always cut releases from *release*

kostas (Fri, 14 Jul 2017 15:07:56 GMT):
If a plan has been finalized (as it sounds like), let's summarize it in the mailing list?

JonathanLevi (Fri, 14 Jul 2017 15:08:19 GMT):
Yes, it's JIRA, just quickly (while we are at it). So 4 projects: 1. fabric 2. fabric-ca 3. fabric-sdk-node 4. fabric-samples

JonathanLevi (Fri, 14 Jul 2017 15:08:35 GMT):
(for now,) have a *release* branch.

cbf (Fri, 14 Jul 2017 15:09:38 GMT):
https://jira.hyperledger.org/browse/FAB-5050

dave.enyeart (Fri, 14 Jul 2017 15:48:06 GMT):
will there be a new release branch per release? e.g. once 1.1 is released will it still be possible to provide fixes on top of 1.0?

jyellick (Fri, 14 Jul 2017 15:49:24 GMT):
Posted my question to the JIRA, but concretely, what should a developer do who wants to submit code destined for v1.0.1? How about for v1.1.0?

dave.enyeart (Fri, 14 Jul 2017 15:50:11 GMT):
that was my next question... can we consider 1.0.1 to be bug fixes and therefore done on release branch whereas new features go into master, destined for 1.1?

jyellick (Fri, 14 Jul 2017 15:54:44 GMT):
@cbf @JonathanLevi ^

cbf (Fri, 14 Jul 2017 16:07:01 GMT):
nothing gets merged to release branch except a release

jyellick (Fri, 14 Jul 2017 16:10:32 GMT):
What then is the process for submitting a fix intended for v1.0.1 vs a feature intended for v1.1.0?

cbf (Fri, 14 Jul 2017 16:11:07 GMT):
we're working on an email

cbf (Fri, 14 Jul 2017 16:11:26 GMT):
but new features should have a feature flag IMNSHO

cbf (Fri, 14 Jul 2017 16:12:42 GMT):
also, I think that we should be voting on new features

cbf (Fri, 14 Jul 2017 16:13:13 GMT):
and be much more deliberate as to what we are delivering

JonathanLevi (Fri, 14 Jul 2017 17:21:20 GMT):
BTW, just quickly in the meantime: - Let's begin with smaller steps. - We will continue to work on master (as always). - The imminent upcoming "release" is indeed 1.0.1, which should be out on July 31. - We will work on master, fast forward merge to the *release* branch and release off of that branch

JonathanLevi (Fri, 14 Jul 2017 17:22:23 GMT):
To clarify, we are not trying to avoid answering the questions regarding "what about 1.1". At this very moment, we have a lot of work that needs to be done, by the maintainers, as we worked with a "binary" flag of 1.0.0 or not.

JonathanLevi (Fri, 14 Jul 2017 17:22:23 GMT):
To clarify, we are not trying to avoid answering the questions regarding "what about 1.1, etc.". These are good questions, and we should really document them, review, (re-)iterate (and improve)... At this very moment, we have a lot of work that needs to be done, by the maintainers, as we worked with a "binary" flag of 1.0.0 or not.

JonathanLevi (Fri, 14 Jul 2017 17:23:19 GMT):
We will have to work out a plan for 1.1, what's a minor version/periodical build/release 1.0.1, 1.0.2, ... and what's longer term, such as separating the 1.1 work, the 1.2, etc.

JonathanLevi (Fri, 14 Jul 2017 17:23:50 GMT):
In line what Chris' suggestion above - that we'd simply vote on new features.

JonathanLevi (Fri, 14 Jul 2017 17:24:25 GMT):
[ Can't tell if I have clarified or confused even more... tbh ]

jyellick (Fri, 14 Jul 2017 17:25:38 GMT):
@JonathanLevi I'm still fairly confused if I'm being honest. It sounds like we should not be merging anything into master right now which we do not intend to go to v1.0.1? That seems like it should be the vast majority of CRs

JonathanLevi (Fri, 14 Jul 2017 17:26:29 GMT):
Let's do this: [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=6rqKkEbb29c7AK2mv)

JonathanLevi (Fri, 14 Jul 2017 17:27:35 GMT):
THere are several bugs, test improvements, etc... that didn't make it to 1.0.0 - we can start merging these.

JonathanLevi (Fri, 14 Jul 2017 17:27:55 GMT):
(From the moment we announce the end of the code freeze, etc.)

JonathanLevi (Fri, 14 Jul 2017 17:28:21 GMT):
But that's a good point @jyellick - we should clarify what should be part of 1.0.1

JonathanLevi (Fri, 14 Jul 2017 17:28:30 GMT):
Planning is key. I'm with you.

jyellick (Fri, 14 Jul 2017 17:28:34 GMT):
So, just to clarify. Nothing that is not a bug fix or a feature which has been voted on for v1.0.1 should be merged?

JonathanLevi (Fri, 14 Jul 2017 17:29:46 GMT):
[ Amiably ] I'm afraid to write here, not only, just for the off-chance that you are going to rewrite the entire channel configuration over the weekend! ;-)

JonathanLevi (Fri, 14 Jul 2017 17:29:46 GMT):
[ Amiably ] I'm afraid to write here, "not only", just for the off-chance that you are going to rewrite the entire channel configuration over the weekend! ;-)

JonathanLevi (Fri, 14 Jul 2017 17:31:15 GMT):
How about we should probably discuss this (the expectations/plan for what should get merged into master) further, at the beginning of the week?

JonathanLevi (Fri, 14 Jul 2017 17:31:15 GMT):
How about / we should probably discuss this (the expectations/plan for what should get merged into master) further, at the beginning of the week?

JonathanLevi (Fri, 14 Jul 2017 17:31:15 GMT):
How about / we should probably discuss this (the expectations/plan for what [else, in addition to the above] should get merged into master) further, at the beginning of the week?

jyellick (Fri, 14 Jul 2017 17:37:37 GMT):
Sounds good. We can defer discussion for the moment, as we clearly have a backlog of definitely v1.0.1 material which is fine to work on. But I think this is something that's important we get a handle on, as the cost of deferring is not free. As people begin working on code intended for v1.1.0 with no path to merge, the time which will be wasted resolving merge conflicts will continue to build.

jyellick (Fri, 14 Jul 2017 17:37:37 GMT):
Sounds good. We can defer discussion for the moment, as we clearly have a backlog of definitely v1.0.1 material which is fine to work on. But I think this is something that's important we get a handle on, as the cost of deferring is not free. As people begin working on code intended for v1.1.0 with no path to merge, the time which will ultimately be wasted resolving merge conflicts will continue to build.

jyellick (Fri, 14 Jul 2017 17:37:37 GMT):
Sounds good. We can defer discussion for the moment, as we clearly have a backlog of definitely v1.0.1 material which is fine to work on. But I think this is something that's important we get a handle on, as the cost of deferring is not free. As people begin working on code intended for v1.1.0 with no path to merge, the time which will ultimately be wasted resolving merge conflicts will continue to build (or worse yet, people will begin to hack on dead code paths, etc.).

yacovm (Fri, 14 Jul 2017 17:45:47 GMT):
so what's the status of merging - @JonathanLevi @cbf , when will it resume?

yacovm (Fri, 14 Jul 2017 17:46:20 GMT):
Should we wait for a discussion for next week and until then still a *MERGE FREEZE* ?

JonathanLevi (Fri, 14 Jul 2017 17:48:00 GMT):
I agree with you Jason. That's why I suggest that we clarify it very early next week (when everybody's back)

JonathanLevi (Fri, 14 Jul 2017 17:48:41 GMT):
I'd still rather release the merge freeze sooner. 7 days of a freeze has been sufficient, IMO.

jyellick (Fri, 14 Jul 2017 17:49:09 GMT):
Since the `release` branch has been created, it seems like we should be safe to begin merging bug fixes for v1.0.1?

JonathanLevi (Fri, 14 Jul 2017 17:49:30 GMT):
Yes, that's what I meant above. Indeed.

JonathanLevi (Fri, 14 Jul 2017 17:50:05 GMT):
Let me formalize it a bit more (in an email etc.) but yes, that's the interim plan.

jyellick (Fri, 14 Jul 2017 17:50:25 GMT):
Great thanks! ( @yacovm ^ )

JonathanLevi (Fri, 14 Jul 2017 17:50:37 GMT):
Call it, the "post-release-weekend plan"

cbf (Fri, 14 Jul 2017 17:50:44 GMT):
+1 bug fixes, doc fixes and test code

yacovm (Fri, 14 Jul 2017 17:51:22 GMT):
so the plan for the next 2 weeks is just bug fixes, doc fixes and test code?

JonathanLevi (Fri, 14 Jul 2017 17:51:38 GMT):
And whatever we agree on, early next week.

yacovm (Fri, 14 Jul 2017 17:51:53 GMT):
I guess - stuff that are gray area will be tagged with needs-review as before?

JonathanLevi (Fri, 14 Jul 2017 17:53:54 GMT):
Yes, the gray area (e.g. "new features") - we should vote on, as written above.

JonathanLevi (Fri, 14 Jul 2017 17:54:17 GMT):
(Relatively) clear(er) ? Makes sense to everybody?

yacovm (Fri, 14 Jul 2017 17:55:26 GMT):
Makes sense, only I wasn't really referring to new features - more like small tweaks in performance, simple high availability improvements, etc.

JonathanLevi (Fri, 14 Jul 2017 17:55:55 GMT):
When in doubt, let's just ask around and vote...

JonathanLevi (Fri, 14 Jul 2017 17:55:55 GMT):
When in doubt, let's just ask around. If needed, we'll vote...

JonathanLevi (Fri, 14 Jul 2017 17:57:55 GMT):
I think that next week, we'll have a clearer message to everybody (everybody as in everybody, not just the maintainers) so that the expectations/plan is clear.

cbf (Fri, 14 Jul 2017 19:13:44 GMT):
@yacovm I think that small tweaks are probably fine for performance or stability improvements. Anything more substantial, we should probably handle with the review-needed approach as before

cbf (Fri, 14 Jul 2017 19:14:30 GMT):
I think we will want to have a maintainers meeting early next week with @mastersingh24 back to build consensus on how we manage feature development for post 1.0

cbf (Fri, 14 Jul 2017 19:15:35 GMT):
I definitely prefer a feature flag approach to new feature introduction

cbf (Fri, 14 Jul 2017 19:16:07 GMT):
that way we can easily disable features that aren't ready for prime time

JonathanLevi (Fri, 14 Jul 2017 22:40:07 GMT):
FYI: https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-July/001308.html

JonathanLevi (Fri, 14 Jul 2017 22:40:07 GMT):
FYI: https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-July/001309.html

JonathanLevi (Fri, 14 Jul 2017 22:43:40 GMT):
Or in a line: *CODE FREEZE - END*

mastersingh24 (Sat, 15 Jul 2017 09:48:35 GMT):
CODE THAW?

cbf (Mon, 17 Jul 2017 13:10:10 GMT):
I'm MELTING

jimthematrix (Mon, 17 Jul 2017 13:29:13 GMT):
@cbf I noticed that the 'release' branch in fabric-sdk-node was created with a few CRs that were merged after the 1.0 tag. Not sure if that was done intentionally. I don't think it's a problem (all changes since the 1.0 tagging was doc and tests) but want to call them out here to avoid future confusion

jimthematrix (Mon, 17 Jul 2017 13:29:31 GMT):
@JonathanLevi @mastersingh24 ^^^

JonathanLevi (Mon, 17 Jul 2017 13:30:02 GMT):
We have branched out of HEAD

cbf (Mon, 17 Jul 2017 13:30:17 GMT):
we discussed this and agreed to cut from HEAD to catch any merges that were post tag but merged during the freeze

jyellick (Mon, 17 Jul 2017 17:32:32 GMT):
@JonathanLevi When do you think we can discuss how developers should proceed with v1.1.0 development? [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=97rkv7bxw4XzACFnr)

greg.haskins (Mon, 17 Jul 2017 19:32:41 GMT):
@jwagantall could you check to see if I have "Push Annotated Tags" rights to fabric-chaintool?

greg.haskins (Mon, 17 Jul 2017 19:32:57 GMT):
I pinged @rjones about this on #fabric-chaintool but he seems to be offline

greg.haskins (Mon, 17 Jul 2017 19:33:18 GMT):
posting the question here in the open to be transparent

jwagantall (Mon, 17 Jul 2017 19:41:28 GMT):
let me check..

jwagantall (Mon, 17 Jul 2017 19:43:30 GMT):
you should with this account

jwagantall (Mon, 17 Jul 2017 19:43:32 GMT):
greg.haskins Greg Haskins gregory.haskins@gmail.com

JonathanLevi (Mon, 17 Jul 2017 19:45:33 GMT):
@rjones is around, btw.

JonathanLevi (Mon, 17 Jul 2017 19:46:04 GMT):
(Or at least someone is exchanging ASCII characters with me, on his behalf ;-))

JonathanLevi (Mon, 17 Jul 2017 19:46:04 GMT):
(Or at least someone is/has been exchanging ASCII characters with me, on his behalf ;-))

jwagantall (Mon, 17 Jul 2017 19:46:29 GMT):
hahahah .. yes.. is him :) he is also replying to me :)

rjones (Mon, 17 Jul 2017 19:51:13 GMT):
@jwagantall could you paste that stanza from refs/meta/config? Push Annotated Tag and Pushed Signed should be open to the ldap group

rjones (Mon, 17 Jul 2017 19:51:56 GMT):
Or if that is the case, blink once. Twice if under duress

jwagantall (Mon, 17 Jul 2017 19:57:38 GMT):
yes.. in fact it is

jwagantall (Mon, 17 Jul 2017 19:57:42 GMT):
pushTag = group ldap/hyperledger-gerrit-fabric-chaintool-committers pushTag = group ldap/hyperledger-gerrit-fabric-committers pushSignedTag = group ldap/hyperledger-gerrit-fabric-chaintool-committers pushSignedTag = group ldap/hyperledger-gerrit-fabric-committers

jwagantall (Mon, 17 Jul 2017 19:57:52 GMT):
@greg.haskins is part of these groups..

greg.haskins (Mon, 17 Jul 2017 20:13:29 GMT):
@jwagantall ty for confirming...i must be doign the push wrong

greg.haskins (Mon, 17 Jul 2017 20:15:46 GMT):
@JonathanLevi @cbf either of you push tags recently?

greg.haskins (Mon, 17 Jul 2017 20:16:16 GMT):
I know its tricky to get the magic incantation to make gerrit happy, but i cant seem to recall it

JonathanLevi (Mon, 17 Jul 2017 20:16:18 GMT):
On July 11, 2017, we pushed the "v1.0.0"

greg.haskins (Mon, 17 Jul 2017 20:16:21 GMT):
```Gregs-MBP:fabric-chaintool ghaskins$ git push gerrit v1.0.0 Counting objects: 1, done. Writing objects: 100% (1/1), 170 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) remote: Processing changes: refs: 1, done To ssh://gerrit.hyperledger.org:29418/fabric-chaintool ! [remote rejected] v1.0.0 -> v1.0.0 (prohibited by Gerrit) error: failed to push some refs to 'ssh://greg.haskins@gerrit.hyperledger.org:29418/fabric-chaintool' Gregs-MBP:fabric-chaintool ghaskins$ git push gerrit HEAD:refs/tags/v1.0.0 Total 0 (delta 0), reused 0 (delta 0) remote: Processing changes: refs: 1, done To ssh://gerrit.hyperledger.org:29418/fabric-chaintool ! [remote rejected] HEAD -> v1.0.0 (prohibited by Gerrit) error: failed to push some refs to 'ssh://greg.haskins@gerrit.hyperledger.org:29418/fabric-chaintool'```

greg.haskins (Mon, 17 Jul 2017 20:16:39 GMT):
I did create the tag annotated as far as I know

JonathanLevi (Mon, 17 Jul 2017 20:16:57 GMT):
I think one needs special permissions for pushing a tag.

greg.haskins (Mon, 17 Jul 2017 20:17:07 GMT):
y, but I should have it

greg.haskins (Mon, 17 Jul 2017 20:17:20 GMT):
(I used to do all the tagging before we got _real_ release managers ;)

JonathanLevi (Mon, 17 Jul 2017 20:17:22 GMT):
Yes, you did it before. I remember.

JonathanLevi (Mon, 17 Jul 2017 20:17:30 GMT):
LOL

greg.haskins (Mon, 17 Jul 2017 20:17:53 GMT):
and @jwagantall confirmed that greg.haskins is in the group still

JonathanLevi (Mon, 17 Jul 2017 20:18:00 GMT):
Interesting.

greg.haskins (Mon, 17 Jul 2017 20:18:10 GMT):
do you recall the syntax you used?

greg.haskins (Mon, 17 Jul 2017 20:18:15 GMT):
i remember its a bit wonky

JonathanLevi (Mon, 17 Jul 2017 20:19:59 GMT):
In my case, I had to tag at a specified commit level as something else was merged

JonathanLevi (Mon, 17 Jul 2017 20:20:01 GMT):
So

JonathanLevi (Mon, 17 Jul 2017 20:20:07 GMT):
*git tag -a v1.0.0 e4b4704 -F release_notes/v1.0.0.txt*

greg.haskins (Mon, 17 Jul 2017 20:20:13 GMT):
ah, -a

greg.haskins (Mon, 17 Jul 2017 20:20:18 GMT):
i think I used -m

greg.haskins (Mon, 17 Jul 2017 20:20:21 GMT):
let me try to recreate it

greg.haskins (Mon, 17 Jul 2017 20:20:41 GMT):
(note that you almost _always_ have to specify the commit-id

JonathanLevi (Mon, 17 Jul 2017 20:20:43 GMT):
There is also: *git show-ref --abbrev=7 --tag*

greg.haskins (Mon, 17 Jul 2017 20:20:53 GMT):
at least, if you use a workflow similar to me

greg.haskins (Mon, 17 Jul 2017 20:21:07 GMT):
(because I always commit a "release" and "prepare for next" CR

greg.haskins (Mon, 17 Jul 2017 20:21:24 GMT):
so, I am virtually always tagging the "release" CR when its no longer current

JonathanLevi (Mon, 17 Jul 2017 20:21:29 GMT):
We had a different workflow in alpha2, beta, rc1

JonathanLevi (Mon, 17 Jul 2017 20:21:44 GMT):
But hey, I managed to adapt, 58 minutes later.

JonathanLevi (Mon, 17 Jul 2017 20:21:46 GMT):
;-)

greg.haskins (Mon, 17 Jul 2017 20:21:52 GMT):
anyway, thanks for the hint, let me try that

JonathanLevi (Mon, 17 Jul 2017 20:22:07 GMT):
Sure. This should be helpful, really: *git show-ref --abbrev=7 --tag

JonathanLevi (Mon, 17 Jul 2017 20:22:07 GMT):
Sure. This should be helpful, really: *git show-ref --abbrev=7 --tag*

JonathanLevi (Mon, 17 Jul 2017 20:22:28 GMT):
Also, when I pushed the tags, it wasn't "for review"

JonathanLevi (Mon, 17 Jul 2017 20:22:28 GMT):
That's just me being a paranoid

greg.haskins (Mon, 17 Jul 2017 20:23:39 GMT):
what is the first field in the show-ref?

greg.haskins (Mon, 17 Jul 2017 20:25:52 GMT):
this is bizzare

greg.haskins (Mon, 17 Jul 2017 20:26:06 GMT):
im not sure what you meant by "for review" above

greg.haskins (Mon, 17 Jul 2017 20:26:16 GMT):
mine werent either: pushing tags was always live/direct

JonathanLevi (Mon, 17 Jul 2017 20:27:00 GMT):
--abbrev= Instead of using the default 7 hexadecimal digits as the abbreviated object name, use digits, or as many digits as needed to form a unique object name. An of 0 will suppress long format, only showing the closest tag.

JonathanLevi (Mon, 17 Jul 2017 20:27:12 GMT):
___ That's just me being a paranoid

JonathanLevi (Mon, 17 Jul 2017 20:27:55 GMT):
--- Check with Ry, I don't know why you suddenly can't push a tag

greg.haskins (Mon, 17 Jul 2017 20:28:00 GMT):
whats weird is it doesnt seem to show the thing I tagged

greg.haskins (Mon, 17 Jul 2017 20:28:04 GMT):
something must be wrong

JonathanLevi (Mon, 17 Jul 2017 20:28:23 GMT):
Yes, that's why I suggested this (git show-ref --abbrev=7 --tag)

JonathanLevi (Mon, 17 Jul 2017 20:28:45 GMT):
Not even in *git tag* ?

greg.haskins (Mon, 17 Jul 2017 20:28:58 GMT):
right, thats what I mean

greg.haskins (Mon, 17 Jul 2017 20:29:08 GMT):
show-ref has bizarre output

JonathanLevi (Mon, 17 Jul 2017 20:29:22 GMT):
It's sick ;-)

greg.haskins (Mon, 17 Jul 2017 20:29:30 GMT):
heh

JonathanLevi (Mon, 17 Jul 2017 20:29:47 GMT):
But not in the cool, slang way, probably.

JonathanLevi (Mon, 17 Jul 2017 20:29:58 GMT):
I can take a look

greg.haskins (Mon, 17 Jul 2017 20:30:16 GMT):
so check this out

greg.haskins (Mon, 17 Jul 2017 20:30:21 GMT):
```$ git log --oneline b393b3f (HEAD, tag: v1.0.0) Release v1.0.0 bb7e324 [FAB-5177] Auto-vendor the shim library 50adcfa [FAB-5229] Update prerequistes in getting-started dce2a8f Merge "[FAB-5138] Adds support for map types" 182ee6d [FAB-5138] Adds support for map types 1d0335d [FAB-5227] Add lein-license plugin c86c926 Merge "[FAB-4859] Improve "Getting Started" documentation" 4c28de2 Merge "FAB-3963 add missing license headers" d331054 [FAB-4859] Improve "Getting Started" documentation fd1fe5d FAB-3963 add missing license headers 0462fe6 [FAB-2036] auto-vendor external dependencies b2ce8e9 Merge "FAB-4571 add missing license headers" 286b38d FAB-4571 add missing license headers 1735990 [FAB-4569] Upgrade example02 clients to beta 4ef1145 FAB-4310 add missing CCBY license to docs d8bd2d6 Set version to 1.0.0-alpha3-SNAPSHOT 3027261 [FAB-4154] Upgrade our deps 604a636 [FAB-4011] Update clojurescript example 20a6080 [FAB-4010] Update nodejs example for 1.0.0-alpha2 507edf5 FAB-3898 add changelog.sh e3744de [FAB-3340] fix broken link to contributing doc b8f8a5c Update to use 1.0.0-alpha versions of the SDK 1ee556a Update documentation for readthedocs 0fc1a53 Port example02 nodejs client to latest version of SDK 1da631a Prepare for v0.10.4 development c7caae4 (tag: v0.10.3) Release v0.10.3 5fde1e5 Link golang chaincode with -static cf55d6c Prepare for v0.10.3 development b579a6a (tag: v0.10.2) Release v0.10.2 708af63 Add basic support for eventhub 62f24c2 Remove base64 from protocol d2ceb4e Prepare for v0.10.2 development e40a745 (tag: v0.10.1) Import release v0.10.1 9a8948b (tag: v0.10.0) Import release v0.10.0 6d0f535 (tag: v0.9.2) Import release v0.9.2 3c23654 (tag: v0.9.1) Import release v0.9.1 aecaced (tag: v0.9.0) Import release v0.9.0 f92acb3 (tag: v0.8.1) Import release v0.8.1 20eadfd (tag: v0.8.0) Import release v0.8.0 aa98214 Initial empty repository```

greg.haskins (Mon, 17 Jul 2017 20:30:32 GMT):
```$ git show-ref --tag 1684f05891a6085cd8da1d812665dbe5ec65d417 refs/tags/v0.10.0 31b9841fe8e3b7a87dd70a6281d317ae67adea18 refs/tags/v0.10.1 bc80f0a0440b876ed0b51c9a54ebbf6564b9d0a6 refs/tags/v0.10.2 295bc9d7fb6383c5ca0e531f756468f1b019ef51 refs/tags/v0.10.3 27a34bcf713473034456599d4b92efb69de16bec refs/tags/v0.8.0 e9e8a4cd8e86df5099654c478c23392b83f0d70a refs/tags/v0.8.1 05aed317a137db671d49776233624e6963d090cf refs/tags/v0.9.0 c99d1e15d749315e1a964ba1df5eb2ba46363f40 refs/tags/v0.9.1 3102520be87ca94df66f98cc41f87347d4b7c161 refs/tags/v0.9.2 91d9fa8f2f4d10d47ea9e2002ad7fc63cb23b8e2 refs/tags/v1.0.0```

greg.haskins (Mon, 17 Jul 2017 20:30:50 GMT):
note that the sha in the "git log" output is different from the "show-ref"

greg.haskins (Mon, 17 Jul 2017 20:30:51 GMT):
i dont get it

JonathanLevi (Mon, 17 Jul 2017 20:30:53 GMT):
This one?

JonathanLevi (Mon, 17 Jul 2017 20:30:54 GMT):
git clone git@github.com:hyperledger/fabric-chaintool.git

greg.haskins (Mon, 17 Jul 2017 20:31:00 GMT):
yep

JonathanLevi (Mon, 17 Jul 2017 20:31:50 GMT):
Yup, yours is not "pushed"

JonathanLevi (Mon, 17 Jul 2017 20:32:03 GMT):
*git show-ref --tag* 1684f05891a6085cd8da1d812665dbe5ec65d417 refs/tags/v0.10.0 31b9841fe8e3b7a87dd70a6281d317ae67adea18 refs/tags/v0.10.1 bc80f0a0440b876ed0b51c9a54ebbf6564b9d0a6 refs/tags/v0.10.2 295bc9d7fb6383c5ca0e531f756468f1b019ef51 refs/tags/v0.10.3 27a34bcf713473034456599d4b92efb69de16bec refs/tags/v0.8.0 e9e8a4cd8e86df5099654c478c23392b83f0d70a refs/tags/v0.8.1 05aed317a137db671d49776233624e6963d090cf refs/tags/v0.9.0 c99d1e15d749315e1a964ba1df5eb2ba46363f40 refs/tags/v0.9.1 3102520be87ca94df66f98cc41f87347d4b7c161 refs/tags/v0.9.2

greg.haskins (Mon, 17 Jul 2017 20:32:09 GMT):
understood

greg.haskins (Mon, 17 Jul 2017 20:32:35 GMT):
what I am saying (right now) is that the shas reported in show-ref dont seem to correlate to the commits

greg.haskins (Mon, 17 Jul 2017 20:32:43 GMT):
and I was just curious what that is supposed to be showing

greg.haskins (Mon, 17 Jul 2017 20:33:00 GMT):
its probably not important

greg.haskins (Mon, 17 Jul 2017 20:33:18 GMT):
what is actually important is I keep getting rejected trying to push the v1.0.0 tag for reasons that are unclear

rjones (Mon, 17 Jul 2017 20:46:58 GMT):
Is it signed

rjones (Mon, 17 Jul 2017 20:47:05 GMT):
Is it annotated

rjones (Mon, 17 Jul 2017 20:48:33 GMT):
@greg.haskins I'm on a phone so I can't do much, but could you paste your exact gut command to create the tag?

greg.haskins (Mon, 17 Jul 2017 20:50:29 GMT):
@rjones: I believe signed=no, annotated=yes

greg.haskins (Mon, 17 Jul 2017 20:50:41 GMT):
BUT, I also believe that is how i did every other tag that I managed

greg.haskins (Mon, 17 Jul 2017 20:51:01 GMT):
(which is, I think all of them up until v1.0.0 and maybe beta/rc

greg.haskins (Mon, 17 Jul 2017 20:51:22 GMT):
perhaps we changes the policy rules?

greg.haskins (Mon, 17 Jul 2017 20:51:22 GMT):
perhaps we changed the policy rules?

greg.haskins (Mon, 17 Jul 2017 20:52:20 GMT):
```$ history | grep 'git tag' 26 git tag 35 git tag 126 git tag b393b3fc03187ec9931dc454c39fc63bc7cb76e4 v1.0.0 127 git tag -m "Release v1.0.0" v1.0.0 b393b3fc03187ec9931dc454c39fc63bc7cb76e4 128 git tag 161 git tag -d v1.0.0 162 git tag -m "Release v1.0.0" v1.0.0 166 git tag -d v1.0.0 167 git tag -a "Release v1.0.0" v1.0.0 169 git tag -a "Release v1.0.0" v1.0.0 HEAD 170 git tag -am "Release v1.0.0" v1.0.0 HEAD 179 git tag -d v1.0.0 180 git tag -a -m "Release v1.0.0" v1.0.0 b393b3fc03187ec9931dc454c39fc63bc7cb76e4 190 git tag -d v1.0.0 192 git tag -m "Release v1.0.0" v1.0.0 b393b3fc03187ec9931dc454c39fc63bc7cb76e4 196 history | grep 'git tag'```

greg.haskins (Mon, 17 Jul 2017 20:52:24 GMT):
@rjones: ^^^

greg.haskins (Mon, 17 Jul 2017 20:52:48 GMT):
that was my various (failed) attempts, heh

greg.haskins (Mon, 17 Jul 2017 20:53:09 GMT):
basically I tried all combos of -a/-m

greg.haskins (Mon, 17 Jul 2017 20:53:46 GMT):
i am reasonably sure that I only did "192" in the past

rjones (Mon, 17 Jul 2017 20:56:13 GMT):
@greg.haskins I haven't touched these rules in forever. I'm pretty sure the tag must be signed. Just add a `-s` (little s) to !192

rjones (Mon, 17 Jul 2017 20:56:36 GMT):
unless you want to do GPG signing, which is A OK; in which case, use `-S`

rjones (Mon, 17 Jul 2017 20:59:30 GMT):
@jwagantall @greg.haskins I have to run to a different appointment but I will follow along on my phone

jwagantall (Mon, 17 Jul 2017 20:59:47 GMT):
sounds good @rjones

greg.haskins (Mon, 17 Jul 2017 21:02:51 GMT):
@JonathanLevi do you recall doing "-s"

greg.haskins (Mon, 17 Jul 2017 21:03:13 GMT):
im on a new laptop and would need to setup GPG, and can...but I dont recall doing this before

rjones (Mon, 17 Jul 2017 21:15:44 GMT):
You don't need GPG for little s

JonathanLevi (Mon, 17 Jul 2017 21:15:52 GMT):
Nope, the above is literally the output from my terminal's *history*

JonathanLevi (Mon, 17 Jul 2017 21:16:27 GMT):
No -s, -S, ...

rjones (Mon, 17 Jul 2017 21:16:48 GMT):
I'll debug this after this appointment I apologize for the timing

greg.haskins (Mon, 17 Jul 2017 21:18:23 GMT):
@rjones: no worries, when you can

greg.haskins (Mon, 17 Jul 2017 21:18:32 GMT):
but note that even -s was prompting me for gpg-isms

greg.haskins (Mon, 17 Jul 2017 21:18:51 GMT):
```$ git tag -s -m "Release v1.0.0" v1.0.0 b393b3fc03187ec9931dc454c39fc63bc7cb76e4 error: gpg failed to sign the data error: unable to sign the tag```

greg.haskins (Mon, 17 Jul 2017 21:18:55 GMT):
could be operator error

rjones (Mon, 17 Jul 2017 21:19:22 GMT):
Shouldn't. It should just inject the signed off by line into the commit

greg.haskins (Mon, 17 Jul 2017 21:19:47 GMT):
thats for commit i think

greg.haskins (Mon, 17 Jul 2017 21:20:00 GMT):
git commit -s will add a DCO

rjones (Mon, 17 Jul 2017 21:20:37 GMT):
Ah ok, I thought the option was the same for fit tag

greg.haskins (Mon, 17 Jul 2017 21:20:47 GMT):
in any case, i am fairly sure that "git tag -m 'msg'" was all that was needed in the past

rjones (Mon, 17 Jul 2017 21:21:02 GMT):
Yes

greg.haskins (Mon, 17 Jul 2017 21:21:07 GMT):
im guessing there is nothing wrong with the tag creation itself, but I am goofing something up with the push

greg.haskins (Mon, 17 Jul 2017 21:21:35 GMT):
I recall gerrit has weird requirements, not quite natural to normal git-isms

greg.haskins (Mon, 17 Jul 2017 21:21:55 GMT):
but I tried all permutations I could think of, all seemed to be rejected in a similar manner

rjones (Mon, 17 Jul 2017 21:21:57 GMT):
What is your exact push command

greg.haskins (Mon, 17 Jul 2017 21:22:03 GMT):
(thus my question about perms)

greg.haskins (Mon, 17 Jul 2017 21:22:35 GMT):
``` 142 git push gerrit v1.0.0 143 git push gerrit v1.0.0:refs/tags/v1.0.0 144 git push gerrit v1.0.0:v1.0.0 145 git push gerrit v1.0.0 146 git push gerrit v1.0.0:refs/heads/v1.0.0 147 git push gerrit v1.0.0 HEAD:refs/heads/v1.0.0 149 git push gerrit HEAD:refs/heads/v1.0.0 150 git push gerrit HEAD:refs/tags/v1.0.0 151 git push gerrit HEAD refs/tags/v1.0.0 152 git push gerrit v1.0.0 refs/tags/v1.0.0 153 git push gerrit v1.0.0 159 git push gerrit v1.0.0 160 git push gerrit HEAD:refs/tags/v1.0.0 165 git push gerrit HEAD:refs/tags/v1.0.0 171 git push gerrit HEAD:refs/tags/v1.0.0 182 git push gerrit HEAD:refs/tags/v1.0.0 183 git push gerrit :v1.0.0 184 git push gerrit v1.0.0 194 git push gerrit v1.0.0```

greg.haskins (Mon, 17 Jul 2017 21:22:54 GMT):
(note that HEAD and v1.0.0 are the same refspec in my case

greg.haskins (Mon, 17 Jul 2017 21:23:20 GMT):
all of the above fail with a similar error

greg.haskins (Mon, 17 Jul 2017 21:23:42 GMT):
im sure I am doing something blatantly dumb, i just cant spot it

greg.haskins (Mon, 17 Jul 2017 21:25:17 GMT):
```Gregs-MBP:fabric-chaintool ghaskins$ git tag -m "Release v1.0.0" v1.0.0 b393b3fc03187ec9931dc454c39fc63bc7cb76e4 Gregs-MBP:fabric-chaintool ghaskins$ git push gerrit v1.0.0 Counting objects: 1, done. Writing objects: 100% (1/1), 171 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 0 (delta 0) remote: Processing changes: refs: 1, done To ssh://gerrit.hyperledger.org:29418/fabric-chaintool ! [remote rejected] v1.0.0 -> v1.0.0 (prohibited by Gerrit) error: failed to push some refs to 'ssh://greg.haskins@gerrit.hyperledger.org:29418/fabric-chaintool'```

rjones (Mon, 17 Jul 2017 21:25:21 GMT):
Is shell globbing the periods in the tag?

greg.haskins (Mon, 17 Jul 2017 21:25:24 GMT):
for example

greg.haskins (Mon, 17 Jul 2017 21:25:35 GMT):
it shouldnt

greg.haskins (Mon, 17 Jul 2017 21:25:47 GMT):
all my tags have had periods in them before

greg.haskins (Mon, 17 Jul 2017 21:25:57 GMT):
(anything is possible, however)

greg.haskins (Mon, 17 Jul 2017 21:26:23 GMT):
let me check my ssh config

rjones (Mon, 17 Jul 2017 21:26:26 GMT):
Unreacgable commit? What does --follow-tags do

greg.haskins (Mon, 17 Jul 2017 21:26:33 GMT):
maybe this laptop is not submitting the right credentials

greg.haskins (Mon, 17 Jul 2017 21:26:50 GMT):
what is the full command?

rjones (Mon, 17 Jul 2017 21:27:05 GMT):
Ah that is the most reasonable guess

rjones (Mon, 17 Jul 2017 21:28:02 GMT):
I was reading https://stackoverflow.com/questions/5195859/push-a-tag-to-a-remote-repository-using-git and it mentioned follow tags

greg.haskins (Mon, 17 Jul 2017 21:28:05 GMT):
can you see anything in the logs on your side?

rjones (Mon, 17 Jul 2017 21:28:16 GMT):
I'm on my phone

rjones (Mon, 17 Jul 2017 21:28:27 GMT):
Later I can check, I doubt it

rjones (Mon, 17 Jul 2017 21:28:45 GMT):
Can you do stream events?

rjones (Mon, 17 Jul 2017 21:29:11 GMT):
Ssh -P portno gerrit gerrit stream-events

greg.haskins (Mon, 17 Jul 2017 21:32:03 GMT):
```$ ssh -p 29418 greg.haskins@gerrit.hyperledger.org **** Welcome to Gerrit Code Review **** Hi Greg Haskins, you have successfully connected over SSH. Unfortunately, interactive shells are disabled. To clone a hosted Git repository, use: git clone ssh://greg.haskins@gerrit.hyperledger.org:29418/REPOSITORY_NAME.git Connection to gerrit.hyperledger.org closed.```

greg.haskins (Mon, 17 Jul 2017 21:32:10 GMT):
implies my credentials are good

greg.haskins (Mon, 17 Jul 2017 21:32:50 GMT):
BTW: --follow-tags had identical error

rjones (Mon, 17 Jul 2017 21:40:53 GMT):
Do a gerrit stream-events

rjones (Mon, 17 Jul 2017 21:40:58 GMT):
Or gerrit help

rjones (Mon, 17 Jul 2017 21:41:20 GMT):
I think all committees also have stream-events

rjones (Mon, 17 Jul 2017 21:41:44 GMT):
Your credentials may be good but the wrong ones

rjones (Mon, 17 Jul 2017 21:41:58 GMT):
I know you had a couple

greg.haskins (Mon, 17 Jul 2017 21:58:59 GMT):
```$ ssh -p 29418 greg.haskins@gerrit.hyperledger.org gerrit stream-events Capability streamEvents is required to access this resource```

rjones (Mon, 17 Jul 2017 22:06:40 GMT):
@greg.haskins I changed the ACL, could you try again?

greg.haskins (Mon, 17 Jul 2017 22:07:09 GMT):
@rjones seems to have same failure

greg.haskins (Mon, 17 Jul 2017 22:07:15 GMT):
oh wait

greg.haskins (Mon, 17 Jul 2017 22:07:17 GMT):
i tried a push

greg.haskins (Mon, 17 Jul 2017 22:07:19 GMT):
hold on

greg.haskins (Mon, 17 Jul 2017 22:07:44 GMT):
ok, my stream-events thing is just sitting there, presumably listening for events

rjones (Mon, 17 Jul 2017 22:07:59 GMT):
OK. that means that you are using the correct credentials

greg.haskins (Mon, 17 Jul 2017 22:07:59 GMT):
(sorry, i misunderstood what "try again" meant ;)

rjones (Mon, 17 Jul 2017 22:08:19 GMT):
:)

rjones (Mon, 17 Jul 2017 22:08:59 GMT):
that was to prove to me that you were using the credentials in that group, and that `stream-events` works says you are

rjones (Mon, 17 Jul 2017 22:11:36 GMT):
@JonathanLevi could I ask you to attempt to create and push this tag for `fabric-chaintool` ? @greg.haskins would that be OK?

rjones (Mon, 17 Jul 2017 22:12:36 GMT):
I ask because @JonathanLevi has pushed tags to `fabric`, and both `ldap/hyperledger-gerrit-fabric-committers` and `ldap/hyperledger-gerrit-fabric-chaintool-committers` have the same permissions

rjones (Mon, 17 Jul 2017 22:13:13 GMT):
on `fabric-chaintool`. the permissions on `refs/tags/*` are the same for `fabric` and `fabric-chaintool`

greg.haskins (Mon, 17 Jul 2017 22:13:21 GMT):
@JonathanLevi it should be "v1.0.0' against this: https://github.com/hyperledger/fabric-chaintool/commit/b393b3fc03187ec9931dc454c39fc63bc7cb76e4

rjones (Mon, 17 Jul 2017 22:14:03 GMT):
if that fails, we have a conundrum.

JonathanLevi (Mon, 17 Jul 2017 22:25:52 GMT):
git push Enter passphrase for key '/Users/jonathan/.ssh/id_rsa': ERROR: Permission to hyperledger/fabric-chaintool.git denied to *hacera*. fatal: Could not read from remote repository.

JonathanLevi (Mon, 17 Jul 2017 22:25:52 GMT):
I think I have made it

greg.haskins (Mon, 17 Jul 2017 22:26:28 GMT):
@rjones: ah, chaintool might have a different LDAP group for maintainers

greg.haskins (Mon, 17 Jul 2017 22:26:42 GMT):
perhaps I dont have the push-tags there?

rjones (Mon, 17 Jul 2017 22:27:19 GMT):
when you are logged in to gerrit, and you open this link: https://gerrit.hyperledger.org/r/#/admin/projects/fabric-chaintool,access , what do you see?

JonathanLevi (Mon, 17 Jul 2017 22:27:38 GMT):
Can you check locally?

rjones (Mon, 17 Jul 2017 22:28:15 GMT):
https://github.com/hyperledger/fabric-chaintool/releases

rjones (Mon, 17 Jul 2017 22:28:25 GMT):
https://github.com/hyperledger/fabric-chaintool/releases/tag/v1.0.0

JonathanLevi (Mon, 17 Jul 2017 22:28:54 GMT):
Yup. Worked, right?

JonathanLevi (Mon, 17 Jul 2017 22:29:10 GMT):
The right commit-level ?

greg.haskins (Mon, 17 Jul 2017 22:29:10 GMT):

Message Attachments

greg.haskins (Mon, 17 Jul 2017 22:29:16 GMT):
looks right

JonathanLevi (Mon, 17 Jul 2017 22:29:30 GMT):
Good stuff.

greg.haskins (Mon, 17 Jul 2017 22:29:48 GMT):
what was the command you used @JonathanLevi ?

greg.haskins (Mon, 17 Jul 2017 22:30:01 GMT):
(command(s), i should say

JonathanLevi (Mon, 17 Jul 2017 22:30:07 GMT):
It's a too aggressive one, to be honest... I know.

JonathanLevi (Mon, 17 Jul 2017 22:30:12 GMT):
Failed without it, so:

rjones (Mon, 17 Jul 2017 22:30:12 GMT):
oh man

JonathanLevi (Mon, 17 Jul 2017 22:30:20 GMT):
git push gerrit-chaintool --tags

rjones (Mon, 17 Jul 2017 22:30:26 GMT):
dude we had this discussion

greg.haskins (Mon, 17 Jul 2017 22:30:49 GMT):
hmm

greg.haskins (Mon, 17 Jul 2017 22:30:51 GMT):
i dont get it

rjones (Mon, 17 Jul 2017 22:31:08 GMT):
OK. My eyes are dilated, the tag is in place, I'm going to go sit somewhere dark

rjones (Mon, 17 Jul 2017 22:31:27 GMT):
I somewhat suspect that tag isn't reachable, since it apparently failed when pushed by name

greg.haskins (Mon, 17 Jul 2017 22:31:41 GMT):
it seems to be on the right SHA

JonathanLevi (Mon, 17 Jul 2017 22:32:06 GMT):
git push gerrit-chaintool refs/tags/v1.0.0

JonathanLevi (Mon, 17 Jul 2017 22:33:12 GMT):
*git remote -v* gerrit-chaintool ssh://JonathanLevi@gerrit.hyperledger.org:29418/fabric-chaintool.git (fetch) gerrit-chaintool ssh://JonathanLevi@gerrit.hyperledger.org:29418/fabric-chaintool.git (push)

rjones (Mon, 17 Jul 2017 22:34:16 GMT):
should I edit in the release notes and try to remember how to generate the binaries?

JonathanLevi (Mon, 17 Jul 2017 23:08:46 GMT):
Do you guys need anything else from me?

rjones (Tue, 18 Jul 2017 00:02:53 GMT):
no

greg.haskins (Tue, 18 Jul 2017 13:22:07 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=6MX3nM2GRbxo3Ngub) @rjones Until we have the CI automation patch in place that @rameshthoomu is working on, that would be good

greg.haskins (Tue, 18 Jul 2017 13:22:31 GMT):
the question really is: do we do this release in the old GH releases way, or the nexus way

greg.haskins (Tue, 18 Jul 2017 13:22:55 GMT):
(btw: to make the binary, just check out the tag, do "make", and then the artifact is in ./target/chaintool

greg.haskins (Tue, 18 Jul 2017 13:23:29 GMT):
here is the relevant CR

greg.haskins (Tue, 18 Jul 2017 13:23:30 GMT):
https://gerrit.hyperledger.org/r/#/c/11715/

dave.enyeart (Tue, 18 Jul 2017 13:29:59 GMT):
@cbf @JonathanLevi Is there a plan around how to build/deliver fixes on top of 1.0.0? I had previously assumed that there would be a 1.0.0 release branch where critical defects could be merged and patches built. But it sounds like that is not the direction we're going. Sounds like defects along with new features will all go into master. With that approach, how to provide fixes only on top of 1.0.0?

dave.enyeart (Tue, 18 Jul 2017 13:31:28 GMT):
I'm raising this now because I opened a defect on behalf of a customer interaction: https://jira.hyperledger.org/browse/FAB-5353

greg.haskins (Tue, 18 Jul 2017 13:41:06 GMT):
@dave.enyeart I think there really isn't any other sane way to do it. In my mind, what needs to be worked out is how that integrates with the rest of the flow

greg.haskins (Tue, 18 Jul 2017 13:42:17 GMT):
without any automation/management/monitoring, it would basically be on the dev to submit a CR to each relevant branch (in this case, presumably v1.0.0 and master)

greg.haskins (Tue, 18 Jul 2017 13:42:25 GMT):
sorry, v1.0.x branch

greg.haskins (Tue, 18 Jul 2017 13:43:12 GMT):
we do have to be careful though, because as history has taught us, we suck at doing this accurate

greg.haskins (Tue, 18 Jul 2017 13:43:14 GMT):
accurately

dave.enyeart (Tue, 18 Jul 2017 13:44:06 GMT):
ok, just wanted to be sure this is considered while the release branching approach is documented. currently there are some questions in FAB-5050

greg.haskins (Tue, 18 Jul 2017 13:44:08 GMT):
and then someone like me and @muralisr have to spend a long weekend sorting out everyones mess

greg.haskins (Tue, 18 Jul 2017 13:44:18 GMT):
and I really dont want to do that again ;)

jimthematrix (Tue, 18 Jul 2017 13:53:54 GMT):
@dave.enyeart agree with Greg and also commented on FAB-5050

jimthematrix (Tue, 18 Jul 2017 13:53:54 GMT):
@dave.enyeart agree with Greg and also commented on FAB-5050 (node SDK has had to do one of these hotfix branches already, back in 1.0.0 alpha)

jimthematrix (Tue, 18 Jul 2017 13:58:31 GMT):
https://jira.hyperledger.org/browse/FAB-2331 - needs review and votes, for javascript chaincode support. I put that under 1.1 for now, but the Composer team is dependent on it and would like that to be the basis of their 1.0 release instead of Otto the JS interpreter written in Golang

yacovm (Tue, 18 Jul 2017 14:00:00 GMT):
@jimthematrix the idea is the implement a shim in node.js that'll run in a container?

jimthematrix (Tue, 18 Jul 2017 14:01:02 GMT):
yes for the former (js based shim impl) and in debate for the latter (whether in separate docker or co-located proc in the peer docker)

yacovm (Tue, 18 Jul 2017 14:06:08 GMT):
IMO it should be in a container

greg.haskins (Tue, 18 Jul 2017 14:07:15 GMT):
I agree with yacovm...until we sort out a suitable platform design that includes various isolation techniques that we are comfortable with, I think it makes sense to assume docker

greg.haskins (Tue, 18 Jul 2017 14:07:31 GMT):
done right, its almost 0 overhead anyway

yacovm (Tue, 18 Jul 2017 14:07:55 GMT):
it's not only that. we are aiming to have life cycle for chaincodes right?

yacovm (Tue, 18 Jul 2017 14:08:08 GMT):
so if we would implement life cycle for containers

greg.haskins (Tue, 18 Jul 2017 14:08:12 GMT):
yes, but I dont see that predicated on docker

yacovm (Tue, 18 Jul 2017 14:08:15 GMT):
we would need to re-implement in for JS

yacovm (Tue, 18 Jul 2017 14:08:20 GMT):
and then some other language would come

greg.haskins (Tue, 18 Jul 2017 14:08:26 GMT):
it would just be part of the driver for whatever the container is

yacovm (Tue, 18 Jul 2017 14:08:29 GMT):
and would want to run outside, like JS

greg.haskins (Tue, 18 Jul 2017 14:08:47 GMT):
understood...i am not saying we would ever have explicit JS linkagages

greg.haskins (Tue, 18 Jul 2017 14:09:02 GMT):
all that I am saying is that there are other potential isolation techniques other than "run in docker"

greg.haskins (Tue, 18 Jul 2017 14:09:35 GMT):
for instance, fork(); secomp(); exec(nodejs)

greg.haskins (Tue, 18 Jul 2017 14:09:54 GMT):
but all I am saying is that until we sort that out and decide there are other viable avenues, assume docker containment

greg.haskins (Tue, 18 Jul 2017 14:11:36 GMT):
the bottom line is: using a two-phased build like we do for GOLANG/CAR produces a docker container that is practically 0 overhead, but normalizes the lifecycle and isolation management behind the docker api

greg.haskins (Tue, 18 Jul 2017 14:12:02 GMT):
this might be the most sensible path forward indefinitely, and it is certainly the _only_ path we have right now

jimthematrix (Tue, 18 Jul 2017 14:27:30 GMT):
@greg.haskins @yacovm I think we are on the same page (see my last comment in FAB-2331)

yacovm (Tue, 18 Jul 2017 14:41:15 GMT):
btw @jimthematrix does mutual TLS work in node.js ? (If we would want mutual TLS in the future between the peer and the shim)

yacovm (Tue, 18 Jul 2017 14:41:30 GMT):
I recall you saying some time that it doesn't or something like that

cbf (Tue, 18 Jul 2017 14:56:36 GMT):
@here https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-July/001314.html

jyellick (Tue, 18 Jul 2017 15:00:35 GMT):
Not sure if the intent is to discuss on the mailing list, JIRA, or here, but I would agree with the assessment that v1.0 is probably not a great candidate for LTS. Are you ( @cbf ) proposing that we quickly release v1.0.1 and then begin merging v1.1 candidates into master immediately after with the assumption that v1.0.1 will go end of life when v1.1 is published?

yacovm (Tue, 18 Jul 2017 15:02:01 GMT):
I think we need to map what is missing in v1.0 to be a LTS first and foremost...

cbf (Tue, 18 Jul 2017 15:06:32 GMT):
maybe email is best

jimthematrix (Tue, 18 Jul 2017 15:18:17 GMT):
@yacovm as far as I'm aware grpc clients in node.js can do TLS mutual auth, I believe you were referring to our discussions on binding the event registration requests to the server cert, for which the node.js grpc support for getting the server cert from handshake was lacking (or at least not easy to determine if it's there)

jimthematrix (Tue, 18 Jul 2017 15:18:17 GMT):
@yacovm as far as I'm aware grpc clients in node.js can do TLS mutual auth, I believe you were referring to our past discussions on binding the event registration requests to the server cert, for which the node.js grpc support for getting the server cert from handshake was lacking (or at least not easy to determine if it's there)

yacovm (Tue, 18 Jul 2017 15:18:31 GMT):
ah yeah

yacovm (Tue, 18 Jul 2017 15:18:33 GMT):
exactly :)

yacovm (Tue, 18 Jul 2017 15:18:36 GMT):
nice memory!

jimthematrix (Tue, 18 Jul 2017 15:18:44 GMT):
;-)

yacovm (Tue, 18 Jul 2017 15:19:26 GMT):
so I think we're good... am concerned for this (I still want to make the chaincode and the peer talk mutual TLS at some point)

colinGrahms (Wed, 19 Jul 2017 09:07:12 GMT):
Has joined the channel.

mastersingh24 (Wed, 19 Jul 2017 14:53:42 GMT):
@jimthematrix @smithbk @rickr - Can you guys take a look at bugs for each of your components and set the target to 1.0.1 for anything you think can be completed by 7/26 and that you feel should be included in the first patch release?

mastersingh24 (Wed, 19 Jul 2017 14:54:09 GMT):
And please make sure that the JIRA's reference any CRs which are merged or in progress?

mastersingh24 (Wed, 19 Jul 2017 14:54:11 GMT):
Thanks

jimthematrix (Wed, 19 Jul 2017 15:17:49 GMT):
@mastersingh24 that has been done for node SDK

jimthematrix (Wed, 19 Jul 2017 15:18:29 GMT):
most 1.0.1 are already in review, the only outstanding one is https://jira.hyperledger.org/browse/FAB-5363

jyellick (Wed, 19 Jul 2017 15:19:58 GMT):
Congrats to @mastersingh24 running unopposed in his landslide victory to become 1.0.x release manager!

dave.enyeart (Wed, 19 Jul 2017 15:41:16 GMT):
@mastersingh24 @cbf As incoming and outgoing release managers, you are aware that work has been ongoing for a while on https://jira.hyperledger.org/browse/FAB-5079, ledger support of private chaincode data aka side db. Since there was no release branch strategy at the time and a code freeze under effect, work proceeded in a side github fork.

dave.enyeart (Wed, 19 Jul 2017 15:41:37 GMT):
Now that we have a release strategy, the intent is to split the code into manageable pieces and submit to gerrit master. However, before asking people to do detailed review on a series of N changesets, only to get to the Nth changeset and realize some refactor is needed, we wanted to get some quick review on the overall approach wrt new feature development in the presence of 1.0.x code. Also wanted to provide visibility to components that will be dependent on the code.

dave.enyeart (Wed, 19 Jul 2017 15:41:50 GMT):
Therefore I suggest to initially push all the code in a large CR, for first-level awareness/review of general approach, but not intended for +2/merge. Then if there is agreement on overall approach, break it up into manageable pieces that will individually be pushed to gerrit, reviewed, and merged. Given where we are, is there agreement on the review approach?

mastersingh24 (Wed, 19 Jul 2017 16:25:54 GMT):
I would expect no less (https://chat.hyperledger.org/channel/fabric-maintainers?msg=L4EtATKww9L6uGp8e) @jimthematrix

jyellick (Wed, 19 Jul 2017 16:51:06 GMT):
Just to make things clear. Since @mastersingh24 is curating the v1.0.x release branches (which will be constructed not as a FF merge from master, but rather as some form of cherry-picking), we should be okay to begin merging v1.1 content? From an orderer perspective, I'd like to get the message flow optimizations through sooner than later. This may make cherry-picking any new bug-fixes into the 1.0.x release less straightforward, but I am happy to shoulder the backporting effort there.

dave.enyeart (Wed, 19 Jul 2017 17:41:02 GMT):
I think that sounds like a very reasonable approach @jyellick

mastersingh24 (Wed, 19 Jul 2017 17:43:29 GMT):
I know there are people who think everything should be automated, but Ive researched several projects who utilize a cherry-pick from master plus sometimes backporting approach as required for fixes deemed appropriate / critical for a patch

kostas (Wed, 19 Jul 2017 18:19:05 GMT):
Is there a way we can make the "which commits to cherry-pick" easier for you as we move forward, or we leave this entirely to you? Assuming, say, 100 commits at the end of each month, you going through all of them is not impossible but I'm wondering if there's something here that could make things easier.

kostas (Wed, 19 Jul 2017 18:19:05 GMT):
Is there a way we can make the "which commits to cherry-pick" process easier for you as we move forward, or we leave this entirely to you? Assuming, say, 100 commits at the end of each month, you going through all of them is not impossible but I'm wondering if there's something here that could make things easier.

kostas (Wed, 19 Jul 2017 18:19:05 GMT):
~Is there a way we can make the "which commits to cherry-pick" process easier for you as we move forward, or we leave this entirely to you? Assuming, say, 100 commits at the end of each month, you going through all of them is not impossible but I'm wondering if there's something here (some JIRA trickery at least) that could simplify the filtering.~ I am blind, the answer's right here, missed it because it was addressed to Jim & co.: https://chat.hyperledger.org/channel/fabric-maintainers?msg=EFK7uBGY7Hnv7vkh2

smithbk (Wed, 19 Jul 2017 18:48:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=EFK7uBGY7Hnv7vkh2) @mastersingh24 Done for fabric-ca

mastersingh24 (Wed, 19 Jul 2017 18:59:53 GMT):
I was going to take a stab at it for core fabric and then ask for others to look / add to the list. I have a pretty good sense on Fabric and had started doing some of it. (https://chat.hyperledger.org/channel/fabric-maintainers?msg=aEYxgdDpvBfLBTkFJ) @kostas

Sujeeban (Thu, 20 Jul 2017 09:44:11 GMT):
Has joined the channel.

paapighoda (Fri, 21 Jul 2017 10:44:44 GMT):
Has joined the channel.

cbf (Fri, 21 Jul 2017 12:25:55 GMT):
I added https://jira.hyperledger.org/browse/FAB-3978 to 'review-needed' - there has been lots of discussion about the design, but the question asked is "can we create this sub-project/repo". Let's not get lost in the weeds. do we agree that a REST SDK would be "a good thing"?

cbf (Fri, 21 Jul 2017 12:29:55 GMT):
@here gentle reminder that when you merge a CR, please be sure to update the JIRA item's status accordingly - thanks

cbf (Mon, 24 Jul 2017 14:18:10 GMT):
I just noticed that the 'review-needed' query in JIRA was only looking at pre-1.0 issues... I fixed the query... note that there are a number that need attention

cbf (Mon, 24 Jul 2017 14:18:23 GMT):
@here ^^

greg.haskins (Mon, 24 Jul 2017 15:03:47 GMT):
@mastersingh24 really want to get this into the next v1.0.x patch release: https://gerrit.hyperledger.org/r/#/c/11763/

greg.haskins (Mon, 24 Jul 2017 15:04:33 GMT):
are you cutting from master or has a new branch been formed?

mastersingh24 (Mon, 24 Jul 2017 18:12:45 GMT):
@greg.haskins - right now I was going to cherry pick and build off the release branch just to see if the process will work moving forward (rather than cut a 1.0.X branch this round)

mastersingh24 (Mon, 24 Jul 2017 18:12:56 GMT):
Just tag the JIRA with 1.0.1

mastersingh24 (Mon, 24 Jul 2017 18:12:58 GMT):
;)

mastersingh24 (Mon, 24 Jul 2017 18:13:57 GMT):
will chaintool be staying at 1.0.0?

greg.haskins (Mon, 24 Jul 2017 18:47:35 GMT):
@mastersingh24 i've been debating what to do about chaintool v fabric versioning

greg.haskins (Mon, 24 Jul 2017 18:47:50 GMT):
my current thinking is: they really should remain separate

greg.haskins (Mon, 24 Jul 2017 18:48:23 GMT):
the v1.0.0 designation is more about the independent event of graduating the tool along with the rest of fabric, more than it is associating it with fabric-1.0.0

greg.haskins (Mon, 24 Jul 2017 18:48:42 GMT):
chaintool is not likely to move versions at the same pace as fabric

greg.haskins (Mon, 24 Jul 2017 18:49:04 GMT):
in any case, based on that thinking, I dont have a problem with chaintool-1.0.0 being released with fabric-1.0.1

greg.haskins (Mon, 24 Jul 2017 18:49:32 GMT):
and I am not quite sure how we would sanely managed coupling the versions even if we thought that was desirable

greg.haskins (Mon, 24 Jul 2017 18:49:32 GMT):
and I am not quite sure how we would sanely manage coupling the versions even if we thought that was desirable

cbf (Mon, 24 Jul 2017 19:11:50 GMT):
@greg.haskins we probably want to maintain some sort of mapping somewhere

cbf (Mon, 24 Jul 2017 19:12:18 GMT):
chaintool, cello, composer, explorer versions known to work with the current version of Fabric

cbf (Mon, 24 Jul 2017 19:46:57 GMT):
@here apparently there is a new version of Gerrit that has an improved UI https://gerrit-review.googlesource.com/q/status:open

cbf (Mon, 24 Jul 2017 19:47:10 GMT):
https://www.gerritcodereview.com/releases/2.14.md

jiangyaoguo (Tue, 25 Jul 2017 02:28:11 GMT):
kubernetes@3

greg.haskins (Tue, 25 Jul 2017 10:28:58 GMT):
new version looks nice

binhn (Tue, 25 Jul 2017 17:02:13 GMT):
Nominate Alessandro Sorniotti as maintainer https://gerrit.hyperledger.org/r/#/c/11909/ Please review

markparz (Wed, 26 Jul 2017 16:19:59 GMT):
Hi @here all maintainers, Greg Wallace and I were talking on the logo pieces and we'd like to get a logo finalized and adopted, it was agreed to have the maintainers have the vote on the logo to go with.... while there are suggestions in some of the docs, for all the different projects under Hyperledger, for now let's just focus on fabric. There are a few entries under https://jira.hyperledger.org/browse/FAB-2185?jql=text%20~%20%22logo%22 Please look at the 1- first .png (FabricLogo1-1.png) , 2- Hyperledger_branding ideas_v2.pdf (3rd file) and 3- Hyperledger Logos For Presentation3.pdf (the last file). If you can look these over and place your vote for 1, 2 or 3 (or "I don't care / hate them all") by EOD tomorrow it would be greatly appreciated.

cbf (Wed, 26 Jul 2017 18:53:38 GMT):
@markparz it would be much easier if we could have clearer set of choices than trolling through a bunch of different presos

cbf (Wed, 26 Jul 2017 18:54:05 GMT):
further, it was not clear to me that any of the proposed logos met the criteria (because the logo per the guidelines is supposed to be square

cbf (Wed, 26 Jul 2017 18:54:21 GMT):
while all the proposed logos were duodecahedrons

markparz (Wed, 26 Jul 2017 19:27:50 GMT):

Message Attachments

markparz (Wed, 26 Jul 2017 19:27:54 GMT):
Fair enough... I don't want this to be overly complicated, so let's start here. First the wording will be the same on any logo chosen, see number 2 on the attachment. I've added the 4th option on this attachment as well. So first choose 1, 2, 3, or 4 as the icon you prefer. Then either A or B for the color palette you prefer the more subtle approach or the in your face look. @cbf in working with Greg, they are there or close to compliant, very minor tweaks that @seanbarclay said he can polish quickly. Thanks @gari and Jason for your votes on for number 2.

markparz (Wed, 26 Jul 2017 19:27:54 GMT):
Fair enough... I don't want this to be overly complicated, so let's start here. First the wording will be the same on any logo chosen, see number 2 on the attachment. I've added the 4th option (number 3) on this attachment as well. So first choose 1, 2, 3, or 4 as the icon you prefer. Then either A or B for the color palette you prefer the more subtle approach or the in your face look. @cbf in working with Greg, they are there or close to compliant, very minor tweaks that @seanbarclay said he can polish quickly. Thanks @gari and Jason for your votes on for number 2.

markparz (Wed, 26 Jul 2017 19:27:54 GMT):
Fair enough... I don't want this to be overly complicated, so let's start here. First the wording will be the same on any logo chosen, see number 2 on the attachment. I've added the 4th option (number 3) on this attachment as well. So first choose 1, 2, 3, or 4 as the icon you prefer. Then either A or B for the color palette you prefer the more subtle approach or the in your face look. @cbf in working with Greg, they are there or close to compliant, very minor tweaks that @seanbarclay said he can polish quickly. Thanks @mastersingh24 and @jyellick for your votes on for number 2.

seanbarclay (Wed, 26 Jul 2017 19:27:54 GMT):
Has joined the channel.

cbf (Wed, 26 Jul 2017 19:29:04 GMT):
ah much better and voting here probably easier to tally

markparz (Wed, 26 Jul 2017 19:29:25 GMT):
yea... good suggestion... apologies for being lazy first go round ;)

cbf (Wed, 26 Jul 2017 19:29:43 GMT):
note that #4 will be nixed, I think because the other Fabric open source project's logo is very similar

cbf (Wed, 26 Jul 2017 19:31:08 GMT):
https://www.google.com/search?q=fabric+logo+open+source&tbm=isch&imgil=vvdjykOgiNAXTM%253A%253BYI4dbO7RBGqWWM%253Bhttp%25253A%25252F%25252F9to5google.com%25252F2015%25252F05%25252F27%25252Ftwitter-kit-digits-android-open-source%25252F&source=iu&pf=m&fir=vvdjykOgiNAXTM%253A%252CYI4dbO7RBGqWWM%252C_&usg=__iFNG1SOA3ulV2jo81mnnVPT00Lw%3D&biw=1255&bih=700&ved=0ahUKEwiM-u3f16fVAhUKNSYKHZ1jDPIQyjcIMw&ei=5O14WYz4PIrqmAGdx7GQDw#imgrc=vvdjykOgiNAXTM:

cbf (Wed, 26 Jul 2017 19:31:55 GMT):
so my preference is 2 if it is conformant with the guidelines

markparz (Wed, 26 Jul 2017 19:33:30 GMT):
color palette desire?

jyellick (Wed, 26 Jul 2017 19:35:18 GMT):
My preference is 2 - with a mild preference towards color palette B, but really, I'd be more than happy to defer to a designer with a better idea of what's fashionable these days

yacovm (Wed, 26 Jul 2017 19:36:17 GMT):
Same as Jason

kostas (Wed, 26 Jul 2017 19:58:46 GMT):
Another one for 2B.

cbf (Wed, 26 Jul 2017 21:10:52 GMT):
oh yes, 2b

cbf (Wed, 26 Jul 2017 21:11:03 GMT):
I like the blue vs the black

JonathanLevi (Wed, 26 Jul 2017 21:11:27 GMT):
If you give me 24-48 hours, our designer can come up with a few options

JonathanLevi (Wed, 26 Jul 2017 21:11:41 GMT):
Unless you are bound by the list... or time? ;-)

JonathanLevi (Wed, 26 Jul 2017 21:11:41 GMT):
Unless you/we are bound by the list... or time? ;-)

cbf (Wed, 26 Jul 2017 21:11:48 GMT):
neither

JonathanLevi (Wed, 26 Jul 2017 21:12:44 GMT):
OK, so 'tentatively' I'm on 2b as well. Just in case I get kidnapped or something along these lines... ;-)

rjones (Wed, 26 Jul 2017 21:32:58 GMT):
If I had a vote, it would be for 3b, as it will look nicer on stickers, shirts, etc. The fine lines of 2 just run together.

cbf (Wed, 26 Jul 2017 21:45:48 GMT):
@rjones has a point there

rjones (Wed, 26 Jul 2017 21:46:35 GMT):
_hides former life as a screen printing hat sewing swag producer in corner_

cbf (Wed, 26 Jul 2017 21:47:15 GMT):
<-- not a graphic designer, but my son is

cbf (Wed, 26 Jul 2017 21:47:34 GMT):
of course, he is away this week

binhn (Thu, 27 Jul 2017 16:22:33 GMT):
@markparz why do we use letter "F" in the logo? ok, i know what it is, but it looks like an F

binhn (Thu, 27 Jul 2017 16:24:14 GMT):
also the shape looks like a pentagon, not a friendly place

markparz (Thu, 27 Jul 2017 17:55:42 GMT):
@binhn the idea was to take some semblance of the Hyperledger project logo, but I see what you are saying... and yes the F was trying tie fabric into the Hyperledger logo.... I see what you are saying about the shape.... hmmm

rjones (Thu, 27 Jul 2017 18:02:42 GMT):
the Hyperledger logo is already a hexagon, though

lehors (Thu, 27 Jul 2017 20:27:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=E7qno3gQwqmLZkYtm) @binhn Was that a joke? :)

jimthematrix (Fri, 28 Jul 2017 14:32:20 GMT):
I'm not sure about the "letter-in-a-hexagon" design, it barely works for Fabric and Composer, but when it comes to "Sawtooth", "Iroha", "Indy" (various samples in the middle column), it gets really weird

jimthematrix (Fri, 28 Jul 2017 14:32:20 GMT):
I'm not sure about the "letter-in-a-hexagon" design, it barely works for Fabric and Composer, but when it comes to "Sawtooth", "Iroha", "Burrow", "Indy" (various samples in the middle column), it gets really weird

jimthematrix (Fri, 28 Jul 2017 14:34:37 GMT):
for color palettes though my vote would also be B

greg.haskins (Fri, 28 Jul 2017 15:39:59 GMT):
Plus, collision with _C_haintool and _C_omposer

mastersingh24 (Fri, 28 Jul 2017 16:41:04 GMT):
Folks - please review https://gerrit.hyperledger.org/r/#/c/11769/4 - I created a single commit with the cherry picked fixes for 1.0.1 and applied them to the release branch. Part of this was an experiment to see how a process like this might work

mastersingh24 (Fri, 28 Jul 2017 16:41:04 GMT):
Folks - please review https://gerrit.hyperledger.org/r/#/c/12019/ - I created a single commit with the cherry picked fixes for 1.0.1 and applied them to the release branch. Part of this was an experiment to see how a process like this might work

rjones (Fri, 28 Jul 2017 16:45:00 GMT):
@mastersingh24 breaks `git bisect` but I suppose the risk of needing it is low. On other projects I've done a `git merge --no-ff ...`, making sure to sign each merge commit

greg.haskins (Fri, 28 Jul 2017 18:20:43 GMT):
I agree with @rjones, probably dont want to obscure bisectability if we can help it. Also note sure of the implications when using gerrit (e.g. does the Change-Id make cherry-pick/merge more complex?)

greg.haskins (Fri, 28 Jul 2017 18:20:43 GMT):
I agree with @rjones, probably dont want to obscure bisectability if we can help it. Also not sure of the implications when using gerrit (e.g. does the Change-Id make cherry-pick/merge more complex?)

rjones (Fri, 28 Jul 2017 18:23:45 GMT):
@greg.haskins let me dig one up from my old project.

rjones (Fri, 28 Jul 2017 18:24:57 GMT):
@greg.haskins this is a merge of the release branch back into master, for instance: https://git.allseenalliance.org/gerrit/#/c/9411/

rjones (Fri, 28 Jul 2017 18:25:58 GMT):
also: https://git.allseenalliance.org/gerrit/#/c/8517/ the merge of a feature branch into release

greg.haskins (Sat, 29 Jul 2017 02:48:07 GMT):
@markparz I started thinking: what if it had kind of a Periodic Table feel to it, like the Breaking Bad title

greg.haskins (Sat, 29 Jul 2017 02:49:18 GMT):

Message Attachments

markparz (Sat, 29 Jul 2017 02:50:04 GMT):
Hmmm I like it

greg.haskins (Sat, 29 Jul 2017 02:50:07 GMT):
disclaimer: I am not a graphic artist (obviously)...main idea is perhaps two letters perhaps buys us some bandwidth

greg.haskins (Sat, 29 Jul 2017 02:50:07 GMT):
disclaimer: I am not a graphic artist (obviously)...main idea is perhaps two letters buys us some bandwidth

markparz (Sat, 29 Jul 2017 02:50:45 GMT):
I think you just might be one in disguise 😀

markparz (Sat, 29 Jul 2017 02:52:06 GMT):
I want to add this to the voting board ... waiting to see if @JonathanLevi has an entry too ... thanks Greg

greg.haskins (Sat, 29 Jul 2017 02:52:23 GMT):
this was my inspiration: https://d3ui957tjb5bqd.cloudfront.net/uploads/2013/09/breaking-bad.png

kostas (Sat, 29 Jul 2017 04:27:38 GMT):
This is actually quite clever. I like it.

yacovm (Sat, 29 Jul 2017 07:06:43 GMT):
The periodic table reminds me of cyclohexane from organic chemistry, i both like and get PTSD from it

yacovm (Sat, 29 Jul 2017 07:06:43 GMT):
The periodic table icon @greg.haskins put reminds me of cyclohexane from organic chemistry, i both like and get PTSD from it

rjones (Sat, 29 Jul 2017 08:56:11 GMT):
@yacovm talk nitrates to me

cbf (Sat, 29 Jul 2017 11:00:59 GMT):
@greg.haskins I like it!

dave.enyeart (Sat, 29 Jul 2017 12:20:29 GMT):
I do like Greg's better than the 'crooked F'!

greg.haskins (Sat, 29 Jul 2017 13:08:33 GMT):
We could call them the "Elements of Hyperledger" or something like that

muralisr (Sat, 29 Jul 2017 15:03:45 GMT):
Love it!

muralisr (Sat, 29 Jul 2017 15:05:04 GMT):
and Hyperledger itslef would be "H" ... the core, simplest element :-)

muralisr (Sat, 29 Jul 2017 15:05:04 GMT):
and Hyperledger itslef would be "H" ... hydrogen the basic element :-)

muralisr (Sat, 29 Jul 2017 15:05:04 GMT):
and Hyperledger itslef would be "H" ... hydrogen one of the first elements of big bang :-)

JonathanLevi (Sat, 29 Jul 2017 19:52:45 GMT):
+1

JonathanLevi (Sat, 29 Jul 2017 19:52:46 GMT):
https://az616578.vo.msecnd.net/files/2016/01/09/635879268869090481737665867_breaking%20bad%20gif.gif

jimthematrix (Mon, 31 Jul 2017 03:16:37 GMT):
folks, please vote for https://jira.hyperledger.org/browse/FAB-2331 (node.js chaincode support), the vote is for getting the project officially started so I can ask @rjones to create a repository (fabric-shim-node) and a RC channel (fabric-node-chaincode). the background was in the email I sent to hyperledger-fabric mailing list on 7/27.

grapebaba (Mon, 31 Jul 2017 07:50:40 GMT):
First commit for metrics, please review https://gerrit.hyperledger.org/r/#/c/11933/

yacovm (Mon, 31 Jul 2017 07:51:03 GMT):
@grapebaba - this belongs to #fabric-pr-review ;)

grapebaba (Mon, 31 Jul 2017 07:51:33 GMT):
aha

paapighoda (Mon, 31 Jul 2017 09:13:03 GMT):
Has left the channel.

muralisr (Mon, 31 Jul 2017 12:11:31 GMT):
@jimthematrix added https://jira.hyperledger.org/browse/FAB-5424 as a dependency for FAB-2331

cbf (Mon, 31 Jul 2017 15:13:07 GMT):
@here https://chat.hyperledger.org/channel/fabric-maintainers?msg=mxCtD5PfotLsg2F4o so, just for Fabric, because apparently Brian wants each project to choose its own logo, are we good with Greg's proposal (the Fa)

cbf (Mon, 31 Jul 2017 15:13:09 GMT):
?

cbf (Mon, 31 Jul 2017 15:13:35 GMT):
can I get the maintainers to weigh in in response with a +1 or -1 etc

JonathanLevi (Mon, 31 Jul 2017 15:54:52 GMT):
Greg, can you share with me the PSD or so?

JonathanLevi (Mon, 31 Jul 2017 15:55:10 GMT):
I would like to make it a bit more symmetric, etc.

JonathanLevi (Mon, 31 Jul 2017 15:55:37 GMT):
Or, shall we agree on this, and then finalize?

JonathanLevi (Mon, 31 Jul 2017 15:55:47 GMT):
+1 for the current design (from me)

jyellick (Mon, 31 Jul 2017 15:55:58 GMT):
I'd feel better if we could get a designer to mock a more polished version together

JonathanLevi (Mon, 31 Jul 2017 15:56:16 GMT):
Yes, that's what I meant. I agree conceptually.

jyellick (Mon, 31 Jul 2017 15:56:24 GMT):
(In particular, to make sure that we have a designer who is interested in adopting and nurturing this design concept)

greg.haskins (Mon, 31 Jul 2017 15:56:32 GMT):
@JonathanLevi would be happy to share full source, but I did it in omnigraffle

greg.haskins (Mon, 31 Jul 2017 15:56:56 GMT):
@jyellick fully agree someone skilled in the graphic arts should produce the final form

greg.haskins (Mon, 31 Jul 2017 15:57:14 GMT):
mine was a concept mock up, at best

greg.haskins (Mon, 31 Jul 2017 15:57:20 GMT):
the alignments, etc, are off

JonathanLevi (Mon, 31 Jul 2017 15:58:01 GMT):
Yes, that would be great. Also we should try to get some advice regarding the color-scheme.

greg.haskins (Mon, 31 Jul 2017 15:58:46 GMT):
https://www.dropbox.com/s/r5aggoljf6aybow/icons.graffle?dl=0

greg.haskins (Mon, 31 Jul 2017 15:58:57 GMT):
thats the original that I produced the PNG from

jyellick (Mon, 31 Jul 2017 15:59:09 GMT):
Understood @greg.haskins, I did not think it was intended to be a final form, but since we had multiple designers from multiple parent orgs, would like to make sure we have cohesive direction around the branding.

greg.haskins (Mon, 31 Jul 2017 15:59:24 GMT):
@jyellick yep, fully agree

greg.haskins (Mon, 31 Jul 2017 16:02:05 GMT):
for completeness, here is a link to the original PNG that I posted: https://www.dropbox.com/s/zafj4tfbllc91nn/hyperledger-logos.png?dl=0

cbf (Mon, 31 Jul 2017 16:28:15 GMT):
@JonathanLevi @jyellick Hyperledger Marketing will help with the polish, we just need to decide the design

JonathanLevi (Mon, 31 Jul 2017 16:29:21 GMT):
+1 on Greg's design

muralisr (Mon, 31 Jul 2017 16:39:52 GMT):
+1 ^^

muralisr (Mon, 31 Jul 2017 16:40:30 GMT):
(conceptually pending any final polish from designers etc)

jyellick (Mon, 31 Jul 2017 16:43:03 GMT):
Not sure how actively anyone is checking the review-needed tag, would appreciate comments/votes on this one https://jira.hyperledger.org/browse/FAB-5504

yacovm (Mon, 31 Jul 2017 16:46:24 GMT):
I voted :)

yacovm (Mon, 31 Jul 2017 16:46:51 GMT):
I will comment my comment from the gerrit item

yacovm (Mon, 31 Jul 2017 16:46:51 GMT):
I will copy my comment from the gerrit item

markparz (Mon, 31 Jul 2017 18:11:12 GMT):

Message Attachments

markparz (Mon, 31 Jul 2017 18:11:14 GMT):
@mastersingh24 @binhn @jimthematrix you guys good with Greg's proposal as well for the fabric logo.. you can thumbs up / down on this image

markparz (Mon, 31 Jul 2017 18:11:14 GMT):
@mastersingh24 @binhn @jimthematrix @yacovm you guys good with Greg's proposal as well for the fabric logo.. you can thumbs up / down on this image

jyellick (Mon, 31 Jul 2017 18:40:22 GMT):
Not interested in any sort of veto, but I am not sold on that design. In general, I like the idea of iconography over text, and I'm having trouble envisioning a polished version. Are we interested in adopting a different logo for each of the assorted "fabric-*" projects? I'm not particularly sure why we want a different badge for say fabric-ca than fabric. And, if the branding is restricted only to fabric (and not hyperledger more broadly), i'm not sure what the periodic table style really buys us... But, as I said, it's not like this decision needs to be unanimous, and at the end of the day I'm happy to defer to those with a better artistic eye than myself.

cbf (Mon, 31 Jul 2017 18:48:08 GMT):
@jyellick I think it would only be for top-level (e.g. fabric) and hence there is one logo

cbf (Mon, 31 Jul 2017 18:48:23 GMT):
sawtooth, burrow COULD opt in, or design their own

cbf (Mon, 31 Jul 2017 18:48:42 GMT):
apparently there is not interest in trying to force a single design on all project

cbf (Mon, 31 Jul 2017 18:48:59 GMT):
we may "adopt" projects that already have a logo and we need to respect that

cbf (Mon, 31 Jul 2017 18:49:37 GMT):
so I would not expect a fabric-ca logo

jyellick (Mon, 31 Jul 2017 18:51:19 GMT):
Right, that was my understanding. So I'm not really sure of the benefit of going with "Fa" over something like the iconography in the originally proposed designs. The text was elegant to represent multiple related projects with a similar theme, but since that is out, I do not see the benefit. (Again, not trying to cause waves her, was content to sit this one out, just responding to the explicit calling out by @markparz )

jyellick (Mon, 31 Jul 2017 18:51:19 GMT):
Right, that was my understanding. So I'm not really sure of the improvement of going with "Fa" over something like the iconography in the originally proposed designs. The text was elegant to represent multiple related projects with a similar theme, but since that is out, I do not see thebenefit. (Again, not trying to cause waves here, was content to sit this one out, just responding to the explicit calling out by @markparz )

jyellick (Mon, 31 Jul 2017 18:51:19 GMT):
Right, that was my understanding. So I'm not really sure of the improvement of going with "Fa" over something like the iconography in the originally proposed designs. The text was elegant to represent multiple related projects with a similar theme, but since that is out, I do not see the benefit. (Again, not trying to cause waves here, was content to sit this one out, just responding to the explicit calling out by @markparz )

markparz (Mon, 31 Jul 2017 19:07:20 GMT):
Right, just the higher level projects... not planning on doing a break down

markparz (Mon, 31 Jul 2017 19:08:59 GMT):
That's me... calling ya out... lol... just want to get a majority rule.... absolutely can stay with the previous vote @jyellick

jyellick (Mon, 31 Jul 2017 19:13:51 GMT):
> Right, just the higher level projects... not planning on doing a break down But this is only the fabric logo. We cannot (and would not want to) force this style onto the other hyperledger projects. > That's me... calling ya out... lol... just want to get a majority rule.... Yes, calling out is a little bit of a strong phrasing, just didn't want you to think I was ignoring the call for response

jyellick (Mon, 31 Jul 2017 19:13:51 GMT):
> Right, just the higher level projects... not planning on doing a break down But this is only the fabric logo. We cannot (and would not want to) force this style onto the other hyperledger projects. So there's no plural to the "projects". > That's me... calling ya out... lol... just want to get a majority rule.... Yes, calling out is a little bit of a strong phrasing, just didn't want you to think I was ignoring the call for response

mastersingh24 (Mon, 31 Jul 2017 19:53:46 GMT):
@markparz - what's the original JIRA with the previous logos you shared?

markparz (Mon, 31 Jul 2017 19:55:09 GMT):
https://jira.hyperledger.org/browse/FAB-2185?jql=text%20~%20%22logo%22

mastersingh24 (Mon, 31 Jul 2017 19:55:44 GMT):
Thx. I decided not to be lazy and found it

mastersingh24 (Mon, 31 Jul 2017 19:56:35 GMT):
I still stick with my vote in that JIRA ;0

mastersingh24 (Mon, 31 Jul 2017 19:56:35 GMT):
I still stick with my vote in that JIRA ;)

mastersingh24 (Mon, 31 Jul 2017 19:56:35 GMT):
I still stick with my vote in that JIRA - Hyperledger_branding ideas_v2.pdf ;)

mastersingh24 (Mon, 31 Jul 2017 19:58:34 GMT):
I like the icons myself. But again, if there are people who care more deeply about this than me and really want something else, I'm not going to stand in the way / argue

kostas (Mon, 31 Jul 2017 20:21:02 GMT):
Can I suggest we all cast our votes on JIRA? https://jira.hyperledger.org/browse/FAB-2185

kostas (Mon, 31 Jul 2017 20:21:08 GMT):
Votes are either 1 to 4 (A or B) or "Greg's idea"

kostas (Mon, 31 Jul 2017 20:21:08 GMT):
Votes are either 1 to 4 (A or B ) or "Greg's idea"

kostas (Mon, 31 Jul 2017 20:22:24 GMT):
(I've lost track of who's supporting what here.)

yacovm (Mon, 31 Jul 2017 20:23:53 GMT):
how do you vote Kostas?

jyellick (Mon, 31 Jul 2017 20:25:34 GMT):
Maybe we can create sub-tasks for the logo, one for each (1-4), and use the JIRA vote button?

jyellick (Mon, 31 Jul 2017 20:25:34 GMT):
Maybe we can create sub-tasks for the logo, one for each (1-4 + Gerg's), and use the JIRA vote button?

jyellick (Mon, 31 Jul 2017 20:25:34 GMT):
Maybe we can create sub-tasks for the logo, one for each (1-4 + Greg's), and use the JIRA vote button?e

jyellick (Mon, 31 Jul 2017 20:25:34 GMT):
Maybe we can create sub-tasks for the logo, one for each (1-4 + Greg's), and use the JIRA vote button?

kostas (Mon, 31 Jul 2017 20:27:35 GMT):
@yacovm: I'll post in the JIRA now. (To answer your question: since we're not necessarily going to use Greg's template for all projects, I think Ill stick with the original vote for 2B.)

yacovm (Mon, 31 Jul 2017 20:27:45 GMT):
same

mastersingh24 (Mon, 31 Jul 2017 20:46:36 GMT):
Can someone spin up a quick Fabric network for voting?

jimthematrix (Mon, 31 Jul 2017 23:24:49 GMT):
voted in FAB-2185, 2B for me too based on the understanding that these are from our design team (so they have been vetted for artistic quality)

yuleeandrea (Mon, 31 Jul 2017 23:41:01 GMT):
Has joined the channel.

greg.haskins (Tue, 01 Aug 2017 02:11:09 GMT):
My primary concern wasnt artistic in nature, but rather the impending collision of _C_omposer, _C_ello and _C_ haintool with the singular letter proposal

greg.haskins (Tue, 01 Aug 2017 02:11:48 GMT):
as long as that is addressed, I defer to the artists

jimthematrix (Tue, 01 Aug 2017 02:33:44 GMT):
same thought process for me

cbf (Tue, 01 Aug 2017 16:03:15 GMT):
my preference is 3b because of @rjones's feedback that #2 would not render well on stickers etc

greg.haskins (Tue, 01 Aug 2017 18:07:02 GMT):
Its primarily a case of TL:DR, but I am not clear what you guys are referring to when you say "2B", etc

greg.haskins (Tue, 01 Aug 2017 18:07:16 GMT):
is this all w.r.t. the logos.jpg?

greg.haskins (Tue, 01 Aug 2017 18:07:26 GMT):
or are there different documents for each group?

JonathanLevi (Tue, 01 Aug 2017 18:23:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=acRXYGfChfcRp66tN)

JonathanLevi (Tue, 01 Aug 2017 18:23:39 GMT):
@greg.haskins 2B means *row 2* - *column *B*

JonathanLevi (Tue, 01 Aug 2017 18:23:39 GMT):
@greg.haskins Yes, by 2B they mean *row 2* - *column B*

greg.haskins (Tue, 01 Aug 2017 18:24:44 GMT):
ok, got it

JonathanLevi (Tue, 01 Aug 2017 18:24:50 GMT):
It's a secret protocol that these guys came up with... ;-)

greg.haskins (Tue, 01 Aug 2017 18:24:53 GMT):
i wasnt sure if it was something in all the other attachments

greg.haskins (Tue, 01 Aug 2017 18:25:05 GMT):
I am still concerned about the "C" collisions though

JonathanLevi (Tue, 01 Aug 2017 18:25:12 GMT):
This way we can vote, they change the image... and BOOM, we get the wrong logo for life!

JonathanLevi (Tue, 01 Aug 2017 18:25:20 GMT):
[amiably/joking]

greg.haskins (Tue, 01 Aug 2017 18:25:25 GMT):
Also, the F looks "weepy"

greg.haskins (Tue, 01 Aug 2017 18:25:34 GMT):
I do like how the cubes go together though

greg.haskins (Tue, 01 Aug 2017 18:26:01 GMT):
When I see that "F", all I can think of is that "waa waa" sound

greg.haskins (Tue, 01 Aug 2017 18:26:02 GMT):
heh

JonathanLevi (Tue, 01 Aug 2017 18:26:04 GMT):
Alright, alright, now that we are spilling the beans... (and the bitcoin fork is not that bad actually)

JonathanLevi (Tue, 01 Aug 2017 18:26:25 GMT):
I am not an expert, but I don't like that the F is bent/broken

JonathanLevi (Tue, 01 Aug 2017 18:26:38 GMT):
We should be "proud" of the F... if you see what I mean?

greg.haskins (Tue, 01 Aug 2017 18:26:41 GMT):
yeah, it looks sad

JonathanLevi (Tue, 01 Aug 2017 18:27:02 GMT):
The F should be as happy as the maintainers.

JonathanLevi (Tue, 01 Aug 2017 18:27:09 GMT):
Or at least as... ;-)

JonathanLevi (Tue, 01 Aug 2017 18:30:06 GMT):
--- Speaking of happiness, is any maintainer aware of any issue that should prevent Gari from finalizing the 1.0.1 release?

JonathanLevi (Tue, 01 Aug 2017 18:30:17 GMT):
Any show-stoppers that were/are not addressed?

greg.haskins (Tue, 01 Aug 2017 18:44:37 GMT):
Yeah, make sure the v1.0.1 release is followed by a v1.0.2-SNAPSHOT CR or it will could hose the tree ;)

greg.haskins (Tue, 01 Aug 2017 18:44:37 GMT):
Yeah, make sure the v1.0.1 release is followed by a v1.0.2-SNAPSHOT CR or it could hose the tree ;)

greg.haskins (Tue, 01 Aug 2017 18:44:47 GMT):
I already made a note of that in his CR though

JonathanLevi (Tue, 01 Aug 2017 19:06:22 GMT):
I have just merged https://gerrit.hyperledger.org/r/#/c/12045/

JonathanLevi (Tue, 01 Aug 2017 19:06:29 GMT):
*CODE FREEZE - BEGIN*

yacovm (Tue, 01 Aug 2017 19:50:05 GMT):
why are we having a code freeze?

yacovm (Tue, 01 Aug 2017 19:50:17 GMT):
@cbf I recall you saying no code freeze

yacovm (Tue, 01 Aug 2017 19:50:17 GMT):
@cbf:

yacovm (Tue, 01 Aug 2017 19:52:16 GMT):
https://chat.hyperledger.org/channel/fabric-scrum?msg=pWLchDfyKznGexYrB

yacovm (Tue, 01 Aug 2017 20:24:09 GMT):
and when is it over? @JonathanLevi

JonathanLevi (Tue, 01 Aug 2017 20:24:51 GMT):
We declared it because of this:

JonathanLevi (Tue, 01 Aug 2017 20:25:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=vP3eHuubyHZG6uc5m)

JonathanLevi (Tue, 01 Aug 2017 20:25:34 GMT):
Gari will make the release off the *release* branch anyway. I'm just being extra prudent.

yacovm (Tue, 01 Aug 2017 20:25:43 GMT):
I see

JonathanLevi (Tue, 01 Aug 2017 20:26:07 GMT):
Why? Is there anything pressing that has to get merged into master this very moment?

yacovm (Tue, 01 Aug 2017 20:26:31 GMT):
not that I know of

JonathanLevi (Tue, 01 Aug 2017 20:26:41 GMT):
OK, cool. Just asking.

JonathanLevi (Tue, 01 Aug 2017 20:26:47 GMT):
Thank you Yacov.

yacovm (Tue, 01 Aug 2017 20:26:55 GMT):
Same

cbf (Tue, 01 Aug 2017 20:39:12 GMT):
@JonathanLevi I don't think we need a code freeze, only a select few can merge to release branch

cbf (Tue, 01 Aug 2017 20:39:54 GMT):
and all CRs are supposed to be submitted to master

JonathanLevi (Tue, 01 Aug 2017 20:40:05 GMT):
That's true. I wanted to simplify, but fair enough, let's release it then.

JonathanLevi (Wed, 02 Aug 2017 00:07:52 GMT):
*CODE FREEZE - END*

adc (Wed, 02 Aug 2017 01:06:56 GMT):
Hi All, please some love to https://gerrit.hyperledger.org/r/#/c/11929/

greg.haskins (Wed, 02 Aug 2017 02:14:21 GMT):
who is the resident expert on the couchdb support?

jyellick (Wed, 02 Aug 2017 03:11:12 GMT):
Guessing that is either @dave.enyeart or @manish-sethi ?

matanyahu (Wed, 02 Aug 2017 07:29:40 GMT):
I like logo no. 2. if it only could change its colour to something different than black to avoid contrasts

dave.enyeart (Wed, 02 Aug 2017 10:28:58 GMT):
@greg.haskins I can take your couchdb questions

cbf (Wed, 02 Aug 2017 11:49:26 GMT):
@here @jwagantall has kindly added an integration with JIRA to RC so now when we reference a JIRA item, it will post a snippet

cbf (Wed, 02 Aug 2017 11:50:13 GMT):
e.g. FAB-4539

greg.haskins (Wed, 02 Aug 2017 11:52:43 GMT):
@dave.enyeart I figured it out, but thank you

jyellick (Wed, 02 Aug 2017 12:55:02 GMT):
Thanks to @yacovm and @kostas for responding to FAB-5504 , but need more maintainers to weigh in (either positively or negatively) so that we can make a decision.

CarlXK (Wed, 02 Aug 2017 13:58:12 GMT):
Has joined the channel.

cbf (Wed, 02 Aug 2017 20:53:29 GMT):
for those of you helping with stackoverflow questions, https://stackoverflow.com/questions/45232825/error-cannot-find-module-fabric-client could use some up-voting... I'll update the docs, but this seems to be a common pitfall for Windows developers

dsanchezseco (Thu, 03 Aug 2017 07:58:54 GMT):
Has joined the channel.

dsanchezseco (Thu, 03 Aug 2017 08:01:47 GMT):
Hi! i've filled this issue on jira(https://jira.hyperledger.org/browse/FAB-5576) and i've already have the code done on local. I want to submited but i have quite an amount of doubts about how to do it correctly. If someone would be kind to help...

lehors (Thu, 03 Aug 2017 08:38:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=iSuT8JcaG7AdiCcjo) @cbf I've already updated the doc for that one so this shouldn't be a problem any more. Now, maybe what's needed is for people to get a brain patch to RTFM ;-)

mastersingh24 (Thu, 03 Aug 2017 09:26:35 GMT):
[Moved to #fabric-dev-env ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=tcs6cmc3ygwzphahu) @dsanchezseco

kostas (Thu, 03 Aug 2017 15:28:55 GMT):
Someone refresh my memory on this: do we submit as "fix-version: 1.1" and let the release manager adjust to 1.0.2 in JIRA when they're doing the cherry-picking, or is it the opposite (i.e. we go for 1.0.2 in JIRA using our judgement, and if the release manager deems that it's not 1.02-applicable, they modify to 1.1)?

mastersingh24 (Thu, 03 Aug 2017 17:02:54 GMT):
Go with 1.0.2

cbf (Thu, 03 Aug 2017 18:47:33 GMT):
for bugs... for feature work, I would think 1.1 @mastersingh24 @JonathanLevi yes?

JonathanLevi (Thu, 03 Aug 2017 18:59:32 GMT):
Yes, that was/would be my vote too. Kostas, is it a relatively small and self-contained bug fix?

JonathanLevi (Thu, 03 Aug 2017 19:00:34 GMT):
"Self-contained", in the sense of, easy to get it merged within a build cycle, etc... not breaking stuff, etc.

kostas (Thu, 03 Aug 2017 19:01:12 GMT):
Bugs and minor improvements is what I had in mind. I can definitely keep it to bugs only, cause "minor" when it comes to improvements is subjective.

kostas (Thu, 03 Aug 2017 19:01:12 GMT):
Bugs and self-contained minor improvements is what I had in mind. I can definitely keep it to bugs only, cause "minor" when it comes to improvements is subjective.

JonathanLevi (Thu, 03 Aug 2017 19:04:46 GMT):
We can also (all of us) consider some minor improvements... I believe. We'll vote over some, but I don't see why not. If people need some of these in 2 weeks or so... I'd be down to vote some of them in. Again, within reason, under consensus, etc.

dave.enyeart (Fri, 04 Aug 2017 13:56:48 GMT):
Please review/vote for FAB-3621 (ACL); FAB-4207 (auth handler); FAB-1151 (side db private data)

eacoeytaux (Fri, 04 Aug 2017 19:54:22 GMT):
Has joined the channel.

greg.haskins (Fri, 04 Aug 2017 22:19:42 GMT):
anyone familiar with this

greg.haskins (Fri, 04 Aug 2017 22:19:47 GMT):
```peer channel create -o orderer:7050 -c mychannel -f /tmp/tmp.Jv90PxXmzj/anchor.tx --tls --cafile /etc/hyperledger/fabric/cryptogen/ordererOrganizations/orderer.net/tlsca/tlsca.orderer.net-cert.pem Error: Got unexpected status: BAD_REQUEST Usage: peer channel create [flags] Flags: -c, --channelID string In case of a newChain command, the channel ID to create. -f, --file string Configuration transaction file generated by a tool such as configtxgen for submitting to orderer -t, --timeout int Channel creation timeout (default 5) Global Flags: --cafile string Path to file containing PEM-encoded trusted certificate(s) for the ordering endpoint --logging-level string Default logging level and overrides, see core.yaml for full syntax -o, --orderer string Ordering service endpoint --ordererTLSHostnameOverride string The hostname override to use when validating the TLS connection to the orderer. --test.coverprofile string Done (default "coverage.cov") --tls Use TLS when communicating with the orderer endpoint -v, --version Display current version of fabric peer server ```

jyellick (Fri, 04 Aug 2017 22:20:08 GMT):
@greg.haskins I can probably help you

jyellick (Fri, 04 Aug 2017 22:20:27 GMT):
Take a look at the tail of your orderer logs, you will see a reason

greg.haskins (Fri, 04 Aug 2017 22:20:42 GMT):
cool...wife is calling but I will check that when I return

jyellick (Fri, 04 Aug 2017 22:20:43 GMT):
If I had to wildly speculate, it would be that your `configtxgen` binary is `v1.0.0` and your orderer is newer

greg.haskins (Fri, 04 Aug 2017 22:20:45 GMT):
thanks!

greg.haskins (Fri, 04 Aug 2017 22:29:15 GMT):
@jyellick back...

greg.haskins (Fri, 04 Aug 2017 22:29:22 GMT):
i just looked, not sure what to look for

greg.haskins (Fri, 04 Aug 2017 22:29:49 GMT):
but I can say, it seems unlikely to be mismatched: I am running configtxgen from the fabric-tools container which was built coincident to the orderer

jyellick (Fri, 04 Aug 2017 22:30:02 GMT):
Take this to DM so we don't pollute this channel? Or I don't mind doing it here

greg.haskins (Fri, 04 Aug 2017 22:30:11 GMT):
sure (sorry all)

Senthil1 (Sun, 06 Aug 2017 03:47:54 GMT):
Has joined the channel.

dileban (Mon, 07 Aug 2017 05:41:12 GMT):
Has joined the channel.

C0rWin (Mon, 07 Aug 2017 15:10:58 GMT):
FAB-5225, needs some maintainers attention tagged as review needed (also has CR in place https://gerrit.hyperledger.org/r/#/c/11537/). Basically it takes care to expose network information via QSCC, e.g. for given channel to ask who are the visible members of that channel.

C0rWin (Mon, 07 Aug 2017 15:10:58 GMT):
https://jira.hyperledger.org/browse/FAB-5225, needs some maintainers attention tagged as review needed (also has CR in place https://gerrit.hyperledger.org/r/#/c/11537/). Basically it takes care to expose network information via QSCC, e.g. for given channel to ask who are the visible members of that channel.

dave.enyeart (Mon, 07 Aug 2017 15:39:30 GMT):
@C0rWin I previously assumed that QSCC would be for only making ledger data available. I thought other types of peer info such as gossip info would be made available via gRPC APIs. What do others think?

C0rWin (Mon, 07 Aug 2017 15:43:08 GMT):
QSCC has all ACL and policies checks in place also QSCC could be leveraged to query for peer info not only ledger

JonathanLevi (Mon, 07 Aug 2017 16:28:14 GMT):
Good morning.

JonathanLevi (Mon, 07 Aug 2017 16:28:17 GMT):
Re: "expose channel leader in org and channel members using system chain code to outside world"

JonathanLevi (Mon, 07 Aug 2017 16:29:05 GMT):
Do we want to have a list of "channel members" available to the outside world?

JonathanLevi (Mon, 07 Aug 2017 16:29:37 GMT):
@C0rWin

JonathanLevi (Mon, 07 Aug 2017 16:30:36 GMT):
Also, in the proposal, how do you want to define who is a "visible" user?

C0rWin (Mon, 07 Aug 2017 16:30:40 GMT):
It's not confidential, you exposed this information in config already

JonathanLevi (Mon, 07 Aug 2017 16:31:10 GMT):
Do we also have users/members that are not "visible" ?

C0rWin (Mon, 07 Aug 2017 16:31:27 GMT):
Yes we have

C0rWin (Mon, 07 Aug 2017 16:31:57 GMT):
And we use channel policies to filter them out if client coming from foreign org

JonathanLevi (Mon, 07 Aug 2017 16:33:09 GMT):
Foreign org, being one that does not have any member in that particular channel?

JonathanLevi (Mon, 07 Aug 2017 16:33:28 GMT):
Or does not have an "admin", as it's currently called.

C0rWin (Mon, 07 Aug 2017 16:33:29 GMT):
In particular, yes

JonathanLevi (Mon, 07 Aug 2017 16:33:56 GMT):
So ChrisF and Jonathan share a channel. Neither of us is "visible"

JonathanLevi (Mon, 07 Aug 2017 16:34:07 GMT):
Another IBMer comes in, sees Chris and not Jonathan?

C0rWin (Mon, 07 Aug 2017 16:34:18 GMT):
No-no

JonathanLevi (Mon, 07 Aug 2017 16:34:25 GMT):
Another HACERA person comes in, sees Jonathan and not Chris?

C0rWin (Mon, 07 Aug 2017 16:34:43 GMT):
Suppose you share a channel

C0rWin (Mon, 07 Aug 2017 16:34:52 GMT):
Are you in same org?

JonathanLevi (Mon, 07 Aug 2017 16:35:14 GMT):
Nope

C0rWin (Mon, 07 Aug 2017 16:35:22 GMT):
Ok

JonathanLevi (Mon, 07 Aug 2017 16:35:24 GMT):
ChirsF IBM, Jonathan HACERA. 2 orgs

JonathanLevi (Mon, 07 Aug 2017 16:35:29 GMT):
The "CJ channel"

C0rWin (Mon, 07 Aug 2017 16:35:50 GMT):
Do you have peer in your org visible to Chris's org?

C0rWin (Mon, 07 Aug 2017 16:36:04 GMT):
Say anchor peer?

JonathanLevi (Mon, 07 Aug 2017 16:36:26 GMT):
Say I have HACERA/webadmin, not on that channel.

C0rWin (Mon, 07 Aug 2017 16:37:02 GMT):
So it he comes to your peer, e.g. Same org

C0rWin (Mon, 07 Aug 2017 16:37:15 GMT):
He will see only peers from your org

C0rWin (Mon, 07 Aug 2017 16:37:32 GMT):
While if he will come to Chris org

C0rWin (Mon, 07 Aug 2017 16:37:39 GMT):
He will see nothing

JonathanLevi (Mon, 07 Aug 2017 16:37:46 GMT):
HACERA/webadmin queries "CJ channel" and sees HACERA/jonathan ?

C0rWin (Mon, 07 Aug 2017 16:38:10 GMT):
Unless Chris has peer in the channel with external endpoint, externally accessible

JonathanLevi (Mon, 07 Aug 2017 16:38:32 GMT):
Not good, IMHO ;-)

JonathanLevi (Mon, 07 Aug 2017 16:38:52 GMT):
Assume Chris belongs to a company that has over 300K employees.

JonathanLevi (Mon, 07 Aug 2017 16:39:16 GMT):
We work out/set up a "private channel".

JonathanLevi (Mon, 07 Aug 2017 16:39:37 GMT):
One of the other peers in his org, changes something. Boom, he is exposed.

JonathanLevi (Mon, 07 Aug 2017 16:39:40 GMT):
---

JonathanLevi (Mon, 07 Aug 2017 16:40:04 GMT):
Did I get the scenario right? Or does it not make sense/I don't get it.

C0rWin (Mon, 07 Aug 2017 16:40:47 GMT):
I am not following

C0rWin (Mon, 07 Aug 2017 16:41:19 GMT):
Of you have a private channel with Chris, which has 300k employees

C0rWin (Mon, 07 Aug 2017 16:41:48 GMT):
And your private channel defined for both of your orgs

JonathanLevi (Mon, 07 Aug 2017 16:42:02 GMT):
Of you have a private channel with Chris. Chris belongs to an Org that has over 300,000 employees/peers

JonathanLevi (Mon, 07 Aug 2017 16:42:02 GMT):
I have a private channel with Chris. Chris belongs to an Org that has over 300,000 employees/peers

C0rWin (Mon, 07 Aug 2017 16:42:21 GMT):
Any peer with signed certificate from either of your orgs could do whatever he wants

JonathanLevi (Mon, 07 Aug 2017 16:42:27 GMT):
The "CJ channel", yes.

JonathanLevi (Mon, 07 Aug 2017 16:42:49 GMT):
Got you.

C0rWin (Mon, 07 Aug 2017 16:43:08 GMT):
This is how it works right now

C0rWin (Mon, 07 Aug 2017 16:43:37 GMT):
No difference made with this respect. In context of proposed change

C0rWin (Mon, 07 Aug 2017 16:49:40 GMT):
Change only suggests to provide an ability to query peer for members which actively was joined to the channel and alive. Of course client has to have be valid, e.g. with valid certificates of one of the channel orgs.

C0rWin (Mon, 07 Aug 2017 16:50:25 GMT):
Currently unless you are doing deep dive into logs no way to detect membership view

JonathanLevi (Mon, 07 Aug 2017 16:50:59 GMT):
"Of course client has to have be valid, e.g. with valid certificates of one of the channel orgs." yes, of course.

JonathanLevi (Mon, 07 Aug 2017 16:51:24 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=2Fjxcup7T6KZ32xyb) Yes, I hear you. Thanks for clarifying.

muralisr (Mon, 07 Aug 2017 18:59:44 GMT):
https://jira.hyperledger.org/browse/FAB-3621 is waiting with bated breath for some votes please :-)

bstasyszyn (Thu, 10 Aug 2017 12:17:42 GMT):
Has joined the channel.

yacovm (Thu, 10 Aug 2017 13:38:32 GMT):
Hi, can maintainers please vote on https://jira.hyperledger.org/browse/FAB-5451 ?

yacovm (Thu, 10 Aug 2017 13:53:24 GMT):
@jimthematrix ^

jimthematrix (Thu, 10 Aug 2017 14:05:09 GMT):
just voted

yacovm (Thu, 10 Aug 2017 14:09:38 GMT):
tnx

marryton007 (Fri, 11 Aug 2017 13:02:01 GMT):
Has joined the channel.

marryton007 (Fri, 11 Aug 2017 13:07:19 GMT):
The master branch of 'fabric-samples' can't start the 'first-network', the error file and patch file uploads

jyellick (Fri, 11 Aug 2017 13:08:53 GMT):
@marryton007 This is not he appropriate channel for this question. Please try #fabric-questions

jyellick (Fri, 11 Aug 2017 13:08:53 GMT):
@marryton007 This is not the appropriate channel for this question. Please try #fabric-questions

marryton007 (Fri, 11 Aug 2017 13:09:10 GMT):
ok, thanks.

aleksandar.likic (Fri, 11 Aug 2017 15:02:10 GMT):
Has joined the channel.

rjones (Fri, 11 Aug 2017 20:54:43 GMT):
I ask your forbearance, this channel will experience a small amount of turbulence for the next few minutes.

rjones (Fri, 11 Aug 2017 20:55:46 GMT):
binhn

rjones (Fri, 11 Aug 2017 20:56:22 GMT):
C0rWin

rjones (Fri, 11 Aug 2017 20:56:57 GMT):
dave.enyeart

rjones (Fri, 11 Aug 2017 20:57:12 GMT):
greg.haskins

rjones (Fri, 11 Aug 2017 20:57:13 GMT):
greg.haskins

rjones (Fri, 11 Aug 2017 20:57:43 GMT):
hgabre

rjones (Fri, 11 Aug 2017 20:57:56 GMT):
JonathanLevi

rjones (Fri, 11 Aug 2017 20:57:58 GMT):
JonathanLevi

rjones (Fri, 11 Aug 2017 20:58:14 GMT):
jiangyaoguo

rjones (Fri, 11 Aug 2017 20:58:32 GMT):
jimthematrix

rjones (Fri, 11 Aug 2017 20:58:39 GMT):
jyellick

rjones (Fri, 11 Aug 2017 20:58:52 GMT):
kostas

rjones (Fri, 11 Aug 2017 20:59:04 GMT):
manish-sethi

rjones (Fri, 11 Aug 2017 20:59:12 GMT):
mastersingh24

rjones (Fri, 11 Aug 2017 20:59:25 GMT):
muralisr

rjones (Fri, 11 Aug 2017 20:59:42 GMT):
sheehan

rjones (Fri, 11 Aug 2017 20:59:49 GMT):
smithbk

rjones (Fri, 11 Aug 2017 21:00:00 GMT):
TamasBlummer

rjones (Fri, 11 Aug 2017 21:00:11 GMT):
yacovm

rjones (Fri, 11 Aug 2017 21:04:01 GMT):
The only people that can speak in this channel are members of the LDAP group `hyperledger-gerrit-fabric-committers` . You all have superpowers now for this channel - please be careful.

rjones (Fri, 11 Aug 2017 21:04:01 GMT):
The only people that can speak in this channel are members of the LDAP group hyperledger-gerrit-fabric-committers . You all have superpowers now for this channel - please be careful.

rjones (Fri, 11 Aug 2017 21:04:56 GMT):
If someone needs the ability to speak, but they cannot speak in this channel, any of the channel owners may choose to upgrade that person - or a channel owner can get in touch with me directly

rjones (Fri, 11 Aug 2017 21:07:12 GMT):
jyellick

rjones (Fri, 11 Aug 2017 21:07:22 GMT):
JonathanLevi

rjones (Fri, 11 Aug 2017 21:08:39 GMT):
cbf

rjones (Fri, 11 Aug 2017 21:08:45 GMT):
mastersingh24

rjones (Fri, 11 Aug 2017 21:08:53 GMT):
binhn

rjones (Fri, 11 Aug 2017 21:09:04 GMT):
jimthematrix

rjones (Fri, 11 Aug 2017 21:09:21 GMT):
C0rWin

rjones (Fri, 11 Aug 2017 21:09:49 GMT):
dave.enyeart

rjones (Fri, 11 Aug 2017 21:10:03 GMT):
greg.haskins

rjones (Fri, 11 Aug 2017 21:10:50 GMT):
TamasBlummer

rjones (Fri, 11 Aug 2017 21:11:01 GMT):
hgabre

rjones (Fri, 11 Aug 2017 21:11:08 GMT):
jiangyaoguo

rjones (Fri, 11 Aug 2017 21:13:14 GMT):
kostas

rjones (Fri, 11 Aug 2017 21:13:28 GMT):
manish-sethi

rjones (Fri, 11 Aug 2017 21:13:44 GMT):
muralisr

rjones (Fri, 11 Aug 2017 21:14:00 GMT):
sheehan

rjones (Fri, 11 Aug 2017 21:14:08 GMT):
smithbk

rjones (Fri, 11 Aug 2017 21:14:23 GMT):
yacovm

rjones (Fri, 11 Aug 2017 21:16:21 GMT):
@jyellick could I ask you to say something in here so I know that maintainers can still speak in a channel for maintainers? thank you

jyellick (Fri, 11 Aug 2017 21:16:31 GMT):
Speaking

rjones (Fri, 11 Aug 2017 21:17:38 GMT):
Excellent.

JonathanLevi (Fri, 11 Aug 2017 21:20:30 GMT):

Message Attachments

JonathanLevi (Fri, 11 Aug 2017 21:20:43 GMT):
OK, we are safe!

rjones (Fri, 11 Aug 2017 21:21:34 GMT):
Everyone that is a `fabric` maintainer is also a channel owner and can `unmute` users as needed. I promise I'm done spamming now.

geekgonecrazy (Fri, 11 Aug 2017 21:39:15 GMT):
Has joined the channel.

arjanvaneersel (Sat, 12 Aug 2017 14:31:33 GMT):
Has joined the channel.

jyellick (Sat, 12 Aug 2017 17:00:41 GMT):
Cross posting from #fabric-pr-review [ ](https://chat.hyperledger.org/channel/fabric-pr-review?msg=RMt2a5BXnTLfGFXdZ)

JonathanLevi (Sat, 12 Aug 2017 21:26:50 GMT):
Hi everybody, how is something like the possible?

JonathanLevi (Sat, 12 Aug 2017 21:27:08 GMT):
(I saw the import path, etc. and the fix...)

JonathanLevi (Sat, 12 Aug 2017 21:27:54 GMT):
The question is more, how could one of us physically submit a breaking CR? Or was it a merge issue?

JonathanLevi (Sat, 12 Aug 2017 21:28:45 GMT):
I though that we have a few mechanisms in Gerrit for preventing this...

JonathanLevi (Sat, 12 Aug 2017 21:29:00 GMT):
(I though that we have a few mechanisms in Gerrit for preventing this...)

yacovm (Sat, 12 Aug 2017 21:36:53 GMT):
Consider the following scenario where the master branch's tip `M` has 2 different change sets that are not stacked on top of each other - `A` and `B`. Now, `A` and `B` can *not* be have a conflict, but if `A` and `B` are merged together - a compilation error (for instance) or a runtime error might occur. Now, assume without loss of generality that `A` is merged before `B` and now the master branch is `M || A`. Now, gerrit would add to `B` an orange circle indicating that it needs to be rebased on top of the current (new) master branch. The current policy allows you to submit `B` to be merged into master without having to rebase it.

yacovm (Sat, 12 Aug 2017 21:36:53 GMT):
Consider the following scenario where the master branch's tip `M` has 2 different change sets that are not stacked on top of each other - `A` and `B`. Now, `A` and `B` can *may not* have a conflict, but if `A` and `B` are merged together - a compilation error (for instance) or a runtime error might occur. Now, assume without loss of generality that `A` is merged before `B` and now the master branch is `M || A`. Now, gerrit would add to `B` an orange circle indicating that it needs to be rebased on top of the current (new) master branch. The current policy allows you to submit `B` to be merged into master without having to rebase it.

yacovm (Sat, 12 Aug 2017 21:38:09 GMT):

Message Attachments

yacovm (Sat, 12 Aug 2017 21:39:45 GMT):
The reason that we allow such change sets to be merged is that each CI cycle takes ~ 1 hour and has a success rate that isn't great as you know ;)

JonathanLevi (Sat, 12 Aug 2017 21:40:22 GMT):
Oh, yeah, I sure know. I see.

yacovm (Sat, 12 Aug 2017 21:41:00 GMT):
So the tactic that I personally usually do is: 1) Rebase locally and run UT and e2e locally 2) Look at the change sets that were merged before the parent of the change set in question until "now" and see if that is dangerous

JonathanLevi (Sat, 12 Aug 2017 21:41:05 GMT):
So one cannot always whether the build is genuinely broken?

yacovm (Sat, 12 Aug 2017 21:41:14 GMT):
ah, we can!

yacovm (Sat, 12 Aug 2017 21:41:26 GMT):
when a merge occurs, a merge CI job is triggered

JonathanLevi (Sat, 12 Aug 2017 21:41:34 GMT):
But only after a full post-merge build.

yacovm (Sat, 12 Aug 2017 21:41:34 GMT):
so you can look at the merge job and see if *that* failed

JonathanLevi (Sat, 12 Aug 2017 21:41:37 GMT):
Yes, I get it.

yacovm (Sat, 12 Aug 2017 21:41:56 GMT):
I know you do, the explanations here are more to the passive readers

JonathanLevi (Sat, 12 Aug 2017 21:42:00 GMT):
So effectively, it's ~1 hour from pushing the CR

JonathanLevi (Sat, 12 Aug 2017 21:42:16 GMT):
And say, another ~1 hour after merge/submitting the CR?

yacovm (Sat, 12 Aug 2017 21:42:28 GMT):
not sure what you're asking?

JonathanLevi (Sat, 12 Aug 2017 21:43:18 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=gGet8hHaNBRTW7YmA) Can we not automate this?

JonathanLevi (Sat, 12 Aug 2017 21:43:18 GMT):
Can we not automate this? [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=gGet8hHaNBRTW7YmA)

yacovm (Sat, 12 Aug 2017 21:44:00 GMT):
so I'd say:

yacovm (Sat, 12 Aug 2017 21:46:12 GMT):
1) I think that this can be done (enforce rebasing) but not sure if gerrit supports that without removing the +2s of maintainers. @rjones would know for sure. What you're asking is - can gerrit make jenkins run CI on a rebased simulation of the code and not on the latest change set (that would remove the +2s) Alternatively - is it possible to rebase without losing +2s? 2) compilation wise it's possible but runtime- wise it's equivalent to the halting problem?

yacovm (Sat, 12 Aug 2017 21:46:12 GMT):
1) I think that this can be done but not sure if gerrit supports that without removing the +2s of maintainers. @rjones would know for sure. What you're asking is - can gerrit make jenkins run CI on a rebased simulation of the code and not on the latest change set (that would remove the +2s) Alternatively - is it possible to rebase without losing +2s? 2) I'd say - compilation wise it's possible but runtime- wise it's equivalent to the halting problem?

yacovm (Sat, 12 Aug 2017 21:46:12 GMT):
1) I think that this can be done but not sure if gerrit supports that without removing the +2s of maintainers. @rjones would know for sure. What you're asking is - can gerrit make jenkins run CI on a rebased simulation of the code and not on the latest change set (that would remove the +2s) Alternatively - is it possible to rebase without losing +2s? 2) compilation wise it's possible but runtime- wise it's equivalent to the halting problem?

rjones (Sat, 12 Aug 2017 21:48:52 GMT):
I would need a lot of help to make that happen, and TBH I'm pretty gun shy right now

rjones (Sat, 12 Aug 2017 21:49:37 GMT):
the way it might work is getting 2+2 basically gives permission to a bot to do something like a rebase + merge, or something of that type

yacovm (Sat, 12 Aug 2017 21:49:39 GMT):
IMHO - since we have release branch and it's tagged and master branch is a developer branch and the release branch is the default branch in github - it's not that bad as it used to be

yacovm (Sat, 12 Aug 2017 21:50:31 GMT):
> the way it might work is getting 2+2 basically gives permission to a bot to do something like a rebase + merge, or something of that type So, is it possible that a bot would read if the change set has a +2, and if the change set needs rebase - rebase it and if CI passes - recover the +2 ?

rjones (Sat, 12 Aug 2017 21:51:21 GMT):
it's all YAML/shell scripts.

rjones (Sat, 12 Aug 2017 21:51:29 GMT):
any of the scripts can do anything you want.

rjones (Sat, 12 Aug 2017 21:51:55 GMT):
the Gerrit trickery is all prolog

yacovm (Sat, 12 Aug 2017 21:52:24 GMT):
protolog is like witchcraft

yacovm (Sat, 12 Aug 2017 21:52:24 GMT):
prolog is like witchcraft

rjones (Sat, 12 Aug 2017 21:52:47 GMT):
we might take this conversation to #fabric-ci

jyellick (Sat, 12 Aug 2017 22:56:23 GMT):
> IMHO - since we have release branch and it's tagged and master branch is a developer branch and the release branch is the default branch in github - it's not that bad as it used to be Agreed. It's not the end of the world that this happened, and, closer to a release, we can (and are) more careful with merging

jyellick (Sat, 12 Aug 2017 22:58:41 GMT):
@rjones What about another Jenkins trigger that we could run which would simply merge the CR onto master, and run a very light CI. If we disable things like code coverage metrics, and maybe even do a `go test-run='^$'` just so that we can get assurances that the code and tests still compile.

rjones (Sat, 12 Aug 2017 23:16:45 GMT):
@jyellick it is literally in your hands to do what you want

rjones (Sat, 12 Aug 2017 23:17:10 GMT):
We have a 'Remerge' command as well

mastersingh24 (Sun, 13 Aug 2017 09:19:00 GMT):
Fellow maintainers - I'll be out on vacation this week (starting with a 7 hour drive this morning :( ). I'll likely be checking in in the early AM since I generally get up before most, but just wanted to let you know in case people think I'm ignoring them ;)

muralisr (Sun, 13 Aug 2017 13:22:16 GMT):
I took the the liberty of V+1 on https://gerrit.hyperledger.org/r/#/c/12335/ with the following comment in the CR ```We have had every test succeed multiple times over the course of all the reverifies. I the latest, behave fails but has succeeded before. Rather wait for one CR where everything works, allow me to override the V-1 please. (Also have submitted https://gerrit.hyperledger.org/r/#/c/12393 for one of the annoying failures).```

binhn (Mon, 14 Aug 2017 14:15:51 GMT):
@mastersingh24 put your car in auto drive mode :-)

binhn (Mon, 14 Aug 2017 18:22:55 GMT):
need 1 more +2 please https://gerrit.hyperledger.org/r/#/c/12147/

dsanchezseco (Wed, 16 Aug 2017 07:01:47 GMT):
Has left the channel.

rjones (Thu, 17 Aug 2017 23:13:55 GMT):
This (merged) commit enables 4 new fabric-specific CI verbs. rebuild-{x,z,behave,e2e} will do what it says on the tin. re{check,verify} still exist and will get all 4. https://github.com/hyperledger/ci-management/commit/b5e642f900663646e10bf278a09656c09ea7187f

geekgonecrazy (Fri, 18 Aug 2017 01:14:42 GMT):
Has left the channel.

dave.enyeart (Fri, 18 Aug 2017 02:22:24 GMT):
@rjones that is awesome. Question- besides doing all four vs one, is there any difference between what a 'reverify' does vs a 'rebuild'?

rjones (Fri, 18 Aug 2017 02:25:22 GMT):
No. The difference is: previously, we had four builds that would fire for one word. Now each of those builds fires for a distinct word, as well as the other word. I picked a word that I wouldn't need a regular expression to distinguish, that's all.

dave.enyeart (Fri, 18 Aug 2017 02:43:48 GMT):
thanks @rjones . And finally, if 3 of 4 pass with initial CI, and you do a rebuild-XXX to get the fourth one to pass, do you get the +1 for Verification automatically?

rjones (Fri, 18 Aug 2017 02:44:27 GMT):
you should. if you don't, please tell me

dave.enyeart (Fri, 18 Aug 2017 02:44:34 GMT):
thx

dave.enyeart (Fri, 18 Aug 2017 03:15:24 GMT):
Concerning https://gerrit.hyperledger.org/r/#/c/11909/ (Nominate Alessandro as maintainer), it looks like there are sufficient votes to merge per the Hyperledger charter - https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#becoming-a-maintainer. Last call for final votes/comments please!

dave.enyeart (Fri, 18 Aug 2017 03:15:24 GMT):
Concerning https://gerrit.hyperledger.org/r/#/c/11909/ (Nominate Alessandro as maintainer), I think we need a resolution. The charter says a majority of maintainer votes is required and therefore the nomination would be rejected. But readthedocs says only 5 votes are needed, in which case the nomination would pass: https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#becoming-a-maintainer. Does anybody know why the disconnect exists between the charter and readthedocs? If we settle that then I think we have our resolution.

JonathanLevi (Fri, 18 Aug 2017 03:54:20 GMT):
This is a tricky situation @dave.enyeart - a few of us made several commitments to keep the ratio of IBMers maintainers below a certain level.

JonathanLevi (Fri, 18 Aug 2017 03:54:47 GMT):
At the same time, I really don't want people to take this personally, or get demotivated.

JonathanLevi (Fri, 18 Aug 2017 03:55:32 GMT):
I have added my notes to the CR... but will be happy to discuss this more/with anyone/everyone.

JonathanLevi (Fri, 18 Aug 2017 04:12:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=NfLZa2HKJe4fLD8Ys) We need to update the read the docs. We need a majority for adding a maintainer.

JonathanLevi (Fri, 18 Aug 2017 04:13:43 GMT):
That CR (Alessandro's case) requires an extra vote, in order to go through... but please all, take a look at my last comment there.

JonathanLevi (Fri, 18 Aug 2017 04:14:40 GMT):
Again, my review "score" is closer to a "-1" too because of our earlier commitment(s) - but will be happy to discuss this more.

dave.enyeart (Fri, 18 Aug 2017 04:14:53 GMT):
Ok, could somebody familiar with the history here update readthedocs. then i think there will be more clarity on a resolution.

JonathanLevi (Fri, 18 Aug 2017 04:15:55 GMT):
Sure, I will do it tomorrow. Not clear why the readthedocs are not in sync. No problem.

rjones (Fri, 18 Aug 2017 06:47:44 GMT):
@JonathanLevi https://readthedocs.org/projects/hyperledger-fabric/ says it was built 8 hours ago?

dave.enyeart (Sat, 19 Aug 2017 13:19:33 GMT):
Ok, https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#becoming-a-maintainer was updated to be aligned with the charter, indicating that a majority is indeed required. Thanks for clarifying.

danielleekc (Mon, 21 Aug 2017 10:01:19 GMT):
Has joined the channel.

binhn (Wed, 23 Aug 2017 00:47:22 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=go372nhr6GHPh2fag) @JonathanLevi that hopefully wouldn't mean accepting maintainers whose code knowledge is peripheral

JonathanLevi (Wed, 23 Aug 2017 06:59:16 GMT):
Hi @binhn - you are right. No, it wouldn't mean that.

JonathanLevi (Wed, 23 Aug 2017 06:59:27 GMT):
It's actually a challenging goal. I was/am still hoping that we will be able get more organizations and individuals interested in Hyperledger Fabric, so that they spend more time, get up to speed, etc... so that they can "move up in the world" and get promoted to be maintainers.

JonathanLevi (Wed, 23 Aug 2017 07:00:41 GMT):
It does not mean that no-IBMers will get a "discount" in terms of knowing enough about the project. At least this is not the way I saw/see it.

JonathanLevi (Wed, 23 Aug 2017 07:01:58 GMT):
If you (Binhn) or others have some insights/views that you would like to share, then we should do it.

JonathanLevi (Wed, 23 Aug 2017 07:02:58 GMT):
Frankly, Hyperledger Fabric does have quite a steep learning curve. Most of us probably don't feel/appreciate it, as we have been around for a while.

JonathanLevi (Wed, 23 Aug 2017 07:05:03 GMT):
For example, some suggested that the Linux Foundation webinar I delivered 2 weeks ago, was already too technical.... while I went over less than 5% of what we have (all) built here.

JonathanLevi (Wed, 23 Aug 2017 18:23:35 GMT):
--- I believe that being a good maintainer for a project such as Hyperledger Fabric, require a combination of skills. I don't think that one necessarily needs to know "everything". Even so, does any one of us really know every single line of this project? No, or at least: I doubt it. So many contributors, and so many moving parts. Could I/we accept all the features that people proposed? No. Can each of really claim that we never make mistakes? No, at least, I make mistakes all the time. However, we do make a constant effort to minimize the number of errors and to minimize their impact. Mind you, I did end up "cutting off" the 1.0 release "abruptly" (in the midst of people arguing over/discussing the release notes), as moments after we have all agreed that we are ready to go - the press-releases were kicking in. Could I/we make everybody happy all the time (e.g. when we released 1.0)? Nope. But hopefully, we can be more communicative, friendly, keeping our minds open to suggestions and continue to welcome others. As a matter of fact, I'm probably the one guy who is constantly/relentlessly asking all of you questions, regularly reaching out for help, and getting others' views... especially when I'm under stress/pressure to deliver or just overworked. Other than recommending that we'd accept new maintainers with limited and/or merely peripheral knowledge, the main thing, I think, is that we should all be "as nice to newcomers as we are being to each other", so that we can bring more people up to speed. Just some more thoughts on this, after getting some more sleep...

JonathanLevi (Wed, 23 Aug 2017 18:24:10 GMT):
--- Hi again, I believe that being a good maintainer in a project such as Hyperledger Fabric, require a combination of skills. I don't think that one necessarily needs to know "everything". Even so, does any one of us really know every single line of this project? No, or at least: I doubt it. So many contributors, and so many moving parts. Could I/we accept all the features that people proposed? No. Can each of really claim that we never make mistakes? No, at least, I make mistakes all the time. However, we do make a constant effort to minimize the number of errors and to minimize their impact. Mind you, I did end up "cutting off" the 1.0 release "abruptly" (in the midst of people arguing over/discussing the release notes), as moments after we have all agreed that we are ready to go - the press-releases were kicking in. Could I/we make everybody happy all the time (e.g. when we released 1.0)? Nope. But hopefully, we can be more communicative, friendly, keeping our minds open to suggestions and continue to welcome others. As a matter of fact, I'm probably the one guy who is constantly/relentlessly asking all of you questions, regularly reaching out for help, and getting others' views... especially when I'm under stress/pressure to deliver or just overworked. Other than recommending that we'd accept new maintainers with limited and/or merely peripheral knowledge, the main thing, I think, is that we should all be "as nice to newcomers as we are being to each other", so that we can bring more people up to speed. Just some more thoughts on this, after getting some more sleep...

JonathanLevi (Wed, 23 Aug 2017 18:25:26 GMT):
--- Hi again, I believe that being a good maintainer in a project such as Hyperledger Fabric, require a combination of skills. I don't think that one necessarily needs to know "everything". Even so, does any one of us really know every single line of this project? No, or at least: I doubt it. So many contributors, and so many moving parts. Could I/we accept all the features that people proposed? No. Can each of us really claim that we never make mistakes? No, at least, I make mistakes all the time. However, we do make a constant effort to minimize the number of errors and to minimize their impact. Mind you, I did end up "cutting off" the 1.0 release "abruptly" (in the midst of people arguing over/discussing the release notes), as moments after we have all agreed that we are ready to go - the press-releases were kicking in. Could I/we make everybody happy all the time (e.g. when we released 1.0)? Nope. But hopefully, we can be more communicative, friendly, keeping our minds open to suggestions and continue to welcome others. As a matter of fact, I'm probably the one guy who is constantly/relentlessly asking all of you questions, regularly reaching out for help, and getting others' views... especially when I'm under stress/pressure to deliver or just overworked. Other than recommending that we'd accept new maintainers with limited and/or merely peripheral knowledge, the main thing, I think, is that we should all be "as nice to newcomers as we are being to each other", so that we can bring more people up to speed. Just some more thoughts on this, after getting some more sleep...

JonathanLevi (Wed, 23 Aug 2017 18:25:44 GMT):
^^^ Comments welcome!

yacovm (Wed, 23 Aug 2017 18:29:32 GMT):
Well, lack of knowledge isn't a constant thing- is it? people can learn. I for one- at first was only comfortable with the gossip code, but then went on and learned from both reading the code, and asking people and am now comfortable with other areas of the code (mainly the peer / msp module)

yacovm (Wed, 23 Aug 2017 18:29:32 GMT):
Well, lack of knowledge isn't a constant thing- is it? people can learn. I for one- at first was only *really* comfortable with the gossip code, but then went on and learned from both reading the code, and asking people and am now comfortable with other areas of the code (mainly the peer / msp module)

yacovm (Wed, 23 Aug 2017 18:33:23 GMT):
Well, lack of knowledge isn't a constant thing- is it? people can learn....

JonathanLevi (Wed, 23 Aug 2017 18:45:13 GMT):
Yes, that's the idea. We share so much material from design docs, to plans, code, reviews, discussions... I don't think it is impossible to "jump on the wagon" and ride with us ;-)

JonathanLevi (Wed, 23 Aug 2017 18:45:13 GMT):
Yes, that's true - that's the idea. We share so much material from design docs, to plans, code, reviews, discussions... I don't think it is impossible to "jump on the wagon" and ride with us ;-)

JonathanLevi (Wed, 23 Aug 2017 18:45:13 GMT):
Yes, that's true - that's the idea. We share so much material: from design docs, to plans, code, reviews, discussions... I don't think it is impossible to "jump on the wagon" and ride with us ;-)

writetogupta (Wed, 23 Aug 2017 21:15:04 GMT):
Has joined the channel.

CodeReaper (Fri, 25 Aug 2017 10:54:05 GMT):
Has joined the channel.

greg.haskins (Sat, 26 Aug 2017 20:59:56 GMT):
all, could someone pls fire this one in: https://gerrit.hyperledger.org/r/#/c/12803/

greg.haskins (Sat, 26 Aug 2017 21:00:16 GMT):
the paired "Release" CR already went in...this should be the next patch (not that baseimage is high volume)

greg.haskins (Sat, 26 Aug 2017 21:01:38 GMT):
ty @yacovm

greg.haskins (Sat, 26 Aug 2017 21:02:25 GMT):
some love for the 12107/12109 pair appreciated too: https://gerrit.hyperledger.org/r/#/c/12109/

greg.haskins (Sat, 26 Aug 2017 21:02:38 GMT):
been languishing for awhile

yacovm (Sat, 26 Aug 2017 21:13:28 GMT):
Have a small comment @greg.haskins

mastersingh24 (Sat, 26 Aug 2017 23:07:47 GMT):
Can we get another +2 on https://gerrit.hyperledger.org/r/#/c/11489/ ? (I'm trying to go through the old CRs here)

mastersingh24 (Mon, 28 Aug 2017 20:34:30 GMT):
Folks - wanted to gauge the appetite for upgrading Go (to 1.9) and grpc-go (to 1.5.2) for the 1.1 release. I've submitted the relevant CRs and if we are bold enough to make the move, we should do so soon to get as much burn-in time as required. The changes required were quite small so seems like a reasonable thing to do IMHO. I also think that the ability to test the use of Golang plugins is definitely worth it's weight in gold plus there are a number of performance enhancements as well

jyellick (Mon, 28 Aug 2017 20:35:04 GMT):
+1

yacovm (Mon, 28 Aug 2017 20:35:17 GMT):
Yes please

yacovm (Mon, 28 Aug 2017 20:35:17 GMT):
Yes please > I also think that the ability to test the use of Golang plugins is definitely worth it's weight in gold

JonathanLevi (Mon, 28 Aug 2017 20:46:45 GMT):
We are looking into 4 weeks timeframe, right?

jyellick (Mon, 28 Aug 2017 20:47:45 GMT):
Code freeze after this week, then release at the end of September?

jyellick (Mon, 28 Aug 2017 20:47:45 GMT):
Code freeze after this week, then release at the end of September? (Is my understanding)

jyellick (Mon, 28 Aug 2017 20:47:45 GMT):
Non-bug code freeze after this week, then release at the end of September? (Is my understanding)

jyellick (Mon, 28 Aug 2017 20:47:45 GMT):
Non-bug-fix code freeze after this week, then release at the end of September? (Is my understanding)

mastersingh24 (Mon, 28 Aug 2017 21:02:02 GMT):
Given no one objected, I still favor trying to do quarterly releases. So if we are going to attempt to do 1.1 at the end of 3Q17 (by Sept 30), we'd have to be done by end of this week with any code and then we'd need to figure out how we are going to carve out a release. Other option would be to skip 3Q17 and wait until 4Q17 and start trying to get some candidate releases out in say early October. I'm working on a strategy for using build tags to make any unfinished / experimental features unavailable in the binary by default as well.

JonathanLevi (Mon, 28 Aug 2017 23:01:32 GMT):
Thanks for bringing this up Gari. Here are my 2 cents:

JonathanLevi (Mon, 28 Aug 2017 23:01:36 GMT):
1. We need to make sure that what is "done" by the end of the week, is sufficient, or shall I say, justifies a release.

JonathanLevi (Mon, 28 Aug 2017 23:02:42 GMT):
That's to say, that if we feel that what's there is not enough or that there are a few big remaining features that are clearly needed, then we may as well delay or skip it. IMHO.

JonathanLevi (Mon, 28 Aug 2017 23:03:41 GMT):
2. If we skip the 3Q17, then I'd recommend not to really wait until the end of 4Q17 (say, xmas time), but to rather have something out closer to the end of Oct, or mid-November.

JonathanLevi (Mon, 28 Aug 2017 23:04:41 GMT):
I don't know how people feel about it. Seems like there is a lot to do in terms of service-ability still, more examples, and we are constantly getting more feedback the more people/organizations try it.

JonathanLevi (Mon, 28 Aug 2017 23:05:15 GMT):
On the other hand, I like(d) the rhythm and momentum we gained in June-July (despite the "heat")

vukolic (Tue, 29 Aug 2017 08:02:25 GMT):
Has joined the channel.

mastersingh24 (Tue, 29 Aug 2017 10:23:39 GMT):
I think as long as we can get on / stay on a regular release cadence we'll be OK. I suppose "quarterly" does not technically have to mean calendar year quarters ;) We could create our own Hyperledger Fabric "fiscal calendar" ;) At this point, given we DID NOT do the type of planning we wanted to due to v1.0.0's ship date as well as summer vacations, perhaps we can decide what our calendar will be. I really do think that 3 months between releases is the right cadence though.

jyellick (Tue, 29 Aug 2017 13:29:03 GMT):
I'd also rather see us ship sooner than later. If we release on a consistent cadence, a particular feature missing a particular release isn't such a big deal, because it will have a shot again in 3 months.

cotofei (Tue, 29 Aug 2017 13:34:46 GMT):
Has joined the channel.

JonathanLevi (Tue, 29 Aug 2017 14:35:43 GMT):
Good morning. Yes, that's very true.

JonathanLevi (Tue, 29 Aug 2017 14:35:51 GMT):
I believe that the more we announce in advance and the more people know what to expect and when - the better.

dave.enyeart (Tue, 29 Aug 2017 17:38:42 GMT):
For our first minor release (1.1) I think it is critical to nail down our strategy and infrastructure around compatibility, build tags vs feature toggles, automated upgrade test, etc. In my opinion these areas will not be completely resolved by end of week. I'd prefer to take the time to do these right, rather than rush to hit an arbitrary date. I think 3 months is a good cadence, I'd just prefer mid-quarter releases rather than end-of-quarter releases. It would work well for 1.1 due to my prior statement, and would work well for 1.2 due to holidays.

dave.enyeart (Tue, 29 Aug 2017 17:38:42 GMT):
For our first minor release (1.1) I think it is critical to nail down our strategy and infrastructure around compatibility, build tags vs feature toggles, automated upgrade test, etc. In my opinion these areas will not be completely resolved by end of week. I'd prefer to take the time to do these right, rather than rush to hit an arbitrary date. The other concern is that many of us are doing customer work the next few weeks rather than focusing on 1.1. I think 3 months is a good cadence, I'd just prefer mid-quarter releases rather than end-of-quarter releases. It would work well for 1.1 due to my prior statements, and would work well for 1.2 due to holidays.

JonathanLevi (Tue, 29 Aug 2017 19:46:25 GMT):
So the checkpoint is on Sept 5th, right?

JonathanLevi (Tue, 29 Aug 2017 19:47:27 GMT):
We need to know by then what's going to be planned & ready for a/the potential release on/by Sep 30th... right?

binhn (Wed, 30 Aug 2017 21:32:47 GMT):
to avoid holidays toward the year end (at least in the US), I would propose 2/15, 5/15, 8/15 and 11/15 to be our quarterly release dates; it would give us time on 1.1 and we can plan on the key bug fixes for 1.0.x Thoughts?

JonathanLevi (Wed, 30 Aug 2017 23:01:01 GMT):
@binhn: +1

jyellick (Wed, 30 Aug 2017 23:25:38 GMT):
I know I've already spoken up for a "sooner than later" approach. I think I'm willing to concede on this one. Let's take a little extra time and get v1.1 right, especially putting controls in for compatibility going forward, automating our release process, etc. so that we can make sure we stay on a nice even 3 month cadence after.

jyellick (Wed, 30 Aug 2017 23:25:38 GMT):
I know I've already spoken up for a "sooner than later" approach, but I think I'm willing to concede on this one. I'd say let's take a little extra time and get v1.1 right, especially putting controls in for compatibility going forward, automating our release process, etc. so that we can make sure we stay on a nice even 3 month cadence after.

mastersingh24 (Thu, 31 Aug 2017 14:34:04 GMT):
Personally, I'd rather stick with real end of quarter releases. I'm good with 11/15 as the target for 1.1 and then I think for 2018 we can do 3/31, 6/30, 9/30 and likely 12/15 (given holidays). I don't think it makes sense to do a 2/15/18 release and given the holiday season post 11/15/17, 3/31/18 makes the most sense

mastersingh24 (Thu, 31 Aug 2017 14:34:27 GMT):
I don't see us doing much between in the month of Dec

mastersingh24 (Thu, 31 Aug 2017 14:36:36 GMT):
And speaking of 1.0.X releases: fabric and fabric-ca 1.0.2 - https://gerrit.hyperledger.org/r/#/q/(project:fabric-ca+OR+project:fabric)+branch:release+status:open

dave.enyeart (Fri, 01 Sep 2017 10:16:41 GMT):
Could somebody remind me of the license header policy? Did we decide not to make a bulk update of all the source files, and rather to simply update them as individual changes are made to files?

dave.enyeart (Fri, 01 Sep 2017 10:16:41 GMT):
Could somebody remind me of the license header policy? Did we decide not to ever make a bulk update of all the source files, and rather to simply update them as individual changes are made to files?

dave.enyeart (Fri, 01 Sep 2017 10:16:46 GMT):
```/* Copyright IBM Corp. All Rights Reserved. SPDX-License-Identifier: Apache-2.0 */```

yacovm (Fri, 01 Sep 2017 10:18:20 GMT):
I think it was said we can do a lazy-update (upon file update)

yacovm (Fri, 01 Sep 2017 10:18:30 GMT):
but IMO a bulk update should be also fine, because why not?

mastersingh24 (Fri, 01 Sep 2017 11:06:38 GMT):
@dave.enyeart - The "check" only checks changed files. We only have to do the changed files, but it might make more sense to change the headers of all the files in whichever package you happen to be updating

JonathanLevi (Wed, 06 Sep 2017 13:55:04 GMT):
Good morning/afternoon/evening

JonathanLevi (Wed, 06 Sep 2017 13:55:24 GMT):
Do we need to discuss the status of the 1.1 release (plan/dates)

JonathanLevi (Wed, 06 Sep 2017 13:55:40 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=gssHzF4qLyCXvkxeq)

JonathanLevi (Wed, 06 Sep 2017 13:56:36 GMT):
At some point (2 weeks ago) we talked about Sep 30's at some point, and want to see if we can have everything defined by today... how do things look?

JonathanLevi (Wed, 06 Sep 2017 13:57:03 GMT):
BTW: It seems like the Golang 1.9 upgrade was a good call @mastersingh24 !

JonathanLevi (Wed, 06 Sep 2017 13:57:27 GMT):
Following which, we have upgraded all of our backend too

JonathanLevi (Wed, 06 Sep 2017 13:57:27 GMT):
Following which, we have upgraded all of our backend too (and tested for days)

greg.haskins (Wed, 06 Sep 2017 14:03:03 GMT):
@JonathanLevi I still consider some kind of xBFT based orderer to be baseline minimum-viable product for v1.1

greg.haskins (Wed, 06 Sep 2017 14:03:16 GMT):
sept 30th seems a bit aggressive for that

jyellick (Wed, 06 Sep 2017 14:03:38 GMT):
BFT for the orderer is not in the cards for v1.1

jyellick (Wed, 06 Sep 2017 14:03:53 GMT):
This is not something we ruled out early in release planning.

jyellick (Wed, 06 Sep 2017 14:03:53 GMT):
This is something we ruled out early in release planning.

greg.haskins (Wed, 06 Sep 2017 14:03:56 GMT):
i guess in the end, a version is just a version

greg.haskins (Wed, 06 Sep 2017 14:04:24 GMT):
but the bottom line is: xBFT is critical IMO so the question really is: which release will it be in?

greg.haskins (Wed, 06 Sep 2017 14:06:16 GMT):
have to step away for a few, but will continue later

greg.haskins (Wed, 06 Sep 2017 14:07:13 GMT):
btw: I am perfectly willing to donate some resources to gaining velocity on the feature, so I should sync up with whomever has been working in that space

greg.haskins (Wed, 06 Sep 2017 14:07:27 GMT):
but bbiab

jyellick (Wed, 06 Sep 2017 14:15:52 GMT):
SBFT is certainly something that we'd like to add back, ultimately, it's a question of priority. To my mind, we have plenty of technical debt built up in the v1.0 release. My concern is that we are pushing ahead with new features and ignoring this debt, and while we build out those features, we are simply compounding the effort which will be required to address these other problems. I like to think the orderer team has done a good job addressing much of this debt towards in the v1.1 release, but there is still more work to do, and I'm worried that we're ignoring this debt elsewhere.

mastersingh24 (Wed, 06 Sep 2017 14:18:09 GMT):
Just to throw this out there, there are a few "options" we should evaluate for a BFT-based orderer: - do it on our own with Fabric - something like sBFT - look at using Tendermint (which Burrow uses as well as a few other projects outside of Hyperledger) In any case, it's time to come up with a plan and then align development / resource so we can properly plan the rollout of this feature / capability

mastersingh24 (Wed, 06 Sep 2017 14:18:36 GMT):
But we need to harden things for 1.1, make any changes needed based on actual usage, etc

greg.haskins (Wed, 06 Sep 2017 14:40:56 GMT):
@jyellick @mastersingh24 agree with the above

greg.haskins (Wed, 06 Sep 2017 14:41:10 GMT):
so, lets keep the dialog going

greg.haskins (Wed, 06 Sep 2017 14:41:22 GMT):
i think if nothing else, this needs to happen sooner rather than later

greg.haskins (Wed, 06 Sep 2017 14:42:18 GMT):
I have some internal (to my employer) deployments that are suitable for v1.0 architecture, but lack of xBFT ordering will limit this to internal only

greg.haskins (Wed, 06 Sep 2017 14:42:28 GMT):
so im really motivated to see this fixed, and can help

kostas (Wed, 06 Sep 2017 14:52:12 GMT):
What @jyellick noted above. With the resources we have available, we have to clean the existing surface before we add new features, else we'll drown in debt. In my mind the rough planning for the orderer was "1.1 = make it faster, 1.2 = make administrators happy (metrics, health checkpoints, etc., 1.3 = make it BFT".

kostas (Wed, 06 Sep 2017 14:54:28 GMT):
@greg.haskins: Let's talk when you get some time. Assuming an extra pair of hands, we might be able to kickstart BFT development earlier.

JonathanLevi (Wed, 06 Sep 2017 16:57:25 GMT):
BTW: I agree with the below: [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=9m5rvWR9A6Eg8r4Za) Especially given that haven't finalized all the details by yesterday (Sept 5), as the soft deadline/checkpoint Chris and Gari asked us to work with.

JonathanLevi (Wed, 06 Sep 2017 16:57:25 GMT):
BTW: I agree with the below: [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=9m5rvWR9A6Eg8r4Za)

JonathanLevi (Wed, 06 Sep 2017 16:57:53 GMT):
Especially given that haven't finalized all the details by yesterday (Sept 5), as the soft "cut off" deadline/checkpoint Chris and Gari asked us to work with.

JonathanLevi (Wed, 06 Sep 2017 16:57:53 GMT):
Especially given that we haven't finalized all the details by yesterday (Sept 5), as the soft "cut off" deadline/checkpoint Chris and Gari asked us to work with.

JonathanLevi (Wed, 06 Sep 2017 16:59:04 GMT):
The question, perhaps, is whether we would still like to have 2 releases/milestones?

JonathanLevi (Wed, 06 Sep 2017 16:59:18 GMT):
I'm just bouncing thoughts around.

JonathanLevi (Wed, 06 Sep 2017 17:00:08 GMT):
S/BFT will certainly be a gamechanger, this 2017....

mastersingh24 (Wed, 06 Sep 2017 17:00:33 GMT):
I look at it like this: - I still like the idea of quarterly releases - I don't see us doing 2 releases (Sept 30 and Dec 31) this year (given being a bit behind in planning as well as holidays in Nov / Dec) - So it seems to be that doing a single minor release (e.g. 1.1 ) this year makes sense and given my point on holidays, etc Nov 15 seems like as good a date as any) - Then in 2018 we can back on track for quarterly releases ;)

JonathanLevi (Wed, 06 Sep 2017 17:01:59 GMT):
I like the 'back on track' bit! ;-)

JonathanLevi (Wed, 06 Sep 2017 17:01:59 GMT):
I like the `back on track` bit! ;-)

mastersingh24 (Wed, 06 Sep 2017 17:02:22 GMT):
There is ZERO chance in getting S/BFT in this year for production use. Hopefully we can all agree on what the first BFT implementation will be and figure out how best to proceed. I think we do need to start putting some effort into thinking about BFT though

JonathanLevi (Wed, 06 Sep 2017 17:02:37 GMT):
We should really consider the overheard. I also like(d) the Nov 15 that Binhn proposed.

mastersingh24 (Wed, 06 Sep 2017 17:04:08 GMT):
Indeed

mastersingh24 (Wed, 06 Sep 2017 17:04:58 GMT):
This should also give us some additional time to properly plan 1.2 (so we can get back on the *right* track) ;)

muralisr (Wed, 06 Sep 2017 18:08:06 GMT):
and stay there ...

greg.haskins (Wed, 06 Sep 2017 18:20:17 GMT):
so, who is doing the xBFT work: Primarily @kostas and @jyellick ?

greg.haskins (Wed, 06 Sep 2017 18:20:21 GMT):
someone else?

greg.haskins (Wed, 06 Sep 2017 18:20:54 GMT):
should we perhaps form some kind of working-group or something to organize?

JonathanLevi (Wed, 06 Sep 2017 18:31:20 GMT):
If we are aiming for post-2017, early- to mid- 2018 target date, then may be we can actually get a few organizations contributing to the effort.

greg.haskins (Wed, 06 Sep 2017 18:31:44 GMT):
that sounds reasonable to me

JonathanLevi (Wed, 06 Sep 2017 18:32:17 GMT):
A task force (as in, a smaller, more focused form of a WG) can probably help and encourage others, I believe...

JonathanLevi (Wed, 06 Sep 2017 18:32:17 GMT):
A task force (as in, a smaller, more focused form of a WG) can probably help and encourage others, I believe...(to support Greg's comment/suggestion)

greg.haskins (Wed, 06 Sep 2017 18:32:29 GMT):
sure, i dont care what we call it

JonathanLevi (Wed, 06 Sep 2017 18:34:06 GMT):
Yes, yes. I know. I am just aware of the process of forming an official WG (from wiki, reports, ...) compared to a few of us [geeks ;-)] who find this interesting... even if at first some may not be able to contribute right away, but at least to just join and be part of the discussion(s).

greg.haskins (Wed, 06 Sep 2017 18:34:53 GMT):
you have a good point...i dont think it needs a ton of formal structure

JonathanLevi (Wed, 06 Sep 2017 18:35:18 GMT):
Yup, let's hope so ;-) @kostas, @jyellick, @mastersingh24: thoughts?

greg.haskins (Wed, 06 Sep 2017 18:35:18 GMT):
a thread on the ML, perhaps a wiki subsection on the already existing...done

JonathanLevi (Wed, 06 Sep 2017 18:35:50 GMT):
Collecting some of the awesome docs that have been produced, initial steps, breaking down to milestones, etc...

JonathanLevi (Wed, 06 Sep 2017 18:35:50 GMT):
Yup, collecting some of the awesome docs that have been produced, initial steps, breaking down to milestones, etc... making more (new) people feel a part of this, or at least know (and assured) that they are welcome...!

kostas (Wed, 06 Sep 2017 18:37:28 GMT):
@greg.haskins: A good part of the core SBFT work was done by Simon pre-1.0, and Gabor and Marko Vukolic extended that slightly. To answer your question directly: the plan was for me to work on SBFT once I got some cycles available (in a month or so) and have it ready for 1.3. But that was the case if we didn't have any volunteers in-between, and it sounds like this is not the case anymore.

kostas (Wed, 06 Sep 2017 18:37:28 GMT):
@greg.haskins: A good part of the core SBFT work was done by Simon pre-1.0, and Gabor and Marko Vukolic extended that slightly. To answer your question directly: the plan was for me to work on SBFT once I got some cycles available (in a bit more than a month or so) and have it ready for 1.3. But that was the case if we didn't have any volunteers in-between, and it sounds like this is not the case anymore.

kostas (Wed, 06 Sep 2017 18:39:30 GMT):
I am skeptical of task forces and workgroups. A thread on the mailing list to kick things off and an associated JIRA is all we need.

greg.haskins (Wed, 06 Sep 2017 18:40:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yua48fiCMQ8fWEaJv) @kostas i agree, i was probably overstating it anyway

greg.haskins (Wed, 06 Sep 2017 18:40:30 GMT):
s/working-group/some way to organize

greg.haskins (Wed, 06 Sep 2017 18:41:24 GMT):
i am also of the opinion that the critical thing be some kind of byzantine resistant orderer, not that it has to be "SBFT" per se

greg.haskins (Wed, 06 Sep 2017 18:41:45 GMT):
if the team things continuing on that work is the best way to get there, great...if not, thats fine too

greg.haskins (Wed, 06 Sep 2017 18:41:45 GMT):
if the team thinks continuing on that work is the best way to get there, great...if not, thats fine too

kostas (Wed, 06 Sep 2017 19:06:37 GMT):
Roger that. (My take is that it'd be a shame not to see the SBFT line of work completed, but I guess we can take that to the mailing list.)

jyellick (Wed, 06 Sep 2017 19:29:57 GMT):
My two cents, I think it would be actually incredibly useful to simply add another CFT orderer, but one that is more closely to a typical BFT orderer first. Take something like etcd/raft and prove that we can take the existing consensus plugin architecture and add a 'leader type' consensus implementation. My hope is that this would only be a few weeks worth of work, would prove out the orderer interfaces, and would familiarize those looking to pull SBFT back into the system with the those ordering interfaces. I think the core of SBFT is pretty solid, it is the integration with the rest of the ordering system where the real outstanding work lives.

kostas (Wed, 06 Sep 2017 19:41:34 GMT):
(I concur.)

greg.haskins (Wed, 06 Sep 2017 23:33:23 GMT):
@mastersingh24 FYI: https://gerrit.hyperledger.org/r/#/c/13217/

greg.haskins (Wed, 06 Sep 2017 23:33:36 GMT):
please consider for v1.0.x branch

greg.haskins (Wed, 06 Sep 2017 23:34:02 GMT):
@mastersingh24 do we still need the v0.4.0 baseimage with go v1.9?

greg.haskins (Wed, 06 Sep 2017 23:34:05 GMT):
i dropped the ball on that one

greg.haskins (Wed, 06 Sep 2017 23:36:19 GMT):
on a different topic: I was thinking about CRs like this: https://gerrit.hyperledger.org/r/#/c/13079/

greg.haskins (Wed, 06 Sep 2017 23:36:54 GMT):
one of the things that bothers me is the shear cognitive load that a vendor update brings

greg.haskins (Wed, 06 Sep 2017 23:38:27 GMT):
I wonder if the tooling exists (e.g. via govendor) or could be created to verify that the sources match the reference to the upstream sources in vendor.json

greg.haskins (Wed, 06 Sep 2017 23:38:51 GMT):
it wouldnt be perfect, as someone could always just pull from a compromised github repo, I suppose

greg.haskins (Wed, 06 Sep 2017 23:39:35 GMT):
but it bothers me that I can't really tell if that is really c5b7fccd2 from the prometheus github repo

greg.haskins (Wed, 06 Sep 2017 23:46:00 GMT):
@mastersingh24 https://gerrit.hyperledger.org/r/#/c/13219/

kostas (Thu, 07 Sep 2017 01:45:10 GMT):
> I wonder if the tooling exists (e.g. via govendor) or could be created to verify that the sources match the reference to the upstream sources in vendor.json Tooling as in "how do we make it a CI job?" (I presume that you're aware of `govendor sync`. For any orderer-related vendor dependencies that I review, I usually fetch locally, then `govendor sync` and make sure that none of the packages in the changeset show up in my local `git status`.)

greg.haskins (Thu, 07 Sep 2017 11:33:16 GMT):
@kostas yeah, good...if that were captured in CI, thats probably good enough

binhn (Thu, 07 Sep 2017 17:35:20 GMT):
i forgot to copy my gerrit private key when i returned my machine; now gerrit doesn't allow me to add a new public key (i deleted the old one); I keep getting 500. The instruction here seems straight forward https://gerrit.hyperledger.org/r/Documentation/user-upload.html#configure_ssh. Does anyone know of any other pre-reqs?

greg.haskins (Thu, 07 Sep 2017 17:44:36 GMT):
@binhn my guess is the problem is on the client side...check (using something like "ssh -vvv" that you are presenting the key that you installed on the server

greg.haskins (Thu, 07 Sep 2017 17:44:50 GMT):
if not, check your ~/.ssh/config

binhn (Thu, 07 Sep 2017 17:55:52 GMT):
i wasn't there yet; trying to upload my public key to gerrit https://gerrit.hyperledger.org/r/#/settings/ssh-keys and get 500

binhn (Thu, 07 Sep 2017 17:56:01 GMT):
from the gerrit UI

greg.haskins (Thu, 07 Sep 2017 18:00:39 GMT):
oh i see

binhn (Thu, 07 Sep 2017 18:36:10 GMT):
@rjones helped figured this out: it only takes rsa1 pub key; i was generating rsa2 key

rjones (Thu, 07 Sep 2017 18:47:50 GMT):
we both learned something :)

binhn (Thu, 07 Sep 2017 19:35:57 GMT):
talking about bft, i know some folks have been working on integrating bft-smart as a sub project -- @vukolic do you have any status?

kostas (Thu, 07 Sep 2017 20:18:15 GMT):
(@vukolic won't be

kostas (Thu, 07 Sep 2017 20:18:15 GMT):
(@vukolic won't be able to respond in the maintainers-only channel)

kostas (Thu, 07 Sep 2017 22:50:42 GMT):
https://chat.hyperledger.org/channel/fabric-consensus?msg=dQR3vGAM5G2jsaDi6

kostas (Fri, 08 Sep 2017 01:40:27 GMT):
I'm not well versed in how our CI works but I'm wondering if there are any speed benefits to be gained by switching to: https://godoc.org/rsc.io/gt

jyellick (Fri, 08 Sep 2017 01:41:44 GMT):
FWIW, in my non-scientific testing, running just `go test` instead of `gocov` takes about 1/5th of the time, so it sounds worth investigating

cbf (Fri, 08 Sep 2017 16:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=DnHwPBeEbsF5aQyaf) @binhn can you please submit a tweak to the docs to make this point? Thanks

cbf (Fri, 08 Sep 2017 16:43:11 GMT):
@here I've noticed that the CR backlog is growing - we have ~230 outstanding CRs

cbf (Fri, 08 Sep 2017 16:44:06 GMT):
each of us should be keeping an eye on this and re-reviewing older CRs and bumping them for progress or asking if the CR can or should be abandoned

cbf (Fri, 08 Sep 2017 16:44:21 GMT):
thanks

mastersingh24 (Fri, 08 Sep 2017 20:21:15 GMT):
`go test` is way faster. The one issue with `go test` is that you cannot use the `cover` flag with multiple packages. But I have to imagine there is a way to aggregate the coverage results for multiple `go test` runs (https://chat.hyperledger.org/channel/fabric-maintainers?msg=TGfx37rkkSqKsXNEx) @jyellick

mastersingh24 (Fri, 08 Sep 2017 20:26:42 GMT):
Apparently, this is quite easy to do ;)

kostas (Fri, 08 Sep 2017 20:29:07 GMT):
Is there a solution that doesn't involve a shell script?

jyellick (Sun, 10 Sep 2017 02:22:54 GMT):
The discussion above reminds me of a couple JIRA issues I had opened a while back: https://jira.hyperledger.org/browse/FAB-5722 https://jira.hyperledger.org/browse/FAB-5723 The former would be nice for local development, while the latter seems like it could seriously improve the performance of CI. Not sure what the effort required to fix these is, but perhaps something we can keep an eye on.

mastersingh24 (Mon, 11 Sep 2017 12:56:48 GMT):
Hello fellow maintainers - RE moving to Go 1.9 -

mastersingh24 (Mon, 11 Sep 2017 12:58:25 GMT):
Would anyone be opposed to sticking with Go 1.7.X for fabric-ca in the 1.1 timeframe? See https://jira.hyperledger.org/browse/FAB-6003 but there's an issue with cfssl and Go 1.9. We can workaround this ourselves and/or submit a fix to cfssl and try to pull it back in if it makes it into cfssl in time for 1.1

mastersingh24 (Mon, 11 Sep 2017 13:40:29 GMT):
https://gerrit.hyperledger.org/r/#/c/13317/ - my stab at the base needed to start using a experimental tag

mastersingh24 (Mon, 11 Sep 2017 15:31:16 GMT):
can someone +2 this one: https://gerrit.hyperledger.org/r/#/c/13289/ ?

mastersingh24 (Mon, 11 Sep 2017 15:31:30 GMT):
Need it to go Z / P images for Go 1.9

jyellick (Mon, 11 Sep 2017 15:31:49 GMT):
Done

jyellick (Mon, 11 Sep 2017 15:31:49 GMT):
Done (though will leave the submit click to you)

mastersingh24 (Mon, 11 Sep 2017 15:36:07 GMT):
Gracias ;)

mastersingh24 (Mon, 11 Sep 2017 15:36:46 GMT):
@jyellick - can you do this one as well: https://gerrit.hyperledger.org/r/#/c/13291/ ? It's the follow up

mastersingh24 (Mon, 11 Sep 2017 15:36:59 GMT):
Else @greg.haskins will get mad at us ;)

jyellick (Mon, 11 Sep 2017 15:37:16 GMT):
And done

mastersingh24 (Mon, 11 Sep 2017 15:37:19 GMT):
Thx

mastersingh24 (Tue, 12 Sep 2017 20:07:09 GMT):
We can disregard this - https://github.com/cloudflare/cfssl/pull/807 ;) (https://chat.hyperledger.org/channel/fabric-maintainers?msg=Ft5z94nSKirMjYX5P)

boliang (Wed, 13 Sep 2017 08:37:57 GMT):
Has joined the channel.

cbf (Wed, 13 Sep 2017 11:43:13 GMT):
@here all, a gentle reminder that the backlog of CRs is our collective responsibility. Each of us should be making a little time to review the backlog and review older CRs to see why they are languishing and review if needed. I've seen too many instances where CRs are being ignored. This is not good for growing a community. Please do what you can to help with the CR backlog when you can.

cbf (Wed, 13 Sep 2017 15:40:15 GMT):
@here as a reminder to maintainers, please close JIRAs when you merge a CR as appropriate

cbf (Wed, 13 Sep 2017 15:40:39 GMT):
there's far too many JIRAs that remain open when the CR has been merged

QwertyJack (Mon, 18 Sep 2017 05:47:07 GMT):
Has joined the channel.

Jacky_Sheng (Wed, 20 Sep 2017 03:21:56 GMT):
Has joined the channel.

leminhy89 (Wed, 20 Sep 2017 10:51:52 GMT):
Has joined the channel.

johnfilippone (Mon, 25 Sep 2017 11:22:56 GMT):
Has joined the channel.

JonathanTan (Thu, 28 Sep 2017 07:11:56 GMT):
Has joined the channel.

kostas (Thu, 28 Sep 2017 10:54:48 GMT):
FAB-5556 is a proposal to drive updates via the capabilities framework.

kostas (Thu, 28 Sep 2017 10:54:56 GMT):
It needs 5 votes before we can start merging the associated changesets.

kostas (Thu, 28 Sep 2017 10:55:04 GMT):
Please have a look and raise objections, if any, in the associated JIRA. (Otherwise vote, so we can move forward.)

muralisr (Thu, 28 Sep 2017 13:51:47 GMT):
@kostas .. voted

cbf (Fri, 29 Sep 2017 15:59:43 GMT):
@kostas now 8 on board, ok to proceed

dave.enyeart (Wed, 04 Oct 2017 21:06:40 GMT):
@here I have posted thoughts on Jira enhancements and 1.1 alpha content over on #fabric-release . Please take a look over there. We can discuss over there or here, depending on the nature of the comments.

dave.enyeart (Fri, 06 Oct 2017 15:02:52 GMT):
@cbf @mastersingh24 Do you think we should create a v1.1-alpha version in Jira? Alternatively we could keep everything at v1.1 and simply have an alpha label for work items targeting alpha. Thoughts?

mastersingh24 (Fri, 06 Oct 2017 15:27:11 GMT):
@dave.enyeart - was pondering this as well. I think creating the version is a good idea (I just created it in JIRA as well). But alpha items should have both v1.1 and v1.1-alpha for fix version(s)

dave.enyeart (Fri, 06 Oct 2017 15:30:19 GMT):
@mastersingh24 thanks, i will tag the features intended for alpha as such

mastersingh24 (Fri, 06 Oct 2017 18:11:57 GMT):
@dave.enyeart - I also have v1.1-experimental as well ;)

mastersingh24 (Fri, 06 Oct 2017 18:12:01 GMT):
covering all bases

dave.enyeart (Fri, 06 Oct 2017 18:25:34 GMT):
@mastersingh24 For experimental, how about we just use a label 'experimental'. That way it could be used across releases, and we wouldn't bloat the versions field. Keep versions limited to releases that we actually cut. What do you think?

mastersingh24 (Fri, 06 Oct 2017 19:33:32 GMT):
@dave.enyeart - sure - because that is what we should moving forward. I liked having it as a release because it's easier to query ;)

mastersingh24 (Fri, 06 Oct 2017 20:11:52 GMT):
@dave.enyeart @cbf I'm working on a JIRA to suggest a branching strategy (nothing earth-shattering) but one thing that dawned on me is that we can basically avoid our current situation by NOT merging features which are not in the current release plan. It's fine for people to submit CRs for features / improvements that are not targetted for the release currently under development, but those features should not be merged. Of course features can be added to the plan provided we get enough votes and the quality of the code. And in terms of making something experimental, we can make those decisions once we get towards cutting an alpha or beta - meaning we don't declare a feature as experimental up front. This decision would be made for features that were planned but are not ready and possibly for some outstanding CRs that might be far enough along

JonathanLevi (Fri, 06 Oct 2017 20:24:16 GMT):
My main concern is that it's not *earth-shuttering* ;-)

mastersingh24 (Fri, 06 Oct 2017 20:26:29 GMT):
hehe - well-played. Don't worry - it will be very nice @JonathanLevi

cbf (Mon, 09 Oct 2017 13:52:54 GMT):
interesting approach...

yacovm (Wed, 11 Oct 2017 11:30:29 GMT):
I think that the e2e in CI is failing: https://jenkins.hyperledger.org/job/fabric-verify-end-2-end-x86_64/9447/console

yacovm (Wed, 11 Oct 2017 11:31:06 GMT):
this change set: https://gerrit.hyperledger.org/r/#/c/14415/ doesn't do anything - just adding a blank like

yacovm (Wed, 11 Oct 2017 11:31:11 GMT):
and e2e fails in CI...

yacovm (Wed, 11 Oct 2017 11:32:10 GMT):
the problem seems focused in the fabric-CA java SDK client : `at org.hyperledger.fabric_ca.sdk.HFCAClient.register(HFCAClient.java:243)`

yacovm (Wed, 11 Oct 2017 11:32:10 GMT):
the problem seems focused in the fabric-CA java SDK client : `at org.hyperledger.fabric_ca.sdk.HFCAClient.register(HFCAClient.java:243)` ``` {"name":"hf.revoker","value":"true"}]} with status code: 401. Response: {"success":false,"result":null,"errors":[{"code":43,"message":"Registrar does not have any values for 'hf.Registrar.Attributes' thus can't register any attributes"}],"messages":[]} 10:41:10 10:41:10 at org.hyperledger.fabric_ca.sdk.HFCAClient.register(HFCAClient.java:243) 10:41:10 at org.hyperledger.fabric_ca.sdkintegration.HFCAClientIT.testUserRevoke(HFCAClientIT.java:305)

C0rWin (Wed, 11 Oct 2017 11:34:23 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-java?msg=GxHxY975Yem5vpHi2

C0rWin (Wed, 11 Oct 2017 11:34:36 GMT):
seems that Angelo also facing same problem

yacovm (Wed, 11 Oct 2017 11:35:53 GMT):
adc

yacovm (Wed, 11 Oct 2017 11:36:04 GMT):
@adc can you confirm? :)

yacovm (Wed, 11 Oct 2017 11:36:45 GMT):
I suggest we talk it over in the scrum and if we can't resolve, we skip the java SDK test in the e2e

adc (Wed, 11 Oct 2017 11:44:18 GMT):
Yes, confirmed

yacovm (Wed, 11 Oct 2017 12:13:45 GMT):
adc

mastersingh24 (Wed, 11 Oct 2017 12:33:36 GMT):
So likely merging this https://gerrit.hyperledger.org/r/#/c/13215/ (for fabric-ca) is the root cause here

cbf (Wed, 11 Oct 2017 19:45:03 GMT):
FAB-6590

cbf (Wed, 11 Oct 2017 19:46:07 GMT):
I've added this to review-needed. Design TBD once the Burrow refactor is merged we will start experimenting and develop a more formal proposal and tasks

rajasekharpippalla (Thu, 12 Oct 2017 11:04:11 GMT):
Has joined the channel.

yacovm (Sat, 14 Oct 2017 13:45:17 GMT):
Is it possible to have a plugin that sets the JIRA issue to DONE once a change set that links to it is merged?

dave.enyeart (Sat, 14 Oct 2017 14:42:28 GMT):
My bad, I forgot to hit Done after a couple of merges last night.

dave.enyeart (Sat, 14 Oct 2017 14:43:23 GMT):
Some people do multiple change sets under a Jira. I've been letting it slide. Should we start enforcing one change set per Jira?

yacovm (Sat, 14 Oct 2017 14:51:10 GMT):
I actually wasn't referring to you, i'm just lazy and don't want to do ot myself so i prefer we automate it somehow

jyellick (Sat, 14 Oct 2017 17:25:26 GMT):
+1 to requiring a unique JIRA for every CR

jyellick (Sat, 14 Oct 2017 17:25:40 GMT):
Easy enough to create subtasks

cbf (Wed, 18 Oct 2017 11:55:22 GMT):
agree, and I have actually asked about doing this but have not had a response

cbf (Wed, 18 Oct 2017 11:55:47 GMT):
we are also trying to get a JIRA expert to help us configure it better

cbf (Wed, 18 Oct 2017 14:18:41 GMT):
https://jira.hyperledger.org/browse/FAB-6590 could use some votes please... I'd like to create a repo to begin work on this integration, thanks

dave.enyeart (Wed, 18 Oct 2017 14:44:12 GMT):
@cbf You have trained me too well - previously you have suggested that we are chasing too many things and need to focus on closing down 1.1 and other tech debt (that will likely go beyond 1.1 already). We don't even have votes for most of the things that are 'in plan' for 1.1 based on https://wiki.hyperledger.org/projects/fabric/proposedv1_1. Therefore I am generally not voting for additional new items, unless you can convince us it is higher priority than current propose plan items.

dave.enyeart (Wed, 18 Oct 2017 14:44:12 GMT):
@cbf You have trained me too well - previously you have suggested that we are chasing too many things and need to focus on closing down 1.1 and other tech debt (that will likely go beyond 1.1 already). I agree. We don't even have votes for most of the things that are 'in plan' for 1.1 based on https://wiki.hyperledger.org/projects/fabric/proposedv1_1. Therefore I am generally not voting for additional new items, unless you can convince us it is higher priority than current propose plan items.

yacovm (Wed, 18 Oct 2017 14:47:53 GMT):
Wait that isn't for v1.1 is it?

dave.enyeart (Wed, 18 Oct 2017 14:48:54 GMT):
No, you can start exploratory work without votes though. Why vote for future things if we don't even have votes for 1.1 things?

dave.enyeart (Wed, 18 Oct 2017 15:01:37 GMT):
Rather than go voting for future things, I'd suggest all maintainers should first go vote for the items in https://wiki.hyperledger.org/projects/fabric/proposedv1_1 that they agree with.

cbf (Wed, 18 Oct 2017 15:02:37 GMT):
@dave.enyeart as for the EVM work, that will begin with my own resources and hopefully others but not before the Burrow work is merged

cbf (Wed, 18 Oct 2017 15:03:36 GMT):
and as for priority - it has visibility in IBM up to Marie and Bob Lord, and outside there is interest from many using Ethereum but wanting permissioned capability

cbf (Wed, 18 Oct 2017 15:04:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=GgKYNvZt8DtDbgs8d) @yacovm nope, more likely 1.2

dave.enyeart (Wed, 18 Oct 2017 15:05:08 GMT):
I think the issue is that we are overloading the Jira voting field. It is used by everyone to suggest "this is a worthwhile feature", and it is used by maintainers to suggest that design is mature enough that merges into master can begin.

dave.enyeart (Wed, 18 Oct 2017 15:05:37 GMT):
I would vote for this one based on the former criteria, but not the latter

cbf (Wed, 18 Oct 2017 15:05:49 GMT):
when we plan for 1.2, we will definitely need a better vehicle

cbf (Wed, 18 Oct 2017 15:06:23 GMT):
voting should be +1/-1 not just +1

cbf (Wed, 18 Oct 2017 15:07:00 GMT):
note that LF is authorized to hire a JIRA expert/consultant to help us configure better

cbf (Wed, 18 Oct 2017 19:47:34 GMT):
@here https://wiki.hyperledger.org/groups/tsc/project-updates/fabric-2017-oct

cbf (Wed, 18 Oct 2017 19:48:04 GMT):
please feel free to edit with any changes as you see fit... I will present our project status at the TSC call this week.

mastersingh24 (Thu, 19 Oct 2017 17:06:23 GMT):
While we can make some changes to JIRA to better meet our workflow / needs, JIRA is not really our problem ;)

mastersingh24 (Thu, 19 Oct 2017 17:06:42 GMT):
Maybe just once, we can properly scope and plan a release ;)

mastersingh24 (Thu, 19 Oct 2017 17:07:18 GMT):
We still need to do some major cleanup in JIRA as well

cbf (Fri, 20 Oct 2017 15:56:40 GMT):
https://gerrit.hyperledger.org/r/c/14737/

cbf (Fri, 20 Oct 2017 15:56:56 GMT):
propose retiring Tamas, Gabor and Sheehan from maintainers

cbf (Fri, 20 Oct 2017 15:57:25 GMT):
please vote with +1 until we have more than half voting

cbf (Fri, 20 Oct 2017 20:27:26 GMT):
@here I need 4 more on 14737 above, please

muralisr (Fri, 20 Oct 2017 20:29:07 GMT):
@cbf hesitate removing maintainers but as it says we can always add back after contribution, I'll go ahead and +1

cbf (Fri, 20 Oct 2017 21:57:43 GMT):
per @binhn comments https://gerrit.hyperledger.org/r/14747 Update maintainer policy

cbf (Fri, 20 Oct 2017 21:58:14 GMT):
clarified that a maintainer can be removed for prolonged inactivity and restored after a month of renewed commitment and contribution/reviews

cbf (Fri, 20 Oct 2017 21:58:59 GMT):
@here I'd like to see majority maintainers approve this change as well since it affects the policy

JonathanLevi (Fri, 20 Oct 2017 22:00:00 GMT):
Very well-worded @binhn and @cbf !

binhn (Fri, 20 Oct 2017 22:00:35 GMT):
awesome, thanks !

JonathanLevi (Fri, 20 Oct 2017 22:01:15 GMT):
No more 3 or four 3-month long vacations in a row for me... eh?

dave.enyeart (Wed, 25 Oct 2017 11:58:49 GMT):
@here I've posted intent for a 1.1 'preview' release over in #fabric-release

dave.enyeart (Wed, 25 Oct 2017 11:59:10 GMT):
Please check it out, and provide any further thoughts over there or here.

dave.enyeart (Wed, 25 Oct 2017 11:59:43 GMT):
Please reply if there are any concerns with moving forward, as early as next week.

dave.enyeart (Wed, 25 Oct 2017 11:59:43 GMT):
Please reply asap if there are any concerns with moving forward, as early as next week.

dave.enyeart (Wed, 25 Oct 2017 14:32:50 GMT):
I've created https://jira.hyperledger.org/browse/FAB-6753 as the work item to actually cut the v1.1 preview release

dave.enyeart (Wed, 25 Oct 2017 14:34:05 GMT):
@cbf agreed to drive the release cutting levers again. Certain parts of release cutting remains a mystery to me, I think we should use the preview as an exercise to fully document the steps. Last release I recommended a google doc for the actual step-by-step instructions (some of the instructions have been in jira items in the past, but it is tedious to copy/paste for each release). I'm open to ideas though.

JonathanLevi (Thu, 26 Oct 2017 02:17:49 GMT):
Hello fellow maintainers, Regarding retiring maintainers (https://gerrit.hyperledger.org/r/#/c/14737/) - (how) would you suggest we can help/address Sheehan's comments/points/asks ? I made 2 suggestions quickly, but maybe there are other options/views ? Thanks, J

cbf (Fri, 27 Oct 2017 20:01:13 GMT):
@sheehan @JonathanLevi point well taken... the policy change was actually driven by the thought to clean up the maintainers because there had been prolonged inactivity... I am happy to learn that you are interested in resuming contributions... as for the idea of keeping a list of contributors and not just sending them down the memory hole

cbf (Fri, 27 Oct 2017 20:02:13 GMT):
I am supportive of this

cbf (Fri, 27 Oct 2017 20:02:35 GMT):
we could have two sections of the maintainers file... current and retired

cbf (Fri, 27 Oct 2017 20:03:35 GMT):
given that you have intent of resuming, I'm more than willing to leave you on for now

cbf (Fri, 27 Oct 2017 20:13:31 GMT):
I've pushed a new CR https://gerrit.hyperledger.org/r/#/c/14737

sheehan (Fri, 27 Oct 2017 22:01:03 GMT):
Thanks, I like the format. Will help to show that contribution has come from multiple sources.

dave.enyeart (Sat, 28 Oct 2017 14:38:30 GMT):
@sheehan We have missed you and would love to keep you in the maintainer list! If you contribute again (e.g. review some CRs for starters) I think there would be widespread support for cbf's latest CR.

sheehan (Mon, 30 Oct 2017 03:05:16 GMT):
Thanks Dave. I plan to resume more regular contributions soon, but over the next few weeks I'll find some CRs to look over.

dave.enyeart (Tue, 31 Oct 2017 17:13:50 GMT):
@here I think we have all code needed in master for `1.1.0-preview`. Just some final docs and fabric-sample to come in later today. Therefore I think we can start the `1.1.0-preview` release testing activities. Here's the schedule I propose:

dave.enyeart (Tue, 31 Oct 2017 17:13:54 GMT):
tuesday pm - code freeze in master, trigger build and run test suites against latest HEAD on master wednesday am - confirm test results. if good, cut 1.1.0-preview release and push images/binaries wednesday pm - pull down images/binaries and verify

dave.enyeart (Tue, 31 Oct 2017 17:14:28 GMT):
I've confirmed with @scottz and @rameshthoomu

scottz (Tue, 31 Oct 2017 17:14:28 GMT):
Has joined the channel.

dave.enyeart (Tue, 31 Oct 2017 17:14:44 GMT):
Any concerns or final merges before code freeze is announced?

JonathanLevi (Tue, 31 Oct 2017 17:47:53 GMT):
Where is the list of the features that are a *must* for 1.1 ?

JonathanLevi (Tue, 31 Oct 2017 17:49:41 GMT):
There are many pending CRs that we should merge for the 1.1-preview (like Gari's mutual TLS)... but let's prioritize what's a real "must"

dave.enyeart (Tue, 31 Oct 2017 17:50:16 GMT):
The 1.1 features are here: https://wiki.hyperledger.org/projects/fabric/proposedv1_1

dave.enyeart (Tue, 31 Oct 2017 17:50:16 GMT):
The 1.1 features are here: https://wiki.hyperledger.org/projects/fabric/proposedv1_1 and in the dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104

JonathanLevi (Tue, 31 Oct 2017 17:50:20 GMT):
Tuesday pm == today?

dave.enyeart (Tue, 31 Oct 2017 17:50:41 GMT):
The first 6 bullets are done and will be highlighted for 1.1.0-preview

dave.enyeart (Tue, 31 Oct 2017 17:51:19 GMT):
they are also the 6 blocking features in the 1.1.0-preview work item: https://jira.hyperledger.org/browse/FAB-6753

dave.enyeart (Tue, 31 Oct 2017 17:52:30 GMT):
today yes... we've been working the last couple weeks to verify the content for these 6

JonathanLevi (Tue, 31 Oct 2017 17:53:07 GMT):

This is what JIRA shows

dave.enyeart (Tue, 31 Oct 2017 17:53:50 GMT):
`preview` means not yet complete, but some features we'd like to highlight and get feedback on are ready enough

dave.enyeart (Tue, 31 Oct 2017 17:53:50 GMT):
`preview` means not yet feature complete, but some features we'd like to highlight and get feedback on are ready enough

JonathanLevi (Tue, 31 Oct 2017 17:54:02 GMT):
15 In progress, 47 Todo, 11 In Review

JonathanLevi (Tue, 31 Oct 2017 17:54:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=QAsz8XaSTHJ3X2kzd) OK, that's what I asked

dave.enyeart (Tue, 31 Oct 2017 17:54:51 GMT):
this is what we've been talking about in #fabric-scrum and #fabric-release the last few weeks

JonathanLevi (Tue, 31 Oct 2017 17:55:03 GMT):
Do we have a list of what we think is *ready enough* for the preview?

dave.enyeart (Tue, 31 Oct 2017 17:55:36 GMT):
it is the 6 features listed as blocking in the jira work item: https://jira.hyperledger.org/browse/FAB-6753

dave.enyeart (Tue, 31 Oct 2017 17:55:57 GMT):
which equals the first 6 bullets here: https://wiki.hyperledger.org/projects/fabric/proposedv1_1

JonathanLevi (Tue, 31 Oct 2017 17:56:48 GMT):
OK. We should try to have this stuff in a more dynamic form in JIRA... I can try to work on it.

JonathanLevi (Tue, 31 Oct 2017 17:56:56 GMT):
Something like this: https://jira.hyperledger.org/browse/FAB-6821?jql=project%20%3D%20FAB%20AND%20fixVersion%20%3D%20v1.1.0-preview

dave.enyeart (Tue, 31 Oct 2017 18:00:32 GMT):
we can also query jira for fix version v1.1.0-preview. these 6 features are tagged as such.

JonathanLevi (Tue, 31 Oct 2017 18:00:46 GMT):
That's the URL I put above

JonathanLevi (Tue, 31 Oct 2017 18:00:59 GMT):
It was a query on the Fix Version

dave.enyeart (Tue, 31 Oct 2017 18:01:28 GMT):
that link takes me to one sub-task only

JonathanLevi (Tue, 31 Oct 2017 18:02:15 GMT):
That's the problem

JonathanLevi (Tue, 31 Oct 2017 18:02:34 GMT):
Anyway... let's confirm that this is a *preview* and not an *alpha*

JonathanLevi (Tue, 31 Oct 2017 18:02:54 GMT):
I have no objections - as long as we don't presume that the API is locked.

JonathanLevi (Tue, 31 Oct 2017 18:03:23 GMT):
I take it that this is mainly for getting the testings cycle kicking in, the Composer in synch with the HEAD of Fabric, etc.

JonathanLevi (Tue, 31 Oct 2017 18:03:46 GMT):
I think the HEAD will need some more work before we can "conclude" the 1.1 release.

dave.enyeart (Tue, 31 Oct 2017 18:05:24 GMT):
indeed, this is a `preview` without features/APIs locked, rather than the fully baked `alpha`, as defined here: https://wiki.hyperledger.org/community/release_taxonomy

JonathanLevi (Tue, 31 Oct 2017 18:05:41 GMT):
Super. Thank you @dave.enyeart - no objections here.

JonathanLevi (Tue, 31 Oct 2017 18:06:01 GMT):
I'd still like to merge a few more CRs when the build is complete.

JonathanLevi (Tue, 31 Oct 2017 18:06:18 GMT):
Timezone wise, can we do 5pm ET ?

dave.enyeart (Tue, 31 Oct 2017 18:06:36 GMT):
essentially, there were some 'long pole' features holding up 1.1, but we wanted to get something out there for people to try out the important features that are ready enough

dave.enyeart (Tue, 31 Oct 2017 18:07:21 GMT):
you mean, you want to merge a few more things before preview. i'm fine with waiting until 5pm if so.

JonathanLevi (Tue, 31 Oct 2017 18:09:00 GMT):
Yes, please. Let's wait until 5pm please.

dave.enyeart (Tue, 31 Oct 2017 18:09:13 GMT):
sure thing. Code freeze starts at 5pm ET

JonathanLevi (Tue, 31 Oct 2017 18:09:20 GMT):
I didn't realize this is scheduled for today. Thanks.

dave.enyeart (Tue, 31 Oct 2017 18:09:30 GMT):
At that time the build and nightly tests will be kicked off.

dave.enyeart (Tue, 31 Oct 2017 18:10:09 GMT):
we don't expect the freeze to last longer than 24 hours, that's why we weren't making a lot of noise about it

JonathanLevi (Tue, 31 Oct 2017 18:16:27 GMT):
Understood. Fair enough. Let me try to squeeze in some stuff. May finish sooner.

JonathanLevi (Tue, 31 Oct 2017 18:31:46 GMT):
Guys, mind taking a look at this?

JonathanLevi (Tue, 31 Oct 2017 18:31:46 GMT):
https://gerrit.hyperledger.org/r/#/c/14949/

mastersingh24 (Tue, 31 Oct 2017 19:39:54 GMT):
I mind but I'll do it

jyellick (Tue, 31 Oct 2017 21:01:35 GMT):
@dave.enyeart Looks like master is broken

jyellick (Tue, 31 Oct 2017 21:01:35 GMT):
@dave.enyeart Looks like master is broken -- I believe https://gerrit.hyperledger.org/r/#/c/15035 will fix it

jyellick (Tue, 31 Oct 2017 21:01:38 GMT):
I believe https://gerrit.hyperledger.org/r/#/c/15035/ will fix it

JonathanLevi (Tue, 31 Oct 2017 21:03:21 GMT):
Yup, let's hold off the code freeze... unless it's for getting the master building.

JonathanLevi (Tue, 31 Oct 2017 21:04:07 GMT):
We have merged way too much/too fast over the last few hours... but these hard-coded versioning of `MSPv1_1` is really key.

JonathanLevi (Tue, 31 Oct 2017 21:05:00 GMT):
p.s. Other than Jason's fix, I'm done with the "merging-spree"

dave.enyeart (Tue, 31 Oct 2017 21:08:16 GMT):
agreed, let's see if jyellick's fix works

dave.enyeart (Tue, 31 Oct 2017 21:08:16 GMT):
agreed, let's see if @jyellick 's fix works

JonathanLevi (Tue, 31 Oct 2017 23:46:06 GMT):
Have just merged it. I think we are good to go with the freeze @dave.enyeart

realhuyi (Wed, 01 Nov 2017 04:38:34 GMT):
Has joined the channel.

nhrishi (Wed, 01 Nov 2017 12:45:21 GMT):
Has joined the channel.

dave.enyeart (Wed, 01 Nov 2017 13:45:40 GMT):
@here Just to confirm that we are in merge freeze today while @cbf and I cut release.

dave.enyeart (Wed, 01 Nov 2017 13:45:40 GMT):
@here Just to confirm that we are in merge freeze today while @cbf and I cut 1.1.0-preview release.

cbf (Wed, 01 Nov 2017 13:46:21 GMT):
what about 1.0.4?

cbf (Wed, 01 Nov 2017 13:46:35 GMT):
the one cross-over is the release notes

cbf (Wed, 01 Nov 2017 13:48:51 GMT):
actually, I can just add the notes, nvm

aso (Wed, 01 Nov 2017 17:18:40 GMT):
Has left the channel.

dave.enyeart (Thu, 02 Nov 2017 01:05:17 GMT):
--- Hyperledger Fabric v1.1.0-preview has been announced ---

dave.enyeart (Thu, 02 Nov 2017 01:05:17 GMT):
@here Hyperledger Fabric v1.1.0-preview has been announced

dave.enyeart (Thu, 02 Nov 2017 01:06:01 GMT):
https://lists.hyperledger.org/pipermail/hyperledger-fabric/2017-November/002036.html

dave.enyeart (Thu, 02 Nov 2017 01:06:08 GMT):
MERGE FREEZE OVER

dave.enyeart (Thu, 02 Nov 2017 01:06:28 GMT):
Resume awesomeness

MoulaliMvg (Thu, 02 Nov 2017 04:42:37 GMT):
Has joined the channel.

jyellick (Tue, 07 Nov 2017 19:23:46 GMT):
With the discussions around the non-chaincode interfaces that exist for the peer, it was brought up that the new channel event service and the deliver service are quite similar. After some discussions with Will, it seems clear that the new channel event service could be rerworked on top of the Deliver API, with some significant additional benefits beyond the code reuse, such as the ability for a client to reconnect at a point in time to the event service, to not worry about 'missing' events. Will wrote it up here and added the review-needed tag. https://jira.hyperledger.org/browse/FAB-6911 would appreciate it if other maintainers could take a look.

wlahti (Tue, 07 Nov 2017 21:51:10 GMT):
Has joined the channel.

Umar12 (Wed, 08 Nov 2017 08:36:45 GMT):
Has joined the channel.

dave.enyeart (Wed, 08 Nov 2017 16:53:13 GMT):
@here Since the policy has been clarified at http://hyperledger-fabric.readthedocs.io/en/master/CONTRIBUTING.html#becoming-a-maintainer, and since Sheehan has resumed contribution, I think we can again review and vote for retiring the dormant maintainers: https://gerrit.hyperledger.org/r/#/c/14737/

JonathanLevi (Thu, 09 Nov 2017 14:05:51 GMT):
Hi guys, operation "static text file update" is complete.

JonathanLevi (Thu, 09 Nov 2017 14:06:18 GMT):
I have just merged the latest change (with a majority of 11/15 > 2/3, which is much more than a simple majority)

JonathanLevi (Thu, 09 Nov 2017 14:07:47 GMT):
I think we all need to be a bit more pragmatic these days. I don't mind hoping on a call here and there if needed... but, for instance, in Sheehan's case - we can all simply re-evaluate and welcome him back if we/you believe in his work/ability/contribution.

JonathanLevi (Thu, 09 Nov 2017 14:09:10 GMT):
I can tell you that I do (believe in Sheehan's work/ability/contribution). But we should not really spend days/nights/weeks discussing such matters... trying walk around the matter without insulting any one.

JonathanLevi (Thu, 09 Nov 2017 14:10:00 GMT):
I can tell you that I do (believe in Sheehan's work/ability/contribution). But we should not really spend days/nights/weeks discussing such matters... trying to walk around the matter without potentially insulting any one.

JonathanLevi (Thu, 09 Nov 2017 14:10:21 GMT):
We don't have to agree on everything, all the time.

JonathanLevi (Thu, 09 Nov 2017 14:10:24 GMT):
That's OK.

SharedMocha (Fri, 10 Nov 2017 20:39:50 GMT):
Has joined the channel.

cbf (Wed, 15 Nov 2017 18:25:31 GMT):
need a couple more votes on this please https://jira.hyperledger.org/browse/FAB-6590

kostas (Thu, 16 Nov 2017 16:10:48 GMT):
Heads up that moving Idemix to v1.1 has been added to the `review-needed` basket: https://jira.hyperledger.org/browse/FAB-7000

cbf (Thu, 16 Nov 2017 20:33:21 GMT):
https://jira.hyperledger.org/browse/FAB-6590 needs one more vote please

dave.enyeart (Thu, 16 Nov 2017 21:29:14 GMT):
I've added review-needed to the rest of the Epics/Features that are tagged as 1.1-release-planning.

dave.enyeart (Thu, 16 Nov 2017 21:31:12 GMT):
Full list can be seen here: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104#Filter-Results/10517

cbf (Fri, 17 Nov 2017 22:30:12 GMT):
@here a thought - there are an increasing number of questions coming in via many different channels, people wanting to learn more about Fabric and the work we're doing here

cbf (Fri, 17 Nov 2017 22:31:48 GMT):
an idea was floated that maybe we could have an "Everything you ever wanted to know about Fabric but were afraid to ask" Google Hangout that we could then post on Youtube for posterity

cbf (Fri, 17 Nov 2017 22:32:05 GMT):
we'd announce on the mailing list and chat etc, maybe even a blog post

cbf (Fri, 17 Nov 2017 22:32:30 GMT):
invite the world to come "meet the maintainers" and ask away

cbf (Fri, 17 Nov 2017 22:32:32 GMT):
thoughts?

cbf (Fri, 17 Nov 2017 22:32:37 GMT):
crazy idea?

rjones (Fri, 17 Nov 2017 22:34:19 GMT):
How about regular office hours with the same format, following that event? it could be staffed by maintainers in advantageous time zones so people can get information at a good time.

cbf (Fri, 17 Nov 2017 22:35:04 GMT):
also not a bad idea

yacovm (Sat, 18 Nov 2017 08:33:36 GMT):
@cbf I think that a better idea should be not a hangout but rather something that can be efficiently consumed later on like a reddit Ask-Me-Anything thread. While a video conference might be a good idea to those who attend it, I think its knowledge would not ripple effectively to lots of people

yacovm (Sat, 18 Nov 2017 08:37:05 GMT):
@rjones I think that maintainers already do that during their work, but though rocket.chat indexes stuff, people don't use the search. I wish we could have some AI with NLP capabilities that processes rocket chat and then links to answers from maintainers if a question that has already been answered is asked.

C0rWin (Sat, 18 Nov 2017 11:08:25 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yYZxWn5JytoZHk2xh) @yacovm we can open such thread on quora

yacovm (Sat, 18 Nov 2017 11:08:42 GMT):
sounds good

dave.enyeart (Sun, 19 Nov 2017 15:31:44 GMT):
I agree with @yacovm that live/recorded sessions will be of limited long term value. The questions will be hit and miss, and the answers won't easily be found later. Fabric readthedocs should be improved to have most of the answers rather than having information scattered around. For the most common questions, I think a FAQ page in Fabric readthedocs would be valuable, with pointers back to readthedocs content to the degree possible. We can look through rocket.chat, stackoverflow, and mailing list for common questions to add to docs and FAQ. The investment in docs has been insufficient to date. I think we'll need an overall editor to drive this effort, that can coordinate pulling together the common questions and answers from various maintainers and other community members.

cbf (Mon, 20 Nov 2017 17:05:47 GMT):
@greg.haskins @mastersingh24 https://jira.hyperledger.org/browse/FAB-7045 thoughts?

greg.haskins (Mon, 20 Nov 2017 17:06:40 GMT):
I was thinking perhaps fabric-thirdparty repo or something like that

greg.haskins (Mon, 20 Nov 2017 17:06:53 GMT):
but in the end, the main thing is getting it out of fabric.git fastpath

mastersingh24 (Mon, 20 Nov 2017 17:51:25 GMT):
Couldn't we add them to the fabric-baseimage repo and/or rename the fabric-baseimage repo? It would make sense to build new images when we update baseimage / baseos in any case

mastersingh24 (Mon, 20 Nov 2017 17:51:46 GMT):
But I'm fine with a new repo as well

kostas (Mon, 20 Nov 2017 17:52:32 GMT):
For my edification, what is a "fastpath"?

greg.haskins (Mon, 20 Nov 2017 17:57:34 GMT):
@kostas general term for anything where performance may matter

greg.haskins (Mon, 20 Nov 2017 17:57:45 GMT):
in this case, build/ci performance

kostas (Mon, 20 Nov 2017 17:57:52 GMT):
Got it.

greg.haskins (Mon, 20 Nov 2017 17:58:48 GMT):
@mastersingh24 yeah, i can see the argument both ways

mastersingh24 (Mon, 20 Nov 2017 17:59:09 GMT):
I go with someone pick smething ;)

mastersingh24 (Mon, 20 Nov 2017 17:59:09 GMT):
I go with someone pick something ;)

greg.haskins (Mon, 20 Nov 2017 17:59:46 GMT):
generally speaking, it would be "nice" if each target had its own release stream..but since kafka et. al. deps on baseimage, I can also see the arguement that they all get spun together

mastersingh24 (Mon, 20 Nov 2017 17:59:46 GMT):
I nominate @greg.haskins to decide ;)

greg.haskins (Mon, 20 Nov 2017 18:00:19 GMT):
im fine with baseimage.git

muralisr (Mon, 20 Nov 2017 18:35:21 GMT):
dumb q likely @greg.haskins @mastersingh24 ... so version changes in these components can be managed easily with this bundling ?

mastersingh24 (Mon, 20 Nov 2017 18:36:40 GMT):
@muralisr - not sure what you mean? Version changes for the 3rd party component (e.g. Kafka, ZK, CouchDB) or versioning for the images themselves?

muralisr (Mon, 20 Nov 2017 18:37:01 GMT):
the 3rd party components

muralisr (Mon, 20 Nov 2017 18:37:46 GMT):
basically if I',m building them separately sounded we "leave it to the user" but now we have to manage it in the baseimage build ?

muralisr (Mon, 20 Nov 2017 18:37:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=NawGhfJNXekLEWRa2) @muralisr I might have missed a nuance of your question before

mastersingh24 (Mon, 20 Nov 2017 18:37:52 GMT):
We don't update the version of the 3rd party component very often so now we'll only push new versions of the images if we decide to change the version of the 3rd party or make some change to the build

muralisr (Mon, 20 Nov 2017 18:41:31 GMT):
Ok....this might actually make it easier to manage version dependencies as it brings it under build ...?

cbf (Mon, 20 Nov 2017 19:37:25 GMT):
ok, I

cbf (Mon, 20 Nov 2017 19:37:37 GMT):
will submit a CR to baseimage to add them

greg.haskins (Mon, 20 Nov 2017 19:56:08 GMT):
my opinion is this makes it easier on the user, not harder

greg.haskins (Mon, 20 Nov 2017 19:56:18 GMT):
one less thing to be built locally

greg.haskins (Tue, 21 Nov 2017 02:35:51 GMT):
@muralisr The way I would advise this to be handled is basically we take the upstream version coupled with our own and push that to dockerhub

greg.haskins (Tue, 21 Nov 2017 02:36:28 GMT):
e.g. $upstream-$ours

greg.haskins (Tue, 21 Nov 2017 02:36:56 GMT):
for zookeeper v3.4.11, it would be something like hyperledger/fabric-zookeeper:v3.4.11-1

greg.haskins (Tue, 21 Nov 2017 02:37:01 GMT):
-2 , -3, etc

greg.haskins (Tue, 21 Nov 2017 02:37:17 GMT):
im ignoring $arch for now

mastersingh24 (Tue, 21 Nov 2017 08:40:19 GMT):
Folks - please check out this JIRA - https://jira.hyperledger.org/browse/FAB-6974 I think this is something we should put in v1.1 as I believe it will help a ton with one of our biggest issues which is getting chaincode containers to communicate with the peer.

muralisr (Tue, 21 Nov 2017 13:19:04 GMT):
@mastersingh24 right, I think its a good thing to do too. Just need to dig into the details and comment

cbf (Tue, 21 Nov 2017 15:02:39 GMT):
I added review needed so please vote if you agree it should be included

jimthematrix (Wed, 22 Nov 2017 03:33:51 GMT):
can I request a vote on this https://gerrit.hyperledger.org/r/#/c/15647 that proposes changing the maintainers list for fabric-sdk-node?

mastersingh24 (Wed, 22 Nov 2017 11:45:00 GMT):
@jimthematrix - Of course you can request the vote. Whether or not anyone votes is a different question ;)

jimthematrix (Wed, 22 Nov 2017 13:41:42 GMT):
@mastersingh24 :joy:

jimthematrix (Wed, 22 Nov 2017 13:41:43 GMT):
@JonathanLevi @yacovm just addressed both your feedbacks (thanks for chiming in!)

jimthematrix (Wed, 22 Nov 2017 13:44:19 GMT):
thanks Jonathan for your interest, I have added you to the list. If other maintainers (eg. Keith) have such interest and believe they will be able to dedicate time for this repository, please also let me know

cbf (Wed, 22 Nov 2017 14:05:34 GMT):
I suggest we treat this as we do the main fabric maintainers list and have 50+% of maintainers agree to this change

cbf (Wed, 22 Nov 2017 14:05:42 GMT):
I added my +1

dave.enyeart (Wed, 22 Nov 2017 15:45:39 GMT):
@jimthematrix I discussed with Keith and he confirmed his interest in being more active as a node.js sdk maintainer.

jimthematrix (Wed, 22 Nov 2017 15:50:18 GMT):
@dave.enyeart done (and thanks for the suggestion)

jimthematrix (Wed, 22 Nov 2017 15:50:32 GMT):
every can you please vote again for the latest patch: https://gerrit.hyperledger.org/r/#/c/15647/

jimthematrix (Wed, 22 Nov 2017 15:50:32 GMT):
everyone can you please vote again for the latest patch: https://gerrit.hyperledger.org/r/#/c/15647/

jackeyliliang (Fri, 24 Nov 2017 02:59:34 GMT):
Has joined the channel.

baoyangc (Sun, 26 Nov 2017 16:40:57 GMT):
Has joined the channel.

binhn (Mon, 27 Nov 2017 23:39:55 GMT):
@here, I might be wrong here, but I don't think we have a documented voting requirement on changes that impact the external usage of Fabric (eg API, programming model, deployment model). I’d like to bring it up here to be discussed and agreed on so that we can document. I propose that we follow the distributed consensus by having more than 2/3 of maintainers voted for if there’re some voted against; otherwise, more than 1/3 is sufficient. I think the current Jira voting used for release risk mitigation is not strong enough for this purpose. I appreciate any thoughts.

yacovm (Mon, 27 Nov 2017 23:47:42 GMT):
2/3 is used for BFT. We don't have byzantine maintainers, do we? :thinking: I think that more than 50% that voted *for* is enough regardless of how many abstained or voted against. Otherwise, since we have some maintainers that are inactive - this would impact liveness.

yacovm (Mon, 27 Nov 2017 23:49:34 GMT):
( i guess we can vote on how much is needed to vote)

binhn (Mon, 27 Nov 2017 23:52:28 GMT):
We can certainly email and request maintainers to vote with a deadline -- similar to TCS

yacovm (Mon, 27 Nov 2017 23:52:38 GMT):
and if they time out? what do we do?

binhn (Mon, 27 Nov 2017 23:53:42 GMT):
we would eliminate those who didn't vote (dynamic quorum :-)

yacovm (Mon, 27 Nov 2017 23:54:03 GMT):
eliminate?

yacovm (Mon, 27 Nov 2017 23:55:00 GMT):
Anyway, my take is that 2/3 is not feasible with the current list.

binhn (Mon, 27 Nov 2017 23:55:52 GMT):
currently we have 15 maintainers, and i think everyone is quite active

C0rWin (Mon, 27 Nov 2017 23:56:35 GMT):
well, I think we need to start to define the notion of changes which impacts external API

C0rWin (Mon, 27 Nov 2017 23:57:08 GMT):
doesn't this counts fixes which take care of critical security issues?

yacovm (Mon, 27 Nov 2017 23:57:11 GMT):
oh, right - we don't have 18 anymore

C0rWin (Mon, 27 Nov 2017 23:57:41 GMT):
external API, external to whom? end users? the SDK developers? who?

binhn (Mon, 27 Nov 2017 23:58:41 GMT):
as i mentioned on my write up: 3 things in my mind 1)api, 2) programming model 3) deployment model

binhn (Mon, 27 Nov 2017 23:58:56 GMT):
there might be more that we need to be careful about

C0rWin (Mon, 27 Nov 2017 23:59:20 GMT):
we have peer API used by SDK, we have SDK API and I think we have to distinguish between those two

yacovm (Mon, 27 Nov 2017 23:59:42 GMT):
right ^

C0rWin (Mon, 27 Nov 2017 23:59:43 GMT):
also what about critical issues which we have to take care?

yacovm (Mon, 27 Nov 2017 23:59:50 GMT):
I think that the API between the peer and the SDK doesn't count

yacovm (Mon, 27 Nov 2017 23:59:56 GMT):
only the API that the user sees

yacovm (Mon, 27 Nov 2017 23:59:56 GMT):
only the API that the user sees counts

C0rWin (Mon, 27 Nov 2017 23:59:58 GMT):
I'd agree

yacovm (Tue, 28 Nov 2017 00:01:07 GMT):
So @binhn I'm still personally not sure about the 2/3. what is your argument against 50% that voted for?

C0rWin (Tue, 28 Nov 2017 00:02:14 GMT):
as long as SDK API remains in same and no changes for Fabric users which develops applications on top of Fabric and those changes could be encapsulated within SDK, I won't consider them as breaking changes

C0rWin (Tue, 28 Nov 2017 00:02:20 GMT):
and we need to clearly specify it

C0rWin (Tue, 28 Nov 2017 00:02:26 GMT):
also not sure about the 60%

binhn (Tue, 28 Nov 2017 00:02:50 GMT):
50% is too easy for collusion

yacovm (Tue, 28 Nov 2017 00:03:01 GMT):
what do you mean?

binhn (Tue, 28 Nov 2017 00:04:05 GMT):
the same way that distributed consensus has proved

yacovm (Tue, 28 Nov 2017 00:05:03 GMT):
I must say I don't follow.

yacovm (Tue, 28 Nov 2017 00:06:04 GMT):
in the byzantine generals problem you can send conflicting votes but in JIRA you can't do that

C0rWin (Tue, 28 Nov 2017 00:06:25 GMT):
in distributed consensus w/ no adversaries, 50%+ is enough to collude on agreement, I'd believe we don't have an adversary maintainer

binhn (Tue, 28 Nov 2017 00:08:28 GMT):
human invents byzantine; it's our nature

binhn (Tue, 28 Nov 2017 00:08:35 GMT):
:-)

C0rWin (Tue, 28 Nov 2017 00:08:51 GMT):
:)

C0rWin (Tue, 28 Nov 2017 00:10:24 GMT):
honestly do not really mind about how many votes do we need, as long as we have clear definition of external API and will define all relevant use cases.

C0rWin (Tue, 28 Nov 2017 00:10:48 GMT):
such as changing API for sake of fixing exploits for example

C0rWin (Tue, 28 Nov 2017 00:11:21 GMT):
or deficiency in design

C0rWin (Tue, 28 Nov 2017 00:12:12 GMT):
btw, once we going into this, we also probably need to define deprecation policy

yacovm (Tue, 28 Nov 2017 00:13:04 GMT):
right, and that's a good thing, because no one said that everything that exists now is set in stone

yacovm (Tue, 28 Nov 2017 00:13:20 GMT):
all big projects deprecate parts of themselves over time

yacovm (Tue, 28 Nov 2017 00:13:20 GMT):
~ all ~ many big projects deprecate parts of themselves over time

yacovm (Tue, 28 Nov 2017 00:19:22 GMT):
anyway @binhn I suggest you open a JIRA for that, so we can.... vote?

yacovm (Tue, 28 Nov 2017 00:20:14 GMT):
I'm sure you believe me since I responded first and immediately, that I didn't collude with anyone ;)

binhn (Tue, 28 Nov 2017 01:42:59 GMT):
we can do that in due time. Let's wait for more feedback from maintainers here

jyellick (Tue, 28 Nov 2017 03:13:26 GMT):
Although it's probably worth having guidance for what sort of changes require a vote, I would expect for most contributors to be able to recognize issues which deserve additional vetting. My question is always how to draw more attention to an issue which requires it. The system I am aware of is to add the review-needed label to the JIRA item, but this often does not seem to attract the amount of attention desired. Posting to the mailing list and or maintainers channel seems a bit spam-like to me, and risks bifurcating the discussion into JIRA + other venue, when it seems like as much of the discussion as possible should be on JIRA. In line with what was said above, I'd think a simple majority if there is dissent, or 1/3rd with adequate time and no dissent. Obviously nothing is set in stone, but it seems at least like a good place to start. I'd suggest that the rule should look something like: "If the issue has been publicized by doing , and at least week days have passed, and at least 1/3rd maintainers have voted in support, and no maintainers are opposed, then it is approved. If a majority of maintainers vote in support, the issue is approved."

heath (Tue, 28 Nov 2017 06:24:08 GMT):
Has joined the channel.

dave.enyeart (Tue, 28 Nov 2017 11:20:31 GMT):
There are many times when a binary decision is needed - implement alternative A or alternative B. Requiring 2/3 majority may lead to stalemate in those scenarios. Therefore I agree with Jason’s proposal - simple majority when there is some dissent, 1/3 is sufficient if there is no dissent. This happens to be exactly what we have been already practicing - requiring 5 (1/3rd) for most decisions and requiring simple majority for ‘important’ decisions such as maintainer nominations.

dave.enyeart (Tue, 28 Nov 2017 11:20:31 GMT):
There are many times when a binary decision is needed - implement alternative A or alternative B. Requiring 2/3 majority may lead to stalemate in those scenarios. Therefore I agree with Jason’s proposal - simple majority when there is some dissent, 1/3 is sufficient if there is no dissent <7>? days after a publicized call to vote. This happens to be aligned with our current practice - requiring 5 (1/3rd) for most decisions and requiring simple majority for ‘important’ decisions such as maintainer nominations.

dave.enyeart (Tue, 28 Nov 2017 11:20:31 GMT):
There are many times when a binary decision is needed - implement alternative A or alternative B. Requiring 2/3 majority may lead to stalemate in those scenarios. Therefore I agree with Jason’s proposal - simple majority when there is some dissent, 1/3 is sufficient if there is no dissent <7>? days after a publicized call to review and vote. This happens to be aligned with our current practice - requiring 5 (1/3rd) for most decisions and requiring simple majority for ‘important’ decisions such as maintainer nominations.

dave.enyeart (Tue, 28 Nov 2017 11:20:45 GMT):
Concerning which ‘important’ items require a vote, I generally agree with Binh’s original guidance above, and I also agree with Jason’s comment that we usually know it when we see it. I’d be fine going with a system where any maintainer can call for a vote by placing review-needed on a Jira item and highlighting it on this maintainers channel. Usually that would be the lead maintainer for a given feature, but could be any maintainer. Again, this happens to be aligned with what we have already been practicing for new top-level features, but should be extended to architectural decisions (which may be written up as a subtask under an approved feature).

dave.enyeart (Tue, 28 Nov 2017 11:20:45 GMT):
Concerning which ‘important’ items require a vote, I generally agree with Binh’s original guidance above, and I also agree with Jason’s comment that we usually know it when we see it. I’d be fine going with a system where any maintainer can call for a vote by placing review-needed on a Jira item and highlighting it on this maintainers channel. Usually that would be the lead maintainer for a given feature, but could be any maintainer. Again, this happens to be aligned with what we have already been practicing for new top-level features, but should be extended to architectural designs/decisions (which would be written up as a subtask under an approved feature, with optional link to google doc if long).

dave.enyeart (Tue, 28 Nov 2017 11:20:45 GMT):
Concerning which ‘important’ items require a review and vote, I generally agree with Binh’s original guidance above, and I also agree with Jason’s comment that we usually know it when we see it. I’d be fine going with a system where any maintainer can call for a review/vote by placing review-needed on a Jira item and highlighting it on this maintainers channel. Usually that would be the lead maintainer for a given feature, but could be any maintainer. Again, this happens to be aligned with what we have already been practicing for new top-level features, but should be extended to architectural designs/decisions (which would be written up as a subtask under an approved feature, with optional link to google doc if long).

dave.enyeart (Tue, 28 Nov 2017 11:20:51 GMT):
I’d prefer if maintainers try not to abstain from votes so that we don’t get into debates about majorities of subsets - if a maintainer doesn’t have enough expertise in a certain area to make a decision they can always follow the lead of a resident expert in the space.

dave.enyeart (Tue, 28 Nov 2017 11:20:51 GMT):
I’d prefer if maintainers not to abstain from votes so that we don’t get into debates about majorities of subsets - if a maintainer doesn’t have enough expertise in a certain area to make a decision they can always follow the lead of a resident expert in the space.

dave.enyeart (Tue, 28 Nov 2017 11:20:51 GMT):
I’d prefer if maintainers not abstain from votes so that we don’t get into debates about majorities of subsets - if a maintainer doesn’t have enough expertise in a certain area to make a decision they can always follow the lead of a resident expert in the space.

dave.enyeart (Tue, 28 Nov 2017 11:20:51 GMT):
I’d prefer that maintainers not abstain from votes so that we don’t get into debates about majorities of subsets - if a maintainer doesn’t have enough expertise in a certain area to make a decision they can always follow the lead of a resident expert in the space.

dave.enyeart (Tue, 28 Nov 2017 11:20:58 GMT):
I think this approach has the necessary checks and balances, without being overly heavyweight.

dave.enyeart (Tue, 28 Nov 2017 11:21:04 GMT):
We have indeed fallen out of the habit of voting on review-needed features for the release, but I think if there is consensus on moving forward with this approach we can re-commit to voting on release features AND architectural decisions.

dave.enyeart (Tue, 28 Nov 2017 11:21:09 GMT):
The remaining open features tagged as 1.1 with review-needed can be found here:

dave.enyeart (Tue, 28 Nov 2017 11:21:16 GMT):
https://jira.hyperledger.org/issues/?filter=10904&jql=project%20%3D%20FAB%20AND%20labels%20%3D%20Release-planning-1.1%20AND%20(type%20%3D%20Epic%20OR%20type%20%3D%20%22New%20Feature%22)%20AND%20status%20!%3D%20Done

binhn (Tue, 28 Nov 2017 14:42:47 GMT):
thanks @dave.enyeart and @jyellick the reason for > 2/3 because I thought about the current active maintainers 9 out or 15 are IBMers, so if we went with 1/2, it would not be perceived as a "fair" system. Of course, I am not saying that all IBM maintainers would vote together regardless, but that's the fact that we have to deal with. let's wait for others to chime in

binhn (Tue, 28 Nov 2017 14:42:47 GMT):
thanks @dave.enyeart and @jyellick the reason for > 2/3 because I thought about the current active maintainers 9 out of 15 are IBMers, so if we went with 1/2, it would not be perceived as a "fair" system. Of course, I am not saying that all IBM maintainers would vote together regardless, but that's the fact that we have to deal with. let's wait for others to chime in

jyellick (Tue, 28 Nov 2017 15:18:46 GMT):
@dave.enyeart The link you sent doesn't seem to have anything to do with the `review-needed` tag?

C0rWin (Tue, 28 Nov 2017 16:02:35 GMT):
looks like a list of items targeted for release

dave.enyeart (Tue, 28 Nov 2017 16:12:04 GMT):
@jyellick The link I sent is for the open features tagged with release-planning-1.1. Each of them has a review-needed tag. Most of them have not been voted on yet.

dave.enyeart (Tue, 28 Nov 2017 16:14:02 GMT):
These are the same features that we have been looking at in the Fabric dashboards and wiki, and there has been general agreement on inclusion in 1.1, we just need to formalize it with votes in the Jiras.

dave.enyeart (Tue, 28 Nov 2017 16:14:02 GMT):
These are the same features that we have been looking at in the Fabric dashboards and wiki https://wiki.hyperledger.org/projects/fabric/proposedv1_1, and there has been general agreement on inclusion in 1.1, we just need to formalize it with votes in the Jiras.

dave.enyeart (Tue, 28 Nov 2017 16:17:48 GMT):
If you are looking for the comprehensive list of review-needed items, that can also be found on the dashboard (middle of page on left): https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104

dave.enyeart (Tue, 28 Nov 2017 18:17:43 GMT):
@here I have filled in details for CouchDB index management feature at https://jira.hyperledger.org/browse/FAB-6174 . There has been a lot of customer demand for this feature (as expected, since CouchDB queries only perform well with index in place). Please review, provide comments, and vote if you agree. There is also a child subtask https://jira.hyperledger.org/browse/FAB-7130 for a specific design decision that is required around changing channel name allowed length, which I have also marked as review-needed.

cbf (Tue, 28 Nov 2017 18:46:40 GMT):
@here so, on the voting, IMO, what we should be doing is building consensus. If we use any threshold voting strategy, someone will be miffed

JonathanLevi (Tue, 28 Nov 2017 18:46:53 GMT):
Ture

JonathanLevi (Tue, 28 Nov 2017 18:46:53 GMT):
True

cbf (Tue, 28 Nov 2017 18:46:56 GMT):
the objective should be to avoid needing a vote

cbf (Tue, 28 Nov 2017 18:47:39 GMT):
working out technical differences of opinion, and then when it becomes clear that we aren't going to get to an agreement, THEN we resort to a vote

cbf (Tue, 28 Nov 2017 18:48:15 GMT):
we originally added the "review-needed" to limit what when into 1.0.0 release (as a forcing function to STOP CODING;-)

cbf (Tue, 28 Nov 2017 18:48:30 GMT):
it raised the threshold and made people think

cbf (Tue, 28 Nov 2017 18:50:09 GMT):
I think that generally, as we think about planning 1.2.0 we should have specific proposals for new or modified features and improvements that we can review, as a team... and that review will surface any differences of opinion

cbf (Tue, 28 Nov 2017 18:51:26 GMT):
we should then try to get to consensus and only when it is clear that none will be reached should we resort to a vote... and then, I think that we should think carefully about whether majority or super-majority is the better choice

cbf (Tue, 28 Nov 2017 18:51:57 GMT):
my concern about super-majority is that it may mean we put the brakes on

cbf (Tue, 28 Nov 2017 18:52:06 GMT):
of course, that could be A Good Thing (tm)

cbf (Tue, 28 Nov 2017 19:06:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=BcGQ2QDKB5Sv5WYsf) @binhn you are suggesting that all the IBMers agree on everything? When has THAT ever happened;-)

jyellick (Tue, 28 Nov 2017 19:18:41 GMT):
@jeffgarratt has been looking at this, and has come up with a proposed model for a formal process. He can't post in this channel, so I can unmute him, or, he can write it up as a JIRA, what do you guys think?

JonathanLevi (Tue, 28 Nov 2017 19:20:09 GMT):
JIRA is totally fine. Unless Jeff would like to get unmuted? (I personally have no objection to Jeff participating here... if that was part of the question)

JonathanLevi (Tue, 28 Nov 2017 19:20:30 GMT):
I don't want to offend anyone by confirming that I don't want to mute someone ;-)))

jyellick (Tue, 28 Nov 2017 19:21:50 GMT):
jeffgarratt

jeffgarratt (Tue, 28 Nov 2017 19:22:21 GMT):
I have formalized a model wrt to governance

JonathanLevi (Tue, 28 Nov 2017 19:22:29 GMT):
Hello @jeffgarratt !

jeffgarratt (Tue, 28 Nov 2017 19:22:34 GMT):
wanted to present it per it's own prescription

jeffgarratt (Tue, 28 Nov 2017 19:22:37 GMT):
hello

jeffgarratt (Tue, 28 Nov 2017 19:22:47 GMT):
i.e. as a new feature

jeffgarratt (Tue, 28 Nov 2017 19:23:58 GMT):
I will write this up as a new feature in Jira and post the link here.

JonathanLevi (Tue, 28 Nov 2017 19:24:13 GMT):
It may be easier @jeffgarratt

jeffgarratt (Tue, 28 Nov 2017 19:26:52 GMT):
will post asap

dave.enyeart (Wed, 29 Nov 2017 03:41:37 GMT):
@cbf I'm not understanding your comments about building consensus first and then voting. The proposal is that we write up features and high level design in the public jira, and then tag it as review-needed to indicate it is ready for review. Reviewers (either maintainers or community members) provide comments if they have feedback or disagree (in total or to specific parts), or vote affirmative to indicate consent. And then iterate until consensus is reached. The jira upvote is a key mechanism to indicate consent during the iterative consensus building process. Are you suggesting we first "review as a team" outside of jira? Or review in jira but not use the actual upvote widget until a 'final' vote is required?

dave.enyeart (Wed, 29 Nov 2017 03:41:37 GMT):
@cbf I'm not understanding your comments about building consensus first and then voting. The proposal is that we write up features and high level design in the public jira, as well as any architectural decisions, and then tag it as review-needed to indicate it is ready for review. Reviewers (either maintainers or community members) provide comments if they have feedback or disagree (in total or to specific parts), or vote affirmative to indicate consent. And then iterate until consensus is reached (whether that means simple majority or super majority is a valid debate). The jira upvote is a key mechanism to indicate consent during the iterative consensus building process. Are you suggesting we first "review as a team" outside of jira? Or review in jira but not use the actual upvote widget until a 'final' vote is required?

dave.enyeart (Wed, 29 Nov 2017 03:41:47 GMT):
This discussion is for building consensus on individual features upfront rather than wait until code review time (which has been happening).

dave.enyeart (Wed, 29 Nov 2017 03:41:55 GMT):
For cross-feature prioritization for 1.2 release planning we will need a different procedure.

dave.enyeart (Wed, 29 Nov 2017 03:42:02 GMT):
Note that this proposal is a lightweight variant of the more formalized feature management and voting process that Jeff is writing up.

dave.enyeart (Wed, 29 Nov 2017 03:42:13 GMT):
I am attempting to build some general consensus around a lightweight approach that could be used for the remainder of 1.1, while Jeff's more formal process is evaluated.

mastersingh24 (Wed, 29 Nov 2017 14:33:41 GMT):
@dave.enyeart - this has always been the process. What's changed? I'm a bit tired of all. We aren't going to vote on everything. The review-needed tag was intended for things that people wanted to add to release after content had already been decided

mastersingh24 (Wed, 29 Nov 2017 14:33:41 GMT):
@dave.enyeart - this has always been the process. What's changed? I'm a bit tired of it all. We aren't going to vote on everything. The review-needed tag was intended for things that people wanted to add to release after content had already been decided.

mastersingh24 (Wed, 29 Nov 2017 14:33:54 GMT):
The bottom line is quite simple: we need to actually plan a release

mastersingh24 (Wed, 29 Nov 2017 14:35:27 GMT):
New features proposals - the process was to write it up in JIRA and possibly attach an external doc and then post to the mailing list. The part we have not done so well is actually planning a release up front before it get's started. I think we can improve on that for v1.1

mastersingh24 (Wed, 29 Nov 2017 14:36:07 GMT):
And new feature descriptions should include a writeup of the proposed architecture

mastersingh24 (Wed, 29 Nov 2017 14:36:23 GMT):
Of course we also need to decide if/when a feature will go in as well

mastersingh24 (Wed, 29 Nov 2017 14:36:54 GMT):
I don't see the point in voting for everything - but I don't think that is what you are proposing

mastersingh24 (Wed, 29 Nov 2017 14:37:26 GMT):
I will also state that many people don't have the context for some of these items. Now we can rectify that with better writeups of features, requirements, etc

mastersingh24 (Wed, 29 Nov 2017 14:42:15 GMT):
For example, sidedb / private data was done very nicely

mastersingh24 (Wed, 29 Nov 2017 14:42:15 GMT):
For example, sidedb / private data was very nicely done

dave.enyeart (Wed, 29 Nov 2017 14:56:21 GMT):
@mastersingh24 agreed to all. In my opinion one issue is that we are not consistently building consensus prior to dev, rather we get new comments during CR review. I'm hoping for better Jira descriptions as well as more eyeballs on it prior to dev. For example I put out https://jira.hyperledger.org/browse/FAB-6174 for review yesterday. If people look at it and agree, an upvote would be a nice indicator, regardless of a formal voting process.

mastersingh24 (Wed, 29 Nov 2017 14:56:48 GMT):
100% agree on up votes

mastersingh24 (Wed, 29 Nov 2017 14:57:07 GMT):
I try to do it for JIRAs whenever I see something that looks like a good idea

mastersingh24 (Wed, 29 Nov 2017 14:57:16 GMT):
Just to indicate some form of tacit approval

cbf (Wed, 29 Nov 2017 17:15:14 GMT):
@dave.enyeart I completely agree - and we do need to do that

cbf (Wed, 29 Nov 2017 17:15:14 GMT):
@dave.enyeart I completely agree - and we do need to do that planning.

jyellick (Thu, 30 Nov 2017 02:35:50 GMT):
Some additional review for https://jira.hyperledger.org/browse/FAB-7114 would be appreciated

dave.enyeart (Thu, 30 Nov 2017 11:42:30 GMT):
@here I think the lack of rush to vote on https://jira.hyperledger.org/browse/FAB-7114 indicates that the solution is difficult to love. That being said, it is our duty to either get behind one of the proposals or write up an alternate proposal. Of the proposals written up, in my opinion this is the one that best meets the requirements and addresses the concerns that have been raised. This is THE critical path item for 1.1 - I’d urge everybody to give it serious consideration this week, and add comments or write up an alternate proposal rather than abstain.

mastersingh24 (Thu, 30 Nov 2017 11:49:46 GMT):
Might also just be that people are heads down on their own items as well. Again - I'm really not sure why we are voting on this one, but that's a different story. People seemed to have concerns on basically getting rid of the existing instantiate mechanism. FAB-7114 basically keeps this in place while adding an extra step which is the fundamental part of the implementation

yacovm (Thu, 30 Nov 2017 12:02:17 GMT):
@dave.enyeart I don't understand how we can vote on a JIRA item that is a sub-task of a JIRA epic/new feature. We voted on FAB-6042 and now we're voting on a sub-task of it. In my opinion, if someone is against 1 of the sub-tasks of a JIRA item, he just shouldn't vote for it, and that's it.

yacovm (Thu, 30 Nov 2017 12:02:17 GMT):
@dave.enyeart I don't understand how we can vote on a JIRA item that is a sub-task of a JIRA epic/new feature that we already voted on. We voted on FAB-6042 and now we're voting on a sub-task of it. In my opinion, if someone is against 1 of the sub-tasks of a JIRA item, he just shouldn't vote for it, and that's it.

dave.enyeart (Thu, 30 Nov 2017 12:05:17 GMT):
Under an approved feature, there are some times important implementation decisions which in my mind are worthy of vetting and even a vote if there is contention. This seems to be one of them.

dave.enyeart (Thu, 30 Nov 2017 12:07:09 GMT):
If you have another proposal to help make the decision, I'm all ears

yacovm (Thu, 30 Nov 2017 12:07:17 GMT):
right, I agree. But - that means that if we can't collect votes on a sub-task, what do the votes of the parent feature count for?

yacovm (Thu, 30 Nov 2017 12:07:22 GMT):
my proposal is simple

yacovm (Thu, 30 Nov 2017 12:07:54 GMT):
if we have a JIRA item that has sub-tasks, we vote on it as usual, and all sub-tasks of it are scrutinized (either in the sub-task discussion or the parent one)

yacovm (Thu, 30 Nov 2017 12:08:07 GMT):
then, if a threshold of votes is collected, there is no re-voting on a part of the JIRA item.

dave.enyeart (Thu, 30 Nov 2017 12:09:50 GMT):
the important thing is building consensus, in my opinion that can be done via comments or upvotes

yacovm (Thu, 30 Nov 2017 12:10:41 GMT):
right, of course. I'm just saying the consensus should be on the entire JIRA with all its sub-tasks

yacovm (Thu, 30 Nov 2017 12:10:44 GMT):
that's all

cbf (Thu, 30 Nov 2017 13:34:38 GMT):
we really should not be voting, but building consensus. Yacov does have a point, but it also points out that when we do agree on a feature, it should have a detailed proposal that we agree on

cbf (Thu, 30 Nov 2017 13:36:18 GMT):
as we wind down on 1.1 and start to think about planning for 1.2 (and yes, we REALLY need to do a formal plan and STICK TO IT once agreed) we should be coming together with fully fleshed out proposals for any new or refactored features complete with sizing estimates and resource commitments.

cbf (Thu, 30 Nov 2017 13:36:33 GMT):
and the sizing needs to include docs, tests and samples

kostas (Thu, 30 Nov 2017 13:57:18 GMT):
For whatever little it's worth, I like the way the Rust folks are handling this: https://github.com/rust-lang/rfcs#what-the-process-is

C0rWin (Thu, 30 Nov 2017 14:49:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=bzJ2icxnyBWZtn8i7) @kostas +100 I think RFC/JSR like approaches to suggest and come to the agreement on new features is a good way going forward on standardizing the whole planning process

cbf (Thu, 30 Nov 2017 14:59:32 GMT):
need one more vote on https://gerrit.hyperledger.org/r/c/15669/ please and that will give us 8 votes (so it can be merged

jeffgarratt (Thu, 30 Nov 2017 18:26:54 GMT):
@here I posted feature to capture the thinking with respect to governance model. https://jira.hyperledger.org/browse/FAB-7147 That then links to the actual analysis and design document here https://jira.hyperledger.org/browse/FAB-7226

jeffgarratt (Thu, 30 Nov 2017 18:29:26 GMT):
I was thinking of shooting a quick video to demonstrate usage wrt to accommodating existing tasks, as well as new features (such as the one above)

wanghaihui (Fri, 01 Dec 2017 08:58:13 GMT):
Has joined the channel.

dsanchezseco (Fri, 01 Dec 2017 12:37:05 GMT):
Has joined the channel.

dsanchezseco (Fri, 01 Dec 2017 12:37:42 GMT):
Has left the channel.

dave.enyeart (Fri, 01 Dec 2017 15:43:10 GMT):
@jeffgarratt , a video would be great, thanks.

dave.enyeart (Fri, 01 Dec 2017 15:44:28 GMT):
@here I've added updated proposal comment to CouchDB index management: https://jira.hyperledger.org/browse/FAB-6174

dave.enyeart (Fri, 01 Dec 2017 15:44:28 GMT):
@here I've added updated proposal comment to CouchDB index management: https://jira.hyperledger.org/browse/FAB-6174?focusedCommentId=35720&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-35720

dave.enyeart (Fri, 01 Dec 2017 15:44:54 GMT):
See 10:30am comment (you don't need to read the full comment chain unless you like pain)

dave.enyeart (Fri, 01 Dec 2017 15:45:45 GMT):
If there is general agreement to the latest proposal, I will write it up as a new Jira item

dave.enyeart (Mon, 04 Dec 2017 11:55:03 GMT):
Updated CouchDB index management design here: https://jira.hyperledger.org/browse/FAB-3067

dave.enyeart (Mon, 04 Dec 2017 11:55:03 GMT):
I've addressed CouchDB index management design comments, and created a Jira with the cleaned up design Description: https://jira.hyperledger.org/browse/FAB-3067

JonathanLevi (Mon, 04 Dec 2017 11:55:35 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=TB5zg8igyMzN7yqno) Thank you @jeffgarratt - let's continue the conversations/discussions/thread over JIRA then, so that others (e.g., non-maintainers) can chime in.

JonathanLevi (Mon, 04 Dec 2017 11:56:14 GMT):
User User_1 removed by JonathanLevi.

JonathanLevi (Mon, 04 Dec 2017 11:57:14 GMT):
[ Have kindly removed Jeff, so that we don't have an "unprecedented case" of a non-maintainer who's permanently added to this channel ]

mastersingh24 (Mon, 04 Dec 2017 15:27:07 GMT):
Fellow maintainers, here's the stack of CRs for the v1.0.5 release: https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric+branch:release+topic:release-1.0.5

mastersingh24 (Mon, 04 Dec 2017 15:27:07 GMT):
Fellow maintainers, here's the stack of CRs for the Fabric v1.0.5 release: https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric+branch:release+topic:release-1.0.5

jeffgarratt (Mon, 04 Dec 2017 15:40:20 GMT):
Has joined the channel.

mastersingh24 (Mon, 04 Dec 2017 18:30:11 GMT):
Can we get one more +2 on: https://gerrit.hyperledger.org/r/15901 https://gerrit.hyperledger.org/r/15893 and then merge? I need to add another CR into the stack and will be easier if you can avoid wasted CI cycles ;)

jyellick (Mon, 04 Dec 2017 18:49:35 GMT):
Did 15901, but can't on 15893, still need help there.

cbf (Fri, 08 Dec 2017 22:16:32 GMT):
@greg.haskins https://gerrit.hyperledger.org/r/c/15861/ we might want to take the discussion to RC or maybe the JIRA

kostas (Mon, 11 Dec 2017 14:26:24 GMT):
Do we know who's in charge of the .htaccess redirects in Gerrit?

yacovm (Mon, 11 Dec 2017 14:27:19 GMT):
I guess worth to ask in #ci-pipeline ?

rjones (Mon, 11 Dec 2017 23:16:33 GMT):
@kostas me, I guess? please ask in #ci-pipeline though

guolidong (Tue, 12 Dec 2017 05:59:52 GMT):
Has joined the channel.

dave.enyeart (Tue, 12 Dec 2017 11:32:49 GMT):
@here For the ability to stream transaction statuses from peer to clients as discussed in https://jira.hyperledger.org/browse/FAB-7069 (aka filtered events), @jeffgarratt has proposed we vote on the two implementation approaches that have been discussed. Thanks Jeff for writing these up as Jira items. Please upvote one or the other, and add any feedback:

dave.enyeart (Tue, 12 Dec 2017 11:32:51 GMT):
https://jira.hyperledger.org/browse/FAB-7419 (peer API approach), or

dave.enyeart (Tue, 12 Dec 2017 11:33:06 GMT):
https://jira.hyperledger.org/browse/FAB-7367 (external application approach)

yacovm (Tue, 12 Dec 2017 11:34:33 GMT):
@dave.enyeart - is there a consensus on one of the following ways: - Using the same `common.Block` but filtering out the fields - Using a new protobuf type that contains only the filtered fields ?

yacovm (Tue, 12 Dec 2017 11:34:49 GMT):
I haven't been able to keep track from all the sub-opinions

dave.enyeart (Tue, 12 Dec 2017 11:35:25 GMT):
Looks like opinions were split on that. I suggest we pick an general approach and then settle that.

dave.enyeart (Tue, 12 Dec 2017 11:35:25 GMT):
Looks like opinions were split on that. I suggest we pick a general approach and then settle that.

dave.enyeart (Tue, 12 Dec 2017 11:35:25 GMT):
Looks like opinions were split on that. I suggest we pick a general approach and then settle the remaining details.

C0rWin (Tue, 12 Dec 2017 11:35:45 GMT):
I think this is an orthogonal to the initial question

C0rWin (Tue, 12 Dec 2017 11:35:55 GMT):
e.g. peer API vs external application

yacovm (Tue, 12 Dec 2017 11:36:04 GMT):
right it is orthogonal to Dave's poll

yacovm (Tue, 12 Dec 2017 11:36:19 GMT):
I'm just asking along the way since I have the opportunity.

C0rWin (Tue, 12 Dec 2017 11:36:22 GMT):
I think we need to settle the approach and decide on implementation details once direction will be clear

dave.enyeart (Tue, 12 Dec 2017 18:24:00 GMT):
Initial input for Fabric upgrade documentation is available in https://jira.hyperledger.org/browse/FAB-6544. Follow the google link there. The doc closely follows the BDD upgrade scenario that Jeff has provided to system test. In fact it links to the BDD feature in many places in case you'd like to drill down. I think we'll want all maintainers to give it a quick preview and add comments, prior to publicizing and writing it up for external documentation consumption.

dave.enyeart (Tue, 12 Dec 2017 18:24:36 GMT):
Specifically there are a few comments in there most appropriate for @jyellick and @kostas .

dave.enyeart (Tue, 12 Dec 2017 18:25:23 GMT):
The most important question in my opinion is whether rolling upgrade can be supported for ordering service nodes.

yacovm (Tue, 12 Dec 2017 19:55:25 GMT):
Who are the target audience of the google doc, @dave.enyeart ?

yacovm (Tue, 12 Dec 2017 19:55:25 GMT):
What's the target audience of the google doc, @dave.enyeart ?

yacovm (Tue, 12 Dec 2017 19:56:14 GMT):
Is it a precursor for an RST document that will be published to users?

dave.enyeart (Tue, 12 Dec 2017 20:24:03 GMT):
@yacovm Yes the google doc is for us to get the upgrade story that we want to document straight. It will be used as input to author the eventual user facing RST. And it will be used by system test in the interim.

zhishui (Tue, 19 Dec 2017 08:12:16 GMT):
Has joined the channel.

mastersingh24 (Mon, 25 Dec 2017 12:35:07 GMT):
Merry Christmas and happy holidays. Let's give ourselves a nice gift and get v1.1 out the door! :christmas_tree:

mastersingh24 (Mon, 25 Dec 2017 12:35:07 GMT):
Happy Holidays to all! Let's give ourselves a nice gift and get v1.1 out the door! :christmas_tree: :menorah: :gift:

JonathanLevi (Tue, 26 Dec 2017 14:44:01 GMT):
Thank you Gari. Yes, happy holidays! Hopefully we can do this w/o Santa... but just for the off-chance, we should all put the Green and Blue blockchain socks (from Consensus 2017) hanging somewhere, in case somebody shows up. A sock for each component! ;-)

mastersingh24 (Wed, 27 Dec 2017 11:16:26 GMT):
Nice!

mastersingh24 (Wed, 27 Dec 2017 11:17:25 GMT):
FYI - I'll be mostly offline for the remainder of the week. Decided to run away from the cold weather here in Boston and head south ;)

cbf (Thu, 04 Jan 2018 12:30:25 GMT):
Happy New Year, @here

cbf (Thu, 04 Jan 2018 12:30:50 GMT):
@dave.enyeart and I discussed the plans to wrap up 1.1 release yesterday

cbf (Thu, 04 Jan 2018 12:31:32 GMT):
specifically, we need to be looking to CODE FREEZE RSN - we discussed next Friday 1/12 as a target date

cbf (Thu, 04 Jan 2018 12:31:32 GMT):
specifically, we need to be looking to FEATURE FREEZE RSN - we discussed next Friday 1/12 as a target date

cbf (Thu, 04 Jan 2018 12:32:44 GMT):
for those not working on remaining features, everyone else needs to be focused on fixing high and highest defects - @dave.enyeart will be going through those and identifying those which we really SHOULD fix for 1.1-alpha

cbf (Thu, 04 Jan 2018 12:33:50 GMT):
Does anyone have concerns about the immediate plan for a FEATURE FREEZE as of 1/12?

cbf (Thu, 04 Jan 2018 12:34:00 GMT):
speak now or forever hold your peace

yacovm (Thu, 04 Jan 2018 12:34:23 GMT):
is that only for fabric core or also for SDKs?

yacovm (Thu, 04 Jan 2018 12:34:23 GMT):
is that only for fabric core, fabric-CA or also for SDKs?

cbf (Thu, 04 Jan 2018 12:35:05 GMT):
if SDKs are trailing... sigh

cbf (Thu, 04 Jan 2018 12:35:29 GMT):
if I had my drothers, we would lock it down now;-)

yacovm (Thu, 04 Jan 2018 12:35:32 GMT):
No concern from my side, of course - just saying they usually lag behind

yacovm (Thu, 04 Jan 2018 12:35:45 GMT):
@jimthematrix

yacovm (Thu, 04 Jan 2018 12:36:06 GMT):
Making sure we take that into account

yacovm (Thu, 04 Jan 2018 12:44:28 GMT):
Also we have that event filtering JIRA which hasn't reached a final consensus yet

yacovm (Thu, 04 Jan 2018 12:44:28 GMT):
Also we have that event filtering JIRA ( FAB-7419 ) which hasn't reached a final consensus yet

cbf (Thu, 04 Jan 2018 12:44:31 GMT):
yep

yacovm (Thu, 04 Jan 2018 12:44:33 GMT):
and SDKs are consumers of that

cbf (Thu, 04 Jan 2018 12:45:16 GMT):
IMO, we really need to stop letting perfection getting in the way of progress

cbf (Thu, 04 Jan 2018 12:45:41 GMT):
there are CRs in review and we are still arguing... insane

C0rWin (Thu, 04 Jan 2018 12:46:00 GMT):
I could not say more

C0rWin (Thu, 04 Jan 2018 12:54:31 GMT):
I'd rather adding UT to it, than trying to refactor it adding another abstraction layers on top of existing code which we could simply reuse as it is

muralisr (Thu, 04 Jan 2018 13:32:19 GMT):
@cbf @mastersingh24 @dave.enyeart the chaincode cleanup has been worked and reviewed and has no external impact. Can we please get that in ?

muralisr (Thu, 04 Jan 2018 13:32:48 GMT):
the series is https://gerrit.hyperledger.org/r/#/c/16533/ https://gerrit.hyperledger.org/r/#/c/16503/ https://gerrit.hyperledger.org/r/#/c/11867/

muralisr (Thu, 04 Jan 2018 13:33:36 GMT):
as reviewers, @C0rWin @yacovm do chime in please

C0rWin (Thu, 04 Jan 2018 13:34:23 GMT):
:spy: on my way

yacovm (Thu, 04 Jan 2018 13:35:50 GMT):
I can't vouch for the safety of the first change set, as the chaincode code is pretty hard to understand. We should have removed that FSM in v1.0 and not now.

yacovm (Thu, 04 Jan 2018 13:35:50 GMT):
I can't vouch for the safety of the first change set, as the chaincode code is pretty hard to understand. We should have removed that FSM before v1.0 release and not now.

yacovm (Thu, 04 Jan 2018 13:37:48 GMT):
actually the 2nd is also pretty complex

muralisr (Thu, 04 Jan 2018 13:38:27 GMT):
now I did not expect that answer

yacovm (Thu, 04 Jan 2018 13:38:48 GMT):
I'm not saying it's not safe to merge it

muralisr (Thu, 04 Jan 2018 13:38:54 GMT):
we spent quite some time chatting about it and my impression was you understood the changes

yacovm (Thu, 04 Jan 2018 13:39:02 GMT):
I understand the change

yacovm (Thu, 04 Jan 2018 13:39:11 GMT):
I think we need to do that

yacovm (Thu, 04 Jan 2018 13:39:30 GMT):
but I honestly don't know how can we know we don't have a logical bug creeping on us

yacovm (Thu, 04 Jan 2018 13:40:09 GMT):
and I'm saying that we should have done that before v1.0 was released

muralisr (Thu, 04 Jan 2018 13:42:47 GMT):
the more we postpone the harder it'll get... during 1.0 madness the focus was to get chaincode to accept concurrent requests and I tried to do that with as less changes as possible (ie, leave the FSM in) and thus reduce risk

yacovm (Thu, 04 Jan 2018 13:43:27 GMT):
right, we should have written that from scratch

yacovm (Thu, 04 Jan 2018 13:43:37 GMT):
instead of taking what isn't fit for v1 architecture

muralisr (Thu, 04 Jan 2018 13:44:16 GMT):
but here we are, removing the the FSM and clean up, why move it to another relkease ?

yacovm (Thu, 04 Jan 2018 13:44:40 GMT):
oh, I'm not saying we shouldn't merge that

yacovm (Thu, 04 Jan 2018 13:44:50 GMT):
I abstain

muralisr (Thu, 04 Jan 2018 13:46:37 GMT):
you have reviewed and have spent time going over the changes... why abstain ?

muralisr (Thu, 04 Jan 2018 13:48:25 GMT):
the changes are confined to 4 files, worst case we can revert with little pain

yacovm (Thu, 04 Jan 2018 13:48:37 GMT):
because I tried to help with the CR, but I cannot vouch for the safety of merging the CR

muralisr (Thu, 04 Jan 2018 13:48:38 GMT):
as it does not affect java or node js

muralisr (Thu, 04 Jan 2018 13:49:19 GMT):
but you understand the changes

muralisr (Thu, 04 Jan 2018 13:49:21 GMT):
?

yacovm (Thu, 04 Jan 2018 13:49:24 GMT):
in macro

yacovm (Thu, 04 Jan 2018 13:49:38 GMT):
not in micro ;)

muralisr (Thu, 04 Jan 2018 13:50:03 GMT):
fair enough...

JanRzepecki (Thu, 04 Jan 2018 15:45:50 GMT):
Has joined the channel.

dave.enyeart (Thu, 04 Jan 2018 18:37:21 GMT):
Now is the time we could really use all hands on deck from maintainers. Those maintainers not on critical path items could perhaps help on CR reviews. Apologies for proposing names, but perhaps @binhn could help review some of the @muralisr CRs and perhaps @JonathanLevi could help review some of the CA CRs highlighted by @smithbk over in #fabric-pr-review. What do you think?

dave.enyeart (Thu, 04 Jan 2018 18:39:54 GMT):
And perhaps @jimthematrix could help review SDK CRs as they become available from @bretharrison and @rickr

JonathanLevi (Thu, 04 Jan 2018 19:49:58 GMT):
Yes, of course I can.

greg.haskins (Thu, 04 Jan 2018 21:45:20 GMT):
howdy all, coming up for air

greg.haskins (Thu, 04 Jan 2018 21:45:33 GMT):
happy new year to you all

muralisr (Thu, 04 Jan 2018 23:52:07 GMT):
hey Greg,:tada:

muralisr (Thu, 04 Jan 2018 23:52:07 GMT):
hey @greg.haskins ,:tada:

muralisr (Thu, 04 Jan 2018 23:52:47 GMT):
(nearest I could find something newyeary :-) )

JonathanLevi (Fri, 05 Jan 2018 00:47:17 GMT):
[ Just like in the good ol' days... ]

CarlXK (Fri, 05 Jan 2018 04:29:10 GMT):
Has left the channel.

Asara (Mon, 08 Jan 2018 14:39:51 GMT):
Has joined the channel.

thiago-moreira (Tue, 09 Jan 2018 00:18:20 GMT):
Has joined the channel.

dave.enyeart (Tue, 09 Jan 2018 04:58:34 GMT):
@here We have 5 Experimental Features for 1.1 that we have been tracking in the release dashboard https://jira.hyperledger.org/issues/?filter=10829 and google release snapshot https://docs.google.com/spreadsheets/d/1TswRWap0MO-CVSLWbGnBzUPQp4SaWUeflRgkxZFh1t0/edit#gid=0 . We need some final disposition for these as we move through alpha/beta/GA. I would propose that we have an ‘advocate maintainer’ for each one to shepherd the experimental feature doc, samples, and system test through the remainder of 1.1 release. The 'advocate maintainer’ would also be the person that could propose the experimental feature is ready for production support, if they feel the feature has reached that level of maturity and thinks they can get consensus on that (I believe we are still operating under the 5 votes rule, as we have not gotten traction on any other voting proposal). Jira is not set up well for this voting, as some of the Features have already gotten 5 votes in Jira, but that was voting to begin the Experimental development. So we’ll need to try to reach consensus in the Jira comments, if we feel that any experimental feature is ready for production support. Note also that we have not standardized on how the experimental feature is hidden in the release, something we likely don’t have time to do prior to alpha but should be done minimally for beta/GA. The google release snapshot indicates how the feature is hidden in the release (currently a combination of experimental build tags, experimental capabilities, and 1.1 capabilities). Here are the five experimental features, looking for an advocate maintainer for three of them… thoughts? FAB 1151 Side DB - Dave FAB 3621 RBACL - Murali FAB 2005 Identity Mixer - Advocate volunteer? Maria had recommended Jason or Yacov. FAB 5664 Distinguish MSP Identity Types - Advocate volunteer? FAB-1973 Java Chaincode - Advocate vounteer?

dave.enyeart (Tue, 09 Jan 2018 04:58:34 GMT):
@here We have 5 Experimental Features for 1.1 that we have been tracking in the release dashboard https://jira.hyperledger.org/issues/?filter=10829 and google release snapshot https://docs.google.com/spreadsheets/d/1TswRWap0MO-CVSLWbGnBzUPQp4SaWUeflRgkxZFh1t0/edit#gid=0 . We need some final disposition for these as we move through alpha/beta/GA. I would propose that we have an ‘advocate maintainer’ for each one to shepherd the experimental feature doc, samples, and system test through the remainder of 1.1 release. The 'advocate maintainer’ would also be the person that could propose the experimental feature is ready for production support, if they feel the feature has reached that level of maturity and thinks they can get consensus on that (I believe we are still operating under the 5 votes rule, as we have not gotten traction on any other voting proposal). Jira is not set up well for this voting, as some of the Features have already gotten 5 votes in Jira, but that was voting to begin the Experimental development. So we’ll need to try to reach consensus in the Jira comments, if we feel that any experimental feature is ready for production support. Note also that we have not standardized on how the experimental feature is hidden in the release, something we likely don’t have time to do prior to alpha but should be done minimally for beta/GA. The google release snapshot indicates how the feature is hidden in the release (currently a combination of experimental build tags, experimental capabilities, and 1.1 capabilities). Here are the five experimental features, looking for an advocate maintainer for three of them… thoughts? https://jira.hyperledger.org/browse/FAB-1151 Side DB - Dave https://jira.hyperledger.org/browse/FAB-3621 RBACL - Murali https://jira.hyperledger.org/browse/FAB-2005 Identity Mixer - Advocate volunteer? Maria had recommended Jason or Yacov. https://jira.hyperledger.org/browse/FAB-5664 Distinguish MSP Identity Types - Advocate volunteer? https://jira.hyperledger.org/browse/FAB-1973 Java Chaincode - Advocate vounteer?

yacovm (Tue, 09 Jan 2018 06:11:20 GMT):
I am not a shepherd but i can advocate for FAB-5664

yacovm (Tue, 09 Jan 2018 06:17:11 GMT):
IdeMix has java sdk client side so i recommend someone familiar with that

mastersingh24 (Tue, 09 Jan 2018 11:45:43 GMT):
@yacovm - might be missing the context but not sure how IdeMix and FAB-5664 are related? And I thought we had merged almost all of the CRs related to 5664. I just need to look at the cryptogen one (last time I checked)

yacovm (Tue, 09 Jan 2018 11:46:08 GMT):
I'm saying

yacovm (Tue, 09 Jan 2018 11:46:17 GMT):
I can help with that one

yacovm (Tue, 09 Jan 2018 11:46:19 GMT):
but not with idemix

yacovm (Tue, 09 Jan 2018 11:46:35 GMT):
because idemix client code is java

yacovm (Tue, 09 Jan 2018 11:46:46 GMT):
(I know java, but I don't know java SDK ;) )

mastersingh24 (Tue, 09 Jan 2018 12:03:48 GMT):
Ah - gotcha.

mastersingh24 (Tue, 09 Jan 2018 12:04:40 GMT):
I thought that wrt to IdeMix, we were going to keep the runtime pieces in Fabric but NOT modify the SDKs for the v1.1 release

dave.enyeart (Tue, 09 Jan 2018 12:39:15 GMT):
I have heard some rumblings that FAB-5664 and FAB-2005 (server components) may be ready or are close to ready for production inclusion. The role of the 'maintainer advocate' in my proposal is to have a maintainer take a deep look at each feature, including doc, samples, system test, and assess if it is really ready for production inclusion. Or if it is close enough, to help close the gap. And then to convince the rest of the maintainers that it is ready to go. And if it is not ready to go, to help hide the feature as experimental prior to 1.1 release. I think @yacovm would be a great choice for either of them.

yacovm (Tue, 09 Jan 2018 12:41:37 GMT):
like I said @dave.enyeart I can do the former but the latter (2005) - I don't know java-SDK so I can't express an educated opinion about whether it's ready for production or not.

yacovm (Tue, 09 Jan 2018 12:42:07 GMT):
Perhaps @Maria wants to say something w.r.t 2005?

Maria (Tue, 09 Jan 2018 12:42:07 GMT):
Has joined the channel.

yacovm (Tue, 09 Jan 2018 12:42:11 GMT):
Maria

dave.enyeart (Tue, 09 Jan 2018 12:42:13 GMT):
Ok, Gari was saying we could take the server part of 2005 but not the sdk part... if that helps...

yacovm (Tue, 09 Jan 2018 12:42:43 GMT):
not sure what is delivered then if there is no client that can use that?

dave.enyeart (Tue, 09 Jan 2018 12:43:44 GMT):
I think Gari and Jason's idea was that server code could be delivered in 1.1, and then SDKs could add support whenever possible.

Maria (Tue, 09 Jan 2018 12:43:48 GMT):
we are finishing with the SDK integration with Angelo

dave.enyeart (Tue, 09 Jan 2018 12:43:48 GMT):
Maria has made her case about 2005 in FAB-7000 comments. I'm just asking for a maintainer to do some additional due diligence around it.

Maria (Tue, 09 Jan 2018 12:44:15 GMT):
but the idea was that we release the fabric part, and the sdk will follow once ready

Maria (Tue, 09 Jan 2018 12:44:57 GMT):
because the fabric part is ready and tested for a long time

Maria (Tue, 09 Jan 2018 12:45:10 GMT):
and i keep getting requests about it

yacovm (Tue, 09 Jan 2018 12:45:12 GMT):
who tested it?

Maria (Tue, 09 Jan 2018 12:45:22 GMT):
from AMEX for example

Maria (Tue, 09 Jan 2018 12:47:13 GMT):
we have e2e demo, full unit test coverage and we use the same crypto material in java sdk

dave.enyeart (Tue, 09 Jan 2018 12:50:17 GMT):
For cases like this where a feature is close to ready, the component owner and 'maintainer advocate' could work together to finish off any gaps, such as working on system test or partnering with system testers, to ensure good BDD coverage.

Maria (Tue, 09 Jan 2018 12:52:23 GMT):
we would be happy to do whatever else is necessary...

yacovm (Tue, 09 Jan 2018 12:53:13 GMT):
1 more thing, while I can do FAB-5664, if @adc wants, he can pick someone else, I don't mind :)

yacovm (Tue, 09 Jan 2018 12:53:18 GMT):
adc

Maria (Tue, 09 Jan 2018 12:53:55 GMT):
however in our view the fabric part is complete.... and we will be able to allocate more resources to finish up other sdks once the fabric part is released

muralisr (Tue, 09 Jan 2018 13:38:48 GMT):
@dave.enyeart I have played with https://jira.hyperledger.org/browse/FAB-5664 Distinguish MSP Identity Types

muralisr (Tue, 09 Jan 2018 13:39:17 GMT):
couple of things - default is disabled so does not interfere with 1.0 configurations

muralisr (Tue, 09 Jan 2018 13:41:33 GMT):
secondly it does work when enabled as far as distinguishing Org.Peer, Org.Client etc but I was struggling a bit with bending it to my scenario (this could be me though)

muralisr (Tue, 09 Jan 2018 13:43:01 GMT):
this could be a useful addition to MSP roles.. however we need some good samples and docs ( @adc @nickgaski )

muralisr (Tue, 09 Jan 2018 13:43:21 GMT):
+1 from me for https://jira.hyperledger.org/browse/FAB-5664

yacovm (Tue, 09 Jan 2018 13:55:58 GMT):
@dave.enyeart it seems to me that @muralisr is a better candidate than me for FAB-5664

muralisr (Tue, 09 Jan 2018 13:56:39 GMT):
hmmm I wouldn't say "better" @yacovm ...did I miss some conv. above ?

muralisr (Tue, 09 Jan 2018 13:56:57 GMT):
I just saw Daves request and responded :-)

dave.enyeart (Tue, 09 Jan 2018 13:57:44 GMT):
@yacovm do you want to take FAB-2005? (minus Java SDK parts). It does sound like @muralisr has good background context with FAB-5664 , even if he didn't completely volunteer :)

muralisr (Tue, 09 Jan 2018 13:59:14 GMT):
Ah... I just didn't read the text fuilly (thanks @yacovm for the pointer...)

muralisr (Tue, 09 Jan 2018 13:59:17 GMT):
I volunteer

yacovm (Tue, 09 Jan 2018 13:59:32 GMT):
thanks Murali

muralisr (Tue, 09 Jan 2018 13:59:37 GMT):
but I'm going to need some time with @adc

yacovm (Tue, 09 Jan 2018 13:59:44 GMT):
I think it makes sense you replace me with that given that you have played it already

muralisr (Tue, 09 Jan 2018 14:00:04 GMT):
@dave.enyeart how much doc and samples are needed for a +1 ?

muralisr (Tue, 09 Jan 2018 14:00:18 GMT):
because thats one thing that'll severly limit use of 5664

dave.enyeart (Tue, 09 Jan 2018 14:01:11 GMT):
If it is included as a production feature, it should have sufficient doc and samples for community to figure out the usage, same as any production feature.

muralisr (Tue, 09 Jan 2018 14:01:13 GMT):
it took me 2 whole day (err, of weekend if I might add :-) ) to get to the bottom...again this coukd just be mne

muralisr (Tue, 09 Jan 2018 14:01:21 GMT):
ok

dave.enyeart (Tue, 09 Jan 2018 14:01:22 GMT):
it is not you :)

muralisr (Tue, 09 Jan 2018 14:01:50 GMT):
I think its got value

dave.enyeart (Tue, 09 Jan 2018 14:02:03 GMT):
having gone through that pain already, makes you immensely qualified to help with 5664

muralisr (Tue, 09 Jan 2018 14:02:15 GMT):
you got it :-)

muralisr (Tue, 09 Jan 2018 14:02:22 GMT):
timeline again please ?

dave.enyeart (Tue, 09 Jan 2018 14:03:53 GMT):
it doesn't have to be perfect for alpha (january), but needs to be started for alpha and then in good shape by beta and ga dates (let's say one month out)

muralisr (Tue, 09 Jan 2018 14:04:14 GMT):
perfect

dave.enyeart (Tue, 09 Jan 2018 14:04:17 GMT):
and you dont have to do much of the actual work...just coach the implementer such as adc

yacovm (Tue, 09 Jan 2018 14:04:24 GMT):
adc

yacovm (Tue, 09 Jan 2018 14:04:27 GMT):
Maria

muralisr (Tue, 09 Jan 2018 14:05:47 GMT):
ok, I'll run my scenario by adc

muralisr (Tue, 09 Jan 2018 14:05:55 GMT):
and go from there

dave.enyeart (Tue, 09 Jan 2018 14:06:35 GMT):
ok great, thanks, this is exactly what i had in mind with "maintainer advocate"... somebody to try out the feature and coach the implementer through docs, samples, test.

dave.enyeart (Tue, 09 Jan 2018 14:11:43 GMT):
@muralisr you can be your own coach for FAB 3621 RBAC :) Do you think the code is ready for production use (assuming your CR gets merged and docs, samples, system test come together)? Or do you think it is better hidden as an experimental feature to collect feedback during 1.1 timeframe?

muralisr (Tue, 09 Jan 2018 14:12:44 GMT):
actually my using the 5664 was really to do convincing playback for 3621 :-)

muralisr (Tue, 09 Jan 2018 14:15:00 GMT):
Ive test and the playback out there with RSCC still works with the recent changes (ie, removal of rscc and the resulting simplification using recent resource bundle / config changes from @jyellick and @manish-sethi )

muralisr (Tue, 09 Jan 2018 14:15:27 GMT):
but that was a hard playback for users to follow because I had to use raw OUs there

muralisr (Tue, 09 Jan 2018 14:15:46 GMT):
but with 5664 I was hoping for a simpler playback that users can easily follow and try

muralisr (Tue, 09 Jan 2018 14:15:56 GMT):
this would kill two birds with 1 stone

muralisr (Tue, 09 Jan 2018 14:16:12 GMT):
(a round about way of answering your q. ... :-) )

muralisr (Tue, 09 Jan 2018 14:16:59 GMT):
which is I think its ready and with a bit of doc can actually do it ... I'd need nick's help though

dave.enyeart (Tue, 09 Jan 2018 14:17:07 GMT):
the threshold for inclusion as a production feature should go beyond "it works". for example private data "works", but i'd like to keep it as an experimental feature during 1.1 timeframe so that we can collect community feedback and have ability to make improvements prior to it becoming a production feature.

muralisr (Tue, 09 Jan 2018 14:17:33 GMT):
agreed

muralisr (Tue, 09 Jan 2018 14:17:49 GMT):
which is why I need a good sample playback and doc

muralisr (Tue, 09 Jan 2018 14:18:19 GMT):
the one I have in mind will basically create various resource with different policies for +ve and -ve tests

muralisr (Tue, 09 Jan 2018 14:18:51 GMT):
I'm ok with experimental too

dave.enyeart (Tue, 09 Jan 2018 14:18:57 GMT):
sounds good... i agree 5664 and 3621 make sense to evaluate together

jyellick (Tue, 09 Jan 2018 14:45:03 GMT):
It's a little hard for me to tell from the conversation above whether @yacovm is handling FAB-2005 or not, but if not, I'd be happy to act as advocate.

yacovm (Tue, 09 Jan 2018 14:45:12 GMT):
I am not

yacovm (Tue, 09 Jan 2018 14:45:16 GMT):
be my guest :)

dave.enyeart (Tue, 09 Jan 2018 15:23:26 GMT):
Ok great, so to summarize the maintainer advocates for the Experimental features: https://jira.hyperledger.org/browse/FAB-1151 Side DB - Dave https://jira.hyperledger.org/browse/FAB-3621 RBAC - Murali https://jira.hyperledger.org/browse/FAB-5664 Distinguish MSP Identity Types - Murali https://jira.hyperledger.org/browse/FAB-2005 Identity Mixer - Jason https://jira.hyperledger.org/browse/FAB-1973 Java Chaincode - TBD After you dig in, we’ll look for your recommendations regarding keeping the feature Experimental vs making a production feature.

cbf (Thu, 11 Jan 2018 18:07:40 GMT):
@here we've been talking/thinking about having a maintainers meeting - well, the opportunity has manifested itself

cbf (Thu, 11 Jan 2018 18:08:25 GMT):
the State Street guys have agreed to host in Boston on 2/5 (I think that this needs to be finalized, but there, I said it)

cbf (Thu, 11 Jan 2018 18:09:27 GMT):
I presume that @greg.haskins, @binhn or @muralisr will provide logistics info when finalized

cbf (Thu, 11 Jan 2018 18:10:01 GMT):
we'll use this day to plan our 1.2 release - really ;-)

cbf (Thu, 11 Jan 2018 18:11:18 GMT):
note that the only reason that we're going to Boston is because that's the only place we can count on Greg showing up... we could have had it in FL

cbf (Thu, 11 Jan 2018 20:02:19 GMT):
----

cbf (Thu, 11 Jan 2018 20:06:00 GMT):
@here a bunch of us (including @mastersingh24, @sykesm and others) and we agreed that the behave tests are not adding value, they need to be frequently re-run and we have no one to maintain the code. Hence, we think that since the end-to-end (fabric-samples/first-network) does the same thing, that we should simply remove the behave verify step in CI

sykesm (Thu, 11 Jan 2018 20:06:00 GMT):
Has joined the channel.

jyellick (Thu, 11 Jan 2018 20:07:31 GMT):
There are some holes, especially around multi-sig config updates which the behave covers, but which the e2e cli does not. I'd suggest that we try to identifies any such things and port them into the e2e.

yacovm (Thu, 11 Jan 2018 20:07:59 GMT):
FWIW i've never seen a bug that behave caught that wasn't caught in golang UTs or e2e

cbf (Thu, 11 Jan 2018 20:08:04 GMT):
they can be ported to the integration tests (fabric-test repo) that get run nightly

cbf (Thu, 11 Jan 2018 20:08:31 GMT):
@yacovm yes, that was my and Gari's thinking as well

cbf (Thu, 11 Jan 2018 20:09:09 GMT):
but to @jyellick point, yes, we can add to first-network

cbf (Thu, 11 Jan 2018 20:10:05 GMT):
we will likely want to rethink how we handle bdd testing - possibly using ginko or go-behave

cbf (Thu, 11 Jan 2018 20:10:21 GMT):
so that we don't have the issue of YAPL

latitiah (Thu, 11 Jan 2018 20:26:26 GMT):
Has joined the channel.

ArnabChatterjee (Fri, 12 Jan 2018 06:02:03 GMT):
Has joined the channel.

mastersingh24 (Fri, 12 Jan 2018 18:43:26 GMT):
Well no one really understands most of the policy stuff truth be told (https://chat.hyperledger.org/channel/fabric-maintainers?msg=tmPGAjEQeWggsqfFe) @muralisr

mastersingh24 (Fri, 12 Jan 2018 18:43:52 GMT):
I think the whole MSP and policy stuff needs "how to" documentation

mastersingh24 (Fri, 12 Jan 2018 18:44:12 GMT):
I do think 5664 should likely go in

JonathanLevi (Fri, 12 Jan 2018 18:49:43 GMT):
TBH, "how to" and more examples.

JonathanLevi (Fri, 12 Jan 2018 18:50:26 GMT):
The flexibility is so powerful there, but I know for a fact that many are afraid to "push the boundaries" there, and "walk close to the pavement"

JonathanLevi (Fri, 12 Jan 2018 18:51:59 GMT):
The flexibility is so powerful there, but I know for a fact that many are afraid to "push the boundaries" there, are afraid to "stray too far from the sidewalk"

JonathanLevi (Fri, 12 Jan 2018 18:51:59 GMT):
The flexibility is so powerful there, but I know for a fact that many are afraid to "push the boundaries" or to "stray too far from the sidewalk"

jyellick (Fri, 12 Jan 2018 18:53:49 GMT):
I'd agree that more documentation is definitely needed around policies, especially with respect to examples. Maybe we can open up some JIRAs for this?

jyellick (Fri, 12 Jan 2018 18:55:14 GMT):
On an unrelated note. After some last minute discussion with the authors, as the advocate for https://jira.hyperledger.org/browse/FAB-2005 Identity Mixer, I'm going to propose that we leave it as is -- experimental -- for v1.1. Although there is an e2e example in review, without SDK support, it is not a compelling story for our users, so I think we should reject the e2e integration of idemix, and release with full support in v1.2.

yacovm (Fri, 12 Jan 2018 18:55:59 GMT):
Makes sense

yacovm (Fri, 12 Jan 2018 18:55:59 GMT):
Makes sensem Jason

yacovm (Fri, 12 Jan 2018 18:55:59 GMT):
Makes sense, Jason

JonathanLevi (Fri, 12 Jan 2018 18:56:00 GMT):
BTW: I fully agree.

JonathanLevi (Fri, 12 Jan 2018 18:57:08 GMT):
I haven't had enough time to play with the recent version either... (even though I'm not an official "Advocate") - I think this approach will be much better both for Fabric and IdMix.

JonathanLevi (Fri, 12 Jan 2018 18:58:03 GMT):
We really don't more rounds of asynchronous "blog wars". I'd rather play it save (again) and commit to the things that we have all "battle-" tested.

JonathanLevi (Fri, 12 Jan 2018 18:58:32 GMT):
We really don't more rounds of asynchronous "blog wars". I'd rather play it safe (again) and commit to the things that we have all "battle-" tested.

yacovm (Fri, 12 Jan 2018 18:59:01 GMT):
blog wars?

yacovm (Fri, 12 Jan 2018 18:59:25 GMT):
I always thought of them as a 1-sided attack

JonathanLevi (Fri, 12 Jan 2018 19:00:04 GMT):
*Some* of us [:-)] may recall a few attacks over the "Channels - for sharing confidential information"...

JonathanLevi (Fri, 12 Jan 2018 19:00:34 GMT):
@yacovm Fair point, actually. I/we were mostly defending a misinterpretation.

muralisr (Fri, 12 Jan 2018 19:18:52 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=GdJ2MfmcBqCeLKE23

muralisr (Fri, 12 Jan 2018 19:20:15 GMT):
had a hangout session with adc on MSP where we discussed what docs and samples woukld be needed to make MSP Role enhancelments easy to use ./ understand

muralisr (Fri, 12 Jan 2018 19:20:39 GMT):
adc was going to work on getting the docs and readmes for this ... hopefully not later than next week

muralisr (Fri, 12 Jan 2018 19:20:55 GMT):
I'll continue to work with him on that

muralisr (Fri, 12 Jan 2018 19:22:11 GMT):
given that @mastersingh24 @dave.enyeart it may be ok to get that feature in (no one questions the usefulness of that I think ?) .. I have +1 (but @dave.enyeart please do check with adc if he;ll be more comfortable getting it in next release)

muralisr (Fri, 12 Jan 2018 19:22:11 GMT):
given that @mastersingh24 @dave.enyeart it may be ok to get that feature in (no one questions the usefulness of that I think ?) .. +1 from me (but @dave.enyeart please do check with adc if he;ll be more comfortable getting it in next release)

mastersingh24 (Fri, 12 Jan 2018 19:23:14 GMT):
makes sense @muralisr

muralisr (Fri, 12 Jan 2018 19:30:07 GMT):
the discussion of using MSP Roles with adc actually nicely dovetailed with the sample I was working on to show case 3621 (resource based ACL) using thos MSP Roles. The sample did work for me (I just was not comfortable with the way I had organized MSPs to get it to work for excercising resource based ACL). So that drove the discussion with adc on docs samples and holes in the current way user species MSPs ... long story short, I feel comfortable with 3621 ... the code path has been excercised for a while with defalt 1.0 behavior and the resource stuff is really a thin veneer on top of the config resource abstraction (especially with the removal of RSCC system chaincode whose work has been subsumed by the policy config code). I believe it has value - opens up ACL mechanisms which is something we are likley to see more and more usage of IMO

muralisr (Fri, 12 Jan 2018 19:30:39 GMT):
with that, I'd be ok with getting 3621 in also - but leave it to other maintainers to decide

muralisr (Fri, 12 Jan 2018 19:32:26 GMT):
of course I'll work on docs and samples (hoping to use the MSP Roles once we have adc docs and samples to point to)

jyellick (Fri, 12 Jan 2018 19:47:16 GMT):
My concern about 3621 is that there have been concerns about the non-endorser based update flow. Especially from @manish-sethi , and if we are not confident about the tx format for updates, then the experimental flag seems appropriate.

yacovm (Fri, 12 Jan 2018 19:50:12 GMT):
But Jason - this only enables you to classify the type of identity, no?

yacovm (Fri, 12 Jan 2018 19:50:22 GMT):
this has nothing to do with deciding the actual enforcement?

jyellick (Fri, 12 Jan 2018 19:53:36 GMT):
@yacovm You are thinking of 5664 Distinguished MSP Identity Types, not 3621 RBAC

jyellick (Fri, 12 Jan 2018 19:54:33 GMT):
(Or perhaps I am confused, but I thought 3621 referred to the assorted ACL items which were populated from the resources tree)

jyellick (Fri, 12 Jan 2018 19:55:42 GMT):
Assuming we feel good about the code/testing/documentation/examples for 5564, I would vote to include it non-experimental

yacovm (Fri, 12 Jan 2018 19:55:48 GMT):
oh oops

yacovm (Fri, 12 Jan 2018 19:56:01 GMT):
mixed them up.

muralisr (Fri, 12 Jan 2018 19:57:48 GMT):
` and if we are not confident about the tx format for updates, then the experimental flag seems appropriate.` - agreed

muralisr (Fri, 12 Jan 2018 19:57:48 GMT):
@jyellick ` and if we are not confident about the tx format for updates, then the experimental flag seems appropriate.` - agreed

muralisr (Fri, 12 Jan 2018 19:59:04 GMT):
I was assuming that the codepath for update is something that is handled uniformly by the common config update code

muralisr (Fri, 12 Jan 2018 19:59:08 GMT):
is that not true ?

jyellick (Fri, 12 Jan 2018 19:59:19 GMT):
It is a new transaction type RESOURCE_UPDATE

jyellick (Fri, 12 Jan 2018 19:59:19 GMT):
It is a new transaction type PEER_RESOURCE_UPDATE

jyellick (Fri, 12 Jan 2018 19:59:42 GMT):
But which uses the common config update code in implementation

muralisr (Fri, 12 Jan 2018 19:59:47 GMT):
right

muralisr (Fri, 12 Jan 2018 20:00:00 GMT):
so the concern is we have not tried it out to make sure it works ?

jyellick (Fri, 12 Jan 2018 20:00:10 GMT):
I will let @manish-sethi express himself, but he would rather see this implemented in the peer state DB

muralisr (Fri, 12 Jan 2018 20:00:12 GMT):
or is there a deeper concern ?

jyellick (Fri, 12 Jan 2018 20:00:52 GMT):
Basically, the channel config implements its own simple (and less powerful) MVCC over the assorted keys

jyellick (Fri, 12 Jan 2018 20:01:32 GMT):
Which does not lend itself well to parallelism, and duplicates what exists in the statedb. This was necessary for channel config, as the orderer must process it (and has no statedb), but it is a valid question whether this should be the same for the peer and the resources tree.

manish-sethi (Fri, 12 Jan 2018 20:03:30 GMT):
yes, my main concern was that we would not want to have two transaction processing techniques with a different semantics and behavior...

muralisr (Fri, 12 Jan 2018 20:04:34 GMT):
let me make sure I understand @manish-sethi ... is this about not using config tx but using invoke tx ?

manish-sethi (Fri, 12 Jan 2018 20:06:56 GMT):
yes, However, I would add that using the endorsement way is more important than invoke.

manish-sethi (Fri, 12 Jan 2018 20:08:10 GMT):
For instance, it could very well be an explicit APIs but yes, invoke is an obvious way.

manish-sethi (Fri, 12 Jan 2018 20:17:58 GMT):
Murali, just pinged on phone and said that he needs to board a flight and will like to continue on this later..

jyellick (Fri, 12 Jan 2018 20:18:40 GMT):
This is a valuable conversation, and I don't meant o derail it, but I thin it demonstrates that: > we are not confident about the tx format for updates So, leave 3621 as experimental?

jyellick (Fri, 12 Jan 2018 20:18:40 GMT):
This is a valuable conversation, and I don't meant to derail it, but I thin it demonstrates that: > we are not confident about the tx format for updates So, leave 3621 as experimental?

jyellick (Fri, 12 Jan 2018 20:18:40 GMT):
This is a valuable conversation, and I don't meant to derail it, but I think it demonstrates that: > we are not confident about the tx format for updates So, leave 3621 as experimental?

muralisr (Fri, 12 Jan 2018 20:21:57 GMT):
yes, I'm ok with that @jyellick

muralisr (Fri, 12 Jan 2018 20:22:59 GMT):
but with the endorsement approach we are back to RSCC based approach ....

muralisr (Fri, 12 Jan 2018 20:24:11 GMT):
@manish-sethi we can take this up later but we _do_ have two models - config and endorsment ... if its a "configuration" then it makes sense to do it the config way

muralisr (Fri, 12 Jan 2018 20:24:47 GMT):
I have gotten used to thinking of this as a kind of configuration update

muralisr (Fri, 12 Jan 2018 20:25:41 GMT):
so have grown used to thinking about that that way

muralisr (Fri, 12 Jan 2018 20:26:10 GMT):
doesn't mean its correct ... on the other hand, would need to be convinced that its wrong :-)

muralisr (Fri, 12 Jan 2018 20:27:05 GMT):
(btw, the plane is delayed a bit... but we certaintly can continue later Manish)

muralisr (Fri, 12 Jan 2018 20:31:25 GMT):
` my main concern was that we would not want to have two transaction processing techniques with a different semantics and behavior...` - I;d turn this on its head and ask "what transaction does a resource update that spans the entire peer (as the resources are peer-wide) mean ? And who will have to endorse it ?"

muralisr (Fri, 12 Jan 2018 20:31:25 GMT):
` my main concern was that we would not want to have two transaction processing techniques with a different semantics and behavior...` - I;d turn this on its head and ask "what transaction does a resource update that spans the entire peer (as the resources are channel-wide ) mean ? And who will have to endorse it ?"

manish-sethi (Fri, 12 Jan 2018 21:16:05 GMT):
Murali, the way I see it is - it is just another dataset that we need to perform CURD operations on and it is channel wise, so would be endorsement policies for this. How is it different than managing the business data?

manish-sethi (Fri, 12 Jan 2018 21:16:05 GMT):
Murali, the way I see it is - it is just another dataset that we need to perform CURD operations on and it is channel-wide, so would be endorsement policies for this. How is it different than managing the business data?

manish-sethi (Fri, 12 Jan 2018 21:16:05 GMT):
Murali, the way I see it is - it is just another dataset that we need to perform CRUD operations on and it is channel-wide, so would be endorsement policies for this. How is it different than managing the business data?

muralisr (Sat, 13 Jan 2018 16:44:39 GMT):
@manish-sethi from user perspective - we have a mechanism for managing channel wide config. And that is via channel transactions. I think of Channel resources fits well in that flow path (and fits with the way we currently define policies, msps etc). (Contrast this with the chaincode specific configuraion which we tried to do using config tx which seemed better belong to the TX model you allude to.) What am I missing ?

muralisr (Sat, 13 Jan 2018 16:49:13 GMT):
Feels like you are coming from an implementation perspect (why have two different data models - config tx vs endorsment tx) whereas I'm coming from a user flow perspective (this is a channel wide definition and we shoukd use existing channel tx to define this).

binhn (Sat, 13 Jan 2018 17:24:51 GMT):
@here I emailed all maintainers this morning about the face-to-face meeting at State Street in Boston on 2/05, please check your inbox. Thanks.

yingmsky (Mon, 15 Jan 2018 02:26:39 GMT):
Has joined the channel.

newlife 1 (Mon, 15 Jan 2018 08:49:36 GMT):
Has joined the channel.

dave.enyeart (Mon, 15 Jan 2018 19:27:49 GMT):
@here Besides the few remainders listed in the 1.1 dashboard https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701, we have achieved FEATURE FREEZE for 1.1. Maintainers will not merge other features/improvements through the remainder of the release. Bug fixes, doc updates, and samples are still highly encouraged. There will be a large focus on fixes, doc, samples, and system test this week, with expectation that alpha is cut next week.

dave.enyeart (Mon, 15 Jan 2018 19:27:49 GMT):
@here Besides the few remainders listed in the 1.1 dashboard https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701, we have achieved FEATURE FREEZE for 1.1. Maintainers will not merge other features/improvements through the remainder of the release. Bug fixes, doc updates, samples, and system test are the priority this week, with expectation that alpha is cut next week.

dave.enyeart (Mon, 15 Jan 2018 19:27:49 GMT):
@here Besides the few In-Review and SDK remainders listed in the 1.1 dashboard https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701, we have achieved FEATURE FREEZE for 1.1. Maintainers will not merge other features/improvements through the remainder of the release. Bug fixes, doc updates, samples, and system test are the priority this week, with expectation that alpha is cut next week.

manish-sethi (Tue, 16 Jan 2018 02:59:38 GMT):
@muralisr - Sorry, got occupied in some of the CRs.. To your earlier comment, I think that I am not clear on your division of configuration types well. For instance, when you say 'chaincode specific' - how is different than when you would say an API specific configuration? If you want to discuss this further in detail, we can do it on a direct chat. If you prefer to wait till @jyellick lays out the details for the lifecycle stuff so we have something concrete to discuss further - that would be good.

muralisr (Tue, 16 Jan 2018 03:10:40 GMT):
@manish-sethi I was not talking about chaincode lifecycle and any configuration that were laid out for that. I was specifically referring to FAB-3621 where resource were defined and configured to control various ACLs for a channel (including a resource used for ACL for Proposal - nothing to do with a chaincode, to drive home the point). My assumption was that we will continue to have channel TX definining configuration for channel and resource for ACL seemed to fit that model.

muralisr (Tue, 16 Jan 2018 03:12:40 GMT):
But to avoid discussion in vacuo, let's wait for a concrete proposal - there's no urgency now that we have agreed to let this be experimental

dave.enyeart (Tue, 16 Jan 2018 11:25:57 GMT):
From the above discussions it sounds like the consensus for the Experimental Features in 1.1 is the following:

dave.enyeart (Tue, 16 Jan 2018 11:25:57 GMT):
@here From the above discussions it sounds like the consensus for the Experimental Features in 1.1 is the following:

dave.enyeart (Tue, 16 Jan 2018 11:26:17 GMT):
https://jira.hyperledger.org/browse/FAB-1151 Side DB - Dave - Keep Experimental https://jira.hyperledger.org/browse/FAB-3621 RBAC - Murali - Keep Experimental https://jira.hyperledger.org/browse/FAB-5664 Distinguish MSP Identity Types - Murali with Angelo - *Promote to production feature* https://jira.hyperledger.org/browse/FAB-2005 Identity Mixer - Jason with Maria - Keep Experimental https://jira.hyperledger.org/browse/FAB-1973 Java Chaincode - Keep Experimental

dave.enyeart (Tue, 16 Jan 2018 11:26:27 GMT):
I discussed FAB-5664 Distinguish MSP Identity Types with @adc.

dave.enyeart (Tue, 16 Jan 2018 11:26:27 GMT):
I discussed FAB-5664 Distinguish MSP Identity Types with @adc

dave.enyeart (Tue, 16 Jan 2018 11:26:37 GMT):
The only remaining part of this one is samples, doc, system test.

dave.enyeart (Tue, 16 Jan 2018 11:27:57 GMT):
@adc , @muralisr , for system test it would be helpful if you could partner with testers to add system test scenarios in the associated test jira: https://jira.hyperledger.org/browse/FAB-6456 .

dave.enyeart (Tue, 16 Jan 2018 11:28:06 GMT):
To help with samples and doc, it would be nice if cryptogen supported OUs. There is already a CR out for review: https://gerrit.hyperledger.org/r/#/c/15483/

dave.enyeart (Tue, 16 Jan 2018 11:28:06 GMT):
To help with samples and doc, it would be nice if cryptogen supported OUs. There is already a CR out for review that Angelo is trying to get in: https://gerrit.hyperledger.org/r/#/c/15483/

dave.enyeart (Tue, 16 Jan 2018 11:28:12 GMT):
Since it touches no server code and would help with samples/doc/consumability, I’m amenable to it going in as part of the sample work effort. Thoughts?

dave.enyeart (Tue, 16 Jan 2018 11:28:18 GMT):
I’ve tagged it as review-needed. Since we are in Feature Freeze I’m thinking we should start following the precedent of 5 votes required to get something in. Sound good?

dave.enyeart (Tue, 16 Jan 2018 11:28:18 GMT):
I’ve tagged the associated jira FAB-6986 as review-needed. Since we are in Feature Freeze I’m thinking we should start following the precedent of 5 votes required to get something in. Sound good?

dave.enyeart (Tue, 16 Jan 2018 12:06:52 GMT):
On a related note, we also need to document the concept of Experimental features and the Experimental build tag. I've created FAB-7746, any volunteers?

muralisr (Tue, 16 Jan 2018 12:28:11 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=H4bFWG5YXKC3Hk9XY

muralisr (Tue, 16 Jan 2018 12:28:35 GMT):
@dave.enyeart ^^^ you got it

yacovm (Thu, 18 Jan 2018 18:02:54 GMT):
Does this https://gerrit.hyperledger.org/r/#/c/16947/ count as a feature?

jyellick (Thu, 18 Jan 2018 18:43:55 GMT):
As it has no affect on the output of the build, I would personally be inclined not to define it as a feature (with respect to our 'feature freeze')

jyellick (Thu, 18 Jan 2018 18:43:55 GMT):
As it has no effect on the output of the build, I would personally be inclined not to define it as a feature (with respect to our 'feature freeze')

dave.enyeart (Thu, 18 Jan 2018 19:12:04 GMT):
Agreed, I'm more worried about logic changes, I'm fine with these small improvements.

Brucepark (Sat, 20 Jan 2018 06:15:16 GMT):
Has joined the channel.

dave.enyeart (Thu, 25 Jan 2018 05:06:42 GMT):
@here We will checkpoint on Thursday to determine if there is anything that would block cutting a 1.1 alpha release. Please speak up if you know of any must-fix bug or must-merge CR. Per the query at https://jira.hyperledger.org/issues/?filter=11901, there are only two highlighted currently. From discussion with @smithbk , it sounds like we want to get FAB-7812 in, while FAB-7844 could likely be deferred from alpha.

dave.enyeart (Thu, 25 Jan 2018 05:13:17 GMT):
There is one more doc CR out for review for event deliver and filtering: https://gerrit.hyperledger.org/r/#/c/17139/ . Although it is not perfect, my opinion is it would be better to merge for alpha and iterate later, rather than to hold it out. If somebody wants to make edits and post another patch, that would be fine as well.

dave.enyeart (Thu, 25 Jan 2018 05:15:12 GMT):
And finally there is likely a doc CR around upgrade coming. Although if it doesn't come in time we could merge post-alpha then point people to the master readthedocs .

dave.enyeart (Thu, 25 Jan 2018 05:30:10 GMT):
@jyellick @kostas I discussed with Luis this afternoon, we agreed that the current Kafka 0.10.2.1 in baseimage 0.4.5 would be sufficient for alpha. Agreed?

dave.enyeart (Thu, 25 Jan 2018 05:30:49 GMT):
He said he's like to bump up Kafka again soon after alpha

dave.enyeart (Thu, 25 Jan 2018 05:30:49 GMT):
He said he'd like to bump up Kafka again soon after alpha

jyellick (Thu, 25 Jan 2018 05:30:59 GMT):
@dave.enyeart I believe a CR was merged earlier today to bump Kafka to v1.0.0

jyellick (Thu, 25 Jan 2018 05:31:16 GMT):
https://gerrit.hyperledger.org/r/c/17121/

dave.enyeart (Thu, 25 Jan 2018 05:31:26 GMT):
right, that would be for the next baseimage. But we can go with current baseimage of 0.4.5 which includes 0.10.2.1.

dave.enyeart (Thu, 25 Jan 2018 05:31:26 GMT):
right, that would be for the next baseimage. But we can go with current baseimage of 0.4.5 for alpha, which includes 0.10.2.1.

dave.enyeart (Thu, 25 Jan 2018 05:33:46 GMT):
https://hub.docker.com/r/hyperledger/fabric-kafka/tags/

jyellick (Thu, 25 Jan 2018 05:34:16 GMT):
My mistake -- from an alpha perspective, I'd agree with Luis's assessment that the Kafka version is not critical. If we could publish the alpha on a newer base image, all the better, but Kafka is a stable project, I think the delay is low risk

dave.enyeart (Thu, 25 Jan 2018 05:35:10 GMT):
we only have about 1 days test experience on 0.4.5. would rather not reset the clock on testing another baseimage for alpha.

dave.enyeart (Thu, 25 Jan 2018 05:35:10 GMT):
we only have about 1 days test experience on 0.4.5. would rather not reset the clock again on testing another baseimage for alpha.

jyellick (Thu, 25 Jan 2018 05:36:59 GMT):
The lack of test time on 0.4.5 is also an argument that we are not losing much by bumping to a newer version, are there any changes other than Kafka that would be pulled into an 0.4.6 image?

dave.enyeart (Thu, 25 Jan 2018 05:37:44 GMT):
kafka would be the only change. i was also concerned about the jump from 0.10.2.1 to 1.0.0 being larger than the prior jumps.

dave.enyeart (Thu, 25 Jan 2018 05:38:08 GMT):
i.e., would want more than 1 day of test if we jump to 1.0.0.

dave.enyeart (Thu, 25 Jan 2018 05:40:28 GMT):
let me re-phrase... the ship is set for 0.4.5. there would have to be a compelling reason to change.

dave.enyeart (Thu, 25 Jan 2018 05:40:28 GMT):
let me re-phrase... the ship is set for 0.4.5. there would have to be a compelling reason to change and delay alpha for the required testing.

jyellick (Thu, 25 Jan 2018 05:40:43 GMT):
I would say bumping the Kafka version is very low risk, and, there are some nice bug fixes that come along if we move to 0.11+. My inclination would be to include the new Kafka in alpha, but I welcome feedback from @kostas or others.

jyellick (Thu, 25 Jan 2018 05:42:11 GMT):
(But, since it is low risk, I'm not sure that we lose a lot if we delay until post-alpha)

dave.enyeart (Thu, 25 Jan 2018 05:43:26 GMT):
refresh my memory on the numbering convention. 1.0.0 vs 0.11+

jyellick (Thu, 25 Jan 2018 05:48:16 GMT):
@dave.enyeart There is no significant departure or incompatibility between v0.11 and v1.0.0. The v1.0.0 label I believe is supposed to be more of an indicator that the Kafka maintainers believe Kafka is officially 'stable' and 'enterprise ready'. https://www.confluent.io/blog/apache-kafka-goes-1-0/

dave.enyeart (Thu, 25 Jan 2018 05:58:03 GMT):
It says "As you can see, 1.0.0 is a significant release with real enhancements." To me this says, it deserves some test time, and we should not make the update a day before alpha release. But I am willing to listen to the majority here.

mastersingh24 (Thu, 25 Jan 2018 08:22:52 GMT):
@dave.enyeart - from a consumption point of view, Kafka v0.11 and v1.0.0 are equivalent. v0.11 introduced new features and v1.0.0 was a hardening of v0.11

mastersingh24 (Thu, 25 Jan 2018 08:23:39 GMT):
So if we are going to move from 0.10.2.x, we should make the jump to 1.0.0 rather than 0.11

dave.enyeart (Thu, 25 Jan 2018 11:58:15 GMT):
Ok. I'll still say the plan of record is to go with 0.10.2.1 using the 0.4.5 base image this week. Anybody see a problem with that?

dave.enyeart (Thu, 25 Jan 2018 11:58:15 GMT):
Ok. I'll still say the plan of record is to go with 0.10.2.1 using the 0.4.5 base image this week. And then test with 1.0.0 starting next week for inclusion in beta / release candidates. Anybody see a problem with that?

dave.enyeart (Thu, 25 Jan 2018 11:59:19 GMT):
We could use another +2 on https://gerrit.hyperledger.org/r/#/c/17115/ . It is harmless per @C0rWin

kostas (Thu, 25 Jan 2018 14:47:23 GMT):
> Ok. I'll still say the plan of record is to go with 0.10.2.1 using the 0.4.5 base image this week. And then test with 1.0.0 starting next week for inclusion in beta / release candidates. Anybody see a problem with that? (This sounds like a reasonable strategy to me.)

cbf (Thu, 25 Jan 2018 16:00:47 GMT):
@dave.enyeart how are we doing?

dave.enyeart (Thu, 25 Jan 2018 16:02:18 GMT):
Ramesh is looking at a change for bootstrap script

dave.enyeart (Thu, 25 Jan 2018 16:02:42 GMT):
@C0rWin is pushing his event client example readme any minute

C0rWin (Thu, 25 Jan 2018 16:02:57 GMT):
already done

C0rWin (Thu, 25 Jan 2018 16:02:58 GMT):
;)

dave.enyeart (Thu, 25 Jan 2018 16:02:59 GMT):
Upgrade doc should come in this afternoon, although we don't necessarily need to wait for that

C0rWin (Thu, 25 Jan 2018 16:03:38 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Foew4Ja7XiJAovALJ) @dave.enyeart https://gerrit.hyperledger.org/r/#/c/16919/

dave.enyeart (Thu, 25 Jan 2018 16:04:07 GMT):
I propose for readthedocs that we NOT push a 1.1.0-alpha release, rather we simply point people to master readthedocs so that we can keep iterating and allow people to see the latest. What do you think @cbf @mastersingh24

cbf (Thu, 25 Jan 2018 16:05:23 GMT):
that scares me a little since we'll be churning some of the docs

dave.enyeart (Thu, 25 Jan 2018 16:05:28 GMT):
Finally, we need to levelset on Node and Java SDK release activities, especially considering that we haven't been able to get a hold of @jimthematrix

cbf (Thu, 25 Jan 2018 16:05:35 GMT):
mixing md and rst

cbf (Thu, 25 Jan 2018 16:05:40 GMT):
refactoring the toc

cbf (Thu, 25 Jan 2018 16:05:41 GMT):
etc

dave.enyeart (Thu, 25 Jan 2018 16:06:13 GMT):
ok, so if we want to point people to 1.1.0-alpha readthedocs, it would be good to get Joe's upgrade doc in later today

dave.enyeart (Thu, 25 Jan 2018 16:06:13 GMT):
ok, so if we want to point people to 1.1.0-alpha readthedocs, it would be good to get Joe's upgrade doc in later today before cutting fabric

dave.enyeart (Thu, 25 Jan 2018 16:07:50 GMT):
And the LAST bug that we are waiting for is in CI currently: https://gerrit.hyperledger.org/r/#/c/17107/

cbf (Thu, 25 Jan 2018 16:18:55 GMT):
+1

cbf (Thu, 25 Jan 2018 16:19:14 GMT):
also, I just realized I started on FAB-7782 and asked you to provide the prose...

cbf (Thu, 25 Jan 2018 16:19:29 GMT):
I can check in what I have and you can pick up from there, ok?

cbf (Thu, 25 Jan 2018 16:22:03 GMT):
@dave.enyeart https://gerrit.hyperledger.org/r/17183

dave.enyeart (Thu, 25 Jan 2018 16:23:32 GMT):
Sure, i haven't done that before, so let me know any tips

dave.enyeart (Thu, 25 Jan 2018 16:23:32 GMT):
@here I've pushed 1.1 release notes : https://gerrit.hyperledger.org/r/#/c/17183/2/release_notes/v1.1.0-alpha.txt

jyellick (Thu, 25 Jan 2018 16:49:06 GMT):
https://gerrit.hyperledger.org/r/c/17155/ ^ I'd also like to propose that we make sure this one gets in for alpha. Presently, if someone upgrades their orderer docker image but does not upgrade their Kafka (or override the default version in the config), the only failure sign in the log they see is a debug level message: ```kafka: error while consuming 0x42027c0f0.channel/0: kafka: insufficient data to decode package, more bytes expected``` The above CR adds an informative critical level log message about the underlying problem. Without it, I think we are going to spend a lot of time fielding questions as people try to debug.

dave.enyeart (Thu, 25 Jan 2018 18:39:27 GMT):
Any other features to highlight?

dave.enyeart (Thu, 25 Jan 2018 18:43:41 GMT):
I'm thinking for next release we should list out other improvements beyond features. If we keep Jira clean we can simply use the Jira Epics/Features to build the feature list, and the Jira Improvements to build the improvement list.

dave.enyeart (Thu, 25 Jan 2018 19:07:17 GMT):
@kostas @jyellick would Fabric 1.0.5 work using Kafka 0.10.2.1? I'm asking because with the proposed bootsrap.sh in https://gerrit.hyperledger.org/r/#/c/17181/ , if you don't pass a Fabric version, it would give you 1.0.5 binaries and 1.0.5 peer/orderer/ca images, but give you the latest kafka (0.10.2.1) tagged with baseimage 0.4.5.

dave.enyeart (Thu, 25 Jan 2018 19:08:03 GMT):
Given the way we tag 3rd parties images now, we may need to go back to a versioned bootstrap.sh approach, to ensure we get all the right levels.

jyellick (Thu, 25 Jan 2018 19:08:04 GMT):
@dave.enyeart Yes, Fabric v1.0.5 should work with any Kafka version > 0.9.0.1

jyellick (Thu, 25 Jan 2018 19:08:04 GMT):
@dave.enyeart Yes, Fabric v1.0.5 should work with any Kafka version >= 0.9.0.1

jyellick (Thu, 25 Jan 2018 19:08:54 GMT):
The `orderer.yaml` file specifies a `Kafka.Version`, this indicates the version of the wire protocols to speak. Newer versions of Kafka understand the older protocol versions (though there might be some minor performance degradation)

dave.enyeart (Thu, 25 Jan 2018 19:09:45 GMT):
@mastersingh24 what do you think of the proposed bootstrap.sh?

dave.enyeart (Thu, 25 Jan 2018 21:00:18 GMT):
Alpha release update - Need to close out the bootstrap.sh discussion above. I think what Ramesh has in https://gerrit.hyperledger.org/r/#/c/17181/ is workable for alpha, but will likely need to change post-alpha. - Upgrade doc will be pushed soon. TLS doc is hopeful for later this afternoon, but we won’t necessarily wait for it. - Will has just pushed a couple edits to the event example readme https://gerrit.hyperledger.org/r/#/c/16919/ . Please review/merge. - Besides the above, we are in MERGE FREEZE for Fabric. - A couple final SDK CRs coming in tonight (Saad and China). - Can likely start cutting Fabric tonight, and then finish out SDKs tomorrow.

dave.enyeart (Thu, 25 Jan 2018 21:01:00 GMT):
Let's shift discussion to #fabric-release , I will post the same there.

dave.enyeart (Thu, 25 Jan 2018 21:51:48 GMT):
@here Upgrade doc is posted, please help to review: https://gerrit.hyperledger.org/r/#/c/17223/

dave.enyeart (Thu, 25 Jan 2018 22:15:17 GMT):
@here TLS doc is posted, please help to review: https://gerrit.hyperledger.org/r/#/c/17229/

dave.enyeart (Thu, 25 Jan 2018 22:55:23 GMT):
@here Need one more +2 on event example and readme: https://gerrit.hyperledger.org/r/#/c/16919/

rjones (Thu, 25 Jan 2018 23:20:47 GMT):
there will be rolling outages to infra Monday. Please see: https://lists.hyperledger.org/pipermail/hyperledger-tsc/2018-January/001360.html this means Jenkins will be in shutdown mode until the queue is drained

rjones (Thu, 25 Jan 2018 23:20:47 GMT):
there will be rolling outages to infra in tommorrow. Please see: https://lists.hyperledger.org/pipermail/hyperledger-tsc/2018-January/001359.html this means Jenkins will be in shutdown mode until the queue is drained

yacovm (Thu, 25 Jan 2018 23:24:16 GMT):
Reviewed both @dave.enyeart

dave.enyeart (Fri, 26 Jan 2018 01:43:29 GMT):
ok, here's where we are:

dave.enyeart (Fri, 26 Jan 2018 01:44:01 GMT):
Joe is doing one final patch to address kostas comments: https://gerrit.hyperledger.org/r/#/c/17223

dave.enyeart (Fri, 26 Jan 2018 01:44:01 GMT):
Upgrade doc: Joe is doing one final patch to address kostas comments: https://gerrit.hyperledger.org/r/#/c/17223

dave.enyeart (Fri, 26 Jan 2018 01:44:01 GMT):
Upgrade doc: Joe addressed kostas comments, needs a final +2 and merge please: https://gerrit.hyperledger.org/r/#/c/17223

dave.enyeart (Fri, 26 Jan 2018 01:44:01 GMT):
Upgrade doc: Joe addressed @kostas comments, needs a final +2 and merge please: https://gerrit.hyperledger.org/r/#/c/17223

dave.enyeart (Fri, 26 Jan 2018 01:44:42 GMT):
TLS: https://gerrit.hyperledger.org/r/#/c/17229 . I don’t think we are going to resolve the review comments tonight. I would propose merge as is so that we have a starting point for alpha that can be iterated on post-alpha. Or does somebody want to attempt another patch tonight?

dave.enyeart (Fri, 26 Jan 2018 01:44:42 GMT):
TLS doc: https://gerrit.hyperledger.org/r/#/c/17229 . I don’t think we are going to resolve the review comments tonight. I would propose merge as is so that we have a starting point for alpha that can be iterated on post-alpha. Or does somebody want to attempt another patch tonight?

dave.enyeart (Fri, 26 Jan 2018 01:44:42 GMT):
TLS doc: https://gerrit.hyperledger.org/r/#/c/17229 . I don’t think we are going to resolve the review comments tonight. I think the document is a good start on a previously missing topic. I would propose merge as is so that we have a starting point for alpha that can be iterated on post-alpha. Or does somebody want to attempt another patch tonight?

dave.enyeart (Fri, 26 Jan 2018 01:46:07 GMT):
Event example and readme: https://gerrit.hyperledger.org/r/#/c/16919/ . Ready to merge.

dave.enyeart (Fri, 26 Jan 2018 01:46:07 GMT):
Event example and readme: https://gerrit.hyperledger.org/r/#/c/16919/ . Merged

dave.enyeart (Fri, 26 Jan 2018 12:51:55 GMT):
@here Gari volunteered to take a final pass at the TLS doc. We still need a final +2 on the upgrade doc please: https://gerrit.hyperledger.org/r/#/c/17223

dave.enyeart (Fri, 26 Jan 2018 12:51:55 GMT):
@here Gari volunteered to take a final pass at the TLS doc.

dave.enyeart (Fri, 26 Jan 2018 12:55:12 GMT):
We still need a final +2 on the upgrade doc please. It doesn't have to be perfect for alpha, I think it sufficiently conveys the upgrade concepts which was the main objective for alpha: https://gerrit.hyperledger.org/r/#/c/17223

dave.enyeart (Fri, 26 Jan 2018 13:47:45 GMT):
Ok, TLS and Upgrade doc both merged now. @cbf and I will cut alpha release today.

cbf (Fri, 26 Jan 2018 15:37:31 GMT):
https://chat.hyperledger.org/channel/fabric-release?msg=iQ5jkGZBhq4cz5sYg

dave.enyeart (Fri, 26 Jan 2018 15:53:45 GMT):
And please don't +2 or merge anything for release unless you are asked. @cbf and I will +2 and merge everything as we go through the prescribed sequence.

dave.enyeart (Fri, 26 Jan 2018 15:54:58 GMT):
And we are documenting the steps in more detail than ever in Jira as we go.

dave.enyeart (Fri, 26 Jan 2018 15:54:58 GMT):
And we are documenting the steps in more detail than ever in Jira as we go, so that subsequent releases go smoothly.

Dan (Fri, 26 Jan 2018 22:25:31 GMT):
Has left the channel.

dave.enyeart (Sat, 27 Jan 2018 01:42:16 GMT):
@here Hyperledger Fabric v1.1.0-alpha is now available! See the mailing list announcement for all the details: https://lists.hyperledger.org/pipermail/hyperledger-fabric/2018-January/002732.html

cbf (Sat, 27 Jan 2018 01:49:24 GMT):
yay, thanks @dave.enyeart

dave.enyeart (Sat, 27 Jan 2018 01:50:03 GMT):
and thanks for driving the release cutting @cbf !

dave.enyeart (Sat, 27 Jan 2018 01:53:03 GMT):
MERGE FREEZE over. Let's take defects down and increase test coverage! 1.1 here we come!

kostas (Mon, 29 Jan 2018 21:23:52 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=e87YuFQZQDRzdKCXo

kostas (Mon, 29 Jan 2018 21:24:01 GMT):
Link for this if you have it handy?

kostas (Mon, 29 Jan 2018 21:24:01 GMT):
Link for this if you have it handy? (I assume it's: https://jira.hyperledger.org/browse/FAB-7780)

dave.enyeart (Mon, 29 Jan 2018 23:09:39 GMT):
@kostas Yes that Jira for cutting the release has 20 subtasks, each including instructions for the release cutter. The Jira is cloned for each release cut (subtasks get cloned with it). And the following document from Ramesh includes more information about what is happening behind the scenes: https://docs.google.com/document/d/12IpQnREUoJEUj2pF2z-0Up55geItFd94fcsbAkPacTg/edit#

greg.haskins (Wed, 31 Jan 2018 16:29:48 GMT):
hey guys, isnt there a place to download cryptogen binaries?

greg.haskins (Wed, 31 Jan 2018 16:30:02 GMT):
i cant recall where it is: was looking in fabric/releases

dave.enyeart (Wed, 31 Jan 2018 17:45:50 GMT):
@greg.haskins If you follow the instructions here it will download the binaries including cryptogen:

dave.enyeart (Wed, 31 Jan 2018 17:45:57 GMT):
http://hyperledger-fabric.readthedocs.io/en/v1.1.0-alpha/samples.html#download-platform-specific-binaries

dave.enyeart (Wed, 31 Jan 2018 17:46:01 GMT):
What it is doing is running the script here:

dave.enyeart (Wed, 31 Jan 2018 17:46:06 GMT):
https://raw.githubusercontent.com/hyperledger/fabric/master/scripts/bootstrap.sh

dave.enyeart (Wed, 31 Jan 2018 17:46:10 GMT):
Which pulls the binaries tar for your platform, e.g.:

dave.enyeart (Wed, 31 Jan 2018 17:46:14 GMT):
https://nexus.hyperledger.org/content/repositories/releases/org/hyperledger/fabric/hyperledger-fabric/darwin-amd64-1.1.0-alpha/hyperledger-fabric-darwin-amd64-1.1.0-alpha.tar.gz

dave.enyeart (Wed, 31 Jan 2018 17:46:30 GMT):
So you could skip to that last step if you just want cryptogen :)

greg.haskins (Wed, 31 Jan 2018 18:46:56 GMT):
@dave.enyeart ty

dave.enyeart (Wed, 31 Jan 2018 19:26:03 GMT):
I've put several easy reviews in #fabric-pr-review . Let's try to make progress on review backlog so that we're not merging a bunch in the last week of 1.1. There is still a decent amount of system test happening in the weeks ahead, so better to get these small fixes in now, before system test gets too far along.

dave.enyeart (Thu, 01 Feb 2018 18:02:26 GMT):
https://jira.hyperledger.org/browse/FAB-6986 and it's CR https://gerrit.hyperledger.org/r/#/c/15483/ is a small cryptogen enhancement that will help explain our OU support via samples. Although we are in feature freeze, this is a small one and low risk since it is in tooling. I've upvoted it for inclusion in 1.1. Other's thoughts?

dave.enyeart (Thu, 01 Feb 2018 18:23:54 GMT):
Additionally, @jyellick is proposing some small updates to configtxlator to simplify upgrade (and upgrade is arguably in dire need of simplification): https://jira.hyperledger.org/browse/FAB-7999

dave.enyeart (Thu, 01 Feb 2018 18:23:54 GMT):
Additionally, @jyellick is proposing some small updates to configtxlator to simplify upgrade (and upgrade is arguably in need of any simplification that we can provide): https://jira.hyperledger.org/browse/FAB-7999 . The CRs are quite small: https://gerrit.hyperledger.org/r/#/c/17447/ and https://gerrit.hyperledger.org/r/#/c/17449/ .

dave.enyeart (Thu, 01 Feb 2018 18:23:54 GMT):
Additionally, @jyellick is proposing some small updates to configtxlator to simplify upgrade (and upgrade is arguably in need of any simplification that we can provide): https://jira.hyperledger.org/browse/FAB-7999 . The CRs are quite small and there is already a system test plan around them, so I'd say let's merge: https://gerrit.hyperledger.org/r/#/c/17447/ and https://gerrit.hyperledger.org/r/#/c/17449/ .

dave.enyeart (Thu, 01 Feb 2018 18:23:54 GMT):
Additionally, @jyellick is proposing some small updates to configtxlator to simplify upgrade (and upgrade is arguably in need of any simplification that we can provide): https://jira.hyperledger.org/browse/FAB-7999 . The CRs are quite small and there is already a system test and doc plan around them as part of the upgrade focus, so I'd say let's merge: https://gerrit.hyperledger.org/r/#/c/17447/ and https://gerrit.hyperledger.org/r/#/c/17449/ .

muralisr (Fri, 02 Feb 2018 02:11:39 GMT):
@dave.enyeart I support https://jira.hyperledger.org/browse/FAB-6986 and it's CR https://gerrit.hyperledger.org/r/#/c/15483 in principle. It will be useful for users using https://jira.hyperledger.org/browse/FAB-5664 I think.

muralisr (Fri, 02 Feb 2018 02:13:24 GMT):
+1 for https://jira.hyperledger.org/browse/FAB-7999 too

mastersingh24 (Fri, 02 Feb 2018 11:38:23 GMT):
@dave.enyeart - I don't support 6986 - it's too complex ... I have been out for a bit, but I can show a much simpler solution

dave.enyeart (Fri, 02 Feb 2018 12:11:53 GMT):
Ok. There are 5 maintainers in favor of FAB-7999. https://gerrit.hyperledger.org/r/#/c/17447 and https://gerrit.hyperledger.org/r/#/c/17449 can be merged.

dave.enyeart (Fri, 02 Feb 2018 12:33:59 GMT):
@mastersingh24 I'd suggest respond back to 6986 or https://gerrit.hyperledger.org/r/#/c/15483 with your thoughts. Angelo has freed up starting today to work on the OU samples, any guidance would be appreciated.

muralisr (Fri, 02 Feb 2018 14:50:09 GMT):
https://chat.hyperledger.org/channel/fabric-maintainers?msg=K3pTnE57uqFWxWKhP

muralisr (Fri, 02 Feb 2018 14:50:38 GMT):
right @mastersingh24 ..that's the reason for the "in principle" ... I remembered your reservations

muralisr (Fri, 02 Feb 2018 14:51:30 GMT):
if we can have some support for OUs, it'll be good

greg.haskins (Sat, 03 Feb 2018 15:34:48 GMT):
@dave.enyeart was just reviewing: https://jira.hyperledger.org/browse/FAB-7999

greg.haskins (Sat, 03 Feb 2018 15:35:00 GMT):
I seem to lack the ability to vote on it

greg.haskins (Sat, 03 Feb 2018 15:35:13 GMT):
because its done?

dave.enyeart (Sat, 03 Feb 2018 16:26:34 GMT):
@greg.haskins Yes we got the required upvotes (4 + maintainer reporter = 5). It has been merged and Done items can no longer be upvoted.

greg.haskins (Sat, 03 Feb 2018 16:28:57 GMT):
@dave.enyeart roger

JonathanLevi (Mon, 05 Feb 2018 14:35:35 GMT):
Are we broadcasting the maintainers' "summit" ?

JonathanLevi (Mon, 05 Feb 2018 14:35:47 GMT):
Unfortunately, I can't join you....

yacovm (Mon, 05 Feb 2018 14:36:08 GMT):
also wondering

yacovm (Mon, 05 Feb 2018 14:36:08 GMT):
> Are we broadcasting the maintainers' "summit" ? also wondering

yacovm (Mon, 05 Feb 2018 14:36:34 GMT):
or, if someone is taking notes, etc.

JonathanLevi (Mon, 05 Feb 2018 14:39:37 GMT):
I believe that *hearing* these convos will be a lot more fun ;-)

JonathanLevi (Mon, 05 Feb 2018 14:40:04 GMT):
I'm *sure* we will get the notes afterwards, one way or another...

janb87 (Mon, 05 Feb 2018 15:04:02 GMT):
Has joined the channel.

jyellick (Mon, 05 Feb 2018 20:46:10 GMT):
@JonathanLevi There is definitely diligent note taking going on, I will ask the room about opening a line

JonathanLevi (Mon, 05 Feb 2018 20:46:28 GMT):
Thank you Jason

jyellick (Mon, 05 Feb 2018 20:50:15 GMT):
@JonathanLevi I have dm-ed you a number

minollo (Mon, 05 Feb 2018 21:42:41 GMT):
Has joined the channel.

dave.enyeart (Wed, 14 Feb 2018 14:24:21 GMT):
Need another +2: https://gerrit.hyperledger.org/r/#/c/17897/ upgrade nodejs version to v8.9.4

dave.enyeart (Wed, 14 Feb 2018 14:24:51 GMT):
After that is merged, we'll be able to release baseimage 0.4.6: https://jira.hyperledger.org/browse/FAB-8266

dave.enyeart (Wed, 14 Feb 2018 14:25:20 GMT):
Which needs to be done as soon as possible, so that kafka 1.0.0 gets pulled into system testing

dave.enyeart (Wed, 14 Feb 2018 19:29:26 GMT):
I triaged the full set of defects again. Merged/Closed/Deferred about 10 of them. For the remainders I ensured there was somebody tagged for next steps. Many of them could be deferred to 1.2, but I'd like the assignee to provide their opinion. If I've tagged your name please try to provide an update by end of week, so that we can discuss final deferrals next week. Here is the current defer list: https://jira.hyperledger.org/issues/?filter=12002 I'd encourage everybody to review and if you see any must-fix or should-fix for 1.1 please update Fix Version to be 1.1 and provide a comment. @scottz please share the list with the testers. @simsc please share the list with support teams.

daveryIBM (Thu, 15 Feb 2018 14:02:08 GMT):
Has left the channel.

dave.enyeart (Fri, 16 Feb 2018 14:52:09 GMT):
@here We are not on pace to release 1.1 given the backlog of CRs that need review. There is a lot of doc activity going on that is not getting maintainer review. In your less-distracted time fri/sat/sun please catch up on CR reviews. Let's also go through the older ones and either abandon or comment that they should be targeted for 1.1 vs 1.2.

kapilAtrey (Fri, 16 Feb 2018 14:55:43 GMT):
Has joined the channel.

muralisr (Fri, 16 Feb 2018 14:57:28 GMT):
@dave.enyeart I have a couple...was planning to clear by monday

dave.enyeart (Fri, 16 Feb 2018 15:36:29 GMT):
We know that we need to invest in serviceability, operational metric gathering, etc. At a bare minimum I think we must have ability to dump stack trace in order to troubleshoot a hung peer in production environments. It seems this would be important on the risk vs reward scale, even as a late breaking 1.1 capability.

dave.enyeart (Fri, 16 Feb 2018 15:36:37 GMT):
Please provide your thoughts in : https://jira.hyperledger.org/browse/FAB-8335

dave.enyeart (Fri, 16 Feb 2018 15:37:03 GMT):
Thanks @yacov for raising it.

dave.enyeart (Fri, 16 Feb 2018 15:37:03 GMT):
Thanks @yacovm for raising it.

tmciver (Fri, 16 Feb 2018 20:43:47 GMT):
Has joined the channel.

inatatsu (Tue, 20 Feb 2018 08:25:31 GMT):
Has joined the channel.

jyellick (Wed, 21 Feb 2018 19:53:45 GMT):
I think we need to make some decisions about our support stance for deploying HLF natively/on bare metal. In particular, if users deploy using our docker images, then they get not only the correct binaries for the processes, but they also get updated base configuration files for those binaries, such as `orderer.yaml` and `core.yaml`. From a viper perspective, it's fairly imperative that these files are kept up to date. If a variable is not present in the yaml file, then it cannot be overridden in the environment, and it is a support nightmare if we cannot rely on env overrides to affect configuration. For v1.1, `orderer.yaml` has a total of 40 new lines, including 6 new variables. For `core.yaml` the total is 240 new lines, including 35 new variables. This excludes the nesting structure required for these new variables, as well as the inline documentation, and changed defaults. I've been assigned https://jira.hyperledger.org/browse/FAB-8013 to document these changes, and if the documentation task is instruct the user to add all of these new variables to their existing config, I think it is a hopeless one. In order to migrate to v1.1, the only real viable solution I see, is to start with the new config file, and port any changes made in the old one, to the new one. However, we do not include the config files in our release artifacts. So the question to me is: Do we support native deployments? If so, then I think we must provide a mechanism for users to get the config artifacts as well as the binaries for a release. If not, then we should probably update our docs to exclude the native upgrade path. Thoughts?

yacovm (Wed, 21 Feb 2018 20:07:13 GMT):
the number of lines is irrelevant as they as mostly comments, and the number of new variables is also irrelevant if most of them are configured to recommended values.

yacovm (Wed, 21 Feb 2018 20:08:00 GMT):
do we really need to change these new variables? I'm sure most of them are simply tunable values that shouldn't be messed with unless the deployer knows what he's doing

yacovm (Wed, 21 Feb 2018 20:08:48 GMT):
> and if the documentation task is instruct the user to add all of these new variables to their existing config, I think it is a hopeless one. You can just do a diff and add the new values from the new version into your existing file, what's the problem?

yacovm (Wed, 21 Feb 2018 20:09:51 GMT):
> In order to migrate to v1.1, the only real viable solution I see, is to start with the new config file, and port any changes made in the old one, to the new one. Can you elaborate?

yacovm (Wed, 21 Feb 2018 20:10:40 GMT):
> So the question to me is: Do we support native deployments? I still don't understand the issue here. Is it the config change that the user needs to tailor manually?

jyellick (Wed, 21 Feb 2018 20:34:23 GMT):
> You can just do a diff and add the new values from the new version into your existing file, what's the problem? This would be my recommendation, that will suggest a user merge the config with diff, rather than attempting to document the individual insertions. > Can you elaborate? Just as you described, tell them they should use the new config file, and merge it with their old via a tool like diff. > I still don't understand the issue here. Is it the config change that the user needs to tailor manually? The key piece is that viper env variable overrides only work if the variable is already defined in the yaml

jyellick (Wed, 21 Feb 2018 20:34:56 GMT):
If a user does not add a new section to the yaml, and then they see a doc, tutorial, etc. which overrides the variable through the environment, then the override will have no effect

yacovm (Wed, 21 Feb 2018 20:35:18 GMT):
but why would he/she not just in the 1st place use the new config file

yacovm (Wed, 21 Feb 2018 20:35:41 GMT):
and just change the stuff he/she needs to change to suit his/her environment?

jyellick (Wed, 21 Feb 2018 20:35:47 GMT):
Because the config file is not part of the release artifacts

yacovm (Wed, 21 Feb 2018 20:35:54 GMT):
so what?

yacovm (Wed, 21 Feb 2018 20:36:09 GMT):
oh i see

jyellick (Wed, 21 Feb 2018 20:36:11 GMT):
I'm suggesting if our answer is "Use the new config file" then we need to provide it

yacovm (Wed, 21 Feb 2018 20:36:14 GMT):
we release only binaries and docker images

yacovm (Wed, 21 Feb 2018 20:36:21 GMT):
is that it?

yacovm (Wed, 21 Feb 2018 20:36:46 GMT):
so, we can just write somewhere that the user needs to use the new config version, and merge it, and problem solved no?

yacovm (Wed, 21 Feb 2018 20:37:26 GMT):
I must say I'm a bit lost in all that "release" process thing - many open source software - you just build from source, take the samples from source and modify them.

yacovm (Wed, 21 Feb 2018 20:38:03 GMT):
so yeah, it's convenient to get release binaries and maybe we should also just declare we also release the config files as well?

jyellick (Wed, 21 Feb 2018 20:38:23 GMT):
I would suggest that if we are providing binaries, we should be providing the accompanying config files required to use them. Or, we don't, and people build from source and get the samples. But where we provide the binary, but not config, it feels inconsistent to me.

yacovm (Wed, 21 Feb 2018 20:38:42 GMT):
I agree Jason, thanks for raising this point

yacovm (Wed, 21 Feb 2018 20:38:57 GMT):
but I think we should 100% support "bare metal"

yacovm (Wed, 21 Feb 2018 20:47:14 GMT):
therefore should also provide the config files along with them.

cbf (Wed, 21 Feb 2018 23:40:37 GMT):
hmmm

cbf (Wed, 21 Feb 2018 23:45:36 GMT):
we do ship the peer and orderer binaries - fabric-ca-client and server are installed via go get (not sure that this is the best idea, TBH, since there's no control over versioning)

cbf (Wed, 21 Feb 2018 23:47:02 GMT):
we also can install binaries on mac via homebrew

cbf (Wed, 21 Feb 2018 23:47:52 GMT):
seems to me that we should have a consistent approach (#1) and that we need to have an expected location for the config files that isn't in the repo tree

cbf (Wed, 21 Feb 2018 23:51:36 GMT):
(note that homebrew only installs configtxgen configtxlator cryptogen

cbf (Wed, 21 Feb 2018 23:58:10 GMT):
homebrew installs in /usr/local/opt/fabric-tools (fwiw) and links to /usr/local/bin

cbf (Wed, 21 Feb 2018 23:59:53 GMT):
but for those binaries, we specify the config be in the $PWD (or specified via args)

cbf (Thu, 22 Feb 2018 00:00:45 GMT):
whatever we choose, we need to make it so that the default config location is consistent in docker as it is for the native binaries

dave.enyeart (Thu, 22 Feb 2018 12:53:10 GMT):
We’ll need to close the above discussion out, any other opinions? @jyellick could I ask you to summarize the proposal in the jira (FAB-8013).

dave.enyeart (Thu, 22 Feb 2018 12:53:17 GMT):
On to more general business...

dave.enyeart (Thu, 22 Feb 2018 12:54:44 GMT):
@here As you know we have been closely tracking defects, doc, and system test with a goal of releasing RC1 next week. That goal is tight but within reach, and will likely depend on defect arrival rate over the next days and weekend progress.

dave.enyeart (Thu, 22 Feb 2018 12:55:08 GMT):
We will need to make decisions about deferrals for remaining defects. There are currently 26 defects tagged for 1.1 (top right widget at https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701 ) and 39 defects tagged for deferral (4th widget on right), based on Fix Version field. We will need to get the former down to 0, and this will likely require some group decision making.

dave.enyeart (Thu, 22 Feb 2018 12:55:15 GMT):
I propose a daily maintainer scrum on this channel next week around 9:45am (US Eastern) for release decision making, or whenever the 9:30am community scrum ends. Thoughts?

dave.enyeart (Thu, 22 Feb 2018 12:55:23 GMT):
Concerning system test, good progress has been made and we will get updates at the 9:30am community scrums. Note that final system test can continue on RC1. Our policy last time around was that release candidate needed to prove itself for two weeks prior to release GA. We may be able to shrink that window going forward, pending system test progress and automation.

dave.enyeart (Thu, 22 Feb 2018 12:55:31 GMT):
Can anybody think of other business that is required prior to RC1? This would be a good time to review/update the release criteria we documented for 1.0 https://wiki.hyperledger.org/projects/fabric/release_exit_criteria . I myself would like clarification on a few items from @cbf (e.g. scans, CII, signed release code, automated release notes).

cbf (Thu, 22 Feb 2018 14:04:15 GMT):
We already have our CII badge, as for security scans, LF does this for 1.0. I know that IBM is doing its own set of scans, I would encourage other members to do the same.

cbf (Thu, 22 Feb 2018 14:05:16 GMT):
as for automated release notes, that is something we can work on for 1.2 per the discussions we had in Boston - leveraging JIRA more effectively to enable us to actually generate a report that could become the release notes.

cbf (Sun, 25 Feb 2018 16:19:38 GMT):
@here just a friendly reminder, if someone picks up a CR from another to address issues, or rebase, then they also need to sign-off on the CR (e.g. 2 or more sign-off lines)

cbf (Sun, 25 Feb 2018 16:20:30 GMT):
as maintainers, we should be aware and try our best to enforce so that we preserve clean IP

cbf (Sun, 25 Feb 2018 16:20:33 GMT):
danke

dave.enyeart (Sun, 25 Feb 2018 16:25:16 GMT):
Additionally, I've been operating under the assumption that if you just fix minor things like typos or wording, that it doesn't preclude you from +2ing. Yes, that's a slippery slope, but I have confidence in the maintainers to use their best judgement.

muralisr (Sun, 25 Feb 2018 16:29:02 GMT):
@cbf thanks for the reminder ^^^ ... I picked it up https://gerrit.hyperledger.org/r/#/c/18213/ just for expediency to reduce round trip (most of the work is @wlahti 's)

muralisr (Sun, 25 Feb 2018 16:29:02 GMT):
@cbf thanks for the reminder ^^^ ... I picked up https://gerrit.hyperledger.org/r/#/c/18213/ just to reduce round trip (most of the work is @wlahti 's)

dave.enyeart (Mon, 26 Feb 2018 12:11:04 GMT):
@here We will do maintainer scrum here after the 9:30am community scrum. Likely will be closer to 10am than 9:45am.

dave.enyeart (Mon, 26 Feb 2018 12:11:45 GMT):
We are looking pretty good heading into the week. Down to 18 defects, most of which I think could be deferred.

dave.enyeart (Mon, 26 Feb 2018 12:12:16 GMT):
Please preview the list and add any comments, so that the maintainer scrum may go quicker:

dave.enyeart (Mon, 26 Feb 2018 12:12:18 GMT):
https://jira.hyperledger.org/issues/?filter=12003&jql=project%20%3D%20FAB%20AND%20issuetype%20%3D%20Bug%20AND%20status%20in%20(%22In%20Progress%22%2C%20%22To%20Do%22%2C%20%22In%20Review%22%2C%20Backlog%2C%20Unverified%2C%20%22Monitor%20%2F%20On%20Hold%22)%20AND%20fixVersion%20in%20(EMPTY%2C%20releasedVersions()%2C%20v1.1%2C%20v1.1.0-alpha)%20AND%20component%20not%20in%20(fabric-quality%2C%20fabric-test-resources%2C%20fabric-ci%2C%20fabric-sdk-py%2C%20fabric-sdk-go%2C%20fabric-chaintool%2C%20fabric-chaincode-java)%20ORDER%20BY%20key%20DESC%2C%20component%20ASC%2C%20createdDate%20ASC

dave.enyeart (Mon, 26 Feb 2018 12:12:18 GMT):
https://jira.hyperledger.org/issues/?filter=12003

dave.enyeart (Mon, 26 Feb 2018 12:13:06 GMT):
And the already deferred list has 44:

dave.enyeart (Mon, 26 Feb 2018 12:13:08 GMT):
https://jira.hyperledger.org/issues/?filter=12002

dave.enyeart (Mon, 26 Feb 2018 13:11:00 GMT):
After we release 1.1, the proposal for branches is as follows: `release-1.0.x` - rename of current `release` branch `release-1.1.x` - this will be the default branch so that people get 1.1 release code by default `master` - new dev for 1.2. Readthedocs would follow the same branches. Any other thoughts?

dave.enyeart (Mon, 26 Feb 2018 13:11:00 GMT):
After we release 1.1, the proposal for branches across all repositories (including fabric-samples) is as follows: `release-1.0.x` - rename of current `release` branch `release-1.1.x` - this will be the default branch so that people get 1.1 release code by default `master` - new dev for 1.2. Readthedocs would follow the same branches (for both fabric and fabric-ca). Any other thoughts?

dave.enyeart (Mon, 26 Feb 2018 13:11:00 GMT):
After we release 1.1, the proposal for branches across all repositories (including fabric-samples) is as follows: `release-1.0.x` - rename of current `release` branch `release-1.1.x` - this will be the default branch so that people get 1.1 release code by default `master` - new dev for 1.2. Readthedocs would follow the same branches. Monthly 3rd digit fixpacks will be provided for the latest release branch. Earlier release branches will get fixpacks for critical fixes only (e.g. security vulnerabilities) Any other thoughts?

cbf (Mon, 26 Feb 2018 13:16:53 GMT):
+1

dave.enyeart (Mon, 26 Feb 2018 13:21:18 GMT):
So when linking across repositories in RTD, which RTD version should the links target? `release-1.1.x` ? `latest` ? This is in response to your last comment in #fabric-scrum @cbf

dave.enyeart (Mon, 26 Feb 2018 13:21:41 GMT):
We will likely merge the docs in their own repository going forward, so this hopefully is only a concern for 1.1.

cbf (Mon, 26 Feb 2018 14:23:47 GMT):
release-1.1.x

dave.enyeart (Mon, 26 Feb 2018 14:50:49 GMT):
@here maintainer scrum

JonathanLevi (Mon, 26 Feb 2018 14:50:59 GMT):
Hello !

dave.enyeart (Mon, 26 Feb 2018 14:51:05 GMT):
Hello!

muralisr (Mon, 26 Feb 2018 14:51:14 GMT):
here

JonathanLevi (Mon, 26 Feb 2018 14:51:24 GMT):
OK, you got me. Hello!

dave.enyeart (Mon, 26 Feb 2018 14:51:27 GMT):
If you haven't seen #fabric-scrum today, please review it for items we are trying to close out today

dave.enyeart (Mon, 26 Feb 2018 14:51:53 GMT):
mostly doc and sample items, and mostly around upgrade

dave.enyeart (Mon, 26 Feb 2018 14:52:10 GMT):
we are trying to close those out today and then move on to RC1 release this week

dave.enyeart (Mon, 26 Feb 2018 14:52:38 GMT):
Please review remaining defects today: https://jira.hyperledger.org/issues/?filter=12003

JonathanLevi (Mon, 26 Feb 2018 14:52:58 GMT):
Monsieur Yellick, please can you not work while you are sick? We don't want to put this entire project at risk... ! @jyellick

dave.enyeart (Mon, 26 Feb 2018 14:53:04 GMT):
As some of them are being closed out today, I don't think we need to walk through them one-by-one here, but please review and add comments as appropriate

dave.enyeart (Mon, 26 Feb 2018 14:54:01 GMT):
We will meet tomorrow (and subsequent days if needed) here for release decision

dave.enyeart (Mon, 26 Feb 2018 14:54:15 GMT):
Any other topics people want to raise today?

dave.enyeart (Mon, 26 Feb 2018 14:57:32 GMT):
I must have missed SOMETHING that needs to get done?

dave.enyeart (Mon, 26 Feb 2018 14:58:58 GMT):
@JonathanLevi Any words of wisdom from the 1.0 release manager?

JonathanLevi (Mon, 26 Feb 2018 15:00:33 GMT):
Not much. I'm following and pull in my weight, but just quickly - I think we should prioritize the usability and security over the samples at this point.

dave.enyeart (Mon, 26 Feb 2018 15:01:25 GMT):
Usability and security are indeed focus areas for 1.2. We are out of runway for 1.1. But if you have anything specific in mind please mention.

JonathanLevi (Mon, 26 Feb 2018 15:01:48 GMT):
I mean, in the existing open list, we have *channel config error, inconsistencies between the configuration and the fabric-ca, CLI container issues*

dave.enyeart (Mon, 26 Feb 2018 15:02:41 GMT):
The open list is indeed a focus area for today

JonathanLevi (Mon, 26 Feb 2018 15:02:46 GMT):
I think these should be addressed, if we are short on resources [these are: time, people, CI machines ;-)] , before we work to update the samples... which we can do a bit later.

dave.enyeart (Mon, 26 Feb 2018 15:03:54 GMT):
ok, that's why we are gathered here now, we will all review the open list and provide comments on next steps as best can. any need discussion here?

JonathanLevi (Mon, 26 Feb 2018 15:04:45 GMT):
Nothing more to from my end. I think the backlog is getting to look better and better

mastersingh24 (Mon, 26 Feb 2018 15:05:15 GMT):
And if someone is going to work an issue, please make sure they assign it to themselves

dave.enyeart (Mon, 26 Feb 2018 15:05:37 GMT):
yes, over-communication is better at these times

JonathanLevi (Mon, 26 Feb 2018 15:05:55 GMT):
Actually, now that we are mentioning over-comm...

JonathanLevi (Mon, 26 Feb 2018 15:06:30 GMT):
I saw Chris' request for the DCO when people (non-author'ed, not-original-CR-submitter) rebase...

JonathanLevi (Mon, 26 Feb 2018 15:07:19 GMT):
.... we should keep this in mind. I admit that I didn't really pay enough attention to it when reviewing.

dave.enyeart (Mon, 26 Feb 2018 15:08:24 GMT):
right, especially at the end here, we are allowing maintainers to upload patches rather than commenting, but please remember to add your signature to the commit.

dave.enyeart (Mon, 26 Feb 2018 15:09:17 GMT):
ok, let's CAREFULLY finish things out today, and meet back here tomorrow same time

mastersingh24 (Mon, 26 Feb 2018 15:09:39 GMT):
we do need to merge this: https://gerrit.hyperledger.org/r/18385

dave.enyeart (Mon, 26 Feb 2018 15:09:58 GMT):
Bret said he will merge this morning

dave.enyeart (Mon, 26 Feb 2018 15:10:33 GMT):
And I am talking to Adnan about the final testing for it

mastersingh24 (Mon, 26 Feb 2018 15:12:03 GMT):
https://jira.hyperledger.org/browse/FAB-8503 - 1 more +2

JonathanLevi (Mon, 26 Feb 2018 15:12:12 GMT):
@dave.enyeart, when you write *morning* to @mastersingh24 , I look at the local time and it's 7:12am... which is more like tea-time/4pm in Boston, if you see what I mean.

JonathanLevi (Mon, 26 Feb 2018 15:12:17 GMT):
Looking at 503

mastersingh24 (Mon, 26 Feb 2018 15:12:35 GMT):
sorry - https://gerrit.hyperledger.org/r/#/c/18341/

JonathanLevi (Mon, 26 Feb 2018 15:14:14 GMT):
Damn it. I merged 8503 instead ;-)

JonathanLevi (Mon, 26 Feb 2018 15:14:28 GMT):
Joking, I agree Jason, in this context, it's not worth the "savings" of the bash session.

dave.enyeart (Mon, 26 Feb 2018 15:15:36 GMT):
BTW, I believe we intend to have the two week quiet period between RC1 and GA, in case something pops up

dave.enyeart (Mon, 26 Feb 2018 15:16:10 GMT):
I am not opposed to doc enhancements going in during that time. thoughts?

dave.enyeart (Mon, 26 Feb 2018 15:16:10 GMT):
I am not opposed to doc enhancements going in during that time (although Joe likely won't be available to help) thoughts?

dave.enyeart (Mon, 26 Feb 2018 15:17:18 GMT):
but primarily, we will be working on 1.2 plan and known items during that time

dave.enyeart (Mon, 26 Feb 2018 15:17:18 GMT):
but primarily, we will be working on 1.2 plan and 1.2 known items during that time

dave.enyeart (Mon, 26 Feb 2018 15:17:45 GMT):
while testers do final regression testing against RC1

mastersingh24 (Mon, 26 Feb 2018 15:18:40 GMT):
doc is good

mastersingh24 (Mon, 26 Feb 2018 15:18:42 GMT):
nothing else

mastersingh24 (Mon, 26 Feb 2018 15:18:54 GMT):
we should only fix bugs which come in against the RC

mastersingh24 (Mon, 26 Feb 2018 15:19:08 GMT):
anything we decided to defer should not be touched

dave.enyeart (Mon, 26 Feb 2018 15:19:16 GMT):
agreed

mastersingh24 (Mon, 26 Feb 2018 15:20:05 GMT):
we are SOOOOOO CLOSE :pray_tone4:

dave.enyeart (Mon, 26 Feb 2018 15:20:18 GMT):
we got this

dave.enyeart (Mon, 26 Feb 2018 15:20:54 GMT):
have a good day (good evening to mastersingh)

mastersingh24 (Mon, 26 Feb 2018 15:28:07 GMT):
hehe

cbf (Mon, 26 Feb 2018 19:45:56 GMT):

cbf (Mon, 26 Feb 2018 19:54:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=XgWFY4DvBGtMxof3J) @mastersingh24 :woo:

dave.enyeart (Tue, 27 Feb 2018 04:07:24 GMT):
Please see my comments in https://jira.hyperledger.org/browse/FAB-8524

dave.enyeart (Tue, 27 Feb 2018 04:08:02 GMT):
Is there agreement that we don't and shouldn't document native binary installations, at least in the near term?

mastersingh24 (Tue, 27 Feb 2018 08:00:12 GMT):
@dave.enyeart - I added a comment to FAB-8524 on why they were getting the error.

dave.enyeart (Tue, 27 Feb 2018 11:12:55 GMT):
@mastersingh24 thanks, makes sense. And do you have an opinion on how much we should or shouldn't document native binary installations in general?

cbf (Tue, 27 Feb 2018 12:32:14 GMT):
I added comment, the use case is unrealistic

cbf (Tue, 27 Feb 2018 12:32:18 GMT):
who would do that?

dave.enyeart (Tue, 27 Feb 2018 13:17:50 GMT):
agreed. My more general question is to what extent we should document native binary deployments.

dave.enyeart (Tue, 27 Feb 2018 13:18:52 GMT):
Has anybody else looked at upgrade? It is coming around but requires some more eyes.

dave.enyeart (Tue, 27 Feb 2018 13:19:31 GMT):
I've posted in #fabric-scrum that I think it is our largest risk area. See that channel for the latest info.

dave.enyeart (Tue, 27 Feb 2018 13:20:09 GMT):
Please try it out and provide comments on the CRs.

dave.enyeart (Tue, 27 Feb 2018 14:13:14 GMT):
Thanks @kostas for volunteering to help with Capabilities/Upgrade reviews

dave.enyeart (Tue, 27 Feb 2018 14:13:50 GMT):
I have created a label `must-fix` so that we can easily track remaining items for the release.

dave.enyeart (Tue, 27 Feb 2018 14:13:56 GMT):
Here is the query: https://jira.hyperledger.org/issues/?jql=labels%20%3D%20must-fix

dave.enyeart (Tue, 27 Feb 2018 14:14:32 GMT):
My opinion only at this point... feel free to add others or comment on the ones included

dave.enyeart (Tue, 27 Feb 2018 14:44:54 GMT):
@here maintainer scrum

dave.enyeart (Tue, 27 Feb 2018 14:45:17 GMT):
Please take a look at the new `must-fix` query.

dave.enyeart (Tue, 27 Feb 2018 14:45:42 GMT):
I think the other defects in the 1.1 list can all be deferred.

dave.enyeart (Tue, 27 Feb 2018 14:45:53 GMT):
So please make sure you agree with the `must-fix` list

dave.enyeart (Tue, 27 Feb 2018 14:46:02 GMT):
Add anything else you know of that is required

dave.enyeart (Tue, 27 Feb 2018 14:46:23 GMT):
And comment on any that you dont think need to be in the list

dave.enyeart (Tue, 27 Feb 2018 14:46:31 GMT):
This is the list we will be marching to

dave.enyeart (Tue, 27 Feb 2018 14:47:57 GMT):
Please review each of the CRs in the `must-fix` list today

dave.enyeart (Tue, 27 Feb 2018 14:48:30 GMT):
7 of the 8 items are In Review

dave.enyeart (Tue, 27 Feb 2018 14:48:44 GMT):
Any other comments?

VikasJakhar (Tue, 27 Feb 2018 20:10:21 GMT):
Has joined the channel.

mrshah-ibm (Wed, 28 Feb 2018 12:10:02 GMT):
Has joined the channel.

dave.enyeart (Wed, 28 Feb 2018 13:15:45 GMT):
#fabric-scrum is updated with the final must-fix CRs

dave.enyeart (Wed, 28 Feb 2018 13:16:27 GMT):
plan is to cut RC1 tomorrow

dave.enyeart (Wed, 28 Feb 2018 14:48:49 GMT):
@here maintainer scrum

dave.enyeart (Wed, 28 Feb 2018 14:49:09 GMT):
I think we have the final must-fix list

dave.enyeart (Wed, 28 Feb 2018 14:49:20 GMT):
Any others we need to discuss?

dave.enyeart (Wed, 28 Feb 2018 14:50:03 GMT):
We can proceed with the fabric and fabric-ca RC1. We don't need to do a RC1 for SDKs since the samples use latest unstable build anyways.

dave.enyeart (Wed, 28 Feb 2018 14:50:03 GMT):
We can proceed with the fabric and fabric-ca RC1 after the last CA fix goes in. We don't need to do a RC1 for SDKs since the samples use latest unstable build anyways.

dave.enyeart (Wed, 28 Feb 2018 14:52:07 GMT):
There are a couple other low-risk ones not on the must-fix list that could be merged today, but be careful.

dave.enyeart (Wed, 28 Feb 2018 14:52:52 GMT):
Does anybody have thoughts on whether we should do a What's New in 1.1 doc topic, vs just the 1.1 announcement email?

dave.enyeart (Wed, 28 Feb 2018 14:54:49 GMT):
We will also tag fabric-samples release branch with a v1.0.6 tag, for anybody following the upgrade doc

cbf (Wed, 28 Feb 2018 14:59:09 GMT):
I could do a blog post for the hyperledger.org blog and cross post from thinkblog

cbf (Wed, 28 Feb 2018 15:00:02 GMT):
https://gerrit.hyperledger.org/r/c/18499/

dave.enyeart (Wed, 28 Feb 2018 15:00:11 GMT):
Ok thanks, we can work on announcement email and blog post together

cbf (Wed, 28 Feb 2018 15:00:20 GMT):
cool

dave.enyeart (Wed, 28 Feb 2018 15:01:03 GMT):
that one looks good chris, just add the INFO level for orderer and we are good to go

dave.enyeart (Wed, 28 Feb 2018 15:02:54 GMT):
one more while I have your attention: https://gerrit.hyperledger.org/r/#/c/18515/

dave.enyeart (Wed, 28 Feb 2018 15:07:36 GMT):
https://gerrit.hyperledger.org/r/#/c/18499/ is ready for another +2

cbf (Wed, 28 Feb 2018 17:47:59 GMT):
this goes with 18499 https://gerrit.hyperledger.org/r/c/18525/

dave.enyeart (Wed, 28 Feb 2018 18:02:47 GMT):
@cbf Do you want to provide the same guidance in channel_update_tutorial.rst?

dave.enyeart (Wed, 28 Feb 2018 18:02:57 GMT):
That's the one Will was talking about

cbf (Wed, 28 Feb 2018 18:03:36 GMT):
ah, yes

cbf (Wed, 28 Feb 2018 18:11:16 GMT):
done

cbf (Wed, 28 Feb 2018 20:27:44 GMT):
infra team is on the issue with gerrit and jira inaccessible

kostas (Wed, 28 Feb 2018 20:28:53 GMT):
What is the protocol for opening up a security issue in JIRA? (To be clear: I don't have one to report, and I'm not speaking about myself specifically.)

rjones (Wed, 28 Feb 2018 20:29:35 GMT):
kostas: file the issue and select "security issue: yes" when you file it

yacovm (Wed, 28 Feb 2018 20:29:47 GMT):
only cbf and Gari have permissions for that, Ry

yacovm (Wed, 28 Feb 2018 20:29:53 GMT):
common folk can't do that

rjones (Wed, 28 Feb 2018 20:30:01 GMT):
that should not be the case. that is a bug.

yacovm (Wed, 28 Feb 2018 20:30:05 GMT):
oh

kostas (Wed, 28 Feb 2018 20:30:09 GMT):
I also have that too but yes, as Yacov says, I'm wondering how others go about it.

yacovm (Wed, 28 Feb 2018 20:30:30 GMT):
anyway you can't do that, JIRA and gerrit are down at the moment

rjones (Wed, 28 Feb 2018 20:30:52 GMT):
there is another way: you could file the bug on H1 if you wanted a bounty. I would ask you not to do that :)

kostas (Wed, 28 Feb 2018 20:33:00 GMT):
> that should not be the case. that is a bug. That makes more sense now. I thought that only maintainers can label something as a security issue which didn't make sense.

cbf (Wed, 28 Feb 2018 20:34:10 GMT):
@kostas https://wiki.hyperledger.org/security

yacovm (Wed, 28 Feb 2018 20:35:19 GMT):
@rjones if I opened a JIRA and it's flagged security - should I be able to add watchers to it?

yacovm (Wed, 28 Feb 2018 20:35:24 GMT):
because I can't from my experience

rjones (Wed, 28 Feb 2018 20:35:56 GMT):
yes, and watchers should be able to see it even if it is a security issue and they are not on the security team

jyellick (Wed, 28 Feb 2018 20:37:11 GMT):
> yes, and watchers should be able to see it even if it is a security issue and they are not on the security team I believe I can confirm this piece is working as designed

jyellick (Wed, 28 Feb 2018 20:37:11 GMT):
> watchers should be able to see it even if it is a security issue and they are not on the security team I believe I can confirm this piece is working as designed

rjones (Wed, 28 Feb 2018 20:40:59 GMT):
JIRA and Gerrit are available again https://status.linuxfoundation.org/incidents/6nnfhx5cwnp8

cbf (Wed, 28 Feb 2018 21:46:43 GMT):
@rjones I *believe* we tried to have a watcher (added) add another watcher and it did not work

cbf (Wed, 28 Feb 2018 21:46:57 GMT):
they are able to see the issue though

rjones (Wed, 28 Feb 2018 21:48:21 GMT):
@cbf yes, I looked into the permissions, there isn't a fine-grained ACL for that. I can either grant anyone that can file a bug permission to manage all watchers on all bugs in a project, or not. I could create a team which is "all trusted people" and manually manage that, or stick with the current method of "a member of the security team adds the new watcher"

rjones (Wed, 28 Feb 2018 21:49:01 GMT):
"a member of the security team, or a JIRA administrator"

cbf (Wed, 28 Feb 2018 21:50:15 GMT):
We could discuss this on the TSC, but I would think that the trusted might be the maintainers + security team... if a security team (who has visibility) adds a maintainer, then the maintainer should be able to add others to the issue

cbf (Wed, 28 Feb 2018 21:50:18 GMT):
make sense?

rjones (Wed, 28 Feb 2018 21:53:59 GMT):
yes, I understand what you want, but I don't know if it will work that way. I'll need to play with it.

cbf (Wed, 28 Feb 2018 21:54:19 GMT):
tx

dave.enyeart (Wed, 28 Feb 2018 23:37:45 GMT):
Improve troubleshooting and debug in BYFN:

dave.enyeart (Wed, 28 Feb 2018 23:37:46 GMT):
https://gerrit.hyperledger.org/r/#/c/18499/

dave.enyeart (Wed, 28 Feb 2018 23:37:55 GMT):
https://gerrit.hyperledger.org/r/#/c/18525/

dave.enyeart (Thu, 01 Mar 2018 04:50:22 GMT):
There are two bugs we'll need to decide on Thursday prior to RC1:

dave.enyeart (Thu, 01 Mar 2018 04:51:07 GMT):
https://jira.hyperledger.org/browse/FAB-8598 @greg.haskins @muralisr @mastersingh24 any ideas?

dave.enyeart (Thu, 01 Mar 2018 04:51:45 GMT):
https://jira.hyperledger.org/browse/FAB-8584 @kostas taking a look

dave.enyeart (Thu, 01 Mar 2018 12:27:58 GMT):
Three that I think are must-fix:

dave.enyeart (Thu, 01 Mar 2018 12:30:27 GMT):
Three that I think are must-fix:

dave.enyeart (Thu, 01 Mar 2018 12:30:49 GMT):
https://jira.hyperledger.org/browse/FAB-8602 @jyellick add volumes to the other docker compose files

dave.enyeart (Thu, 01 Mar 2018 12:30:49 GMT):
https://jira.hyperledger.org/browse/FAB-8602 @jyellick add volumes to the other docker compose files: https://gerrit.hyperledger.org/r/#/c/18591/

dave.enyeart (Thu, 01 Mar 2018 12:31:19 GMT):
https://jira.hyperledger.org/browse/FAB-8598 builds failing on s390

dave.enyeart (Thu, 01 Mar 2018 12:31:19 GMT):
https://jira.hyperledger.org/browse/FAB-8598 builds failing on s390 due to docker busybox unavailable. harshna thinks it may be available now. @rameshthoomu please kick off another s390 build this morning.

dave.enyeart (Thu, 01 Mar 2018 12:31:19 GMT):
https://jira.hyperledger.org/browse/FAB-8598 builds failing on s390 due to docker busybox unavailable. harsha thinks it may be available now. @rameshthoomu please kick off another s390 build this morning.

dave.enyeart (Thu, 01 Mar 2018 12:31:43 GMT):
https://jira.hyperledger.org/browse/FAB-8584 please review fix at https://gerrit.hyperledger.org/r/#/c/18585/

yacovm (Thu, 01 Mar 2018 12:45:42 GMT):
@kostas @jyellick i don't understand why the kafka connection should cause deliver to return a service unavailable

yacovm (Thu, 01 Mar 2018 12:45:42 GMT):
@kostas @jyellick why the kafka connection should cause deliver to return a service unavailable

yacovm (Thu, 01 Mar 2018 12:45:57 GMT):
is that so the peer would failover to the other node?

yacovm (Thu, 01 Mar 2018 12:46:17 GMT):
because the orderer is expected to be not updated anymore?

dave.enyeart (Thu, 01 Mar 2018 14:44:33 GMT):
@here maintainer scrum

dave.enyeart (Thu, 01 Mar 2018 14:45:11 GMT):
Both CRs above are in review. @kostas pushing another patch. please review both.

muralisr (Thu, 01 Mar 2018 14:45:14 GMT):
here

dave.enyeart (Thu, 01 Mar 2018 14:45:39 GMT):
besides those two, any other business prior to doing the release cutting CRs?

dave.enyeart (Thu, 01 Mar 2018 14:46:46 GMT):
I see https://jira.hyperledger.org/browse/FAB-8606 for java-sdk is Highest

dave.enyeart (Thu, 01 Mar 2018 14:46:56 GMT):
please review that one as well, although we will not cut RC1 for the SDKs

dave.enyeart (Thu, 01 Mar 2018 14:47:53 GMT):
Rick will do primary review, but perhaps @C0rWin could take a quick look as well since he expressed interested in java sdk

dave.enyeart (Thu, 01 Mar 2018 14:49:35 GMT):
oh, we could use one more +2 on https://gerrit.hyperledger.org/r/#/c/18589/ before we call for code freeze

dave.enyeart (Thu, 01 Mar 2018 14:50:32 GMT):
system test will try out the fixes above today, then we start release process

muralisr (Thu, 01 Mar 2018 14:51:40 GMT):
done on https://gerrit.hyperledger.org/r/#/c/18589 @dave.enyeart

dave.enyeart (Thu, 01 Mar 2018 14:51:54 GMT):
thx

dave.enyeart (Thu, 01 Mar 2018 14:52:47 GMT):
ok, i think that's it for now, but keep an eye out on this channel in case we need reviews today

dave.enyeart (Thu, 01 Mar 2018 16:14:28 GMT):
FAB-8602 is ready for final +2s please:

dave.enyeart (Thu, 01 Mar 2018 16:14:34 GMT):
https://gerrit.hyperledger.org/r/c/18591 https://gerrit.hyperledger.org/r/c/18593

dave.enyeart (Thu, 01 Mar 2018 17:16:06 GMT):
The above Jiras are resolved and CRs merged. Starting release process for v1.1.0-rc1. CODE FREEZE in effect.

cbf (Thu, 01 Mar 2018 17:16:43 GMT):
technically it is a MERGE FREEZE;-)

dave.enyeart (Thu, 01 Mar 2018 17:17:03 GMT):
MERGE FREEZE in effect!

tmciver (Thu, 01 Mar 2018 17:24:06 GMT):
Has left the channel.

cbf (Thu, 01 Mar 2018 21:59:52 GMT):
before we release the merge freeze, wonder if we should cut the release 1.1 branch from rc1?

cbf (Thu, 01 Mar 2018 22:00:06 GMT):
@mastersingh24 @dave.enyeart

cbf (Thu, 01 Mar 2018 22:01:56 GMT):
docs for v1.1.0-rc1 published for fabric and fabric ca

cbf (Thu, 01 Mar 2018 22:02:54 GMT):
we do have doc changes still, but I think all changes except urgent fixes and doc should be deferred post 1.1.0

dave.enyeart (Thu, 01 Mar 2018 22:03:32 GMT):
I think that's a good idea so that 1.2 development could start on master branch, while we merge any critical defects to both master and the 1.1 branch. My only concern was things like the CHANGELOG.MD, which would diverge on the two branches (two different views of 1.1.0), not sure how we'd work that?

dave.enyeart (Thu, 01 Mar 2018 22:04:16 GMT):
I guess master CHANGELOG.MD would go from 1.1 RC1 to 1.2?

dave.enyeart (Thu, 01 Mar 2018 22:10:50 GMT):
hmmm, @yacovm just reminded me that there is an 'old' release-1.1 branch that we probably need to clean up:

dave.enyeart (Thu, 01 Mar 2018 22:10:51 GMT):
https://github.com/hyperledger/fabric/branches

yacovm (Thu, 01 Mar 2018 22:11:22 GMT):
I agree with @dave.enyeart , lets cut a v1.1 branch from master so we can start merging pending v1.2 content. No time to waste :)

jyellick (Thu, 01 Mar 2018 22:13:23 GMT):
+1, unless anyone has complications (and we're happy with respect to the changelog?)

dave.enyeart (Thu, 01 Mar 2018 22:13:24 GMT):
In terms of timing, i do agree that right after RC1 is ideal time

cbf (Thu, 01 Mar 2018 22:13:48 GMT):
well, we could fudge the changelog

cbf (Thu, 01 Mar 2018 22:15:18 GMT):
because we SHOULD have the same set of fixes in both

cbf (Thu, 01 Mar 2018 22:15:26 GMT):
we just won't be tagging a release

cbf (Thu, 01 Mar 2018 22:15:53 GMT):
but we can copy the changelog from the formal release

dave.enyeart (Thu, 01 Mar 2018 22:16:42 GMT):
I dont see an issue of changelog going from 1.1 RC1 to 1.2 for the 1.2 release branch. what's important is the 1.1 changelog on 1.1 branch.

cbf (Thu, 01 Mar 2018 22:16:53 GMT):
+1

dave.enyeart (Thu, 01 Mar 2018 22:17:13 GMT):
so yeah, I definitely +1

cbf (Thu, 01 Mar 2018 22:17:39 GMT):
so, then if we ARE starting on 1.2, then what we need to do is start using JIRA right;-)

yacovm (Thu, 01 Mar 2018 22:17:52 GMT):
what do you mena?

yacovm (Thu, 01 Mar 2018 22:17:52 GMT):
what do you mean?

cbf (Thu, 01 Mar 2018 22:17:53 GMT):
we can generate a nice changelog from JIRA if we do this right

cbf (Thu, 01 Mar 2018 22:18:53 GMT):
see my note then

cbf (Thu, 01 Mar 2018 22:19:10 GMT):
I'd like to get agreement on the branch naming strategy

cbf (Thu, 01 Mar 2018 22:19:41 GMT):
I proposed 'release-1.0' and 'release-1.1'

cbf (Thu, 01 Mar 2018 22:26:22 GMT):
@mastersingh24 likes 'release-1.0.x' and 'release-1.1.x' - I'm okay with that - it signals we have patches

yacovm (Thu, 01 Mar 2018 22:27:50 GMT):
But why would anyone use something other than latest?

yacovm (Thu, 01 Mar 2018 22:28:06 GMT):
We dont add features-only fix bugs

cbf (Thu, 01 Mar 2018 22:28:32 GMT):
latest is actually UNSTABLE

cbf (Thu, 01 Mar 2018 22:28:46 GMT):
so, maybe instead of latest we call it unstable?

yacovm (Thu, 01 Mar 2018 22:28:48 GMT):
I mean latest for a release branch

yacovm (Thu, 01 Mar 2018 22:29:11 GMT):
I.e why would i use release-1.0.5 instead of release-1.0.6?

cbf (Thu, 01 Mar 2018 22:29:27 GMT):
it won't be release-1.0.5

cbf (Thu, 01 Mar 2018 22:29:33 GMT):
it will be release-1.0.x

yacovm (Thu, 01 Mar 2018 22:29:38 GMT):
Oh

yacovm (Thu, 01 Mar 2018 22:29:38 GMT):
Oh- im my mind i expanded the *x* to all versions....

yacovm (Thu, 01 Mar 2018 22:29:38 GMT):
Oh- in my mind i expanded the *x* to all versions....

cbf (Thu, 01 Mar 2018 22:29:50 GMT):
and always build the latest tag

yacovm (Thu, 01 Mar 2018 22:30:59 GMT):
I think it makes sense, it does signal we have patches

cbf (Thu, 01 Mar 2018 22:31:02 GMT):
s/latest/most recent//

yacovm (Thu, 01 Mar 2018 22:31:17 GMT):
Though i dont mind either

yacovm (Thu, 01 Mar 2018 22:31:17 GMT):
Though i dont mind either, good with the v1.1 approach too

jyellick (Thu, 01 Mar 2018 22:32:06 GMT):
I'll second @yacovm I would have been happy with release-1.1, but release-1.1.x also works for me

jyellick (Thu, 01 Mar 2018 22:32:06 GMT):
I'll second @yacovm, I would have been happy with release-1.1, but release-1.1.x also works for me

yacovm (Thu, 01 Mar 2018 22:34:38 GMT):
Can a branch name have * instead of x?

jyellick (Thu, 01 Mar 2018 22:35:14 GMT):
Even if it can, I'd oppose that, interferes with normal shell parsing and would need to be quoted/escaped every time

rjones (Thu, 01 Mar 2018 22:36:18 GMT):
I was just reading about implementing lambdas and closure in bash, so why not?

mastersingh24 (Sat, 03 Mar 2018 10:18:39 GMT):
Here's a quick poll for branch naming conventions: https://www.surveymonkey.com/r/P2GPLQD

jyellick (Sat, 03 Mar 2018 14:46:07 GMT):
Not in the poll, but another question. Our tags are "v1.1.0", "v1.0.6" etc. Would it make sense to preface the version number with 'v' in the branch for consistency's sake?

dave.enyeart (Sat, 03 Mar 2018 14:52:35 GMT):
clarification on the poll - the EXACT branch name will also appear as the RTD version, right?

mastersingh24 (Sat, 03 Mar 2018 15:52:26 GMT):
correct

mastersingh24 (Sat, 03 Mar 2018 15:54:23 GMT):
@jyellick - FWIW, my take is that having "release" and "v" in the branch name is redundant. Can you live without it? ;)

mastersingh24 (Sat, 03 Mar 2018 16:02:19 GMT):
For those who want to see the status of the poll: https://www.surveymonkey.com/results/SM-D6SSCPSP8/

jyellick (Sat, 03 Mar 2018 17:41:50 GMT):
@mastersingh24 I can certainly live without it. We tag our docker images without the 'v'. Maybe we should rethink our git tagging scheme as well. Just threw it out there as food for thought.

cbf (Sat, 03 Mar 2018 19:35:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Hni9vYWF2PuxxBmiP) @mastersingh24 +1

GiorgiBlockchain (Mon, 05 Mar 2018 03:34:17 GMT):
Has joined the channel.

mastersingh24 (Mon, 05 Mar 2018 10:19:09 GMT):
Folks - a reminder for those of you who have not voted for the branch naming conventions; please vote at https://www.surveymonkey.com/r/P2GPLQD Currently 10 folks have voted and it's still too close to call

mastersingh24 (Mon, 05 Mar 2018 14:22:38 GMT):
Breaking news: WE HAVE A WINNER! https://www.surveymonkey.com/results/SM-D6SSCPSP8/ (we have 15 maintainers and 12 have voted with 8 in favor of the `release-M.M` naming convention)

mastersingh24 (Mon, 05 Mar 2018 14:23:12 GMT):
(for those who do not want to do the math, that means there is no way for `release-M.M.x` to win) ;)

cbf (Mon, 05 Mar 2018 17:21:10 GMT):
@mastersingh24 you going to create the branches?

jtclark (Mon, 05 Mar 2018 17:54:44 GMT):
Has joined the channel.

mastersingh24 (Mon, 05 Mar 2018 18:39:09 GMT):
I'm happy to do so ;)

mastersingh24 (Mon, 05 Mar 2018 18:39:36 GMT):
So we create release-1.1 from the current tip of master?

mastersingh24 (Mon, 05 Mar 2018 18:46:38 GMT):
release-1.0 has been created from release ;)

mastersingh24 (Mon, 05 Mar 2018 18:49:50 GMT):
release-1.1 has been created ;)

mastersingh24 (Mon, 05 Mar 2018 18:49:50 GMT):
release-1.1 has been created from master ;)

dave.enyeart (Mon, 05 Mar 2018 18:57:19 GMT):
ok, so any doc improvement or critical fix in the next couple weeks has to be cherry picked to both master and release-1.1, by the submitter. I've found that the Gerrit Cherry Pick UI button is pretty good for this, if the files are in sync. And maintainers will have watch for any misses upon merge. Right? And we'll need to decide whether one Jira is sufficient, or request two Jiras get created. @mastersingh24 what's your opinion given you have some background here with the 1.0.x release branch?

mastersingh24 (Mon, 05 Mar 2018 18:58:16 GMT):
that's my assessment as well .... JIRA associated with a CR should have the fix version set to all applicable versions ...

mastersingh24 (Mon, 05 Mar 2018 18:58:42 GMT):
Should be easy to deal with master / release-1.1 for now .... bug fixes and docs only for releaese-1.1

mastersingh24 (Mon, 05 Mar 2018 18:58:42 GMT):
Should be easy to deal with master / release-1.1 for now .... bug fixes and docs only for release-1.1

dave.enyeart (Mon, 05 Mar 2018 18:58:57 GMT):
we could say that main jira is for master and if you want a backport create a sub-task? that would work for Bugs but not sub-tasks (as a sub-task cannot have a sub-task)

dave.enyeart (Mon, 05 Mar 2018 18:58:57 GMT):
we could say that main jira is for master and if you want a backport to release-1.1 create a sub-task? that would work for Bugs but not sub-tasks (as a sub-task cannot have a sub-task)

mastersingh24 (Mon, 05 Mar 2018 18:59:03 GMT):
and yes - the UI works well for these

dave.enyeart (Mon, 05 Mar 2018 19:00:39 GMT):
in prior projects, we've found that it is impossible to track the backport intent and status without separate work item

dave.enyeart (Mon, 05 Mar 2018 19:00:39 GMT):
in prior projects, we've found that it is impossible to track the backport intent and status without separate work item, and things would get missed.

dave.enyeart (Mon, 05 Mar 2018 19:01:47 GMT):
although the Cherry Pick would have the original FAB number in the commit message

smithbk (Mon, 05 Mar 2018 19:28:11 GMT):
heads up that a CR is coming for fabric-ca to revendor bccsp from fabric to pull in the latest bccsp fixes

cbf (Mon, 05 Mar 2018 19:41:45 GMT):
so, I think that what @mastersingh24 is suggesting is that if we add fixVersion for each of the affected versions, that will suffice

cbf (Mon, 05 Mar 2018 19:41:58 GMT):
and use the cherry-pick UI

cbf (Mon, 05 Mar 2018 19:43:23 GMT):
@mastersingh24 are you updating RTD or shall I?

cbf (Mon, 05 Mar 2018 19:48:26 GMT):
nvm, see you already have done this

cbf (Mon, 05 Mar 2018 19:48:28 GMT):
thx

dave.enyeart (Mon, 05 Mar 2018 19:56:43 GMT):
Right, I'm just saying with the multi-FixVersion approach there is more risk of a Jira getting marked Done when it hasn't been ported to the appropriate release branches yet, and then it gets accidentally missed. There is no perfect answer, we can start with this approach and see how it goes.

mastersingh24 (Mon, 05 Mar 2018 20:04:09 GMT):
diligence is really the only answer .... of course we can try to provide process help as well

yacovm (Mon, 05 Mar 2018 20:07:03 GMT):
if we have v1.1 branch now, does that mean the merge freeze is over?

yacovm (Mon, 05 Mar 2018 20:07:43 GMT):
actually - where is the branch? I only see tags

rjones (Tue, 06 Mar 2018 02:16:35 GMT):
Has left the channel.

dave.enyeart (Tue, 06 Mar 2018 18:03:12 GMT):
MERGE FREEZE OVER. Discussed with @mastersingh24: For `fabric`: - use `master` branch for new 1.2 code, but remember that we will require written motivation and design for anything significant starting in 1.2 (either in Jira Description for small items, or a linked google doc or slides for larger items). - use `release-1.1` branch for any doc improvements or critical fixes that need to be made prior to 1.1 GA release - every time you merge something, think about whether it needs to be cherry picked to the other branch, and make sure the Jira Fix Version includes both releases (v1.1 and v1.2 for master). For the other projects - there is not much 1.2 activity yet, so we’ll let 1.1 finalize in `master` before creating the release branches.

dave.enyeart (Wed, 07 Mar 2018 12:43:34 GMT):
For `fabric-ca` - the re-vendored bccsp is merged, and `release-1.1` created. For any remaining critical fixes or doc updates, remember to cherry pick the CR into both releases.

dave.enyeart (Wed, 07 Mar 2018 14:42:27 GMT):
I am pulling together retrospective / lessons learned from 1.1 release. Will make them public to solicit additions, but feel free to direct message me with anything you'd like to see included in the first draft. Also, I am cleaning up the items already marked 1.2 in Jira (keeping in mind the priorities that were agreed to at maintainers meeting), and then will publish a query for us all to look at so that we can refine the plan for 1.2.

jyellick (Fri, 09 Mar 2018 06:58:04 GMT):
Per the maintainers meeting, we left the chaincode lifecycle problem unresolved. This is something which I believe is critical we fix for v1.2. I've linked to a Google doc with (yet another) proposal inside https://jira.hyperledger.org/browse/FAB-8724 which borrows heavily from other proposals and is hopefully acceptable to all. Please review. If we want to contain this for v1.2, it is imperative that we reach consensus upon a path forward as soon as possible so that we can begin implementing.

mastersingh24 (Fri, 09 Mar 2018 11:12:06 GMT):
Folks - can we get some eyes on https://gerrit.hyperledger.org/r/11867 ? This is the removal of FSM. Would like to get this in so that we can get https://gerrit.hyperledger.org/r/18699 (refactoring to make the code base more testable and give a foundation for adding new things) rebased and it as well

yacovm (Fri, 09 Mar 2018 11:34:08 GMT):
@muralisr should append his signed-off-by to the first one...

yacovm (Fri, 09 Mar 2018 11:35:25 GMT):
the change set by @sykesm you pointed should be updated, as some of the code there was split into other change sets.

mastersingh24 (Fri, 09 Mar 2018 11:49:34 GMT):
yep and yep

dave.enyeart (Fri, 09 Mar 2018 14:46:49 GMT):
@mastersingh24 It looks like you are still advocating to do docker multi-architecture support in 1.1: https://jira.hyperledger.org/browse/FAB-8338 .

dave.enyeart (Fri, 09 Mar 2018 14:47:11 GMT):
If we do a change like that, I think we must do a release candidate 2 so that people can test it out, before 1.1 GA

mastersingh24 (Fri, 09 Mar 2018 14:55:41 GMT):
We can easily test this out without needing to put out a new build or RC. But I'm also fine with doing this later as well

mastersingh24 (Fri, 09 Mar 2018 14:56:32 GMT):
The download scripts already re-tag images as :latest - so the samples for 1.1 will just work as the compose files refer to latest

dave.enyeart (Fri, 09 Mar 2018 15:03:28 GMT):
@mastersingh24 the samples also allow a `-i` flag to indicate the specific image version. This is used in the upgrade tutorial.

dave.enyeart (Fri, 09 Mar 2018 15:03:28 GMT):
@mastersingh24 the samples also allow a `-i` flag to indicate the specific image version. This is used in the upgrade tutorial. The sample scripts then generate the docker tag as `i) IMAGETAG=`uname -m`"-"$OPTARG`

mastersingh24 (Fri, 09 Mar 2018 15:04:29 GMT):
well that was a terrible idea :(

mastersingh24 (Fri, 09 Mar 2018 15:04:43 GMT):
although you can still update from latest to latest ;)

mastersingh24 (Fri, 09 Mar 2018 15:04:58 GMT):
or anything to latest ;)

mastersingh24 (Fri, 09 Mar 2018 15:05:15 GMT):
but again -- samples can be updated without putting out new builds

mastersingh24 (Fri, 09 Mar 2018 15:05:20 GMT):
that was my point

mastersingh24 (Fri, 09 Mar 2018 15:05:30 GMT):
but as I said, we can delay

dave.enyeart (Fri, 09 Mar 2018 15:11:09 GMT):
right, these things tend to have unanticipated consequences, i'm just suggesting it would be safer to try something new on a rc2 rather than GA release, so that we get a wider audience trying it out.

dave.enyeart (Fri, 09 Mar 2018 15:11:59 GMT):
my preference would be to wait until 1.2, it's only a quarter away :)

mastersingh24 (Fri, 09 Mar 2018 15:34:21 GMT):
that's fine too

mastersingh24 (Fri, 09 Mar 2018 15:34:50 GMT):
I do believe that the existing tags are still available even if we go with multi-arch

mastersingh24 (Fri, 09 Mar 2018 15:35:02 GMT):
but should be fine to do post 1.1 release

dave.enyeart (Fri, 09 Mar 2018 16:19:40 GMT):
Ok, let's do docker multi-architecture in 1.2 then. Luis is also making some comments in https://gerrit.hyperledger.org/r/#/c/18467/ , so better to let this bake than rush it out.

cbf (Fri, 09 Mar 2018 18:33:16 GMT):
good call, not a good idea to make radical changes at this hour

dave.enyeart (Mon, 12 Mar 2018 05:32:55 GMT):
Fabric 1.1 Retrospective - I've pulled together a retrospective document based on maintainer meeting and other responses I've received:

dave.enyeart (Mon, 12 Mar 2018 05:33:04 GMT):
https://docs.google.com/document/d/1qyYDY6yn8_unFKmxmUDtTs2tP6DHCf9QNE5Rh-w1FMQ/edit?usp=sharing

dave.enyeart (Mon, 12 Mar 2018 05:34:07 GMT):
I added access based on the gmail IDs that I have. Ping me or request access via the doc so that I can add your gmail ID to the access list.

dave.enyeart (Mon, 12 Mar 2018 05:34:43 GMT):
I intend to share public, but wanted maintainers to do a pass first

dave.enyeart (Mon, 12 Mar 2018 05:35:35 GMT):
Please add your ideas and edits

jyellick (Mon, 12 Mar 2018 20:21:35 GMT):
@here Maintainers: As we enter development for v1.2, it is time for us to make a concrete decision with respect to chaincode lifecycle. The existing problems have been known for around 6 months, and despite at least 9 distinct proposals, there is still no consensus to an approach. At the maintainer's meeting on February 5th, it was my impression that we agreed upon one more week for alternate proposals and deliberation, then we would make a decision. It is now (obviously) over a month later. We need to end this. The proposal needs to: A. Solve the original problem: "restrict who can instantiate chaincodes on a channel" B. Be possible to implement correctly by the release of v1.2. C. Support the other v1.2 (and unloved v1.0/v1.1) use cases, like private data, and pluggable escc/vscc. (See [1]) There is a design task, for the chaincode lifecycle epic: https://jira.hyperledger.org/browse/FAB-8787 . In this task, there is a link to a design document which IMO addresses all three of these points. Like all of the proposals, there are things to dislike about it, but IMO this is not an item which brings a lot of value to our users, and I would much rather we be devoting our time and energy to pieces like BFT ordering or ZK which we know users are asking for. There are other proposals, which I do not personally believe satisfy (A), (B), (C), so I will leave it to others to bring them forward if they feel they are viable. So, I come here to you fellow maintainers, to see if we can get some agreement on a path forward. In my opinion, we need a concrete and final decision on lifecycle ASAP, ideally within the next 48 hous, but definitely by the end of the week. I always hope that we can build consensus around the decisions in fabric, but we cannot afford another 6 months of debate, and there is nothing to indicate optimism that we will arrive at a unanimous decision anytime soon. [1] Because it seems to be a point which is not acknowledged in the comments on the doc: to support pluggable escc/vscc, I see no way to solve chaincode lifecycle without splitting define and Init. At validation time, both the VSCC of the LSCC and the custom VSCC of the chaincode must be satisfied. Since there is only one set of endorsements, and only the ESCC of the initially called chaincode (LSCC) endorses, a cc2cc style Init can never pass validation, and therefore can never be instantiated. If we are dead set on not splitting define/Init, the only way I see to fix cc2cc invocation with different ESCC/VSCCs, would be to change our transaction format to accommodate multiple sets of endorsements, and change the invocation path to invoke the ESCC for each chaincode in a cc2cc context, and update the corresponding validation code to map the correct set of endorsements to the correct VSCC. Finally, even if all of this were changed, we would still have the problem that one of the rationales for custom ESCC/VSCC is for zero-knowledge applications, where revealing the identity of the endorsing peer breaks the security of the application, and bundling standard X.509 endorsements with ZK ones would be counterproductive. Even if there is a clever way to address the latter problem, all of these changes seem sufficiently big that trying to satisfy (B) of implementing correctly for v1.2 is unlikely.

yacovm (Mon, 12 Mar 2018 20:31:18 GMT):
I must say I don't understand the problem with splitting `instantiate` into `define` and `init` - the tough part is behind all these - to collaborate out of band and install the metadata package on the chaincodes. With service discovery capabilites - the client SDK knows exactly which peers it can ask for `define` and which for `init` and it should be a breeze - coupled with registering to events - we should be make those 2 appear atomic to the end-user.

yacovm (Mon, 12 Mar 2018 20:31:18 GMT):
I must say I don't understand the problem with splitting `instantiate` into `define` and `init` - the tough part in the design is actually behind both of them - to collaborate out of band and install the metadata package on the chaincodes. With service discovery capabilites - the client SDK knows exactly which peers it can ask for `define` and which for `init` and it should be a breeze - coupled with registering to events - we should be make those 2 appear atomic to the end-user.

yacovm (Mon, 12 Mar 2018 20:31:18 GMT):
I must say I don't understand the problem with splitting `instantiate` into `define` and `init` - the tough part in the design is actually behind both of them - to collaborate out of band and install the metadata package on the chaincodes. With service discovery capabilites - the client SDK knows exactly which peers it can ask for `define` (LSCC EP) and which for `init` (since it has been defined a couple of second ago!) and it should be a breeze - coupled with registering to events - we should be make those 2 appear atomic to the end-user.

yacovm (Mon, 12 Mar 2018 20:31:18 GMT):
I must say I don't understand the problem with splitting `instantiate` into `define` and `init` - the tough part in the design is actually behind both of them - to collaborate out of band and install the metadata package on the chaincodes. With service discovery capabilites - the client SDK knows exactly which peers it can ask for `define` (LSCC EP) and which for `init` (since it has been defined a couple of second ago!) and it should be a breeze - coupled with registering to events - the end user doesn't have to do anything at all. He/she can sit back and relax while the chaincodes is being defined and init-ed!

yacovm (Mon, 12 Mar 2018 20:31:18 GMT):
I must say I don't understand the problem with splitting `instantiate` into `define` and `init` - the tough part in the design is actually behind both of them - to collaborate out of band and install the metadata package on the chaincodes. With service discovery capabilites - the client SDK knows exactly which peers it can ask for `define` (LSCC EP) and which for `init` (since it has been defined a couple of second ago!) and it should be a breeze - coupled with registering to events - the end user doesn't have to do anything at all. He/she can sit back and relax while the chaincode is being defined and init-ed!

yacovm (Mon, 12 Mar 2018 20:31:18 GMT):
I must say I don't understand the problem with splitting `instantiate` into `define` and `init` - the tough part in the design is actually _ before _ both of them - to collaborate out of band and install the metadata package on the chaincodes. With service discovery capabilites - the client SDK knows exactly which peers it can ask for `define` (LSCC EP) and which for `init` (since it has been defined a couple of second ago!) and it should be a breeze - coupled with registering to events - the end user doesn't have to do anything at all. He/she can sit back and relax while the chaincode is being defined and init-ed!

manish-sethi (Mon, 12 Mar 2018 20:35:38 GMT):
Personally, I never understood the overemphasis that `init` had been receiving as a special function at the first place.

muralisr (Mon, 12 Mar 2018 21:46:10 GMT):
@jyellick +1 to try and wrap this up soon

GopalPanda (Tue, 13 Mar 2018 01:53:54 GMT):
Has joined the channel.

jyellick (Wed, 14 Mar 2018 02:14:52 GMT):
As an update to what was posted above, I believe we have reached an agreement for the approach to chaincode lifecycle as linked in the document to FAB-8787. Although the agreement comes with some reservations, since there is agreement, I'll plan to move forward with coordinating an implementation for v1.2.

dave.enyeart (Wed, 14 Mar 2018 04:20:03 GMT):
Thank you Jason for your patience and diligence to have successfully driven this through consensus. While it’s been clear for a while that no single solution would make all maintainers 100% satisfied, you have woven a path that meets the core objectives and that all maintainers can live with. While it’s been a challenging process, there’s a lot to be proud of here in terms of the consensus building and respect for everybody’s ideas. And thanks to everybody that worked on various proposals, as each revision helped to nudge us towards a workable solution. Time to execute!

dave.enyeart (Wed, 14 Mar 2018 16:11:08 GMT):
important one to review for 1.1: https://gerrit.hyperledger.org/r/#/c/19157/

dave.enyeart (Wed, 14 Mar 2018 22:48:41 GMT):
We intend to cut 1.1 release tomorrow. 1.1 has held up well under system test, and the number of new defect arrivals has been very low and slowing.

dave.enyeart (Wed, 14 Mar 2018 22:48:41 GMT):
We intend to cut 1.1 release tomorrow. 1.1 rc1 has held up well under system test, and the number of new defect arrivals has been very low and slowing.

dave.enyeart (Wed, 14 Mar 2018 22:48:41 GMT):
@here We intend to cut 1.1 release tomorrow. 1.1 rc1 has held up well under system test, and the number of new defect arrivals has been very low and slowing.

dave.enyeart (Wed, 14 Mar 2018 22:50:17 GMT):
fabric and fabric-ca will be cut from release-1.1 branches, so we will have merge freeze in those repositories, no freeze needed on master.

dave.enyeart (Wed, 14 Mar 2018 22:51:58 GMT):
release-1.1 branches will also be created for fabric-chaincode-node, fabric-sdk-node, fabric-samples during the cut.

dave.enyeart (Wed, 14 Mar 2018 22:52:56 GMT):
fabric-sdk-java has some more fixes and test coming, so it will not be released on the same schedule.

dave.enyeart (Wed, 14 Mar 2018 22:53:40 GMT):
speak now if you know of any late breaking release blocker

dave.enyeart (Thu, 15 Mar 2018 18:27:19 GMT):
Release process for v1.1 starting, although we need to wait for some final automated tests to finish later this afternoon.

dave.enyeart (Thu, 15 Mar 2018 18:27:33 GMT):
we'll post updates in #fabric-release

dave.enyeart (Fri, 16 Mar 2018 05:04:56 GMT):
Hyperledger Fabric v1.1 release artifacts are published for fabric, fabric-ca, fabric-chaincode-node, fabric-sdk-node, and documentation. Go ahead and download and try it out: http://hyperledger-fabric.readthedocs.io/en/release-1.1/samples.html#binaries You can checkout latest master in fabric-samples for trials. After we get some more success confirmations on various platforms Friday, we will tag fabric-samples and announce the release.

dave.enyeart (Fri, 16 Mar 2018 05:07:01 GMT):
Release cutting Jira https://jira.hyperledger.org/browse/FAB-8881 sub-tasks are up to date with comments in remaining items.

cbf (Fri, 16 Mar 2018 13:02:56 GMT):
@smithbk @rameshthoomu fabric-ca e2e test consistently failing... can you please look into this

cbf (Fri, 16 Mar 2018 13:03:08 GMT):
https://gerrit.hyperledger.org/r/c/19273/

rjones (Sun, 18 Mar 2018 03:46:56 GMT):
Has joined the channel.

rjones (Sun, 18 Mar 2018 03:47:23 GMT):
Does the default branch need to change from `release-1.0` to `release-1.1`? https://github.com/hyperledger/fabric/branches

dave.enyeart (Sun, 18 Mar 2018 04:09:56 GMT):
yes, default branch should be changed to release-1.1 for these projects:

dave.enyeart (Sun, 18 Mar 2018 04:10:08 GMT):
fabric

dave.enyeart (Sun, 18 Mar 2018 04:10:17 GMT):
fabric-ca

dave.enyeart (Sun, 18 Mar 2018 04:10:30 GMT):
fabric-chaincode-node

dave.enyeart (Sun, 18 Mar 2018 04:10:42 GMT):
fabric-sdk-node

dave.enyeart (Sun, 18 Mar 2018 04:11:16 GMT):
fabric-samples

dave.enyeart (Sun, 18 Mar 2018 04:12:29 GMT):
also, fabric-samples `release` branch can be deleted now that we have `release-1.0` branch, like we did in the other projects (I confirmed with Ramesh that nothing in CI uses `release`)

rjones (Sun, 18 Mar 2018 04:15:54 GMT):
@dave.enyeart could you log in to github and go here: https://github.com/hyperledger/fabric-samples/network/dependencies#balance-transfer%252Fpackage-lock.json please

rjones (Sun, 18 Mar 2018 04:17:29 GMT):
hmm I can't add you as a collaborator

dave.enyeart (Sun, 18 Mar 2018 04:17:58 GMT):
i'm there

rjones (Sun, 18 Mar 2018 04:18:03 GMT):
do you want me to file that bug or no?

rjones (Sun, 18 Mar 2018 04:18:31 GMT):
you might need to refresh

dave.enyeart (Sun, 18 Mar 2018 04:19:12 GMT):
yes go ahead and open a jira

dave.enyeart (Sun, 18 Mar 2018 04:20:19 GMT):
probably should follow the process from the hyperledger wiki right?

rjones (Sun, 18 Mar 2018 04:22:02 GMT):
https://jira.hyperledger.org/browse/FAB-8947

rjones (Mon, 19 Mar 2018 01:18:17 GMT):
https://gerrit.hyperledger.org/r/#/c/19361/ (master) https://gerrit.hyperledger.org/r/#/c/19363/ (release-1.1)

dave.enyeart (Tue, 20 Mar 2018 13:58:36 GMT):
Starting in two minutes:

dave.enyeart (Tue, 20 Mar 2018 13:58:36 GMT):
@here Starting in two minutes:

dave.enyeart (Tue, 20 Mar 2018 13:58:46 GMT):
Community call - Improving the consistency and flexibility of the Fabric Code base - Matt Sykes https://ibm.webex.com/join/enyeart Let's use the dial in number that webex provides.

wjzheng (Tue, 20 Mar 2018 19:07:16 GMT):
Has joined the channel.

ShikarSharma (Tue, 20 Mar 2018 22:43:46 GMT):
Has joined the channel.

jyellick (Wed, 21 Mar 2018 19:23:07 GMT):
https://jira.hyperledger.org/browse/FAB-8788 ^ Here is a design of what to do with the Fabric ACLs previously known as RSCC and or Resources. Any feedback is appreciated.

jyellick (Wed, 21 Mar 2018 19:23:07 GMT):
https://jira.hyperledger.org/browse/FAB-8788 ^ Here is a design of what to do with the peer ACLs previously known as RSCC and or Resources. Any feedback is appreciated.

rjones (Thu, 22 Mar 2018 19:04:37 GMT):
Has left the channel.

greg.haskins (Thu, 22 Mar 2018 19:47:18 GMT):
hey guys, question about release numbering

greg.haskins (Thu, 22 Mar 2018 19:47:36 GMT):
i have a patch to chaintool that I want to get into the v1.1.x stream

greg.haskins (Thu, 22 Mar 2018 19:48:21 GMT):
the fabric v1.1.0 release ships with chaintool is v1.0.1

greg.haskins (Thu, 22 Mar 2018 19:49:08 GMT):
the change that I have could go either way in terms of chaintool being v1.0.2 or v1.1.0 (its the addition of a CCI grammar type

greg.haskins (Thu, 22 Mar 2018 19:49:42 GMT):
given that the grammar type is ABI impacting, it could easily justify a bump of MINOR to v1.1.0

greg.haskins (Thu, 22 Mar 2018 19:49:52 GMT):
but I didnt want that to be confused with fabric v1.1.0

jyellick (Thu, 22 Mar 2018 19:59:32 GMT):
My personal take would be stick to semver, go to v1.1.0, and maybe add a doc/note somewhere mentioning that its version and Fabric's are not tied together.

greg.haskins (Thu, 22 Mar 2018 20:01:13 GMT):
@jyellick that sounds reasonable to me

greg.haskins (Thu, 22 Mar 2018 20:40:22 GMT):
@jyellick @dave.enyeart https://jira.hyperledger.org/browse/FAB-9061

greg.haskins (Thu, 22 Mar 2018 20:40:49 GMT):
assuming this is agreed upon, ill cut the release and then submit a CR to update the fabric release-1.1 branch

rjones (Thu, 22 Mar 2018 22:19:00 GMT):
Has joined the channel.

rjones (Thu, 22 Mar 2018 22:19:20 GMT):
https://gerrit.hyperledger.org/r/#/q/FAB-9063 I request further discussion

rjones (Thu, 22 Mar 2018 22:20:14 GMT):
I get complaints that it is opaque that the Fabric Release Managers having this hidden +2 ability, so I want to make it public.

greg.haskins (Thu, 22 Mar 2018 22:47:21 GMT):
@rjones: merged for chaintool

rjones (Thu, 22 Mar 2018 22:58:11 GMT):
@greg.haskins thank you

greg.haskins (Fri, 23 Mar 2018 13:42:49 GMT):
hi all, I have a few fixes related to chaintool for v1.1.x that I would love to see get into v1.1.1

greg.haskins (Fri, 23 Mar 2018 13:42:52 GMT):
https://jira.hyperledger.org/browse/FAB-9073

greg.haskins (Fri, 23 Mar 2018 13:42:54 GMT):
for example

greg.haskins (Fri, 23 Mar 2018 13:43:06 GMT):
any objections if I start to push some CRs to the release-1.1 branch

greg.haskins (Fri, 23 Mar 2018 13:43:07 GMT):
?

greg.haskins (Fri, 23 Mar 2018 13:43:35 GMT):
heres another: https://jira.hyperledger.org/browse/FAB-9059

greg.haskins (Fri, 23 Mar 2018 13:43:51 GMT):
(actually @muralisr will be tackling 9059

greg.haskins (Fri, 23 Mar 2018 13:44:06 GMT):
but the target of release-1.1 is the important thing to discuss

greg.haskins (Fri, 23 Mar 2018 13:57:26 GMT):
https://gerrit.hyperledger.org/r/#/c/19673/

rjones (Fri, 23 Mar 2018 16:35:58 GMT):
@cbf @dave.enyeart @mastersingh24 I need a hand. https://gerrit.hyperledger.org/r/#/c/19637/ https://gerrit.hyperledger.org/r/#/c/19635/

rjones (Fri, 23 Mar 2018 16:37:21 GMT):
@cbf @dave.enyeart @mastersingh24 I think there is a larger discussion you need to have with @rickr in regards to https://gerrit.hyperledger.org/r/#/c/19645/

cbf (Fri, 23 Mar 2018 21:21:14 GMT):
@rickr the maintainers agreed that the release manages needed to have maintainer (commit) privs for the purpose of cutting branches, tags and merging CRs during a release. Please merge the CR. Thanks

muralisr (Sat, 24 Mar 2018 12:10:01 GMT):
@greg.haskins I think the chaintool update is isolated enough to be low-risk but not sure of the rules around it ( @cbf @dave.enyeart @mastersingh24 , thoughts please ?)

mastersingh24 (Sat, 24 Mar 2018 13:34:45 GMT):
@muralisr - I assume you are asking about updating chaintool version for v1.1.1 ? We should definitely do it for master branch in any case

muralisr (Sat, 24 Mar 2018 13:37:30 GMT):
so basically push to master branch and at some point will pull into v1.1.1 branch @mastersingh24 ?

mastersingh24 (Sat, 24 Mar 2018 13:38:06 GMT):
minimally we should do master branch. I'm ok with adding it to v1.1.1 as well ... seems low risk

greg.haskins (Sat, 24 Mar 2018 14:49:36 GMT):
yeah, my assumption is that almost everything that goes into release-1.1 branch should also go to master....not sure how we want to facilitate that

greg.haskins (Sat, 24 Mar 2018 14:49:46 GMT):
this is generally a weak spot of the gerrit model

greg.haskins (Sat, 24 Mar 2018 14:50:18 GMT):
shall I submit a coincident CR to master as well?

greg.haskins (Sat, 24 Mar 2018 14:50:46 GMT):
i was going to wait until it was merged in 1.1 but I can fire one in any time

rjones (Sat, 24 Mar 2018 16:07:54 GMT):
I would advise a merge from release to master doing a --ours as appropriate

rjones (Sat, 24 Mar 2018 16:08:14 GMT):
--no-ff -s etc

cbf (Mon, 26 Mar 2018 12:28:54 GMT):
@greg.haskins yeah, would be good to get things aligned.

dave.enyeart (Tue, 27 Mar 2018 14:15:10 GMT):
@cbf I agree we should have a maintainer meeting soon. I am out of office this week, but don't let that hold things up. I've dumped my release planning thoughts at the end of the retrospective doc:

dave.enyeart (Tue, 27 Mar 2018 14:15:24 GMT):
https://docs.google.com/document/d/1qyYDY6yn8_unFKmxmUDtTs2tP6DHCf9QNE5Rh-w1FMQ/edit#heading=h.guz3k8svs8k8

cbf (Tue, 27 Mar 2018 15:03:38 GMT):
@dave.enyeart you take care, I'll try to do justice to your retro comments/thoughts

bbehlendorf (Wed, 28 Mar 2018 21:13:52 GMT):
Has joined the channel.

cbf (Wed, 28 Mar 2018 21:55:09 GMT):
@here reminder we'll have a maintainers meeting tomorrow at 9 am ET https://wiki.hyperledger.org/community/calendar-public-meetings

cbf (Thu, 29 Mar 2018 12:45:19 GMT):
@here just a reminder about the maintainers meeting at 9 am ET (15 minutes)

cbf (Thu, 29 Mar 2018 12:45:33 GMT):
we'll be discussing the retrospective doc above

cbf (Thu, 29 Mar 2018 12:47:47 GMT):
https://zoom.us/j/969277614

cbf (Thu, 29 Mar 2018 13:46:46 GMT):
@here zoom crashed

cbf (Thu, 29 Mar 2018 13:46:59 GMT):
cannot restart @tkuhrt

cbf (Thu, 29 Mar 2018 13:47:09 GMT):
are others having same problem?

tkuhrt (Thu, 29 Mar 2018 13:47:16 GMT):
We are all still in

cbf (Thu, 29 Mar 2018 13:47:29 GMT):
when I try to join it says invalid meeting id

tkuhrt (Thu, 29 Mar 2018 13:47:37 GMT):
Hmm...

jyellick (Thu, 29 Mar 2018 13:47:42 GMT):
I joined successfully < 5 minutes ago

tkuhrt (Thu, 29 Mar 2018 13:47:44 GMT):
https://zoom.us/j/969277614

yacovm (Thu, 29 Mar 2018 13:47:52 GMT):
just provide '#' (empty meeting ID) - maybe it works?

rjones (Thu, 29 Mar 2018 20:55:36 GMT):
User User_1 added by rjones.

rjones (Thu, 29 Mar 2018 20:56:22 GMT):
When this change is merged: https://gerrit.hyperledger.org/r/#/c/19941/ the in-flight changes for project:fabric will either need to have CI run again, or be manually voted on.

rjones (Thu, 29 Mar 2018 20:56:57 GMT):
When this change is merged: https://gerrit.hyperledger.org/r/#/c/19503/ the fabric CI process will change substantially.

rjones (Thu, 29 Mar 2018 20:57:33 GMT):
Any objections? This may create some turbulence for a little while.

cbf (Thu, 29 Mar 2018 23:00:36 GMT):
I suggest we bite the bullet... easter weekend, passover maybe tomorrow is a good time to do this? @rjones @mastersingh24 - @rameshthoomu @tongli are you guys comfortable? It might also be worthwhile sending an email to the hyperledger-fabric mailing list explaining the new CI pipeline

rjones (Thu, 29 Mar 2018 23:06:24 GMT):
@cbf I'm not around this weekend. Jenkins is doing nothing ATM. You say go, it can happen now.

rjones (Thu, 29 Mar 2018 23:07:26 GMT):
@cbf my largest concern is the ~125 in flight changes that will either need a new pass of CI, or manual voting, which is why I've been flogging a couple trivial changes in #fabric-pr-review

yacovm (Thu, 29 Mar 2018 23:08:15 GMT):
> Build-checks job only trigger for the patch set, rest all triggers based on the comment posted. Can you please explain what it means? when a change set is uploaded it will only run the build check and for the rest I need to comment? on the change set?

rjones (Thu, 29 Mar 2018 23:09:56 GMT):
@yacovm I _think_ the first job posts the comments to trigger other jobs.

rjones (Thu, 29 Mar 2018 23:09:56 GMT):
@yacovm I think the first job posts the comments to trigger other jobs.

yacovm (Thu, 29 Mar 2018 23:10:32 GMT):
oh, the 21 century is here

cbf (Thu, 29 Mar 2018 23:17:31 GMT):
I've been doing some cleanup, maybe tomorrow? I'd like a few others to weigh in in agreement

rjones (Thu, 29 Mar 2018 23:18:25 GMT):
OK. I'll direct other conversation into -pr-r

muralisr (Fri, 30 Mar 2018 14:01:27 GMT):
posting on behalf of @rameshthoomu ... he opened these high defects based on the recent CI failures. Will be good to get some eyes on these to reduce CI churn and help everyone!

muralisr (Fri, 30 Mar 2018 14:01:29 GMT):
FAB-9248 FAB-9100 FAB-9093 FAB-9212

greg.haskins (Mon, 02 Apr 2018 15:13:51 GMT):
so, I had a few CRs merged to release-1.1. What is the process for the (expected to be typical) case where those CRs should also apply to master?

greg.haskins (Mon, 02 Apr 2018 15:14:26 GMT):
are we automating this? maintainers manual merge? submitters manual re-submit ?

greg.haskins (Mon, 02 Apr 2018 15:16:25 GMT):
(for all I know, this has already been done..i havent looked yet)

greg.haskins (Mon, 02 Apr 2018 15:16:49 GMT):
I am more curious, as I know this was an unsolved problem in the v0.6 -> v1.0 days

mastersingh24 (Mon, 02 Apr 2018 16:15:21 GMT):
@greg.haskins - No automation ... but there's a process. As you know, now that we have cut v1.1.0, we should only be making bug fixes and improving docs on that branch. In both cases, when someone actually fixes the bug or creates the doc, they should actually tag the JIRA with the versions they think the bug/doc fix should go to. Once a CR is reviewed and ready for merge, whoever actually does the merge (or perhaps the reviews) should check the JIRA and if necessary cherrypick the CR to the appropriate branch(es). If it's not a straight cherrypick, then they can try to fix the conflict or ask the submitter of the CR to create a version for the other branch(es)

mastersingh24 (Mon, 02 Apr 2018 16:21:05 GMT):
I should say that both maintainer and submitter can do the cherrypick / resubmit, but the responsibility for ensuring patches make it to all relevant releases / branches falls on the maintainers

greg.haskins (Mon, 02 Apr 2018 16:38:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=YuTpjR847ArGz7si3) @mastersingh24 roger, ill submit those CRs now then

greg.haskins (Mon, 02 Apr 2018 16:39:05 GMT):
hopefully it wont be as chaotic as the v0.6 -> v1.0 branches since there should be much smaller divergence targeted to v1.1.x from v1.1.0

greg.haskins (Mon, 02 Apr 2018 16:41:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=WHHDTH5S3AHTrGxbS) @mastersingh24 BTW: I think this is understood, but the stuff I had been putting forth I wouldnt classify as either "bug" nor 'doc" per se, but it is intended to be fairly low-risk improvements to the build to facilitate maintenance of 1.1.x

greg.haskins (Mon, 02 Apr 2018 16:41:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=WHHDTH5S3AHTrGxbS) @mastersingh24 BTW: I think this is understood, but some of the stuff I had been putting forth I wouldnt classify as either "bug" nor 'doc" per se, but it is intended to be fairly low-risk improvements to the build to facilitate maintenance of 1.1.x

greg.haskins (Mon, 02 Apr 2018 16:41:59 GMT):
e.g. "make docker-list"

mastersingh24 (Mon, 02 Apr 2018 19:34:59 GMT):
I agree ...

greg.haskins (Wed, 04 Apr 2018 22:21:44 GMT):
test

greg.haskins (Wed, 04 Apr 2018 22:22:07 GMT):
anyone else seeing weirdness with this RC?

rjones (Wed, 04 Apr 2018 22:22:29 GMT):
I noticed it was super quiet today

greg.haskins (Wed, 04 Apr 2018 23:27:34 GMT):
two things I observed: 1) I was spontaneously logged out perhaps around 6pm (that generally never happens)

greg.haskins (Wed, 04 Apr 2018 23:27:57 GMT):
and 2) my messages to @jyellick appear to be pending, even though he appears to be online

greg.haskins (Wed, 04 Apr 2018 23:28:13 GMT):
not sure why my messages work in this channel and not on PM though

cbf (Wed, 04 Apr 2018 23:32:18 GMT):
+2 I was just notified about posts that were hours old according to TS

cbf (Wed, 04 Apr 2018 23:32:34 GMT):
@rjones maybe needs a reboot?

mastersingh24 (Thu, 05 Apr 2018 11:18:09 GMT):
@greg.haskins - maybe RC does not like you anymore? ;)

greg.haskins (Thu, 05 Apr 2018 12:00:59 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yCGvhRQ7uTeTGr2zC) @mastersingh24 indeed

mastersingh24 (Thu, 05 Apr 2018 16:09:44 GMT):
I think it's starting to hate me as well .... to be fair, I do say mean things about it

dave.enyeart (Sat, 07 Apr 2018 13:09:15 GMT):
As we've discussed previously, our documented guidance around using Vagrant or not is inconsistent. We need to clarify the docs once and for all, I think the choices are: 1) recommend to use vagrant 2) recommend not to use vagrant, except in certain scenarios (and still maintain it) 3) recommend not to use vagrant at all (and potentially remove the support) 4) state that it is developer choice and highlight the pros/cons of using vagrant (what are they?) Personally, I’ve just always used vagrant as that was the recommendation when I started, and I’ve had a decent experience with it. Does anybody have strong opinions?

yacovm (Sat, 07 Apr 2018 13:12:24 GMT):
I'm not sure why we need vagrant now? can't a windows developer just make an ubuntu 16 vm and run `make` ?

yacovm (Sat, 07 Apr 2018 13:12:24 GMT):
I'm not sure why we need vagrant now? can't a windows user just make an ubuntu 16 vm and run `make` ?

yacovm (Sat, 07 Apr 2018 13:16:37 GMT):
in the past the dependencies were much more like rocksDB, BDD, etc.

yacovm (Sat, 07 Apr 2018 13:20:34 GMT):
:eight_spoked_asterisk: not a strong opinion...

yacovm (Sat, 07 Apr 2018 13:20:34 GMT):
* not a strong opinion...

cbf (Sat, 07 Apr 2018 17:25:07 GMT):
older versions of Windows not so much...

cbf (Sat, 07 Apr 2018 17:25:37 GMT):
at the end of the day, this is a fabric developer thing only

cbf (Sat, 07 Apr 2018 17:26:04 GMT):
I do know that some still use it based on some of the comments I've read in RC and email

cbf (Sat, 07 Apr 2018 17:26:36 GMT):
what I think is that IFF we keep it, we maintain it

cbf (Sat, 07 Apr 2018 17:26:55 GMT):
but, that also means someone needs to care

cbf (Sat, 07 Apr 2018 17:34:19 GMT):
I would recommend we send a note to the mailing list and ask if anyone cannot live without it, wait a week (reminding in the interim that it will be removed if we don't receive sufficient interest) and make a decision based on that feedback.

mastersingh24 (Sun, 08 Apr 2018 12:35:50 GMT):
@kostas did have comment about his use of it and the value he sees .... but agree we can't just leave this thing around with no one updating it

pandrejko (Mon, 09 Apr 2018 13:00:00 GMT):
Has joined the channel.

cbf (Mon, 09 Apr 2018 14:32:10 GMT):
+1

kostas (Mon, 09 Apr 2018 15:54:00 GMT):
All fair points on it being a dev thing and needing maintenance. If nobody offers to maintain, I'm fine with having it removed.

JonathanLevi (Mon, 09 Apr 2018 18:20:13 GMT):
True. Just to say, that some of our devs are (still) using Vagrant for dev - but that's mainly because/to check that our stuff works with Vagrant.

JonathanLevi (Mon, 09 Apr 2018 18:20:41 GMT):
If we agree to remove it, we will work "natively" with Ubuntu only.

JonathanLevi (Mon, 09 Apr 2018 18:21:27 GMT):
Wonder who is using Ubuntu 18.04 "final beta" already... or am I the only crazy one, who spent the weekend on fixing his/her bluetooth headset volume ;-)

jyellick (Mon, 09 Apr 2018 19:11:50 GMT):
I would not like to volunteer to maintain it, but, I do fire it up from time to time when I am trying to verify that a failure or strange output is not a peculiarity of my local environment

guoger (Tue, 10 Apr 2018 03:06:07 GMT):
Has joined the channel.

cbf (Tue, 10 Apr 2018 10:53:48 GMT):
for a good laugh: https://www.youtube.com/watch?v=NSemlYagjIU

yacovm (Tue, 10 Apr 2018 10:57:14 GMT):
i am laughing but also crying

cbf (Tue, 10 Apr 2018 11:03:40 GMT):
lol

cbf (Tue, 10 Apr 2018 11:03:54 GMT):
it's brilliant

cbf (Tue, 10 Apr 2018 11:08:24 GMT):
LOL the tests that are broken, "just ignore them"

mastersingh24 (Tue, 10 Apr 2018 11:09:20 GMT):
comedy

rjones (Tue, 10 Apr 2018 14:10:12 GMT):
I knew Scons was part of that.

dave.enyeart (Wed, 11 Apr 2018 11:45:31 GMT):
For the maintainer meeting, I put together a view of v1.2 release plan. Feel free to preview and make comments for discussion:

dave.enyeart (Wed, 11 Apr 2018 11:45:41 GMT):
https://docs.google.com/document/d/1prtMkLOkZZx7RYi_meb-3yY6lgFhISLQtx8AcSMDhdo/edit

dave.enyeart (Wed, 11 Apr 2018 13:03:57 GMT):
@here maintainer meeting starting

dave.enyeart (Wed, 11 Apr 2018 13:04:07 GMT):
https://zoom.us/j/797255621

mastersingh24 (Wed, 11 Apr 2018 14:06:38 GMT):
Thanks @dave.enyeart and nice job facilitating the call!

harrijk (Wed, 11 Apr 2018 14:10:05 GMT):
Has left the channel.

tkuhrt (Wed, 11 Apr 2018 18:28:58 GMT):
As asked in this morning's maintainers call, all recordings are stored in the following Google Drive folder: https://drive.google.com/drive/u/0/folders/15w14LqjdgREkCabSzWfsgZpj4BPypa9a (currently uploading this morning's call)

kostas (Wed, 11 Apr 2018 19:57:25 GMT):
^^ Is this link somewhere on our website/wiki? (If not, can we make it so?)

tkuhrt (Wed, 11 Apr 2018 23:03:46 GMT):
@kostas : I added it under https://wiki.hyperledger.org/projects/fabric?&#meetings

kostas (Fri, 13 Apr 2018 14:24:42 GMT):
Can someone with access to the allowed components list in JIRA create a "fabric-common" component please?

kostas (Fri, 13 Apr 2018 14:26:41 GMT):
There are issues that span a range of components, and the current practice of tagging everything with "fabric-peer, fabric-orderer, fabric-foo, fabric-bar" etc. strikes me as silly. (For instance, how would you label something related to policies/cauthdsl?)

rjones (Fri, 13 Apr 2018 16:33:54 GMT):
@kostas https://jira.hyperledger.org/issues/?jql=project%20%3D%20FAB%20AND%20component%20%3D%20fabric-common

kostas (Fri, 13 Apr 2018 16:37:52 GMT):
@rjones: Excellent, thank you.

rjones (Tue, 17 Apr 2018 22:41:11 GMT):
I wish to make a possible controversial change to Gerrit. I'm asking all the teams that use Gerrit. May I require JIRA links in all Gerrit changes? this isn't something I can enable on a per-project basis.

dave.enyeart (Wed, 18 Apr 2018 00:18:45 GMT):
We ask people to do it regardless, so requiring it is one less thing we have to try to enforce ourselves

cbf (Wed, 18 Apr 2018 13:31:22 GMT):
ok for fabric, fabric-ca, fabric-sdk* etc

cbf (Wed, 18 Apr 2018 13:32:10 GMT):
I think, though, that you will want to raise this across all projects maybe via hyperledger-technical-discuss list?

dave.enyeart (Wed, 18 Apr 2018 14:16:24 GMT):
We seem to be challenged with oversight and reviews in the areas of build, CI, image creation. Probably because this is a niche area that requires certain skills and dedicated time. Is there a maintainer that could volunteer to be our point person in this area, go deep, and provide oversight and guidance? Or perhaps we need to nominate a non-maintainer that could help in this area (potentially becoming a maintainer in the future). Thoughts?

dave.enyeart (Wed, 18 Apr 2018 14:16:31 GMT):
Note - it is the stalled docker multi-architecture support (https://gerrit.hyperledger.org/r/#/c/18467/) that triggered this...but I've been thinking we need a point person in this area for a while.

ericmvaughn (Thu, 19 Apr 2018 13:35:04 GMT):
Has joined the channel.

cbf (Thu, 19 Apr 2018 15:22:39 GMT):
I'd be happy to lead this @dave.enyeart

huikang (Fri, 20 Apr 2018 19:21:54 GMT):
Has joined the channel.

kostas (Sat, 21 Apr 2018 00:17:38 GMT):
Taking a stub at the CRs starting from the older ones first -- how do we treat CRs related to features that won't be in 1.2? In an ideal world, the submitter would know that, and they'd be OK with rebasing until the time is right to merge. I have a feeling this is not the case for several of the CRs that I'm seeing though. So, what is the message that we leave in those CRs? Do we let them know that the CR won't cut it for the next version, and live with a CR that will still there stale until the time is right to merge (at which point we invite the submitter to rebase and edit as needed)? Do we abandon the CR, at the risk of discouraging submitters and sending the wrong message? Between the two options, I'm tending towards the former, but maybe a better suggestion is still out there.

kostas (Sat, 21 Apr 2018 00:17:38 GMT):
Taking a stub at the CRs starting from the older ones first -- how do we treat CRs related to features that won't be in 1.2? In an ideal world, the submitter would know that, and they'd be OK with rebasing until the time is right to merge. I have a feeling this is not the case for several of the CRs that I'm seeing though. So, what is the message that we leave in those CRs? Do we let them know that the CR won't cut it for the next version, and live with a CR that will stale there until the time is right to merge (at which point we invite the submitter to rebase and edit as needed)? Do we abandon the CR, at the risk of discouraging submitters and sending the wrong message? Between the two options, I'm tending towards the former, but maybe a better suggestion is still out there.

cbf (Sat, 21 Apr 2018 00:25:26 GMT):
I think that we should do the former - advise it will be postponed until post 1.2 and maybe mark as WIP so that it won't be confused

cbf (Sat, 21 Apr 2018 00:26:08 GMT):
or better yet, mark as [1.3]

mastersingh24 (Sat, 21 Apr 2018 13:06:43 GMT):
Right .... this is not atypical at all ... I had some CRs against loopback and Kafka back in the day which hung out for a while

cbf (Sat, 21 Apr 2018 20:22:21 GMT):
it just needs to be communicated early

hosemose (Tue, 24 Apr 2018 04:59:35 GMT):
Has joined the channel.

gombiuda (Tue, 24 Apr 2018 06:09:51 GMT):
Has joined the channel.

cbf (Tue, 24 Apr 2018 11:50:35 GMT):
@here apologies for the late notice, but we will hold our bi-weekly maintainers meeting tomorrow, Wednesday April 25 at 9 am ET

cbf (Tue, 24 Apr 2018 11:51:06 GMT):
@tkuhrt would you please add this as a regular call (bi-weekly wednesdays at 9 am)

cbf (Tue, 24 Apr 2018 11:51:23 GMT):
we'll also need a zoom link, thanks

tkuhrt (Tue, 24 Apr 2018 17:46:48 GMT):
@cbf: Details on the community calendar - https://www.google.com/calendar/event?eid=M2tzZzZzZ2xtM3YxbDM3ZWtrOWI5dHZtMWxfMjAxODA0MjVUMTMwMDAwWiBsaW51eGZvdW5kYXRpb24ub3JnX25mOXU2NGc5azlydmQ5Zjh2cDR2dXIyM2IwQGc&ctz=America/New_York

cbf (Tue, 24 Apr 2018 19:07:49 GMT):
thanks @tkuhrt !

anishman (Wed, 25 Apr 2018 10:37:20 GMT):
Has joined the channel.

dave.enyeart (Wed, 25 Apr 2018 12:30:17 GMT):
@here reminder - maintainer meeting in 30 minutes

dave.enyeart (Wed, 25 Apr 2018 12:30:34 GMT):
we can use the release planning doc to guide the discussion again:

dave.enyeart (Wed, 25 Apr 2018 12:30:35 GMT):
https://docs.google.com/document/d/1prtMkLOkZZx7RYi_meb-3yY6lgFhISLQtx8AcSMDhdo/edit

dave.enyeart (Wed, 25 Apr 2018 12:31:00 GMT):
I've added some discussion points in there... feel free to add other topics for discussion

dave.enyeart (Wed, 25 Apr 2018 12:58:58 GMT):
https://www.google.com/url?q=https%3A%2F%2Fzoom.us%2Fj%2F797255621

dave.enyeart (Wed, 25 Apr 2018 12:58:58 GMT):
https://zoom.us/j/797255621

dthibeau94 (Wed, 25 Apr 2018 13:05:45 GMT):
Has joined the channel.

tkuhrt (Wed, 25 Apr 2018 23:43:41 GMT):
Hey, all. Today, the maintainers meeting lasted for 259 minutes because people forgot to log out of Zoom when they were done. This means (I am guessing because I was in the air) that the Architecture WG and the Whitepaper WG was unable to meet. Please be cognizant when you use Zoom, that you must leave the meeting when you are done.

cbf (Thu, 26 Apr 2018 00:37:14 GMT):
Is there a way to limit the meeting to 60 mins?

cbf (Thu, 26 Apr 2018 00:37:41 GMT):
I agree that we need to be mindful, but sometimes sh*t happens;-)

tkuhrt (Fri, 27 Apr 2018 15:51:07 GMT):
No way to limit. Over in #architecture-wg we are talking about moving to a single number for all Hyperledger meetings.

chainsaw (Fri, 27 Apr 2018 15:52:39 GMT):
Has joined the channel.

youssefg (Wed, 02 May 2018 18:24:28 GMT):
Has joined the channel.

cbf (Thu, 03 May 2018 20:45:57 GMT):
I'd like to merge https://gerrit.hyperledger.org/r/c/20853/ soon. This transitions us from the x86_64 era to the amd64 era. It needs to be *coordinated* with a patch to CI that @rameshthoomu has teed up, We had to manually verify the change(because it needs the CI patch to verify) but this is ready to go. We just need to be sure that we coordinate the two merges... this has to go first. It may also require some re-triggering of verify jobs. If I could get 2 +2s (and @rameshthoomu please vote as well) then we can schedule the two merges

cbf (Thu, 03 May 2018 20:46:27 GMT):
I've got the -2 just so it isn't accidentally merged prematurely

am (Fri, 04 May 2018 19:06:33 GMT):
Has joined the channel.

dave.enyeart (Sat, 05 May 2018 13:18:56 GMT):

Test Strategy-v1.2.pptx.zip

dave.enyeart (Sat, 05 May 2018 13:19:05 GMT):
(remove .zip extension and then open the PPT)

dave.enyeart (Sat, 05 May 2018 13:19:37 GMT):
We'll review the test strategy with the Epic owners and community during the Monday fabric-scrum timeslot

dave.enyeart (Sat, 05 May 2018 13:19:37 GMT):
We'll review the v1.2 test strategy with the Epic owners and community during the Monday fabric-scrum timeslot

dave.enyeart (Sat, 05 May 2018 13:20:40 GMT):
Feel free to comment/edit and then I'll upload the final one Monday 9:30am

dave.enyeart (Sat, 05 May 2018 14:01:52 GMT):

Test Strategy-v1.2.pptx.zip

elainejlai (Tue, 08 May 2018 20:12:13 GMT):
Has joined the channel.

cbf (Tue, 08 May 2018 23:21:37 GMT):
DOn't forget, we have a maintainer's meeting tomorrow at 9 am

cbf (Tue, 08 May 2018 23:21:37 GMT):
DOn't forget, we have a maintainer's meeting tomorrow at 9 am ET tomorrow

cbf (Tue, 08 May 2018 23:21:38 GMT):
Topic: Hyperledger Fabric Maintainer's Meeting Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community Or iPhone one-tap : US: +16465588656,,4034983298# or +16699006833,,4034983298# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free) Meeting ID: 403 498 3298 International numbers available: https://zoom.us/u/bAaJoyznp

dave.enyeart (Wed, 09 May 2018 13:05:59 GMT):
@here starting maintainer meeting

dave.enyeart (Wed, 09 May 2018 13:06:06 GMT):
google doc: https://docs.google.com/document/d/1prtMkLOkZZx7RYi_meb-3yY6lgFhISLQtx8AcSMDhdo/edit

dave.enyeart (Tue, 15 May 2018 19:27:38 GMT):
I will be highlighting daily the priority CR reviews required to get to v1.2 code completion, as well as proposed reviewers (although all maintainers should review daily).

dave.enyeart (Tue, 15 May 2018 19:27:38 GMT):
I will be highlighting daily the priority CR reviews required to get to v1.2 code completion, as well as proposed reviewers based on who has most context (although all maintainers should help review daily).

dave.enyeart (Tue, 15 May 2018 19:27:49 GMT):
If you don't like my proposed reviewers list, let me know

dave.enyeart (Wed, 16 May 2018 13:29:58 GMT):
I posted the updated CR review priorities in #fabric-pr-review

dave.enyeart (Wed, 16 May 2018 13:30:08 GMT):
I will do it each morning

dave.enyeart (Wed, 16 May 2018 13:30:23 GMT):
feel free to add others that you think are high priority

cbf (Thu, 17 May 2018 15:48:57 GMT):
fabric-ca tests are unstable af

cbf (Thu, 17 May 2018 15:49:11 GMT):
I get different failures

cbf (Thu, 17 May 2018 15:49:12 GMT):
sigh

JonathanLevi (Thu, 17 May 2018 17:04:46 GMT):
Well, they are pushing me to merge a lot of stuff

JonathanLevi (Thu, 17 May 2018 17:04:57 GMT):
But the code is not that nice...

JonathanLevi (Thu, 17 May 2018 17:06:47 GMT):
(sorry, wrong chat window)

kostas (Mon, 21 May 2018 17:22:15 GMT):
Who has JIRA sudo powers when it comes to the dashboards for v1.2? Can they share those editing rights with me? For example, the query that we're using to track defect backlog development for 1.2 is wrong and I'd like to fix it. This was also the case for 1.1.)

rjones (Mon, 21 May 2018 17:31:49 GMT):
@kostas the group you need added to is jira-fabric-admins. someone would need to file a ticket: helpdesk@hyperledger.org to add you

kostas (Mon, 21 May 2018 17:32:51 GMT):
@rjones: Thanks. Can that someone be me? (I can write an excellent recommendation letter for myself, modesty is not an issue.)

rjones (Mon, 21 May 2018 17:33:48 GMT):
it would need to be @mastersingh24 @cbf @dave.enyeart or @Clayton Sims

rjones (Mon, 21 May 2018 17:33:48 GMT):
it would need to be @mastersingh24 @cbf @dave.enyeart or @simsc

kostas (Mon, 21 May 2018 17:34:04 GMT):
Got it, thank you.

cbf (Mon, 21 May 2018 17:34:31 GMT):
I have not been able to figure out how to share editing of dashboards

cbf (Mon, 21 May 2018 17:35:11 GMT):
@rjones AFAICT I cannot edit @simsc dashboard and vice-versa

rjones (Mon, 21 May 2018 17:35:19 GMT):
oh strange.

cbf (Mon, 21 May 2018 17:35:28 GMT):
it is R/O to me

rjones (Mon, 21 May 2018 17:35:58 GMT):
well, scratch that @kostas

cbf (Mon, 21 May 2018 17:36:06 GMT):
@kostas what does work is to describe what you want and send to Clayton

kostas (Mon, 21 May 2018 17:36:21 GMT):
Roger, will do. Thank you both.

kostas (Mon, 21 May 2018 17:55:39 GMT):
What is our policy with porting fixes to previous versions? Do we provide such fixes, or not?

kostas (Mon, 21 May 2018 17:55:51 GMT):
Previous versions in this case means v1.0.x

kostas (Mon, 21 May 2018 17:57:07 GMT):
Likewise, what is our policy with writing fixes for a potential v1.1.x given that 1.2 is right around the corner?

dave.enyeart (Mon, 21 May 2018 18:08:27 GMT):
we will backport critical fixes. so far anybody can propose such a backport by adding prior release FixVersion and providing a CR for the prior branch. Note that if there are no changes in the code between releases, the CR is as trivial as hitting the Cherry Pick button in the gerrit UI. Then the backport merge requires two +2 like any other CR. So we as maintainers are responsible for determining which fixes are critical and should think about this upon any fix merge.

kostas (Mon, 21 May 2018 18:09:18 GMT):
Do we backport to the previous minor release only, or all minor versions released?

dave.enyeart (Mon, 21 May 2018 18:09:20 GMT):
We don't have enough releases behind us yet, but soon enough we'll have to consider a policy, such as backport to latest N releases.

dave.enyeart (Mon, 21 May 2018 18:09:20 GMT):
We don't have enough releases behind us yet for it to become an issue, but soon enough we'll have to consider a policy, such as backport to latest N releases.

dave.enyeart (Mon, 21 May 2018 18:09:56 GMT):
Or latest minor release on current and prior major release.

kostas (Mon, 21 May 2018 18:10:04 GMT):
Got it, thanks Dave. @cbf: what is the norm?

dave.enyeart (Mon, 21 May 2018 18:16:54 GMT):
And as the releases stack up, tracking which fixes are in which releases will become more challenging. We'll likely need some more sophisticated tracking as anybody can easily miss setting the jira Fix Version correctly.

cbf (Mon, 21 May 2018 18:27:09 GMT):
well, we have not yet adopted an LTS posture, and the policy as such had been to backport to previous MINOR release

cbf (Mon, 21 May 2018 18:27:44 GMT):
so, if we find a defect in master, we would cherry-pick/backport to v1.0.x (e.g. v1.0.6)

cbf (Mon, 21 May 2018 18:27:56 GMT):
actually, check that

cbf (Mon, 21 May 2018 18:28:15 GMT):
we would backport to release-1.1 branch and then cut v1.0.7

cbf (Mon, 21 May 2018 18:28:25 GMT):
@kostas

kostas (Mon, 21 May 2018 18:29:33 GMT):
So anything that's deemed as a backportable (sic) fix, goes in v1.0.7 and v1.1.1?

kostas (Mon, 21 May 2018 18:30:13 GMT):
And once v1.2 is out, we only care about v1.1.x - @cbf: Y/N?

cbf (Mon, 21 May 2018 20:06:34 GMT):
yes

cbf (Mon, 21 May 2018 20:06:52 GMT):
although 1.0.7 questionable - think depending on severity

JonathanLevi (Mon, 21 May 2018 20:10:00 GMT):
Amigo maintainers

JonathanLevi (Mon, 21 May 2018 20:10:32 GMT):
I am having too many side convo's regarding this: https://gerrit.hyperledger.org/r/#/c/21161/

JonathanLevi (Mon, 21 May 2018 20:11:53 GMT):
I admit, that I pushed to merge (and merged after objections were removed from) https://gerrit.hyperledger.org/r/#/c/21159/

Sarah.Conway (Mon, 21 May 2018 20:12:04 GMT):
Has joined the channel.

JonathanLevi (Mon, 21 May 2018 20:12:15 GMT):
BUT, I did it mainly because there wasn't a claim for a "real" revocation algorithm

JonathanLevi (Mon, 21 May 2018 20:13:16 GMT):
So a few things:

JonathanLevi (Mon, 21 May 2018 20:13:21 GMT):
1. There are many issues, concerns and inconsistent discussions around revocations that have been taking place over the last few weeks.

JonathanLevi (Mon, 21 May 2018 20:14:13 GMT):
2. Remember the maintainer meeting we had when there are arguments regarding what should be revoked, deleted, from the CA, from the Node, etc... ? Here this is much more complicated.

JonathanLevi (Mon, 21 May 2018 20:14:29 GMT):
3. Bottom line, we already "shook on" not having the revocation in 1.2 (for several reasons)

JonathanLevi (Mon, 21 May 2018 20:14:39 GMT):
4. We merged a lot and very quickly already.

yacovm (Mon, 21 May 2018 20:14:47 GMT):
ahem, lets just be precise ;) It's a non-revocation ....

yacovm (Mon, 21 May 2018 20:15:00 GMT):
which is "epoch" based

JonathanLevi (Mon, 21 May 2018 20:15:23 GMT):
5. Why don't we just let it lay, have a week of integration tests... release 1.2 at a high quality... and revisit this in 1.3 as agreed ?

yacovm (Mon, 21 May 2018 20:16:03 GMT):
are the revocations support CRs going to fabric-CA or not?

JonathanLevi (Mon, 21 May 2018 20:16:09 GMT):
There are a lot of moving parts here, and some of this stuff is super "sensitive" cryptographically...

yacovm (Mon, 21 May 2018 20:17:50 GMT):
are the revocations support CRs going to fabric-CA or not?

JonathanLevi (Mon, 21 May 2018 20:20:20 GMT):
Not really.

yacovm (Mon, 21 May 2018 20:20:27 GMT):
how so?

yacovm (Mon, 21 May 2018 20:20:39 GMT):
I thought they are needed for the fabric core epoch non revocation stuff?

JonathanLevi (Mon, 21 May 2018 20:20:43 GMT):
These are all deferred. We just keep some of the core, which affects the API...

JonathanLevi (Mon, 21 May 2018 20:21:17 GMT):
Please be more specific. What are you missing/need?

JonathanLevi (Mon, 21 May 2018 20:21:38 GMT):
We really did agree not to have the revocation support. You can ask around ;-)

yacovm (Mon, 21 May 2018 20:22:00 GMT):
oh... then what is the issue? whether to merge the change sets but just not use them?

JonathanLevi (Mon, 21 May 2018 20:22:07 GMT):
I have just merged some SDK compatibility and stuff.

yacovm (Mon, 21 May 2018 20:22:15 GMT):
Can we just hide behind a compilation flag for fabric-core?

JonathanLevi (Mon, 21 May 2018 20:22:20 GMT):
The issue is that we should STOP CODING

JonathanLevi (Mon, 21 May 2018 20:22:51 GMT):
And not bring half-baked stuff that is due in 1.3 and try to squeeze it back into 1.2 just 5 days before the cut-off.

JonathanLevi (Mon, 21 May 2018 20:22:55 GMT):
:-)

JonathanLevi (Mon, 21 May 2018 20:23:03 GMT):
Seriously. Let's stabilize the tree.

yacovm (Mon, 21 May 2018 20:23:08 GMT):
so the merge freeze is in 5 days?

JonathanLevi (Mon, 21 May 2018 20:23:59 GMT):
Hopefully

JonathanLevi (Mon, 21 May 2018 20:24:09 GMT):
If we slow down the merges...

JonathanLevi (Mon, 21 May 2018 20:24:24 GMT):
... test and fix what's absolutely needed.

JonathanLevi (Mon, 21 May 2018 20:24:51 GMT):
We all know that we are still somewhat "in the Red".

JonathanLevi (Mon, 21 May 2018 20:25:10 GMT):
All I wanted to discuss and bring up that we should not volunteer to take more risk.

JonathanLevi (Mon, 21 May 2018 20:25:45 GMT):
Let's start converging in earnest, if possible.

yacovm (Mon, 21 May 2018 20:29:11 GMT):
I think, that if we decided not to have revocation support, then what's the risk here from a macro POV, excluding bugs? you can't revoke an identity anyway, and the users should be aware of that, so I say we just recommend https://gerrit.hyperledger.org/r/#/c/21161/ that poor CR. Since we're supposed to have e2e functional test(s) we should be good that it doesn't break anything, once we build the e2e tests

yacovm (Mon, 21 May 2018 20:29:11 GMT):
I think, that if we decided not to have revocation support, then what's the risk here from a macro POV, excluding bugs? you can't revoke an identity anyway, and the users should be aware of that, so I recommend merging https://gerrit.hyperledger.org/r/#/c/21161/ that poor CR. Since we're supposed to have e2e functional test(s) we should be good that it doesn't break anything, once we build the e2e tests

JonathanLevi (Mon, 21 May 2018 20:34:36 GMT):
I disagree.

JonathanLevi (Mon, 21 May 2018 20:35:03 GMT):
I think we need to review this properly.

JonathanLevi (Mon, 21 May 2018 20:35:31 GMT):
e2e tests don't tell you a thing about whether that encryption scheme is privacy preserving at all.

JonathanLevi (Mon, 21 May 2018 20:36:06 GMT):
We allowed a lot of stuff in back at the last minute of 1.1 this way.

JonathanLevi (Mon, 21 May 2018 20:36:16 GMT):
I don't think it's a good process.

yacovm (Mon, 21 May 2018 20:36:59 GMT):
> e2e tests don't tell you a thing about whether that encryption scheme is privacy preserving at all. true, but you can't actually figure that out from looking at the code. you need to read all their papers on the subject

JonathanLevi (Mon, 21 May 2018 20:37:18 GMT):
Therefore, we should just merge this ? ;-)

JonathanLevi (Mon, 21 May 2018 20:37:56 GMT):
I read Jan's papers on the subject. Maybe that's the issue? ;-)

JonathanLevi (Mon, 21 May 2018 20:38:31 GMT):
Seriously, let's be careful here. It's much worse to have an incomplete thing, than not to have it.

JonathanLevi (Mon, 21 May 2018 20:39:07 GMT):
And it's not a "poor CR" ;-) It's a series...

yacovm (Mon, 21 May 2018 20:39:44 GMT):
i mean the one remaining

JonathanLevi (Mon, 21 May 2018 20:41:39 GMT):
Again, I have already merged a CR this morning that went over my comfort zone... and pushed others to agree.

JonathanLevi (Mon, 21 May 2018 20:44:35 GMT):
Again, I have already merged a CR this morning that went way over my comfort zone... based on not having this algo in.

JonathanLevi (Mon, 21 May 2018 20:44:35 GMT):
Again, I have already merged a CR this morning that went way over/out of my comfort zone... based on not having this algo in.

JonathanLevi (Mon, 21 May 2018 20:45:26 GMT):
At any rate, I don't want to repeat myself, but still happy to discuss if you think that we should stuff more things from 1.3 into the 1.2 branch, while we are still in the red.

dave.enyeart (Tue, 22 May 2018 00:49:24 GMT):
I'm with you Jonathan, we are beyond the date for feature delivery, let's keep merges to fixes and polish to make the existing v1.2 features whole. This week and next week the focus is on testing and fixing issues.

dave.enyeart (Tue, 22 May 2018 00:49:28 GMT):
The only exception I'd say are SDKs, as they are using this week to finalize support for the recently merged v1.2 server features. I'm not thrilled about that, but it is what it is.

cbf (Tue, 22 May 2018 14:38:11 GMT):
@here FYI, I just pushed multi-arch manifests for fabric 1.1.0 images

cbf (Tue, 22 May 2018 14:38:28 GMT):
also tagged all x86_64-1.1.0 as amd64-1.1.0

cbf (Tue, 22 May 2018 14:38:52 GMT):
y'all can thank me later :grinning:

JonathanLevi (Tue, 22 May 2018 15:15:34 GMT):
@cbf and his "Hash Commit Reveal" scheme yet again!

dave.enyeart (Wed, 23 May 2018 03:08:08 GMT):
We have a maintainer's meeting tomorrow... several of us had conflicts at 9 am ET, we will start 30 minutes later at 9:30am ET. Topic: Hyperledger Fabric Maintainer's Meeting Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community Or iPhone one-tap : US: +16465588656,,4034983298# or +16699006833,,4034983298# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free) Meeting ID: 403 498 3298 International numbers available: https://zoom.us/u/bAaJoyznp

dave.enyeart (Wed, 23 May 2018 03:08:08 GMT):
We have a maintainer's meeting tomorrow (Wednesday)... several of us had conflicts at 9 am ET, we will start 30 minutes later at 9:30am ET. Topic: Hyperledger Fabric Maintainer's Meeting Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community Or iPhone one-tap : US: +16465588656,,4034983298# or +16699006833,,4034983298# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free) Meeting ID: 403 498 3298 International numbers available: https://zoom.us/u/bAaJoyznp

JonathanLevi (Wed, 23 May 2018 13:32:17 GMT):
Can we please spend the first minute on finding out how come only @yacovm found this *hilarious* joke

cbf (Wed, 23 May 2018 13:32:22 GMT):
https://zoom.us/my/hyperledger.community

JonathanLevi (Wed, 23 May 2018 13:32:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=JcqG6Yc8LsKxE3cu3)

JonathanLevi (Wed, 23 May 2018 13:32:25 GMT):
funny ?

cbf (Wed, 23 May 2018 13:32:29 GMT):
@here please join thanks

JonathanLevi (Wed, 23 May 2018 14:00:51 GMT):
https://etherealsummit.com

mastersingh24 (Wed, 23 May 2018 15:37:27 GMT):
He's Israeli as well? Although then Artem should have laughed ;) (https://chat.hyperledger.org/channel/fabric-maintainers?msg=XHwAma8xnFZjnFJjH) @JonathanLevi

yacovm (Wed, 23 May 2018 15:38:08 GMT):
i have a very low bar for jokes

mastersingh24 (Wed, 23 May 2018 15:39:03 GMT):
I would have laughed but I ignore messages from @JonathanLevi

JonathanLevi (Wed, 23 May 2018 15:40:34 GMT):
Please ignore this.

mastersingh24 (Wed, 23 May 2018 15:40:41 GMT):
I think it's a "best practice"

mastersingh24 (Wed, 23 May 2018 15:40:46 GMT):
haha

JonathanLevi (Wed, 23 May 2018 15:41:10 GMT):
Read. Ignore. Repeat.

JonathanLevi (Wed, 23 May 2018 15:41:39 GMT):
Best consensus mechanism. Lock free.

mastersingh24 (Wed, 23 May 2018 15:41:55 GMT):
Best consensus mechanism: Gari is right

rjones (Wed, 23 May 2018 15:42:14 GMT):
That is a suspect algorithm, at best

mastersingh24 (Wed, 23 May 2018 15:42:32 GMT):
The proof is a bit sketchy ... I'll give you that

tkuhrt (Wed, 23 May 2018 17:29:39 GMT):
Hey, All. I notice that you moved the maintainers meeting this morning and ran 1/2 an hour or more into the Hyperledger Quilt meeting time. Please be cognizant of the fact that there is a meeting scheduled after your maintainers meeting. This seems to be the second time that the maintainers meeting has caused problems for the Quilt meeting.

dave.enyeart (Wed, 23 May 2018 19:04:09 GMT):
@tkuhrt The maintainer meeting went to 2:30pm (UTC) today. According to the Hyperledger calendar, the Quilt meeting was to start at 3:00pm (UTC). Just want to understand further, as we are considering whether we need to move the official timeslot permanently.

rjones (Wed, 23 May 2018 20:16:56 GMT):
@here: moving forward, for the next little while, any change which is in this state: https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric+is:mergeable+label:f3-integrationtest%253C1 when you +2 a change, please also +1 the F3-IntegrationTest label. There will be a job to put a placeholder +1 in place for now as development moves forward. Please direct questions to @rameshthoomu or @tongli

tkuhrt (Wed, 23 May 2018 20:17:49 GMT):
@dave.enyeart : You are right. I was thinking about the winter time when the two meetings are back-to-back.

dave.enyeart (Wed, 23 May 2018 20:18:13 GMT):
phew

jyellick (Wed, 23 May 2018 20:21:40 GMT):
I meant to bring this up on the maintainer's call this morning, but can we _please_ stop doing CI for fabric in another project. The fact that a particular version of CI is not tied to a particular commit is problematic enough, but when there are mystery failures like the above it is very frustrating, as it's difficult to even understand how the failure is occurring.

jrosmith (Wed, 23 May 2018 20:27:15 GMT):
Has joined the channel.

cbf (Wed, 23 May 2018 20:33:12 GMT):
@jyellick yes, that is being considered and worked on for post 1.2. @tongli has been working on Jenkins pipeline jobs that we can run from the repo so we have tighter alignment and control (and so that we can actually understand WTH is going on).

cbf (Wed, 23 May 2018 22:28:33 GMT):
@here so, it was only recently that I learned that this channel is moderated - read-only for all but the fabric-maintainers. This seems to me to be unwise choice. It cuts off a channel for discussion. I certainly believe that there are more suitable channels for general questions, or pleas to review a CR etc and we can gently remind people if they repeatedly use this channel for anything aside from discussions with maintainers and about the project... if threads get too long, they can be taken elsewhere

cbf (Wed, 23 May 2018 22:29:15 GMT):
I'd like others to weigh in, please

cbf (Wed, 23 May 2018 22:29:55 GMT):
I think that there are voices in the community that have valuable insight... just because they aren't maintainers should not preclude their voices in this channel

yacovm (Wed, 23 May 2018 22:29:59 GMT):
i just hope we won't get swarmed by the people that copy-paste the same error message to 20 channels

yacovm (Wed, 23 May 2018 22:30:24 GMT):
this channel is usually used for important announcements

yacovm (Wed, 23 May 2018 22:30:24 GMT):
this channel is usually used for important announcements, therefore I suggest that we have a strict policy that if someone posts something irrelevant like an error message, a screenshot, peer logs, etc. - we would just automatically delete it

cbf (Wed, 23 May 2018 22:30:30 GMT):
I agree, that would be abusive and we can ask @rjones and @tkuhrt to quietly coach people who do

rjones (Wed, 23 May 2018 22:31:17 GMT):
as channel owners, you also have the power to mute or remove abusive users as required

cbf (Wed, 23 May 2018 22:31:28 GMT):
good point

cbf (Wed, 23 May 2018 22:31:35 GMT):
can we mute @mastersingh24 ?

rjones (Wed, 23 May 2018 22:32:05 GMT):
yes, the UI would allow me to do that. :)

rjones (Wed, 23 May 2018 22:32:20 GMT):
your point about coaching users is correct, though.

rjones (Wed, 23 May 2018 22:33:13 GMT):

gari.png

cbf (Wed, 23 May 2018 22:33:15 GMT):
:laughing:

cbf (Wed, 23 May 2018 22:34:02 GMT):
sadly, I don't have that power --- j/k

cbf (Wed, 23 May 2018 22:34:49 GMT):
besides, every once in a while he has something useful to say

rjones (Wed, 23 May 2018 22:35:36 GMT):
I won't ask what my SNR is, since I have a good idea it is approximately zero

rjones (Wed, 23 May 2018 22:37:03 GMT):
regardless: I support marking this channel read/write, and I think you have the power to make that change should you all decide to do so. I suspect you have a consensus algorithm that is better than "what @mastersingh24 says is right" but... whatever

kostas (Wed, 23 May 2018 22:55:49 GMT):
Good with R/W.

rjones (Wed, 23 May 2018 23:41:42 GMT):
please use #fabric-pr-review for pull requests' (PR) reviews

rjones (Wed, 23 May 2018 23:42:11 GMT):

JonathanLevi (Thu, 24 May 2018 11:44:26 GMT):
I agree. Yes, I clearly remember the one useful thing @mastersingh24 had to say back in February 2018 and another semi-useful back in April. [ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=TPGX5dp5meok2fhiT)

JonathanLevi (Thu, 24 May 2018 11:46:28 GMT):
I'd keep him unmuted, just for the off-chance that we'll hear/read something from him this June. I don't have any high expectations from him this May anymore, tbh, we have only 7 days to go anyway.

JonathanLevi (Thu, 24 May 2018 11:47:48 GMT):
Unmuting is better, just for the off-chance that we'll hear/read something from him this June. I don't have any high expectations from him this May anymore, tbh, we have only 7 days to go anyway.

kostas (Thu, 24 May 2018 13:00:31 GMT):
Are we supposed to support 32-bit architectures?

cbf (Thu, 24 May 2018 14:54:09 GMT):
@kostas who is asking?

kostas (Thu, 24 May 2018 15:04:15 GMT):
@cbf: One of our users who's looking to get a peer running on a Pi: https://jira.hyperledger.org/browse/FAB-10356 (unsure why that matters though)

cbf (Thu, 24 May 2018 15:06:48 GMT):
well, seems to me like it would be a bit of work, and unclear how much demand there is

cbf (Thu, 24 May 2018 15:07:16 GMT):
someone keen on it could fork

cbf (Thu, 24 May 2018 15:07:29 GMT):
what do others think?

kostas (Thu, 24 May 2018 15:13:16 GMT):
Wanted to make sure there is no statement out there that says we support architectures X, Y, and Z. It looks like there's not.

jyellick (Thu, 24 May 2018 15:17:27 GMT):
Looks like AMCL can either be built for 32 or 64 bit architectures: https://github.com/milagro-crypto/amcl/tree/master/version3/go Does anyone know how other projects with an AMCL dependency handle this?

mastersingh24 (Wed, 30 May 2018 23:09:35 GMT):
The implied support statement is for platforms officially supported by Docker ..... which are all 64bit platforms. Ubuntu does provide Docker for 32bit ARM7 processors, but this is not officially supported by Docker

rogerwilcos (Wed, 30 May 2018 23:13:54 GMT):
Has joined the channel.

dave.enyeart (Thu, 31 May 2018 17:32:41 GMT):
@here

dave.enyeart (Thu, 31 May 2018 17:32:46 GMT):
*Identity Mixer: Proposal to defer to v1.3* As most of you know, for the June release we set an end-of-May date as the final decision point for what content goes into v1.2 and what content gets deferred. And as most of you know, Identity Mixer has been the remaining feature on the cusp. The team working on Identity Mixer has been working some heroics to get an initial end-to-end scenario working across Fabric, Fabric CA, and Java SDK. Some brilliant work there, and I commend the team on the huge effort to pull off and e2e very quickly. It is time to make a FINAL decision. *I propose to defer Identity Mixer to v1.3*, based on the following: - For complex integration scenarios like this (what’s more complex than cross-component zero knowledge proof?), an initial end-to-end success does not equate to a shippable well-tested function. It takes time (much more than the two weeks remaining before RC1), to review, merge, finalize, stabilize, function test (positive and negative), system test, fix, document, socialize, and get feedback on a complex cross-component crypto function such as Identity Mixer. - Given the fixed set of developers, testers, documenters, attempting to squeeze in all of the above work in two weeks would take away from other release functions, injecting risk into the entire v1.2 release, not just the Identity Mixer feature. - The new release train model was designed exactly for these types of decisions. Instead of scrambling in the last weeks of a release and risk making mistakes, we have another release just 3 months away, and we now have some great function in the queue to finalize, test, and ship in 3 months. There are some options on *how* we defer (rip out code, disabling some entry points, etc), but let’s first come to a final decision on whether to defer. *Maintainers - Please +1 to defer, or -1 if you’d like to propose an alternate plan.*

dave.enyeart (Thu, 31 May 2018 17:32:46 GMT):
*Identity Mixer: Proposal to defer to v1.3* As most of you know, for the June release we set an end-of-May date as the final decision point for what content goes into v1.2 and what content gets deferred. And as most of you know, Identity Mixer has been the remaining feature on the cusp. The team working on Identity Mixer has been working some heroics to get an initial end-to-end scenario working across Fabric, Fabric CA, and Java SDK. Some brilliant work there, and I commend the team on the huge effort to pull off an e2e very quickly. It is time to make a FINAL decision. *I propose to defer Identity Mixer to v1.3*, based on the following: - For complex integration scenarios like this (what’s more complex than cross-component zero knowledge proof?), an initial end-to-end success does not equate to a shippable well-tested function. It takes time (much more than the two weeks remaining before RC1), to review, merge, finalize, stabilize, function test (positive and negative), system test, fix, document, socialize, and get feedback on a complex cross-component crypto function such as Identity Mixer. - Given the fixed set of developers, testers, documenters, attempting to squeeze in all of the above work in two weeks would take away from other release functions, injecting risk into the entire v1.2 release, not just the Identity Mixer feature. - The new release train model was designed exactly for these types of decisions. Instead of scrambling in the last weeks of a release and risk making mistakes, we have another release just 3 months away, and we now have some great function in the queue to finalize, test, and ship in 3 months. There are some options on *how* we defer (rip out code, disabling some entry points, etc), but let’s first come to a final decision on whether to defer. *Maintainers - Please +1 to defer, or -1 if you’d like to propose an alternate plan.*

dave.enyeart (Thu, 31 May 2018 17:32:46 GMT):
*Identity Mixer: Proposal to defer to v1.3* As most of you know, for the June release we set an end-of-May date as the final decision point for what content goes into v1.2 and what content gets deferred. And as most of you know, Identity Mixer has been the remaining feature on the cusp. The team working on Identity Mixer has been working some heroics to get an initial end-to-end scenario working across Fabric, Fabric CA, and Java SDK. Some brilliant work there, and I commend the team on the huge effort to pull off an e2e very quickly. It is time to make a FINAL decision. *I propose to defer Identity Mixer to v1.3*, based on the following: - For complex integration scenarios like this (what’s more complex than cross-component zero knowledge proof?), an initial end-to-end success does not equate to a shippable well-tested function. It takes time (much more than the two weeks remaining before RC1), to review, merge, finalize, stabilize, function test (positive and negative), system test, fix, document, socialize, and get feedback on a complex cross-component crypto function such as Identity Mixer. - Given the fixed set of developers, testers, documenters, attempting to squeeze in all of the above work in two weeks would take away from other release functions, injecting risk into the entire v1.2 release, not just the Identity Mixer feature. - The new release train model was designed exactly for these types of decisions. Instead of scrambling in the last weeks of a release and risk making mistakes, we have another release just 3 months away, and we now have some great function in the queue to finalize, test, and ship in 3 months. We can even put out an early v1.3 alpha to socialize the new feature. There are some options on *how* we defer (rip out code, disabling some entry points, etc), but let’s first come to a final decision on whether to defer. *Maintainers - Please +1 to defer, or -1 if you’d like to propose an alternate plan.*

kostas (Thu, 31 May 2018 17:33:40 GMT):
Vote to defer.

kostas (Thu, 31 May 2018 17:33:40 GMT):
Vote to defer, so +1.

mastersingh24 (Thu, 31 May 2018 17:37:26 GMT):
+1

yacovm (Thu, 31 May 2018 17:55:13 GMT):
> injecting risk into the entire v1.2 release Is it really that risky though, to try and push hard in the next week and see if the gap can be covered? It's not that you need to do rigorous system tests, it's crypto - there are no moving parts... I'm asking and not voting because I don't feel comfortable on voting -1 when it's not me that is putting the extra work in the end.

dave.enyeart (Thu, 31 May 2018 17:56:33 GMT):
two weeks ago i would have said the same thing, but in my opinion the velocity is not enough to close the gap in two weeks

dave.enyeart (Thu, 31 May 2018 17:56:33 GMT):
two weeks ago i would have said the same thing, but in my opinion the velocity is not enough to close the gap in two more weeks

dave.enyeart (Thu, 31 May 2018 17:56:33 GMT):
two weeks ago i would have said the same thing, but in my opinion the velocity is not enough to close the gap in two more weeks. the last 1% typically takes 20% of the time :)

mastersingh24 (Thu, 31 May 2018 18:03:33 GMT):
@yacovm - I can only speak for myself, but while I of course appreciate the extra effort, there was no reason for it. We have 3 month release windows ... if you come close but miss one window, you make the next. On the risk side, there has been a lot of churn during trying to get the tests working. I can't quantify the risk to the release in terms of "work", but I can quantify the risk of shipping code that has not been properly vetted and a feature which has been used / tested by no one outside of the development team. As someone who actually has to support people running the code, putting out code before it's ready causes a lot of issues.

yacovm (Thu, 31 May 2018 18:04:18 GMT):
Agree on the 3 month cycle logic...

mastersingh24 (Thu, 31 May 2018 18:04:20 GMT):
I'm not sure about the current APIs / interfaces and I don't want to be stuck supporting them and not being able to change them

yacovm (Thu, 31 May 2018 18:04:29 GMT):
understood

mastersingh24 (Thu, 31 May 2018 18:04:38 GMT):
We've done this too many time before ;) :(

mastersingh24 (Thu, 31 May 2018 18:06:14 GMT):
Now I will also say that once 1.2 is out the door, we should be ready to build a v1.3 preview/alpha/whatever which is basically 1.2 plus IdeMixer and get some feedback for sure ;)

cbf (Thu, 31 May 2018 18:12:55 GMT):
defer +1

cbf (Thu, 31 May 2018 18:13:53 GMT):
and seriously, when we say code freeze 6 weeks before... we need to stick to that

cbf (Thu, 31 May 2018 18:14:21 GMT):
as @mastersingh24 said, if you miss the bus, another is right behind it

C0rWin (Thu, 31 May 2018 18:22:40 GMT):
+1 to defer

binhn (Thu, 31 May 2018 18:25:38 GMT):
+1 on defer -- I looked at the doc, but it is not enough to get me going. It also doesn't document the gaps clearly, which I have given feedback to the authors; another 3 mos to work on would certainly make it better

muralisr (Thu, 31 May 2018 18:32:25 GMT):
+1 to defer

mastersingh24 (Thu, 31 May 2018 18:38:29 GMT):
+1 to defer from @rickr as well

smithbk (Thu, 31 May 2018 19:04:09 GMT):
+1 to defer

dave.enyeart (Thu, 31 May 2018 19:08:03 GMT):
Ok, that's a majority already, deferred!

dave.enyeart (Thu, 31 May 2018 19:11:05 GMT):
@cbf to be fair we did say SDK dev could continue through May, and many of the fabric and fabric-ca side issues were only found when doing end-to-end testing through SDK, but yeah, we should have stopped sooner, just kept thinking we were one CR away...

JonathanLevi (Thu, 31 May 2018 19:48:30 GMT):
Which brings up rule #11 of the Fight-Club: we don't trust reports from people who love what they do so much ;-) Every time I merged another CR one 3 new CRs got updated ! ;-)

JonathanLevi (Thu, 31 May 2018 19:49:42 GMT):
On a more serious note, I am happy with the results of the vote, and I think it was OK to still.give it a try, despite my concerns here a week+ ago.

JonathanLevi (Thu, 31 May 2018 19:49:42 GMT):
On a more serious note, I am happy with the results of the vote, and I think it was "OK" to still give it a try, despite my concerns here a week+ ago. Could we have done in a separate branch? Maybe. Would we have kept the same cadence? hard to tell. But clearly, the issue was/is just that towards the last days the gaps became much clearer and the merges indeed became increasingly risky (as it became clear that this is not going to be the last CR that I am merging "post deadline")... But I am glad you all agreed here, without my need to pull my my weight again also with a vote

JonathanLevi (Thu, 31 May 2018 19:49:42 GMT):
On a more serious note, I am happy with the results of the vote, and I think it was "OK-ish" to still give it a try at first, despite my concerns here a week+ ago. Could we have done in a separate branch? Maybe. Would we have kept the same cadence? Hard to tell. But clearly, the issue was/is just that towards the last days the gaps became much clearer and the merges indeed became increasingly risky (as it became clear that this is not going to be the last CR that I am merging "post deadline")... But I am glad you all agreed here, without the need from me to pull my my weight again, also with a vote.

JonathanLevi (Thu, 31 May 2018 19:50:19 GMT):
The main "mental" challenge with the "release train model" at the beginning, is letting the train really leave station on time.

JonathanLevi (Thu, 31 May 2018 19:50:19 GMT):
The main "mental" challenge with the "release train model" at the beginning, is letting the train to really leave the station on time.

JonathanLevi (Thu, 31 May 2018 19:50:19 GMT):
The main "mental" challenge with the "release train model" at the beginning, is with allowing the train to really leave the station on time.

JonathanLevi (Thu, 31 May 2018 19:51:07 GMT):
I think we have enough dev maturity and openness all around, and it will get better and smoother the more often (and frequently) we do it.

smithbk (Thu, 31 May 2018 21:03:28 GMT):
Totally agree. Even though I was involved in trying to help get this in, it was too much change too late in the cycle. It's an easy one to have consensus on.

smithbk (Thu, 31 May 2018 21:03:28 GMT):
Totally agree. Even though I was involved in trying to help get this in, it was too much change too late in the cycle.

mastersingh24 (Thu, 31 May 2018 21:30:01 GMT):
good news ... we are way ahead for 1.3 ;)

mastersingh24 (Sat, 02 Jun 2018 13:15:50 GMT):
When will we move to a CODE FREEZE and cut the v1.2 branch and move into critical bug fix only mode?

cbf (Sat, 02 Jun 2018 14:50:59 GMT):
sigh

cbf (Sat, 02 Jun 2018 14:51:05 GMT):
exactly

dave.enyeart (Sun, 03 Jun 2018 14:21:13 GMT):
@mastersingh24 @cbf Given that function test is still underway (wrapping up this week), defects are still being found, and service discovery SDK CRs are coming in this week, I was thinking we would allow all defects and important polish items for the next two weeks. Then in mid-June cut a RC1 and release to community, and create a v1.2 branch. Then the last two weeks of June only critical fixes could get in for the final v1.2 release. System test will proceed all throughout June. Of course, as we progress through each week of June we will get more and more critical of which CRs to merge, by weighing benefit and risk of each one. I prefer to allow maintainers (at least two per CR) to make these judgement calls.

cbf (Mon, 04 Jun 2018 11:15:59 GMT):
We should have images from stable builds tagged nightly, shortly (presently, they are tagged from each merge, which is too much churn... asking @rameshthoomu to just tag nightly) If anyone needs images to test as they would with an RC1, they can pull from Nexus. I'll post something with directions once the documentation is ready.

dave.enyeart (Thu, 07 Jun 2018 14:24:08 GMT):
Note that I am out of office for the next week. I posted an update in fabric-release and fabric-scrum. I'd ask the maintainers to keep a close eye on the release while I am out. Thanks!

abraham (Fri, 08 Jun 2018 05:40:05 GMT):
Has joined the channel.

richzhao (Fri, 08 Jun 2018 14:41:10 GMT):
Has joined the channel.

dave.enyeart (Thu, 14 Jun 2018 18:39:29 GMT):
We need to make a final decision on how to handle Fabric CA now that Idemix is deferred from release v1.2. Please see last few comments in https://gerrit.hyperledger.org/r/#/c/22687/ and add your thoughts please.

dave.enyeart (Fri, 15 Jun 2018 14:26:15 GMT):
Any other comments on https://gerrit.hyperledger.org/r/#/c/22687/ ? If no other comments I'll plan on merging later today, as this is considered the lowest risk approach of disabling Idemix by CA and system test teams.

dave.enyeart (Fri, 15 Jun 2018 14:26:15 GMT):
Discussed https://gerrit.hyperledger.org/r/#/c/22687/ with Gari. We decided to go ahead and merge https://gerrit.hyperledger.org/r/#/c/22687/ since that will have the least impact on CI and system test.

dave.enyeart (Fri, 15 Jun 2018 14:28:53 GMT):
Concerning defects - there are 35 v1.2 defects open and 12 defects that need triage (no Fix Version). See the lower right widgets: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701 . 21 of the defects are In Review and need maintainer review (about half are ledger ones that piled up while I was away, which I am focusing on today). For the ones not in review, could use maintainer help triaging, commenting, and where appropriate, deferring by setting Fix Version to v1.3 or FUTURE. Any remaining ones we’ll need to discuss next week before cutting v1.2 RC1.

dave.enyeart (Sat, 16 Jun 2018 17:21:29 GMT):
Three 'high' sev defect fixes are ready for final review and merge. I've reviewed and tested each of them: https://gerrit.hyperledger.org/r/#/c/23059/ https://gerrit.hyperledger.org/r/#/c/22909/

dave.enyeart (Sat, 16 Jun 2018 17:21:38 GMT):
https://gerrit.hyperledger.org/r/#/c/22887/

DuncanMuhoro (Sun, 17 Jun 2018 11:01:07 GMT):
Has joined the channel.

cbf (Mon, 18 Jun 2018 13:57:57 GMT):
https://gerrit.hyperledger.org/r/c/22981/ https://gerrit.hyperledger.org/r/c/22979/ https://gerrit.hyperledger.org/r/c/22995/ <-- these have been kid tested, are not core code, and will be needed for the release process ... would be nice to get them merged please

cbf (Mon, 18 Jun 2018 13:58:20 GMT):
@rameshthoomu can confirm, I believe

JonathanLevi (Mon, 18 Jun 2018 18:24:33 GMT):
Hi @cbf, we have merged two out of the 3. The third one requires a follow up patch, it seems. (I don't mind pushing a patch myself here)

cbf (Mon, 18 Jun 2018 18:29:09 GMT):
ok, will look

dave.enyeart (Mon, 18 Jun 2018 21:50:48 GMT):
ok, need one more +2 on https://gerrit.hyperledger.org/r/#/c/22979/

JonathanLevi (Mon, 18 Jun 2018 21:53:55 GMT):
Merged. Thank you Dave.

dave.enyeart (Mon, 18 Jun 2018 22:22:57 GMT):
ok, now we are ready to cut baseimage 0.4.9 which includes final updates for v1.2: https://gerrit.hyperledger.org/r/#/c/23259/

JonathanLevi (Tue, 19 Jun 2018 01:39:58 GMT):
(BTW: I have +2'ed a few hours ago. Whoever needs it, please hit *Submit* when ready.)

JonathanLevi (Tue, 19 Jun 2018 01:40:14 GMT):
(BTW: I +2'ed a few hours ago. Whoever needs it, please hit *Submit* when ready.)

dave.enyeart (Tue, 19 Jun 2018 03:49:30 GMT):
Thanks... and now the prepare for 0.4.10 baseimage: https://gerrit.hyperledger.org/r/#/c/23297/

dave.enyeart (Tue, 19 Jun 2018 13:46:53 GMT):
baseimage 0.4.9 and third party docker images have been pushed to dockerhub. that being said, we don't think we will increment fabric from 0.4.8 to 0.4.9, in order to mitigate any risk (no updates important enough to warrant the late move).

dave.enyeart (Tue, 19 Jun 2018 13:46:53 GMT):
baseimage 0.4.9 and third party docker images have been pushed to dockerhub. that being said, we don't think we will increment fabric from 0.4.8 to 0.4.9 before v1.2 is cut, in order to mitigate any risk (no updates important enough to warrant the late move).

dave.enyeart (Tue, 19 Jun 2018 13:47:01 GMT):
Here’s the agenda items I have in mind for tomorrow’s maintainer meeting. Anything else to add? v1.2 - Defect assessment - We are down to 6 Defects in triage and 16 Defects in v1.2 backlog: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701. Most of them appear to be deferrable. Please label any that you think are must fix with `must-fix` (must-fix widget has been added to dashboard) - System, upgrade, compatibility test progress update - Documentation update - Build/release process update (multi-architecture support) - Final Epic updates - RC1 Decision v1.3 - Discuss release themes and epic prioritization. For any Epics to be considered, mark them as Fix Version=v1.3. We have a good set already identified and already in-progress in many cases.

SjirNijssen (Tue, 19 Jun 2018 14:58:38 GMT):
Has joined the channel.

dave.enyeart (Wed, 20 Jun 2018 10:26:18 GMT):
Reminder - Fabric maintainer meeting at 9am US Eastern today. See the invite on the Hyperledger calendar: https://calendar.google.com/calendar/embed?mode=AGENDA&src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=UTC

dave.enyeart (Wed, 20 Jun 2018 10:26:28 GMT):
https://zoom.us/my/hyperledger.community

dave.enyeart (Wed, 20 Jun 2018 10:26:28 GMT):
meeting link: https://zoom.us/my/hyperledger.community

andrew-coleman (Wed, 20 Jun 2018 10:42:36 GMT):
Has joined the channel.

mbwhite (Wed, 20 Jun 2018 13:09:44 GMT):
Has joined the channel.

dave.enyeart (Wed, 20 Jun 2018 13:17:14 GMT):
https://jira.hyperledger.org/issues/?jql=issuetype%20%3D%20Epic%20AND%20fixVersion%20%3D%20v1.3%20ORDER%20BY%20key%20ASC

kostas (Thu, 21 Jun 2018 15:04:02 GMT):
Anyone following up on how to loosen up the restriction on the title length for CRs in Gerrit?

kostas (Thu, 21 Jun 2018 15:04:02 GMT):
Anyone following up on how to loosen the restriction on the title length for CRs in Gerrit?

kostas (Thu, 21 Jun 2018 15:04:02 GMT):
Anyone following up on how to allow longer titles in CRs in Gerrit?

yacovm (Thu, 21 Jun 2018 15:11:28 GMT):
gzip?

yacovm (Thu, 21 Jun 2018 15:11:28 GMT):
gzip, or we can make the title pass through a word stemmer ( https://en.wikipedia.org/wiki/Stemming )

jyellick (Thu, 21 Jun 2018 15:11:31 GMT):
My understanding from the maintainer's meeting was that it is not a gerrit limitation, it is a git limitation. For the git short-logs to read correctly, we have a character limit. I think what was being advocated was to drop the requirement of the 10 characters of FAB-XXXXX from the first line, and say it must be elsewhere in the message.

jyellick (Thu, 21 Jun 2018 15:11:31 GMT):
My understanding from the maintainer's meeting was that it is not a gerrit limitation, it is a git limitation. For the git short-logs to read correctly, we have a character limit. I think what was being advocated was to drop the requirement of the 10 characters of `FAB-XXXXX ` from the first line, and say it must be elsewhere in the message.

jyellick (Thu, 21 Jun 2018 15:14:36 GMT):
https://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting

kostas (Thu, 21 Jun 2018 15:24:24 GMT):
Understood. Are we onboard for dropping the `FAB-xxxxx`prefix in all CRs starting from the 1.3 cycle?

cbf (Thu, 21 Jun 2018 15:25:43 GMT):
it needs to be in the body... think we need a check that can scan for that in the build

cbf (Thu, 21 Jun 2018 15:26:43 GMT):
though I will say that this means that the generated changelog will need to have some gyrations to incorporate the JIRA since the changelog is based on shortlog

cbf (Thu, 21 Jun 2018 20:58:51 GMT):
MERGE FREEZE --- While we cut the rc1 release, please refrain from merging any CRs thanks

nvxtien (Fri, 22 Jun 2018 11:38:17 GMT):
Has joined the channel.

rjones (Fri, 22 Jun 2018 13:46:42 GMT):
@jyellick I know this is trivial but the bracket decoration isn't needed, that would buy a very small amount of space.

jyellick (Fri, 22 Jun 2018 13:48:10 GMT):
@rjones Indeed, I've stopped using the bracket notation on mine, but even without, 3 letters + 1 dash + 5 digits + 1 space = 10 characters. Or, 20% of our 50 character limit.

rjones (Fri, 22 Jun 2018 13:49:33 GMT):
Yes, I was just looking at a bunch of changes in flight and saw lots of [] decorations. I suppose you could add that to a style check. But your overall point is not diminished.

yacovm (Fri, 22 Jun 2018 13:50:31 GMT):
@jyellick - you're the main contributor to the fact that the JIRA IDs now contain so many digits...

dave.enyeart (Fri, 22 Jun 2018 14:01:36 GMT):
To paste what was announced in #fabric-scrum ...

dave.enyeart (Fri, 22 Jun 2018 14:01:40 GMT):
fabric v1.2.0-rc1 has been cut, pushed to dockerhub, and tagged. fabric release branch release-1.2 has been created. release-1.2 branch will be used for any critical defects found in rc1 and targeted for the upcoming v1.2.0 release. master branch can be used for new v1.3 development. Merge freeze lifted, go and use master as usual. fabric-ca v1.2.0-rc1 is in final verification, will be pushed to dockerhub shortly.

dave.enyeart (Fri, 22 Jun 2018 14:01:53 GMT):
fabric-ca is still in MERGE FREEZE

rjones (Fri, 22 Jun 2018 15:27:48 GMT):
Has left the channel.

cbf (Fri, 22 Jun 2018 16:43:59 GMT):
Fabric CA MERGE FREEZE END

dave.enyeart (Tue, 26 Jun 2018 11:33:36 GMT):
See #fabric-pr-review for latest must-fix defect

cbf (Mon, 02 Jul 2018 20:14:44 GMT):
All seems to be looking good for cutting 1.2.0 tomorrow

cbf (Mon, 02 Jul 2018 20:15:32 GMT):
will have a merge freeze on the release-1.2 branches only while the release is being produced

jyellick (Mon, 02 Jul 2018 23:24:26 GMT):
I was getting some questions about the assorted capabilities documented in the `configtx.yaml` which are really inappropriate for v1.2 -- a low risk merge https://gerrit.hyperledger.org/r/c/23961/ but would not be the end of the world if it did not get in

kostas (Tue, 03 Jul 2018 01:38:44 GMT):
@jyellick: I'll +2 because it does seem low-risk. Can you -2? That way we prevent accidental merging and @cbf or @dave.enyeart can remove your -2, then +2 and merge if they think it's good to go.

kostas (Tue, 03 Jul 2018 01:38:44 GMT):
@jyellick: I can +2 since it does seem low-risk, if you -2. That way we prevent accidental merging and @cbf or @dave.enyeart can remove your -2, then +2 and merge if they think it's good to go.

cbf (Tue, 03 Jul 2018 10:06:32 GMT):
I +2ed need one more... @mastersingh24 ?

JonathanLevi (Tue, 03 Jul 2018 12:34:37 GMT):
Merged.

JonathanLevi (Tue, 03 Jul 2018 12:35:48 GMT):
Totally agree. Merged (with an inline explanation which captures the "why").

BabuPallam (Wed, 04 Jul 2018 22:21:59 GMT):
Has joined the channel.

sigma67 (Sat, 07 Jul 2018 13:40:34 GMT):
Has joined the channel.

nvlasov (Wed, 11 Jul 2018 02:51:54 GMT):
Has joined the channel.

NoLimitHoldem (Wed, 11 Jul 2018 06:17:17 GMT):
Has joined the channel.

jyellick (Wed, 11 Jul 2018 13:02:39 GMT):
What's the zoom link for the meeting?

manish-sethi (Wed, 11 Jul 2018 13:03:00 GMT):
https://zoom.us/my/hyperledger.community

jyellick (Wed, 11 Jul 2018 13:06:02 GMT):
@cbf @dave.enyeart @mastersingh24 Are you joining the meeting?

dave.enyeart (Wed, 11 Jul 2018 13:14:06 GMT):
Input for Jira consultant: https://docs.google.com/document/d/1svxqQsdUeJXNi8XqZyyJj3duk5YmJl8XtkrWGe9bQ28/edit?usp=sharing v1.2 Retropective: https://docs.google.com/document/d/1SMTcGTMmTpGIEFA9o8LhbtYhhSBS79TPIBCv-J3pCIc/edit?usp=sharing v1.3 Epic prioritization: I’ve sent a survey monkey link to maintainers via email. v1.3 Epic query: https://jira.hyperledger.org/issues/?jql=issuetype%20%3D%20Epic%20AND%20fixVersion%20%3D%20v1.3.0

wenjian (Wed, 11 Jul 2018 13:14:51 GMT):
Has joined the channel.

cbf (Wed, 11 Jul 2018 13:16:34 GMT):
I cannot join, unfortunately

rjones (Thu, 12 Jul 2018 04:18:51 GMT):
Has joined the channel.

dave.enyeart (Fri, 13 Jul 2018 15:16:36 GMT):
Concerning v1.3 Epic Prioritization... Survey Monkey seems very slow... but it does come back if you wait long enough, so if you haven't voted yet try again.

dave.enyeart (Fri, 13 Jul 2018 15:16:53 GMT):
Survey results as of 8 responses: https://www.surveymonkey.com/results/SM-9H6W3JZWL/

dave.enyeart (Fri, 13 Jul 2018 15:17:27 GMT):
My commentary: - There is resource on the top 6 items (and to a lesser degree the top 11 items), so we appear to be working on the right things already. - I think the survey is a good addition to our release processes... provides some more transparency, even though it pretty much reflects what we've already been talking about. - Not all top items will get contained in v1.3, we'll see where we land... as you develop items keep in mind a strategy for how to exclude from the release if it needs to get deferred (exclusion approach will be epic specific, e.g. using V1_3 capability). - Programming model improvements (Composer/SDK work) didn't get included in the survey since it was an Improvement rather than an Epic... I've fixed that, but I think it's safe to say that it is a priority and can be worked in parallel since it is different resources. - The token and zero knowledge work is not fully netted out into Epic(s), but investment has started as it is a larger item that will be staged over multiple releases. - Hygiene work can and should continue in parallel with Epic work. We have a Hygiene board https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=173&view=planning&selectedIssue=FAB-6559 with a backlog of Hygiene items, feel free to create and label items with 'hygiene' so that they show up in this board. @sykesm has been managing the prioritization of Hygiene items. The MSP singleton refactoring is currently the top item.

rjones (Fri, 13 Jul 2018 22:56:27 GMT):
I want to demod this channel. It is the last hold out. Any objections? https://chat.hyperledger.org/channel/demod?msg=X5wkw8BGRvfTofPgD @tkuhrt

mastersingh24 (Sat, 14 Jul 2018 14:15:46 GMT):
@rjones ... fine by me ... @cbf and I were discussing this the other day

bestbeforetoday (Mon, 16 Jul 2018 12:10:02 GMT):
Has joined the channel.

cbf (Mon, 16 Jul 2018 12:24:26 GMT):
ok by me @rjones

dave.enyeart (Mon, 16 Jul 2018 14:02:01 GMT):
Hi, we are starting a meeting to review proposed Jira changes: https://global.gotomeeting.com/join/377933877

mastersingh24 (Tue, 17 Jul 2018 12:08:15 GMT):
We really need to get this stack from @jyellick in: https://gerrit.hyperledger.org/r/#/q/owner:jyellick%2540us.ibm.com+status:open

mastersingh24 (Tue, 17 Jul 2018 12:08:30 GMT):
Can we get some love on these please?

mastersingh24 (Tue, 17 Jul 2018 16:24:09 GMT):
Fellow maintainers .... I implore you to reconsider the concept of moving to single +2 for Fabric CRs. There are many straight-forward CRs and we are simply not reviewing them quickly enough. I'm really not sure why so many are opposed to moving to a single +2 model

mastersingh24 (Tue, 17 Jul 2018 16:25:17 GMT):
I'd even settle in the near term for allow maintainers who submit changes to +2 their own as well

jyellick (Tue, 17 Jul 2018 16:31:05 GMT):
Although I have my concerns about code quality with a single +2 system, it does seem obvious that in the current system of 2+2, we are simply not getting through the backlog of CRs. For instance, I pushed a fairly long, but trivial series, doing some refactor to make lifecycle more pluggable to enable the v1.3 lifecycle epic work. I pushed it over a month ago at this point, and aside from Gari's +2s, it is languishing. Although I think we need to more comprehensively address things, I think Gari's solution of allowing a maintainer to self +2 if they believe the CR is straightforward would at least help clear the log jam.

dave.enyeart (Tue, 17 Jul 2018 18:46:45 GMT):
I agree that allowing a maintainer to +2 their own (straightforward) CRs is a decent compromise for now. We can also have the top SME do a deeper review and a 2nd person do a lighter quicker review (we sometimes do that already, although unspoken). I still have concerns about going completely to a single +2 policy in fabric project... the 2nd reviewer often leaves good comments, and our code would be in a worse place if we had lost all those 2nd reviews. We have seen that a single defect in critical areas can cause a state fork or panic ALL peers in a network, and finding these defects ahead of time is priceless, even if that impacts velocity. My opinion...

yacovm (Tue, 17 Jul 2018 18:50:56 GMT):
@dave.enyeart - my thoughts exactly.

yacovm (Tue, 17 Jul 2018 18:50:56 GMT):
> I agree that allowing a maintainer to +2 their own (straightforward) CRs is a decent compromise for now. We can also have the top SME do a deeper review and a 2nd person do a lighter quicker review (we sometimes do that already, although unspoken). I still have concerns about going completely to a single +2 policy in fabric project... the 2nd reviewer often leaves good comments, and our code would be in a worse place if we had lost all those 2nd reviews. We have seen that a single defect in critical areas can cause a state fork or panic ALL peers in a network, and finding these defects ahead of time is priceless, even if that impacts velocity. My opinion... @dave.enyeart - my thoughts exactly.

yacovm (Tue, 17 Jul 2018 18:51:48 GMT):
> I agree that allowing a maintainer to +2 their own (straightforward) CRs is a decent compromise for now. We can also have the top SME do a deeper review and a 2nd person do a lighter quicker review (we sometimes do that already, although unspoken). I still have concerns about going completely to a single +2 policy in fabric project... the 2nd reviewer often leaves good comments, and our code would be in a worse place if we had lost all those 2nd reviews. We have seen that a single defect in critical areas can cause a state fork or panic ALL peers in a network, and finding these defects ahead of time is priceless, even if that impacts velocity. My opinion... my thoughts exactly.

yacovm (Tue, 17 Jul 2018 19:03:51 GMT):
And to add to that: We... somehow got to v1.3, with a 2+2 policy, didn't we? What has changed that we need to change the policy? The obvious thing that has changed is that Jason and Matt altogether pushed lately 4 gerrit pages. Setting aside the kudos for all the hard work ;) - that work is mainly refactoring and addressing existing code - which means, at some point the refactoring is going to end, and then the rate of gerrit commits is expected to fall, isn't it? If that is the case- then it's only a temporary state, and should we really do such a drastic change to address a temporary state? I'm saying all this despite I will (personally) greatly enjoy an only 1 +2 policy. Herding 2 +2s for my features in v1.2 was a very.... proactive task on my behalf, and the code ended up being merged eventually.

yacovm (Tue, 17 Jul 2018 19:05:35 GMT):
Therefore I think the "add your own +2" is a perfect compromise though I have to say that it is a bit biased and non uniform.

mastersingh24 (Tue, 17 Jul 2018 19:10:29 GMT):
We either have good judgement or we don't ..... just because YOU CAN does not mean YOU HAVE TO ;)

mastersingh24 (Tue, 17 Jul 2018 19:11:11 GMT):
And I will say that proper tests and well structured code are a better solution that 2+2

mastersingh24 (Tue, 17 Jul 2018 19:11:11 GMT):
And I will say that proper tests and well structured code are a better solution than 2+2

yacovm (Tue, 17 Jul 2018 19:12:04 GMT):
too many times I run code coverage and I see that the tests that were added didn't cover all the added code, so it can be misleading ;)

mastersingh24 (Tue, 17 Jul 2018 19:12:04 GMT):
Don't merge stuff if you are unsure ;)

mastersingh24 (Tue, 17 Jul 2018 19:12:27 GMT):
good point @yacovm

mastersingh24 (Tue, 17 Jul 2018 19:13:02 GMT):
number of tests or amount of test code does not necessarily equate to proper test coverage

adarshsaraf123 (Wed, 18 Jul 2018 08:13:15 GMT):
Has joined the channel.

ChanderGovindarajan (Wed, 18 Jul 2018 08:13:22 GMT):
Has joined the channel.

dave.enyeart (Wed, 18 Jul 2018 08:34:47 GMT):
Maintainer meeting today 9am US Eastern / 1pm UTC: https://zoom.us/my/hyperledger.community

dave.enyeart (Wed, 18 Jul 2018 08:35:00 GMT):
Topics

dave.enyeart (Wed, 18 Jul 2018 08:35:55 GMT):
v1.3 Epic Prioritization/Planning - I've created a slide to capture the surveymonkey results

dave.enyeart (Wed, 18 Jul 2018 08:35:55 GMT):
v1.3 Epic Prioritization/Planning - I've created a slide to capture the surveymonkey results, and we've scheduled playbacks for Epics that are ready: https://wiki.hyperledger.org/projects/fabric/playbacks

dave.enyeart (Wed, 18 Jul 2018 08:37:33 GMT):
v1.2 retrospective: https://docs.google.com/document/d/1SMTcGTMmTpGIEFA9o8LhbtYhhSBS79TPIBCv-J3pCIc/edit?usp=sharing

dave.enyeart (Wed, 18 Jul 2018 08:38:11 GMT):

Clipboard - July 18, 2018 4:38 AM

dave.enyeart (Wed, 18 Jul 2018 13:03:05 GMT):
@here Maintainer meeting starting

samir.tata (Thu, 19 Jul 2018 03:53:54 GMT):
Has joined the channel.

jtonline (Thu, 19 Jul 2018 15:13:08 GMT):
Has joined the channel.

dimaxgl (Fri, 20 Jul 2018 12:50:45 GMT):
Has joined the channel.

IsaacWong (Fri, 20 Jul 2018 15:11:03 GMT):
Has joined the channel.

dave.enyeart (Mon, 23 Jul 2018 16:40:42 GMT):
latest epic prioritization chart after the maintainer meeting (only addition was a sample for cross-system deployment):

dave.enyeart (Mon, 23 Jul 2018 16:40:50 GMT):

Clipboard - July 23, 2018 12:40 PM

dave.enyeart (Mon, 23 Jul 2018 16:41:11 GMT):

Fabric_v13_Epic_Prioritization.pptx.zip

dave.enyeart (Mon, 23 Jul 2018 16:41:57 GMT):
v1.2 retrospective edits based on last maintainer meeting: https://docs.google.com/document/d/1SMTcGTMmTpGIEFA9o8LhbtYhhSBS79TPIBCv-J3pCIc/edit?usp=sharing

dave.enyeart (Mon, 23 Jul 2018 16:44:19 GMT):
The only other item of interest in last weeks maintainer meeting was that there was consensus to allow maintainers to +2 their own CRs if the maintainer has confidence that the CR is straightforward enough to bypass the second independent review. I will push an edit to the Fabric contribution docs mentioning this.

dave.enyeart (Mon, 23 Jul 2018 19:26:18 GMT):
@here Proposal to retire dormant maintainers, let's see if there is support from majority: https://gerrit.hyperledger.org/r/#/c/24675/

dave.enyeart (Mon, 23 Jul 2018 19:26:18 GMT):
@here Proposal to retire dormant maintainers, let's see if there is support from majority, indicate with a +1: https://gerrit.hyperledger.org/r/#/c/24675/

iamksseo (Tue, 24 Jul 2018 02:02:43 GMT):
Has joined the channel.

fabiomolinar (Tue, 24 Jul 2018 18:13:02 GMT):
Has joined the channel.

thakkarparth007 (Tue, 24 Jul 2018 20:05:48 GMT):
Has joined the channel.

cbf (Tue, 24 Jul 2018 20:25:26 GMT):
the proposal was approved with 9 out of 15 maintainers agreeing to the proposed change

rjones (Tue, 24 Jul 2018 20:32:13 GMT):
@cbf I will note @jimthematrix is also a fabric-sdk-node committer.

cbf (Tue, 24 Jul 2018 20:33:17 GMT):
@rjones thanks, yes

rjones (Tue, 24 Jul 2018 20:33:38 GMT):
among others. ```hyperledger-gerrit-fabric-sdk-java-committers hyperledger-gerrit-fabric-chaincode-node-committers hyperledger-gerrit-fabric-chaincode-java-committers hyperledger-gerrit-fabric-sdk-node-committers```

yacovm (Tue, 24 Jul 2018 20:47:22 GMT):
Wondering if it makes sense to have the maximum inactivity timeout be a function of number of change sets

yacovm (Tue, 24 Jul 2018 20:47:22 GMT):
Wondering if it makes sense to have the maximum inactivity timeout be a function of number of change sets :thinking_face:

cbf (Tue, 24 Jul 2018 20:49:42 GMT):
we need a more coherent means of tracking all this... maybe something like what docker does

rjones (Tue, 24 Jul 2018 21:00:50 GMT):
@jeremyphelps was working on an MD->JSON->LDAP bridge a while ago, don't know if it went anywhere

jeremyphelps (Tue, 24 Jul 2018 21:00:50 GMT):
Has joined the channel.

jeremyphelps (Wed, 25 Jul 2018 13:41:59 GMT):
@rjones I think that was Aric working on that, he demo'd something internally the other day.

MattHamilton (Wed, 25 Jul 2018 14:17:21 GMT):
Has joined the channel.

kostas (Wed, 25 Jul 2018 18:07:06 GMT):
Regarding the JIRA improvements that we've put in last week, a quick question. Would any subsequent improvements (in terms of new fields, less fields, etc.) require the help of a consultant, or we are in a place now where we can do those edits ourselves?

cbf (Wed, 25 Jul 2018 20:38:09 GMT):
we should be able to ask for specific tweaks directly

cbf (Wed, 25 Jul 2018 20:38:28 GMT):
but we do have the consultant for something like 4 hours a month follow-up

cbf (Wed, 25 Jul 2018 20:38:37 GMT):
@kostas ^^

kostas (Wed, 25 Jul 2018 20:39:45 GMT):
Got it, thanks. Directly as in -- reach out to Suze, or somewhere else?

kostas (Wed, 25 Jul 2018 20:39:45 GMT):
Got it, thanks. Directly as in -- reach out to Suze, or someone/somewhere else?

kostas (Wed, 25 Jul 2018 20:39:45 GMT):
@cbf: Got it, thanks. Directly as in -- reach out to Suze, or someone/somewhere else?

cbf (Wed, 25 Jul 2018 20:41:34 GMT):
@dhuseby ??

yacovm (Wed, 25 Jul 2018 20:43:58 GMT):
@cbf @dave.enyeart @mastersingh24 is it possible to add a binary to the docker tools container for v1.2 somehow?

yacovm (Wed, 25 Jul 2018 20:44:01 GMT):
context:

yacovm (Wed, 25 Jul 2018 20:44:20 GMT):
https://chat.hyperledger.org/channel/fabric-questions?msg=cJPDHhkvwrSEFbTCZ

yacovm (Wed, 25 Jul 2018 20:44:48 GMT):
Seems some users rely on the tools container and the `discover` binary isn't there

cbf (Wed, 25 Jul 2018 20:45:09 GMT):
ah, sure

cbf (Wed, 25 Jul 2018 20:45:24 GMT):
create a JIRA and assign to me

yacovm (Wed, 25 Jul 2018 20:45:28 GMT):
thanks :)

yacovm (Wed, 25 Jul 2018 20:49:25 GMT):
FAB-11316

bourbonkidQ (Wed, 25 Jul 2018 20:50:58 GMT):
Has joined the channel.

yacovm (Wed, 25 Jul 2018 20:55:29 GMT):
hmmm, i opened it accidentally as documentation change and seems like i can't change it.... @dave.enyeart can you or anyone else try?

cbf (Wed, 25 Jul 2018 20:57:26 GMT):
let me see

cbf (Wed, 25 Jul 2018 20:59:03 GMT):
I cannot - @dave.enyeart I thought you said we could change with an option under the More button

dave.enyeart (Wed, 25 Jul 2018 21:02:46 GMT):
@cbf @yacovm I changed it to a Task. It is under More-->Move. I think anybody can do it, but let me know if you guys don't have permission.

cbf (Wed, 25 Jul 2018 21:03:09 GMT):
Move is completely counterintuitive

cbf (Wed, 25 Jul 2018 21:03:14 GMT):
wow

dave.enyeart (Wed, 25 Jul 2018 21:03:18 GMT):
yep

cbf (Wed, 25 Jul 2018 21:03:20 GMT):
thx

yacovm (Wed, 25 Jul 2018 21:04:56 GMT):
thanks for both!

yacovm (Wed, 25 Jul 2018 21:04:56 GMT):
thanks for both! (the move and the info tip)

cbf (Wed, 25 Jul 2018 21:19:47 GMT):
@yacov https://gerrit.hyperledger.org/r/2478

yacovm (Wed, 25 Jul 2018 21:20:05 GMT):
that was fast

yacovm (Wed, 25 Jul 2018 21:20:05 GMT):
that was fast, thanks

yacovm (Wed, 25 Jul 2018 21:20:19 GMT):
but i can't see it

yacovm (Wed, 25 Jul 2018 21:22:03 GMT):
but can we add it somehow to v1.2 ?

yacovm (Wed, 25 Jul 2018 21:22:03 GMT):
but can we add it somehow to v1.2 published docker images?

yacovm (Wed, 25 Jul 2018 21:22:11 GMT):
should we cherry pick it to v1.2 too?

Ryan2 (Thu, 26 Jul 2018 00:09:04 GMT):
Has joined the channel.

cbf (Thu, 26 Jul 2018 11:47:16 GMT):
I can do that

dave.enyeart (Thu, 26 Jul 2018 17:40:44 GMT):
I see a CR to remove event hub was merged. At a maintainers meeting earlier this month, we said we would do some homework to determine impact to each of the SDKs, prior to making a decision of whether event hub could be removed in v1.3 timeframe with minimal impact to existing applications. Let's discuss in FAB-11122 , I've asked in there for each of the SDKs, what is the last release that used the peer's event hub? Hyperledger follows semantic versioning which means an API should only be removed at a major release... if we want to be more aggressive than the policy I think we should have all the facts first and achieve some consensus among maintainers. If the SDKs haven't used event hub since 1.1, I think we could make a case for the early retirement, but should probably include a release note in 1.2.1 with the deprecation warning.

dave.enyeart (Thu, 26 Jul 2018 17:40:44 GMT):
I see a CR to remove event hub was merged. At a maintainers meeting earlier this month, we said we would do some homework to determine impact to each of the SDKs, prior to making a decision of whether event hub could be removed in v1.3 timeframe with minimal impact to existing applications. Let's discuss in FAB-11122 , I've asked in there for each of the SDKs, what is the last release that used the peer's event hub? Hyperledger follows semantic versioning which means an API should only be removed at a major release... if we want to be more aggressive than the policy I think we should have all the facts first and achieve some consensus among maintainers. If the SDKs haven't used event hub since 1.0, I think we could make a case for the early retirement, but should probably include a release note in 1.2.1 with the deprecation warning (would have been better to release note in 1.2.0, but that ship has sailed).

jyellick (Thu, 26 Jul 2018 17:49:16 GMT):
My understanding is that the eventhub APIs were marked 'deprecated' as of v1.1. Though I agree with the intent of semantic versioning, based on feedback from users, anyone who has tried using the eventhub in 'real' deployments have found it ultimately causes stability problems in the peer, resulting in long hangs, missed events, etc, not to mention the inability to do real access control. In fact, the channel event service stuff seems to be one of the primary motivators towards migration to v1.1. Despite the break in semantic versioning, my vote is that the removal is the right thing to do.

yacovm (Thu, 26 Jul 2018 17:49:25 GMT):
But I've seen change sets of SDKs that they removed the client side code

dave.enyeart (Thu, 26 Jul 2018 17:49:55 GMT):
yeah, i'm asking which version of the SDKs did they remove references to event hub

dave.enyeart (Thu, 26 Jul 2018 17:50:12 GMT):
we need to understand this regardless for the release notes

yacovm (Thu, 26 Jul 2018 17:50:13 GMT):
I believe it's latest....

jyellick (Thu, 26 Jul 2018 17:50:49 GMT):
v1.3, yes. The old eventhub stuff was left available as an API for v1.0 peers, but was marked deprecated, that the channel event mechanism is the preferred API for v1.1+ peers

jyellick (Thu, 26 Jul 2018 17:50:49 GMT):
v1.3, yes. The old eventhub stuff was left available as an API in the SDK so that it could continue to work with v1.0 peers, but was marked deprecated, that the channel event mechanism is the preferred API for v1.1+ peers

jyellick (Thu, 26 Jul 2018 17:52:09 GMT):
I do not believe either SDK transparently changed implementation from using the old eventhub to the new event service. I believe they both exposed the channel based event service as a new API.

dave.enyeart (Thu, 26 Jul 2018 18:33:58 GMT):
@jyellick looks like java sdk gave warning not to use event hub as of 1.1. looks like node sdk made both available in v1.1 and v1.2, no indication of deprecation as far as I can tell, and samples used old event hub up until today. So there will likely be v1.2 apps using old event hub when v1.3 goes out.

jyellick (Thu, 26 Jul 2018 18:35:47 GMT):
Good to know, and we should certainly document. I still stand by the assertion that removing it for v1.3 is the right call.

dave.enyeart (Thu, 26 Jul 2018 19:32:18 GMT):
Given the nature of the event hub problems, I would have to agree that forcing applications over to the new channel event service before they upgrade to v1.3 is the best (or least bad) option... I've tagged the jira as Release Note Required

zjubfd (Sat, 28 Jul 2018 10:14:22 GMT):
Has joined the channel.

yacovm (Sat, 28 Jul 2018 10:59:50 GMT):
Are we doing FAB-3389 for v1.3 ?

yacovm (Sat, 28 Jul 2018 11:00:07 GMT):
@dave.enyeart @cbf @mastersingh24

yacovm (Sat, 28 Jul 2018 11:00:36 GMT):
@sykesm

dave.enyeart (Sat, 28 Jul 2018 11:46:22 GMT):
@yacovm I've tagged it and it's parent epic as help-wanted, been trying to find somebody for it. @muralisr said he may be able to look at it.

dave.enyeart (Sat, 28 Jul 2018 11:49:21 GMT):
At this point I'd say v1.4.0 is more likely, although it would be really great if some good soul could add some minimal amount of metrics in v1.3.0.

yacovm (Sat, 28 Jul 2018 12:06:53 GMT):
I think we should merge code but not activate it in v1.3

yacovm (Sat, 28 Jul 2018 12:06:53 GMT):
I think we should merge code for metrics, but not activate it in v1.3

yacovm (Sat, 28 Jul 2018 12:07:26 GMT):
i.e not do https://gerrit.hyperledger.org/r/#/c/24889/6/peer/node/start.go@385

yacovm (Sat, 28 Jul 2018 12:07:54 GMT):
But, that's only my opinion.... if others think otherwise or likewise please state so.

yacovm (Sat, 28 Jul 2018 12:10:06 GMT):
my question is - are we activating this for v1.3?

dave.enyeart (Sat, 28 Jul 2018 12:10:48 GMT):
Ah, I didn't realize work has resumed on it... if some good metrics are added in v1.3 timeframe, why wouldn't we activate it?

dave.enyeart (Sat, 28 Jul 2018 12:10:48 GMT):
Ah, I didn't realize work has resumed on it (https://gerrit.hyperledger.org/r/#/c/24889/), if some good metrics are added in v1.3 timeframe, why wouldn't we activate it?

yacovm (Sat, 28 Jul 2018 12:11:09 GMT):
well... do we have *any* integration test with metrics?

dave.enyeart (Sat, 28 Jul 2018 12:11:44 GMT):
that would indeed be a requirement

dave.enyeart (Sat, 28 Jul 2018 12:12:02 GMT):
the submitter probably needs some guidance

dave.enyeart (Sat, 28 Jul 2018 12:16:00 GMT):
i sure wish we had test guidance in RTD that we could point people to @latitiah :) http://hyperledger-fabric.readthedocs.io/en/latest/testing.html

yacovm (Sat, 28 Jul 2018 12:16:01 GMT):
do you not think metrics warrants a playback?

dave.enyeart (Sat, 28 Jul 2018 12:16:24 GMT):
of course it would

yacovm (Sat, 28 Jul 2018 12:16:41 GMT):
@grapebaba ^

dave.enyeart (Sat, 28 Jul 2018 12:30:47 GMT):
@yacovm thanks for bringing it up... I've connected with grapebaba about design playbacks (I don't think non-maintainers can post here yet)

rjones (Sat, 28 Jul 2018 12:37:28 GMT):
@dave.enyeart they should be able to

C0rWin (Sat, 28 Jul 2018 17:32:36 GMT):
There is `Fabric CLI design review` scheduled for next week, which appears in my calendar as following:

C0rWin (Sat, 28 Jul 2018 17:32:41 GMT):

Clipboard - July 28, 2018 8:32 PM

C0rWin (Sat, 28 Jul 2018 17:32:52 GMT):
do we really need that much time for this?

cbf (Sat, 28 Jul 2018 20:15:03 GMT):
metrics collection would be awesome addition for 1.3

dave.enyeart (Sun, 29 Jul 2018 01:46:28 GMT):
@rjones can you update the Fabric CLI Design Review to be 45 minutes

dave.enyeart (Sun, 29 Jul 2018 01:46:43 GMT):
you got the start time correct :)

yacovm (Sun, 29 Jul 2018 12:30:43 GMT):
I don't think 1 day is enough for this, TBH

C0rWin (Sun, 29 Jul 2018 12:32:27 GMT):
well, it's only 12 hours, probably a warm up

rjones (Sun, 29 Jul 2018 22:45:21 GMT):
@C0rWin @dave.enyeart please tell me if it's re-done. I just trimmed it to 45 minutes, which I think will be a lot of ground. I don't understand why you don't want a 12 hour meeting

dave.enyeart (Mon, 30 Jul 2018 01:30:07 GMT):
@rjones I didn't get an updated invite, but that's ok, I'm sure people won't mind if we stop 11 hours early

rjones (Mon, 30 Jul 2018 03:18:58 GMT):
well I told the dang thing to send updated meeting details but I see no email ¯\_(ツ)_/¯

bpbuch (Tue, 31 Jul 2018 16:22:54 GMT):
Has joined the channel.

jg507 (Tue, 31 Jul 2018 21:13:26 GMT):
Has joined the channel.

dave.enyeart (Wed, 01 Aug 2018 12:58:04 GMT):
@here maintainer meeting starting in a couple minutes, some links that we will discuss:

dave.enyeart (Wed, 01 Aug 2018 12:58:16 GMT):
Release schedule: https://docs.google.com/document/d/1SMTcGTMmTpGIEFA9o8LhbtYhhSBS79TPIBCv-J3pCIc/edit#heading=h.nqedm5f92m27

dave.enyeart (Wed, 01 Aug 2018 12:58:16 GMT):
Release schedule in retrospective doc: https://docs.google.com/document/d/1SMTcGTMmTpGIEFA9o8LhbtYhhSBS79TPIBCv-J3pCIc/edit#heading=h.nqedm5f92m27

dave.enyeart (Wed, 01 Aug 2018 12:58:33 GMT):
Release dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10701

dave.enyeart (Wed, 01 Aug 2018 12:59:55 GMT):
https://zoom.us/my/hyperledger.community

dave.enyeart (Wed, 01 Aug 2018 19:48:25 GMT):
As a follow-up to our maintainer meeting today... here's the hygiene board that will pick up any jira items with label `hygiene`: https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=173&view=planning

dave.enyeart (Wed, 01 Aug 2018 19:48:37 GMT):
If you feel strongly about prioritizing a certain item, go ahead and create it, label it `hygiene`, and promote it from general Backlog to Next Items. On the next maintainer call we can discuss relative priorities and rank the Next Items top-down.

dave.enyeart (Wed, 01 Aug 2018 19:49:48 GMT):
Technically - Next Items is a jira sprint, but we won't actually start it, we use it more as a revolving door to rank items above the general Backlog.

dave.enyeart (Wed, 01 Aug 2018 19:50:54 GMT):
Thanks to @sykesm for watching over the hygiene backlog the past few months.

mhomaid (Thu, 02 Aug 2018 16:40:21 GMT):
Has joined the channel.

diizuka (Fri, 03 Aug 2018 00:22:04 GMT):
Has joined the channel.

zmaro (Fri, 03 Aug 2018 15:21:46 GMT):
Has joined the channel.

GopalPanda (Sat, 04 Aug 2018 00:30:18 GMT):
I would like to join fabric community and become a contributor, how to start the process.

rjones (Sat, 04 Aug 2018 04:10:13 GMT):
@GopalPanda read https://hyperledger-fabric.readthedocs.io/en/release-1.2/CONTRIBUTING.html and please ask questions in #fabric-questions

GopalPanda (Sat, 04 Aug 2018 06:07:22 GMT):
@rjones Thank you , will all the guidelines

dave.enyeart (Tue, 14 Aug 2018 14:13:40 GMT):
@here Design review starting for Fabric tokens - https://zoom.us/j/5184947650

dave.enyeart (Wed, 15 Aug 2018 12:05:05 GMT):
@here maintainer meeting starts in one hour: https://zoom.us/my/hyperledger.community

jyellick (Wed, 15 Aug 2018 13:00:58 GMT):
I'm double-booked this morning with another call I can't miss, but will try to join late

larry618 (Sun, 19 Aug 2018 07:42:55 GMT):
Has joined the channel.

bdjidi (Tue, 21 Aug 2018 22:48:30 GMT):
Has joined the channel.

jimthematrix (Wed, 22 Aug 2018 03:43:15 GMT):
@dave.enyeart I missed the FabToken design review, was it recorded? (I did read through the design doc)

rjones (Wed, 22 Aug 2018 07:54:33 GMT):
@jimthematrix https://drive.google.com/drive/folders/1GHQkm41tF76kDR5x5eLzJhzLj9S-0bWf ?

dave.enyeart (Wed, 22 Aug 2018 13:34:39 GMT):
@here From a release perspective, getting CRs reviewed remains the largest risk to the release - we need to stop adding new code and catch up on the review backlog please. We have almost 200 CRs in review and the incomings are far outpacing the reviews.

dave.enyeart (Wed, 22 Aug 2018 13:34:47 GMT):
I’d ask ALL maintainers to stop coding and focus on reviews until we can get to a reasonable backlog.

dave.enyeart (Wed, 22 Aug 2018 13:38:43 GMT):
On the next maintainers call we'll assess where we are... we will likely need to defer some stories or entire epics in order to focus on the priorities that can be delivered and tested in v1.3 timeframe.

dave.enyeart (Wed, 22 Aug 2018 13:38:43 GMT):
On the maintainers call next week we'll assess where we are... hopefully we can make good review progress in the next week, but we will likely need to defer some stories or entire epics in order to focus on the priorities that can be delivered and tested in v1.3 timeframe.

nrohith (Wed, 22 Aug 2018 13:38:47 GMT):
Has joined the channel.

dave.enyeart (Thu, 23 Aug 2018 12:32:29 GMT):
@here I've nominated Matt Sykes as a Fabric maintainer. Please review and +1 if you agree: https://gerrit.hyperledger.org/r/#/c/25819/

dave.enyeart (Thu, 23 Aug 2018 17:05:46 GMT):
Merged - welcome to the club @sykesm ! @rjones Can you grant the privileges please.

dave.enyeart (Thu, 23 Aug 2018 17:05:46 GMT):
Confirmed and merged - welcome to the club @sykesm ! @rjones Can you grant the privileges please.

rjones (Thu, 23 Aug 2018 18:39:46 GMT):
Help desk ticket opened 🤠

JonathanLevi (Thu, 23 Aug 2018 20:52:08 GMT):
--- The *master* branch is temporarily broken. Do not "git pull"...

JonathanLevi (Thu, 23 Aug 2018 20:52:22 GMT):
... and certainly not "git push" ;-)

yacovm (Thu, 23 Aug 2018 20:52:31 GMT):
or, git pull and then git push a fix

JonathanLevi (Thu, 23 Aug 2018 20:52:52 GMT):
Sounds like a lot to ask ;-)

JonathanLevi (Thu, 23 Aug 2018 20:54:15 GMT):
!(git pull) && !(git push) && ( (git pull) && (git commit a fix) && (git push) )

JonathanLevi (Thu, 23 Aug 2018 20:55:02 GMT):
Or would you like an || ?

yacovm (Thu, 23 Aug 2018 20:55:08 GMT):
that's what i was typing

JonathanLevi (Thu, 23 Aug 2018 20:55:37 GMT):
!(git pull) && !(git push) && ( (git pull) || (git commit a fix) && (git push) )

mathiasb303 (Wed, 29 Aug 2018 12:12:26 GMT):
Has joined the channel.

dave.enyeart (Wed, 29 Aug 2018 12:36:36 GMT):
@here Maintainer meeting coming up at the top of the hour. Agenda for today: 1) With mid-September release candidate for v1.3 approaching, let’s first get a system test update 2) v1.3 epic close down 3) v1.4 update - some epics are currently underway, mark any other candidate epics as FixVersion=v1.4.0 and we will review in next maintainer meetings 4) Other items - performance, hygiene, etc.

dave.enyeart (Wed, 29 Aug 2018 12:36:36 GMT):
@here Maintainer meeting coming up at the top of the hour: https://zoom.us/my/hyperledger.community Agenda for today: 1) With mid-September release candidate for v1.3 approaching, let’s first get a system test update 2) v1.3 epic close down 3) v1.4 update - some epics are currently underway, mark any other candidate epics as FixVersion=v1.4.0 and we will review in next maintainer meetings 4) Other items - performance, hygiene, etc.

moriohara (Wed, 29 Aug 2018 13:09:33 GMT):
Has joined the channel.

rickr (Wed, 29 Aug 2018 14:41:48 GMT):

dave.enyeart (Wed, 29 Aug 2018 15:07:09 GMT):
Maintainer meeting recording from today: https://drive.google.com/file/d/1785Ao-lQNaWeaC74_huiinuOrO3S40sp/view

sureshtedla (Fri, 31 Aug 2018 16:25:02 GMT):
Has joined the channel.

wonderfan (Thu, 06 Sep 2018 23:28:39 GMT):
Has joined the channel.

raviyelleni (Sun, 09 Sep 2018 04:45:01 GMT):
Has joined the channel.

dave.enyeart (Wed, 12 Sep 2018 13:00:41 GMT):
@here maintainer meeting starting: https://zoom.us/my/hyperledger.community

JaydipMakadia (Thu, 13 Sep 2018 13:12:03 GMT):
Has joined the channel.

cbf (Mon, 17 Sep 2018 14:40:33 GMT):
@here I've been thinking about this a while, we currently have nothing in the CR heading that indicates whether the CR is a fix, or a feature, etc

cbf (Mon, 17 Sep 2018 14:41:26 GMT):
I seem to recall that there was a convention used by some projects to specify the nature of a CR/PR eg

cbf (Mon, 17 Sep 2018 14:41:55 GMT):
FIX FOO-nnnn blah blah blah

cbf (Mon, 17 Sep 2018 14:43:26 GMT):
now, we have also talked about loosening the requirement to put the JIRA id in the heading, but it is not being used consistently. However, especially as we close in on the end of a release cycle, being able to identify which CRs need reviews becomes increasingly important

cbf (Mon, 17 Sep 2018 14:44:48 GMT):
maybe we could adopt a convention that at least for bug fixes, we include FIX in the header so that we don't waste time opening up CRs that don't need immediate attention

cbf (Mon, 17 Sep 2018 14:44:51 GMT):
thoughts?

yacovm (Mon, 17 Sep 2018 14:46:35 GMT):
I'd say *forcing* a convention isn't a must since there are gray areas - sometimes something is an improvement in the eyes of one, and a bug fix in the eyes of another. I think that it can be nice if you had some indication of if it's a bug fix, though I don't see how to enforce it voluntarily? particularly for new members.

yacovm (Mon, 17 Sep 2018 14:48:03 GMT):
FIX in the header sounds good to me....

cbf (Mon, 17 Sep 2018 14:52:24 GMT):
not forcing anything

mastersingh24 (Mon, 17 Sep 2018 15:42:52 GMT):
I've been going with "Fixes FAB-XXX #done" We could either go with FIX or BUG in the header

mastersingh24 (Mon, 17 Sep 2018 15:42:59 GMT):
I guess FIX would be better

dave.enyeart (Mon, 17 Sep 2018 16:59:53 GMT):
How about simply requesting that the commit message start with a distinguishing verb, such as "Fix...", "Add...", "Refactor...", "Document...", "Test...". Then we won't be using any extra characters, simply making the commit message more informative. And encourage people to use "Fix..." for bugs.

cbf (Mon, 17 Sep 2018 20:38:34 GMT):
I'd be okay with that, the convention I had seen previously was used to generate a changelog, but we are doing that with JIRA now

JonathanLevi (Tue, 18 Sep 2018 14:16:53 GMT):
Can I have a quick +2 here please? https://gerrit.hyperledger.org/r/#/c/26343/

JonathanLevi (Tue, 18 Sep 2018 14:18:03 GMT):
(terminated the fabric-ca build earlier too early. Will sleep better knowing that it wasn't the last CR I merged there)

JonathanLevi (Tue, 18 Sep 2018 14:20:14 GMT):
Thanks @smithbk and @dave.enyeart

dave.enyeart (Wed, 19 Sep 2018 13:35:42 GMT):
@here I've posted remaining release items that I know of in #fabric-scrum . As we're at the end of the road here, please participate in fabric-scrum this week, could use all your help closing things down this week.

muralisr (Wed, 19 Sep 2018 14:15:54 GMT):
:+1: I've bin remiss in participating...will from next time

mastersingh24 (Wed, 19 Sep 2018 14:21:45 GMT):
slacker ^^^^

mastersingh24 (Wed, 19 Sep 2018 14:22:10 GMT):
just kidding @muralisr - I know you miss me

wyatt-noise (Wed, 19 Sep 2018 23:58:59 GMT):
Has joined the channel.

muralisr (Thu, 20 Sep 2018 03:58:45 GMT):
not entirely out of the realm of possibility @mastersingh24 :-)

adc (Thu, 20 Sep 2018 13:12:23 GMT):
please, some love to https://gerrit.hyperledger.org/r/#/c/25948/ Thanks :)

JonathanLevi (Thu, 20 Sep 2018 15:23:41 GMT):
@adc - do we want this In Fabric 1.3 RC1 ?

JonathanLevi (Thu, 20 Sep 2018 15:24:30 GMT):
We are under a "soft" (*HARD*) "code freeze" ... but if it's important I can ask @dave.enyeart and the rest of the gang...

JonathanLevi (Thu, 20 Sep 2018 15:24:30 GMT):
We are under a "soft" (*HARD*) "code freeze" ... but if it's important we can ask @dave.enyeart and the rest of the gang...

JonathanLevi (Thu, 20 Sep 2018 15:24:30 GMT):
We are under a "soft" (though relatively *HARD*) "code freeze" ... but if it's important we can ask @dave.enyeart and the rest of the gang...

JonathanLevi (Thu, 20 Sep 2018 15:24:30 GMT):
We are under a "soft" (though relatively *HARD* ;-) ) "code freeze" ... but if it's important we can ask @dave.enyeart and the rest of the gang...

binhn (Thu, 20 Sep 2018 16:34:07 GMT):
@adc your pr doesn't seem to relate to 1.3 features but future; can we hold until 1.3 done?

dave.enyeart (Thu, 20 Sep 2018 16:50:06 GMT):
we have been allowing v1.4 content to get merged, as long as it is not exposed or disruptive to v1.3 execution paths. but with the release candidate scheduled for early next week, it is indeed time for a soft freeze where only critical v1.3 items should get merged.

dave.enyeart (Thu, 20 Sep 2018 16:50:22 GMT):
after we create the release-1.3 branch next week, master will be wide open again for v1.4 dev.

cbf (Thu, 20 Sep 2018 17:28:25 GMT):
+1

adc (Fri, 21 Sep 2018 07:25:42 GMT):
@binhn, alright. No problem. It can wait. Sorry for that :)

adc (Fri, 21 Sep 2018 07:25:42 GMT):
@binhn, alright. No problem. It can wait. Sorry for that

dave.enyeart (Sun, 23 Sep 2018 16:58:04 GMT):
@all Things are looking pretty good for the v1.3 release candidate. I've mentioned a few final CRs in #fabric-pr-review . Does anybody else know of other critical items?

dave.enyeart (Mon, 24 Sep 2018 16:37:40 GMT):
@all Latest updates posted in #fabric-scrum . I will call for merge freeze except for any critical release CRs that we discuss here or in #fabric-scrum

yacovm (Mon, 24 Sep 2018 17:27:57 GMT):
@dave.enyeart how long is the merge freeze expected, and what is the policy between its end to the cutting of GA ? can we merge v1.4 content that seems detached from the production path? can we merge small fixes such as https://gerrit.hyperledger.org/r/#/c/26470/ , etc. ?

dave.enyeart (Mon, 24 Sep 2018 17:31:11 GMT):
freeze usually ends within 24 hours. when rc1 is cut, we also create release-1.3 branch, and at that time normal merging can resume in master. for the next 24 hours, only critical fixes and release CRs should be merged into master

yacovm (Mon, 24 Sep 2018 17:32:18 GMT):
yes i am asking about the policy after the 24 hours ;)

yacovm (Mon, 24 Sep 2018 17:32:52 GMT):
between RC1 cut and GA

dave.enyeart (Mon, 24 Sep 2018 17:33:39 GMT):
master is wide open again between RC1 and GA. we do any v1.3 GA fixes in release-1.3.

Ferrymania (Tue, 25 Sep 2018 02:47:23 GMT):
Has joined the channel.

MikeyGarcia (Tue, 25 Sep 2018 13:04:38 GMT):
Has joined the channel.

dave.enyeart (Wed, 26 Sep 2018 05:38:17 GMT):
fabric, fabric-ca, fabric-chaincode-java v1.3.0-rc1 have been released.

dave.enyeart (Wed, 26 Sep 2018 05:38:32 GMT):
release-1.3 branch has been created for each for any critical bugs that are found over the next week.

dave.enyeart (Wed, 26 Sep 2018 05:38:41 GMT):
master branch is re-opened for v1.4 development.

dave.enyeart (Wed, 26 Sep 2018 05:38:56 GMT):
Caveat - please don't merge into fabric-ca yet. e2e tests from the SDKs are still failing there due to java chaincode issues we've been having, related to syncing across the repositories and branches for 1.3.0-SNAPSHOT, 1.3.0-rc1, 1.3.0, and 1.4.0.

dave.enyeart (Wed, 26 Sep 2018 05:39:04 GMT):
Proposed solution for part of the problem in CRs

dave.enyeart (Wed, 26 Sep 2018 05:39:08 GMT):
https://gerrit.hyperledger.org/r/#/c/26589/ https://gerrit.hyperledger.org/r/#/c/26590/ https://gerrit.hyperledger.org/r/#/c/26591/

dave.enyeart (Wed, 26 Sep 2018 12:32:10 GMT):
@here Maintainer meeting in 30 minutes

dave.enyeart (Wed, 26 Sep 2018 12:32:33 GMT):
Here are the agenda topics I have for today so far... anything else to add?

dave.enyeart (Wed, 26 Sep 2018 12:32:40 GMT):
v1.3 release candidate update - Dave Enyeart v1.3 SDK release plans and v1.4 beta plans v1.3 retrospective - please add thoughts, we can review next meeting https://docs.google.com/document/d/1kB-M1sZifxbwIZXO5w79xJDkgFgOeFI4n-rR2AIAU0I/edit# v1.4 planning - all Interoperability test for cross repository testing (e.g. Identity Mixer, java chaincode) - Latitia Haskins .NET chaincode proposal - Manuel Rauber

dave.enyeart (Wed, 26 Sep 2018 12:32:40 GMT):
v1.3 release candidate update - Dave Enyeart v1.3 SDK release plans and v1.4 early beta for programming model v1.3 retrospective - please add thoughts, we can review next meeting https://docs.google.com/document/d/1kB-M1sZifxbwIZXO5w79xJDkgFgOeFI4n-rR2AIAU0I/edit# v1.4 planning - all Interoperability test for cross repository testing (e.g. Identity Mixer, java chaincode) - Latitia Haskins .NET chaincode proposal - Manuel Rauber

dave.enyeart (Wed, 26 Sep 2018 12:53:30 GMT):
-----------------

dave.enyeart (Wed, 26 Sep 2018 12:53:30 GMT):
----------------- v1.4 planning ----------------

dave.enyeart (Wed, 26 Sep 2018 12:54:10 GMT):
The feedback from many community members is that they would like a long term support release of Hyperledger Fabric v1.x, with operational improvements. The Fabric maintainers and developers are spending a large percentage of time supporting the community, across Fabric, SDKs, samples, etc. We can get some 'quick wins' in these areas by focusing some effort for next release on operational improvements and SDK/sample improvements. Additionally, some of the larger features we have been working on could benefit from in depth community feedback and test prior to delivery. Let me propose the following high level plan to address these concerns:

dave.enyeart (Wed, 26 Sep 2018 12:54:39 GMT):
1.4 - smaller “long term support" release - ship early-mid Dec, with an early beta targeting programming model additions - operational improvements - metrics, serviceability, improved logging - programming model additions for SDK and chaincode - Node.js SDK and sample improvements - private data reconciliation (deliver the code-complete but deferred items from v1.3)

yacovm (Wed, 26 Sep 2018 12:54:43 GMT):
> The Fabric maintainers and developers are spending a large percentage of time supporting the community :100:

dave.enyeart (Wed, 26 Sep 2018 12:54:52 GMT):
2.0 - large new items - end of 1Q19, with a more formal beta early on to get feedback on the new features - Raft orderer - Token - Lifecycle 2.0 - Local collections - Idemix revocation support - go based CLI - hygiene items, especially on peer side, e.g. removal of singleton

dave.enyeart (Wed, 26 Sep 2018 12:55:08 GMT):
------------------------------

yacovm (Wed, 26 Sep 2018 12:55:11 GMT):
wait wait, isn't Raft v1.4 ?

cbf (Wed, 26 Sep 2018 13:04:45 GMT):
@here maintainer meeting is starting, please join

sureshtedla (Wed, 26 Sep 2018 13:05:17 GMT):
link please?

Maria (Wed, 26 Sep 2018 13:05:29 GMT):
https://zoom.us/my/hyperledger.community

latitiah (Wed, 26 Sep 2018 13:05:36 GMT):
:wave:

jyellick (Wed, 26 Sep 2018 13:05:45 GMT):
Here

bretharrison (Wed, 26 Sep 2018 13:05:48 GMT):
On call

elli-androulaki (Wed, 26 Sep 2018 13:05:51 GMT):
Here

scottz (Wed, 26 Sep 2018 13:05:53 GMT):
here

joe-alewine (Wed, 26 Sep 2018 13:05:55 GMT):
Here

cbf (Wed, 26 Sep 2018 13:05:56 GMT):
here

pandrejko (Wed, 26 Sep 2018 13:06:07 GMT):
here

sstone1 (Wed, 26 Sep 2018 13:06:15 GMT):
howdy

andrew-coleman (Wed, 26 Sep 2018 13:06:41 GMT):
here

sureshtedla (Wed, 26 Sep 2018 13:06:48 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=FrgzyHHrpYstGhvdE) @Maria Thank you

sykesm (Wed, 26 Sep 2018 13:49:38 GMT):
Test flakes: https://jira.hyperledger.org/issues/?filter=12178

cbf (Wed, 26 Sep 2018 13:55:59 GMT):
I know I am beating a dead horse, but chaincode should just be images that get pulled

sykesm (Wed, 26 Sep 2018 13:56:17 GMT):
that's one aspect, but, in general, yes

cbf (Wed, 26 Sep 2018 13:56:42 GMT):
yes, I understand, but we should definitely get rid of the build-the-image in the peer

sstone1 (Wed, 26 Sep 2018 14:01:41 GMT):
:+1:

sykesm (Wed, 26 Sep 2018 14:04:13 GMT):
I've outlined a list of actions to Gari a few times. They will not be surprises. For fabric core: - we focus on protbuf+grpc only - we define process contracts for chaincode (docker is the primary implementation) - we define a pluggable launcher based on a cni-like model - we clearly indicate fabric core code should not be included in user assets - we extract the libraries (including golang shim) that should not be part of core - pieces of msp; vendor them as needed

yacovm (Wed, 26 Sep 2018 14:14:42 GMT):
what pieces of `msp` exactly?

yacovm (Wed, 26 Sep 2018 14:16:01 GMT):
and what is the plan w.r.t branches?

yacovm (Wed, 26 Sep 2018 14:17:33 GMT):
I personally think that before we declare we do lots of feature branches for post v1.4 items

yacovm (Wed, 26 Sep 2018 14:17:43 GMT):
we need to estimate how much code is left in these features

yacovm (Wed, 26 Sep 2018 14:17:53 GMT):
because at least for Raft I don't think it's much....

yacovm (Wed, 26 Sep 2018 14:19:30 GMT):
and if we have a development branch for 2.0 items - then don't we need to push the v1.4 items to the 2.0 one as well?

yacovm (Wed, 26 Sep 2018 14:19:43 GMT):
otherwise it'll be very hard to join them together afterwards

adc (Wed, 26 Sep 2018 14:19:52 GMT):
@sykesm I'm also curios to learn which part of msp do you think should be vendored

yacovm (Wed, 26 Sep 2018 14:20:28 GMT):
I'd say you need to have a say in the decision, @adc ;)

mne (Wed, 26 Sep 2018 14:20:29 GMT):
Has joined the channel.

cbf (Wed, 26 Sep 2018 14:27:03 GMT):
fwiw, we need a k8s process for chaincode

cbf (Wed, 26 Sep 2018 14:27:03 GMT):
fwiw, IMO we need a k8s process for chaincode

mbwhite (Wed, 26 Sep 2018 14:29:06 GMT):
+1 here as well; is there a location (google doc/jira etc) where these thoughts are captured (like those above) are captured? Would like to get up-to-speed on the thinking

dave.enyeart (Wed, 26 Sep 2018 14:38:10 GMT):
ok, we got the fabric-ca end2end tests passing now. I can give the all clear for fabric, fabric-ca, fabric-chaincode-java. master branch is wide open again for new dev. release-1.3 branch will be used for critical v1.3.0 bug fixes. We'll create release-1.3 branches for the other repos laster today.

cbf (Wed, 26 Sep 2018 14:38:33 GMT):
yay!

chimonas (Wed, 26 Sep 2018 15:05:05 GMT):
Has joined the channel.

aso (Wed, 26 Sep 2018 17:50:15 GMT):
Has joined the channel.

binhn (Wed, 26 Sep 2018 18:02:53 GMT):
re 1.4, we'll be working on enhanced mvcc; without it, fabric would not be useable to us

dave.enyeart (Wed, 26 Sep 2018 19:54:45 GMT):
Fabric v1.3.0-rc1 has been announced! https://lists.hyperledger.org/g/fabric/message/4656

dave.enyeart (Wed, 26 Sep 2018 20:12:23 GMT):
Ping me if you'd like anything else included in the release notes for the final release:

dave.enyeart (Wed, 26 Sep 2018 20:12:28 GMT):
https://github.com/hyperledger/fabric/releases/tag/v1.3.0-rc1

dave.enyeart (Wed, 26 Sep 2018 20:12:37 GMT):
https://github.com/hyperledger/fabric-ca/releases/tag/v1.3.0-rc1

yoheiueda (Thu, 27 Sep 2018 09:07:43 GMT):
Has joined the channel.

sheehan (Thu, 27 Sep 2018 14:11:33 GMT):
@dave.enyeart - missed the last maintainers meeting. Could you post the recording link when you have a chance? Can't find it at https://drive.google.com/drive/u/0/folders/15w14LqjdgREkCabSzWfsgZpj4BPypa9a Thanks

cbf (Thu, 27 Sep 2018 15:37:19 GMT):
I updated the CONTRIBUTIONS.rst to add a better description of our processes

cbf (Thu, 27 Sep 2018 15:37:21 GMT):
https://gerrit.hyperledger.org/r/26638

cbf (Thu, 27 Sep 2018 15:37:52 GMT):
@dave.enyeart @mastersingh24 and others, feedback encouraged

dave.enyeart (Thu, 27 Sep 2018 18:25:50 GMT):
@binhn We have not forgotten about enhanced mvcc, in fact that is one of the multiple drivers for the hygiene/refactoring that will span v1.4 and 2.0. Specifically the validator/committer refactoring is one of the top priorities currently, which will unblock the enhanced mvcc task FAB-11422. We will get the hygiene/refactoring plan into jira and then we can add the corresponding blocking links.

dave.enyeart (Thu, 27 Sep 2018 18:27:05 GMT):
@rjones @tkuhrt please post the link to the maintainer meeting recording once it is available

rjones (Thu, 27 Sep 2018 18:29:52 GMT):
@dave.enyeart It will be this afternoon

jdfigure (Thu, 27 Sep 2018 20:02:33 GMT):
Has joined the channel.

iramiller (Thu, 27 Sep 2018 20:21:47 GMT):
Has joined the channel.

rjones (Thu, 27 Sep 2018 23:03:31 GMT):
@dave.enyeart 20180926-fabric-maintainers.* in https://drive.google.com/open?id=15w14LqjdgREkCabSzWfsgZpj4BPypa9a

sheehan (Fri, 28 Sep 2018 03:08:57 GMT):
Thanks!

jmason900 (Fri, 28 Sep 2018 13:37:58 GMT):
Has joined the channel.

binhn (Fri, 28 Sep 2018 14:08:48 GMT):
@dave.enyeart ok, we'll coordinate with the refactoring effort

rjones (Sat, 29 Sep 2018 06:43:50 GMT):
@cbf confluence is coming to Hyperledger at the highest priority. I filed a flaming hot work order today.

wangdong (Sat, 29 Sep 2018 08:48:23 GMT):
Has joined the channel.

zhaochy (Sun, 30 Sep 2018 02:03:56 GMT):
Has joined the channel.

knagware9 (Mon, 01 Oct 2018 03:28:42 GMT):
Has joined the channel.

vanitas92 (Mon, 01 Oct 2018 09:07:30 GMT):
Has joined the channel.

mastersingh24 (Mon, 01 Oct 2018 11:07:10 GMT):
@binhn @muralisr - Are either of you attending the hackfest in Montreal? Any other maintainers planning on attending? I know @cbf and I will be there

muralisr (Mon, 01 Oct 2018 12:46:04 GMT):
@mastersingh24 I haven't planned for it yet... but will definitely be there at the global forum (hope to see you there !)

mastersingh24 (Mon, 01 Oct 2018 12:54:01 GMT):
The global forum in Geneva?

mastersingh24 (Mon, 01 Oct 2018 12:54:12 GMT):
apparently I will be there as well

muralisr (Mon, 01 Oct 2018 14:38:34 GMT):
:thumbsup:

rjones (Mon, 01 Oct 2018 14:54:05 GMT):
@mastersingh24 Basel, no?

mastersingh24 (Mon, 01 Oct 2018 15:02:04 GMT):
right ... yeah

andrew-coleman (Tue, 02 Oct 2018 09:17:07 GMT):
@mastersingh24 I'll be at the hackfest. And the meetup this evening

dave.enyeart (Tue, 02 Oct 2018 14:22:52 GMT):
I've been doing a lot of bookkeeping recently. I think we all know this, but just in case I’ll provide some reminders: - `master` and `release-1.3` branches are now split. Recommendation is to do new work in master and then cherry pick to release-1.3 if it is an important fix for the upcoming 1.3.0. - when the code is well aligned (such as release-1.3 and master currently), it is simple to cherry pick by using the Cherry Pick button in gerrit. If you’ve never tried this, you’ll love it! This can be done by CR developer or any maintainer, as needed. - for the most critical fixes that current production customers will need, the fix can also be cherry picked to release-1.1 and release-1.2, although many times this will require a manual local cherry pick and conflict resolution. Be very judicious and careful with these, we must not risk breaking existing customers in a 3rd digit patch release. - in the Jira FixVersion, indicate the intent by listing the target releases. For example for a fix in master and release-1.3, indicate FixVersion `v1.4.0` , `v1.3.0`. - to be very clear of intent, add a link in the Jira comments to each of the release CRs. It should be in sync with the FixVersions. If they are not in sync, it should raise a flag that there was an oversight that needs to be resolved before closing. - If you merge the last CR, remember to Close the jira item.

dave.enyeart (Tue, 02 Oct 2018 14:22:52 GMT):
I've been doing a lot of bookkeeping recently. I think we all know this, but just in case I’ll provide some reminders: - `master` and `release-1.3` branches are now split. Recommendation is to do new work in master and then cherry pick to release-1.3 if it is an important fix for the upcoming 1.3.0. - when the code is well aligned (such as release-1.3 and master currently), it is simple to cherry pick by using the Cherry Pick button in gerrit. If you’ve never tried this, you’ll love it! This can be done by CR developer or any maintainer, as needed. - for the most critical fixes that current production customers will need, the fix can also be cherry picked to release-1.1 and release-1.2, although many times this will require a manual local cherry pick and conflict resolution. Be very judicious and careful with these, we must not risk breaking existing customers in a 3rd digit patch release. - in the Jira FixVersion, indicate the intent by listing the target releases. For example for a fix in master and release-1.3, indicate FixVersion `v1.4.0` , `v1.3.0`. - to be very clear of intent, add a link in the Jira comments to each of the release CRs. It should be in sync with the FixVersions. If they are not in sync, it should raise a flag in your mind that there was an oversight that needs to be resolved before closing. - If you merge the last CR, remember to Close the jira item.

sstone1 (Wed, 03 Oct 2018 12:46:35 GMT):
is there a suggested file extension for chaincode packages created with the `peer chaincode package` command? the only thing i can see is a `.out` extension in an example in the docs, but i'm not sure `.out` counts ;-)

sstone1 (Wed, 03 Oct 2018 12:47:17 GMT):
i was thinking more of something like `.cds` (Chaincode Deployment Spec) or `.cdp` (Chaincode Deployment Package)

yacovm (Wed, 03 Oct 2018 12:53:36 GMT):
I'm not sure, but i do know it might be a good idea to rewrite all that chaincode packaging stuff....

yacovm (Wed, 03 Oct 2018 12:54:24 GMT):
- It's not portable - SDK and peer CLI produce different outputs :( - No one can unzip this using any tool.... so no one can actually inspect it properly

cbf (Wed, 03 Oct 2018 13:10:25 GMT):
I think it might be a good idea to rethink it completely

yacovm (Wed, 03 Oct 2018 13:17:53 GMT):
@cbf can you expand? Do you mean docker approach?

cbf (Wed, 03 Oct 2018 13:25:31 GMT):
yes

cbf (Wed, 03 Oct 2018 13:25:53 GMT):
our handling of chaincode is insane

yacovm (Wed, 03 Oct 2018 13:26:10 GMT):
well i think for v1.4 it's too late for that

cbf (Wed, 03 Oct 2018 13:26:20 GMT):
yeah, I know

yacovm (Wed, 03 Oct 2018 13:26:24 GMT):
so i suggest something that we can add to v1.4 so it will be LTS :)

yacovm (Wed, 03 Oct 2018 13:27:55 GMT):
rewrite the packaging to be something easily inspect-able and also portable, via a deterministic archive based package and validate it works the same in golang/JS/java

cbf (Wed, 03 Oct 2018 13:29:00 GMT):
I still say rube goldberg would be proud

jyellick (Wed, 03 Oct 2018 13:39:30 GMT):
FYI, as part of the deferred lifecycle work, the packaging was already somewhat addressed. See https://gerrit.hyperledger.org/r/c/25443/ . As an interim step, the new packaging was changed to be a vanilla tar.gz file, which embeds a manifest file, and in the go/node case another tar of the source files, or in the car case, a .car file. Ultimately, the hope was that we could adopt something similar to the CF buildpack, and flatten the packaging structure, but as a first step, it seemed like a minimal way to make packages trivially user-inspectable.

sstone1 (Wed, 03 Oct 2018 13:41:14 GMT):
@jyellick interesting... is there a CR lined up for the SDK work to create the new format packages?

jyellick (Wed, 03 Oct 2018 13:44:08 GMT):
The SDKs have not implemented this as of yet. In fact, I've suggested that they should probably hold off, seeing as the plan calls for lifecycle in v2.0, and there is obviously other interest in improving the packaging. The lifecycle work is really much more about the lifecycle of instantiating/upgrading, the install/packaging related changes were brought in as a minimal set to bring a bit of sanity by removing several components of our rube goldberg machine.

jyellick (Wed, 03 Oct 2018 13:47:45 GMT):
Particularly note that the new packaging contains three pieces of information type, path, and the code (contrasted with the old packaging, which contains, name, version, path, type, args, runtime, insantiation policy, signatures, code, and probably some other fields I am forgetting). I'd have loved to remove type and path as well, but it would have been a much more invasive change.

sstone1 (Wed, 03 Oct 2018 14:01:33 GMT):
how come name and version have been removed? aren't they useful for identifying what's in the package? does that now require looking in the code to figure that out?

jyellick (Wed, 03 Oct 2018 14:02:04 GMT):
Name and version are passed as parameters to the install function when the package is installed.

jyellick (Wed, 03 Oct 2018 14:03:19 GMT):
If we were to take a more radical departure, I would suggest that we move away from name/version

jyellick (Wed, 03 Oct 2018 14:03:25 GMT):
And simply refer to packages by their hash

mbwhite (Wed, 03 Oct 2018 15:26:46 GMT):
@jyellick do you have a reference to the high design of the new lifecycle?

dave.enyeart (Wed, 03 Oct 2018 15:47:56 GMT):
I'd start with the July 30 playback: https://wiki.hyperledger.org/projects/fabric/playbacks

toddinpal (Wed, 03 Oct 2018 19:45:13 GMT):
Has joined the channel.

davidkel (Thu, 04 Oct 2018 08:10:41 GMT):
@dave.enyeart Has any more thought been given to the concept of 1.4 being LTS, Specifically timescales ? It occurs to me that we would want to look at the LTS lifecycles of dependent components such as node.js and consider whether to take the hit of moving to node.js 10 in 1.4 rather than remaining at 8 as it has a longer LTS period.

dave.enyeart (Thu, 04 Oct 2018 10:46:33 GMT):
@davidkel LTS is a goal for v1.4 unless we find a compelling reason for it not to be. No discussion of timescales yet. I do recommend aggressively moving up dependencies, and that should be done early in the v1.4 cycle. Would node.js 8 to node.js 10 update impact existing applications?

davidkel (Thu, 04 Oct 2018 10:47:44 GMT):
@dave.enyeart I have heard that there are some small incompatibilities, but until it does get released as LTS I won't know for sure. Node 10 is due to go LTS this month

grice32 (Thu, 04 Oct 2018 17:41:42 GMT):
Has joined the channel.

mbwhite (Fri, 05 Oct 2018 13:20:20 GMT):
FYI - I've had a brief review of the release notes and nothing has jumped out. But will continue to review and look to start trialing node 10. Do we have an JIRAs for handling 'currency' items such as this?

dave.enyeart (Sun, 07 Oct 2018 18:33:50 GMT):
@mbwhite there is no jira item for updating dependencies... go ahead and create one for your use. (note - we are looking at a more exhaustive update of dependencies for v1.4, so we may create an umbrella jira, but go ahead with your own for now).

mbwhite (Mon, 08 Oct 2018 08:56:36 GMT):
willd o thanks @dave.enyeart

mbwhite (Mon, 08 Oct 2018 08:56:36 GMT):
will do thanks @dave.enyeart

dave.enyeart (Tue, 09 Oct 2018 06:08:26 GMT):
Fabric v1.3.0 has been updated to use baseimage 0.4.13, which includes the fix for the slow couchdb container start. We intend to do final testing on Tuesday and release on Wednesday.

mbwhite (Tue, 09 Oct 2018 08:27:35 GMT):
@dave.enyeart is this the error that is observed ``` Error: error getting endorser client for channel: endorser client failed to connect to peer0.org1.example.com:7051: failed to create new connection: context deadline exceeded ```

dave.enyeart (Tue, 09 Oct 2018 12:03:56 GMT):
@mbwhite yes, that is one of the manifestations, if peer can't start due to couchdb not yet available.

cbf (Tue, 09 Oct 2018 13:23:12 GMT):
@here I notice that there are a lot of stale CRs that have merge conflicts and or unresolved comments

cbf (Tue, 09 Oct 2018 13:23:59 GMT):
If you have stale CRs, please either get it moving or abandon the CR

cbf (Tue, 09 Oct 2018 13:24:24 GMT):
it really looks bad to someone from the outside if there are tons of unmerged CRs

cbf (Tue, 09 Oct 2018 13:25:29 GMT):
further, if you see a contribution from someone that is languishing, please review it and help the contribution forward

raccoonrat (Wed, 10 Oct 2018 02:50:55 GMT):
Has joined the channel.

dave.enyeart (Wed, 10 Oct 2018 08:20:05 GMT):
@here We are ready to release final v1.3.0. MERGE FREEZE in `release-1.3` branches today. `master` branches remain open for v1.4 dev.

14gracel (Wed, 10 Oct 2018 12:12:45 GMT):
Has joined the channel.

dave.enyeart (Wed, 10 Oct 2018 13:05:13 GMT):
@here maintainer meeting starting: https://zoom.us/my/hyperledger.community

dave.enyeart (Wed, 10 Oct 2018 13:06:11 GMT):
to summarize from last maintainer meeting…

dave.enyeart (Wed, 10 Oct 2018 13:06:23 GMT):
v1.3 retrospective - please add thoughts https://docs.google.com/document/d/1kB-M1sZifxbwIZXO5w79xJDkgFgOeFI4n-rR2AIAU0I/edit#

dave.enyeart (Wed, 10 Oct 2018 13:06:32 GMT):
1.4 - smaller “long term support" release - ship early-mid Dec, with an early beta targeting programming model additions - operational improvements - operational metrics - grpc monitoring - health checks for all components - improved logging - improve info messages, don’t require debug level to troubleshoot common problems, dynamic level setting, rational module and submodule breakdown) - programming model additions - SDK - chaincode - sdk and sample improvements, for both existing API and new programming model - samples such as balance transfer have been leading applications in the wrong direction. - samples should showcase good production practices such as utilizing discovery service, handling invalidations, load balancing and retries for orderers/peers becoming unavailable. - private data reconciliation (deliver the code-complete but deferred items from v1.3) - minimal hygiene work

dave.enyeart (Wed, 10 Oct 2018 13:06:32 GMT):
1.4 - smaller “long term support" release - ship early-mid Dec, with an early beta targeting programming model additions operational improvements - operational metrics - grpc monitoring - health checks for all components - improved logging - improve info messages, don’t require debug level to troubleshoot common problems, dynamic level setting, rational module and submodule breakdown) programming model additions - SDK - chaincode sdk and sample improvements, for both existing API and new programming model - samples such as balance transfer have been leading applications in the wrong direction. - samples should showcase good production practices such as utilizing discovery service, handling invalidations, load balancing and retries for orderers/peers becoming unavailable. private data reconciliation (deliver the code-complete but deferred items from v1.3) minimal hygiene work

dave.enyeart (Wed, 10 Oct 2018 13:06:46 GMT):
2.0 - large new items - end of 1Q19, with a more formal beta early on to get feedback on the new features - Raft orderer - Token - Lifecycle 2.0 - Local collections - Idemix revocation support - go based CLI - larger hygiene items, especially on peer side, e.g. validation refactoring, decouple go chaincode shim from fabric, removal of singletons

yacovm (Wed, 10 Oct 2018 13:18:41 GMT):
I would like to add FAB-11980 to v2.0 , it's a very low risk and easily containable item in v2.0, just adding a capability to chaincode to send messages via gossip :)

mbwhite (Wed, 10 Oct 2018 13:19:24 GMT):
@dave.enyeart could you confirm or deny if anything we (in Hursley) needs to be done for the node-chaincode, node-sdk to acheive the 1.3 release? i.

dave.enyeart (Wed, 10 Oct 2018 13:37:46 GMT):
@mbwhite we typically work with @bretharrison and @rameshthoomu to create the node.js release CRs and ensure proper tagging and npm pushes, so no action needed from your side unless you want to be active in the process.

bretharrison (Wed, 10 Oct 2018 13:40:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=yqjxdvbcDibwQswwp) @mbwhite I will work with Matthew on the required CR to prepare for the release

cbf (Wed, 10 Oct 2018 13:40:59 GMT):
https://tech.evojam.com/2016/05/19/gerrit-based-workflow-complete-developers-walkthrough/ is a pretty thorough gerrit tutorial and yes, we can handle feature branches, it isn't recommended, but we can handle a couple I think

cbf (Wed, 10 Oct 2018 13:41:23 GMT):
@dave.enyeart @mastersingh24 ^

dave.enyeart (Wed, 10 Oct 2018 22:34:33 GMT):
Today we released and tagged for v1.3.0 fabric, fabric-ca, fabric-chaincode-java, fabric-chaincode-node, fabric-sdk-node, fabric-samples.

dave.enyeart (Wed, 10 Oct 2018 22:35:16 GMT):
MERGE FREEZE in `release-1.3` branch over. I know you are all excited about fixing some defects for the eventual v1.3.1 already!

underbell (Thu, 11 Oct 2018 09:00:21 GMT):
Has joined the channel.

mastersingh24 (Thu, 11 Oct 2018 10:34:57 GMT):
Defects? We have defects?

yacovm (Thu, 11 Oct 2018 10:36:51 GMT):
must be a confusion with a different blockchain project

knagware9 (Thu, 11 Oct 2018 11:45:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=TDdwwTLXm2Bs3REXN) @mastersingh24 tried BYFN end to end test and balance transfer no issue as of now ...also tested with couch db ..now couch db connect in less time ..Thanks

dave.enyeart (Thu, 11 Oct 2018 12:18:16 GMT):
--------------------------------------------------- Fabric v1.3.0 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/topic/announcement_hyperledger/27240996?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,27240996 ---------------------------------------------------

mastersingh24 (Sat, 13 Oct 2018 11:00:36 GMT):
@dave.enyeart @cbf - thanks for the efforts getting the release out and of course thanks to all the maintainers and contributors for all the work during the release cycle! That's two releases in a row that were more or less on our 3 month schedule!

kostas (Tue, 16 Oct 2018 12:30:04 GMT):
Who has delete superpowers in JIRA, and how can I get some? I'm trying to maintain a clean house. Gracias.

yacovm (Tue, 16 Oct 2018 12:30:45 GMT):
@dave.enyeart I summon thee

kostas (Tue, 16 Oct 2018 12:31:13 GMT):
He lost them apparently, I summoned him privately about this as well.

cbf (Tue, 16 Oct 2018 12:39:55 GMT):
I can delete, which JIRAs need to be deleted?

cbf (Tue, 16 Oct 2018 12:41:03 GMT):
oops, nope, looks like I lost that superpower as well

cbf (Tue, 16 Oct 2018 12:41:23 GMT):
what you can do is withdraw

dave.enyeart (Tue, 16 Oct 2018 12:41:27 GMT):
I just opened a helpdesk ticket to get to the bottom of this...

dave.enyeart (Tue, 16 Oct 2018 12:41:27 GMT):
I just opened a helpdesk ticket to get to the bottom of this... perhaps Delete has been disabled project wide

cbf (Tue, 16 Oct 2018 12:41:36 GMT):
that closes with no action and you can specify a rationale

kostas (Tue, 16 Oct 2018 12:43:10 GMT):
It's most likely my OCD in action here, and I understand there are bigger fish to fry, but I do wish to delete. Sometimes we're reckless w/ how we created stories, and editing a story so as to unlink it with my good, semi-polished epic is actually more work than it should be. I should be able to 1-click (well, 2-click) delete.

kostas (Tue, 16 Oct 2018 12:43:10 GMT):
It's most likely my OCD in action here, and I understand there are bigger fish to fry, but I do wish to delete. Sometimes we're reckless w/ how we create stories, and editing a story so as to unlink it with my good, semi-polished epic is actually more work than it should be. I should be able to 1-click (well, 2-click) delete.

cbf (Tue, 16 Oct 2018 12:43:52 GMT):
@rjones @tkuhrt seems to me that when/before any administrative actions are taken, like removing some capability as above, that we should be notified and maybe even asked.

cbf (Tue, 16 Oct 2018 12:44:12 GMT):
I agree

cbf (Tue, 16 Oct 2018 12:44:32 GMT):
unless and until it becomes a problem, I don't see why we cannot delete JIRAs

cbf (Tue, 16 Oct 2018 12:45:07 GMT):
I can understand not allowing randos that capability, but maintainers have a certain responsibility

mastersingh24 (Tue, 16 Oct 2018 14:52:00 GMT):
are we sure that this was not the result of the custom changes we made? ;)

mastersingh24 (Tue, 16 Oct 2018 14:54:30 GMT):
it looks like it was omitted in the Fabric permissions scheme

rjones (Tue, 16 Oct 2018 15:51:10 GMT):
Not sure when it changed.

dave.enyeart (Tue, 16 Oct 2018 20:14:51 GMT):
My delete privilege was reinstated today. I'm ok doing deletes for the project, hopefully there shouldn't be many as it is often better to withdraw with some text describing why it is being withdrawn.

kostas (Tue, 16 Oct 2018 20:20:43 GMT):
Can we please give delete privileges to all maintainers? Not sure why this would be limited to a subset. /cc @rjones

rjones (Tue, 16 Oct 2018 22:13:58 GMT):
@kostas I think it was added to the maintainers group? I don't admin JIRA. @jwagantall ?

kostas (Tue, 16 Oct 2018 22:15:52 GMT):
@rjones: It is now - gracias!

AndrewNRise (Fri, 19 Oct 2018 08:21:15 GMT):
Has joined the channel.

mastersingh24 (Fri, 19 Oct 2018 11:18:40 GMT):
@rjones - would it be possible to add a new project under the Fabric moniker; we'd like to add `fabric-go` which will be the repository for the common Go library pkgs we use across the various Fabric projects. We'll start with adding the new common health check pkg and will also attempt to move the bccsp pkg out of the fabric repo. It would also be nice to have a `fabric-go` project in JIRA as well but not strictly required to start with

dave.enyeart (Fri, 19 Oct 2018 12:00:56 GMT):
@mastersingh24 how about calling it `fabric-common` ?

mastersingh24 (Fri, 19 Oct 2018 12:24:33 GMT):
well -- I think we should call it something with `go` because we may break out things in other languages as well .... looking at other projects, they tend to use the language in the repo

yacovm (Fri, 19 Oct 2018 12:25:47 GMT):
`fabric-gommon`

mastersingh24 (Fri, 19 Oct 2018 12:26:05 GMT):
LOL

mastersingh24 (Fri, 19 Oct 2018 12:26:07 GMT):
nice

yacovm (Fri, 19 Oct 2018 12:26:15 GMT):
or `fabric-gomon` as in go-monster because that's what it is

dave.enyeart (Fri, 19 Oct 2018 12:30:33 GMT):
to be consistent with our existing names it would be `fabric-common-go` right?

mastersingh24 (Fri, 19 Oct 2018 13:11:35 GMT):
`fabric-lib-go` seems better to me ... but frankly I just want a repo with `fabric` and `go` in it

jyellick (Fri, 19 Oct 2018 13:21:40 GMT):
+1 for `fabric-lib-go`

rameshthoomu (Fri, 19 Oct 2018 13:35:43 GMT):
fabric-go-lib

rjones (Fri, 19 Oct 2018 15:48:10 GMT):
@mastersingh24 if you want a new repo please file a help desk ticket: helpdesk@hyperledger.org and be explicit about permissions and merge (NACR, 2+2)

rjones (Fri, 19 Oct 2018 15:49:36 GMT):
fabric-lib-go seems like a good name, much like fabric-sdk-* if we add a new library it will sort nicely in the UI

mastersingh24 (Fri, 19 Oct 2018 16:24:46 GMT):
thx @rjones ... I forgot what I was supposed to do ;)

yuki-kon (Sat, 20 Oct 2018 00:19:53 GMT):
Has joined the channel.

yacovm (Sat, 20 Oct 2018 15:51:51 GMT):
what is going into `fabric-lib-go` @mastersingh24 ?

dave.enyeart (Sat, 20 Oct 2018 15:53:47 GMT):
I believe health check rest service that can be used across peer, orderer, fabric-ca. as well as bccsp so that it can be used across peer and fabric-ca.

mastersingh24 (Sat, 20 Oct 2018 19:04:03 GMT):
Yes ... the health check will be the first thing in there and time permitting we'll move bccsp there as well during this cycle. If not, we'll move it there for the v2.0.0 cycle

adc (Tue, 23 Oct 2018 05:38:13 GMT):
is the msp package also supposed to be moved?

mastersingh24 (Tue, 23 Oct 2018 12:05:12 GMT):
@adc ... no .. we won't move the MSP package ... just bccsp eventually. Of course we still need to refactor the MSP stuff for 2.0

cbf (Wed, 24 Oct 2018 11:02:16 GMT):
will be 30 mins late to the maintainer's meeting later this morning

cbf (Wed, 24 Oct 2018 12:42:05 GMT):
my call was moved, nevermind

dave.enyeart (Wed, 24 Oct 2018 12:57:54 GMT):
@here maintainer meeting at the top of the hour

dave.enyeart (Wed, 24 Oct 2018 12:58:00 GMT):
Agenda:

dave.enyeart (Wed, 24 Oct 2018 12:58:03 GMT):
v1.4 (2018 Q4 Release) Dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11429 v1.3 (October 10th) Retrospective: https://docs.google.com/document/d/1kB-M1sZifxbwIZXO5w79xJDkgFgOeFI4n-rR2AIAU0I/edit#

dave.enyeart (Wed, 24 Oct 2018 12:58:42 GMT):
https://zoom.us/my/hyperledger.community

cbf (Wed, 24 Oct 2018 13:01:43 GMT):
@simsc can you please make your dashboard and all of the queries used public access? I did this for the roadmap link I use to share all of the tracked releases https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104

gennadyl (Wed, 24 Oct 2018 13:05:32 GMT):
Has joined the channel.

dave.enyeart (Wed, 24 Oct 2018 18:49:18 GMT):
I forgot to mention on the maintainer call - we are hosting some playback demos for recent features: https://wiki.hyperledger.org/projects/fabric/playbacks

dave.enyeart (Wed, 24 Oct 2018 18:49:33 GMT):
Thursday is Service Discovery

dave.enyeart (Wed, 24 Oct 2018 18:49:51 GMT):
Next week we'll do State-based endorsement and Identity Mixer

dave.enyeart (Wed, 24 Oct 2018 18:50:03 GMT):
I'll also post on fabric-playbacks

dave.enyeart (Wed, 24 Oct 2018 18:52:01 GMT):
If anybody would like to do design reviews for upcoming features, or significant updates to already reviewed features (for v1.4, 2.0, etc), please add an entry to https://wiki.hyperledger.org/projects/fabric/playbacks

cagdast (Thu, 25 Oct 2018 07:49:51 GMT):
Has joined the channel.

mbwhite (Fri, 26 Oct 2018 12:29:35 GMT):
^ @dave.enyeart was just going to ask about that. I've added the 'Contract and Transaction Metadata' https://jira.hyperledger.org/browse/FAB-12071

dave.enyeart (Fri, 26 Oct 2018 12:48:27 GMT):
@mbwhite great, go ahead and pick a date

mbwhite (Fri, 26 Oct 2018 12:51:20 GMT):
Is thursday fixed for these or can it be any date?

dave.enyeart (Fri, 26 Oct 2018 18:33:36 GMT):
@mbwhite I see you picked Nov 8th, that works, but it doesn't have to be a Thursday, you could move to an earlier date if desired.

mbwhite (Tue, 30 Oct 2018 15:48:34 GMT):
thanks @dave.enyeart suspect we'll need to move the date actually.

mbwhite (Tue, 30 Oct 2018 15:49:10 GMT):
We're seeing quite a few build failures at present - sdk and chaincode for zOS.. blocking CRs... is this a known issue?

dave.enyeart (Tue, 30 Oct 2018 16:11:52 GMT):
you mean the daily failures on s390? yes those are being worked. do you need s390 for a playback/beta?

mbwhite (Tue, 30 Oct 2018 16:30:39 GMT):
No; but it's preventing merging of CRs (Job builder is a -1)

14gracel (Wed, 31 Oct 2018 09:51:35 GMT):
I'm trying to merge a cleanup PR into https://github.com/fabric-sdk-node/fabric-sdk-node.github.io/pull/2 since the files are no longer necessary and aren't removed as part of the build. Does anyone have write access?

yacovm (Wed, 31 Oct 2018 11:10:02 GMT):
@14gracel we use gerrit for pull requests

14gracel (Wed, 31 Oct 2018 11:11:23 GMT):
@yacovm As far as I know we cant use gerrit to merge direct doc changes?

yacovm (Wed, 31 Oct 2018 11:24:35 GMT):
We can!

yacovm (Wed, 31 Oct 2018 11:24:42 GMT):
I think....

yacovm (Wed, 31 Oct 2018 11:24:58 GMT):
Oh it's github.io...

yacovm (Wed, 31 Oct 2018 11:25:10 GMT):
Sorry my bad i didnt look at the link

rjones (Wed, 31 Oct 2018 13:32:19 GMT):
@14gracel please fix DCO on your copy in your repo and force push

rjones (Wed, 31 Oct 2018 13:32:30 GMT):
s/copy/fork

14gracel (Wed, 31 Oct 2018 13:45:21 GMT):
Cheers @rjones

14gracel (Wed, 31 Oct 2018 14:42:25 GMT):
@rjones I do not have permission to force push, or am I misunderstanding what I need to do? Ive fixed the commit

rjones (Wed, 31 Oct 2018 14:43:43 GMT):
what I'm saying is this. update your repo on your machine and force push to your repo. you should absolutely have that permission in your own space. you will need to have done a `git commit --amend -s` to the top commit to get the signature in the right place

14gracel (Wed, 31 Oct 2018 14:58:43 GMT):
Thanks for clarifying. I was trying to force push directly to the main repo rather than my fork. PR is ready to be merged

rjones (Wed, 31 Oct 2018 19:48:53 GMT):
@14gracel uh - that repo is actually outside of hyperledger :( I have no control over it.

rjones (Wed, 31 Oct 2018 19:49:39 GMT):
@14gracel your commit, I think, needs to go into gerrit? I don't know who forked that repo

dave.enyeart (Wed, 31 Oct 2018 20:44:38 GMT):
@bretharrison can you comment on https://github.com/fabric-sdk-node/fabric-sdk-node.github.io ...where is that content sourced from?

mbwhite (Thu, 01 Nov 2018 09:53:51 GMT):
@dave.enyeart the content comes from the sdk build (likewise with the shim apis) docs; the build has access to push stuff there.... but we don't know who the 'human' is that would have access to it as well.

aso (Thu, 01 Nov 2018 17:30:38 GMT):
https://gerrit.hyperledger.org/r/#/c/20529/ already with a +2 and +1

tkuhrt (Thu, 01 Nov 2018 18:52:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=Loy2uP7b5fbBddrrb) @cbf : I personally think delete permissions on Jira are a bad idea, but that could be because one of the bugs I opened on one of our projects was deleted. That is definitely not the right way to handle closing a bug. I hope that this group thinks long and hard before deleting bugs that were created by someone else.

cbf (Thu, 01 Nov 2018 20:02:27 GMT):
we can close with no action now, so...

aso (Sat, 03 Nov 2018 10:15:24 GMT):
pls another +2 for https://gerrit.hyperledger.org/r/#/c/25311/

aso (Sat, 03 Nov 2018 10:15:31 GMT):
it's already got a +1 and +2

DirkKrueger (Sat, 03 Nov 2018 13:59:40 GMT):
Has joined the channel.

awes0menessInc (Tue, 06 Nov 2018 03:38:29 GMT):
Has joined the channel.

aso (Tue, 06 Nov 2018 09:02:33 GMT):
pls another +2 for https://gerrit.hyperledger.org/r/#/c/20533/

mbwhite (Tue, 06 Nov 2018 15:04:13 GMT):
@dave.enyeart I can't do this Thursday for the metadata playback... I'll move it to next week if that's ok

dave.enyeart (Tue, 06 Nov 2018 15:06:07 GMT):
@mbwhite go ahead and update the wiki with your new date

enriquebusti (Wed, 07 Nov 2018 12:01:34 GMT):
Has joined the channel.

aso (Wed, 07 Nov 2018 13:03:31 GMT):
another +2 for https://gerrit.hyperledger.org/r/#/c/20987/ pls...

dave.enyeart (Wed, 07 Nov 2018 13:56:36 GMT):
@here Fabric maintainer meeting in 5 minutes: https://zoom.us/my/hyperledger.community

matthewphamilton (Wed, 07 Nov 2018 15:21:17 GMT):
Has joined the channel.

odowdaibm (Thu, 08 Nov 2018 19:09:57 GMT):
The tutorial doc https://gerrit.hyperledger.org/r/c/26813/ and fabric-sample tutorial https://gerrit.hyperledger.org/r/c/27168/ are also ready for +2 -- been tried out by lots of users and really important for 1.4 beta users to try out new SDK functionality. Thanks for a +2 on these please!

odowdaibm (Thu, 08 Nov 2018 19:10:08 GMT):
Would appreciate +2s for the following very straightforward doc changes please -- thanks: https://gerrit.hyperledger.org/r/c/26306/ and https://gerrit.hyperledger.org/r/c/26051/

odowdaibm (Thu, 08 Nov 2018 19:10:53 GMT):
Sorry to ask for 4, but folks have been very busy I know and I'm struggling to build incremental advances on these docs and sample without a merge. Ty again!

jwagantall (Fri, 09 Nov 2018 19:03:39 GMT):
@here Heads up, we will pause Jenkins in 45 mins to upgrade it to the latest LTS and upgrade the OpenStack plugin. The current API being used it will deprecate soon and we need to upgrade. Thanks! This should take about 30 mins

jwagantall (Fri, 09 Nov 2018 20:03:17 GMT):
@here Jenkins upgrade is happening right now.. thanks!

jwagantall (Fri, 09 Nov 2018 20:20:05 GMT):
@here Jenkins upgrade is now completed.. Thanks!

SamRasha (Mon, 12 Nov 2018 09:44:04 GMT):
Has joined the channel.

kostas (Tue, 13 Nov 2018 21:37:37 GMT):
Can someone remind me where we store the Dockerfiles for our third party images?

dave.enyeart (Tue, 13 Nov 2018 21:52:48 GMT):
@kostas https://github.com/hyperledger/fabric-baseimage/tree/master/images

dave.enyeart (Wed, 14 Nov 2018 23:33:28 GMT):
Congratulations @aso on becoming the latest maintainer! Glad to see merit rewarded. https://gerrit.hyperledger.org/r/#/c/27559/. @rjones could you do your magic with the maintainer permissions?

sh777 (Thu, 15 Nov 2018 02:50:52 GMT):
Has joined the channel.

rjones (Thu, 15 Nov 2018 05:26:20 GMT):
@dave.enyeart please send email to helpdesk@hyperledger.org

rjones (Thu, 15 Nov 2018 05:26:35 GMT):
With those details

BellaAdams (Sat, 17 Nov 2018 00:46:03 GMT):
Has joined the channel.

huxiangdong (Tue, 20 Nov 2018 00:33:28 GMT):
Has joined the channel.

marryton007 (Tue, 20 Nov 2018 08:19:39 GMT):
Hi, guys, Does anybody know how to debug or trace the source code of fabric, I used dlv to do it, but I met the problem about "debug_frame". it describes by the following URL https://manios.org/2018/10/05/metricbeat-debug-frame-section-error. I use dlv 1.1.0 and go 1.11.2, and I notice that fabric 1.2.1 need go 1.10.x to compile. So, I met a hard problem, any suggestion is appreciative.

jyellick (Tue, 20 Nov 2018 15:08:40 GMT):
@marryton007 You might want to talk with @john-philipp who has been attempting a similar exercise. I believe go 1.11, debuggers, and go plugins (which fabric uses) do not interact nicely. The development go v1.12 seems to have better support. I think you will find that many go developers stay away from the go debuggers, but best of luck in your endeavors.

john-philipp (Tue, 20 Nov 2018 15:08:41 GMT):
Has joined the channel.

john-philipp (Tue, 20 Nov 2018 16:17:40 GMT):
@marryton007: in case this is still an issue. :) Yes, apparently importing the wrong packages into your code breaks (as in completely disables) the debugger... This was/is an issue from versions `>1.9` and is only resolved in `v1.12` which is still under development. :] So we install from source and stay on master: (follow https://golang.org/doc/install/source) (you'll need Go `v1.4+` to install Go from source) Once you're done check your go version, and make sure it is marked as `devel` Now `go get github.com/derekparker/delve/cmd/dlv` And in vscode add the following configuration: ``` { "name": "peer node start", "type": "go", "request": "launch", "mode": "debug", // "program": "go/src/github.com/hyperledger/fabric/orderer", "program": "go/src/github.com/hyperledger/fabric/peer", "env": {"FABRIC_CFG_PATH": "there be keys here"}, "args": ["node", "start"] }, ``` Set a breakpoint in `peer/main.go` (as a simple example) and "Start debugging". _Should_ work. In terms of config, you can cheat and copy it from the docker containers (usually /etc/hyperledger/...). However, I'd just build some scripts to generate consistent config. Notably, this very much does *not* let you debug the docker containers, that requires remote debugging which I am working on now. Anyway, let me know if you run into any issues.

Rajatsharma (Wed, 21 Nov 2018 06:52:34 GMT):
Has joined the channel.

Rajatsharma (Wed, 21 Nov 2018 06:52:48 GMT):
Hello, I'm trying to run the sample System Chaincode following the steps on https://hyperledger-fabric.readthedocs.io/en/release-1.3/systemchaincode.html - I've used the example chaincode (https://github.com/hyperledger/fabric/tree/release-1.3/examples/plugins/scc). I copied this to the peer after building it on Go. and made the necassary changes at /etc/hyperledger/fabric/core.yaml. But there are no logs or no response when I restart the peer. Can anyone please help me with the process.

marryton007 (Wed, 21 Nov 2018 06:53:55 GMT):
@john-philipp I can debug peer on a Linux VM now. Yes, it need to build the master branch of GO, and rebuild delve with the latest version of GO. I also tried installing delve into the docker container and enable remote debug, but it can't work now.

marryton007 (Wed, 21 Nov 2018 06:54:49 GMT):
Below is my Dockefile: FROM hyperledger/fabric-peer:1.2.1 ENV GOPATH /opt/gopath ENV GOROOT /opt/go ENV PATH $GOROOT/bin:$GOPATH/bin:$PATH ENV FABRIC_CFG_PATH /etc/hyperledger/fabric WORKDIR $GOPATH COPY go $GOROOT/bin/go COPY dlv $GOPATH/bin/dlv COPY peer /usr/local/bin CMD ["peer","node","start"]

marryton007 (Wed, 21 Nov 2018 06:55:37 GMT):
The error message: API server listening at: [::]:2345 could not launch process: could not find external debug info file

marryton007 (Wed, 21 Nov 2018 06:55:52 GMT):
docker-compose file of peer service:

marryton007 (Wed, 21 Nov 2018 06:56:32 GMT):
command: dlv --headless --listen=:2345 --api-version=2 exec /usr/local/bin/peer -- node start

marryton007 (Wed, 21 Nov 2018 07:01:22 GMT):

peer-debug.zip

marryton007 (Wed, 21 Nov 2018 08:41:40 GMT):
@john-philipp It works fine with docker now. I can use goland or vscode to connect and debug now! You should copy the latest dlv and peer into docker image, just like the Dockefile desribes.

john-philipp (Wed, 21 Nov 2018 12:06:22 GMT):
Indeed. :)

john-philipp (Wed, 21 Nov 2018 12:06:22 GMT):
@marryton007 Indeed. :)

dave.enyeart (Wed, 21 Nov 2018 13:35:47 GMT):
@here Due to multiple people out of office for the US holiday, maintainer meeting is moved to November 28th, and will resume every other week cadence from there.

mbwhite (Wed, 21 Nov 2018 13:40:26 GMT):
Have a good holiday :-)

dave.enyeart (Wed, 21 Nov 2018 13:40:28 GMT):
I will remind everybody to keep v1.4 close down in mind. We are targeting a release candidate in early December and GA in mid-December. Large functional changes should be avoided at this time. Lower risk changes like metrics and health checks should continue. Please keep up on CR reviews and reviewing Bug backlogs

dave.enyeart (Wed, 21 Nov 2018 13:41:30 GMT):
Thanks @mbwhite , and thanks for holding the fort down the next few days :)

QwertyJack (Sun, 25 Nov 2018 08:42:27 GMT):
Hi there ! When will v1.4 release ? Thanks.

mastersingh24 (Sun, 25 Nov 2018 10:23:28 GMT):
@QwertyJack - should be before XMas

JonathanLevi (Mon, 26 Nov 2018 18:53:44 GMT):
Good morning/evening, after-noon...

JonathanLevi (Mon, 26 Nov 2018 18:53:57 GMT):
Hope everybody had good holidays, etc.

JonathanLevi (Mon, 26 Nov 2018 18:54:36 GMT):
The master branch *may* have been broken (unit tests), but finally began to work for me on all platforms after the latest merge.

yacovm (Mon, 26 Nov 2018 18:54:57 GMT):
what is broken?

JonathanLevi (Mon, 26 Nov 2018 18:55:04 GMT):
FWIW, just fetch the latest. Not sure why the CI didn't get it.

yacovm (Mon, 26 Nov 2018 18:55:27 GMT):
what's the error?

JonathanLevi (Mon, 26 Nov 2018 18:57:47 GMT):
I posted it here: https://gerrit.hyperledger.org/r/#/c/27381/

JonathanLevi (Mon, 26 Nov 2018 18:58:19 GMT):
It was broken, I suspect. Tried on 3 systems and received the exact same error

JonathanLevi (Mon, 26 Nov 2018 18:58:29 GMT):
Works now

yacovm (Mon, 26 Nov 2018 19:00:08 GMT):
@adc

yacovm (Mon, 26 Nov 2018 19:00:08 GMT):
@adc ^

aso (Mon, 26 Nov 2018 20:07:22 GMT):
ouch... at least after merging that, bccsp tests are passing

aso (Mon, 26 Nov 2018 20:07:35 GMT):
https://jenkins.hyperledger.org/job/fabric-merge-x86_64/5017/console ```19:27:16 ok github.com/hyperledger/fabric/bccsp/idemix 8.629s coverage: 89.7% of statements 19:28:15 ok github.com/hyperledger/fabric/bccsp/idemix/bridge 67.315s coverage: 96.9% of statements 19:28:15 ok github.com/hyperledger/fabric/bccsp/idemix/handlers 0.268s coverage: 97.4% of statements ```

aso (Mon, 26 Nov 2018 21:21:51 GMT):
I re-ran unit tests on https://gerrit.hyperledger.org/r/#/c/27381/ - success

dave.enyeart (Tue, 27 Nov 2018 20:40:35 GMT):
@here As you know we are entering shutdown for release v1.4. Please join maintainer call tomorrow 9am US Eastern so that we can review where we are and make any final decisions. We’ve been doing a good job of keeping up with function and integration test as we go, which has enabled us to work fairly late in the cycle, but we need to close down. Here’s the week-by-week plan: - Nov 26th (week of) - merge final dev CRs; focus on bugs and system test - Dec 3rd (week of) - stabilize; continued focus on bugs; complete system test priorities; finish upgrade doc and test; write release notes and any other remaining doc. - Dec 10th (target Monday) - release candidate; complete any remaining system tests against the release candidate this week. - Dec 17th (target Monday) - final v1.4 release We will need all hands on deck to ensure that we hit these dates. That includes help reviewing bug and CR backlogs in your component areas this week. See the v1.4 and ‘Needs Triage’ defect widgets on the right side of the release dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11429 I plan to resume fabric-scrum dialogs starting from Thursday until we have shipped the release.

dave.enyeart (Tue, 27 Nov 2018 20:40:35 GMT):
@here As you know we are entering shutdown for release v1.4. Please join maintainer call tomorrow 9am US Eastern so that we can review where we are and make any final decisions. We’ve been doing a good job of keeping up with function and integration test as we go, which has enabled us to work fairly late in the cycle, but we need to close down. Here’s the week-by-week plan: - Nov 26th (week of) - merge final dev CRs; focus on bugs and system test - Dec 3rd (week of) - stabilize; continued focus on bugs; complete system test priorities; finish upgrade doc and test; write release notes and any other remaining doc. - Dec 10th (target Monday) - release candidate (RC1); complete any remaining system tests against the release candidate this week. - Dec 17th (target Monday) - final v1.4 release We will need all hands on deck to ensure that we hit these dates. That includes help reviewing bug and CR backlogs in your component areas this week. See the v1.4 and ‘Needs Triage’ defect widgets on the right side of the release dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11429 I plan to resume fabric-scrum dialogs starting from Thursday until we have shipped the release.

skarim (Tue, 27 Nov 2018 21:05:07 GMT):
Has joined the channel.

dave.enyeart (Tue, 27 Nov 2018 21:06:31 GMT):
As we've done before, when reviewing bugs make your best judgement of FixVersion v1.4.0 or v2.0.0 or Future. I've scanned the list and it seems most can be deferred or changed to enhancements (Stories), but we'll need the experts in each area to make those calls and then we can review any that are in question.

dave.enyeart (Wed, 28 Nov 2018 12:44:10 GMT):
The Fabric live download script is broken, I've pushed a fix: https://gerrit.hyperledger.org/r/#/c/27778/

dave.enyeart (Wed, 28 Nov 2018 12:52:59 GMT):
@cbf What are your thoughts on an automated test for bootstrap.sh so that it does not get broken again?

mbwhite (Wed, 28 Nov 2018 13:55:26 GMT):
@dave.enyeart on the Script itself.. I've seen feedback from other projects, that the use of link shorteners isn't preferred - as people can't see exactly what they might be downloading. One for consideration..

dave.enyeart (Wed, 28 Nov 2018 13:56:05 GMT):
Yes, that's been my concern as well, but I believe @cbf wanted the download metrics

mbwhite (Wed, 28 Nov 2018 13:56:32 GMT):
..which is one of great things about bit.ly

mbwhite (Wed, 28 Nov 2018 13:57:15 GMT):
what's the dial in info for the maintainers call?

dave.enyeart (Wed, 28 Nov 2018 13:58:58 GMT):
@here maintainer meeting starting: https://zoom.us/my/hyperledger.community

sheehan (Wed, 28 Nov 2018 14:43:32 GMT):
@dave.enyeart - for archive/pruning mentioned in the meeting, is there an epic or existing design doc? Also, what is Artem's RC username?

dave.enyeart (Wed, 28 Nov 2018 15:08:15 GMT):
Artem is @C0rWin , Jira is https://jira.hyperledger.org/browse/FAB-106. I believe Artem started a google doc after the Fabric maintainers meeting in February

C0rWin (Wed, 28 Nov 2018 16:43:38 GMT):
@sheehan a few months ago I have shared preliminary draft with @binhn

dave.enyeart (Wed, 28 Nov 2018 17:31:42 GMT):
The fix for the download script: https://gerrit.hyperledger.org/r/#/c/27782/

dave.enyeart (Wed, 28 Nov 2018 21:20:15 GMT):
There is yet another issue with the download script... we'll have to revert to how it was before the issues: https://gerrit.hyperledger.org/r/#/c/27791/

dave.enyeart (Wed, 28 Nov 2018 21:49:12 GMT):
merged

haggis (Thu, 29 Nov 2018 08:08:15 GMT):
Has joined the channel.

JonathanLevi (Thu, 29 Nov 2018 14:16:19 GMT):
Wait, is Artem @C0rWin ?!?

JonathanLevi (Thu, 29 Nov 2018 14:17:17 GMT):
So all these years of me praising Artem in @C0rWin 's window/chat.... dude, you should have said something ;-)

JonathanLevi (Thu, 29 Nov 2018 14:18:14 GMT):
---- Can somebody please help us with a quick fix here: https://gerrit.hyperledger.org/r/#/c/27777/

JonathanLevi (Thu, 29 Nov 2018 14:18:37 GMT):
Both Angelo and I ran it locally to double-check. Thanks.

C0rWin (Thu, 29 Nov 2018 14:22:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=KdKeoQvLjc24zyto8) @JonathanLevi :joy:

C0rWin (Thu, 29 Nov 2018 14:24:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=66xQMmT5XtLwfhBRA) @JonathanLevi This explains me now, why you referred to me in third person while we were chatting, all these years :)

dave.enyeart (Thu, 29 Nov 2018 14:56:53 GMT):
@here Fabric playback on 'interop test' starting in 5 minutes. See announcement and call info in #fabric-scrum .

dave.enyeart (Thu, 29 Nov 2018 14:57:16 GMT):
We can use all maintainers help in driving our test strategy.

dave.enyeart (Thu, 29 Nov 2018 14:57:25 GMT):
And in general, we could use help from all maintainers to facilitate fabric-scrum discussion. We WILL do release candidate in one week... so don't delay brining anything up...

JonathanLevi (Thu, 29 Nov 2018 16:46:23 GMT):
For the love of wet water...

JonathanLevi (Thu, 29 Nov 2018 16:46:28 GMT):
https://gerrit.hyperledger.org/r/#/c/27777/

JonathanLevi (Thu, 29 Nov 2018 16:46:38 GMT):
;-)

jyellick (Fri, 30 Nov 2018 04:24:37 GMT):
Looks like master currently fails to build with a linter error: ```# github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr [github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr.test] core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr/txmgr_test.go:1272:6: no new variables on left side of := make: *** [Makefile:205: linter] Error 2 ``` https://gerrit.hyperledger.org/r/c/27835/ should resolve it, but any CRs currently going through CI will likely need to be rebased

JonathanLevi (Fri, 30 Nov 2018 05:34:37 GMT):
Jason, pls feel free to +2 it. I will merge.

manish-sethi (Fri, 30 Nov 2018 05:35:20 GMT):
I did it just now - thanks

JonathanLevi (Fri, 30 Nov 2018 05:35:32 GMT):
Great.

JonathanLevi (Fri, 30 Nov 2018 05:42:24 GMT):
BTW: any idea how it happened ?

JonathanLevi (Fri, 30 Nov 2018 05:42:52 GMT):
How was this merged without the ":"

manish-sethi (Fri, 30 Nov 2018 05:43:20 GMT):
Some change must have been merged between this cr passing the tests and merging.

JonathanLevi (Fri, 30 Nov 2018 05:44:53 GMT):
Yeah, so it seems... and the CI let it happen, even though it is a clear "no go".

JonathanLevi (Fri, 30 Nov 2018 05:45:39 GMT):
Just to confirm, this was not a case of two different Cars passing soerately and then the merge "kept" the extra ":", right?

JonathanLevi (Fri, 30 Nov 2018 05:48:18 GMT):
[ Context: There are a few ongoing threads regarding the CI/CDs these days, so if there is more stuff we should bring up, it may be a good time to report. Thanks and good night ]

binhn (Sat, 01 Dec 2018 16:07:32 GMT):
came across an interesting blog using Fabric https://www.itransition.com/blog/hyperledger-fabric-blockchain-payments-problems-and-solutions

Rajatsharma (Sat, 01 Dec 2018 20:00:36 GMT):
Other than the documentation is there any other source a beginner can go through, to learn all the basic concepts of Fabric.

JonathanLevi (Sun, 02 Dec 2018 05:54:34 GMT):
While #fabric-questions may be a better channel for such a question, let me answer quickly. In addition to documentation, there are also code samples in the fabric-samples folder. Other than this, some of us vendors provide courses and classes. Take a look at the Linux Foundation's "Fabric Fundamentals"... or some other classes by other training partners. Hope this helps... but if you have a follow up question, pls let's switch to the other rocketchat channel.

JonathanLevi (Tue, 04 Dec 2018 11:00:30 GMT):
----

JonathanLevi (Tue, 04 Dec 2018 11:01:29 GMT):
Fellow maintainers, a quick suggestion. Even more so in the coming days, due to some issues with the official build on the CIs, let's be a bit extra prudent/patient.

yacovm (Tue, 04 Dec 2018 11:02:26 GMT):
what issues?

JonathanLevi (Tue, 04 Dec 2018 11:02:43 GMT):
While Gerrit does not allow us (most of the time) to merge CRs without two +2... we can also wait a bit for a build to complete before the first +2.

yacovm (Tue, 04 Dec 2018 11:03:36 GMT):
what's the concern?

JonathanLevi (Tue, 04 Dec 2018 11:06:19 GMT):
It's good practice to check first that a CR compiles before approving it.

JonathanLevi (Tue, 04 Dec 2018 11:07:13 GMT):
I know that we don't always do it, but these coming days we should try to be more careful.

JonathanLevi (Tue, 04 Dec 2018 11:08:00 GMT):
If it is really hard to resist then don't allow this suggestion to stop you ;-)

dave.enyeart (Tue, 04 Dec 2018 15:35:15 GMT):
Sure we can do that. My larger concern is that stale CRs don't get merged. If you see an older CR I'd recommend `Rebase` and `Run VerifyBuild`. Note that tomorrow there is a playback scheduled for CI improvements. Ramesh will propose going back to the auto-rebuild after Rebase to address this concern, among other things.

dave.enyeart (Tue, 04 Dec 2018 15:35:24 GMT):
See playback schedule here: https://wiki.hyperledger.org/projects/fabric/playbacks

dave.enyeart (Tue, 04 Dec 2018 15:35:38 GMT):
I will also post to mailing list today

dave.enyeart (Tue, 04 Dec 2018 15:36:16 GMT):
Although for CI it's probably the maintainers that are most interested... please try to attend. Wednesday 10am US Eastern.

JonathanLevi (Tue, 04 Dec 2018 17:57:25 GMT):
Is master broken ?

JonathanLevi (Tue, 04 Dec 2018 17:58:18 GMT):
Irrespective of the HSM and the new token...

JonathanLevi (Tue, 04 Dec 2018 17:58:50 GMT):
Can others try a fresh build and unit tests pls?

JonathanLevi (Tue, 04 Dec 2018 17:59:14 GMT):
(thanks)

kostas (Tue, 04 Dec 2018 18:08:31 GMT):
@JonathanLevi: Which package is failing for your specifically?

JonathanLevi (Tue, 04 Dec 2018 18:12:39 GMT):
There are 7 more commits in Fabric master and now HCR-HF-JOB1/build_logs/MSB-HF-JOB1-49.log build.04-Dec-2018 18:28:35 FAIL github.com/hyperledger/fabric/core/chaincode 67.245s

JonathanLevi (Tue, 04 Dec 2018 18:13:00 GMT):
Pls ignore the first line. Our CI is very talkative ;-)

yacovm (Tue, 04 Dec 2018 18:13:13 GMT):
does it fail consistently?

JonathanLevi (Tue, 04 Dec 2018 18:13:38 GMT):
Twice. We are running on two more platforms

JonathanLevi (Tue, 04 Dec 2018 18:13:47 GMT):
This is why I am asking others to try too, pls

JonathanLevi (Tue, 04 Dec 2018 18:14:09 GMT):
Making sure that j havenlr lost my mind.

JonathanLevi (Tue, 04 Dec 2018 18:14:44 GMT):
Checking, may be a better verb. Checking whether I have lost my mind ;-)

kostas (Tue, 04 Dec 2018 18:36:31 GMT):
@JonathanLevi: All unit tests pass successfully on the current tip (`6c3895c4e`) on my localhost.

kostas (Tue, 04 Dec 2018 18:36:31 GMT):
@JonathanLevi: All unit tests pass successfully on the current tip (6c3895c4e) on my localhost.

JonathanLevi (Tue, 04 Dec 2018 18:37:40 GMT):
Thank you @kostas . Running a super clean build.

JonathanLevi (Tue, 04 Dec 2018 19:42:10 GMT):
Using Vagrant?

JonathanLevi (Tue, 04 Dec 2018 19:42:39 GMT):
So, FWIW, having spent almost a day on this:

JonathanLevi (Tue, 04 Dec 2018 19:42:55 GMT):
Everything passed completely at revision 6c3895c4eec36be9813668fdd86e85b483b4802c for me

JonathanLevi (Tue, 04 Dec 2018 19:43:17 GMT):
Inside vagrant... ONLY if I run this:

JonathanLevi (Tue, 04 Dec 2018 19:43:40 GMT):
*sudo mkdir -p /var/lib/softhsm/tokens*

JonathanLevi (Tue, 04 Dec 2018 19:43:50 GMT):
----

JonathanLevi (Tue, 04 Dec 2018 19:44:29 GMT):
Maybe it is a "human error" and/or maybe I am tired... but I am sharing, just in case any/some of you experience anything similar.

JonathanLevi (Tue, 04 Dec 2018 19:45:25 GMT):
Without the tokens directory, some of these builds really go to town.

JonathanLevi (Tue, 04 Dec 2018 19:46:31 GMT):
----

JonathanLevi (Tue, 04 Dec 2018 19:46:50 GMT):
Taking a break, but maybe it will help any lost soul out there/here

sykesm (Tue, 04 Dec 2018 22:35:20 GMT):
So, I think we need to revert the PKCS11 changes made in FABCI-227 and FAB-12670. I don't view those as successful. Not only is it making a mess of my local builds, it's forcing a rebase of all pending CRs to accommodate the changes made in the build environment.

sykesm (Tue, 04 Dec 2018 22:36:10 GMT):
rationale in https://jira.hyperledger.org/browse/FAB-13164

arjitkhullar (Wed, 05 Dec 2018 00:03:54 GMT):
Has joined the channel.

dave.enyeart (Wed, 05 Dec 2018 02:54:49 GMT):
I'm good with reverting, but the revert CR FAB-13164 https://gerrit.hyperledger.org/r/#/c/27934/ also has unit test failures. And then the question after reverting is how to resolve the original issue that FAB-12670 tried to address.

dave.enyeart (Wed, 05 Dec 2018 04:42:29 GMT):
In general unit test is really flakely these days... let's take advantage of the quiet period before v1.4 ship and resolve some of the recent flakes (if you dont have any defects to work...)

JonathanLevi (Wed, 05 Dec 2018 06:00:58 GMT):
Even though I am one of the guys who pushed to merge the latest changes the moment the CI build passed, I tend to agree.

JonathanLevi (Wed, 05 Dec 2018 06:02:26 GMT):
I, and others, have spent a full day on trying to figure out wwhats causing the softhsm side effects, that required `token` directory was surprising and it feels like a patch that will merrit more patches.

JonathanLevi (Wed, 05 Dec 2018 06:04:56 GMT):
@dave.enyeart If it is easier, I can also "revert" while fixing the UT, with a follow up CR or in the same CR. Let's discuss (with the developers and the CI team, the systems guys, etc.) and see what's the best course of action, and I can throw more cycles on it.

JonathanLevi (Wed, 05 Dec 2018 06:05:41 GMT):
These are definitely good days for cleaning and stabilizing.

JonathanLevi (Wed, 05 Dec 2018 06:07:05 GMT):
I want to find out, this morning, why was the softhsm introduced right now, and whether it is really needed.

JonathanLevi (Wed, 05 Dec 2018 06:07:56 GMT):
I want to find out, this morning, why was the softhsm introduced right now, and whether it is really needed in this shape and form.

JonathanLevi (Wed, 05 Dec 2018 06:09:21 GMT):
But in a line, I agree with @sykesm (Matthew). This is just the first 24 hours since our merge.

dave.enyeart (Wed, 05 Dec 2018 13:22:00 GMT):
Could I ask all maintainers to take a look at #fabric and #fabric-questions occasionally. It seems only Gari, Yacov, and myself are in there. I usually scan it once a day, it only takes a few minutes, and it really helps to understand how people are using Fabric and where the pain points are. I try to point people to docs or samples rather than get into lengthy discussions. If there is nothing to point to in one of your areas of responsibility, please help to improve the doc in that area.

mbwhite (Wed, 05 Dec 2018 13:39:26 GMT):
@dave.enyeart fyi could add me to the meeting invite for the maintainers calls please?

JonathanLevi (Wed, 05 Dec 2018 13:45:04 GMT):
Amigo maintainers... apologies, my OCD kicked in and it needs addressing.

JonathanLevi (Wed, 05 Dec 2018 13:45:22 GMT):
Things are off with the master branch

JonathanLevi (Wed, 05 Dec 2018 13:45:44 GMT):
In addition to the softhsm

JonathanLevi (Wed, 05 Dec 2018 13:46:22 GMT):
Can others take another look

JonathanLevi (Wed, 05 Dec 2018 13:46:29 GMT):
Commit 8d14cfcdf8303dfc6a44164ead8f88f4ce08cadf broke the test - FAIL github.com/hyperledger/fabric/orderer/consensus/etcdraft 60.935s

JonathanLevi (Wed, 05 Dec 2018 13:46:58 GMT):
I am now automating a bit more...

C0rWin (Wed, 05 Dec 2018 13:47:01 GMT):
do you have specific error?

JonathanLevi (Wed, 05 Dec 2018 13:49:40 GMT):
Let me run with a log

JonathanLevi (Wed, 05 Dec 2018 13:49:55 GMT):
Go reports memory corruption issues there

JonathanLevi (Wed, 05 Dec 2018 13:50:08 GMT):
Mind trying ?

yacovm (Wed, 05 Dec 2018 13:50:24 GMT):
memory corruption....? :worried:

yacovm (Wed, 05 Dec 2018 13:51:30 GMT):
is that in CI @JonathanLevi or a local test run?

C0rWin (Wed, 05 Dec 2018 13:54:40 GMT):
just run on my local machine etcdraft tests and got ```SUCCESS! -- 66 Passed | 0 Failed | 0 Pending | 0 Skipped```

C0rWin (Wed, 05 Dec 2018 13:54:45 GMT):
@JonathanLevi ^^^

dave.enyeart (Wed, 05 Dec 2018 14:15:41 GMT):
I've seen intermittent failures in etcdraft unit test as well. I just merged https://gerrit.hyperledger.org/r/#/c/27943/ , hopefully that will help.

dave.enyeart (Wed, 05 Dec 2018 14:16:26 GMT):
Here's a recent unit test failure I've seen:

dave.enyeart (Wed, 05 Dec 2018 14:16:31 GMT):
https://jenkins.hyperledger.org/job/fabric-verify-unit-tests-x86_64/6818/console

dave.enyeart (Wed, 05 Dec 2018 14:16:46 GMT):
@kostas

JonathanLevi (Wed, 05 Dec 2018 14:19:39 GMT):
Can I attach a file?

JonathanLevi (Wed, 05 Dec 2018 14:24:15 GMT):
Mailed you. Re-running the latest too

JonathanLevi (Wed, 05 Dec 2018 14:24:54 GMT):
Can rocket chat not support attachments? Or am I just getting old?

JonathanLevi (Wed, 05 Dec 2018 14:25:11 GMT):
Please answer only the first part !

JonathanLevi (Wed, 05 Dec 2018 14:25:21 GMT):
:grimacing:

JonathanLevi (Wed, 05 Dec 2018 15:00:02 GMT):
----

JonathanLevi (Wed, 05 Dec 2018 15:00:02 GMT):
Lastest build works.

JonathanLevi (Wed, 05 Dec 2018 15:00:12 GMT):
Thank you Dave and Kostas

dave.enyeart (Wed, 05 Dec 2018 15:00:49 GMT):
@here Fabric CI meeting starting: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Thu, 06 Dec 2018 11:27:44 GMT):
Everybody - please help to keep Jira clean (developer and component lead and merger). I'm spending too much time chasing down Jiras with incorrect information, for example bugs that are merged but not marked Done. Having correct status, correct FixVersion, and a link to the CR helps more than you can imagine. Also as we merge bug fixes, for critical ones that could impact existing customers, consider a backport to v1.3 or v1.2. If the code (or doc) in a certain area has not changed much since v1.3, it could be as simple as hitting the Cherry Pick button in Gerrit and specifying release-1.3. The FixVersion should then be updated to indicate 1.4.0,1.3.1 (the next 3rd digit release will be 1.3.1... you can figure it out by looking at tags... if latest tag is v1.3.0 that means the next fix pack is v1.3.1). As the releases pile up, having this discipline will pay dividends many times over.

dave.enyeart (Thu, 06 Dec 2018 11:27:44 GMT):
Everybody - please help to keep Jira clean (developer and component lead and merger). I'm spending too much time chasing down Jiras with incorrect information, for example bugs that are merged but not marked Done. Having correct status, correct FixVersion, and a link to the CR helps more than you can imagine. Also as we merge bug fixes, for critical ones that could impact existing users, consider a backport to v1.3 or v1.2. If the code (or doc) in a certain area has not changed much since v1.3, it could be as simple as hitting the Cherry Pick button in Gerrit and specifying release-1.3. The FixVersion should then be updated to indicate 1.4.0,1.3.1 (the next 3rd digit release will be 1.3.1... you can figure it out by looking at tags... if latest tag is v1.3.0 that means the next fix pack is v1.3.1). As the releases pile up, having this discipline will pay dividends many times over.

JonathanLevi (Fri, 07 Dec 2018 14:50:16 GMT):
----

JonathanLevi (Fri, 07 Dec 2018 14:50:52 GMT):
Since it's a Friday: did anyone had any issues (after) upgrading to the latest vagrant ?

JonathanLevi (Fri, 07 Dec 2018 14:50:52 GMT):
Since it's a Friday: have anyone had any issues (after) upgrading to the latest vagrant ?

JonathanLevi (Fri, 07 Dec 2018 14:50:54 GMT):
A new version of Vagrant is available: 2.2.2

JonathanLevi (Fri, 07 Dec 2018 14:50:54 GMT):
*A new version of Vagrant is available: 2.2.2*

dave.enyeart (Fri, 07 Dec 2018 14:54:34 GMT):
I think most people have moved away from vagrant as the native build generally works well

dave.enyeart (Fri, 07 Dec 2018 14:55:54 GMT):
We are getting close to a merge freeze on Monday for RC1... be careful and judicious with your merges between now and Monday...

dave.enyeart (Mon, 10 Dec 2018 03:47:19 GMT):
Looks we we'll be ready for RC1 on Monday. I'll announce merge freeze when we start.

dave.enyeart (Mon, 10 Dec 2018 03:48:18 GMT):
@here please review What's New for v1.4 doc: https://gerrit.hyperledger.org/r/#/c/27998/ https://logs.hyperledger.org/production/vex-yul-hyp-jenkins-3/fabric-docs-build-x86_64/1104/html/whatsnew.html Generated doc

dave.enyeart (Mon, 10 Dec 2018 03:49:25 GMT):
We didn't call out Long Term Support release by name, but advised that it is the release for production operations.

dave.enyeart (Mon, 10 Dec 2018 03:49:25 GMT):
We didn't call out Long Term Support release by name, but advised that it is the recommended release for production operations.

dave.enyeart (Mon, 10 Dec 2018 03:51:04 GMT):
That's open for discussion...

dave.enyeart (Mon, 10 Dec 2018 03:51:04 GMT):
That's open for discussion here...

dave.enyeart (Mon, 10 Dec 2018 03:51:04 GMT):
Using LTS label is open for discussion here...

dave.enyeart (Mon, 10 Dec 2018 04:02:40 GMT):
Personally I didn't think we should use LTS label until we have a specific LTS definition/policy in place

dave.enyeart (Mon, 10 Dec 2018 04:02:40 GMT):
Personally I didn't think we should use LTS label until we have a specific LTS definition/policy in place. We can always call it LTS later.

mbwhite (Mon, 10 Dec 2018 09:31:51 GMT):
+1 to that @dave.enyeart

dave.enyeart (Mon, 10 Dec 2018 10:18:16 GMT):
https://gerrit.hyperledger.org/r/#/c/27883/ upgrade doc has been reviewed by multiple people, could somebody merge please?

dave.enyeart (Mon, 10 Dec 2018 10:18:16 GMT):
~https://gerrit.hyperledger.org/r/#/c/27883/ upgrade doc has been reviewed by multiple people, could somebody merge please?~

rameshthoomu (Mon, 10 Dec 2018 13:02:39 GMT):
@cbf @mastersingh24 Could you pls review these changes. Below changes publishes two digit (1.4) docker tag (multiarch) to dockerhub https://gerrit.hyperledger.org/r/#/c/28010/ https://gerrit.hyperledger.org/r/#/c/28009/ https://gerrit.hyperledger.org/r/#/c/27917/

JonathanLevi (Mon, 10 Dec 2018 14:31:19 GMT):
Merged 27883. @cbf and @mastersingh24 - I took a look at the 3 CRs above from @rameshthoomu

JonathanLevi (Mon, 10 Dec 2018 14:31:46 GMT):
They all seem pretty trivial. No change to the process, other than adding a new variable (for the two digit version)

JonathanLevi (Mon, 10 Dec 2018 14:32:06 GMT):
Upgrading the VERSION to "1.3" (from 1.2)

JonathanLevi (Mon, 10 Dec 2018 14:32:09 GMT):
and,

JonathanLevi (Mon, 10 Dec 2018 14:32:41 GMT):
Adding the multiarch script also to the *fabric-chaincode-java*

JonathanLevi (Mon, 10 Dec 2018 14:32:45 GMT):
Not risky to merge

JonathanLevi (Mon, 10 Dec 2018 14:32:45 GMT):
Not risky to merge - reverify-ing https://gerrit.hyperledger.org/r/#/c/27917/

JonathanLevi (Mon, 10 Dec 2018 14:32:45 GMT):
In the meantime, reverify-ing https://gerrit.hyperledger.org/r/#/c/27917/

dave.enyeart (Mon, 10 Dec 2018 14:45:35 GMT):
yeah, the question is are we all good with having a two digit tag in dockerhub. e.g. so that people can pull v1.3 and always get the latest 3rd digit release in v1.3.x stream.

dave.enyeart (Mon, 10 Dec 2018 14:46:18 GMT):
i don't know if there is a precedent for or against that in other projects

dave.enyeart (Mon, 10 Dec 2018 18:19:49 GMT):
ok, two digit tags have been merged.

dave.enyeart (Mon, 10 Dec 2018 18:21:00 GMT):
@here I believe we are ready for MERGE FREEZE. Waiting to hear back from @odowdaibm on whether he expects a fabcar tutorial doc update today

dave.enyeart (Mon, 10 Dec 2018 18:21:28 GMT):
In the meantime you can review the fabric release CR: https://gerrit.hyperledger.org/r/#/c/28050/

dave.enyeart (Mon, 10 Dec 2018 18:21:42 GMT):
Release notes are more substantial this time around, please take a look.

dave.enyeart (Tue, 11 Dec 2018 06:55:13 GMT):
fabric and fabric-ca v1.4.0-rc1 released. fabric release-1.4 branch created. fabric release-1.4 is open for critical release defect fixes. fabric master is open for 2.0.0 development. MERGE FREEZE over for fabric. on Tuesday we will do node sdk, node chaincode, java chaincode, fabric-samples, and announce

dave.enyeart (Tue, 11 Dec 2018 06:55:13 GMT):
fabric and fabric-ca v1.4.0-rc1 released. release-1.4 branches created. release-1.4 is open for critical release defect fixes. master is open for 2.0.0 development. MERGE FREEZE over for fabric and fabric-ca. on Tuesday we will do node sdk, node chaincode, java chaincode, fabric-samples, and announce

JonathanLevi (Tue, 11 Dec 2018 08:03:57 GMT):
@dave.enyeart Very well done. The smoothest Fabric release/release candidate to date. Thanks for all the hard work (you and everyone here)

cbf (Tue, 11 Dec 2018 08:30:59 GMT):
;-)

lehors (Tue, 11 Dec 2018 13:45:33 GMT):
@dave.enyeart shouldn't fabric-samples also be tagged?

dave.enyeart (Tue, 11 Dec 2018 14:19:48 GMT):
yes. we'll do it after the node and chaincode releases today.

dave.enyeart (Tue, 11 Dec 2018 14:19:48 GMT):
yes. we'll do it after the sdk and chaincode releases today.

dave.enyeart (Tue, 11 Dec 2018 14:55:52 GMT):
Need one more +2 on the fabcar sample updates: https://gerrit.hyperledger.org/r/#/c/28038/

dave.enyeart (Tue, 11 Dec 2018 14:56:35 GMT):
in a nutshell, there are now three variants: 1) javascript new programming model 2) typescript new programming model 3) javascript low-level programming model using fabric-client

dave.enyeart (Tue, 11 Dec 2018 14:57:19 GMT):
the Writing Your First App tutorial will focus on # 1

dave.enyeart (Tue, 11 Dec 2018 15:36:30 GMT):
Thanks @lehors the corresponding doc CR is https://gerrit.hyperledger.org/r/#/c/27824/

lehors (Tue, 11 Dec 2018 15:36:42 GMT):
thanks

lehors (Tue, 11 Dec 2018 15:37:42 GMT):
fyi, I've been testing on my old Windows 7 box and so far all is good :)

kostas (Tue, 11 Dec 2018 18:15:32 GMT):
How do we cut 1.4? Do we cherry-pick items on 1.4-rc1, or do we cut from master again?

yacovm (Tue, 11 Dec 2018 18:23:20 GMT):
we cherry pick from master into v1.4 branch

yacovm (Tue, 11 Dec 2018 18:23:57 GMT):
every CR that you want to be in v1.4 GA should be pushed to master and cherry picked to v1.4 branch

dave.enyeart (Tue, 11 Dec 2018 18:58:27 GMT):
and then we cut from release-1.4 branch

dave.enyeart (Tue, 11 Dec 2018 19:08:52 GMT):
updated fabcar tutorial that uses new programming model... has been reviewed/tested by multiple people, ready for merge:

dave.enyeart (Tue, 11 Dec 2018 19:08:56 GMT):
https://gerrit.hyperledger.org/r/#/c/27824/ master

dave.enyeart (Tue, 11 Dec 2018 19:09:15 GMT):
https://gerrit.hyperledger.org/r/#/c/28079/ release-1.4

dave.enyeart (Tue, 11 Dec 2018 20:11:30 GMT):
@here a little help from my friends ^^^^

dave.enyeart (Wed, 12 Dec 2018 13:30:58 GMT):
@here maintainers meeting in 30 minutes: https://zoom.us/my/hyperledger.community

dave.enyeart (Wed, 12 Dec 2018 14:01:40 GMT):
@here maintainer meeting starting

dave.enyeart (Wed, 12 Dec 2018 17:43:48 GMT):
one sentence update in docs about SDK compatibility: https://gerrit.hyperledger.org/r/#/c/28123/ https://gerrit.hyperledger.org/r/#/c/28129/

dave.enyeart (Wed, 12 Dec 2018 17:56:58 GMT):
Final piece of the release is to align samples. We are aligning with 1.4.0-rc1 chaincode shim and 1.4.0-rc2 node sdk: https://gerrit.hyperledger.org/r/#/c/28092/

dave.enyeart (Wed, 12 Dec 2018 18:17:52 GMT):
@here ^^^^^^ Need some help from others with cbf and mastersigh24 traveling

dave.enyeart (Wed, 12 Dec 2018 18:21:09 GMT):
Thanks @yacovm ! I'll tag and then do a final test, then we'll be ready to announce

yacovm (Wed, 12 Dec 2018 18:21:41 GMT):
you can also close the JIRA

yacovm (Wed, 12 Dec 2018 18:21:41 GMT):
you can also close the JIRA (in my stead)

dave.enyeart (Wed, 12 Dec 2018 18:22:02 GMT):
:)

dave.enyeart (Wed, 12 Dec 2018 20:30:46 GMT):
--------------------------------------------------- Fabric v1.4.0 RELEASE CANDIDATE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/topic/announcement_hyperledger/28735908 ---------------------------------------------------

Thomas-tuo (Mon, 17 Dec 2018 06:51:45 GMT):
Has joined the channel.

dave.enyeart (Tue, 18 Dec 2018 03:30:09 GMT):
Final system tests for Fabric v1.4 has identified a few issues that are currently being resolved. We expect to release a rc2 this week with the final updates. Pending results of rc2 testing, a final v1.4 release can then be expected at the beginning of January.

sykesm (Wed, 19 Dec 2018 14:58:59 GMT):
For those that are still around, I submitted 20 CR's last night to remove dead code; no new function. Of those, half or more failed in unit test due to flakes; of those that were resubmitted, half failed again. We need to focus on fixing these flakes. https://jira.hyperledger.org/issues/?filter=12178

mbwhite (Wed, 19 Dec 2018 15:38:29 GMT):
https://gerrit.hyperledger.org/r/#/c/28294/ Is an update to the x509 library for the node chaincode

yacovm (Wed, 19 Dec 2018 15:39:24 GMT):
@mbwhite `&> #fabric-pr-review `

dave.enyeart (Wed, 19 Dec 2018 16:28:42 GMT):
@sykesm Thank you for keeping the pressure on the flakes and providing the query. @kostas and @C0rWin can I ask you to drive the raft and gossip flakes with your teams respectively.

dave.enyeart (Wed, 19 Dec 2018 16:28:42 GMT):
@sykesm Thank you for keeping the pressure on the flakes and providing the query. It absolutely is unacceptable to have such a high unit test failure rate. @kostas and @C0rWin can I ask you to drive the raft and gossip flakes with your teams respectively.

kostas (Wed, 19 Dec 2018 16:44:25 GMT):
Already on it.

dave.enyeart (Wed, 19 Dec 2018 20:08:04 GMT):
Thanks @kostas and @C0rWin !

dave.enyeart (Wed, 19 Dec 2018 20:08:09 GMT):
We ALL need to apply more rigor around flakes, even the innocent victims of unit test failures. We will only improve the situation if we are vigilant about opening Jira bugs for flakes: When you see a unit test failure in one of your CRs, query Jira for the test name string to see if it has already been opened as a bug (the test name is usually a searchable unique string). If a flake bug is already opened in Jira - add a comment stating that you’ve seen it again. If this is the 2nd or 3rd time seen, go ahead and change bug priority to High. If a flake bug is not yet opened, please open a new bug with the following information - Put the test name in the Summary - Copy/paste the failure snippet into description - Fill in component (we will rely on component owners to triage) - Add label `flakes`. If the problem is seen in CI rather than a CR unit test, add label `ci_failure`

dave.enyeart (Wed, 19 Dec 2018 20:08:09 GMT):
We ALL need to apply more rigor around flakes, even the innocent victims of unit test failures. We will only improve the situation if we are vigilant about opening Jira bugs for flakes: When you see a unit test failure in one of your CRs - copy/paste the error message to a gerrit comment as you do `Run UnitTest` - query Jira for the test name string to see if it has already been opened as a bug (the test name is usually a searchable unique string). If a flake bug is already opened in Jira - add a comment stating that you’ve seen it again. If this is the 2nd or 3rd time seen, go ahead and change bug priority to High. If a flake bug is not yet opened, please open a new bug with the following information - Put the test name in the Summary - Copy/paste the failure snippet into description - Fill in component (we will rely on component owners to triage) - Add label `flakes`. If the problem is seen in CI rather than a CR unit test, add label `ci_failure`

dave.enyeart (Wed, 19 Dec 2018 20:08:09 GMT):
We ALL need to apply more rigor around flakes, even the innocent victims of unit test failures. We will only improve the situation if we are vigilant about opening Jira bugs for flakes: When you see a unit test failure in one of your CRs - copy/paste the error message to a gerrit comment as you do `Run UnitTest` - query Jira for the test name string to see if it has already been opened as a bug (the test name is usually a searchable unique string). If a flake bug is already opened in Jira - add a comment stating that you’ve seen it again. If this is the 2nd or 3rd time seen, go ahead and change bug priority to High. If a flake bug is not yet opened, please open a new bug with the following information - Put the test name in the Summary - Copy/paste the failure snippet into description - Fill in component (we will rely on component owners to triage) - Add label `flakes`. If the problem is seen in CI rather than a CR unit test, also add label `ci_failure`

dave.enyeart (Wed, 19 Dec 2018 20:08:09 GMT):
We ALL need to apply more rigor around flakes, even the innocent victims of unit test failures. We will only improve the situation if we are vigilant about opening Jira bugs for flakes: When you see a unit test failure in one of your CRs - copy/paste the error message to a gerrit comment as you do `Run UnitTest` - query Jira for the test name string to see if it has already been opened as a bug (the test name is usually a searchable unique string). If a flake bug is already opened in Jira - add a comment stating that you’ve seen it again. If this is the 2nd or 3rd time seen, go ahead and change bug priority to High. Worst offenders and blockers should get Highest. If a flake bug is not yet opened, please open a new bug with the following information - Put the test name in the Summary - Copy/paste the failure snippet into description - Fill in component (we will rely on component owners to triage) - Add label `flakes`. If the problem is seen in CI rather than a CR unit test, also add label `ci_failure`

dave.enyeart (Wed, 19 Dec 2018 20:08:09 GMT):
We ALL need to apply more rigor around flakes, even the innocent victims of unit test failures. We will only improve the situation if we are vigilant about opening Jira bugs for flakes: When you see a unit test failure in one of your CRs - copy/paste the error message to a gerrit comment as you do `Run UnitTest` - query Jira for the test name string to see if it has already been opened as a bug (the test name is usually a searchable unique string). If a flake bug is already opened in Jira - add a comment stating that you’ve seen it again. If this is the 2nd or 3rd time seen, go ahead and change bug priority to High. Worst offenders and blockers should get Highest. If a flake bug is not yet opened, please open a new bug with the following information - Put the test name in the Summary - Copy/paste the failure snippet into description - Fill in component (we will rely on component owners to triage) - Add label `flakes`. If the problem is seen in other CI rather than a CR unit test, also add label `ci_failure`

dave.enyeart (Wed, 19 Dec 2018 20:11:22 GMT):
Any other thoughts?

sambhavdutt (Wed, 19 Dec 2018 20:49:52 GMT):
Has joined the channel.

vijay.bP (Wed, 19 Dec 2018 20:54:24 GMT):
Has joined the channel.

C0rWin (Wed, 19 Dec 2018 21:31:29 GMT):
@dave.enyeart working to reduce gossip flakes :/

dave.enyeart (Thu, 20 Dec 2018 01:43:25 GMT):
Latest system tests in release-1.4 branch have had good results. We plan to cut v1.4.0-rc2 from release-1.4 branch on Thursday. We will include fabric, fabric-ca, fabric-chaincode-java, fabric-chaincode-node, and fabric-samples. Note that fabric-sdk-node already has a rc2. @C0rWin and @mbwhite you can prepare release CRs in release-1.4 branch for java and node chaincode.

rameshthoomu (Thu, 20 Dec 2018 01:44:39 GMT):
Ok

rameshthoomu (Thu, 20 Dec 2018 01:44:53 GMT):
I updated only chanincode-java

rameshthoomu (Thu, 20 Dec 2018 01:45:02 GMT):
But sure will send in few hours

mbwhite (Thu, 20 Dec 2018 10:34:51 GMT):
@dave.enyeart the CR is ready and waiting; as are CRs for the x509 locking to v0.3.3 for all releases.

dave.enyeart (Thu, 20 Dec 2018 14:04:28 GMT):
Release process starting for v1.4.0-rc2.

dave.enyeart (Thu, 20 Dec 2018 14:04:44 GMT):
MERGE FREEZE in `release-1.4` branch only

dave.enyeart (Thu, 20 Dec 2018 14:04:58 GMT):
I'll post updates in #fabric-release today

dave.enyeart (Thu, 20 Dec 2018 14:26:22 GMT):
@here I'm not sure if @cbf is available today... any other volunteer want to volunteer to be release buddy today? Review release CRs, try out the images, etc.

dave.enyeart (Thu, 20 Dec 2018 14:26:22 GMT):
@here I'm not sure if @cbf is available today... any other volunteer want to to be release buddy today? Review release CRs, try out the images, etc.

dave.enyeart (Thu, 20 Dec 2018 14:27:39 GMT):
I can educate you on the release ~hacks~ magic

lehors (Thu, 20 Dec 2018 14:30:03 GMT):
@dave.enyeart I'm happy to help as much as I can but I have limited availability - with the time difference I have to deal with family stuff at various points in time

dave.enyeart (Thu, 20 Dec 2018 14:30:18 GMT):
and you can't +2 regardless :(

lehors (Thu, 20 Dec 2018 14:30:24 GMT):
on the other hand I can test on Mac, Windows 7, and Ubuntu :)

lehors (Thu, 20 Dec 2018 14:30:40 GMT):
ah, indeed, that I can't do

dave.enyeart (Thu, 20 Dec 2018 14:30:55 GMT):
that would be great... could use your help on windows... i'll mention you when images are ready

lehors (Thu, 20 Dec 2018 14:30:57 GMT):
I thought you only meant for testing

muralisr (Thu, 20 Dec 2018 17:06:50 GMT):
@dave.enyeart let me know what you need and if within my scope for helping...

dave.enyeart (Thu, 20 Dec 2018 22:37:37 GMT):
@here need one final +2 to finish off v1.4.0-rc2: https://gerrit.hyperledger.org/r/#/c/28338/

dave.enyeart (Thu, 20 Dec 2018 23:12:34 GMT):
All done folks...

dave.enyeart (Thu, 20 Dec 2018 23:12:36 GMT):
--------------------------------------------------- Fabric v1.4.0 RELEASE CANDIDATE 2 ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/topic/announcement_hyperledger/28815938 ---------------------------------------------------

mbwhite (Fri, 21 Dec 2018 08:44:46 GMT):
:clap:

mbwhite (Fri, 21 Dec 2018 16:37:41 GMT):
I'm troubled by https://gerrit.hyperledger.org/r/#/c/28349/ failing on x86 merge build but the other 3 builds succeding... this is the 1.1.5 shim release... Any thoughts from anybody would be most welcome.

mbwhite (Fri, 21 Dec 2018 16:49:18 GMT):
Ignore the above - 3rd respin of the same build it worked....

merq (Sat, 22 Dec 2018 03:45:52 GMT):
Has joined the channel.

dave.enyeart (Sat, 22 Dec 2018 13:27:17 GMT):
There's been some good progress around fixing unit test flakes. @C0rWin @kostas and all, as you and your teams fix flakes in master, go ahead and cherry pick to release-1.4. As we will likely support v1.4 for a long time, we'd like to keep it free from flakes as well.

dave.enyeart (Sat, 22 Dec 2018 13:28:31 GMT):
Same goes for doc improvements... please do CRs in master and cherry pick to release-1.4 while the files are still in sync.

dave.enyeart (Sat, 22 Dec 2018 13:30:07 GMT):
Concerning fabric-samples, I still haven't created a release-1.4 branch. Sample improvements can be made in master only for now. I'll create the fabric-samples release-1.4 branch upon final cut of v1.4.0.

dave.enyeart (Sat, 22 Dec 2018 13:31:25 GMT):
Note that fabric-samples is however already tagged for v1.4.0-rc2 (this is required for our install and upgrade scripts to work correctly)

rjones (Mon, 31 Dec 2018 05:37:18 GMT):
I would appreciate your assistance in getting these changes merged: https://gerrit.hyperledger.org/r/#/q/owner:%22Ry+Jones%22+status:open I suspect all of the remaining CI failures are due to rigging, not the changes themselves. Changes to repos without CI setup will need V+1 manually set. Thank you.

mastersingh24 (Mon, 31 Dec 2018 14:23:38 GMT):
trying to increase your commit rate @rjones? LOL

mastersingh24 (Mon, 31 Dec 2018 14:29:35 GMT):
@rjones - merged all the ones I can

grapebaba (Mon, 31 Dec 2018 16:14:41 GMT):
Hi maintainers, we proposal a fabric management system https://docs.google.com/document/d/1DoxDzUIGyfnecEeWQDNXSc-cy7s32Cn2CaRjKQDV6f4

grapebaba (Mon, 31 Dec 2018 16:15:13 GMT):
would love you guys support

rjones (Mon, 31 Dec 2018 16:18:56 GMT):
Thank you, @mastersingh24

greg2git (Mon, 31 Dec 2018 18:01:10 GMT):
Has joined the channel.

rjones (Mon, 31 Dec 2018 21:49:34 GMT):
One more for fabric-sdk-py: https://gerrit.hyperledger.org/r/#/c/28424/

gongliaoan (Wed, 02 Jan 2019 09:06:36 GMT):
Has joined the channel.

dave.enyeart (Thu, 03 Jan 2019 14:44:40 GMT):
Release update for v1.4. We are waiting for some people to return from vacation Friday/Monday before we do final v1.4.0 release.

dave.enyeart (Thu, 03 Jan 2019 14:47:12 GMT):
We are looking at some final sdk compatibility test results. Any other known issues before we release v1.4.0?

dave.enyeart (Thu, 03 Jan 2019 14:56:16 GMT):
Please review proposed LTS wording:

dave.enyeart (Thu, 03 Jan 2019 14:56:16 GMT):
Please review proposed LTS wording (provided by cbf):

dave.enyeart (Thu, 03 Jan 2019 14:56:21 GMT):
```Hyperledger Fabric v1.4 marks our first Long Term Support release (https://en.wikipedia.org/wiki/Long-term_support). Our policy to date has been to provide bug fix (patch) releases for our most recent major or minor release until the next major or minor release has been published. We plan to continue this policy for subsequent releases. However, for v1.4.0, we are pledging to provide bug fixes for a period of one year from the date of release (insert date). This will likely result in a series of patch releases (v1.4.1, v1.4.2, …), where multiple fixes are bundled into a patch release. If you are running with Hyperledger Fabric v1.4.x, you can be assured that you will be able to safely upgrade to any of the subsequent patch releases. In the advent that there is need of some upgrade process to remedy a defect, we will provide that process with the patch release. As for eventually upgrading to the 2.0 release series, we will ensure that you can safely do so from any of the 1.4.x patch releases, however we may require that you serially upgrade minor versions of 2.x series releases.```

dave.enyeart (Thu, 03 Jan 2019 21:18:34 GMT):
See #fabric-pr-review : https://chat.hyperledger.org/channel/fabric-pr-review?msg=yXhtiHmWaDLRHqMsp , need to get these fabric-samples CRs merged and CI working well before we create fabric-samples release-1.4 branch as part of v1.4.0 release

pasimoes (Fri, 04 Jan 2019 15:51:35 GMT):
Has joined the channel.

BellaAdams (Mon, 07 Jan 2019 06:36:45 GMT):
how to become the maintainer of Fabric

BellaAdams (Mon, 07 Jan 2019 06:37:07 GMT):
I want to develop Fabric Go sdk

BellaAdams (Mon, 07 Jan 2019 06:37:32 GMT):
I want to make the Fabric Go sdk better

yacovm (Mon, 07 Jan 2019 07:17:10 GMT):
@BellaAdams ask also in #fabric-sdk-go

sstone1 (Mon, 07 Jan 2019 11:29:03 GMT):
@dave.enyeart the last paragraph is vague as to what you will be able to safely upgrade; is it everything, the ledger data, chaincode/smart contracts, applications - what? I suspect with the SDKs we may take the opportunity to make breaking changes inbetween v1.4 and v2.0.

dave.enyeart (Mon, 07 Jan 2019 12:56:55 GMT):
@sstone1 How about we simply remove the last sentence:

dave.enyeart (Mon, 07 Jan 2019 12:56:59 GMT):
`````` Hyperledger Fabric v1.4 marks our first Long Term Support release (https://en.wikipedia.org/wiki/Long-term_support). Our policy to date has been to provide bug fix (patch) releases for our most recent major or minor release until the next major or minor release has been published. We plan to continue this policy for subsequent releases. However, for v1.4.0, we are pledging to provide bug fixes for a period of one year from the date of release (insert date). This will likely result in a series of patch releases (v1.4.1, v1.4.2, …), where multiple fixes are bundled into a patch release. If you are running with Hyperledger Fabric v1.4.x, you can be assured that you will be able to safely upgrade to any of the subsequent patch releases. In the advent that there is need of some upgrade process to remedy a defect, we will provide that process with the patch release.``` ```

dave.enyeart (Mon, 07 Jan 2019 12:56:59 GMT):
``` Hyperledger Fabric v1.4 marks our first Long Term Support release (https://en.wikipedia.org/wiki/Long-term_support). Our policy to date has been to provide bug fix (patch) releases for our most recent major or minor release until the next major or minor release has been published. We plan to continue this policy for subsequent releases. However, for v1.4.0, we are pledging to provide bug fixes for a period of one year from the date of release (insert date). This will likely result in a series of patch releases (v1.4.1, v1.4.2, …), where multiple fixes are bundled into a patch release. If you are running with Hyperledger Fabric v1.4.x, you can be assured that you will be able to safely upgrade to any of the subsequent patch releases. In the advent that there is need of some upgrade process to remedy a defect, we will provide that process with the patch release.```

sstone1 (Mon, 07 Jan 2019 13:26:31 GMT):
:+1: works for me

bestbeforetoday (Tue, 08 Jan 2019 10:38:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=dMbk3KAdbiGAWB7ja) @BellaAdams It's worth noting that you can go ahead and contribute fixes and improvements without being a maintainer. Maintainer is just required to review/approve changes going in to the codebase. Perhaps a good idea to talk to the maintainers about any proposed changes first though

cbf (Tue, 08 Jan 2019 16:02:30 GMT):
all, some of us have been discussing the gerrit backlog, which seems to be perpetually in arrears. The idea we came up with was to institute a policy and some tooling to help us manage the backlog in an objective manner - to provide for a means of automating the abandonment of CRs and comments that are repeatedly ignored and to help us ensure that as CRs come in from the broader community that they are receiving the attention they deserve

cbf (Tue, 08 Jan 2019 16:02:50 GMT):
here is the proposed language (I will share on the mailing list as well):

cbf (Tue, 08 Jan 2019 16:02:55 GMT):
=========

cbf (Tue, 08 Jan 2019 16:02:57 GMT):
Here's some proposed language for a proposed policy on Gerrit CRs. Feedback welcomed. As the Fabric project has grown, so too has the backlog of open CRs. One problem that nearly all projects face is managing that backlog effectively, and Fabric is no exception. In an effort to keep the backlog of Fabric and related project CRs manageable, we are proposing to introduce a policy to be enforced by a set of bots similarly to the manner in which other large projects manage their CR backlog. ----- Proposed CR Aging Policy The Fabric project maintainers will automatically monitor all CR activity for delinquency. If a CR has not been updated in 2 weeks, a reminder comment will be added requesting that the CR be either updated to address any outstanding comments, or abandoned if it is to be withdrawn. If a delinquent CR goes another 2 weeks without an update, it will be automatically abandoned. If a CR has aged more than 2 months since it was originally submitted, even if it has activity, it will be flagged for maintainer review. If a submitted CR has passed all validation but has not been reviewed in 48 hours, it will be flagged to the #fabric-pr-review channel daily until it receives a review comment(s). This policy applies to all official Fabric projects (fabric, fabric-ca, fabric-samples, fabric-test, fabric-sdk-node, fabric-sdk-java, fabric-chaincode-node, fabric-chaincode-java, fabric-chaincode-evm, fabric-baseimage, and fabric-amcl).

cbf (Tue, 08 Jan 2019 16:03:02 GMT):
==========

cbf (Tue, 08 Jan 2019 16:03:15 GMT):
comments welcomed

yacovm (Tue, 08 Jan 2019 16:13:33 GMT):
can we automate the 2 weeks warning?

dave.enyeart (Tue, 08 Jan 2019 16:24:16 GMT):
We are starting release process for v1.4.0. Announcing MERGE FREEZE. We'll take it slow so that we can publish on Wednesday. There is some press lined up for Thursday.

dave.enyeart (Tue, 08 Jan 2019 16:24:16 GMT):
We are starting release process for v1.4.0. Announcing MERGE FREEZE in release-1.4 branches. We'll take it slow so that we can publish on Wednesday. There is some press lined up for Thursday.

dave.enyeart (Tue, 08 Jan 2019 16:24:47 GMT):
master remains open for 2.0 business.

dave.enyeart (Tue, 08 Jan 2019 18:54:27 GMT):
We will reiterate the Help Wanted query during maintainer call tomorrow. I've done a quick review to remove outdated items. Please tag any known work items with `help-wanted` prior to the call please.

dave.enyeart (Tue, 08 Jan 2019 18:54:30 GMT):
https://jira.hyperledger.org/issues/?filter=10147

dave.enyeart (Tue, 08 Jan 2019 18:54:30 GMT):
https://jira.hyperledger.org/issues/?filter=10147 Help Wanted query as advertised in RTD: https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#fixing-issues-and-working-stories

rjones (Tue, 08 Jan 2019 19:19:42 GMT):
@yacovm Gerrit has a robust automation interface.

rjones (Tue, 08 Jan 2019 19:20:17 GMT):
@yacovm if it could run on Heroku for $7 a month, even as a cron job, there's probably money for it somewhere

cbf (Tue, 08 Jan 2019 19:35:16 GMT):
oops, I didn't paste in the modified version was supposed to be 72 hours (3 days) note also that as with all things, there can be flexibility when warranted (long weekends, holidays etc)

JonathanLevi (Tue, 08 Jan 2019 22:14:17 GMT):
Any objections to me merging something on fabric-ca ?

JonathanLevi (Tue, 08 Jan 2019 22:14:32 GMT):
We aren't in a full code-freeze ON, I take it?

JonathanLevi (Tue, 08 Jan 2019 22:14:51 GMT):
Not my CR, but some improvements to error codes, that can/could be useful.

JonathanLevi (Tue, 08 Jan 2019 22:23:19 GMT):
(Please ignore these ^^^) ;-)

JonathanLevi (Tue, 08 Jan 2019 22:25:51 GMT):
Have just merged a set of improvements to the fabric-ca. But either way, if we are setting a hard code-freeze (between now and Thu), please feel free to shout it.

yacovm (Tue, 08 Jan 2019 22:30:19 GMT):
72 hours for notification?

yacovm (Tue, 08 Jan 2019 22:30:44 GMT):
72 hours....?

yacovm (Tue, 08 Jan 2019 22:30:53 GMT):
for notification?

yacovm (Tue, 08 Jan 2019 22:32:38 GMT):
72 hours for what? until an idle CR will be reminded to be updated?

BellaAdams (Wed, 09 Jan 2019 06:11:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=RDGZx9P5TqJRNeJwz) @bestbeforetoday I got it. Thanks

JonathanLevi (Wed, 09 Jan 2019 06:57:26 GMT):
(in the spirit of the new year...) @BellaAdams in fact, sometimes we wonder whether the Fabric community and the other maintainers chose to nominate and vote to support our promotions to a maintainer status, just because they wanted us to deal with more maintenance, so that we code less ;-) Jokes aside, feel free to code, chat about features, open JIRA items, submit CRs... get bashed a bit when/if you are wrong, learn, improve, push, etc... this is a very inclusive project and any type of contribution (even if people being with feedback/questions) - are really welcome!

BellaAdams (Wed, 09 Jan 2019 08:24:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=bWHa6DeWLDy557kkL) @JonathanLevi I am very glad to do some contribution

raviranjan14 (Wed, 09 Jan 2019 12:45:37 GMT):
Has joined the channel.

dave.enyeart (Wed, 09 Jan 2019 13:03:39 GMT):
@here maintainer meeting in one hour, here's the agenda items I know about: Fabric v1.4.0 release scheduled for tomorrow: See Long-term support wording above Fabric roadmap: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11705 Chaincode refactoring - community involvement @sykesm @binhn, e.g. https://jira.hyperledger.org/browse/FAB-13582 helped-wanted items: https://jira.hyperledger.org/issues/?filter=10147 Aging CR policy - see proposal above from @cbf Fabric management proposal (@grapebaba) - https://docs.google.com/document/d/1DoxDzUIGyfnecEeWQDNXSc-cy7s32Cn2CaRjKQDV6f4/edit

dave.enyeart (Wed, 09 Jan 2019 13:03:39 GMT):
@here maintainer meeting in one hour, here's the agenda items I know about: Fabric v1.4.0 release scheduled for tomorrow: See Long-term support wording above Fabric roadmap: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11705 Chaincode refactoring - community involvement @sykesm @binhn, e.g. https://jira.hyperledger.org/browse/FAB-13582 helped-wanted items: https://jira.hyperledger.org/issues/?filter=10147 Aging CR policy - see proposal above from @cbf Fabric management proposal @grapebaba - https://docs.google.com/document/d/1DoxDzUIGyfnecEeWQDNXSc-cy7s32Cn2CaRjKQDV6f4/edit

dave.enyeart (Wed, 09 Jan 2019 13:03:39 GMT):
@here maintainer meeting in one hour, here's the agenda items I know about: Fabric v1.4.0 release later today and announcements tomorrow: See Long-term support wording above Fabric roadmap: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11705 Chaincode refactoring - community involvement @sykesm @binhn, e.g. https://jira.hyperledger.org/browse/FAB-13582 helped-wanted items: https://jira.hyperledger.org/issues/?filter=10147 Aging CR policy - see proposal above from @cbf Fabric management proposal @grapebaba - https://docs.google.com/document/d/1DoxDzUIGyfnecEeWQDNXSc-cy7s32Cn2CaRjKQDV6f4/edit

mbwhite (Wed, 09 Jan 2019 13:19:24 GMT):
@dave.enyeart - query on the long-term-support.... say there was a important defect and I felt it warranted a fabric-chaincode-node release. Would I need to wait until collectively say a Fabric 1.4.2 release; i.e. is it for the maintainers per component to say when a patch release should be released?

JonathanLevi (Wed, 09 Jan 2019 13:35:08 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=2zHppRE96KTy9tk29) @BellaAdams BTW: This is an "internal" channel for the maintainers. Let's continue chatting on the other channels. Thanks.

JonathanLevi (Wed, 09 Jan 2019 13:43:26 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=DSzTzSBXsLvAcmnFQ) @mbwhite It depends on the case and the severity of it. We, and @dave.enyeart in particular, are trying to always test the water make the maintainers vote over things. If it's bad [severe] enough, we may have a "global" 1.4.2 even if it fixes only a few (or even one component).

dave.enyeart (Wed, 09 Jan 2019 13:46:33 GMT):
@JonathanLevi @mbwhite For major releases we like to go out together. For minor releases (3rd digit fixes) SDKs are on their own schedule. I think we'll need some more discussion for chaincode. For example I believe for java chaincode it looks for the javaenv matching the peer version. We need to discuss this and get some consistency around java and node.

dave.enyeart (Wed, 09 Jan 2019 14:00:02 GMT):
@here maintainer meeting web conf - https://zoom.us/my/hyperledger.community

HongweiPeng (Wed, 09 Jan 2019 14:08:33 GMT):
Has joined the channel.

cbf (Wed, 09 Jan 2019 14:58:48 GMT):
had to drop

cbf (Wed, 09 Jan 2019 14:58:52 GMT):
good call

rjones (Wed, 09 Jan 2019 18:02:57 GMT):
Please observe: https://github.com/hyperledger/fabric-sdk-java/pull/18#issuecomment-452785551

rjones (Wed, 09 Jan 2019 18:04:54 GMT):
@mastersingh24 ^^^

rjones (Wed, 09 Jan 2019 18:05:25 GMT):
in 24 hours it will close the PR

levinem (Wed, 09 Jan 2019 18:23:01 GMT):
Has joined the channel.

levinem (Wed, 09 Jan 2019 19:04:20 GMT):
Is there a meeting now on zoom? Was interested in potentially listening in.

levinem (Wed, 09 Jan 2019 19:06:44 GMT):
Apologies, noted the time zone setting on the Community Calendar.

DmitriPlakhov (Thu, 10 Jan 2019 12:08:16 GMT):
Has joined the channel.

dave.enyeart (Thu, 10 Jan 2019 22:32:08 GMT):
------------------------------------------------------------------- Hyperledger Fabric v1.4 LTS RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/topic/announcement_hyperledger/29001113 -------------------------------------------------------------------

dave.enyeart (Thu, 10 Jan 2019 22:34:14 GMT):
If there is any doubt, MERGE FREEZE lifted in release-1.4 :)

dave.enyeart (Thu, 10 Jan 2019 22:47:45 GMT):
As always, a HUGE thank you to @rameshthoomu for navigating the release mechanics and keeping this project humming

richzhao (Thu, 10 Jan 2019 23:10:34 GMT):
glad to see the release

rjones (Fri, 11 Jan 2019 19:13:30 GMT):
@dave.enyeart @cbf @mastersingh24 assistance please? https://gerrit.hyperledger.org/r/#/c/28424/

rjones (Fri, 11 Jan 2019 19:23:29 GMT):
@cbf I see the fabric maintainers group has no superpowers in fabric-sdk-py. Oversight? I'll push a change for it

rjones (Fri, 11 Jan 2019 19:25:05 GMT):
s/maintainers/release managers/

cbf (Fri, 11 Jan 2019 19:25:39 GMT):
well, it isn't formally part of fabric release - I would leave to Baohua to decide... It may be appropriate to evaluate how current it is and bring it on board (I have made similar suggestion for sdk-go _

rjones (Fri, 11 Jan 2019 19:26:36 GMT):
ah I see. I had forgotten that. Apologies for harassing you three to do something you can't :)

FLASHJr (Sun, 13 Jan 2019 09:21:18 GMT):
Has joined the channel.

dave.enyeart (Mon, 14 Jan 2019 19:01:56 GMT):
There has been good progress on flakes, but somehow new ones keep coming up. We'll have to stay on top of them. You can see current flakes in the new Bugs and Tech Debt dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11706

dave.enyeart (Mon, 14 Jan 2019 19:02:53 GMT):
When you come across a flake, remember to search for the failure in Jira and either create a new jira bug or add a comment to an existing jira bug if found.

dave.enyeart (Mon, 14 Jan 2019 19:04:06 GMT):
Also, for all the ones that have been merged into master recently, let's cherry pick to release-1.4 while the code is still relatively in sync. Mentioning some of the people that have merged fixes into master recently: @yacovm @C0rWin @kostas @guoger @wlahti @sykesm

dave.enyeart (Mon, 14 Jan 2019 19:06:14 GMT):
Anybody can cherry pick, but probably makes the most sense for the developer of the flake fix to do the cherry picking.

dave.enyeart (Tue, 15 Jan 2019 11:48:44 GMT):
For the remaining playbacks this week I posted to Hyperledger calendar, mailing list, #fabric-playbacks , and sent invites to maintainers. Kind of painful to manage in 4 places... anybody have thoughts on streamlining?

dave.enyeart (Tue, 15 Jan 2019 11:48:44 GMT):
For the remaining playbacks this week I posted to Hyperledger calendar, https://wiki.hyperledger.org/projects/fabric/playbacks, mailing list, #fabric-playbacks , and sent invites to maintainers. Kind of painful to manage in 5 places... anybody have thoughts on streamlining?

baohua (Wed, 16 Jan 2019 04:16:22 GMT):
Has joined the channel.

mike.casey (Wed, 16 Jan 2019 16:42:20 GMT):
Has joined the channel.

dave.enyeart (Thu, 17 Jan 2019 11:31:13 GMT):
A few quick reminders: -When merging a CR, mark it Done in Jira and ensure FixVersion is set. -To ensure CRs get closed you can put *FAB-XXXX #done* in the commit message. But for this to work you have to remember to put the Jira "In CR Review" due to the Jira transition rules. -When merging a CR consider if it should be cherry picked to release-1.4. Since v1.4 is LTS, we should cherry pick any doc improvement, flake fix, and important bug fix. While the files are generally still in sync between master and release-1.4, this is usually just a quick push of the Cherry Pick button in gerrit. -Cherry pick can be done by developer or merging maintainer. -To signal that something should be backported, set the Fix Version in Jira to v2.0.0,v1.4.1. -Keeping Jira clean is the responsibility of the developer, the merging maintainer, and the squad lead. Please help!

robinrob (Fri, 18 Jan 2019 09:11:07 GMT):
Has joined the channel.

sstone1 (Fri, 18 Jan 2019 09:43:15 GMT):
@dave.enyeart @mastersingh24 @jyellick with all the new chaincode stuff going on - what will happen to chaincode on the upgrade path from 1.4 to 2.0? say i follow these steps: 1) stand up a 1.4 fabric 2) deploy a chaincode to that fabric 3) upgrade the fabric to 2.0 4) attempt to invoke the chaincode i deployed at 1.4 will the original 1.4 chaincode image still be used? or will the upgrade to 2.0 cause it to be rebuilt?

awjh (Fri, 18 Jan 2019 09:48:25 GMT):
Has joined the channel.

mastersingh24 (Fri, 18 Jan 2019 12:54:21 GMT):
We still have to maintain some level of backwards compatibility. Containers are not rebuilt even today when upgrading and that would continue to be the case in 2.0

sstone1 (Fri, 18 Jan 2019 13:22:52 GMT):
okay, thanks for the update @mastersingh24 :+1:

jyellick (Fri, 18 Jan 2019 14:31:39 GMT):
Yes, we will continue to have old lifecycle support in the new binary to give users a migration path. Once v2.0 capabilities are enabled on a channel, we will make the old lifecycle read-only, and I would like to see all of the endorser-side old lifecycle components removed in v2.1 (the validation will need to stick around indefinitely to support older chains).

kostas (Fri, 18 Jan 2019 18:58:12 GMT):
Someone who's smarter than me: can we modify whatever linter checks we have in CI so that we reject CRs that don't have GoDoc comments that don't end with a period? See: https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences

kostas (Fri, 18 Jan 2019 18:58:15 GMT):
I'm hoping (and I'm naive) that this acts as a nudge of sorts towards caring more about how our stuff looks in GoDoc.

kostas (Fri, 18 Jan 2019 18:58:57 GMT):
As is the case with how we do JIRA, our attention to GoDoc seems like an afterthought.

kostas (Fri, 18 Jan 2019 18:59:37 GMT):
And while I understand we may have bigger fish to fry, I don't think this is something that we should keep postponing.

kostas (Fri, 18 Jan 2019 19:00:03 GMT):
We'll never go: "Alright, we'll fix GoDoc for everything in this release." This should be gradual.

kostas (Fri, 18 Jan 2019 19:03:03 GMT):
On a related note for those who review code: I would ask that [we occassionally bring up a godoc server locally](http://whipperstacker.com/2015/10/03/run-a-godoc-server-locally-to-see-documentation-for-unpublished-packages/) and check how the package we're reviewing looks like.

mastersingh24 (Sun, 20 Jan 2019 12:23:12 GMT):
@kostas - I looked at some other linter wrappers such as golangci-lint and gometalinter and they did not seem to have any options for godoc / comments either other than basic formatting. On a related note, maybe we should actually be using one of those packages instead anyway. @sykesm - any thoughts about this?

C0rWin (Sun, 20 Jan 2019 14:57:38 GMT):
@kostas @mastersingh24 https://github.com/golangci/awesome-go-linters seems that other linter also do no have options for GoDoc formatting

dave.enyeart (Sun, 20 Jan 2019 19:30:39 GMT):
I think the Makefile has gone bad as of https://gerrit.hyperledger.org/r/#/c/27491/ (switch to Alpine)

dave.enyeart (Sun, 20 Jan 2019 19:31:08 GMT):
When I update peer code and then `make peer`, I get response:

dave.enyeart (Sun, 20 Jan 2019 19:31:12 GMT):
```make: Nothing to be done for `peer'.```

dave.enyeart (Sun, 20 Jan 2019 19:31:25 GMT):
I have to clean it before it will make again.

dave.enyeart (Sun, 20 Jan 2019 19:31:56 GMT):
If I checkout out the commit prior to the Alpine change, `make peer` works as it always has previously

dave.enyeart (Sun, 20 Jan 2019 19:32:26 GMT):
any ideas @mastersingh24 ?

mastersingh24 (Sun, 20 Jan 2019 20:37:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=sxRczGakdkh2JyeGz) @dave.enyeart https://gerrit.hyperledger.org/r/28839

dave.enyeart (Sun, 20 Jan 2019 20:42:06 GMT):
@mastersingh24 Confirmed that it works now... +2ed

ycarmel (Tue, 22 Jan 2019 08:46:03 GMT):
Has joined the channel.

incarose (Wed, 23 Jan 2019 00:23:36 GMT):
Has joined the channel.

dave.enyeart (Wed, 23 Jan 2019 13:03:41 GMT):
@here Maintainer meeting in one hour, any other topics? * Release v2.0 dashboard - https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 * Bugs and Tech Debt dashboard - https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11706 * Aging CR policy - update

dave.enyeart (Wed, 23 Jan 2019 14:00:03 GMT):
@here Maintainer meeting starting: https://zoom.us/my/hyperledger.community

dave.enyeart (Thu, 24 Jan 2019 06:08:26 GMT):
I have a CR to make it more clear how people can contribute to Fabric. Please review CR and/or the generated doc: https://logs.hyperledger.org/production/vex-yul-hyp-jenkins-3/fabric-docs-build-x86_64/1291/html/CONTRIBUTING.html#ways-to-contribute

dave.enyeart (Thu, 24 Jan 2019 06:08:26 GMT):
I have a CR to make it more clear how people can contribute to Fabric. Please review CR https://gerrit.hyperledger.org/r/#/c/28933/ and/or the generated doc: https://logs.hyperledger.org/production/vex-yul-hyp-jenkins-3/fabric-docs-build-x86_64/1291/html/CONTRIBUTING.html#ways-to-contribute

dave.enyeart (Thu, 24 Jan 2019 06:09:29 GMT):
You'll see I mention `help-wanted` list, so please take a moment to look at the list, remove anything outdated in your areas, and tag anything new that you know of that could use some help

dave.enyeart (Thu, 24 Jan 2019 06:10:27 GMT):
@cbf Please update the release roadmap dashboard to display v2.0 and v2.1 now (pinged you the details separately)

dave.enyeart (Thu, 24 Jan 2019 06:11:56 GMT):
Once this is reviewed I will send the link to mailing list

dave.enyeart (Thu, 24 Jan 2019 06:12:10 GMT):
@sykesm @simsc FYI

mrjdomingus (Thu, 24 Jan 2019 10:11:30 GMT):
Has joined the channel.

C0rWin (Tue, 29 Jan 2019 12:52:30 GMT):
did we already apply policy for orphaned (more than two weeks) CRs in gerrit? @dave.enyeart @mastersingh24 @cbf

mastersingh24 (Tue, 29 Jan 2019 12:53:40 GMT):
I've been applying it for quite some time, but I'd say it is in effect now

C0rWin (Tue, 29 Jan 2019 13:20:34 GMT):
Ok ;) I was asking about automated process, but manual is also good to start with

cbf (Tue, 29 Jan 2019 14:52:05 GMT):
I have to get the scripting in place, but I have been swamped with other priorities

cbf (Tue, 29 Jan 2019 14:52:20 GMT):
but agree, we should consider it in place

lehors (Tue, 29 Jan 2019 19:32:54 GMT):
do you guys give a warning?

lehors (Tue, 29 Jan 2019 19:33:46 GMT):
and, I hope you don't forget that maintainers also ought to comment before they ditch any CR

lehors (Tue, 29 Jan 2019 19:36:05 GMT):
#fabric-pr-review seems to have been deserted by all maintainers... :-/

dave.enyeart (Thu, 31 Jan 2019 16:38:07 GMT):
Is everybody ok with this change:

dave.enyeart (Thu, 31 Jan 2019 16:38:10 GMT):
https://jira.hyperledger.org/browse/FABCI-282 - Send email to CR owner if CI merge job fails

dave.enyeart (Thu, 31 Jan 2019 16:38:16 GMT):
If a merge job fails, email should be sent to CR owner in addition to CI team, so that CR owner can investigate if their CR introduced a regression.

C0rWin (Thu, 31 Jan 2019 18:25:17 GMT):
is it too much to ask to add console log tar gz file to this email?

C0rWin (Thu, 31 Jan 2019 18:25:17 GMT):
is it too much to ask to add console log tar gz file to this email? @dave.enyeart

rjones (Thu, 31 Jan 2019 18:58:29 GMT):
Has left the channel.

sykesm (Thu, 31 Jan 2019 19:34:50 GMT):
We may have a merge conflict between these two FAB-14007 / Change-Id: I4e7962ad0d7c7d69f5aa011b6797d53892d02a12 FAB-12918 / Change-Id: Ifa067393567b03ecff9bf60bdf685b41bd1aef83

sykesm (Thu, 31 Jan 2019 19:35:41 GMT):
in gossip/gossip/gossip_test.go @C0rWin

sykesm (Thu, 31 Jan 2019 19:41:35 GMT):
^ I'm doing the quick fix

sykesm (Thu, 31 Jan 2019 19:43:45 GMT):
@C0rWin @yacovm - https://gerrit.hyperledger.org/r/c/29089/ ?

sykesm (Thu, 31 Jan 2019 19:43:45 GMT):
~@C0rWin @yacovm - https://gerrit.hyperledger.org/r/c/29089/ ?~

scottz (Fri, 01 Feb 2019 16:28:34 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=mioiZPwqTSj39eQEP) @C0rWin The email will contain a link to where you can see any saved artifacts and the console logfile.

C0rWin (Fri, 01 Feb 2019 20:13:21 GMT):
For how ling it gonna be persisted? Will it be retained fot longer period? We have many JIRAs with such links not that helpful though @scottz

C0rWin (Fri, 01 Feb 2019 20:13:21 GMT):
For how long it gonna be persisted? Will it be retained fot longer period? We have many JIRAs with such links not that helpful though @scottz

C0rWin (Fri, 01 Feb 2019 20:13:21 GMT):
For how long it gonna be persisted? Will it be retained for longer period? We have many JIRAs with such links not that helpful though @scottz

scottz (Fri, 01 Feb 2019 21:57:35 GMT):
I believe there is a way to find the logfile, even after the initial 7 days when the jobs disappear. That way is better, since there are other file artifacts too in some cases. Let me forward the request to the CI guys to see if we can provide instructions in the email. If not, then we can reconsider the idea to attach the logfile.

vikpande (Mon, 04 Feb 2019 16:34:05 GMT):
Has joined the channel.

vikpande (Mon, 04 Feb 2019 16:35:05 GMT):
Hello maintainers. One of our community members is looking for the playbacks of fabric for these topics " RAFT and Lifecyle and , but also last weeks sessions were not there at all. Fabric Performance" the member looked at this page which is not available anymore - https://wiki.hyperledger.org/projects/fabric/playbacks but that does not work as a URL. (Page not found).. I was able to redirect to the right page https://wiki.hyperledger.org/display/fabric/Playbacks . However, even there she/he couldnt find the playbacks. Can someone shed some light and share the location/link where the playbacks are stored. thank you

dave.enyeart (Mon, 04 Feb 2019 16:57:25 GMT):
@tkuhrt Two things concerning the above message: 1) The prior wiki links are no longer available, will there be a community announcement about the wiki migration? 2) I've tried to upload recent community recordings from last two weeks but the linux foundation google drive is out of space.

greg2git (Mon, 04 Feb 2019 19:57:43 GMT):
yes, please let the rest of the community know when https://wiki.hyperledger.org/projects/fabric/playbacks is back up or successfully migrated to another globally accessible URL

rjones (Mon, 04 Feb 2019 20:02:21 GMT):
Has joined the channel.

rjones (Mon, 04 Feb 2019 20:02:44 GMT):
https://wiki-archive.hyperledger.org/

rjones (Mon, 04 Feb 2019 20:09:39 GMT):
@dave.enyeart this is the first I've heard of for the google drive being full.

dave.enyeart (Mon, 04 Feb 2019 20:10:30 GMT):
I mentioned to Tracy last Thursday in fabric-playbacks, and here today.

rjones (Mon, 04 Feb 2019 22:54:16 GMT):
@dave.enyeart Hyperledger pays for a 5TB Google drive. We are not even using 1TB.

dave.enyeart (Mon, 04 Feb 2019 23:50:44 GMT):
@rjones ok, looks like google drive uses the uploader's account for storage rather than the owning folder's account, so we'll need to figure out a new uploading mechanism. See https://productforums.google.com/forum/?noredirect=true#!topic/drive/lCnogIobjxc

greg2git (Tue, 05 Feb 2019 00:00:27 GMT):
@greg2git looks like i found it here: https://wiki.hyperledger.org/display/fabric/Playbacks Thank you for the quick response

rjones (Tue, 05 Feb 2019 02:16:40 GMT):
@dave.enyeart WRT Tracy: https://lists.hyperledger.org/g/tsc/message/2010

dave.enyeart (Wed, 06 Feb 2019 13:21:09 GMT):
@here Maintainer meeting coming up at the top of the hour. Here are the agenda topics I have so far, welcome others: *1) Release update* Development for core *lifecycle* and *token management* features is making good progress in Q1, however there are many downstream impacts including node sdk, automated tests throughout CI, samples, doc. Additionally we would like to get community feedback, especially since lifecycle will impact existing users. We think it makes sense to release as a beta for Q1 and as a production feature at end of Q2. Raft is mostly development complete and is actively being system tested in preparation for a March release. Upon discussing with several maintainers, we propose: - Deliver a v2.0 beta for Q1 (March) and Q2 (June) production release including lifecycle (along with the required implicit private data collections), token, required validation updates, node sdk support, programming model updates, and alpine. - Deliver a v1.4.x release in Q1 (March) to serve as a delivery vehicle for Raft and a few serviceability metrics and health checks. Yes, it is unusual to deliver new function in a third digit release, but since Raft will be ready, is isolated in the code, and will not impact v1.4.0 customers that move to v1.4.x, we think it is acceptable. Also the serviceability improvements will help with 1.4.x LTS support. This approach is seen as favorable to releasing a separate v1.5 since that would bring confusion to the v1.4.0 LTS release. *2) Fabric CA Maintainers* Proposal to split maintainers for Fabric and Fabric CA. Initial Fabric CA maintainer list would be based on contribution and review activity over the past 12 months. That would yield the following maintainers: Chris Ferris, Dave Enyeart, Gari Singh, Jonathan Levi, Keith Smith, Matt Sykes, Saad Karim (new). I will submit a gerrit CR to formalize the proposal. *3) Aging CR update* Automation is being put in place to remind CR owners to address review feedback, to abandon CRs that are idle for 2 two-week periods (they can easily be restored), and to remind maintainers about reviews needed. After maintainer meeting, we will proceed directly to a proposal for *Peer and Chaincode cloud native deployment support* from Binh Nguyen ( https://jira.hyperledger.org/browse/FAB-13582 ).

dave.enyeart (Wed, 06 Feb 2019 13:21:09 GMT):
@here Maintainer meeting coming up at the top of the hour. Here are the agenda topics I have so far, welcome others: *1) Release update* Development for core *lifecycle* and *token management* features is making good progress in Q1, however there are many downstream impacts including node sdk, automated tests throughout CI, samples, doc. Additionally we would like to get community feedback, especially since lifecycle will impact existing users. We think it makes sense to release as a beta for Q1 and as a production feature at end of Q2. *Raft* is mostly development complete and is actively being system tested in preparation for a March release. Upon discussing with several maintainers, we propose: - Deliver a *v2.0 beta for Q1 (March) and Q2 (June) production release* including lifecycle (along with the required implicit private data collections), token, required validation updates, node sdk support, programming model updates, and alpine. - Deliver a *v1.4.x release in Q1 (March) to deliver Raft and a few serviceability metrics and health checks.* Yes, it is unusual to deliver new function in a third digit release, but since Raft will be ready, is isolated in the code, and will not impact v1.4.0 customers that move to v1.4.x, we think it is acceptable. Also the serviceability improvements will help with 1.4.x LTS support. This approach is seen as favorable to releasing a separate v1.5 since that would bring confusion to the v1.4.0 LTS release. *2) Fabric CA Maintainers* Proposal to split maintainers for Fabric and Fabric CA. Initial Fabric CA maintainer list would be based on contribution and review activity over the past 12 months. That would yield the following maintainers: Chris Ferris, Dave Enyeart, Gari Singh, Jonathan Levi, Keith Smith, Matt Sykes, Saad Karim (new). I will submit a gerrit CR to formalize the proposal. *3) Aging CR update* Automation is being put in place to remind CR owners to address review feedback, to abandon CRs that are idle for 2 two-week periods (they can easily be restored), and to remind maintainers about reviews needed. After maintainer meeting, we will proceed directly to a proposal for *Peer and Chaincode cloud native deployment support* from Binh Nguyen ( https://jira.hyperledger.org/browse/FAB-13582 ).

dave.enyeart (Wed, 06 Feb 2019 13:21:09 GMT):
@here Maintainer meeting coming up at the top of the hour. Here are the agenda topics I have so far, welcome others: *1) Release update* Development for core *lifecycle* and *token management* features is making good progress in Q1, however there are many downstream impacts including node sdk, automated tests throughout CI, samples, doc. Additionally we would like to get community feedback, especially since lifecycle will impact existing users. We think it makes sense to release as a beta for Q1 and as a production feature at end of Q2. *Raft* is mostly development complete and is actively being system tested in preparation for a March release. Upon discussing with several maintainers, we propose: - Deliver a *v2.0 beta for Q1 (March) and Q2 (June) production release* including lifecycle (along with the required implicit private data collections), token, required validation updates, node sdk support, programming model updates, and alpine. - Deliver a *v1.4.x release in Q1 (March) to deliver Raft and a few serviceability metrics and health checks*, along with fixes since v1.4.0. Yes, it is unusual to deliver new function in a third digit release, but since Raft will be ready, is isolated in the code, and will not impact v1.4.0 customers that move to v1.4.x, we think it is acceptable. Also the serviceability improvements will help with 1.4.x LTS support. This approach is seen as favorable to releasing a separate v1.5 since that would bring confusion to the v1.4.0 LTS release. *2) Fabric CA Maintainers* Proposal to split maintainers for Fabric and Fabric CA. Initial Fabric CA maintainer list would be based on contribution and review activity over the past 12 months. That would yield the following maintainers: Chris Ferris, Dave Enyeart, Gari Singh, Jonathan Levi, Keith Smith, Matt Sykes, Saad Karim (new). I will submit a gerrit CR to formalize the proposal. *3) Aging CR update* Automation is being put in place to remind CR owners to address review feedback, to abandon CRs that are idle for 2 two-week periods (they can easily be restored), and to remind maintainers about reviews needed. After maintainer meeting, we will proceed directly to a proposal for *Peer and Chaincode cloud native deployment support* from Binh Nguyen ( https://jira.hyperledger.org/browse/FAB-13582 ).

dave.enyeart (Wed, 06 Feb 2019 14:00:46 GMT):
@here Maintainer meeting web conf: https://zoom.us/my/hyperledger.community.3

joe-alewine (Wed, 06 Feb 2019 14:15:44 GMT):
Sooo.... is this meeting not going to happen?

jyellick (Wed, 06 Feb 2019 14:16:03 GMT):
Are you on the right zoom link? It's going

jyellick (Wed, 06 Feb 2019 14:16:03 GMT):
Are you on the right zoom link? It's going @joe-alewine

joe-alewine (Wed, 06 Feb 2019 14:16:57 GMT):
@jyellick Oh, it's a different zoom link than in the email invite

joe-alewine (Wed, 06 Feb 2019 14:16:57 GMT):
@jyellick Oh, it's a different zoom link than in the email invite @dave.enyeart

joe-alewine (Wed, 06 Feb 2019 14:17:43 GMT):
A few people are on that one --- Yacov, Bret, Angelo

jyellick (Wed, 06 Feb 2019 14:18:40 GMT):
@yacovm @bretharrison @adc ^

joe-alewine (Wed, 06 Feb 2019 14:18:46 GMT):
Or at least were

joe-alewine (Wed, 06 Feb 2019 14:18:54 GMT):
A few are on this one now

dave.enyeart (Wed, 06 Feb 2019 15:33:19 GMT):
@joe-alewine Sorry about the zoom change... there was a conflict with another Hyperledger meeting, I've switched to https://zoom.us/my/hyperledger.community.3 going forward to avoid collisions and have updated the meeting invite.

aso (Fri, 08 Feb 2019 18:34:15 GMT):
master is broken one rename was missing from (https://gerrit.hyperledger.org/r/#/c/29146/)

aso (Fri, 08 Feb 2019 18:34:25 GMT):
fixed in https://gerrit.hyperledger.org/r/#/c/29205/

aso (Fri, 08 Feb 2019 18:34:39 GMT):
2nd +2 please

aso (Fri, 08 Feb 2019 18:34:39 GMT):
~2nd +2 please~

aso (Fri, 08 Feb 2019 18:39:04 GMT):
thx @jyellick

dave.enyeart (Sat, 09 Feb 2019 03:42:18 GMT):
The fabric-ca maintainer proposal has reached a majority and is merged: https://gerrit.hyperledger.org/r/#/c/29219/

dave.enyeart (Sat, 09 Feb 2019 03:42:28 GMT):
Welcome aboard @skarim !

dave.enyeart (Sat, 09 Feb 2019 03:42:40 GMT):
I've sent hyperledger helpdesk an email to update the fabric-ca privileges.

SatoshiNishishita (Tue, 12 Feb 2019 04:57:36 GMT):
Has joined the channel.

TarasKob (Tue, 12 Feb 2019 14:49:53 GMT):
Has joined the channel.

kostas (Thu, 14 Feb 2019 18:41:56 GMT):
Version 1.4.0 still shows up as unreleased in JIRA. Can we fix it?

minollo (Thu, 14 Feb 2019 18:44:05 GMT):
@manish-sethi @dave.enyeart is anyone working on https://jira.hyperledger.org/browse/FAB-106 at this point? Any design proposal available?

manish-sethi (Thu, 14 Feb 2019 18:46:22 GMT):
@minollo - Design is not at a stage that can be shared. Haven't actively started working on this as such.

minollo (Thu, 14 Feb 2019 18:48:53 GMT):
thanks @manish-sethi ; we may be interested in contributing to this project to accelerate it

manish-sethi (Thu, 14 Feb 2019 18:50:08 GMT):
@minollo - sure great. will touchbase with you in near future.

dave.enyeart (Thu, 14 Feb 2019 19:25:09 GMT):
@kostas Jira has been updated to indicate v1.4.0 is released

KartikChauhan (Fri, 15 Feb 2019 08:44:52 GMT):
Has joined the channel.

gregnotso (Sun, 17 Feb 2019 12:28:14 GMT):
Has joined the channel.

shibasisp (Sun, 17 Feb 2019 15:33:39 GMT):
Has joined the channel.

brockhager (Mon, 18 Feb 2019 15:56:33 GMT):
Has joined the channel.

jyellick (Tue, 19 Feb 2019 15:33:07 GMT):
Did something change with Gerrit where on rebase +2-s become +1-s?

dave.enyeart (Tue, 19 Feb 2019 15:41:37 GMT):
@jyellick gerrit authentication server had some issues this morning, appears to be resolved now.

jyellick (Tue, 19 Feb 2019 15:42:52 GMT):
@dave.enyeart It looks like any CRs I rebased this morning had their +2-s converted into +1s (still there). https://gerrit.hyperledger.org/r/c/29147/ for instance

jyellick (Tue, 19 Feb 2019 15:43:25 GMT):
Not the end of the world... but confusing and a bit odd

C0rWin (Tue, 19 Feb 2019 15:44:15 GMT):
there was an issue with authentication this morning, I think this is somewhat related

dave.enyeart (Tue, 19 Feb 2019 15:45:19 GMT):
I suspect future rebases will be ok, may have to reapply +2s on the ones impacted.

dave.enyeart (Tue, 19 Feb 2019 15:45:19 GMT):
I suspect future rebases will be ok, may have to reapply +2s on the ones impacted this morning.

dave.enyeart (Wed, 20 Feb 2019 14:00:30 GMT):
@here Maintainer meeting starting: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 20 Feb 2019 14:00:43 GMT):
Release Update - v1.4.1 targeted for end of March. Raft and a few serviceability metrics and health checks are being backported to release-1.4 since they are ready and will not impact current v1.4.0 users. If there is demand for critical fixes prior to then, we have an option to cut a v1.4.1 sooner and then make Raft available in v1.4.2. - v2.0 beta targeted for end of March with final release expected end of June. Due to the major updates in v2.0 we would like to get community feedback during beta timeframe (updated lifecycle, implicit org collections, token, programming model updates, alpine images) After maintainer meeting, we will proceed directly to lifecycle playback .

AVK (Wed, 20 Feb 2019 15:09:51 GMT):
Has joined the channel.

minollo (Fri, 22 Feb 2019 03:33:46 GMT):
@dave.enyeart can you clarify one thing? About 1.4.1 end of March: is that going "for sure" to include Raft ordering service? Or is it now possible that Raft ordering service will first see the light only in 1.4.2? And, is 1.4.2 "formally" scheduled for end of June? Thanks!

kostas (Fri, 22 Feb 2019 05:09:50 GMT):
@minollo: Raft is going to be part of the 1.4.1 release.

minollo (Fri, 22 Feb 2019 05:25:11 GMT):
Thanks @kostas

knagware9 (Fri, 22 Feb 2019 11:36:09 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=AyZsXQTZ4bJh7pzqG) @dave.enyeart Can I found meeting record somewhere , would like to check release update , Thanks

dave.enyeart (Fri, 22 Feb 2019 12:23:42 GMT):
@knagware9 Sorry I missed the recording this week. In addition to the above update, we mostly reviewed the Current Status field in the v2.0 Epic dashboard here: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700. I was able to capture the Lifecycle playback, recording here: https://wiki.hyperledger.org/display/fabric/playbacks

dave.enyeart (Fri, 22 Feb 2019 12:30:42 GMT):
@minollo third digit fixes on the v1.4 LTS release will happen at least quarterly - currently targeted for v1.4.1 end of March, v1.4.2 end of June, but may be released more frequent if there are critical bugs found that require quicker release. For example if there was a critical bug found this week, we may release v1.4.1 sooner and then also pull v1.4.2 forward to include Raft.

minollo (Fri, 22 Feb 2019 12:42:38 GMT):
@dave.enyeart understood; I suppose that means that - no matter if it's labeled 1.4.1, 1.4.2, or 1.4.87, whatever 1.4.x you release in the end of March timeframe *will* feature raft-based ordering service; correct?

dave.enyeart (Fri, 22 Feb 2019 13:09:04 GMT):
@minollo That's the plan, and the team working on it is currently on target. Exact release date for third digit releases depends on bugs found and test progress. The maintainers value quality over all else.

knagware9 (Fri, 22 Feb 2019 13:24:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=upQMEGK7Wc8NeR3A9) @dave.enyeart Thanks , Just watched Lifecycle playback ,,looks great

braduf (Sun, 24 Feb 2019 20:49:27 GMT):
Has joined the channel.

sambhavdutt (Mon, 04 Mar 2019 00:18:08 GMT):
For your information There have been connsistent fails in the sdk-node tests, there is an open bug for this issue, https://jira.hyperledger.org/browse/FABN-1165

sambhavdutt (Mon, 04 Mar 2019 01:52:34 GMT):
https://jira.hyperledger.org/browse/FAB-14465 @bretharrison @andrew-coleman The BYFN tests are failing in Node Chaincode test in 1.4 and master , can you take a look

sambhavdutt (Mon, 04 Mar 2019 01:52:34 GMT):
https://jira.hyperledger.org/browse/FAB-14465 The BYFN tests are failing in Node Chaincode test in 1.4 and master , can you take a look

mbwhite (Mon, 04 Mar 2019 13:17:24 GMT):
Is anybody aware of an issue wtih master branch `cryptotxgen` using the configtx.yaml from basic-network gives a lot of these errors ``` configtxgen -profile OneOrgChannel -outputCreateChannelTx /etc/hyperledger/configtx/channel.tx -channelID mychanne ```

jyellick (Mon, 04 Mar 2019 13:18:15 GMT):
@mbwhite Ensure that the channel creation profile has policies defined in it -- let me get you a link

mbwhite (Mon, 04 Mar 2019 13:18:32 GMT):
thanks;

jyellick (Mon, 04 Mar 2019 13:18:46 GMT):
https://gerrit.hyperledger.org/r/c/29421/

jyellick (Mon, 04 Mar 2019 13:18:46 GMT):
https://gerrit.hyperledger.org/r/c/29421/ (Also ensure policies are present: https://gerrit.hyperledger.org/r/c/29528/ )

mbwhite (Mon, 04 Mar 2019 13:25:31 GMT):
I see... ok thanks!

mbwhite (Mon, 04 Mar 2019 13:27:16 GMT):
FYI everybdoy - the fabric-chaincode-node master builds won't build until we've modified the crptotygen configuration file - re the above change

dave.enyeart (Wed, 06 Mar 2019 13:18:15 GMT):
@here Maintainer meeting at the top of the hour. Agenda topics that I have so far: Release Update - *v1.4.1* targeted for end of March. Raft and a few serviceability metrics and health checks have been backported to release-1.4. - *v2.0 alpha* targeted for end of March with final release expected end of June. Due to the major updates in v2.0 we would like to get community feedback during alpha timeframe (updated lifecycle, implicit org collections, token, programming model updates, alpine images). Deliver as an alpha rather than a beta so that any feedback related to API changes can be addressed. We are working on tutorials so that the community can try the new lifecycle and token scenarios. We still have a large backlog of CRs needing review. Fabric-CA has recently moved from two +2 review policy to non-author code review (NACR) which requires one +2. There is another proposal to make the same change for fabric and fabric-samples. Maintainers could +1 if they'd like additional reviews, or could +2 if they'd like to merge immediately. Thoughts? Proposal for making chaincode build and launch flexible enough to support various schemes, including the 'cloud native' approach from https://jira.hyperledger.org/browse/FAB-13582. For details see https://gist.github.com/sykesm/0958550cc41b47f8b99b4f54697ac342

dave.enyeart (Wed, 06 Mar 2019 13:18:15 GMT):
@here Maintainer meeting at the top of the hour. Agenda topics that I have so far: Release Update - *v1.4.1* targeted for end of March. Raft and a few serviceability metrics and health checks have been backported to release-1.4. - *v2.0 alpha* targeted for end of March with final release expected end of June. Due to the major updates in v2.0 we would like to get community feedback during alpha timeframe (updated lifecycle, implicit org collections, token, programming model updates, alpine images). Deliver as an alpha rather than a beta so that any feedback related to API changes can be addressed. We are working on tutorials so that the community can try the new lifecycle and token scenarios. We still have a large backlog of CRs needing review. Fabric-CA has recently moved from two +2 review policy to non-author code review (NACR) which requires one +2. There is another proposal to make the same change for fabric and fabric-samples. Maintainers could +1 if they'd like additional reviews, or could +2 if they'd like to merge immediately. Thoughts? Proposal to archive fabric-sdk-rest subproject since it is no longer being developed and maintained. Proposal for making chaincode build and launch flexible enough to support various schemes, including the 'cloud native' approach from https://jira.hyperledger.org/browse/FAB-13582. For details see https://gist.github.com/sykesm/0958550cc41b47f8b99b4f54697ac342

dave.enyeart (Wed, 06 Mar 2019 13:18:15 GMT):
@here Maintainer meeting at the top of the hour. Agenda topics that I have so far: Release Update - *v1.4.1* targeted for end of March. Raft and a few serviceability metrics and health checks have been backported to release-1.4. - *v2.0 alpha* targeted for end of March with final release expected end of June. Due to the major updates in v2.0 we would like to get community feedback during alpha timeframe (updated lifecycle, implicit org collections, token, programming model updates, alpine images). Deliver as an alpha rather than a beta so that any feedback related to API changes can be addressed. We are working on tutorials so that the community can try the new lifecycle and token scenarios. v2.0 dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 We still have a large backlog of CRs needing review. Fabric-CA has recently moved from two +2 review policy to non-author code review (NACR) which requires one +2. There is another proposal to make the same change for fabric and fabric-samples. Maintainers could +1 if they'd like additional reviews, or could +2 if they'd like to merge immediately. Thoughts? Proposal to archive fabric-sdk-rest subproject since it is no longer being developed and maintained. Proposal for making chaincode build and launch flexible enough to support various schemes, including the 'cloud native' approach from https://jira.hyperledger.org/browse/FAB-13582. For details see https://gist.github.com/sykesm/0958550cc41b47f8b99b4f54697ac342

dave.enyeart (Wed, 06 Mar 2019 13:59:26 GMT):
@here maintainer meeting starting: https://zoom.us/my/hyperledger.community.3

bryangross (Wed, 06 Mar 2019 14:04:34 GMT):
Has joined the channel.

dave.enyeart (Wed, 06 Mar 2019 17:35:21 GMT):
@here Since the maintainer meeting I've been hearing mixed feedback from maintainers on the proposal to move fabric to a single +2 review policy - there is no clear consensus. So it seems the needle has not moved much since we last discussed this in July. That being said, we do have an issue providing timely reviews. Allowing maintainers to self +2 has helped somewhat, but not enough. Something must change. Let's discuss some more options here. Some ideas to jumpstart the conversation: 1) Move to a single +2 where the initial reviewer uses judgement whether they will +2 and merge, or simply provide +1 and wait for (or nominate) another reviewer. 2) Move to a single +2 and use a component model where certain critical components require a +2 from one of the named component experts. Given current code structure, this would likely be on the honor system rather than enforced. 3) Keep two +2 policy, and collectively commit to spending more time on reviews on a regular basis, at the price of velocity on other maintainer work items. 4) Keep two +2 policy, and expand the list of maintainers. Other ideas?

dave.enyeart (Wed, 06 Mar 2019 17:37:58 GMT):
To let you know where my head is... I'm edging towards option 2 but would like to hear everybody's thoughts

dave.enyeart (Wed, 06 Mar 2019 17:37:58 GMT):
To let you know where my head is... I'm edging towards option 2, but it opens just as many questions as it answers (e.g. what is a component? what is a component expert?), I'd like to hear everybody's thoughts

yacovm (Wed, 06 Mar 2019 18:58:59 GMT):
> That being said, we do have an issue providing timely reviews. Is there some quantifiable score/metric or analysis that someone performed that can back up this claim?

yacovm (Wed, 06 Mar 2019 18:59:36 GMT):
I don't think this is the case

jyellick (Wed, 06 Mar 2019 19:01:31 GMT):
FWIW, I was also very much looking forward to the gerrit automation. Because the backlog of CR reviews is unkempt, it discourages reviewing CRs which are outside of a known line of work. It's frustrating setting aside time to review CRs only to find yourself sifting through mostly things which should have been abandoned weeks ago.

swetha (Wed, 06 Mar 2019 19:42:52 GMT):
Has joined the channel.

dave.enyeart (Wed, 06 Mar 2019 20:05:11 GMT):
>Is there some quantifiable score/metric or analysis that someone performed that can back up this claim?

dave.enyeart (Wed, 06 Mar 2019 20:05:28 GMT):
I don't have the data from before the recent effort to clean up old CRs. This query will help though: `status:open project:fabric is:mergeable label:Code-Review>-1 label:f3-integrationtest:1`

dave.enyeart (Wed, 06 Mar 2019 20:05:41 GMT):
currently sitting at 81 reviewable CRs in fabric

jyellick (Wed, 06 Mar 2019 20:06:07 GMT):
What happened to the automation effort? Is that being actively worked on?

yacovm (Wed, 06 Mar 2019 20:16:34 GMT):
> currently sitting at 81 reviewable CRs in fabric Even if we assume that all 81 should be merged (which I find hard to believe) - I don't see the problem. We have 14 maintainers, right? Should be easily doable in 2-3 days :)

dave.enyeart (Wed, 06 Mar 2019 20:23:54 GMT):
It is less of an issue for people with 2-3 maintainers in their squad. It is more of an issue for others.

dave.enyeart (Wed, 06 Mar 2019 20:24:58 GMT):
The automation effort will help clean up and abandon unreviewable CRs, but will not help with reviewable CRs (beyond sending nag notes)

dave.enyeart (Wed, 06 Mar 2019 20:25:14 GMT):
@cbf any update on the aging CR automation?

yacovm (Wed, 06 Mar 2019 20:26:23 GMT):
I think the issue here is not the feature development, but the non feature development actually

yacovm (Wed, 06 Mar 2019 20:26:30 GMT):
the feature development IMO flows just fine

dave.enyeart (Wed, 06 Mar 2019 20:27:07 GMT):
right, it's the stuff coming in from outside the core squads that languishes most

jyellick (Wed, 06 Mar 2019 20:27:35 GMT):
I thought there was also some talk of assigning maintainers to a CR as advocate/shepherd of sorts? As Yacov points out if with 81 CRs, and 12 maintainers, giving 7 CRs per maintainer to track would hardly be onerous. On the other hand, asking each maintainer to review 81 CRs to keep them progressing is not so practical.

yacovm (Wed, 06 Mar 2019 20:28:54 GMT):
we have 14-15 maintainers

yacovm (Wed, 06 Mar 2019 20:29:22 GMT):
81 CRs is 160 +2s. not something un-achievable

yacovm (Wed, 06 Mar 2019 20:29:22 GMT):
81 CRs is 160 +2s. not something UN-achievable in a few days for all of them

dave.enyeart (Wed, 06 Mar 2019 20:29:28 GMT):
the comments are not directed to the two most active maintainers :)

dave.enyeart (Wed, 06 Mar 2019 20:29:28 GMT):
the comments are not directed to two of the most active maintainers :)

jyellick (Wed, 06 Mar 2019 20:30:27 GMT):
So must be directed at me :slight_smile:

jyellick (Wed, 06 Mar 2019 20:31:00 GMT):
In any case... if we had some way to assign stewardship of CRs to a maintainer, it would go a long way.

jyellick (Wed, 06 Mar 2019 20:31:00 GMT):
In any case... if we had some way to assign stewardship of particular CRs to a maintainer, it would go a long way.

dave.enyeart (Wed, 06 Mar 2019 20:32:07 GMT):
as we see CRs come in, we can all tag 'relevant' maintainers in that area of the code as potential reviewers in CRs

jyellick (Wed, 06 Mar 2019 20:33:38 GMT):
Personally, I don't think that works. If we want to be serious about addressing languishing CRs I think we need explicit singular responsibility for a particular maintainer on a particular CR. I'm not even suggesting that they must be the one to +2, or that they are the SME, merely that it is on them to ensure that it gets attention from the right spots and doesn't get forgotten.

dave.enyeart (Wed, 06 Mar 2019 20:34:11 GMT):
like round robin assignment rather than SME?

yacovm (Wed, 06 Mar 2019 20:34:55 GMT):
what's SME??

dave.enyeart (Wed, 06 Mar 2019 20:35:04 GMT):
subject matter expert

jyellick (Wed, 06 Mar 2019 20:35:34 GMT):
Right. And if you're assigned a CR clearly that I should review, and you can convince me to take ownership, great. For most of the feature work for instance, I would expect the maintainers in that squad to be owners. But "everyone tagged should be responsible" seems like a recipe for diffusion of responsibility where no one takes any action.

dave.enyeart (Wed, 06 Mar 2019 20:39:16 GMT):
ok, so how about if there is an obvious candidate reviewer, add them as a reviewer up front (we do this about half the time regardless). and if there is a CR that has had no attention for 7(?) days and no reviewer assigned, have the new automation assign a reviewer round robin.

yacovm (Wed, 06 Mar 2019 20:41:47 GMT):
how does a new contributer locate that candidate?

dave.enyeart (Wed, 06 Mar 2019 20:42:47 GMT):
they won't... if there is an obvious candidate reviewer 'we' can add them, if it falls through the cracks for 7 days it gets auto-assigned round robin

yacovm (Wed, 06 Mar 2019 20:42:53 GMT):
i just think we need to do an analysis of more quality and pin-point locations (code wise) that are neglected with respect to reviews

yacovm (Wed, 06 Mar 2019 20:43:11 GMT):
pointing at 81 CRs includes a lot of noise like documentation CRs, etc.

jyellick (Wed, 06 Mar 2019 20:50:43 GMT):
Personally, I know I am very bad about picking up CRs which I'm not explicitly added as a reviewer for. And, just because it's in my list to review doesn't necessarily mean it's got my full attention. For instance, I have 21 CRs I'm currently listed as a reviewer on, and the vast majority of those are feature squad related. I'm not even sure gerrit reviewer tags is the right approach. Even a simple google doc spreadsheet with assignments would work.

dave.enyeart (Wed, 06 Mar 2019 20:52:35 GMT):
ok, the world has heard some of our ideas... let's hear from the other 12 :)

suchith.arodi (Wed, 06 Mar 2019 21:41:56 GMT):
Has joined the channel.

muralisr (Wed, 06 Mar 2019 22:05:42 GMT):
Very broadly, there are two types of CRs .. one-ofs (bug fixes, docs, small features etc) and then the others that are part of a chain that are related and are broken up parts of large CRs. The later are the problem... takes more effort for a maintainer to jump in the middle ( as the person needs to be aware of the CRs leading up to it) and for the same reason hard to come up with a process to pick and assign them to arbitrary maintainer (even one familiar with the area). Any process for "assigning" maintainer to CR would have to take that into account .. so for perhaps assign one or two maintainers during the progression of the entire set

muralisr (Wed, 06 Mar 2019 22:05:57 GMT):
(not sure if that helps ... @dave.enyeart :-) )

binhn (Wed, 06 Mar 2019 22:40:46 GMT):
I'd like to discuss this with the maintainers here. Gari -1 on https://gerrit.hyperledger.org/r/#/c/29313/ > I really think we need to move this out of the core fabric repository and I also think we should just cut ties to the old way of doing things. We cannot continue to carry legacy with us ... chaincode which as already been built will continue to run and if people want to "upgrade" chaincode they use the new model On this particular feature, I like Gari's idea, but conventionally software, including open source, supports a period of deprecation to allow migration. If we want to break this, a major release would be the right time. Thoughts?

dave.enyeart (Thu, 07 Mar 2019 01:54:48 GMT):
@binhn Please see the chaincode build and launch proposal that was presented at the maintainer meeting today: https://gist.github.com/sykesm/0958550cc41b47f8b99b4f54697ac342

dave.enyeart (Thu, 07 Mar 2019 01:56:04 GMT):
It may provide a path for v1.x chaincode containers as well as 'cloud native' chaincode.

dave.enyeart (Thu, 07 Mar 2019 01:57:09 GMT):
BTW, I've created a Maintainer Meeting page in the Hyperledger wiki with meeting recordings: https://wiki.hyperledger.org/display/fabric/Maintainer+Meetings

dave.enyeart (Thu, 07 Mar 2019 01:57:09 GMT):
BTW, I've created a Maintainer Meeting page in the NEW Hyperledger wiki with meeting recordings: https://wiki.hyperledger.org/display/fabric/Maintainer+Meetings

dave.enyeart (Thu, 07 Mar 2019 01:58:59 GMT):
The new Confluence based wiki is much more powerful than the old wiki. It has native Jira integration, and we should be able to leverage it for all types of things including plans and design documents.

muralisr (Thu, 07 Mar 2019 02:59:56 GMT):
@dave.enyeart looking back at the comment, doesn't build and launch proposal addresses the comment Gari refers to. Ultimately we have to support both models (if only for a while) and the CRs just address that.

muralisr (Thu, 07 Mar 2019 02:59:56 GMT):
@dave.enyeart looking back at the comment, doesn't sound like build and launch proposal addresses the comment Gari refers to. Ultimately we have to support both models (if only for a while) and the CRs just address that.

dave.enyeart (Thu, 07 Mar 2019 03:14:57 GMT):
I thought Matt was suggesting builder/launcher to support both peer-driven chaincode build/launch as well as external build/launch.

muralisr (Thu, 07 Mar 2019 13:22:46 GMT):
@dave.enyeart he is... but the CRs have to do with _what_ on launching (basically, to connect back for the old model or to serve for the new)

muralisr (Thu, 07 Mar 2019 13:22:46 GMT):
@dave.enyeart he is... but the CRs have to do with _what_ on launching (basically, to connect back for the old model or to serve for the new) and so orthogonal to that on the face of it

muralisr (Thu, 07 Mar 2019 13:22:46 GMT):
@dave.enyeart he is... but the CRs have to do with _what_ on launching (basically, to connect back or to serve) and so orthogonal to that on the face of it

binhn (Thu, 07 Mar 2019 14:59:14 GMT):
@dave.enyeart thanks for the link; i read it; not much there, but unless i am missing something, it sounds like more runtime objects to manage = more complex

dave.enyeart (Thu, 07 Mar 2019 15:00:08 GMT):
it is a de-coupling to support multiple schemes without impacting peer code, like the cloud native

binhn (Thu, 07 Mar 2019 15:00:39 GMT):
my question above is more about our support for backward compatibility in this new cc model and Gari's comment, which I like as it would simplify things

dave.enyeart (Thu, 07 Mar 2019 15:02:16 GMT):
Will defer that question to @sykesm as he has been focusing in this area

binhn (Thu, 07 Mar 2019 15:03:06 GMT):
introducing another runtime object would not be necessary in that spirit as we would no longer need the old model

MHBauer (Thu, 07 Mar 2019 18:32:26 GMT):
Has joined the channel.

rangak (Thu, 07 Mar 2019 20:51:02 GMT):
Has joined the channel.

cbf (Thu, 07 Mar 2019 20:55:15 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=3acwnKAe8sPsBQPTo) @dave.enyeart I have it working... what I wanted and asked for was a) review and b) some initial manual cleanup so we don't start with a mass abandon

KyunghoKim (Tue, 12 Mar 2019 03:09:44 GMT):
Has joined the channel.

jlcs (Wed, 13 Mar 2019 14:12:19 GMT):
Has joined the channel.

DimaPdc (Fri, 15 Mar 2019 13:09:04 GMT):
Has joined the channel.

dave.enyeart (Fri, 15 Mar 2019 21:26:29 GMT):
@here Proposal to retire dormant fabric maintainers, please +1 to indicate agreement https://gerrit.hyperledger.org/r/#/c/30130/

rohanshrothrium (Wed, 20 Mar 2019 07:49:52 GMT):
Has joined the channel.

dave.enyeart (Wed, 20 Mar 2019 12:59:39 GMT):
@here Maintainer call starting in the next few minutes: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 20 Mar 2019 13:00:29 GMT):
*Release update*: - *v1.4.1* - Release candidate targeted for end of March, final release early April. Raft support is 'green' from system test perspective and is available for use today in release-1.4 branch. - *v2.0 alpha* - Prioritized right after v1.4.1, target mid April release. The new chaincode lifecycle support and token support will be highlighted in the v2.0 alpha with small tutorials so that users can provide feedback. Targeting mid-year for final v2.0 release. *fabric-samples* proposal - Similar to what we did recently for fabric-ca, there is a proposal to shift fabric-samples project to a one +2 policy (non-author code review). Additionally there is a proposal to split fabric-samples from fabric in terms of maintainers, with initial set of maintainers based on contribution and review activity the past 6 months. *CI Update* We have been focusing on CI improvements including emphasis on test flakes and CI failures. There are a new set of widgets in the Fabric Bugs and Tech Debt dashboard to track CI issues based on the new labels `ci-blocker`, `ci-failure`, `ci-flake`, `ci-first-failure`: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11706

lehors (Wed, 20 Mar 2019 13:17:07 GMT):
for reference, the CR I abandoned I was talking about is https://gerrit.hyperledger.org/r/#/c/28887/

lehors (Wed, 20 Mar 2019 13:17:35 GMT):
it did include a *change* to high-throughput that may still need to be applied, I will look into that

dave.enyeart (Wed, 20 Mar 2019 13:25:45 GMT):
As mentioned on the maintainer call, here is the new wiki location for playback schedule and recordings: https://wiki.hyperledger.org/display/fabric/playbacks

dave.enyeart (Wed, 20 Mar 2019 13:25:46 GMT):
And for maintainer meeting recordings: https://wiki.hyperledger.org/display/fabric/Maintainer+Meetings

lehors (Wed, 20 Mar 2019 13:26:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=2sPJwihLZxNBieyiW) after checking I see that high-throughput was fixed independently so we're good there

mbwhite (Wed, 20 Mar 2019 14:02:04 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=usYDyFsq3YP9KQZPu) @dave.enyeart Do we think this should be extended to the other repos?

sstone1 (Wed, 20 Mar 2019 14:07:42 GMT):
looks like gari is already on the case: https://gerrit.hyperledger.org/r/#/c/30251/

rjones (Wed, 20 Mar 2019 18:43:17 GMT):
@sstone1 need to follow up with a helpdesk ticket for the LDAP rejiggering

rjones (Wed, 20 Mar 2019 18:49:47 GMT):
@mastersingh24 Jim is also in: ```hyperledger-gerrit-fabric-chaincode-java-committers hyperledger-gerrit-fabric-sdk-node-committers```

rjones (Wed, 20 Mar 2019 18:50:01 GMT):
(that is his complete remaining membership)

rjones (Wed, 20 Mar 2019 18:56:00 GMT):
https://gerrit.hyperledger.org/r/#/q/owner:%22Jim+Zhang+%253Cjim_the_matrix%2540hotmail.com%253E%22

MHBauer (Thu, 21 Mar 2019 02:43:07 GMT):
how do I turn off/mute logging during the tests?

MHBauer (Thu, 21 Mar 2019 22:18:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=wpRRsyMqBAXHWTKq8) I found in the docs, and was told about `FABRIC_LOGGING_SPEC` which I used as `export FABRIC_LOGGING_SPEC=FATAL` to get some peace and quiet.

muralisr (Fri, 22 Mar 2019 14:23:46 GMT):
@MHBauer redirected the q to #fabric-peer-endorser-committer

mbanerjee (Mon, 25 Mar 2019 20:11:30 GMT):
Has joined the channel.

mbanerjee (Mon, 25 Mar 2019 20:13:02 GMT):
Is there a timeline for Hyperledger Fabric 2.0 release? If so, please share the details. Also is there going to be a GO SDK for Fabric?

rjones (Mon, 25 Mar 2019 20:40:11 GMT):
Has left the channel.

cbf (Tue, 26 Mar 2019 10:18:13 GMT):
there is a go sdk for fabric. fabric-sdk-go repo. It is not part of the formal release yet, but it is pretty decent

cbf (Tue, 26 Mar 2019 10:19:34 GMT):
As for the 2.0 release, we are working on 1.4.1 that integrates Raft consensus. Once that is out (shortly) we will be working on an alpha of 2.0

gregnotso (Tue, 26 Mar 2019 14:08:04 GMT):
@cbf is Raft replacing or just augmenting Kafka?

yacovm (Tue, 26 Mar 2019 14:08:21 GMT):
we will see how it fares

sykesm (Tue, 26 Mar 2019 14:23:02 GMT):
Seems we have an issue with current master

sykesm (Tue, 26 Mar 2019 14:23:20 GMT):
FAB-14700 Kafka2Raft validate broadcast

sykesm (Tue, 26 Mar 2019 14:23:37 GMT):
``` 08:56:17 # github.com/hyperledger/fabric/orderer/consensus/migration_test [github.com/hyperledger/fabric/orderer/consensus/migration.test] 08:56:17 orderer/consensus/migration/migration_test.go:461:29: undefined: etcdraft.Metadata 08:56:17 orderer/consensus/migration/migration_test.go:462:19: undefined: etcdraft.Metadata 08:56:17 orderer/consensus/migration/migration_test.go:486:20: undefined: etcdraft.Metadata 08:56:21 Makefile:217: recipe for target 'linter' failed 08:56:21 make: *** [linter] Error 2 08:56:21 + '[' 2 '!=' 0 ']' 08:56:21 + echo '------> make basic-checks native FAILED' 08:56:21 ------> make basic-checks native FAILED 08:56:21 + vote -m '"code checks are failed"' -l F1-VerifyBuild=-1 08:56:21 + ssh -p 29418 hyperledger-jobbuilder@gerrit.hyperledger.org gerrit review 30374,2 --notify '"NONE"' -m '"code checks are failed"' -l F1-VerifyBuild=-1 ```

jyellick (Tue, 26 Mar 2019 14:23:45 GMT):
@tock Could you please take a look?

tock (Tue, 26 Mar 2019 14:23:45 GMT):
Has joined the channel.

sykesm (Tue, 26 Mar 2019 14:23:47 GMT):
also, integration tests failed ias well

sykesm (Tue, 26 Mar 2019 14:23:47 GMT):
also, integration tests failed as well

sykesm (Tue, 26 Mar 2019 14:24:51 GMT):
integration test failures were introduced with something in the following: ``` $ git lol HEAD..origin/master * c0a9673a1 (origin/master, origin/HEAD) Merge "FAB-14700 Kafka2Raft validate broadcast" |\ | * 2d924d0d8 FAB-14700 Kafka2Raft validate broadcast * 84408d3f2 Merge "FAB-14777 remove unreferenced items from makefile" |\ | * a12c8edc0 FAB-14777 remove unreferenced items from makefile * d032f2cbc Merge "FAB-14735 don't check consenters if wasn't changed" |\ | * d1bdc3f32 FAB-14735 don't check consenters if wasn't changed * 878ed4bf9 Merge "[FAB-14433] Add Raft links to Kafka doc" |\ | * d5e139873 [FAB-14433] Add Raft links to Kafka doc * acf4c944d Merge "[FAB-14432] Add Raft text to Upgrade doc" * bd4c82c24 [FAB-14432] Add Raft text to Upgrade doc ``` if we exclude doc and makefile changes, it's in the orderer/kafka/migration area as well

tock (Tue, 26 Mar 2019 14:26:12 GMT):
@jyellick @sykesm already pushed a CR to fix this: https://gerrit.hyperledger.org/r/#/c/30409/

sykesm (Tue, 26 Mar 2019 14:26:52 GMT):
yes - 7 minutes ago.

tock (Tue, 26 Mar 2019 14:27:23 GMT):
indeed

sykesm (Tue, 26 Mar 2019 14:27:46 GMT):
were the integration test issues addressed as well?

sykesm (Tue, 26 Mar 2019 14:28:17 GMT):
some other CR I need to look at?

tock (Tue, 26 Mar 2019 14:28:19 GMT):
the CR passed all CI stages, including integration tests

tock (Tue, 26 Mar 2019 14:30:11 GMT):
No other CRs, this fixes the problem.

duwenhui (Thu, 28 Mar 2019 04:20:06 GMT):
Has joined the channel.

dave.enyeart (Thu, 28 Mar 2019 17:02:12 GMT):
@here We plan to cut Fabric v1.4.1-rc1 (release candidate) tomorrow, and then cut the final release in mid-April pending feedback from the community, especially on the new Raft feature that many are interested in trying. ------------------------ With v1.4.1 behind us, we need renewed focus on the CI issues and flakes that have been increasingly impacting developer productivity. We will tackle on a few fronts: 1) There are known issues with the CI infrastructure, specifically IO issues that increase test time and the chance of flakes, especially in timing dependent tests in areas such as gossip and Raft. 1a) We are actively pursuing CI infrastructure improvements with Linux Foundation. 1b) @rameshthoomu is looking into shifting Fabric integration test job from x86 to s390 infrastructure, since integration test has gotten worse both in execution time and flakes. s390 infrastructure has been faster and less flakey than the Linux Foundation x86 infrastructure. 2) Improve Fabric unit and integration tests - Fix flakes and refactor tests as needed to improve execution times throughout the project, with specific focus (but not limited to) gossip and orderer/Raft. -------------------------- To reiterate prior guidance around flakes --- we will only improve the situation if we are ALL vigilant about opening Jira bugs for flakes: When you see a unit/integration test failure in one of your CRs, paste the test error and associated Jira number into the gerrit comments so that people know it has been investigated ( @C0rWin has volunteered to do this for some of the recently observed flakes). If the ci-flake bug is already opened in Jira: - add a comment stating that you’ve seen it again. If this is the 2nd or 3rd time seen, go ahead and change bug priority to High. Worst offenders should be Highest priority and labeled with `ci-blocker`. If a flake bug is not yet opened, please open a new Jira bug: - Put the test name in the Summary - Copy/paste the failure snippet into description - Fill in component (we will rely on squad leads and component owners to triage, starting with the High priorities) - Add label `ci-flake`.

dave.enyeart (Thu, 28 Mar 2019 17:06:30 GMT):
Everybody should look at the Bugs and Tech Debt dashboard daily, especially the CI Blockers and CI Flakes:

dave.enyeart (Thu, 28 Mar 2019 17:06:30 GMT):
-------------------------- Everybody should look at the Bugs and Tech Debt dashboard daily, especially the CI Blockers and CI Flakes:

dave.enyeart (Thu, 28 Mar 2019 17:06:31 GMT):
https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11706

tongli (Thu, 28 Mar 2019 17:14:53 GMT):
@dave.enyeart dave, i have been working with a group people on the interop project, the working group has come up with a flow and some code to allow one to expand the network (adding new orgs to existing network), I would like to share what we came up with and the chaincode and programs with fabric developer community, when is the best time to show that to the fabric dev community?

dave.enyeart (Thu, 28 Mar 2019 17:25:13 GMT):
@tongli Do you mean Fabric open source developers? Or do you mean Fabric developer users?

tongli (Thu, 28 Mar 2019 17:31:22 GMT):
open source developers @dave.enyeart

dave.enyeart (Thu, 28 Mar 2019 17:31:57 GMT):
@tongli Feel free to schedule yourself on the playback wiki... preferred timeslot is Tuesdays 10am US Eastern: https://wiki.hyperledger.org/display/fabric/playbacks

tongli (Thu, 28 Mar 2019 17:32:18 GMT):
so how many people normally participate in that meeting?

tongli (Thu, 28 Mar 2019 17:32:59 GMT):
we would like to get developers opinions on what we came up with and we also have few questions. more like a show and tell, and confirmation sort of things.

tongli (Thu, 28 Mar 2019 17:34:07 GMT):
@dave.enyeart ^^^

dave.enyeart (Thu, 28 Mar 2019 17:34:22 GMT):
around 15 usually

tongli (Thu, 28 Mar 2019 17:34:46 GMT):
most of them are maintainers?

dave.enyeart (Thu, 28 Mar 2019 17:34:47 GMT):
most of the maintainers try to attend, and then some others

tongli (Thu, 28 Mar 2019 17:34:55 GMT):
cool. cool.

tongli (Thu, 28 Mar 2019 17:35:24 GMT):
let me try to schedule a time on Tuesday then. Thanks @dave.enyeart

dave.enyeart (Thu, 28 Mar 2019 17:35:28 GMT):
I send invites to maintainers and presenters, and announce to others via mailing list and rocket chat

tongli (Thu, 28 Mar 2019 17:35:41 GMT):
k. thanks again.

dave.enyeart (Fri, 29 Mar 2019 12:47:37 GMT):
@jyellick and all @here We are getting a few final Raft doc fixes in this morning, then I will proceed with v1.4.1 release candidate. Any other release candidate blockers?

cbf (Fri, 29 Mar 2019 14:14:42 GMT):
awesome!

dave.enyeart (Fri, 29 Mar 2019 15:00:15 GMT):
I have some conflicts the next couple hours, we'll start mid-afternoon.

dave.enyeart (Fri, 29 Mar 2019 18:01:08 GMT):
@here MERGE FREEZE in release-1.4 while I prepare the release CR

dave.enyeart (Fri, 29 Mar 2019 21:18:33 GMT):
@here I was planning to just do release candidate for fabric. However, I realized that in release-1.4 the version of Fabric is still tightly coupled with the version of java chaincode javaenv and node chaincode baseimage, therefore the rc would not work for java or node chaincodes. I have a CR that allows Fabric to run with any 'latest' version of javaenv or baseimage: https://gerrit.hyperledger.org/r/#/c/30552/

dave.enyeart (Fri, 29 Mar 2019 21:18:33 GMT):
@here I was planning to just do release candidate for fabric (not fabric-ca, chaincodes, sdks). However, I realized that in release-1.4 the version of Fabric is still tightly coupled with the version of java chaincode javaenv and node chaincode baseimage, therefore the rc would not work for java or node chaincodes. I have a CR that allows Fabric to run with any 'latest' version of javaenv or baseimage: https://gerrit.hyperledger.org/r/#/c/30552/

dave.enyeart (Fri, 29 Mar 2019 21:18:35 GMT):
The same had been done by @mastersingh24 in v2.0 in FAB-11096 a couple months ago, but I only realized today that release-1.4 was not set up the same way.

dave.enyeart (Fri, 29 Mar 2019 21:19:56 GMT):
I suggest we merge this for the release candidate today. Then next week we can discuss whether to keep like this, or revert to prior behavior for the final v1.4.1 release.

dave.enyeart (Fri, 29 Mar 2019 21:19:57 GMT):
Thoughts?

yacovm (Fri, 29 Mar 2019 21:25:10 GMT):
+1 as long as we test it ;)

dave.enyeart (Fri, 29 Mar 2019 21:26:53 GMT):
I've tested locally, looks good

dave.enyeart (Fri, 29 Mar 2019 21:46:11 GMT):
@yacovm can I talk you into upgrading your +1 to a +2?

dave.enyeart (Fri, 29 Mar 2019 22:03:50 GMT):
Note, the merge job will also run SDK tests and node chaincode tests. We wait for merge job to succeed before tagging and pushing to dockerhub

yacovm (Fri, 29 Mar 2019 22:39:13 GMT):
100 fungible fabtokens and you have my +2

dave.enyeart (Fri, 29 Mar 2019 23:46:19 GMT):
thanks, we're good now - pushing to dockerhub

guoger (Sat, 30 Mar 2019 02:07:59 GMT):
i got a related question, do we have regression tests?

dave.enyeart (Sat, 30 Mar 2019 02:42:36 GMT):
@guoger The merge job on the release CR (and any CR) does e2e regression tests. There is also a larger nightly test bucket. We also pull down the published images and binaries and run the automated tutorials against them. For example we did byfn (go, java, node chaincode, `-o etcdraft`), eyfn, fabcar.

dave.enyeart (Sat, 30 Mar 2019 02:43:28 GMT):
All is good - I've tagged fabric and fabric-samples with v1.4.1-rc1.

guoger (Sat, 30 Mar 2019 02:44:27 GMT):
@dave.enyeart do those test against a mixed version of fabric? could you point me to the code? thx!

dave.enyeart (Sat, 30 Mar 2019 02:45:37 GMT):
not mixed version, but the intent with the automated 'interop' tests is that you could pick any versions

dave.enyeart (Sat, 30 Mar 2019 02:45:37 GMT):
not mixed version yet, but the intent with the automated 'interop' tests is that you could pick any versions

guoger (Sat, 30 Mar 2019 02:45:46 GMT):
actually, regression test is a wrong word, i was mostly thinking of compatibility test

guoger (Sat, 30 Mar 2019 02:45:46 GMT):
actually, i was wrong using word "regression test", i was mostly thinking of compatibility test

dave.enyeart (Sat, 30 Mar 2019 02:46:30 GMT):
we are investing in this 'interop' suite

dave.enyeart (Sat, 30 Mar 2019 02:47:00 GMT):
we do 'compatibility' tests with older SDKs and newer Fabric/Fabric-CA

dave.enyeart (Sat, 30 Mar 2019 02:47:00 GMT):
we do 'compatibility' tests with older SDKs and newer Fabric/Fabric-CA, in order to support upgrades well

dave.enyeart (Sat, 30 Mar 2019 02:49:03 GMT):
those are only semi-automated currently... somebody has to pull a certain SDK level and fabric level then run the SDK integration tests and look at results. Typically those are run for minor releases not third digit releases.

dave.enyeart (Sat, 30 Mar 2019 02:51:11 GMT):
@latitiah could you do a brief show and tell this week on how far you've gotten with 'interop' tests and next steps?

guoger (Sat, 30 Mar 2019 02:55:11 GMT):
actually, what promise do we have w.r.t compatibility? do we strictly follow semver? or as long as releases in 1.4.x are compatible with each other, we are good?

dave.enyeart (Sat, 30 Mar 2019 03:11:41 GMT):
Fabric components are compatible within a major release, e.g. any 1.x.x. Any exceptions to semver would be very rare and would be highlighted in release notes. Crossing a major release boundary may see some incompatibilities, but again they are kept to a minimum and release noted, and typically gated behind a 'capability' in order to support networks with mixed versions.

dave.enyeart (Sat, 30 Mar 2019 03:11:41 GMT):
Fabric components are compatible within a major release, e.g. any 1.x.x. Any exceptions to semver would be very rare, require maintainer approval, and would be highlighted in release notes. Crossing a major release boundary may see some incompatibilities, but again they are kept to a minimum and release noted, and typically gated behind a 'capability' in order to support networks with mixed versions.

dave.enyeart (Sat, 30 Mar 2019 03:11:41 GMT):
Fabric components are compatible within a major release, e.g. any 1.x.x. Any exceptions to semver would be very rare, require majority maintainer approval, and would be highlighted in release notes. Crossing a major release boundary may see some incompatibilities, but again they are kept to a minimum and release noted, and typically gated behind a 'capability' in order to support networks with mixed versions.

dave.enyeart (Sat, 30 Mar 2019 03:16:58 GMT):
Getting back to the v1.4.1-rc1 release... fabric and fabric-samples are tagged and can be downloaded. I've updated instructions at:

dave.enyeart (Sat, 30 Mar 2019 03:17:00 GMT):
https://hyperledger-fabric.readthedocs.io/en/release-1.4/install.html

dave.enyeart (Sat, 30 Mar 2019 03:17:20 GMT):

Clipboard - March 29, 2019 11:17 PM

dave.enyeart (Sat, 30 Mar 2019 03:19:08 GMT):
I plan to send a message to the mailing list along those lines on Saturday.... let me know if anybody has concerns with that approach

dave.enyeart (Sat, 30 Mar 2019 03:27:33 GMT):
Final CRs to close out v1.4.1-rc1 release process:

dave.enyeart (Sat, 30 Mar 2019 03:27:39 GMT):
https://gerrit.hyperledger.org/r/#/c/30559/

dave.enyeart (Sat, 30 Mar 2019 03:27:48 GMT):
https://gerrit.hyperledger.org/r/#/c/30548/

dave.enyeart (Sat, 30 Mar 2019 20:11:55 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v1.4.1-rc1 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/5788 ----------------------------------------------------------------------

baohua (Mon, 01 Apr 2019 01:57:54 GMT):
Great!

pandrejko (Tue, 02 Apr 2019 12:15:03 GMT):
Maintainers - In preparation for the Alpha 2.0 release it would be good to get some more reviews on the FabToken documentation and you can take it for a spin - https://gerrit.hyperledger.org/r/#/c/29266/ https://gerrit.hyperledger.org/r/#/c/30509/

gumballwabbit (Wed, 03 Apr 2019 01:30:10 GMT):
Has joined the channel.

gumballwabbit (Wed, 03 Apr 2019 01:47:18 GMT):
Hi, I am interested in contributing to the the Hyperledger Project by creating SDKs in dotnet and haskell, I see for that I need to put in a proposal, however, before creating a proposal, it says,

gumballwabbit (Wed, 03 Apr 2019 01:47:20 GMT):
The seed of a new project has to be vetted in a public forum before creating a project proposal. It is best if the project has technical champions who believe in the project and are the maintainers of the project. The technical champions can change in the middle of the project.

gumballwabbit (Wed, 03 Apr 2019 01:47:53 GMT):
where can i discuss these?

gumballwabbit (Wed, 03 Apr 2019 01:48:09 GMT):
or is there a channel that this can be posted on

dave.enyeart (Wed, 03 Apr 2019 12:33:56 GMT):
@here Maintainer meeting at the top of the hour: https://zoom.us/my/hyperledger.community.3 Agenda topics so far: Release update: v1.4.1-rc1 with Raft support and new operational metrics and health checks delivered March 29th: https://lists.hyperledger.org/g/fabric/message/5788 v2.0 alpha targeted for mid-April: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 We have a focused effort to address tech debt, especially in the area of unit test and integration test 'flakes' and execution time. See the Bugs and Tech Debt dashboard: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11706 Update to Coding Guidelines: https://logs.hyperledger.org/production/vex-yul-hyp-jenkins-3/fabric-docs-build-x86_64/1669/html/style-guides/go-style.html Documentation Multi-Language Support Proposal from Rich Zhao.

dave.enyeart (Wed, 03 Apr 2019 15:12:35 GMT):
Maintainer meeting recording is available at https://wiki.hyperledger.org/display/fabric/Maintainer+Meetings

lehors (Thu, 04 Apr 2019 16:06:55 GMT):
fyi, I restarted my old win7 box and successfully used 1.4.1-rc1

lehors (Thu, 04 Apr 2019 16:06:55 GMT):
fyi, I restarted my old win7 box and successfully used/tested 1.4.1-rc1

lehors (Thu, 04 Apr 2019 16:08:19 GMT):
both within docker toolbox and within vagrant with a local build I was able to run

lehors (Thu, 04 Apr 2019 16:08:39 GMT):
I tested with BYFN+EYFN

lehors (Thu, 04 Apr 2019 16:10:05 GMT):
the longest was to go through all the system updates required after several months of downtime :)

mastersingh24 (Thu, 04 Apr 2019 17:36:48 GMT):
`old win7 box` - @lehors we know it's your current box. no need to be ashamed LOL

baohua (Mon, 08 Apr 2019 13:40:37 GMT):
Guess Microsoft would like or hate it ;-)

dave.enyeart (Mon, 08 Apr 2019 16:09:16 GMT):
@here We are targeting v2.0.0-alpha release for first half of this week, and v1.4.1 release for second half of this week. Please be judicious about merges into master and release-1.4 this week. Nothing de-stabilizing please.

baohua (Tue, 09 Apr 2019 01:59:46 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=L4jHvHbhScKPWkgru) @dave.enyeart :thumbsup:

dave.enyeart (Tue, 09 Apr 2019 12:02:50 GMT):
https://gerrit.hyperledger.org/r/#/c/30511/ token cli docs

dave.enyeart (Tue, 09 Apr 2019 12:02:50 GMT):
@here I will CRs required for v2.0 alpha release: https://gerrit.hyperledger.org/r/#/c/30511/ token cli docs

dave.enyeart (Tue, 09 Apr 2019 12:02:50 GMT):
@here I will post CRs required for v2.0 alpha release: https://gerrit.hyperledger.org/r/#/c/30511/ token cli docs

dave.enyeart (Tue, 09 Apr 2019 12:03:12 GMT):
https://gerrit.hyperledger.org/r/#/c/30817/ byfn couchdb docs

dave.enyeart (Tue, 09 Apr 2019 12:12:10 GMT):
https://gerrit.hyperledger.org/r/#/c/29266/ fabtoken main doc

dave.enyeart (Tue, 09 Apr 2019 12:28:44 GMT):
https://gerrit.hyperledger.org/r/#/c/30827/ Get BYFN to work with Java chaincode

dave.enyeart (Tue, 09 Apr 2019 13:01:34 GMT):
@here I'm calling for a MERGE FREEZE in master branches today so that we can release v2.0.0-alpha

dave.enyeart (Tue, 09 Apr 2019 13:01:56 GMT):
Let's merge only what is needed for v2.0.0-alpha

dave.enyeart (Tue, 09 Apr 2019 13:02:14 GMT):
Need the above merged please

dave.enyeart (Tue, 09 Apr 2019 13:02:26 GMT):
Any other must-have blockers for v2.0.0-alpha?

dave.enyeart (Tue, 09 Apr 2019 14:30:06 GMT):
@here What's New for v2.0.0 Alpha doc: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html

dave.enyeart (Tue, 09 Apr 2019 14:30:10 GMT):
Please review

dave.enyeart (Tue, 09 Apr 2019 14:30:22 GMT):
I'll fix the couple broken links

mastersingh24 (Tue, 09 Apr 2019 14:30:27 GMT):
I merged the updated Node SDK sample as well

mastersingh24 (Tue, 09 Apr 2019 14:30:27 GMT):
I merged the updated Node SDK token sample as well

dave.enyeart (Tue, 09 Apr 2019 14:30:47 GMT):
Thanks, we'll likely do Node SDK a few days later

dave.enyeart (Tue, 09 Apr 2019 14:30:47 GMT):
Thanks, we'll likely release Node SDK a few days later

dave.enyeart (Tue, 09 Apr 2019 14:31:02 GMT):
Most of the alpha material targets CLI

mastersingh24 (Tue, 09 Apr 2019 14:31:05 GMT):
it was actually an update to fabric-samples

mastersingh24 (Tue, 09 Apr 2019 14:31:28 GMT):
https://gerrit.hyperledger.org/r/30309

dave.enyeart (Tue, 09 Apr 2019 14:31:38 GMT):
ok, since samples references 'unstable' snapshots should be ok

mastersingh24 (Tue, 09 Apr 2019 14:31:43 GMT):
right

dave.enyeart (Tue, 09 Apr 2019 14:32:04 GMT):
For releases I typically update that to be the release version, but for alpha I'll keep as 'unstable'

mastersingh24 (Tue, 09 Apr 2019 14:33:55 GMT):
I did not do a grammar check, but the release notes look good ;)

bretharrison (Tue, 09 Apr 2019 15:22:40 GMT):
Chaincode Node published version `2.0.0-alpha` tagged `alpha` https://www.npmjs.com/package/fabric-shim

dave.enyeart (Tue, 09 Apr 2019 15:50:22 GMT):
Thanks

dave.enyeart (Tue, 09 Apr 2019 15:50:54 GMT):
@here Please review fabric v2.0.0-release CR including release notes: https://gerrit.hyperledger.org/r/#/c/30833/

dave.enyeart (Tue, 09 Apr 2019 15:50:54 GMT):
@here Please review fabric v2.0.0-alpha release CR including release notes: https://gerrit.hyperledger.org/r/#/c/30833/

dave.enyeart (Tue, 09 Apr 2019 16:06:29 GMT):
https://gerrit.hyperledger.org/r/#/c/30832/ fix What's New links

dave.enyeart (Tue, 09 Apr 2019 18:48:05 GMT):
Need +2s on the two above CRs

dave.enyeart (Tue, 09 Apr 2019 18:48:05 GMT):
@here Need +2s on the two above CRs

dave.enyeart (Tue, 09 Apr 2019 19:59:39 GMT):
@here https://gerrit.hyperledger.org/r/#/c/30844/ fabric-ca release CR and release notes for review

dave.enyeart (Wed, 10 Apr 2019 03:35:14 GMT):
Everything looks good with 2.0.0-alpha across fabric, fabric-ca, all three chaincode languages. Pushed to dockerhub. I will tag release.

dave.enyeart (Wed, 10 Apr 2019 06:53:58 GMT):
Since there are some major announcements with 2.0.0-alpha, please review the proposed mailing list posting before I send it Wednesday:

dave.enyeart (Wed, 10 Apr 2019 06:54:08 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the v2.0 Alpha release. v2.0 is targeted for the middle of the year, but given there are some major new features coming, we wanted to provide plenty of time for the Fabric community to try it out and provide feedback. The largest change you'll see is an improved lifecycle for managing chaincode that supports both centralized and decentralized governance models. The decentralized chaincode governance model enables organizations to come to agreement on a chaincode before it is made available for interacting with the ledger. Specifically, a sufficient number of organizations must approve the definition of a chaincode before it becomes active, as defined by configurable polices on a Fabric channel. The v2.0 Alpha also provides Fabric's first native token support for your trial. Fabric tokens are governed by a UTXO model where tokens can be issued, transferred, and redeemed. All peers on a channel validate each transaction, ensuring the transactor's authorization to the tokens and preventing double spends. Also, the Raft-based ordering service that is being delivered in Fabric v1.4.1 is also available in the v2.0 Alpha. Finally, the Fabric Docker images will now based on Alpine Linux, providing a more compact and secure container architecture. Refer to the What's New documentation for all the details: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Wed, 10 Apr 2019 06:54:08 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the v2.0 Alpha release. v2.0 is targeted for the middle of the year, but given there are some major new features coming, we wanted to provide plenty of time for the Fabric community to try it out and provide feedback. The largest change you'll see is an improved lifecycle for managing chaincode that supports both centralized and decentralized governance models. The decentralized chaincode governance model enables organizations to come to agreement on a chaincode before it is made available for interacting with the ledger. Specifically, a sufficient number of organizations must approve the definition of a chaincode before it becomes active, as defined by configurable polices on a Fabric channel. The v2.0 Alpha also provides Fabric's first native token support for your trial. Fabric tokens are governed by a UTXO model where tokens can be issued, transferred, and redeemed. All peers on a channel validate each transaction, ensuring the transactor's authorization to the tokens and preventing double spends. Also, the Raft-based ordering service that is being delivered in Fabric v1.4.1 is also available in the v2.0 Alpha. Finally, the Fabric Docker images will now be based on Alpine Linux, providing a more compact and secure container architecture. Refer to the What's New documentation for all the details: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Wed, 10 Apr 2019 06:54:08 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the v2.0 Alpha release. v2.0 is targeted for the middle of the year, but given there are some major new features coming, we wanted to provide plenty of time for the Fabric community to try it out and provide feedback. The largest change you'll see is an improved lifecycle for managing chaincode that supports both centralized and decentralized governance models. The decentralized chaincode governance model enables organizations to come to agreement on a chaincode before it is made available for interacting with the ledger. Specifically, a sufficient number of organizations must approve the definition of a chaincode before it becomes active, as defined by configurable policies on a Fabric channel. The v2.0 Alpha also provides Fabric's first native token support for your trial. Fabric tokens are governed by a UTXO model where tokens can be issued, transferred, and redeemed. All peers on a channel validate each transaction, ensuring the transactor's authorization to the tokens and preventing double spends. Also, the Raft-based ordering service that is being delivered in Fabric v1.4.1 is also available in the v2.0 Alpha. Finally, the Fabric Docker images will now be based on Alpine Linux, providing a more compact and secure container architecture. Refer to the What's New documentation for all the details: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Wed, 10 Apr 2019 11:58:36 GMT):
Since I wasn't explicit... MERGE FREEZE lifted

cbf (Wed, 10 Apr 2019 12:15:30 GMT):
LGTM thanks!

troyronda (Wed, 10 Apr 2019 14:33:11 GMT):
Hi folks - I'm wondering if there are any thoughts on a canonical import path for protos between various Fabric Go projects? Historically, the fabric-sdk-go project has contained the protos under its own namespace (github.com/hyperledger/fabric-sdk-go/...). There are some SDK functions that return the protobuf types (using the SDK’s copy of the protos, and therefore, the SDK’s types). Going forward, it would be nice if we could return compatible/canonical types. Would love to hear your thoughts.

dave.enyeart (Wed, 10 Apr 2019 14:42:25 GMT):
@sykesm has a roadmap in mind to address this, let's see if we can find him...

dave.enyeart (Wed, 10 Apr 2019 14:52:26 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v2.0.0-alpha RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/5851 ----------------------------------------------------------------------

dave.enyeart (Wed, 10 Apr 2019 15:21:09 GMT):
@here We decided not to tag v2.0.0-alpha as `latest` in dockerhub, since that would confuse existing Fabric v1.4 LTS users.

dave.enyeart (Wed, 10 Apr 2019 15:21:16 GMT):
@MHBauer suggested not using `latest` ever, which I tend to agree with.

dave.enyeart (Wed, 10 Apr 2019 15:21:22 GMT):
It causes all kinds of confusion, as this article details pretty well: https://container-solutions.com/docker-latest-confusion/

dave.enyeart (Wed, 10 Apr 2019 15:21:53 GMT):
With release v1.4.1 targeted for tomorrow, we have an opportunity to remove `latest` tag and release note it and announce it. Thoughts?

dave.enyeart (Wed, 10 Apr 2019 16:13:15 GMT):
Discussed with Matt and we're thinking v2.0 release mid-year would be a good opportunity to retire `latest` tag

dave.enyeart (Thu, 11 Apr 2019 04:41:51 GMT):
@here fabric maintainers - please use +1 to vote for a new list of fabric-samples maintainers as discussed at a prior maintainer call. The CR also proposes to switch fabric-samples to a single +2 non-author code review policy.

dave.enyeart (Thu, 11 Apr 2019 12:06:27 GMT):
@here We will start release process for v1.4.1 across all components. I don't know of any blockers or CRs that need to get merged first. Let me know if you have any.

dave.enyeart (Thu, 11 Apr 2019 12:58:33 GMT):
@here , I have not heard of any blockers so I will call for MERGE FREEZE in release-1.4 branches.

dave.enyeart (Thu, 11 Apr 2019 12:59:03 GMT):
I've pushed release CR for fabric v1.4.1 for review: https://gerrit.hyperledger.org/r/#/c/30888/

tongli (Thu, 11 Apr 2019 13:04:35 GMT):
@dave.enyeart we have to reschedule that again, we are not ready today to present. Can we push this back to 4/23 10:00am?

dave.enyeart (Thu, 11 Apr 2019 13:16:22 GMT):
@tongli Sure thing

dave.enyeart (Thu, 11 Apr 2019 13:16:57 GMT):
@tongli Please respond to the fabric mailing list announcement as such

tongli (Thu, 11 Apr 2019 13:46:27 GMT):
@dave.enyeart Thanks very much!

dave.enyeart (Thu, 11 Apr 2019 13:47:12 GMT):
@tongli you want me to send the fabric mailing list announcement, or are you doing it?

tongli (Thu, 11 Apr 2019 13:47:45 GMT):
@dave.enyeart if you can, that will be awesome.

dave.enyeart (Thu, 11 Apr 2019 13:47:50 GMT):
doing now

tongli (Thu, 11 Apr 2019 13:47:55 GMT):
thanks so much!

dave.enyeart (Thu, 11 Apr 2019 13:48:03 GMT):
let's delete these messages... don't want to disrupt release messages

cbf (Thu, 11 Apr 2019 14:19:27 GMT):
CI complete, I +2ed

mastersingh24 (Thu, 11 Apr 2019 14:25:53 GMT):
Dave ... +2 as well ... you can do the merge honors when ready

baohua (Thu, 11 Apr 2019 14:48:43 GMT):
+1!

yacovm (Thu, 11 Apr 2019 14:56:33 GMT):
safe to merge

dave.enyeart (Thu, 11 Apr 2019 15:11:31 GMT):
@here And here's the fabric-ca release CR for review: https://gerrit.hyperledger.org/r/#/c/30891/

dave.enyeart (Thu, 11 Apr 2019 18:32:12 GMT):
v1.4.1 released - tagged fabric, fabric-ca, fabric-chaincode-node, fabric-chaincode-java, fabric-sdk-node, fabric-samples

dave.enyeart (Thu, 11 Apr 2019 18:32:32 GMT):
MERGE FREEZE lifted in release-1.4

dave.enyeart (Thu, 11 Apr 2019 20:51:09 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v1.4.1 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/5862 ----------------------------------------------------------------------

dave.enyeart (Fri, 12 Apr 2019 14:28:14 GMT):
@here I will be out of office until April 23rd.

dave.enyeart (Fri, 12 Apr 2019 14:28:24 GMT):
For the maintainer meeting next week I actually didn't have any special agenda topics yet... we walked through the v2.0 epics last time, and of course we've just released v2.0.0-alpha and v1.4.1.

dave.enyeart (Fri, 12 Apr 2019 14:28:33 GMT):
Some others are also out of office so we could potentially cancel it unless some agenda topics come up here.

dave.enyeart (Fri, 12 Apr 2019 14:28:43 GMT):
@cbf could I ask you to make the call next week of whether the meeting is on or off?

dave.enyeart (Fri, 12 Apr 2019 14:28:53 GMT):
In terms of what's next, focus for the immediate term has shifted to closing down remaining odds and ends for v2.0, as well as tackling tech debt that has built up in various areas.

dave.enyeart (Fri, 12 Apr 2019 14:29:00 GMT):
Various maintainers are actively driving those debt items (you know who you are!).

dave.enyeart (Fri, 12 Apr 2019 14:29:06 GMT):
See tech debt dashboard especially the right-side widgets: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11706 .

dave.enyeart (Fri, 12 Apr 2019 14:29:13 GMT):
If you feel there is something else critical please tag it in Jira as v2.0 with priority Highest/High so that it gets visibility on the dashboard.

rjones (Sat, 13 Apr 2019 00:07:06 GMT):
Has joined the channel.

rjones (Sat, 13 Apr 2019 00:07:18 GMT):
Could I ask Fabric maintainers to please join https://lists.hyperledger.org/g/maintainers ? I'd appreciate it.

baohua (Sat, 13 Apr 2019 09:18:45 GMT):
Done, thanks!

rjones (Tue, 16 Apr 2019 00:26:01 GMT):
Hi. Who could route this bug. We have a developer waiting for review of a design doc for IDEMIX implementation for node and they keep getting shuffled around. https://jira.hyperledger.org/browse/FABN-689?focusedCommentId=59222&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-59222

jyellick (Wed, 17 Apr 2019 04:29:13 GMT):
@cbf Above @dave.enyeart asked you to make the call whether we would hold the maintainers meeting or not. What's the call?

cbf (Wed, 17 Apr 2019 12:07:25 GMT):
do we have an agenda?

cbf (Wed, 17 Apr 2019 12:07:46 GMT):
I can drive if needed

cbf (Wed, 17 Apr 2019 12:08:17 GMT):
@all lets do the maintainer call

cbf (Wed, 17 Apr 2019 12:08:21 GMT):
I can drive

cbf (Wed, 17 Apr 2019 13:25:20 GMT):
@dave.enyeart a few key people missing, but here's the jist of the call

cbf (Wed, 17 Apr 2019 13:26:17 GMT):
lifecycle, programming model, raft and token epics well contained for 2.0

cbf (Wed, 17 Apr 2019 13:27:02 GMT):
peer and chaincode cloud native support has had some reviews, @muralisr reworked, and could use some more reviews

cbf (Wed, 17 Apr 2019 13:27:59 GMT):
we need an update from @JonathanLevi on IDEMIX revocation

cbf (Wed, 17 Apr 2019 13:28:41 GMT):
we reviewed the tech debt backlog highlighting areas that need attention (espically flakes and highest priority)

davidkhala (Thu, 18 Apr 2019 12:09:12 GMT):
Has joined the channel.

davidkhala (Thu, 18 Apr 2019 12:11:17 GMT):
Dear maintainer, I am the creator of https://jira.hyperledger.org/browse/FABN-1185

davidkhala (Thu, 18 Apr 2019 12:13:04 GMT):
I proposed it at the last night of 1.4.0, Bret appreciate the idea and wanted to work it out together, but I thought he is so occupied

davidkhala (Thu, 18 Apr 2019 12:13:04 GMT):
I proposed it at the last night of 1.4.0, Bret appreciated the idea and wanted to work it out together, but maybe he is so occupied recently

davidkhala (Thu, 18 Apr 2019 12:13:22 GMT):
Bret said : `I like your idea of the `connect` and would like to expand on it by making it the process to work with a peer or orderer. Make a `connect` or `open-session` call required by the application before using the orderer or peer. This will only be done once and then the endpoint would be usable. There could be a `ping` or some sort of connection check also.`

davidkhala (Thu, 18 Apr 2019 12:13:22 GMT):
Bret said : I like your idea of the `connect` and would like to expand on it by making it the process to work with a peer or orderer. Make a `connect` or `open-session` call required by the application before using the orderer or peer. This will only be done once and then the endpoint would be usable. There could be a `ping` or some sort of connection check also.

davidkhala (Thu, 18 Apr 2019 12:14:34 GMT):
During my progress, I find myself stuck one point that we have make decision whether to change the `connect` function in `ChannelEventHub`

davidkhala (Thu, 18 Apr 2019 12:14:34 GMT):
During my progress, I find myself stuck one point that we have to make decision whether to change the `connect` function in `ChannelEventHub`

davidkhala (Thu, 18 Apr 2019 12:15:51 GMT):
if we unify the usage of 'grpc.waitForReady', the `channelEventHub.connect` will be an `async/await` nodejs function, this pattern will conflict with current `callback` design

davidkhala (Thu, 18 Apr 2019 12:16:51 GMT):
Maybe I could prepare a design document first?

richzhao (Mon, 22 Apr 2019 23:12:56 GMT):

Clipboard - April 23, 2019 7:12 AM

richzhao (Mon, 22 Apr 2019 23:13:27 GMT):
dear maintainers, I created a change to support multi-languages in fabric docs, change: https://gerrit.hyperledger.org/r/#/c/31051/ issue: https://jira.hyperledger.org/browse/FAB-15246

richzhao (Mon, 22 Apr 2019 23:22:06 GMT):
the change failed due to missing license in the translation file .PO in docs/source/locale/*, .po and .pot files are translation files. it is not necessary to scan license for these files.

richzhao (Mon, 22 Apr 2019 23:31:10 GMT):
changed check_license.sh

Antimttr (Mon, 29 Apr 2019 21:31:49 GMT):
Has joined the channel.

tijohnson (Tue, 30 Apr 2019 20:03:14 GMT):
Has joined the channel.

tijohnson (Tue, 30 Apr 2019 20:05:02 GMT):
@here RocketChat will be be offline for an upgrade today @17:00EST Should be back on-line withing 30mins

tijohnson (Tue, 30 Apr 2019 20:05:02 GMT):
@here RocketChat will be be offline for an upgrade today @17:00EST Should be back on-line within 30mins

bretharrison (Tue, 30 Apr 2019 20:16:42 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=4So5r6vZhaxTL9rWo) @davidkhala We should discuss these issues on the NodeSDK channel

tijohnson (Tue, 30 Apr 2019 21:04:22 GMT):
@here Sorry for the late notice but we had to cancel the RocketChat Update I will reschedule

mbwhite (Wed, 01 May 2019 08:36:17 GMT):
@tijohnson out of curiosity - what changes would we see in the new version? Any new features?

dave.enyeart (Wed, 01 May 2019 12:54:10 GMT):
@here For maintainer meeting today, I can do a quick release update, any other agenda topics for today?

mastersingh24 (Wed, 01 May 2019 12:55:06 GMT):
I'd like to discuss fabric-samples ... specifically byfn ;)

dave.enyeart (Wed, 01 May 2019 13:01:09 GMT):
maintainer meeting starting: https://zoom.us/my/hyperledger.community.3

lehors (Wed, 01 May 2019 13:44:57 GMT):
shoot, my calendar entry was off by 1h :(

lehors (Wed, 01 May 2019 13:45:29 GMT):
@mastersingh24 I'm curious to know what you wanted to talk about regarding byfn

mastersingh24 (Wed, 01 May 2019 14:07:54 GMT):
We need to stop treating byfn as "tutorials" by script. byfn should simply stand up some basic topologies and stop there

mastersingh24 (Wed, 01 May 2019 14:08:44 GMT):
e.g. no channel creation, no chaincode install, no chaincode instantiation, etc no add an org no add this / add that

lehors (Wed, 01 May 2019 14:17:13 GMT):
it sounds like what basic-network was meant to be

lehors (Wed, 01 May 2019 14:17:13 GMT):
it sounds like what basic-network is meant to be

lehors (Wed, 01 May 2019 14:18:01 GMT):
what difference do you see between the two?

mastersingh24 (Wed, 01 May 2019 14:26:18 GMT):
Frankly, we could probably get rid of basic network

mastersingh24 (Wed, 01 May 2019 14:26:42 GMT):
although it is "lighter weight"

sstone1 (Wed, 01 May 2019 14:26:50 GMT):
I was already planning on doing that as soon as I get FabCar running on top of BYFN (it's there in 1.4, just need to make the 2.0 lifecycle changes)

mastersingh24 (Wed, 01 May 2019 14:27:56 GMT):
but I think having 1 place which stands up topologies is best approach.

sstone1 (Wed, 01 May 2019 14:28:47 GMT):
> no channel creation how do you see that fitting in with the samples that would deploy to those topologies? would the samples create their own channels?

mastersingh24 (Wed, 01 May 2019 14:32:48 GMT):
We could consider creating a default channel .... I was torn on that one given our lack of tolling in that area

mastersingh24 (Wed, 01 May 2019 14:32:48 GMT):
We could consider creating a default channel .... I was torn on that one given our lack of tooling in that area

mastersingh24 (Wed, 01 May 2019 14:33:24 GMT):
probably makes the most sense

sstone1 (Wed, 01 May 2019 14:47:14 GMT):
one of the other things that is related that could use some discussion - all of our samples have deployment scripts that go through the chaincode deploy process - e.g. https://github.com/hyperledger/fabric-samples/blob/master/high-throughput/scripts/install-chaincode.sh

sstone1 (Wed, 01 May 2019 14:48:25 GMT):
we could pull all of that out into a single set of sample operational scripts for working with BYFN, and have the samples call those instead

lehors (Wed, 01 May 2019 15:55:13 GMT):
well, that's the challenge in my opinion @sstone1. Every time someone needs a variation of byfn they make a copy and modify it - it actually started with e2e and basic-network, then byfn, and so on

lehors (Wed, 01 May 2019 15:56:02 GMT):
I agree that it would be good to refactor all this into something more generic that could be built on instead of copied and modified every time

lehors (Wed, 01 May 2019 15:56:35 GMT):
but we would also need some discipline not to repeat the same pattern again and again

lehors (Wed, 01 May 2019 15:58:45 GMT):
and by the way, I've been looking at your work on fabcar and waiting for that to complete as well - your CRs need some work to get them up to date - I'll be happy to review them once you've done that

sstone1 (Wed, 01 May 2019 16:05:48 GMT):
great, thanks - hoping to get back to that this week!

MHBauer (Wed, 01 May 2019 18:08:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=9fooi7xLKwvf94Z3F) @lehors having personally copied both byfn and first-network to have a 'real' environment to test against, yes, I've done that.

rjones (Wed, 01 May 2019 18:43:44 GMT):
@mbwhite the new feature is modern mobile clients for Android can connect to it 🤪

dave.enyeart (Wed, 01 May 2019 20:31:44 GMT):
Concerning samples, we've talked a few times and I think we are for the most part aligned: Finish shifting Fabcar to first-network, retire basic network, split first-network into a network only sample that can optionally have various chaincode samples deployed against it. If the deployment pattern can be re-used, all the better. @sstone1 is this all something that your team can take as a mission?

gregnotso (Thu, 02 May 2019 00:21:04 GMT):
if basic network is retired what happens with fabtoken?

lehors (Thu, 02 May 2019 07:33:17 GMT):
it's probably just be a matter of terminology because I think the end result is essentially the same but I think instead of retiring basic-network and splitting first-network what we need is to update basic-network and change first-network to build on that

lehors (Thu, 02 May 2019 07:34:09 GMT):
I just don't know what we would call the "network only sample" that we'd split off of first-network other than basic-network :)

mbwhite (Thu, 02 May 2019 07:54:57 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=e4Ym5N4FaNd0GMmArX) @rjones ah :-) that will be useful...

sstone1 (Thu, 02 May 2019 08:37:16 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=y4XrYH8fmQs3Mgpyd) @dave.enyeart yeah, definitely

dave.enyeart (Thu, 02 May 2019 10:09:55 GMT):
@lehors Basic network has one org with one peer. First network has two orgs with two peers each. As such you can do much more interesting things with first network. In this way the new network only sample will look more like first network than basic network. But you are right, it is will be like basic network in that it doesn't come tightly coupled with a chaincode scenario.... rather various chaincode scenarios can be layered on top.

dave.enyeart (Thu, 02 May 2019 10:09:55 GMT):
@lehors Basic network has one org with one peer. First network has two orgs with two peers each. As such you can do much more interesting things with first network. In this way the new network only sample will look more like first network than basic network. But you are right, it will be like basic network in that it doesn't come tightly coupled with a chaincode scenario.... rather various chaincode scenarios can be layered on top.

lehors (Thu, 02 May 2019 13:51:49 GMT):
@dave.enyeart I understand the difference, when I said "update basic-network" I was talking about making it compatible with first-network - so indeed, I would extend it to two orgs

lehors (Thu, 02 May 2019 13:52:18 GMT):
that's why I said I think it's more a matter of terminology, I think we have agreement on the end goal

lehors (Thu, 02 May 2019 13:52:46 GMT):
for what it's worth, I've not been able to make basic-network work with 2.0

lehors (Thu, 02 May 2019 13:53:40 GMT):
I can't seem to get a config that works

lehors (Thu, 02 May 2019 13:54:22 GMT):
it always fails to satisfy the endorsement policy

lehors (Thu, 02 May 2019 13:55:38 GMT):
but I don't know enough about how that works to know if it's just me missing something or if there is an actual problem because I'm hitting some edge case - one single org

troyronda (Thu, 02 May 2019 14:01:29 GMT):
Good morning Fabric Maintainers. With the launch of our Fabric-based network Verified.Me, I thought it would be great to share with you some of our next open steps. We would also like to contribute components to the larger Hyperledger community. Here is a link to a document providing an introduction to where we are going: https://docs.google.com/document/d/1ENMO-S7i0ef09IRx5teE-eJbRMFsaKSXEdatcufvjPM/edit?usp=sharing.

george.aristy (Thu, 02 May 2019 15:47:34 GMT):
Has joined the channel.

davidkhala (Fri, 03 May 2019 03:40:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=qAEDJRTutCmQY2JwQ) @troyronda interesting interop proposal! Does the DID part is based on Indy project or some other?

troyronda (Fri, 03 May 2019 11:15:57 GMT):
@davidkhala The proposal includes enabling Fabric as a DID ledger. (And build interop to Aries).

yacovm (Fri, 03 May 2019 13:08:07 GMT):
@troyronda is there usage of the `ursa` libraries in fabic as part of your project? how did you guys overcome the "language" gap? the ursa crypto is rust isn't it?

troyronda (Fri, 03 May 2019 13:37:17 GMT):
@yacovm So far, we have been building the Fabric-based components in Go (without ursa) ... and we are working on moving the code to public GitHub repos (I'll post the links).

troyronda (Fri, 03 May 2019 13:40:32 GMT):
(I would like to look more into ursa (yes, rust) and Go language bindings, particularly for working on Aries-compatible edge components).

levanto (Fri, 10 May 2019 11:15:19 GMT):
Has joined the channel.

levanto (Fri, 10 May 2019 11:15:32 GMT):
Has left the channel.

grapebaba (Mon, 13 May 2019 07:49:48 GMT):
hi maintainers, we recently test fabric 1.4.1 using perf test framework caliper, we found a odd high cpu cost by time.Now.

grapebaba (Mon, 13 May 2019 07:50:00 GMT):
I report a bug https://jira.hyperledger.org/browse/FAB-15432

mbanerjee (Tue, 14 May 2019 03:55:38 GMT):
Does any one have the latest performance numbers (tps)? Please share. thanks.

dave.enyeart (Wed, 15 May 2019 02:47:27 GMT):
@here Many maintainers are traveling or otherwise out of office this week. Let's cancel Wednesday's maintainer meeting and resume in two weeks. I'll leave a note in the zoom meeting to contact us here in case others show up with any topics.

chinmay213211 (Thu, 23 May 2019 07:03:33 GMT):
Has joined the channel.

dereckluo (Thu, 23 May 2019 17:54:51 GMT):
Has joined the channel.

MHBauer (Thu, 23 May 2019 21:55:29 GMT):
any way to track down if a TODO in the code is being tracked anywhere?

MHBauer (Thu, 23 May 2019 22:05:44 GMT):
For example, https://github.com/hyperledger/fabric/blame/2a55639248c8e9e2092f65ca02015f2713239356/core/peer/peer.go#L362-L368 has existed for a couple of years, and ripples inside of gossip, for as far as I can tell, a bunch of dead code. In that case, if the true practice is "suspect everything" then we might as well just code it that way instead of injecting a noop so far down.

yacovm (Fri, 24 May 2019 09:54:55 GMT):
can you please point at the dead code?

yacovm (Fri, 24 May 2019 10:00:31 GMT):
and this isn't a noop, it's a co-noop.

yacovm (Fri, 24 May 2019 14:28:34 GMT):
i can't see it, @MHBauer :/

rjones (Fri, 24 May 2019 14:51:10 GMT):
@yacovm lines 362-368:

rjones (Fri, 24 May 2019 14:51:22 GMT):
``` service.GetGossipService().SuspectPeers(func(identity api.PeerIdentityType) bool { // TODO: this is a place-holder that would somehow make the MSP layer suspect // that a given certificate is revoked, or its intermediate CA is revoked. // In the meantime, before we have such an ability, we return true in order // to suspect ALL identities in order to validate all of them. return true })```

yacovm (Fri, 24 May 2019 14:51:39 GMT):
it's not dead code. dead code is code that doesn't do anything

rjones (Fri, 24 May 2019 14:52:46 GMT):
perhaps he chose the word "dead" inartfully?

rjones (Fri, 24 May 2019 14:53:15 GMT):
I'm not making his argument for him, I thought you couldn't see the GitHub highlights :)

yacovm (Fri, 24 May 2019 14:53:32 GMT):
it's possible to refactor and remove the predicate and just make the loop inside the gossip code re-validate all identities anyway, but then you'll only end up removing the predicate but still not removing the functions themselves.

yacovm (Fri, 24 May 2019 14:53:56 GMT):
so instead of `SuspectPeers(func(api.PeerIdentityType))` you'll have `SuspectPeers()`

yacovm (Fri, 24 May 2019 14:54:38 GMT):
however I am sure we have bigger problems than this

yacovm (Fri, 24 May 2019 14:54:38 GMT):
however I am ~ sure ~ know we have bigger problems than this

yacovm (Fri, 24 May 2019 14:54:38 GMT):
however I ~ am sure ~ know we have bigger problems than this

guoger (Sun, 26 May 2019 13:06:26 GMT):
How to trigger CI via gerrit reply now? seems that none of `Run VerifyBuild`/`Run [Integration|Unit]Test`/`Reverify` work...

yacovm (Sun, 26 May 2019 13:57:30 GMT):
@guoger CI has been dead the entire weekend

yacovm (Sun, 26 May 2019 13:57:53 GMT):
my stuff isn't building too

guoger (Sun, 26 May 2019 13:57:59 GMT):
yeah... just saw the conversation in #fabric-ci

guoger (Sun, 26 May 2019 13:58:09 GMT):
:(

rjones (Tue, 28 May 2019 14:47:38 GMT):
Looks like it's building now

baohua (Wed, 29 May 2019 00:17:34 GMT):
Same finding, and it works now.

baohua (Wed, 29 May 2019 00:18:03 GMT):
https://gerrit.hyperledger.org/r/#/c/fabric/+/31519/

dave.enyeart (Wed, 29 May 2019 12:34:41 GMT):
Topics for today's maintainer meeting:

dave.enyeart (Wed, 29 May 2019 12:34:49 GMT):
*RELEASE UPDATE - v1.4 LTS* Quarterly releases continue - v1.4.2 scheduled for beginning of July. In addition to bug fixes, there are some noteworthy improvements targeted for v1.4.2 that will require capability updates: FAB-15041 Kafka to Raft consensus-type migration FAB-14307 Peer administration: Rollback a channel's ledger on a peer, while preserving private data FAB-7559 Move ordering service endpoints into OrdererOrg groups Note - Due to the capability update, we could call this a v1.5 release, and state that v1.x LTS includes v1.4 and above (other projects such as Node.js take this approach). Thoughts? v1.4.2 Features, Stories, Tasks: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11429#Filter-Results/12660

dave.enyeart (Wed, 29 May 2019 12:34:49 GMT):
*RELEASE UPDATE - v1.4 LTS* Quarterly releases continue - v1.4.2 scheduled for beginning of July. In addition to bug fixes, there are some noteworthy improvements targeted for v1.4.2 that will require capability updates: * FAB-15041 Kafka to Raft consensus-type migration * FAB-14307 Peer administration: Rollback a channel's ledger on a peer, while preserving private data * FAB-7559 Move ordering service endpoints into OrdererOrg groups Note - Due to the capability update, we could call this a v1.5 release, and state that v1.x LTS includes v1.4 and above (other projects such as Node.js take this approach). Thoughts? v1.4.2 Features, Stories, Tasks: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11429#Filter-Results/12660

dave.enyeart (Wed, 29 May 2019 12:34:57 GMT):
*RELEASE UPDATE - v2.0* With a healthy v1.4 LTS in the market, the maintainers are taking the time to ensure that v2.0 can serve as the basis for future extensions. As such, code, test, and CI is being refactored prior to a v2.0 release later this year. https://jira.hyperledger.org/browse/FAB-15337 captures some of the important changes planned for v2.0: * FAB-15499 Support upgrade to v2 (including rebuilding of ledger databases to v2 format) * FAB-5177 peer/ccenv should not include the shim - chaincodes must vendor the shim * FAB-15366 As a go chaincode developer, I want to free myself from the go-logging dependency * FAB-15390 As a fabric maintainer, I want to remove unnecessary endpoints and APIs that overlap with the operations service * FAB-15351 Stop publishing 3rd party images - More official Kafka, Zookeeper, CouchDB images available on dockerhub * FAB-15338 Remove support for Go plugins - The Go community has found that plugin approach to be not very practical. * FAB-15367 Move shim.MockStub to shimtest package and deprecate for removal v2.0 Epics to highlight: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 * FAB-11237 Chaincode lifecycle - 2.0 improvements * FAB-10889 Chaincode lifecycle - implicit org-specific collections (enables lifecycle 'voting') * FAB-12221 Validator/Committer refactor - make validation code maintainable and prepare for post-order execution additions. * FAB-14513 Fabric performance improvements - v2.x (state db cache, note - unmarshaled block cache not needed due to validation refactor) * FAB-13582 Peer and Chaincode cloud native deployment support - Phase 1 * Note: FabToken from v2.0 alpha not expected to be released in v2.0. Based on alpha feedback, the maintainers are evaluating broader post-order execution and privacy capabilities before delivering FabToken in its current form. Programming model updates (various FABs)

dave.enyeart (Wed, 29 May 2019 12:34:57 GMT):
---------------------

dave.enyeart (Wed, 29 May 2019 12:35:21 GMT):
*RELEASE UPDATE - v2.0* With a healthy v1.4 LTS in the market, the maintainers are taking the time to ensure that v2.0 can serve as the basis for future extensions. As such, code, test, and CI is being refactored prior to a v2.0 release later this year. https://jira.hyperledger.org/browse/FAB-15337 captures some of the important changes planned for v2.0: * FAB-15499 Support upgrade to v2 (including rebuilding of ledger databases to v2 format) * FAB-5177 peer/ccenv should not include the shim - chaincodes must vendor the shim * FAB-15366 As a go chaincode developer, I want to free myself from the go-logging dependency * FAB-15390 As a fabric maintainer, I want to remove unnecessary endpoints and APIs that overlap with the operations service * FAB-15351 Stop publishing 3rd party images - More official Kafka, Zookeeper, CouchDB images available on dockerhub * FAB-15338 Remove support for Go plugins - The Go community has found that plugin approach to be not very practical. * FAB-15367 Move shim.MockStub to shimtest package and deprecate for removal v2.0 Epics to highlight: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 * FAB-11237 Chaincode lifecycle - 2.0 improvements * FAB-10889 Chaincode lifecycle - implicit org-specific collections (enables lifecycle 'voting') * FAB-12221 Validator/Committer refactor - make validation code maintainable and prepare for post-order execution additions. * FAB-14513 Fabric performance improvements - v2.x (state db cache, note - unmarshaled block cache not needed due to validation refactor) * FAB-13582 Peer and Chaincode cloud native deployment support - Phase 1 * Note: FabToken from v2.0 alpha not expected to be released in v2.0. Based on alpha feedback, the maintainers are evaluating broader post-order execution and privacy capabilities before delivering FabToken in its current form. Programming model updates (various FABs)

dave.enyeart (Wed, 29 May 2019 12:35:21 GMT):
*RELEASE UPDATE - v2.0* With a healthy v1.4 LTS in the market, the maintainers are taking the time to ensure that v2.0 can serve as the basis for future extensions. As such, code, test, and CI is being refactored prior to a v2.0 release later this year. https://jira.hyperledger.org/browse/FAB-15337 captures some of the important changes planned for v2.0: * FAB-15499 Support upgrade to v2 (including rebuilding of ledger databases to v2 format) * FAB-5177 peer/ccenv should not include the shim - chaincodes must vendor the shim * FAB-15366 As a go chaincode developer, I want to free myself from the go-logging dependency * FAB-15390 As a fabric maintainer, I want to remove unnecessary endpoints and APIs that overlap with the operations service * FAB-15351 Stop publishing 3rd party images - More official Kafka, Zookeeper, CouchDB images available on dockerhub * FAB-15338 Remove support for Go plugins - The Go community has found that plugin approach to be not very practical. * FAB-15367 Move shim.MockStub to shimtest package and deprecate for removal v2.0 Epics to highlight: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 * FAB-11237 Chaincode lifecycle - 2.0 improvements * FAB-10889 Chaincode lifecycle - implicit org-specific collections (enables lifecycle 'voting') * FAB-12221 Validator/Committer refactor - make validation code maintainable and prepare for post-order execution additions. * FAB-14513 Fabric performance improvements - v2.x (state db cache, note - unmarshaled block cache not needed due to validation refactor) * FAB-13582 Peer and Chaincode cloud native deployment support - Phase 1 * Programming model updates (various FABs) * Note: FabToken from v2.0 alpha not expected to be released in v2.0. Based on alpha feedback, the maintainers are evaluating broader post-order execution and privacy capabilities before delivering FabToken in its current form.

dave.enyeart (Wed, 29 May 2019 12:35:21 GMT):
*RELEASE UPDATE - v2.0* With a healthy v1.4 LTS in the market, the maintainers are taking the time to ensure that v2.0 can serve as the basis for future extensions. As such, code, test, and CI is being refactored prior to a v2.0 release later this year. https://jira.hyperledger.org/browse/FAB-15337 captures some of the important changes planned for v2.0: * FAB-5177 peer/ccenv should not include the shim - chaincodes must vendor the shim * FAB-15366 As a go chaincode developer, I want to free myself from the go-logging dependency * FAB-15390 As a fabric maintainer, I want to remove unnecessary endpoints and APIs that overlap with the operations service * FAB-15351 Stop publishing 3rd party images - More official Kafka, Zookeeper, CouchDB images available on dockerhub * FAB-15338 Remove support for Go plugins - The Go community has found that plugin approach to be not very practical. * FAB-15367 Move shim.MockStub to shimtest package and deprecate for removal * FAB-15499 Support upgrade to v2 (including rebuilding of ledger databases to v2 format) v2.0 Epics to highlight: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11700 * FAB-11237 Chaincode lifecycle - 2.0 improvements * FAB-10889 Chaincode lifecycle - implicit org-specific collections (enables lifecycle 'voting') * FAB-12221 Validator/Committer refactor - make validation code maintainable and prepare for post-order execution additions. * FAB-14513 Fabric performance improvements - v2.x (state db cache, note - unmarshaled block cache not needed due to validation refactor) * FAB-13582 Peer and Chaincode cloud native deployment support - Phase 1 * Programming model updates (various FABs) * Note: FabToken from v2.0 alpha not expected to be released in v2.0. Based on alpha feedback, the maintainers are evaluating broader post-order execution and privacy capabilities before delivering FabToken in its current form.

dave.enyeart (Wed, 29 May 2019 12:35:28 GMT):
---------------------

dave.enyeart (Wed, 29 May 2019 12:35:35 GMT):
*PROPOSAL FOR A GATED MULTI-BRANCH JENKINS PIPELINE - DEMO* Fabric's current monolithic CI system is based on a single branch strategy. In the current state, end-to-end testing is performed after a changeset becomes part of the codebase. This allows for code that doesn't function in the end-to-end tests to potentially become part of Fabrics "production" branch. Moreover it provides no incentive for developers to fix broken code because their changes have already made it into the codebase. This proposal presents a gated, multi-branch strategy written in Jenkins Pipeline that ensures code never becomes part of the "production" branches unless it has been vetted against the end-to-end testing strategies currently employed post-merge in Fabrics current CI system.

BrettLogan (Wed, 29 May 2019 12:55:29 GMT):
Has joined the channel.

minollo (Wed, 29 May 2019 13:06:43 GMT):
@dave.enyeart , can you remind me the meeting URL?

dave.enyeart (Wed, 29 May 2019 15:44:47 GMT):
During the maintainer meeting, consensus was to keep the plan of record concerning next release number being v1.4.2 (rather than v1.5, even though new capabilities are being delivered in v1.4.2)

tatsu-sato (Fri, 31 May 2019 02:36:54 GMT):
Has joined the channel.

KartikChauhan (Fri, 07 Jun 2019 14:02:05 GMT):
I'm trying out the wallet classes introduced in Hyperledger Fabric v1.4. All the wallet classes work fine except for `HSMWalletMixin`. I couldn't understand the working of it. There's not much info available about it in the official documentation or in sdk docs. It says in the docs > currently you should use the FileSystemWallet class in combination with the HSMWalletMixin class to manage HSM wallets. There's no working example from where I could take any help. I've no idea how to use these two classes together. Plus, isn't there any option of configuring `HSMWalletMixin` class with AWS CloudHSM currently?

dave.enyeart (Fri, 07 Jun 2019 15:32:16 GMT):
For Node.js SDK questions please post to #fabric-sdk-node , one of the experts over there could help @odowdaibm @andrew-coleman @14gracel

iamdm (Tue, 11 Jun 2019 10:49:06 GMT):
Has joined the channel.

dave.enyeart (Tue, 11 Jun 2019 15:12:09 GMT):
@here In the last maintainer meeting we walked through the v1.4.2 and v2.0 plans in some detail. Some community members specifically solution providers have been wanting an open session to provide feedback to the Fabric maintainers. I'm thinking that can be the focus of tomorrow's maintainer meeting and I can send a note to the mailing list as such. wdyt?

dave.enyeart (Tue, 11 Jun 2019 15:12:14 GMT):
Any other topics for tomorrow?

dave.enyeart (Tue, 11 Jun 2019 15:12:17 GMT):
We should probably spend a few minutes on CI direction.

lehors (Tue, 11 Jun 2019 18:02:11 GMT):
the TSC is considering enforcing 2FA on the hyperledger github org, everyone is therefore directed to setup 2FA if they haven't done so yet

lehors (Tue, 11 Jun 2019 18:02:38 GMT):
those who don't will eventually be kicked out of the org when the enforcement comes into effect

lehors (Tue, 11 Jun 2019 18:02:48 GMT):
feedback from maintainers is welcome

lehors (Tue, 11 Jun 2019 18:05:30 GMT):
for what it's worth: about half of our org members have not enabled it at the time we started spreading the word

lehors (Tue, 11 Jun 2019 18:05:30 GMT):
for what it's worth: about half of our org members had not enabled it at the time we started spreading the word

dave.enyeart (Tue, 11 Jun 2019 18:51:42 GMT):
@lehors just to be clear - you are talking about https://help.github.com/en/articles/securing-your-account-with-two-factor-authentication-2fa right?

rjones (Tue, 11 Jun 2019 18:53:37 GMT):
yes

rjones (Tue, 11 Jun 2019 18:54:14 GMT):
@dave.enyeart check the pinned message in #general

dave.enyeart (Tue, 11 Jun 2019 18:57:07 GMT):
@here how about maintainer meeting tomorrow - are others agreeable if we advertise an 'open mic' format where people can provide any fabric feedback? you all used to have an opinion on everything!

smithbk (Tue, 11 Jun 2019 18:58:01 GMT):
Has left the channel.

dave.enyeart (Wed, 12 Jun 2019 00:01:02 GMT):
@rjones I received a fabric maintainer meeting cancellation from hyperledger, and it no longer shows on the calendar for tomorrow: https://calendar.google.com/calendar/embed?mode=AGENDA&src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=UTC

rjones (Wed, 12 Jun 2019 01:24:13 GMT):
@dave.enyeart I have no idea what is going on

dave.enyeart (Wed, 12 Jun 2019 01:25:19 GMT):
The cancellation came from kottoni

rjones (Wed, 12 Jun 2019 01:25:44 GMT):
@dave.enyeart could I bother you to send an invite to me? Like, invite me to the meeting you used to have

rjones (Wed, 12 Jun 2019 01:25:56 GMT):
rjones@linuxfoundation.otg

rjones (Wed, 12 Jun 2019 01:25:56 GMT):
rjones@linuxfoundation.org

dave.enyeart (Wed, 12 Jun 2019 01:28:33 GMT):
sent

rjones (Wed, 12 Jun 2019 01:29:39 GMT):
thanks

rjones (Wed, 12 Jun 2019 01:31:51 GMT):
You should have an invite to the new meeting - let me know

dave.enyeart (Wed, 12 Jun 2019 02:23:14 GMT):
@rjones thanks - meeting is restored

dave.enyeart (Wed, 12 Jun 2019 02:34:51 GMT):
Ok, sent to mailing list: Hyperledger Fabric maintainer meetings occur every other Wednesday at 9am US Eastern (13:00 UTC during daylight savings time). On this Wednesday's maintainer meeting we will keep the agenda open to allow for any community feedback to the maintainers. We look forward to hearing your thoughts. Web conference: https://zoom.us/my/hyperledger.community.3 Additional information: https://wiki.hyperledger.org/display/fabric/Maintainer+Meetings

rjones (Wed, 12 Jun 2019 02:40:54 GMT):
I apologize for the turbulence

MHBauer (Wed, 12 Jun 2019 05:09:24 GMT):
definitely turn on 2fa everywhere. not sure LF logins have it, but I've had mine set up on github for years. basically can'tbe a maintainer of anything on github without having 2fa.

dave.enyeart (Wed, 12 Jun 2019 13:00:08 GMT):
@here maintainer meeting starting: https://zoom.us/my/hyperledger.community.3

gregnotso (Wed, 12 Jun 2019 13:42:58 GMT):
when will recording be posted?

troyronda (Wed, 12 Jun 2019 13:49:22 GMT):
Here is the document that was mentioned on this morning's call: https://chat.hyperledger.org/channel/fabric-maintainers?msg=qAEDJRTutCmQY2JwQ

jmason900 (Wed, 12 Jun 2019 13:49:26 GMT):
reposting Troy Ronda's notes on their TrustBloc initiative. It has many of the same high level features and requirements that most compliance solutions have, ours included. We are working to make ours GDPR compliant as well. https://docs.google.com/document/d/1ENMO-S7i0ef09IRx5teE-eJbRMFsaKSXEdatcufvjPM/edit

jmason900 (Wed, 12 Jun 2019 13:51:44 GMT):
@troyronda Great job on verified.me solution. Your requirements are common to most of us ... change controls, off-chain content delivery and privacy etc

mbwhite (Wed, 12 Jun 2019 13:54:14 GMT):
@dave.enyeart where will the recordings be of the call? Some v. good observations it would good to listen to again; On the topic of the Programming Model, I'm hoping to do a demo of the Java Contract tomorrow on the Dev Community Call

dave.enyeart (Wed, 12 Jun 2019 13:54:17 GMT):
Maintainer meeting recording has been posted --> https://wiki.hyperledger.org/display/fabric/Maintainer+Meetings

mbwhite (Wed, 12 Jun 2019 13:54:35 GMT):
and my question is answered immediately :-)

gregnotso (Wed, 12 Jun 2019 13:56:43 GMT):
thx for the quick posting

troyronda (Wed, 12 Jun 2019 15:02:30 GMT):
Awesome thanks!

lehors (Thu, 13 Jun 2019 17:58:05 GMT):
There was a vote today, and the motion to enable 2FA for the Hyperledger org on GitHub at the end of the next TSC call (20 JUN 2019) was approved. If you are a member of the Hyperledger GitHub organization and you do not have 2FA enabled, GitHub will remove you from the org. This does not preclude rejoining in the future.

lehors (Thu, 13 Jun 2019 17:59:32 GMT):
the Linux Foundation is upgrading its token based login system and will enforce 2FA "soon"

lehors (Thu, 13 Jun 2019 17:59:55 GMT):
this will then cover gerrit

jyellick (Mon, 17 Jun 2019 01:58:07 GMT):
A nomination to add @guoger to our set of maintainers https://gerrit.hyperledger.org/r/c/fabric/+/31934

jaswanth (Tue, 18 Jun 2019 04:50:48 GMT):
Has joined the channel.

dave.enyeart (Tue, 18 Jun 2019 18:58:19 GMT):
Merged - welcome to the gang @guoger !

dave.enyeart (Tue, 18 Jun 2019 19:00:17 GMT):
Sent request to helpdesk@hyperledger.org to give Jay fabric maintainer permissions

guoger (Wed, 19 Jun 2019 01:53:20 GMT):
Thanks Dave, i'll keep up the momentum!

dave.enyeart (Wed, 26 Jun 2019 12:54:55 GMT):
@here Maintainer meeting starting in a few minutes

dave.enyeart (Wed, 26 Jun 2019 12:55:22 GMT):
With v1.4.2 closing down, we'll review the v1.4.2 items: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=11429#Filter-Results/12660

dave.enyeart (Wed, 26 Jun 2019 12:55:30 GMT):
Any other agenda topics for today?

rjones (Wed, 26 Jun 2019 12:58:22 GMT):
@dave.enyeart I have a broad question: GitHub gives me tons of security alerts across Fabric repo mirrors. How do you, as maintainers, want this handled?

rjones (Wed, 26 Jun 2019 12:59:46 GMT):
Example: ``` hyperledger / fabric-test Known security vulnerabilities detected Dependency cryptography Version >= 1.9.0 < 2.3 Upgrade to ~> 2.3 Vulnerabilities CVE-2018-10903 High severity Defined in requirements.txt Dependency adm-zip Version < 0.4.11 Upgrade to ~> 0.4.11 Vulnerabilities CVE-2018-1002204 High severity Defined in package-lock.json Dependency url-parse Version < 1.4.3 Upgrade to ~> 1.4.3 Vulnerabilities CVE-2018-3774 High severity Defined in package-lock.json Dependency timespan Version <= 2.3.0 Vulnerabilities CVE-2017-16115 Low severity Defined in package-lock.json Dependency cryptiles Version < 4.1.2 Upgrade to ~> 4.1.2 Vulnerabilities CVE-2018-1000620 High severity Defined in package-lock.json Dependency pyopenssl Version < 17.5.0 Upgrade to ~> 17.5.0 Vulnerabilities CVE-2018-1000807 High severity CVE-2018-1000808 Moderate severity Defined in requirements.txt Dependency pyyaml Version < 4.2b1 Upgrade to ~> 4.2b1 Vulnerabilities CVE-2017-18342 High severity Defined in requirements.txt Dependency webpack-dev-server Version < 3.1.11 Upgrade to ~> 3.1.11 Vulnerabilities CVE-2018-14732 Low severity Defined in package-lock.json Dependency lodash Version < 4.17.11 Upgrade to ~> 4.17.11 Vulnerabilities CVE-2018-16487 Low severity CVE-2018-16487 Low severity Defined in package-lock.json Dependency extend Version >= 3.0.0 < 3.0.2 Upgrade to ~> 3.0.2 Vulnerabilities CVE-2018-16492 Low severity CVE-2018-16492 Low severity Defined in package-lock.json Dependency tar Version < 2.2.2 Upgrade to ~> 2.2.2 Vulnerabilities CVE-2018-20834 High severity Defined in package-lock.json Dependency axios Version <= 0.18.0 Upgrade to ~> 0.18.1 Vulnerabilities CVE-2019-10742 High severity Defined in package-lock.json Dependency fstream Version < 1.0.12 Upgrade to ~> 1.0.12 Vulnerabilities WS-2019-0100 Moderate severity Defined in package-lock.json Dependency ws Version >= 0.2.6 < 3.3.1 Upgrade to ~> 3.3.1 Vulnerabilities WS-2017-0421 High severity Defined in package-lock.json Dependency js-yaml Version < 3.13.1 Upgrade to ~> 3.13.1 Vulnerabilities WS-2019-0063 High severity WS-2019-0032 Moderate severity Defined in package-lock.json Dependency handlebars Version < 4.0.14 Upgrade to ~> 4.0.14 Vulnerabilities WS-2019-0064 High severity Defined in package-lock.json ```

rjones (Wed, 26 Jun 2019 13:04:02 GMT):

Your GitHub security alerts for the week of Jun 18 - Jun 25 _ Fastmail.pdf

cbf (Wed, 26 Jun 2019 13:10:51 GMT):
I found fabric-chaincode-node, fabric-test, fabric-docs, and fabric-chaintool to have security warnings

cbf (Wed, 26 Jun 2019 13:11:14 GMT):
the one that has actual release implications is fabric-chaincode-node

cbf (Wed, 26 Jun 2019 13:12:06 GMT):
fabric-test we should clean up - could be that we just need to update the dependencies

cbf (Wed, 26 Jun 2019 13:12:26 GMT):
fabric-chaintool I think we need to have someone from StateStreet weigh in on

rjones (Wed, 26 Jun 2019 13:12:43 GMT):
I have a PR out there for one of them

cbf (Wed, 26 Jun 2019 13:13:03 GMT):
fabric-docs we need to revisit at some point

rjones (Wed, 26 Jun 2019 13:13:29 GMT):
feel free to abandon or merge at will: https://gerrit.hyperledger.org/r/c/fabric-docs/+/31467

cbf (Wed, 26 Jun 2019 13:13:32 GMT):
we may want to simply archive that repo until we decide on actually following through on a separate repo for docs

rjones (Wed, 26 Jun 2019 13:14:05 GMT):
I no longer have those powers, but I'll show you how to create a new ticket

cbf (Wed, 26 Jun 2019 13:18:45 GMT):
please, we just discussed on the maintainers call and a previous call had decided to leave the docs in the fabric repo so everyone agreed we could just archive fabric-docs

rjones (Wed, 26 Jun 2019 13:18:59 GMT):
ok.

cbf (Wed, 26 Jun 2019 13:19:02 GMT):
thx

rjones (Wed, 26 Jun 2019 13:38:06 GMT):
@cbf: I think you should be able to see this? https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-16573

cbf (Wed, 26 Jun 2019 13:47:30 GMT):
Ah, I see you've submitted the ticket thanls!

cbf (Wed, 26 Jun 2019 13:47:30 GMT):
Ah, I see you've submitted the ticket thanks

guoger (Thu, 27 Jun 2019 01:50:47 GMT):
is gerrit down?

jyellick (Thu, 27 Jun 2019 02:25:20 GMT):
@guoger Not working for me

dave.enyeart (Mon, 01 Jul 2019 23:40:39 GMT):
There is a Maintainer Meeting scheduled for July 10th, but myself and several others will be out of office. Any volunteers to facilitate the meeting? If no agenda topics we could cancel.

dave.enyeart (Mon, 01 Jul 2019 23:42:04 GMT):
We've talked about calling the meeting a Contributor Meeting instead and formalize the agenda topics beforehand. We could unveil the new format July 24th.

mastersingh24 (Tue, 02 Jul 2019 08:46:48 GMT):
I'm out as well

huxiangdong (Tue, 02 Jul 2019 10:41:28 GMT):
is there any plan to enhance the idemix feature, for example enabling custom attribute or enabling support in sdk other than JAVA? current implementation seems quite limited...

dave.enyeart (Tue, 09 Jul 2019 14:03:04 GMT):
Due to multiple maintainer vacations, we will cancel July 10th maintainer meeting. Next meeting is July 24th.

rjones (Tue, 09 Jul 2019 17:02:03 GMT):
Has left the channel.

scottz (Wed, 10 Jul 2019 13:41:42 GMT):
@rjones Did you open issues to resolve the security warnings? If not, could you at least open a FAB for the *fabric-test* repo, to upgrade tools versions as @cbf suggested? Maybe it could be an epic, and I can create and link tasks for each of the tools warnings. Either that, or make it a task and we can create subtasks to address each one. Please include the full email you received. Assign it to me and I'll create tasks or subtasks and try to get some folks to resolve them in fabric-test.

rjones (Wed, 10 Jul 2019 13:41:43 GMT):
Has joined the channel.

dave.enyeart (Wed, 10 Jul 2019 14:16:20 GMT):
@here Please review draft release notes for v1.4.2: https://gerrit.hyperledger.org/r/#/c/fabric/+/32240/

dave.enyeart (Wed, 10 Jul 2019 14:16:24 GMT):
I haven't done a review of commits for important fixes yet, so I'm sure there's more to add to theh release notes. Go ahead and push subsequent patches to add other important notes.

dave.enyeart (Wed, 10 Jul 2019 14:16:24 GMT):
I haven't done a review of commits for important fixes yet, so I'm sure there's more to add to the release notes. Go ahead and push subsequent patches to add other important notes.

dave.enyeart (Wed, 10 Jul 2019 14:17:16 GMT):
We'll also want to add deprecation statements for the things we know will be changing in v2.0

dave.enyeart (Wed, 10 Jul 2019 14:17:16 GMT):
We'll also want to add deprecation statements for the things we know will be changing in v2.0. And mention the new v1.4.2 capabilities.

rjones (Wed, 10 Jul 2019 14:42:35 GMT):
@scottz I did not open bugs. Let me do that

rjones (Wed, 10 Jul 2019 14:47:41 GMT):
@scottz like this? https://jira.hyperledger.org/browse/FAB-15912

scottz (Wed, 10 Jul 2019 14:49:31 GMT):
@rjones ok, but I cannot read the pdf email

rjones (Wed, 10 Jul 2019 14:51:11 GMT):
@scottz try now. I had to rename it, sorry

scottz (Wed, 10 Jul 2019 14:59:06 GMT):
@rjones better. but when I click the boxes "Review all vulnerable dependencies" in each section, it shows me 404 error when trying to connect to github.

rjones (Wed, 10 Jul 2019 14:59:44 GMT):
what is your github username?

scottz (Wed, 10 Jul 2019 15:02:01 GMT):
scottz64

rjones (Wed, 10 Jul 2019 15:02:47 GMT):
invite sent.

baohua (Thu, 11 Jul 2019 02:20:45 GMT):
Gonna review this important release!

bbehlendorf (Fri, 12 Jul 2019 17:29:09 GMT):
Quick question, where is the list of Fabric maintainers maintained? I looked at https://github.com/hyperledger/fabric/blob/release-1.4/CONTRIBUTING.md but didn't see a list there

bbehlendorf (Fri, 12 Jul 2019 17:30:16 GMT):
Oh, nevermind, found it: https://hyperledger-fabric.readthedocs.io/en/latest/MAINTAINERS.html

medikent (Fri, 12 Jul 2019 19:57:06 GMT):
Has joined the channel.

medikent (Fri, 12 Jul 2019 19:57:07 GMT):
Hello, I would like to contribute to the GO sdk. What would be the best way for me to get started? I have accessed the JIRA and looked over the issues. I just want to learn the codebase a bit before I start trying to make any changes or take any major issues.

medikent (Fri, 12 Jul 2019 20:13:26 GMT):
I'd at least like to make some docs contributions.

yacovm (Fri, 12 Jul 2019 20:16:15 GMT):
@troyronda ^

troyronda (Fri, 12 Jul 2019 20:38:59 GMT):
@medikent of course, contributions are welcome - ping us on #fabric-sdk-go and we can review JIRA issues you create & when you have a Gerrit change submitted.

dave.enyeart (Mon, 15 Jul 2019 14:49:40 GMT):
v1.4.2 release update - early this week there is some final testing ongoing including testing the updated node OU support and dependency updates to couchdb, kafka, zookeeper (https://gerrit.hyperledger.org/r/#/c/fabric-baseimage/+/32176/). I will also be updating release notes.

dave.enyeart (Mon, 15 Jul 2019 14:49:42 GMT):
If everything goes smoothly we expect to release v1.4.2 midweek.

dave.enyeart (Mon, 15 Jul 2019 14:50:36 GMT):
Please post here if anybody knows of any remaining issues or tasks that need to be addressed before v1.4.2 release.

owenlilly (Mon, 15 Jul 2019 15:44:26 GMT):
Has joined the channel.

dave.enyeart (Tue, 16 Jul 2019 20:27:32 GMT):
Update - we have finished v1.4.2 testing. The updates to 3rd party dependencies and node OU support have been deferred to v1.4.3. We'll begin v1.4.2 release process tomorrow.

dave.enyeart (Tue, 16 Jul 2019 20:28:11 GMT):
Let's free merges to release-1.4 release branch, except for minor things such as doc.

dave.enyeart (Tue, 16 Jul 2019 20:28:11 GMT):
Let's freeze merges to release-1.4 release branch, except for minor things such as doc.

jyellick (Tue, 16 Jul 2019 20:29:49 GMT):
@dave.enyeart I think you meant 'freeze' instead of 'free'

dave.enyeart (Wed, 17 Jul 2019 01:26:36 GMT):
indeed!

dave.enyeart (Wed, 17 Jul 2019 16:05:30 GMT):
@here Please see draft release notes for v1.4.2: https://gerrit.hyperledger.org/r/#/c/fabric/+/32240/

dave.enyeart (Wed, 17 Jul 2019 16:08:05 GMT):
I included deprecation statements for the known functions being removed in v2.0.0. For functions that are proposed to be removed after v2.0.0, I did not include since we can use the v2.0.0 release notes to announce those deprecations, but if you feel strongly about other deprecations please go ahead and push another patch with your additions/edits.

yacovm (Wed, 17 Jul 2019 16:12:00 GMT):
LGTM

manish-sethi (Wed, 17 Jul 2019 16:27:19 GMT):
I see a pending comment from Jay - https://gerrit.hyperledger.org/r/#/c/fabric/+/32240/2/release_notes/v1.4.2.txt@92

manish-sethi (Wed, 17 Jul 2019 16:27:19 GMT):
@dave.enyeart - I see a pending comment from Jay - https://gerrit.hyperledger.org/r/#/c/fabric/+/32240/2/release_notes/v1.4.2.txt@92

rjones (Wed, 17 Jul 2019 16:29:49 GMT):
Has left the channel.

dave.enyeart (Wed, 17 Jul 2019 17:48:59 GMT):
Addressed.

dave.enyeart (Wed, 17 Jul 2019 17:48:59 GMT):
Addressed and merged.

dave.enyeart (Wed, 17 Jul 2019 18:28:05 GMT):
Fabric release CR, please +2: https://gerrit.hyperledger.org/r/#/c/fabric/+/32380/

dave.enyeart (Wed, 17 Jul 2019 19:22:40 GMT):
Fabric-CA release CR: https://gerrit.hyperledger.org/r/#/c/fabric-ca/+/32381/

dave.enyeart (Wed, 17 Jul 2019 22:31:18 GMT):
Fabric and Fabric-CA v1.4.2 is published and tagged

dave.enyeart (Wed, 17 Jul 2019 22:32:53 GMT):
We'll wait node.js and java chaincode to publish before announcing @mbwhite

dave.enyeart (Wed, 17 Jul 2019 22:32:53 GMT):
We'll wait for node.js and java chaincode to publish before announcing @mbwhite

dave.enyeart (Wed, 17 Jul 2019 22:33:09 GMT):
Prepare for next CRs could use +2s:

dave.enyeart (Wed, 17 Jul 2019 22:33:39 GMT):
https://gerrit.hyperledger.org/r/#/c/fabric/+/32383/

dave.enyeart (Wed, 17 Jul 2019 22:33:55 GMT):
https://gerrit.hyperledger.org/r/#/c/fabric-ca/+/32384/

dave.enyeart (Sat, 20 Jul 2019 14:28:41 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v1.4.2 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/6484 ----------------------------------------------------------------------

liurain (Tue, 23 Jul 2019 04:53:03 GMT):
Has joined the channel.

MHBauer (Tue, 23 Jul 2019 15:51:55 GMT):
On the rebranding of the meeting. It's too early for the Pacific Coast time.

jyellick (Tue, 23 Jul 2019 16:07:40 GMT):
I'm certainly open to moving the meeting later, though I expect we'll have trouble finding a time that is convenient for everyone. We have a number of contributors in UTC +3, and UTC+2, vs. the pacific coast's UTC -7, so with a 10 hour spread, I expect someone will be inconvenienced .

rhall9090 (Wed, 24 Jul 2019 12:53:36 GMT):
Has joined the channel.

BrettLogan (Wed, 24 Jul 2019 12:56:56 GMT):

CICD_Proposal.pdf

BrettLogan (Wed, 24 Jul 2019 12:57:23 GMT):
The slides for this mornings agenda topic

dave.enyeart (Wed, 24 Jul 2019 12:58:07 GMT):
@here Contributor's Meeting starting at the top of the hour: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 24 Jul 2019 12:58:07 GMT):
@here Thanks Brett. Contributor's Meeting starting at the top of the hour: https://zoom.us/my/hyperledger.community.3

sstone1 (Wed, 24 Jul 2019 13:01:53 GMT):
@BrettLogan slide 12 makes me so happy

heatherp (Wed, 24 Jul 2019 13:07:12 GMT):
Has joined the channel.

lehors (Wed, 24 Jul 2019 13:14:39 GMT):
good for you. I don't share your enthusiasm...

cbf (Wed, 24 Jul 2019 13:19:55 GMT):
Much of the rationale for Gerrit was support for multiple reviews, and DCO check compliance.

cbf (Wed, 24 Jul 2019 13:20:25 GMT):
GitHub has the latter (DCO bot) but only manual 2+2

sstone1 (Wed, 24 Jul 2019 13:21:29 GMT):
GitHub has the ability to require >1 approving reviews?

cbf (Wed, 24 Jul 2019 13:22:20 GMT):
no, I stated the opposite - it can only be enforced manually to my understanding

sstone1 (Wed, 24 Jul 2019 13:22:45 GMT):
nope, they added it recently

cbf (Wed, 24 Jul 2019 13:23:00 GMT):
ah - note I said "to my knowledge"

sstone1 (Wed, 24 Jul 2019 13:23:08 GMT):

Screenshot 2019-07-24 at 14.22.52.png

cbf (Wed, 24 Jul 2019 13:23:11 GMT):
so this means that we have what we need

cbf (Wed, 24 Jul 2019 13:25:10 GMT):
some projects have done this (partition off responsibility for sections of the code)

cbf (Wed, 24 Jul 2019 13:25:20 GMT):
Docker did it

mbwhite (Wed, 24 Jul 2019 13:25:33 GMT):
The 'debug with ssh' option, for me, is a real win. Having tried to debug builds that only fail in CI systems, and not locally is really really hard..

cbf (Wed, 24 Jul 2019 13:26:36 GMT):
@binhn basically we have a Git mirror

lehors (Wed, 24 Jul 2019 13:44:56 GMT):
reluctantly support the recommendation

lehors (Wed, 24 Jul 2019 13:45:52 GMT):
I agree with the rationale, I'm just not the github fanboy @sstone1 is :-)

cbf (Wed, 24 Jul 2019 13:46:03 GMT):
@BrettLogan think we could handle like nominating new maintainer - submit a CR with a link to the proposal, and we look to have a majority of maintainers sign off

muralisr (Wed, 24 Jul 2019 13:54:27 GMT):
@BrettLogan so to make sure I understood correctly... there will be a 1-1 between git and gerrit entries but the new git entries won't preserve any of the comments, CI history and the approvals ?

BrettLogan (Wed, 24 Jul 2019 13:57:43 GMT):
I don't see why not, the pull request could be the update to the maintainers file, which includes a link to the proposal. Is this how it is handled today? Conversation can still happen in the pull request. If it ends up merged, it is part of the public history. Is there something special about how it is handled today that you are concerned may not be replicatable in github? I've only been here for Jay's nomination and didn't really follow it closely

yacovm (Wed, 24 Jul 2019 14:01:01 GMT):
> If it ends up merged, it is part of the public history. Is there something special about how it is handled today that you are concerned may not be replicatable in github? the only thing not replicated is the proof of who +2ed or +1ed the CR, I think

yacovm (Wed, 24 Jul 2019 14:01:14 GMT):
and how many, etc.

BrettLogan (Wed, 24 Jul 2019 14:02:42 GMT):
@muralisr There will be a one to one, but we could scrape the comments and post them on the corresponding Jira for ones which exist (which is a majority of them). Most of the CI history also already exists in the Commit Rollup in Jira, right? Realistically, we can do whatever we want with the existing data in gerrit by scraping it

muralisr (Wed, 24 Jul 2019 14:02:51 GMT):
ok. There was some mention of comments. I ,might have misunderstood

BrettLogan (Wed, 24 Jul 2019 14:03:56 GMT):
So I have to check to see if you can lock a thread after the change is merged, as I was able to go in and +1 a merged change in github. What I couldn't do was add a +2 after the fact, and the history of who +2 the change exists after the merge in the commit history

muralisr (Wed, 24 Jul 2019 14:04:35 GMT):
sounds good... good to not to lose comments (the +2 and approvals not so important I think)

BrettLogan (Wed, 24 Jul 2019 15:17:17 GMT):
And just to confirm, you can lock +1 at any point in Pull Request, and +2's can't be added after a merge. So we can preserve that for things like voting on maintainers

jyellick (Wed, 24 Jul 2019 15:26:34 GMT):
It sounds like we may have no option, but, the biggest inadequacy I see with Github is how it handles dependent changes. We say in our coding guidelines to "keep change requests small", and to break large changes into a series of smaller ones. I do believe this is critical for doing meaningful code review. However, Github PRs simply have no support for a "PR Series". If you push one PR which contains commits of another, you simply end up with 2 PRs, one that is a subset of the other. You can set the source branch manually, but then when the base PR merges, it breaks the child, and the child PR needs to be updated manually. There are hacky, manual ways to approximate a change-series style Gerrit workflow like: https://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/ But this approach requires user and maintainer discipline in the authoring and merging of PRs which makes the complexity of Gerrit seem simple. There is certainly community demand to allow PRs to stack: https://github.com/isaacs/github/issues/867 https://github.com/isaacs/github/issues/950 https://github.com/isaacs/github/issues/959 There are even some projects/plugins to make the manual PR stacking process less awful: https://github.com/ryanhiebert/probot-chain https://github.com/z0al/dep Still, if we move off of Gerrit, losing the ability to manage a CR series with a simple `git push` and instead having to do awkward backflips will be a serious regression.

jyellick (Wed, 24 Jul 2019 15:26:34 GMT):
It sounds like we may have no option, but, the biggest inadequacy I see with Github is how it handles dependent changes. We say in our coding guidelines to "keep change requests small", and to break large changes into a series of smaller ones. I do believe this is critical for doing meaningful code review. However, Github PRs simply have no support for a "PR Series". If you push one PR which contains commits of another, you simply end up with 2 PRs, one that is a subset of the other. You can set the source branch manually, but then when the base PR merges, it breaks the child, and the child PR needs to be updated manually. There are hacky, manual ways to approximate a change-series style Gerrit workflow like: https://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/ But this approach requires user and maintainer discipline in the authoring and merging of PRs which makes the complexity of Gerrit seem simple. There is certainly community demand to allow PRs to stack: https://github.com/isaacs/github/issues/867 https://github.com/isaacs/github/issues/950 https://github.com/isaacs/github/issues/959 There are even some projects/plugins to make the manual PR stacking process less awful: https://github.com/ryanhiebert/probot-chain https://github.com/z0al/dep But, despite the demand, Github has no clean way to address the problem. If we move off of Gerrit, losing the ability to manage a CR series with a simple `git push` and instead having to do awkward backflips will be a serious regression.

yacovm (Wed, 24 Jul 2019 15:56:44 GMT):
@jyellick - I guess we'll have to resort to doing several commits in a single PR, and then have an all or nothing merge?

yacovm (Wed, 24 Jul 2019 15:56:55 GMT):
jyellick - I guess we'll have to resort to doing several commits in a single PR, and then have an all or nothing merge?

jyellick (Wed, 24 Jul 2019 15:59:45 GMT):
That is one option, though I do think this will hurt the quality of reviews. It will be difficult to track which commits have actually been reviewed, whether the changes in them have been addressed etc. I haven't played with it too much, but I recall github also being rather ungraceful when it came to modifying a PR. Either you stack a new commit on top (which, might end up being huge if the change ripples through the dependent commits), or you do a force push and rewrite the commit history, which as I recall the github UI doesn't handle particularly nicely. I haven't played much with github in this respect recently though.

yacovm (Wed, 24 Jul 2019 16:01:25 GMT):
yeah that's what I noticed too... it's a problem for people like me that always forget to `goimports` the code, etc. and they end up pushing commits on top that only get resolved when the merge is a squad-and-merge one.

mbwhite (Wed, 24 Jul 2019 16:04:53 GMT):
I've worked on systems both with and without the concept of co-req and pre-req changes. And when the change control system has moved on the same codebase between systems with different approaches. Likewise the same discussion has occured.

mbwhite (Wed, 24 Jul 2019 16:07:21 GMT):
The only wisdom from those experiences is (a) never try and get one system to do exactly the same as something else, it hurts in the long run (b) the most important thing is the discussion so it's clear how the team develops as a whole and can tackle the issues clearly

yacovm (Wed, 24 Jul 2019 16:14:13 GMT):
actually @mbwhite @jyellick - this makes me wonder - is it possible to do code reviews of stacked commits *without CI* in gerrit, and after code review has finished, promote that commit to github so it can pass CI ?

yacovm (Wed, 24 Jul 2019 16:15:28 GMT):
I know it sounds a bit complex, but if you can somehow verify (maybe using hash + automation) that the gerrit commit is the same commit as in git... then you can code review stacked CRs easily

yacovm (Wed, 24 Jul 2019 16:15:28 GMT):
I know it sounds a bit complex (and probably an overkill), but if you can somehow verify (maybe using hash + automation) that the gerrit commit is the same commit as in git... then you can code review stacked CRs easily

jyellick (Wed, 24 Jul 2019 16:25:41 GMT):
But if the commit doesn't pass CI in github, then what's your recourse? Having CI run before review (waste machine time instead of human) seems optimal.

yacovm (Wed, 24 Jul 2019 16:26:53 GMT):
you can submit a PR to github, if it passes CI, gerrit picks up the change set, you review it in gerrit if you want (in case it's someone that likes to stack 20 commits ;) , not mandatory) and then you update the commits in github according to gerrit, and gerrit picks up these changes too.

jyellick (Wed, 24 Jul 2019 16:33:08 GMT):
Definitely a better flow, but having two SCMs is still awkward.

huxd (Thu, 25 Jul 2019 05:37:38 GMT):
Has joined the channel.

liurain (Thu, 25 Jul 2019 07:33:58 GMT):
I recently submitted a proposal to the community to contribute to the new project, but there seems to be some controversy about the comments on it. Based on the comments in the comments, I hope to discuss it at the next contributor meeting. You are also very welcome to comment on this proposal. https://wiki.hyperledger.org/display/HYP/Hyperledger+Justitia+Proposal

rolsonquadras (Thu, 25 Jul 2019 19:42:43 GMT):
Has joined the channel.

mastersingh24 (Fri, 26 Jul 2019 10:03:02 GMT):
Using two SCMs is a non-starter in my book ... the main reason to move to Github is primarily to improve our CI ... the current LF managed Jenkins is simply not working for us and the options we've been offered simply don't work with Gerrit and have no plans to integrate with Gerrit in the foreseeable future. There are many fairly substantial projects which are using Github ... many of them are Apache projects which moved from using svn and various review tools to Github PRs (Kafka and Spark are 2 examples). Of course I think we need to set guidelines on how we want things to work (e.g. adding commits to address changes, force merge for rebase, squashing commits on merge, etc). I think there are ways to address differences, perceived shortcomings, etc ....

jyellick (Fri, 26 Jul 2019 13:57:57 GMT):
Agreed, if fixing our CI woes means we need to deal with a new workflow on Github, I think it will be worth it, and we'll figure out a new model. I'm just remembering the pre-Gerrit days when we were on Github and some of the workflow problems we had.

mastersingh24 (Fri, 26 Jul 2019 13:58:42 GMT):
Indeed ... I think we do need to "get our act together" and determine how we want things to work

BrunoVavala (Thu, 01 Aug 2019 18:55:05 GMT):
Has joined the channel.

BrunoVavala (Thu, 01 Aug 2019 18:55:06 GMT):
Hello Fabric Maintainers, is it possible to schedule a playback session on Aug 20? We (the contributors of the Hyperledger Labs Fabric Private Chaincode project) would like to give an overview of the FPC project (design, objectives, current status, integration with Fabric, deployment, use cases) and get some feedback from you.

dave.enyeart (Fri, 02 Aug 2019 13:29:47 GMT):
@BrunoVavala sure, how about at the Aug 21st contributor meeting?

sykesm (Fri, 02 Aug 2019 15:38:25 GMT):
Anyone know where the process for requesting the creation of a new repository lives? The new LF JIRA system indicates that "links to governing body approval" are required. So, assistance and direction to that portion is what I'm looking for. This is related to the creation of the fabric-chaincode-go and fabric-protos repositories...

dave.enyeart (Fri, 02 Aug 2019 17:51:14 GMT):
If they are looking for governing body approval our two options are a CR vote (e.g. an update to fabric readme to list the intra project dependencies) or a Jira proposal with upvotes by majority of maintainers.

dave.enyeart (Fri, 02 Aug 2019 17:52:57 GMT):
Previously the requests were not formalized, so this time around will set the new precedent.

BrunoVavala (Fri, 02 Aug 2019 21:26:47 GMT):
@dave.enyeart sounds interesting, let me check and I will give you an answer on Monday

mastersingh24 (Mon, 05 Aug 2019 12:23:22 GMT):
I already had them created

mastersingh24 (Mon, 05 Aug 2019 12:24:43 GMT):
fabric-chaincode-go fabric-protos fabric-protos-go

mastersingh24 (Mon, 05 Aug 2019 12:24:46 GMT):
all created

mastersingh24 (Mon, 05 Aug 2019 12:25:02 GMT):
Gerrit repos though ... until we moe to Github

mastersingh24 (Mon, 05 Aug 2019 12:25:02 GMT):
Gerrit repos though ... until we move to Github

sykesm (Mon, 05 Aug 2019 13:35:09 GMT):
Is there a mirror configured as well?

mastersingh24 (Mon, 05 Aug 2019 13:37:02 GMT):
yeah ... I asked them to do that ... but I don't think it's triggered until the first commit as I recall

sykesm (Mon, 05 Aug 2019 13:37:11 GMT):
thanks

BrunoVavala (Mon, 05 Aug 2019 17:51:18 GMT):
@dave.enyeart Ok, we can schedule our session on Aug 21st at 9am EST. I suppose we'll use the hyperledger.community.3 zoom meeting.

BrunoVavala (Mon, 05 Aug 2019 17:51:18 GMT):
@dave.enyeart Ok, we can schedule our session on Aug 21st at 9am EST. I suppose we'll use the hyperledger.community.3 zoom meeting. Title: Fabric Private Chaincode: Enhancing Chaincode Privacy with Intel SGX Presenters: Marcus Brandenburger (IBM Zurich), Michael Steiner (Intel Labs), Bruno Vavala (Intel Labs) Thanks!

BrunoVavala (Mon, 05 Aug 2019 17:51:18 GMT):
@dave.enyeart Ok, we can schedule our session on Aug 21st at 9am EST. I suppose we'll use the hyperledger.community.3 zoom meeting. I hope we can use a 1h slot (~40 for presentation, the rest for questions) Title: Fabric Private Chaincode: Enhancing Chaincode Privacy with Intel SGX Presenters: Marcus Brandenburger (IBM Zurich), Michael Steiner (Intel Labs), Bruno Vavala (Intel Labs) Thanks!

msteiner (Tue, 06 Aug 2019 04:05:50 GMT):
Has joined the channel.

huxd (Tue, 06 Aug 2019 05:45:36 GMT):
will this meeting be posted in the public meeting calendar? interested in this topic...

bur (Tue, 06 Aug 2019 07:45:39 GMT):
Has joined the channel.

liurain (Tue, 06 Aug 2019 08:50:20 GMT):
Hello Fabric Maintainers,``` ```

liurain (Tue, 06 Aug 2019 08:53:04 GMT):
``` I want to briefly introduce one of my project proposals at the August 7th meeting. The entire introduction process may take up to 15 minutes. Do not know if it is ok? ```

guoger (Tue, 06 Aug 2019 09:59:02 GMT):
@liurain i believe you are talking about bi-weekly contributor meeting, and you are welcome to pitch the project. @dave.enyeart is there an agenda that @liurain should fill beforehand?

liurain (Tue, 06 Aug 2019 10:02:13 GMT):
That's right, I am talking about that meeting. The relevant agenda has not yet been filled out.

dave.enyeart (Tue, 06 Aug 2019 15:33:17 GMT):
@liurain I've added you to the agenda for tomorrow's Contributor Meeting: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

dave.enyeart (Tue, 06 Aug 2019 15:33:38 GMT):
@BrunoVavala I've also added you to the agenda for August 21st

BrunoVavala (Tue, 06 Aug 2019 17:02:12 GMT):
Thank you @dave.enyeart

dave.enyeart (Tue, 06 Aug 2019 20:47:49 GMT):
@here This has been discussed a few times but no Jira existed previously... I've created it:

dave.enyeart (Tue, 06 Aug 2019 20:47:51 GMT):
Remove s390x support from Fabric in v2.0: https://jira.hyperledger.org/browse/FAB-16237

dave.enyeart (Tue, 06 Aug 2019 20:48:28 GMT):
Please either upvote in Jira or add a comment so that we can gauge maintainer support to get this into v2.0

dave.enyeart (Tue, 06 Aug 2019 20:48:28 GMT):
Please either upvote in Jira or add a comment with any concerns, so that we can gauge maintainer support to get this into v2.0

liurain (Wed, 07 Aug 2019 00:44:53 GMT):
Thank you.

richzhao (Wed, 07 Aug 2019 01:39:14 GMT):
@dave.enyeart I would ask a few mins to discuss fabric multi-language documentation proposal https://wiki.hyperledger.org/display/HYP/Multi-Language+Documentation

dave.enyeart (Wed, 07 Aug 2019 09:50:13 GMT):
Sure, it looks like we'll have about 15 more minutes available in today's contributor meeting. I've added you to the agenda at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

dave.enyeart (Wed, 07 Aug 2019 09:53:44 GMT):
Today's contributor meeting agenda (9am US Eastern / 13:00 UTC) - Release update (10 minutes) - Fabric CI proposal update - Brett Logan (10 minutes) - Hyperledger Justitia proposal - https://wiki.hyperledger.org/display/HYP/Hyperledger+Justitia+Proposal - Rui Liu (25 minutes) - Hyperledger Fabric documentation translation proposal update - https://wiki.hyperledger.org/display/HYP/Multi-Language+Documentation - Rich Zhao (15 minutes)

dave.enyeart (Wed, 07 Aug 2019 09:53:44 GMT):
Today's contributor meeting agenda (9am US Eastern / 13:00 UTC) https://zoom.us/my/hyperledger.community.3 - Release update (10 minutes) - Fabric CI proposal update - Brett Logan (10 minutes) - Hyperledger Justitia proposal - https://wiki.hyperledger.org/display/HYP/Hyperledger+Justitia+Proposal - Rui Liu (25 minutes) - Hyperledger Fabric documentation translation proposal update - https://wiki.hyperledger.org/display/HYP/Multi-Language+Documentation - Rich Zhao (15 minutes)

dave.enyeart (Wed, 07 Aug 2019 12:59:49 GMT):
@here meeting starting

sstone1 (Wed, 07 Aug 2019 14:36:59 GMT):
@guoger @yacovm is this error something to do with CR 32428? [34m2019-08-07 12:33:14.020 UTC [orderer.common.server] Main -> INFO 008[0m Starting cluster listener on [::]:7050 [35m2019-08-07 12:33:14.022 UTC [grpc] RegisterService -> FATA 009[0m grpc: Server.RegisterService after Server.Serve for "orderer.AtomicBroadcast"

sstone1 (Wed, 07 Aug 2019 14:37:07 GMT):
https://jenkins.hyperledger.org/job/fabric-samples-verify-x86_64/458/artifact/fabcar/fabcar-go/orderer.example.com.log

yacovm (Wed, 07 Aug 2019 14:49:52 GMT):
if you mean Jay's change set, then I would bet you're right because: > [35m2019-08-07 12:33:14.022 UTC [grpc] RegisterService -> FATA 009[0m grpc: Server.RegisterService after Server.Serve for "orderer.AtomicBroadcast" must be related to these gRPC server line moving he did

yacovm (Wed, 07 Aug 2019 14:49:57 GMT):
I'll take a look now

sstone1 (Wed, 07 Aug 2019 14:51:50 GMT):
thanks Yacov!

yacovm (Wed, 07 Aug 2019 14:55:30 GMT):
ha i think i got it... if we use kafka/solo then `clusterGRPCServer` is `grpcServer` and then ``` if !reuseGrpcListener { logger.Info("Starting cluster listener on", clusterGRPCServer.Address()) go clusterGRPCServer.Start() } ``` activates it i think

yacovm (Wed, 07 Aug 2019 14:55:41 GMT):
@guoger ?

yacovm (Wed, 07 Aug 2019 15:05:19 GMT):
https://gerrit.hyperledger.org/r/#/c/fabric/+/32765/ @sstone1

guoger (Wed, 07 Aug 2019 15:23:22 GMT):
@yacovm yup, my bad. but can we just change it to `if !reuseGrpcListener && clusterType {`

guoger (Wed, 07 Aug 2019 15:24:02 GMT):
so we have only one line change, and it is more explicit by checking `clusterType`, instead of checking something is nil

yacovm (Wed, 07 Aug 2019 17:26:21 GMT):
yeah.... that was my initial attempt but I hated it. Turns out, the 2nd attempt doesn't work because it gets carried by the registrar current and then blows up down the path. I reverted to patch set 1 as you suggest

jyellick (Wed, 07 Aug 2019 20:29:01 GMT):
Master seems to be broken from a compilation perspective again https://gerrit.hyperledger.org/r/c/fabric/+/32777

wlahti (Wed, 07 Aug 2019 20:29:48 GMT):
I pushed a fix here: https://gerrit.hyperledger.org/r/c/fabric/+/32772

wlahti (Wed, 07 Aug 2019 20:29:48 GMT):
I pushed a fix for that here. should be ready to go: https://gerrit.hyperledger.org/r/c/fabric/+/32772

jyellick (Wed, 07 Aug 2019 20:30:22 GMT):
Great, thanks @wlahti

minollo (Thu, 08 Aug 2019 17:23:55 GMT):
@dave.enyeart is there a recording available for yesterday's (8/7) contributor meeting?

dave.enyeart (Thu, 08 Aug 2019 20:05:24 GMT):
Yes, posted at: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

minollo (Thu, 08 Aug 2019 20:11:00 GMT):
Grazie

jambonrose (Fri, 09 Aug 2019 16:30:50 GMT):
Has joined the channel.

guoger (Mon, 12 Aug 2019 03:15:45 GMT):
anyone knows how to get a list of recently failed IT/UT logs from jenkins? Basically i'm trying to find a recent hit of a particular test flake, and I have to spend many clicks on open CRs with red cross to find logs. Thx!

dave.enyeart (Mon, 12 Aug 2019 12:34:50 GMT):
@guoger The failed jobs can be seen in red on the left side of these pages:

dave.enyeart (Mon, 12 Aug 2019 12:34:51 GMT):
https://jenkins.hyperledger.org/view/fabric/job/fabric-verify-unit-tests-x86_64/

dave.enyeart (Mon, 12 Aug 2019 12:35:06 GMT):
https://jenkins.hyperledger.org/view/fabric/job/fabric-verify-integration-tests-x86_64/

guoger (Mon, 12 Aug 2019 13:03:50 GMT):
thanks!

kostas (Mon, 12 Aug 2019 21:25:32 GMT):
With the upcoming move off of Gerrit, is there any point in manually purging (abandoning) long-standing PRs? We have some that go way back (up to a year).

cbf (Tue, 13 Aug 2019 12:18:42 GMT):
please abandon any personal CRs that are stale or unlikely to move forward

dave.enyeart (Tue, 13 Aug 2019 13:36:40 GMT):
Right, the plan is to get all CRs either merged or abandoned before the change from Gerrit. We should start cleaning up now. Let's all try to chip away at it this week.

dave.enyeart (Tue, 13 Aug 2019 13:37:08 GMT):
We can be more aggressive on the abandoning and site the CR Aging policy: https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#cr-aging-policy

dave.enyeart (Tue, 13 Aug 2019 13:37:08 GMT):
We can be more aggressive on the abandoning and cite the CR Aging policy: https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#cr-aging-policy

dave.enyeart (Tue, 13 Aug 2019 13:37:08 GMT):
We can be more aggressive on the abandoning and reference the CR Aging policy: https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#cr-aging-policy

dave.enyeart (Tue, 13 Aug 2019 13:38:37 GMT):
Also an objective of the weekly triage role is to look for stale CRs and address, either by reviewing or abandoning or tagging some maintainers for help.

dave.enyeart (Tue, 13 Aug 2019 13:38:37 GMT):
Also an objective of the weekly triage role is to look for stale CRs and address, either by reviewing themselves or tagging a maintainer for help with review/abandonment.

dave.enyeart (Tue, 13 Aug 2019 13:39:16 GMT):
This week it is @wlahti . Next week it is @BrettLogan .

rjones (Tue, 13 Aug 2019 14:54:46 GMT):
Has joined the channel.

rjones (Tue, 13 Aug 2019 14:55:18 GMT):
qq: what is Fabric's timeline to move? pre or post 2.0?

kostas (Tue, 13 Aug 2019 15:49:17 GMT):
I am not talking about my own CRs.

BrettLogan (Tue, 13 Aug 2019 16:33:45 GMT):
Yea, there is a parallel conversation happening in #ci-pipeline that addresses this

rjones (Tue, 13 Aug 2019 16:45:29 GMT):
It is possible to move some of those pending ones directly, but I would not suggest it. If we turn on a full mirror to github, you end up with a branch per patch - look https://github.com/alljoyn/services-base for an example of the branch/commit ratio

rodolfoleal (Thu, 15 Aug 2019 16:40:02 GMT):
Has joined the channel.

BrettLogan (Thu, 15 Aug 2019 19:25:06 GMT):
FYI: Fabric-Verify-Unit-Tests builds are broken in CI for a couple hours. We migrated to a new cloud image today built using a new process to support newer versions of Golang. There was a minor bug in it, that wasnt caught in our sandbox CI system. We are building the new image now and will have the change in within the next couple hours

BrettLogan (Thu, 15 Aug 2019 19:25:06 GMT):
FYI: Fabric Unit Tests are broken for a couple hours. We migrated to a new cloud image today built using a new process to support newer versions of Golang. There was a minor bug in it, that wasnt caught in our sandbox CI system. We are building the new image now and will have the change in within the next couple hours

sykesm (Mon, 19 Aug 2019 13:36:39 GMT):
Before we start moving all projects over to github, we have three we want to start with: 1. fabric-protos 2. fabric-protos-go 3. fabric-chaincode-go We have pushed templates of the first two to the hyperledger-cicd project to play with some possible CI tooling. Regardless of that, we need to act on the move sooner rather than later. Who is or should be driving the definition of the PR review process? Setup of something like probot for DCO validation?

sykesm (Mon, 19 Aug 2019 13:36:39 GMT):
Before we start moving all projects over to github, we have three we want to start with: 1. fabric-protos 2. fabric-protos-go 3. fabric-chaincode-go We have pushed templates of the first two to the hyperledger-cicd project to play with some possible CI tooling. Regardless of that, we need to act on the move sooner rather than later. There are no dependencies on these projects so it makes it easy to experiment there. Who is or should be driving the definition of the PR review process? Setup of something like probot for DCO validation?

dave.enyeart (Mon, 19 Aug 2019 14:45:26 GMT):
@sykesm If you are talking about policies, you can propose here and then we can discuss at the maintainer/contributor meeting this Wednesday. In terms of implementing it, previously Chris Ferris and Ramesh worked on these types of things, they have transitioned most of the these duties to Brett Logan.

troyronda (Mon, 19 Aug 2019 14:54:11 GMT):
@sykesm Excellent. It would be wonderful to have a fabric-protos-go in hyperledger, itself. (and then also have fabric-sdk-go import from it.)

sykesm (Mon, 19 Aug 2019 20:49:09 GMT):
Implementing is trivial - I need guidance through process. Proposal is simple: the repositories live on github, PRs are required. PRs must be approved by one or more of the people listed in CODEOWNERS and builds must be successful.

sykesm (Mon, 19 Aug 2019 20:50:01 GMT):
fabric-protos-go will be its own top level repo and include a go.mod. Same is true of fabric-chaincode-go. They will no longer be in the fabric repo once we get through the process exercise.

galaxystar (Tue, 20 Aug 2019 01:23:17 GMT):
Has joined the channel.

bestbeforetoday (Tue, 20 Aug 2019 09:42:10 GMT):
Will there also be built and published _fabric-protos-node_ and _fabric-protos-java_ projects that the Node and Java SDKs can just depend on?

jtonline (Tue, 20 Aug 2019 09:45:35 GMT):
My understanding is that there will be published artifacts for Java (maven repo?) and JavaScript (npm module) - the go repo is just the go method of publishing. Happy to help get the build for those in place.

bestbeforetoday (Tue, 20 Aug 2019 09:46:06 GMT):
:thumbup:

sykesm (Tue, 20 Aug 2019 11:50:33 GMT):
@jtonline @bestbeforetoday that statement is only true if someone does the work.

sykesm (Tue, 20 Aug 2019 11:51:22 GMT):
We are doing what is necessary to extract the go chaincode shim from the fabric repo in a sane way.

sykesm (Tue, 20 Aug 2019 11:52:15 GMT):
There are no stories in our backlog for node/java at this time

sykesm (Tue, 20 Aug 2019 11:52:15 GMT):
Just wanted to give a bit of a warning - over the next couple of days we're going to be pulling the protos and generated bindings out of the fabric repo. The fabric-protos and fabric-protos-go have already been populated with the assets. We will also be putting the chaincode shim and extensions into fabric-chaincode-go at some point today and the package import will change. After everything is populated, we need to shift to using those new repositories for the go assets. I expect this will impact multiple repositories - especially those that use go chaincode.

troyronda (Tue, 20 Aug 2019 11:55:05 GMT):
I think it is time to advance the status of fabric-sdk-go. The SDK is being used in production and has had a stable client interface surface for several months. We sometimes receive questions about its status (e.g., Is it still alpha? Is it official?), and I think we need to be able to set a better direction to these community members. We also have been stuck numbering 1.0.0-alphax and we would like to get to a normalized versioning.

troyronda (Tue, 20 Aug 2019 11:56:12 GMT):
(this is somewhat related to the fabric-protos-go discussion, as it would be preferable to switch our exposed protos to the common types exposed by the new repo.)

jtonline (Tue, 20 Aug 2019 13:17:00 GMT):
@sykesm Is there an issue or anything I should link new stories to to get that in place? I'll double check here but I'm optimistic we can do the work :)

mbwhite (Tue, 20 Aug 2019 15:07:50 GMT):
As discussed - it is very much aligned with our interestes

dave.enyeart (Tue, 20 Aug 2019 20:24:48 GMT):
We'd like to update some of the brief Fabric descriptions on the Hyperledger web pages, please give a thumbs up if you're good with these updates, or comment if you'd like to see some additional edits:

dave.enyeart (Tue, 20 Aug 2019 20:24:48 GMT):
@here We'd like to update some of the brief Fabric descriptions on the Hyperledger web pages, please give a thumbs up if you're good with these updates, or comment if you'd like to see some additional edits. From shortest to longest brief description:

dave.enyeart (Tue, 20 Aug 2019 20:24:51 GMT):

Clipboard - August 20, 2019 4:24 PM

dave.enyeart (Tue, 20 Aug 2019 20:25:21 GMT):
https://www.hyperledger.org/

dave.enyeart (Tue, 20 Aug 2019 20:25:56 GMT):
Proposed Updated Text: `Enterprise grade DLT with privacy support`

dave.enyeart (Tue, 20 Aug 2019 20:26:28 GMT):
https://www.hyperledger.org/projects

dave.enyeart (Tue, 20 Aug 2019 20:27:02 GMT):
Proposed Updated Text: `An enterprise grade permissioned distributed ledger framework that offers modularity, versatility, and privacy options to satisfy a broad set of industry use cases ranging from finance, to healthcare, to supply-chain and more.`

dave.enyeart (Tue, 20 Aug 2019 20:27:23 GMT):
https://www.hyperledger.org/projects/fabric

dave.enyeart (Tue, 20 Aug 2019 20:27:43 GMT):
Proposed Updated Text: `Hyperledger Fabric is an enterprise grade permissioned distributed ledger framework for developing solutions and applications, that offers modularity and versatility, to satisfy a broad set of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy. `

kostas (Tue, 20 Aug 2019 22:37:40 GMT):
"Enterprise grade" is a compound modifier here, so a hyphen would be handy: enterprise-grade DLT. Other than that, LGTM.

mastersingh24 (Wed, 21 Aug 2019 09:44:51 GMT):
``` Hyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. It's modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy. ```

dave.enyeart (Wed, 21 Aug 2019 11:32:46 GMT):
ok, to summarize one more time, we've got these three:

dave.enyeart (Wed, 21 Aug 2019 11:32:46 GMT):
ok, to summarize one more time, we've got these three for the short, medium, and long description:

dave.enyeart (Wed, 21 Aug 2019 11:32:57 GMT):
`Enterprise-grade DLT with privacy support.`

dave.enyeart (Wed, 21 Aug 2019 11:33:08 GMT):
`An enterprise-grade permissioned distributed ledger framework that offers modularity, versatility, and privacy options to satisfy a broad set of industry use cases ranging from finance, to healthcare, to supply-chain and more.`

dave.enyeart (Wed, 21 Aug 2019 11:33:15 GMT):
`Hyperledger Fabric is an enterprise grade permissioned distributed ledger framework for developing solutions and applications, that offers modularity and versatility, to satisfy a broad set of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy. `

dave.enyeart (Wed, 21 Aug 2019 11:33:15 GMT):
`Hyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. It's modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.`

dave.enyeart (Wed, 21 Aug 2019 12:58:50 GMT):
@here Fabric Contributor Meeting starting: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 21 Aug 2019 12:59:04 GMT):
Agenda topics for today:

dave.enyeart (Wed, 21 Aug 2019 12:59:11 GMT):
- Release update (5 minutes) - Marketing update (5 minutes) - SCM update (5 minutes) - Fabric Private Chaincode: Enhancing Chaincode Privacy with Intel SGX - Marcus Brandenburger (IBM Zurich), Michael Steiner (Intel Labs), Bruno Vavala (Intel Labs) (45 minutes)

greg2git (Wed, 21 Aug 2019 13:12:07 GMT):
yeah, it should be 'its' even if it's very 'possessive'

mastersingh24 (Wed, 21 Aug 2019 13:12:48 GMT):
sorry ... yeah ... auto-correct got me on that one ;)

mastersingh24 (Wed, 21 Aug 2019 13:12:53 GMT):
should be "its"

troyronda (Wed, 21 Aug 2019 17:00:54 GMT):
FYI: I pushed a CR for fabric-sdk-go to use an external protos module (but we need to wait for the real repo, of course): https://gerrit.hyperledger.org/r/c/fabric-sdk-go/+/33084

rjones (Wed, 21 Aug 2019 17:04:58 GMT):
@troyronda One comment on that CR

metadata (Thu, 22 Aug 2019 09:22:28 GMT):
Has joined the channel.

shitaibin (Thu, 22 Aug 2019 12:17:40 GMT):
Has joined the channel.

troyronda (Thu, 22 Aug 2019 12:41:03 GMT):
I have tested the current master protos (from fabric-protos-go) using fabric-sdk-go against 1.4 with success. Is anyone aware of any breaking changes in the protos that will affect a client using 2.x protos targeting a 1.4 fabric network? (I assume not - so an upgraded SDK can target either 1.x or 2.x).

jtonline (Thu, 22 Aug 2019 13:25:00 GMT):
Fyi, https://jira.hyperledger.org/browse/FAB-16388 and https://jira.hyperledger.org/browse/FAB-16387

firas.qutishat (Thu, 22 Aug 2019 13:35:47 GMT):
Has joined the channel.

sykesm (Thu, 22 Aug 2019 14:12:21 GMT):
Just wanted to give a bit of a warning - over the next couple of days we're going to be pulling the protos and generated bindings out of the fabric repo. The fabric-protos and fabric-protos-go have already been populated with the assets. We will also be putting the chaincode shim and extensions into fabric-chaincode-go at some point today and the package import will change. After everything is populated, we need to shift to using those new repositories in fabric-test used by master for the go assets.

lehors (Thu, 22 Aug 2019 14:15:39 GMT):
hey, Fabric Maintainers, please beware that there is going to be "Maintainers Summit" in October, and all maintainers are encourage to attend. See: https://wiki.hyperledger.org/display/events/Maintainer+Summit+October+8-10%2C+2019

lehors (Thu, 22 Aug 2019 14:15:39 GMT):
hey, Fabric Maintainers, please beware that there is going to be a "Maintainers Summit" in October, and all maintainers are encourage to attend. See: https://wiki.hyperledger.org/display/events/Maintainer+Summit+October+8-10%2C+2019

binhn (Sat, 24 Aug 2019 20:23:25 GMT):
it's good to know who can attend the summit that we can plan some topics together

guoger (Mon, 26 Aug 2019 09:24:02 GMT):
not sure what to do if merge build fails? i.e. https://gerrit.hyperledger.org/r/c/fabric/+/33036/3

guoger (Mon, 26 Aug 2019 09:24:03 GMT):
thx

dave.enyeart (Mon, 26 Aug 2019 10:34:04 GMT):
@guoger The merge job failure looks like a unit test flake. The merge-end-2-end failure is a recurring problem from java sdk integration tests, hopefully @andrew-coleman @bestbeforetoday will get a fix this week.

dave.enyeart (Mon, 26 Aug 2019 10:34:19 GMT):
I did a 'remerge' to rerun the jobs to see if they pass this time

dave.enyeart (Mon, 26 Aug 2019 10:35:42 GMT):
The failures do not impact code getting merged, so sadly we've gotten accustomed to the failures in sdk integration tests

dave.enyeart (Mon, 26 Aug 2019 10:37:02 GMT):
@caod (Danny) Has the weekly role of triaging CI failures this week.

caod (Mon, 26 Aug 2019 10:37:02 GMT):
Has joined the channel.

guoger (Mon, 26 Aug 2019 10:49:17 GMT):
@dave.enyeart i see, thx!

dan13 (Mon, 26 Aug 2019 15:26:32 GMT):
Has joined the channel.

dave.enyeart (Mon, 26 Aug 2019 17:32:15 GMT):
@here trying to close to v1.4.3 release... i'm thinking we merge https://gerrit.hyperledger.org/r/#/c/fabric/+/33180/ first, but could use another pair of eyes

dave.enyeart (Mon, 26 Aug 2019 17:32:15 GMT):
@here trying to close down v1.4.3 release... i'm thinking we merge https://gerrit.hyperledger.org/r/#/c/fabric/+/33180/ first, but could use another pair of eyes

dave.enyeart (Mon, 26 Aug 2019 17:32:15 GMT):
trying to close down v1.4.3 release... i'm thinking we merge https://gerrit.hyperledger.org/r/#/c/fabric/+/33180/ first, but could use another pair of eyes

dave.enyeart (Mon, 26 Aug 2019 17:32:15 GMT):
trying to close down v1.4.3 release... i'm thinking we merge ~https://gerrit.hyperledger.org/r/#/c/fabric/+/33180/~ first, but could use another pair of eyes

dave.enyeart (Mon, 26 Aug 2019 17:33:09 GMT):
ah, Gari merged, thanks

dave.enyeart (Mon, 26 Aug 2019 17:34:55 GMT):
so, i think the last CR to merge would be the upgrade doc and what's new doc: https://gerrit.hyperledger.org/r/#/c/fabric/+/32864/

dave.enyeart (Mon, 26 Aug 2019 17:34:55 GMT):
so, i think the last CR to merge would be the upgrade doc and what's new doc: ~https://gerrit.hyperledger.org/r/#/c/fabric/+/32864/~

dave.enyeart (Mon, 26 Aug 2019 18:31:36 GMT):
All release-1.4 CRs targeted for v1.4.3 are now merged.

dave.enyeart (Mon, 26 Aug 2019 18:31:44 GMT):
@here Let's start MERGE FREEZE for release-1.4 branch so that we can release v1.4.3.

dave.enyeart (Mon, 26 Aug 2019 19:21:34 GMT):
@here Please review release notes for v1.4.3: https://gerrit.hyperledger.org/r/#/c/fabric/+/33186/1/release_notes/v1.4.3.txt

dave.enyeart (Mon, 26 Aug 2019 19:44:54 GMT):
and for fabric-ca: https://gerrit.hyperledger.org/r/#/c/fabric-ca/+/33188/

swetha (Tue, 27 Aug 2019 02:20:09 GMT):
github

dave.enyeart (Tue, 27 Aug 2019 03:42:32 GMT):
fabric, fabric-ca, fabric-samples v1.4.3 all tagged

dave.enyeart (Tue, 27 Aug 2019 03:42:37 GMT):
MERGE FREEZE lifted

dave.enyeart (Tue, 27 Aug 2019 03:42:51 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v1.4.3 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/6709 ----------------------------------------------------------------------

cbf (Tue, 27 Aug 2019 18:41:23 GMT):
:thumbsup:

BrettLogan (Wed, 28 Aug 2019 22:11:55 GMT):
FYI: Jenkins is currently experiencing severe performance issues, there is currently a backlog of jobs queued. Replying to your Gerrit changes to rerun builds that are already queued will only exacerbate the issue. We are investigating and working on resolution

BrettLogan (Wed, 28 Aug 2019 22:54:53 GMT):
Are our nodes in San Jose or Montreal datacenter

rjones (Thu, 29 Aug 2019 04:54:15 GMT):
Montreal

Hengming (Thu, 29 Aug 2019 13:46:08 GMT):
Has joined the channel.

Hengming (Fri, 30 Aug 2019 11:27:00 GMT):
fabric-sdk-node maintainers: there are two outgoing patch sets waiting for a while for CRs - 32205 and 32704 on Gerrit. Anyone can help to review them? Thanks a million.

sstone1 (Fri, 30 Aug 2019 12:10:29 GMT):
@bestbeforetoday @andrew-coleman @heatherp @bretharrison ^

dave.enyeart (Fri, 30 Aug 2019 13:05:20 GMT):
Note that channel #fabric-sdk-node is the best channel to use to get the attention of the fabric-sdk-node maintainers

dave.enyeart (Fri, 30 Aug 2019 13:06:32 GMT):
In case you missed it - protos have been moved to hyperledger/fabric-protos-go this morning in https://gerrit.hyperledger.org/r/#/c/fabric/+/33279/. Many CRs will need to be rebased and re-verified with `VerifyBuild`

dave.enyeart (Fri, 30 Aug 2019 13:07:28 GMT):
We can't count on the old verify +1s in these situations.

MHBauer (Sat, 31 Aug 2019 00:19:58 GMT):
yay

rjones (Sat, 31 Aug 2019 17:22:55 GMT):
I request reviews as appropriate please: https://gerrit.hyperledger.org/r/#/q/status:open+%22FAB-16489%22

rjones (Sat, 31 Aug 2019 17:22:55 GMT):
I request reviews and merges as appropriate please: https://gerrit.hyperledger.org/r/#/q/status:open+%22FAB-16489%22

rjones (Sat, 31 Aug 2019 17:23:35 GMT):
These are more urgent: https://gerrit.hyperledger.org/r/#/q/status:open+%22FAB-16487%22

rjones (Mon, 02 Sep 2019 19:21:42 GMT):
thanks @kostas I made the updates you suggested more broadly :)

rjones (Tue, 03 Sep 2019 13:59:10 GMT):
I pray before the fabric maintainers to merge these: https://gerrit.hyperledger.org/r/q/message:%252216489%2522+label:verified%253D1+status:open and consider merging these: https://gerrit.hyperledger.org/r/q/message:%252216489%2522+label:verified%253C1+status:open even though they are not V+1. Many of them never will be - there is no automation on those repos.

sykesm (Tue, 03 Sep 2019 14:55:39 GMT):
I took care of fabric-ca and fabric-lib-go

jyellick (Tue, 03 Sep 2019 18:51:27 GMT):
+2-ed and or merged those that I have privs for

rjones (Tue, 03 Sep 2019 20:24:40 GMT):
thank you both

rjones (Tue, 03 Sep 2019 20:25:27 GMT):
I don't know if you can merge https://gerrit.hyperledger.org/r/q/status:open+%22FAB-16487%22 but that is a security issue

dave.enyeart (Wed, 04 Sep 2019 11:11:26 GMT):
Most of them merged now

dave.enyeart (Wed, 04 Sep 2019 11:14:14 GMT):
Agenda for today's Contributor Meeting: - Release update - CI and SCM update - @sykesm @BrettLogan - Node.js SDK v2.0 roadmap - @bretharrison @andrew-coleman

dave.enyeart (Wed, 04 Sep 2019 11:14:27 GMT):
Anything else to discuss?

lehors (Wed, 04 Sep 2019 12:58:33 GMT):
@dave.enyeart I think it'd be good to discuss the October maintainers meeting: https://wiki.hyperledger.org/display/events/Maintainer+Summit+October+8-10%2C+2019

lehors (Wed, 04 Sep 2019 12:59:11 GMT):
all maintainers are encouraged to attend, and it'd be best if some specific topics were identified and added to the agenda

dave.enyeart (Wed, 04 Sep 2019 13:02:15 GMT):
@here maintainer meeting starting https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 04 Sep 2019 13:02:15 GMT):
@here contributor meeting starting https://zoom.us/my/hyperledger.community.3

bretharrison (Wed, 04 Sep 2019 14:40:34 GMT):
Here is the NodeSDK refactored low level https://jira.hyperledger.org/browse/FABN-1347

rjones (Wed, 04 Sep 2019 14:40:51 GMT):
thank you

rjones (Wed, 04 Sep 2019 14:42:16 GMT):
dang, sorry I missed that call

dave.enyeart (Wed, 04 Sep 2019 15:00:18 GMT):
Recording is published at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

medikent (Thu, 05 Sep 2019 00:31:07 GMT):
Any note on a registration cost for the Oct 8-10 Maintainer summit?

lehors (Thu, 05 Sep 2019 16:01:59 GMT):
it

lehors (Thu, 05 Sep 2019 16:01:59 GMT):
it's free

lehors (Thu, 05 Sep 2019 16:01:59 GMT):
@medikent it's free

mastersingh24 (Thu, 05 Sep 2019 18:08:17 GMT):
there is no admission free, but in life nothing is free @lehors LOL

rallam (Thu, 05 Sep 2019 18:33:26 GMT):
Has joined the channel.

rallam (Thu, 05 Sep 2019 19:32:54 GMT):
Hi, I have an application which does batch updates. Right now, it process only one application, and ignores the other one. How does chaincode/sdkclient act to multiple transaction submitted at the sametime..does it have code in place to handle concurrency..? Thank you!

rallam (Thu, 05 Sep 2019 19:32:54 GMT):
Hi, I have an application which does batch updates. Right now, it process only one transaction, and ignores the other one. How does chaincode/sdkclient act to multiple transaction submitted at the sametime..does it have code in place to handle concurrency..? Thank you!

rallam (Thu, 05 Sep 2019 19:32:54 GMT):
Hi, I have an application which does batch updates to the chaincode. Right now, it process only one transaction, and ignores the other one. How does chaincode/sdkclient act to multiple transaction submitted at the sametime..does it have code in place to handle concurrency..? Thank you!

lehors (Thu, 05 Sep 2019 20:54:51 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=4vXK6nf72n4iQMB6P) @mastersingh24 I almost wrote "free to you" but thought people would understand. I guess you're not in that category 😋

dave.enyeart (Fri, 06 Sep 2019 13:17:14 GMT):
Folks - please remember to Close the Jira when merging a CR.

rjones (Fri, 06 Sep 2019 15:36:00 GMT):
I have four changes I would like to get merged: https://gerrit.hyperledger.org/r/#/q/fab-16489+status:open these set a baseline CODEOWNERS as part of the move to GitHub. I would like to get these in so that once the move is made, the teams can manage themselves.

dave.enyeart (Fri, 06 Sep 2019 15:52:47 GMT):
+2ed what I could. need another. also need @andrew-coleman @bestbeforetoday for https://gerrit.hyperledger.org/r/#/c/fabric-gateway-java/+/33320/

bestbeforetoday (Fri, 06 Sep 2019 17:01:30 GMT):
Done

dave.enyeart (Sat, 07 Sep 2019 13:13:22 GMT):
We've seen a falling off in the number of maintainers reviewing CRs proactively... Reminder that we could use all maintainers help, especially at this time since we plan to retire Gerrit.

rjones (Sat, 07 Sep 2019 13:21:32 GMT):
@dave.enyeart do you, the maintainers, think a stepwise move from Gerrit to GitHub would work? Take the atomic projects, move those, prove everything out?

dave.enyeart (Sat, 07 Sep 2019 15:43:00 GMT):
We've been talking about doing one first to learn any lessons, likely fabric-ca. @BrettLogan is driving a plan... I'll put some notes over on #fabric-ci to drive more discussion.

rallam (Mon, 09 Sep 2019 17:56:15 GMT):
Hi, I have an application which does batch updates to the chaincode. Right now, it process only one transaction, and ignores the other one. How does chaincode/sdkclient act to multiple transaction submitted at the sametime..does it have code in place to handle concurrency..? Thank you!

troyronda (Wed, 11 Sep 2019 14:42:37 GMT):
We should apply the next release tag to the Fabric SDK Go (last tag was end of March). Fabric SDK Go Beta 1 CR has been proposed: https://gerrit.hyperledger.org/r/c/fabric-sdk-go/+/33455

BrettLogan (Wed, 11 Sep 2019 19:35:28 GMT):
As a step to moving to a new CI system for Fabric, the following repos have been archived: fabric-docs and fabric-test-resources. The following repos will have their Gerrit -> GitHub mirrors broken, Gerrit will be marked read-only, and GitHub will become the main SCM system for these repos: fabric-amcl, fabric-chaintool and homebrew-fabric. This process has been initiated, and will happen once the team at Linux Foundation IT services act on the ticket

dsessions (Wed, 11 Sep 2019 20:29:56 GMT):
Has joined the channel.

dsessions (Wed, 11 Sep 2019 20:29:57 GMT):
ibm

MHBauer (Thu, 12 Sep 2019 00:07:17 GMT):
\o/

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning Fabric-CA will migrate to GitHub for SCM and Azure Pipelines for CI. The Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request's directly through GitHub. PR's will be built and tested in Azure Pipeline's and the results will be published to the GitHub Pull Request Conversation's tab as well as the Pull Request's Check's tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link's to the actual Azure Pipeline's Job page can be obtained in the Pull Request's Check's tab. Gerrit will be read-only from that time point on, and will no longer accept pushes.

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning *Fabric-CA* will migrate to GitHub for SCM and Azure Pipelines for CI. The *Fabric-CA* Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request’s through GitHub. *Fabric-CA* Gerrit will be taken read-only at the same time, and will no longer accept pushes. PR’s will be built and tested in Azure Pipeline’s and the results will be published to the GitHub Pull Request Conversation’s tab as well as the Pull Request’s Check’s tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link’s to the actual Azure Pipeline’s Job page (where realtime job output, log archives from containers, and documentation build artifacts can be obtained) can be obtained in the Pull Request’s Check’s tab.

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning Fabric-CA will migrate to GitHub for SCM and Azure Pipelines for CI. The Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request' through GitHub. Gerrit will be taken read-only at the same time, and will no longer accept pushes. PR's will be built and tested in Azure Pipeline's and the results will be published to the GitHub Pull Request Conversation's tab as well as the Pull Request's Check's tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link's to the actual Azure Pipeline's Job page can be obtained in the Pull Request's Check's tab.

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning Fabric-CA will migrate to GitHub for SCM and Azure Pipelines for CI. The Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request' through GitHub. Gerrit will be taken read-only at the same time, and will no longer accept pushes. PR's will be built and tested in Azure Pipeline's and the results will be published to the GitHub Pull Request Conversation's tab as well as the Pull Request's Check's tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link's to the actual Azure Pipeline's Job page (where job output, log archives from containers and documentation build artifacts can be obtained) can be obtained in the Pull Request's Check's tab.

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning Fabric-CA will migrate to GitHub for SCM and Azure Pipelines for CI. The Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request's through GitHub. Gerrit will be taken read-only at the same time, and will no longer accept pushes. PR's will be built and tested in Azure Pipeline's and the results will be published to the GitHub Pull Request Conversation's tab as well as the Pull Request's Check's tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link's to the actual Azure Pipeline's Job page (where job output, log archives from containers and documentation build artifacts can be obtained) can be obtained in the Pull Request's Check's tab.

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning Fabric-CA will migrate to GitHub for SCM and Azure Pipelines for CI. The Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request's through GitHub. Gerrit will be taken read-only at the same time, and will no longer accept pushes. PR's will be built and tested in Azure Pipeline's and the results will be published to the GitHub Pull Request Conversation's tab as well as the Pull Request's Check's tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link's to the actual Azure Pipeline's Job page (where realtime job output, log archives from containers and documentation build artifacts can be obtained) can be obtained in the Pull Request's Check's tab.

BrettLogan (Fri, 13 Sep 2019 15:13:53 GMT):
*Announcement*: On Monday morning Fabric-CA will migrate to GitHub for SCM and Azure Pipelines for CI. The Gerrit -> GitHub mirror will be broken as early as 0600 EST. Following this change, we will begin serving Pull Request's through GitHub. Gerrit will be taken read-only at the same time, and will no longer accept pushes. PR's will be built and tested in Azure Pipeline's and the results will be published to the GitHub Pull Request Conversation's tab as well as the Pull Request's Check's tab. Azure will post status updates at the beginning of the CI cycle as well as updating successes and failures in realtime. Link's to the actual Azure Pipeline's Job page (where realtime job output, log archives from containers, and documentation build artifacts can be obtained) can be obtained in the Pull Request's Check's tab.

BrettLogan (Fri, 13 Sep 2019 15:16:33 GMT):
This will be a learning process for both the migration process and the PR process. You should follow this closely as this migration will help redefine our PR process moving forward for all repos

BrettLogan (Fri, 13 Sep 2019 15:16:33 GMT):
This will be a learning process for both the migration process and the PR process. You should follow this closely and provide input as this migration will help redefine our PR process moving forward for all repos. As a reminder, #fabric-ci exists for conversations related to CI

MHBauer (Fri, 13 Sep 2019 16:52:04 GMT):
cool!

yacovm (Fri, 13 Sep 2019 17:46:35 GMT):
When is the ETA of the Fabric core migration, and is there a plan to terminate gerrit for Fabric core (take offline completely)? I am asking because I think keeping a read only gerrit server for a while (a few months) would be good. @BrettLogan

rjones (Fri, 13 Sep 2019 17:47:29 GMT):
@yacovm my expectation is that, like other projects, the Gerrit instance will live on read-only as long as the project is willing to pay for it.

BrettLogan (Fri, 13 Sep 2019 17:47:45 GMT):
^^^

rjones (Fri, 13 Sep 2019 17:48:22 GMT):
I have done exports of Gerrit to GitHub, and it is not pretty.

BrettLogan (Fri, 13 Sep 2019 17:48:27 GMT):
I am preparing a proposal for the Wednesday maintainers meeting to open the discussion around time-frames for the other repos

rjones (Fri, 13 Sep 2019 17:48:39 GMT):
Every change set is a new branch - so every repo has thousands of branches.

rjones (Fri, 13 Sep 2019 17:49:45 GMT):
Here is an example: https://github.com/alljoyn/core-alljoyn 4600 commits, 6200 branches

dhuseby (Fri, 13 Sep 2019 21:00:31 GMT):
@rjones if you don't need all of those branches, then you can trim them after migration

rjones (Fri, 13 Sep 2019 21:31:11 GMT):
@dhuseby and you lose the code reviews.

rjones (Mon, 16 Sep 2019 15:36:12 GMT):
Has left the channel.

BrettLogan (Tue, 17 Sep 2019 01:30:44 GMT):
Fabric CA has officially been migrated to GitHub. Code changes can be submitted through the PR process via the repo at https://github.com/hyperledger/fabric-ca

BrettLogan (Tue, 17 Sep 2019 01:30:49 GMT):
CI is executed in Azure Pipelines and the UI can be found at https://dev.azure.com/Hyperledger/Fabric%20CA/_build

BrettLogan (Tue, 17 Sep 2019 01:30:49 GMT):
CI is executed in Azure Pipelines and the UI can be found at https://dev.azure.com/Hyperledger/Fabric%CA/_build

BrettLogan (Tue, 17 Sep 2019 01:30:49 GMT):
CI is executed in Azure Pipelines and the UI can be found at https://dev.azure.com/Hyperledger/Fabric CA/_build

mastersingh24 (Tue, 17 Sep 2019 07:52:08 GMT):
Have we outlined / documented the process we are using? Typical flow where people fork and submit PRs?

BrettLogan (Tue, 17 Sep 2019 12:32:27 GMT):
I am hoping to have a rough draft ready later today for the maintainers to look over and approve. Trying to make sure we cover as many bases in it as possible from the start

MHBauer (Tue, 17 Sep 2019 19:51:38 GMT):
What "cases" could there be? We need to pick one thing and do that. Not support multiple.

BrettLogan (Tue, 17 Sep 2019 20:07:01 GMT):
By cases I mean supporting both contributions from Gerrit and GitHub. Until we migrate everything, we have to interim support both, and make sure the doc is clear on processes for both, and that it is clear which repos are in which systems

BrettLogan (Tue, 17 Sep 2019 20:07:01 GMT):
By "bases" I mean supporting both contributions from Gerrit and GitHub. Until we migrate everything, we have to interim support both, and make sure the doc is clear on processes for both, and that it is clear which repos are in which system

BrettLogan (Tue, 17 Sep 2019 20:08:19 GMT):
We don't want to have to field dozens of questions about why pushes aren't being accepted in Gerrit as we migrate because we aren't clear enough in the doc, or don't make it accessible enough

MHBauer (Tue, 17 Sep 2019 20:08:39 GMT):
:+1:

swetha (Tue, 17 Sep 2019 20:11:36 GMT):
@BrettLogan is there a doc in the process of moving from gerrit to github? I am curious mostly about how we convert our current ci/cd builds.

swetha (Tue, 17 Sep 2019 20:11:36 GMT):
@BrettLogan is there a doc on the process of moving from gerrit to github? I am curious mostly about how we convert our current ci/cd builds.

BrettLogan (Tue, 17 Sep 2019 20:23:50 GMT):
There is not. It's fairly straightforward, the vast, vast majority of the work is handled by LFIT. In tomorrows Fabric's maintainers call I will go over what we did to migrate Fabric CA. I am reaching out to a maintainer in each project, who I am asking to discuss with the rest of the maintainers when they would like to migrate. Due to the tight timeline for getting this work done, I am offering to do the migration for several projects where their CI pipelines are trivial to replicate in Azure, so we can get them done asap. The remaining teams who I don't have the cycles to offer my help, I am scheduling meetings with their maintainers so I can give them the information they need to do this on their own.

swetha (Tue, 17 Sep 2019 20:25:19 GMT):
Thanks for the info! I am one of the maintainers for the fabric-chaincode-evm. I know in the past we have had ci/cd issues because our project was using pipelines instead of what fabric core was using. Do you know if that will be a problem for us?

BrettLogan (Tue, 17 Sep 2019 20:26:31 GMT):
With Azure you will have total ownership over your CI, you won't have a dependency on the CI-Management repo like you do today. You will handle all of your own dependency installation and configuring your pipeline in whatever manner you see fit

swetha (Tue, 17 Sep 2019 20:27:27 GMT):
Oh great! I will wait for tomorrow's call to learn more then :) Thanks!

MHBauer (Tue, 17 Sep 2019 21:01:38 GMT):
I'll probably catch the recording afterwards. Too early.

sstone1 (Wed, 18 Sep 2019 08:23:33 GMT):
I can't seem to use the latest Docker images from master

sstone1 (Wed, 18 Sep 2019 08:23:48 GMT):
``` $ docker run --rm -it hyperledger/fabric-orderer standard_init_linux.go:211: exec user process caused "no such file or directory" $ docker run --rm -it hyperledger/fabric-orderer sh / # orderer sh: orderer: not found / # ls -lart $(which orderer) -rwxrwxr-x 1 root root 40709240 Sep 18 00:38 /usr/local/bin/orderer / # file $(which orderer) /usr/local/bin/orderer: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, Go BuildID=CwjXkg9GqLuUBAKs79oR/EufQYnLs5NH0atAf5YPD/PKXT7U_VQ4kyy1L4goin/VZX8KxoXgsd5xR49aDwb, BuildID[sha1]=f97518d7fc15fb7f8e0d47870b13883103e74f94, not stripped / # /usr/local/bin/orderer sh: /usr/local/bin/orderer: not found / # ldd /usr/local/bin/orderer /lib64/ld-linux-x86-64.so.2 (0x7eff1968e000) libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7eff1968e000) libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7eff1968e000) libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7eff1968e000) ```

BrettLogan (Wed, 18 Sep 2019 11:33:43 GMT):
@sstone1 my best guess is this is related to the changes merged yesterday that change the image build process. I will confer with the developer and we will fix and republish asap

sstone1 (Wed, 18 Sep 2019 11:52:26 GMT):
:+1: thanks @BrettLogan

BrettLogan (Wed, 18 Sep 2019 12:16:27 GMT):
@sstone1 did you pull those images or build them locally

sstone1 (Wed, 18 Sep 2019 12:17:25 GMT):
pulled them from nexus

dave.enyeart (Wed, 18 Sep 2019 12:51:39 GMT):
@here Agenda for today's Fabric Contributor Meeting - starting in 10 minutes: - v2.0 release update - CI and SCM update - Brett Logan - Fabric v2.0 - ledger data upgrade Manish Sethi, Wenjian Qiao Any other topics?

dave.enyeart (Wed, 18 Sep 2019 12:53:03 GMT):
As a reminder anybody can propose topics for future meetings here, and then we'll update the schedule at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

dave.enyeart (Wed, 18 Sep 2019 12:59:30 GMT):
Contributor Meeting web conference: https://zoom.us/my/hyperledger.community.3

rjones (Wed, 18 Sep 2019 13:52:02 GMT):
Has joined the channel.

rjones (Wed, 18 Sep 2019 15:07:59 GMT):
@dave.enyeart let me know how or when I can help

BrettLogan (Thu, 19 Sep 2019 01:32:18 GMT):

Clipboard - September 18, 2019 9:32 PM

BrettLogan (Thu, 19 Sep 2019 01:33:27 GMT):
@here Hello Fabric maintainers! As most of you are aware, earlier this week we migrated Fabric CA from Gerrit to GitHub for SCM and Jenkins to Azure Pipelines for CI. That changeover went off without any hiccups. In this morning’s maintainers call we have proposed moving Fabric as the next repository. With a deadline of 12/31 for migrating repos, and the Fabric 2.0 release slated for late Q4, waiting to migrate Fabric until after 2.0 is released is no longer a viable option. In a sooner-rather-than-later move, we are proposing to migrate the core Fabric repo from Gerrit to GitHub and Jenkins to Azure Pipelines on Friday, 9/27 at 0900 PST.

BrettLogan (Thu, 19 Sep 2019 01:33:27 GMT):
Hello Fabric maintainers! As most of you are aware, earlier this week we migrated Fabric CA from Gerrit to GitHub for SCM and Jenkins to Azure Pipelines for CI. That changeover went off without any hiccups. In this morning’s maintainers call we have proposed moving Fabric as the next repository. With a deadline of 12/31 for migrating repos, and the Fabric 2.0 release slated for late Q4, waiting to migrate Fabric until after 2.0 is released is no longer a viable option. In a sooner-rather-than-later move, we are proposing to migrate the core Fabric repo from Gerrit to GitHub and Jenkins to Azure Pipelines on Friday, 9/27 at 0900 PST. With that in mind, this proposal includes the fact that the Fabric maintainers will need to cleanup existing CR’s in Gerrit. To accommodate this, we are proposing a “code freeze” starting Monday 9/23 at 0600 PST. This will give the maintainers the week to abandon, merge, or request changes to existing CR’s. During this time period we will ask developers to submit changes directly through GitHub’s pull request process (will communicate through mailing list, rocket chat, and comment on CR’s that are erroneously opened in Gerrit). These PR’s will remain in place until the migration has finished on Friday, then we will mass trigger these PR’s to run CI against them. This early migration will provide us an opportunity to build out release pipelines as well and test those release pipelines with a potential 2.0-beta release. Assuming no dissention we hope to move forward with this plan and look forward to lowering our barrier of entry for new contributors, by adopting these industry standards, and opening up Fabric to contributions from contributors who may have been turned off in the past to the CR process in Gerrit.

BrettLogan (Thu, 19 Sep 2019 01:33:36 GMT):
With that in mind, this proposal includes the fact that the Fabric maintainers will need to cleanup existing CR’s in Gerrit. To accommodate this, we are proposing a “code freeze” starting Monday 9/23 at 0600 PST. This will give the maintainers the week to abandon, merge, or request changes to existing CR’s. During this time period we will ask developers to submit changes directly through GitHub’s pull request process (will communicate through mailing list, rocket chat, and comment on CR’s that are erroneously opened in Gerrit). These PR’s will remain in place until the migration has finished on Friday, then we will mass trigger these PR’s to run CI against them. This early migration will provide us an opportunity to build out release pipelines as well and test those release pipelines with a potential 2.0-beta release. Assuming no dissention we hope to move forward with this plan and look forward to lowering our barrier of entry for new contributors, by adopting these industry standards, and opening up Fabric to contributions from contributors who may have been turned off in the past due to the CR process in Gerrit.

dave.enyeart (Thu, 19 Sep 2019 11:11:33 GMT):
@here We ask that all maintainers pause their own work items for a week in order to focus all energy on getting through the fabric gerrit backlog.

dave.enyeart (Thu, 19 Sep 2019 11:11:36 GMT):
For review comments that have been lingering, I think it is reasonable for us to upload patches to address review comments rather than continue to wait for the original submitter.

dave.enyeart (Thu, 19 Sep 2019 19:36:35 GMT):
@here UPDATE: A few of the maintainers talked after the contributor meeting and we'd like to better understand the github PR review process before we open the flood gates for Fabric PRs. We will take a deeper look at this next week and share here. We will NOT code freeze Fabric in Gerrit September 23rd and will NOT cutover to github September 27th. We will communicate an updated date after getting comfortable with the github PR review process. In the meantime, it still makes sense to expedite getting through the Gerrit review backlog, so no change there. I would encourage trivial PRs to Fabric CA in Github so that everybody gets comfortable with the new flow.

rjones (Thu, 19 Sep 2019 19:56:05 GMT):
@here Hyperledger has a test org. If you want to play with stuff, please let me know your GitHub ID. I am inviting everyone as an owner so you can see all the options available.

rjones (Thu, 19 Sep 2019 19:56:58 GMT):
@BrettLogan and @sykesm also have the ability to add people to https://github.com/hyperledger-cicd - no need to block on me

tongli (Thu, 19 Sep 2019 20:05:05 GMT):
litong01 is my id, @rjones

rjones (Thu, 19 Sep 2019 20:11:57 GMT):
you are a member since last week

rjones (Thu, 19 Sep 2019 20:22:40 GMT):
https://wiki.hyperledger.org/display/fabric/Migration+status I will hook this up and replace it with a JIRA query _soon_

MHBauer (Thu, 19 Sep 2019 20:29:40 GMT):
nice page

rjones (Thu, 19 Sep 2019 20:52:40 GMT):
thanks. I assume it is duplicating a JIRA query somewhere

MHBauer (Thu, 19 Sep 2019 20:54:32 GMT):
ha

guoger (Fri, 20 Sep 2019 03:41:29 GMT):
@dave.enyeart hi, wondering if the contributor meeting record is available now? thx!

rjones (Fri, 20 Sep 2019 05:11:21 GMT):
@guoger https://wiki.hyperledger.org/display/fabric/Contributor+Meetings has them at the bottom of the page

rjones (Wed, 25 Sep 2019 13:45:12 GMT):
https://wiki.hyperledger.org/display/fabric/Migration+status Feel free to kibitz on this list

lehors (Wed, 25 Sep 2019 17:59:19 GMT):
hi there, I'm surprised not to see any announcements about the move to github on the mailing list, did I miss it?

lehors (Wed, 25 Sep 2019 17:59:38 GMT):
we should blast the mailing list with messages letting people know what's going on

lehors (Wed, 25 Sep 2019 18:00:02 GMT):
the fabric-ca README still points to gerrit for contributions...

lehors (Wed, 25 Sep 2019 18:00:58 GMT):
I heard on the recording of last week's contributors call that we would have special instructions until we can update readthedocs, when is that going to happen??

lehors (Wed, 25 Sep 2019 18:03:18 GMT):
I love Dave's status reports on this channel and the recordings of the contributors calls because they help a lot in finding out what's up when I have been busy with other things but we can't rely on everyone to know to look into those to find out that there is a major change going on

lehors (Wed, 25 Sep 2019 18:03:30 GMT):
we have to crank up our communication here

BrettLogan (Wed, 25 Sep 2019 18:27:05 GMT):
While I totally agree that we need to blast the mailing list about major happenings with the CI migration there are a few reasons we have elected not to do so just yet (we actually had major communications prepared for the mailing list last week, but decided to hold off). Chief among these reasons are that historically speaking we have had a large number of CI anti-patterns copied throughout the hyperledger org that have just made things impossible to maintain and update. We chose to move Fabric-CA first to learn the process, but to also make 100% sure we get it right before moving Fabric and engaging the larger community. A number of the Fabric-CA maintainers have been meeting several times a week to go over whats been done and make sure we get this right. Our fear is announcing too soon, and people being turned off by the lack of defined processes, or people replicating existing bad patterns and those spreading throughout the community. I do agree we can do several things better in the meantime: At the very least update the Fabric CONTRIBUTING doc to point to the CA readme and add minor GitHub contribution facts (with a 'beta'-like tag on that section that lets people know these aren't finalized) to the CA readme and second, send an email to the mailing list saying that we have retired Gerrit for CA and migrated to GitHub, and see the Fabric CA readme for contribution guidelines. Our intention has never been to hide whats happening, it was to at least be transparent in existing channels as we can, without replicating Fabric's history of bad practices in CI. And once we knew we had it right, then blast the email list.

BrettLogan (Wed, 25 Sep 2019 18:27:05 GMT):
While I totally agree that we need to blast the mailing list about major happenings with the CI migration there are a few reasons we have elected not to do so just yet (we actually had major communications prepared for the mailing list last week, but decided to hold off). Chief among these reasons are that historically speaking we have had a large number of CI anti-patterns copied throughout the hyperledger org that have just made things impossible to maintain and update. We chose to move Fabric-CA first to learn the process, but to also make 100% sure we get it right before moving Fabric and engaging the larger community. A number of the Fabric-CA maintainers have been meeting several times a week to go over whats been done and make sure we get this right. Our fear is announcing too soon, and people being turned off by the lack of defined processes, or people replicating existing bad patterns and those spreading throughout the community. I do agree we can do several things better in the meantime: At the very least update the Fabric CONTRIBUTING doc to point to the CA readme and add minor GitHub contribution facts (with a 'beta' tag on that section) to the CA readme and second, send an email to the mailing list saying that we have retired Gerrit for CA and migrated to GitHub, and see the Fabric CA readme for contribution guidelines. Our intention has never been to hide whats happening, it was to at least be transparent in existing channels as we can, without replicating Fabric's history of bad practices in CI. And once we knew we had it right, then blast the email list.

BrettLogan (Wed, 25 Sep 2019 18:27:42 GMT):
I will take it up as a task by end of week to finish updating the fabric-ca readme with a pointer from CONTRIBUTING docs, and to let the email list know this information is available and CA has migrated

BrettLogan (Wed, 25 Sep 2019 18:27:42 GMT):
I will take it up as a task by end of week to finish updating the fabric readme with a pointer from CONTRIBUTING docs, and to let the email list know this information is available and CA has migrated

lehors (Wed, 25 Sep 2019 18:34:37 GMT):
the README should have a big banner with a warning

lehors (Wed, 25 Sep 2019 18:34:37 GMT):
readthedocs too

lehors (Wed, 25 Sep 2019 18:37:39 GMT):
I have no doubts that it's not because anyone is trying to hide anything

lehors (Wed, 25 Sep 2019 18:37:55 GMT):
but I think the fear you are referring to is ill founded

lehors (Wed, 25 Sep 2019 18:38:11 GMT):
I see zero reason not to say what you just stated here on the mailing list

lehors (Wed, 25 Sep 2019 18:38:17 GMT):
people aren't stupid

lehors (Wed, 25 Sep 2019 18:38:21 GMT):
they can understand

lehors (Wed, 25 Sep 2019 18:38:30 GMT):
IF they are told what's going on

lehors (Wed, 25 Sep 2019 18:38:46 GMT):
it's nice for the maintainers to be talking to one another but that's not enough

lehors (Wed, 25 Sep 2019 18:39:32 GMT):
there should have been an announcement sent about the coming changes

lehors (Wed, 25 Sep 2019 18:39:43 GMT):
and there should be on going updates being sent out

lehors (Wed, 25 Sep 2019 18:40:21 GMT):
call me old school if you want but I don't think filling up RC's channels cuts it

lehors (Wed, 25 Sep 2019 18:40:34 GMT):
this should be sent out to the mailing list

yacovm (Wed, 25 Sep 2019 18:56:29 GMT):
Worry not.... No one is pushing CRs to Fabric CA anyway

lehors (Wed, 25 Sep 2019 18:56:59 GMT):
come on Yacov, that's beside the point

lehors (Wed, 25 Sep 2019 18:57:22 GMT):
sorry if I missed the sarcasm ;-)

yacovm (Wed, 25 Sep 2019 18:57:40 GMT):
I'm just saying that Brett's approach makes sense - let's be sure we have all the things in place before we do official announcements

lehors (Wed, 25 Sep 2019 18:58:05 GMT):
I don't agree

lehors (Wed, 25 Sep 2019 18:58:18 GMT):
if we move a repo we ought to let people know

lehors (Wed, 25 Sep 2019 18:58:26 GMT):
whether it's fabric-ca or any other

lehors (Wed, 25 Sep 2019 18:58:49 GMT):
the mere fact that we are working on it justifies letting people know

lehors (Wed, 25 Sep 2019 19:00:46 GMT):
I see as no different than when I received an email from a sysadmin saying "watch out we are going to do a maintenance upgrade on xxx on - expect a disruption of the service blah blah"

lehors (Wed, 25 Sep 2019 19:00:46 GMT):
I see this as no different than when I received an email from a sysadmin saying "watch out we are going to do a maintenance upgrade on xxx on - expect a disruption of the service blah blah"

lehors (Wed, 25 Sep 2019 19:00:46 GMT):
I see this as no different than when I receive an email from a sysadmin saying "watch out we are going to do a maintenance upgrade on xxx on - expect a disruption of the service blah blah"

lehors (Wed, 25 Sep 2019 19:01:14 GMT):
then sometimes you get correcting announcements and the likes but at least you're informed

lehors (Wed, 25 Sep 2019 19:06:20 GMT):
by the way, there is a repo that I didn't see listed on the slide: fabric-test-resources

lehors (Wed, 25 Sep 2019 19:07:00 GMT):
I don't know whether it's actually sill used

rjones (Wed, 25 Sep 2019 19:07:04 GMT):
it was removed

lehors (Wed, 25 Sep 2019 19:07:44 GMT):
ah, but it says it's a mirror and points to gerrit

rjones (Wed, 25 Sep 2019 19:07:49 GMT):
https://github.com/hyperledger-archives/fabric-test-resources-gerrit

lehors (Wed, 25 Sep 2019 19:08:26 GMT):
ok, it may not matter

rjones (Wed, 25 Sep 2019 19:08:35 GMT):
https://wiki.hyperledger.org/display/fabric/fabric-test-resources is the dashboard for that project

rjones (Wed, 25 Sep 2019 19:08:48 GMT):
https://wiki.hyperledger.org/display/fabric/Migration+status contains the fabric repos

lehors (Wed, 25 Sep 2019 19:09:11 GMT):
good to know, thanks

lehors (Wed, 25 Sep 2019 19:09:36 GMT):
how does one know about this wiki?

rjones (Wed, 25 Sep 2019 19:10:16 GMT):
It is a page I created to work with Brett and Dave while we were plowing through the easy ones.

lehors (Wed, 25 Sep 2019 19:11:02 GMT):
seems useful, I recommend letting people know about when the plan is announced (last week ;-)

lehors (Wed, 25 Sep 2019 19:11:02 GMT):
seems useful, I recommend letting people know about it when the plan is announced (last week ;-)

BrettLogan (Wed, 25 Sep 2019 19:16:20 GMT):
I don't think I called anyone stupid. What I said was, historically people have copied existing code, for better or for worse, and that has lead to major problems. Unfortunately this is a fact. With every project in hyperledger currently revisiting CI, and Fabric being the most visible, we run a very real risk of people copying what we do. Our first revision to CA included things like `go get golint` which is the way it was done years ago. Having taken a step back, we realize this is a not the right approach anymore. These dependencies should be versioned. Unfortunately, every single repository that is Go-based has this anti-pattern copied in it's CI. If we blast the email list with every little thing that we do, we will never get a good CI system in place. Waiting until we are 100% ready to announce is logical when only 0.001% of the community is able to answer questions on CI and provide fixes for the current system. If I spent my workday and freetime and sleeptime doing nothing but answering CI questions (which is what I spend my time doing now) and sending emails, we would never get closer to getting this done. Again, I do agree we should have sent an email about the transition, and updated the readme by now, we will get that done

BrettLogan (Wed, 25 Sep 2019 19:16:20 GMT):
I don't think I called anyone stupid. What I said was, historically people have copied existing code, for better or for worse, and that has lead to major problems. Unfortunately this is a fact. With every project in hyperledger currently revisiting CI, and Fabric being the most visible, we run a very real risk of people copying what we do. Our first revision to CA included things like `go get golint` which is the way it was done years ago. Having taken a step back, we realize this is a not the right approach anymore. These dependencies should be versioned. Unfortunately, every single repository that is Go-based has this anti-pattern copied in it's CI. If we blast the email list with every little thing that we do, we will never get a good CI system in place. Waiting until we are 100% ready to announce is logical when only 0.001% of the community is able to answer questions on CI. If I spent my workday and freetime and sleeptime doing nothing but answering CI questions (which is what I spend my time doing now) and sending emails, we would never get closer to getting this done. Again, I do agree we should have sent an email about the transition, and updated the readme by now, and I will get it done, this one-man-team only has so many cycles to contribute. I can only offer my apologies that these things haven't happened yet and promise to work towards getting them done

rjones (Wed, 25 Sep 2019 19:24:05 GMT):
@lehors I was trying to decide between a JIRA epic and a wiki page, and I wanted to get some experience with the Decisions macro for... reasons :)

lehors (Wed, 25 Sep 2019 19:42:43 GMT):
Brett, I'm sorry if I sounded unappreciative of all the effort being put into all this. I really didn't mean that. I just think there is a desirable middle ground between "blasting the list with every little thing" and not saying anything.

lehors (Wed, 25 Sep 2019 19:43:15 GMT):
I think this is such a major change that it deserves more communication

lehors (Wed, 25 Sep 2019 19:43:57 GMT):
And this doesn't mean that *you* should be responsible for it

MHBauer (Wed, 25 Sep 2019 19:44:30 GMT):
@BrettLogan thanks for answering us for the fabric-chaincode-evm

dave.enyeart (Wed, 25 Sep 2019 20:47:19 GMT):
@lehors You are correct that we should announce plans and contribution guidance. The gap is that we are still pulling together the plan and contribution guidance! The near-zero traffic fabric-ca repository was chosen as the guinea pig so that we could discover any issues, and nail down concrete plans and contribution guidance. These are currently being written down in a proposal that will go out to the mailing list.

dave.enyeart (Wed, 25 Sep 2019 20:47:29 GMT):
Brett actually did draft a mailing list note for the fabric-ca transition, upon review by a few maintainers we thought it would be more effective to share the proposal for the next repositories in parallel with the announcement, otherwise it would lead to more questions than answers.

dave.enyeart (Wed, 25 Sep 2019 20:47:37 GMT):
Shame on us - we gambled and didn't count on an astute contributor catching us in the days inbetween :) Point taken.

BrettLogan (Fri, 27 Sep 2019 12:46:42 GMT):
FYI: we are aware of the severe degradation of performance with Gerrit over the last 24 hours. We are actively working with the linux foundation to identify the issue and provide remedy as soon as possible

rjones (Fri, 27 Sep 2019 13:22:47 GMT):
https://status.linuxfoundation.org/incidents/y197yg8qpb4d

BrettLogan (Mon, 30 Sep 2019 14:41:02 GMT):
For those of you with pending CI builds, I am working to identify the issue with LFIT. Jenkin's went into an unplanned shutdown, and with no jobs pending, isn't executing the shutdown cycle. We will update you when we have more information.

BrettLogan (Mon, 30 Sep 2019 15:04:36 GMT):
LFIT has fixed the issue

EltonSearcy (Mon, 30 Sep 2019 17:06:04 GMT):
Has joined the channel.

dave.enyeart (Mon, 30 Sep 2019 17:30:52 GMT):
key

BrettLogan (Tue, 01 Oct 2019 16:57:43 GMT):
https://gerrit.hyperledger.org/r/c/fabric/+/33817

BrettLogan (Tue, 01 Oct 2019 16:58:01 GMT):
First draft of github contributions

BrettLogan (Tue, 01 Oct 2019 16:58:22 GMT):
https://logs.hyperledger.org/production/vex-yul-hyp-jenkins-3/fabric-docs-build-x86_64/2221/html/github/github.html

BrettLogan (Tue, 01 Oct 2019 16:59:38 GMT):
As a reminder this is a stop gap for giving people a starting place for contributing via GitHub. It's not the be-all-end-all source of truth, that will be part of the much larger update coming soon with Fabric's migration

rjones (Tue, 01 Oct 2019 20:37:30 GMT):
As part of the migration, I need some help: https://gerrit.hyperledger.org/r/q/%2522%255Bin-68%255D%2522+status:open

rjones (Tue, 01 Oct 2019 20:37:53 GMT):
Furthermore, I propose to you the maintainers, you might consider relaxing the 2+2 requirement and go for NACR

dave.enyeart (Wed, 02 Oct 2019 02:35:49 GMT):
@here Please merge the github contribution doc: https://gerrit.hyperledger.org/r/#/c/fabric/+/33817/

dave.enyeart (Wed, 02 Oct 2019 02:36:14 GMT):
It doesn't have to be perfect yet... but we want to get a draft into the docs so that we can request feedback from community.

manish-sethi (Wed, 02 Oct 2019 04:23:54 GMT):
This is not yet in mergeable state. Basic things doesn't work... have left a few comments.

BrettLogan (Wed, 02 Oct 2019 07:02:46 GMT):
Addressed, good catch. Presumably none of us caught it because we were testing using release-1.4 (which already existed locally) and not master

dave.enyeart (Wed, 02 Oct 2019 11:15:36 GMT):
Thanks, let's get it merged now. We want to show at contributor meeting. We can make further edits in subsequent CR.

sykesm (Wed, 02 Oct 2019 12:39:51 GMT):
I feel like we've had that discussion before...

dave.enyeart (Wed, 02 Oct 2019 12:58:31 GMT):
@here Contributor Call starting

dave.enyeart (Wed, 02 Oct 2019 12:58:36 GMT):
Agenda topics:

dave.enyeart (Wed, 02 Oct 2019 12:58:37 GMT):
Release update CI and SCM update - Brett Logan Fabric node config proposal - Matt Sykes

dave.enyeart (Wed, 02 Oct 2019 12:58:44 GMT):
https://zoom.us/my/hyperledger.community.3

sykesm (Wed, 02 Oct 2019 13:02:52 GMT):
https://gist.github.com/sykesm/3a841471ab24ff711540dd78af2bf01d

lehors (Wed, 02 Oct 2019 13:05:04 GMT):
thank you for the announcement :-)

lehors (Wed, 02 Oct 2019 13:05:58 GMT):
just so you know I don't merely whine all the time ;-)

lehors (Wed, 02 Oct 2019 13:08:04 GMT):
btw, GitHub just announced the ability to comment on multiple diff lines - WOOHOO - just like Gerrit has been able to do for years... ;-)

rjones (Wed, 02 Oct 2019 21:09:59 GMT):
yeah, I know

dave.enyeart (Thu, 03 Oct 2019 02:23:30 GMT):
last time I unofficially polled maintainers majority agreed to single +2 for all projects except core fabric.

dave.enyeart (Thu, 03 Oct 2019 02:25:58 GMT):
the thinking was that we could relax things per directory after going to github... but upon looking at it, it looks like the number of reviewers (2 for fabric) is a project-wide setting, with only the ability to specify who the reviewers are per directory via CODEOWNERS file

rjones (Thu, 03 Oct 2019 02:34:15 GMT):
correct. I only meant to do it on Gerrit until the migration is over

yacovm (Thu, 03 Oct 2019 08:27:17 GMT):
@dave.enyeart you should IMO pull the docs from the fabric core...

josephnicholas (Fri, 04 Oct 2019 03:29:30 GMT):
Has joined the channel.

dave.enyeart (Wed, 09 Oct 2019 14:11:41 GMT):
People often pick the default branch when doing PRs to github. Therefore we are talking about making the default branch 'master' instead of 'release-1.4' for each of the fabric projects. Any concerns?

MHBauer (Wed, 09 Oct 2019 17:55:45 GMT):
I would imagine a lot of tutorials are encoded with that being stable/1.4

MHBauer (Wed, 09 Oct 2019 17:56:02 GMT):
Otherwise, that's a pretty usual expectation.

MHBauer (Wed, 09 Oct 2019 17:58:37 GMT):
And the tutorial thing can be solved with a hard reference on checkout `git clone XXXXXX --branch v1.4.3`

mbwhite (Thu, 10 Oct 2019 12:14:43 GMT):
FYI - Node chaincode @ unstable should now be install-able again - please let me know if not...

cbf (Thu, 10 Oct 2019 17:55:18 GMT):
all, after discussion here at the maintainers summit, a few of us thought it would be a good idea to adopt the RFC process that other teams are using

cbf (Thu, 10 Oct 2019 17:55:33 GMT):
I've drafted a proposal derived from Sawtooth https://github.com/christo4ferris/fabric-rfcs-proposal

cbf (Thu, 10 Oct 2019 17:56:04 GMT):
I'll ask Ry to create a repo after we've kicked the tires on this for a while

cbf (Thu, 10 Oct 2019 17:56:24 GMT):
please add comments or make proposed changes via PR

cbf (Thu, 10 Oct 2019 17:56:24 GMT):
please add issues or make proposed changes via PR

MHBauer (Thu, 10 Oct 2019 21:04:53 GMT):
I don't understand adding that on top of JIRA

kostas (Fri, 11 Oct 2019 00:41:55 GMT):
Done and done.

dave.enyeart (Fri, 11 Oct 2019 12:32:01 GMT):
@MHBauer The idea is that for proposals we discuss in fabric-rfcs and then merge the final design as a forever record of what was agreed to. This would be in place of Jira for proposals and feature designs, as those tend to get lost in the Jira abyss. Many other projects in Hyperledger and beyond have had good success with this approach.

dave.enyeart (Fri, 11 Oct 2019 12:33:09 GMT):
Jira is better for tracking the actual implementation by decomposing stories/tasks across components.

dave.enyeart (Fri, 11 Oct 2019 12:33:09 GMT):
Jira is better for tracking the actual implementation by decomposing stories/tasks across components, and then rolling up with other issues to understand a release.

dave.enyeart (Fri, 11 Oct 2019 12:33:48 GMT):
As GitHub continues to mature, it MAY replace Jira at some point for everything, but I propose we take it one step at a time.

dave.enyeart (Fri, 11 Oct 2019 12:34:10 GMT):
This and related topics will be a focus on contributor meeting next Wednesday.

dave.enyeart (Fri, 11 Oct 2019 12:36:38 GMT):
Another proposal that we can discuss here or in contributor meeting, is that for small work items self contained in one PR, there would be no requirement to open a corresponding Jira.

dave.enyeart (Fri, 11 Oct 2019 12:38:22 GMT):
Jira would track the backlog of future work items, including bugs, tasks, and implementation stories for larger work items.

cbf (Fri, 11 Oct 2019 12:58:59 GMT):
:thumbsup:

cbf (Fri, 11 Oct 2019 16:37:28 GMT):
thanks @kostas !

cbf (Fri, 11 Oct 2019 16:37:57 GMT):
all, Kostas made some changes, encourage feedback on this RFC proposal from others as well

cbf (Fri, 11 Oct 2019 16:38:08 GMT):
hope we can resolve by Weds maintainers call

cbf (Fri, 11 Oct 2019 16:39:01 GMT):
as a reminder, the link to the proposal is here https://github.com/christo4ferris/fabric-rfcs-proposal

cbf (Fri, 11 Oct 2019 17:28:02 GMT):
https://gerrit.hyperledger.org/r/c/fabric/+/33947 Proposal to add Pam Andrejko to maintainers

dave.enyeart (Fri, 11 Oct 2019 17:54:00 GMT):
Shifting docs to its own repository has been discussed for a long time. We decided to defer further talks on that topic until after the transition to GitHub. So yeah, having Pam as a maintainer would be awesome. +1ed in the CR. Just wanted to mention this context in case others had similar thoughts.

cbf (Fri, 11 Oct 2019 17:55:18 GMT):
yes, agreed but no need to wait for that IMO

dave.enyeart (Fri, 11 Oct 2019 17:55:26 GMT):
right

MHBauer (Fri, 11 Oct 2019 21:30:36 GMT):
I am not familiar with jira, but that just leads me to more questions. What were people doing before? Do we have no designs for anything?

kostas (Fri, 11 Oct 2019 23:21:25 GMT):
JIRA for everything including the design doc. The rough process was something along the lines of (1) create a JIRA with an RFC, (2) present it on a maintainers/contributors meeting for comments/support, (3) advance the JIRA issue from there.

yacovm (Fri, 11 Oct 2019 23:25:19 GMT):
yeah.... and in between do community playback for feedback and comments

MHBauer (Fri, 11 Oct 2019 23:28:37 GMT):
Is there a way to filter the existing ones out?

kostas (Fri, 11 Oct 2019 23:39:24 GMT):
Highly unlikely. Filtering for epics would be a good start but I doubt it's a 1:1 mapping.

MHBauer (Tue, 15 Oct 2019 20:55:47 GMT):
Why do a lot of scripts point at dockerhub when we have a nexus instance where images are hosted?

MHBauer (Tue, 15 Oct 2019 20:55:57 GMT):
balancing off the load?

MHBauer (Tue, 15 Oct 2019 20:55:57 GMT):
:+1:

BrettLogan (Tue, 15 Oct 2019 21:08:33 GMT):
Very poor historical design

BrettLogan (Tue, 15 Oct 2019 21:08:33 GMT):
Very poor historical design, though Nexus is for development consumption, not community consumption. You will find places where that rule isn't always applied

BrettLogan (Tue, 15 Oct 2019 21:08:33 GMT):
Very poor historical design, though Nexus is for development consumption, not community consumption

BrettLogan (Tue, 15 Oct 2019 21:10:08 GMT):
Once we get Fabric's repo's off of Gerrit, next on our plate is to make a decision about where Fabric's artifacts are stored, and where they come from when used in CI (or are built instead of pulled, and passed through stages in CI) and where the community consume them from

MHBauer (Tue, 15 Oct 2019 21:24:57 GMT):
:+1:

dave.enyeart (Wed, 16 Oct 2019 12:59:42 GMT):
@here maintainer meeting starting - https://zoom.us/my/hyperledger.community.3 Agenda topics: *Release update* v1.4.4 targeted for November - bug fixes - Also shifts fabric docker images from ubuntu to debian:buster-20190910-slim - smaller images, more secure - note - v2.0 shifts to alpine images - even smaller, even more secure v2.0 targeted for December (if run out of time I'd propose at least do a v2.0.0-beta release). Largest v2.0 items remaining: - config updates for peer, orderer, fabric-ca (and downstream impacts to tests, samples, docs, etc) - external chaincode documentation - state database cache for improved performance - upgrade documentation - node sdk v2.0 refactoring - in master split fabric-client into fabric-base (for transactions) and fabric-admin (for v2.0 lifecycle support) *fabric-rfcs repository to capture new proposals* - see proposal at https://github.com/christo4ferris/fabric-rfcs-proposal *SCM and CI update* - Pull Request template - see https://github.com/hyperledger/fabric-ca/pull/53 - Change default branch to master in all repositories - Working through release process on fabric-ca - Once above items complete, shift core fabric repository to github - Other repositories (e.g. sdks, chaincodes, fabric-test) can transition at any time Anything else?

dave.enyeart (Wed, 16 Oct 2019 12:59:42 GMT):
@here maintainer meeting starting - https://zoom.us/my/hyperledger.community.3 Agenda topics: *Release update* v1.4.4 targeted for November - bug fixes - Also shifts fabric docker images from ubuntu to debian:buster-20190910-slim - smaller images, more secure - note - v2.0 shifts to alpine images - even smaller, even more secure v2.0 targeted for December (if run out of time I'd propose at least do a v2.0.0-beta release). Largest v2.0 items remaining: - config updates for peer, orderer, fabric-ca (and downstream impacts to tests, samples, docs, etc) - external chaincode documentation - state database cache for improved performance - upgrade documentation - node sdk v2.0 refactoring - in master split fabric-client into fabric-base (for transactions) and fabric-admin (for v2.0 lifecycle support) *fabric-rfcs repository to capture new proposals* - see proposal at https://github.com/christo4ferris/fabric-rfcs-proposal *SCM and CI update* - Pull Request template - see https://github.com/hyperledger/fabric-ca/pull/53 - Change default branch to master in all repositories - Working through release process on fabric-ca - Updating Contribution documentation for github - Once above items complete, shift core fabric repository to github - Other repositories (e.g. sdks, chaincodes, fabric-test) can transition at any time Anything else?

mbwhite (Wed, 16 Oct 2019 13:04:24 GMT):
Just on the topic of the move to github - we're blocked until we have credentials for publishing to npm, maven, dockerhub etc.

BrettLogan (Wed, 16 Oct 2019 13:05:14 GMT):
Correct, I opened a ticket yesterday to get the credentials installed in AZP. Hoping to have them by the end of the week

mbwhite (Wed, 16 Oct 2019 13:15:01 GMT):
No issues with the RFCs approach

cbf (Wed, 16 Oct 2019 17:05:33 GMT):
sorry I missed the call this morning... what was the outcome of the RFCs discussion?

BrettLogan (Wed, 16 Oct 2019 19:48:33 GMT):
Friday, at 1600EST there will be a 2 hour outage on linux foundation hosted infrastructure. The outage is scheduled to occur as late in the day as possible, and during reasonable business hours so that in the event there is an issue with infrastructure upgrade teams within Linux Foundation can be brought in to help triage the issue while still in office.

BrettLogan (Wed, 16 Oct 2019 19:48:48 GMT):
The following infrastructure will be effected:

BrettLogan (Wed, 16 Oct 2019 19:48:48 GMT):
The following infrastructure will be affected:

BrettLogan (Wed, 16 Oct 2019 19:48:51 GMT):
```wiki.hyperledger.org jira.hyperledger.org members.hyperledger.org jenkins.hyperledger.org + sandbox chat.hyperledger.org nexus.hyperledger.org gerrit.hyperledger.org```

BrettLogan (Wed, 16 Oct 2019 19:48:51 GMT):
```wiki.hyperledger.orgjira.hyperledger.org members.hyperledger.org jenkins.hyperledger.org + sandbox chat.hyperledger.org nexus.hyperledger.org gerrit.hyperledger.org```

rjones (Wed, 16 Oct 2019 22:00:33 GMT):
@mbwhite @BrettLogan ah could we chat about what credentials are missing where? what ticket was opened?

dave.enyeart (Thu, 17 Oct 2019 03:44:57 GMT):
no comments... which I assume means everybody is somewhere between agreement and ecstatic :)

dave.enyeart (Thu, 17 Oct 2019 03:45:16 GMT):
I encouraged everybody to read the proposal in full and comment

mbwhite (Thu, 17 Oct 2019 07:55:40 GMT):
Hello; the final publishing step requires us to be able to publish to NPM, DockerHub, Maven Central, (and also publish to GitHub pages). The github repos can be used for staging purposes, but the final destinations need to be the main repos... it's the credentials for these that are required

BrettLogan (Fri, 18 Oct 2019 18:12:41 GMT):
@here Reminder: Starting in 2 hours (1600 EST) OS updates will take all Hyperledger infrastructure offline for approximately 2 hours. Starting at (1500 EST) the Jenkins queue will be disabled, and any newly submitted jobs will automatically run when the queue is re-enabled. The following infrastructure is affected by this outage:

BrettLogan (Fri, 18 Oct 2019 18:12:41 GMT):
Reminder: Starting in 2 hours (1600 EST) OS updates will take all Hyperledger infrastructure offline for approximately 2 hours. Start at (1500 EST) the Jenkins queue will be disabled, and any newly submitted jobs will automatically run when the queue is re-enabled. The following infrastructure is affected by this outage:

BrettLogan (Fri, 18 Oct 2019 18:12:41 GMT):
@here Reminder: Starting in 2 hours (1600 EST) OS updates will take all Hyperledger infrastructure offline for approximately 2 hours. Start at (1500 EST) the Jenkins queue will be disabled, and any newly submitted jobs will automatically run when the queue is re-enabled. The following infrastructure is affected by this outage:

BrettLogan (Fri, 18 Oct 2019 18:12:43 GMT):
```wiki.hyperledger.org jira.hyperledger.org members.hyperledger.org jenkins.hyperledger.org + sandbox chat.hyperledger.org nexus.hyperledger.org gerrit.hyperledger.org```

dave.enyeart (Wed, 23 Oct 2019 20:52:57 GMT):
@here Do you still see a need to keep this historical pre-v1.0 doc topic: https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html

dave.enyeart (Wed, 23 Oct 2019 20:52:58 GMT):
It has old concepts such as ValidatedLedger and a Checkpoint which deviates from current Checkpoint thoughts. The note at the top even says it is superseded by the v1.0 paper at https://arxiv.org/abs/1801.10228v2 , and frankly superseded by the rest of the doc now. We kept it as a historical reference, but I think we could delete from master (v2.0) and just keep in release-1.4 for historical reference.

yacovm (Wed, 23 Oct 2019 20:56:44 GMT):
no reason to keep an outdated document. Besides, I'm sure I'm not the only one triggered by seeing these runes (`⊥`) .

cbf (Thu, 24 Oct 2019 15:40:05 GMT):
some interesting insight here https://medium.com/open-source-communities/maintainer-vs-community-97edc28387ad

cbf (Thu, 24 Oct 2019 15:41:15 GMT):
agreed we could nuke this

dave.enyeart (Thu, 24 Oct 2019 16:09:35 GMT):
@here As most of you know, we have been looking into configuration improvements for peer and orderer. Matt, Gari, and I further discussed the various configuration fallout, and our opinion is that it may be too disruptive to a v2.0 release after all. We're thinking that it would be better to simply proceed with the v2.0 release without the config updates, so that we can get back to a release cadence and start moving forward with some of the other important post-v2.0 features. We would still like to deliver a code-complete v2.0 beta before the holidays, since a lot has changed in v2.0, and a lot has changed since the alpha. And then allow for a small period of feedback before cutting final v2.0 release in the new year. We'll socialize further in the contributor meeting next Wednesday, but I suggest we start closing down the v2.0 release. This also implies that the validation updates would get deferred to v2.1 - we could use Manish's help finalizing the state db cache, and could use Wenjian's help with upgrade test and documentation.

soumyanayak (Thu, 24 Oct 2019 16:20:34 GMT):
Has joined the channel.

cbf (Thu, 24 Oct 2019 16:24:25 GMT):
please also socialize via mailing list

medikent (Thu, 24 Oct 2019 20:18:12 GMT):
Are there meeting notes or recordings I can use to come up to speed on the configuration changes so I can understand why there might be fallout?

lehors (Fri, 25 Oct 2019 06:50:40 GMT):
@medikent see https://jira.hyperledger.org/browse/FAB-16753

dave.enyeart (Fri, 25 Oct 2019 13:14:01 GMT):
And at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings you'll see that the config updates were a topic of discussion at the October 2nd meeting and you could listen to that recording (posted on the same page). But I'll tell you, that the discussion didn't really deviate from the posted design.

dave.enyeart (Fri, 25 Oct 2019 13:14:01 GMT):
@medikent And at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings you'll see that the config updates were a topic of discussion at the October 2nd meeting and you could listen to that recording (posted on the same page). But I'll tell you, that the discussion didn't really deviate from the posted design.

CT123 (Fri, 25 Oct 2019 13:14:17 GMT):
Has joined the channel.

dave.enyeart (Fri, 25 Oct 2019 14:41:56 GMT):
@C0rWin Anything of interest to report from Hyperledger Bootcamp in Moscow? I heard in prior bootcamps they had trouble getting Fabric up.

dave.enyeart (Fri, 25 Oct 2019 14:43:10 GMT):
Build Your First Network tutorial/sample updates will be a topic for next Wednesday's contributor meeting... so we'd encourage anybody with feedback to attend.

rjones (Fri, 25 Oct 2019 15:24:21 GMT):
@Silona ^^^

Silona (Fri, 25 Oct 2019 15:24:21 GMT):
Has joined the channel.

dave.enyeart (Fri, 25 Oct 2019 17:29:37 GMT):
@Silona I think you mentioned some general feedback for Fabric maintainers as well... you could mention here or attend the next contributors meeting.

BrettLogan (Mon, 28 Oct 2019 00:44:39 GMT):
We are aware of issues related to binary download requests and docker pulls from Nexus3 failing due to HTTPS handshakes, unfortunately we are unlikely to be able to do anything about it tonight (US EST timezone), but will pick up the work in the morning once sysadmins with LFIT get in. Requests for artifacts are being served around `26 B/s` for the last 48 hours

BrettLogan (Mon, 28 Oct 2019 00:44:39 GMT):
We are aware of issues related to docker pulls to Nexus3 failing due to HTTPS handshakes, unfortunately we are unlikely to be able to do anything about it tonight (US EST timezone), but will pick up the work in the morning once sysadmins with LFIT get in. Requests for artifacts are being served around `26 B/s` for the last 48 hours

BrettLogan (Mon, 28 Oct 2019 00:44:39 GMT):
We are aware of issues related to binary requests and docker pulls to Nexus3 failing due to HTTPS handshakes, unfortunately we are unlikely to be able to do anything about it tonight (US EST timezone), but will pick up the work in the morning once sysadmins with LFIT get in. Requests for artifacts are being served around `26 B/s` for the last 48 hours

BrettLogan (Mon, 28 Oct 2019 00:44:39 GMT):
We are aware of issues related to binary download requests and docker pulls to Nexus3 failing due to HTTPS handshakes, unfortunately we are unlikely to be able to do anything about it tonight (US EST timezone), but will pick up the work in the morning once sysadmins with LFIT get in. Requests for artifacts are being served around `26 B/s` for the last 48 hours

HLFPOC (Wed, 30 Oct 2019 04:53:24 GMT):
Has joined the channel.

dave.enyeart (Wed, 30 Oct 2019 12:04:19 GMT):
@here maintainer meeting starts in one hour - https://zoom.us/my/hyperledger.community.3 Agenda topics: Release update v1.4.4 targeted for November - bug fixes - Also shifts fabric docker images from ubuntu to debian:buster-20190910-slim - smaller images, more secure - note - v2.0 shifts to alpine images - even smaller, even more secure v2.0.0-beta targeted for December, remaining items that we are trying to close down: - external chaincode documentation - external chaincode as a server - state database cache for improved performance - upgrade documentation - node sdk v2.0 refactoring - in master split fabric-client into fabric-base (for transactions) and fabric-admin (for v2.0 lifecycle support) - please go through Jira backlogs and help to highlight anything that needs to get in before v2.0 SCM and CI update - Chaincode and SDK projects shifted from Gerrit to Github, and from Jenkins to Azure Pipelines (node sdk still in progress this week) - Change default branch to master in all repositories - We will attempt our first release from Azure Pipelines using fabric-baseimage (0.4.17 bumps go to 1.12.12) - Contribution documentation will shift focus entirely from Gerrit to Github - Checking on number of Azure Pipeline nodes for fabric - Once above items complete, shift core fabric repository to github Today's deep-dive: - Next generation enhancements for Build Your First Network tutorial and sample Anything else?

awjh (Fri, 01 Nov 2019 13:52:48 GMT):
Hi, has the Request for Comments process been implemented? Or is this still being agreed on?

awjh (Fri, 01 Nov 2019 13:52:48 GMT):
Hi, has the Request for Comments process been implemented? Or is this still being agred on?

jyellick (Fri, 01 Nov 2019 14:27:39 GMT):
https://github.com/christo4ferris/fabric-rfcs-proposal/issues <- There's still a number of outstanding items, though I think there was general support for implementing it, but it seems a bit stalled

awjh (Fri, 01 Nov 2019 14:28:24 GMT):
Okay, I am loooking to propose Go in the new contract programming model like exists for Java and Node. How is it best for me to go about this?

jyellick (Fri, 01 Nov 2019 15:15:38 GMT):
Good question -- maintainers, can we make an effort to settle this RFC proposal?

dave.enyeart (Fri, 01 Nov 2019 15:57:06 GMT):
There are three proposed changes at https://github.com/christo4ferris/fabric-rfcs-proposal/pulls . @cbf can you review these changes and help to drive the RFC proposal to completion?

cbf (Fri, 01 Nov 2019 16:01:38 GMT):
will do

cbf (Fri, 01 Nov 2019 16:17:59 GMT):
@kostas can you please amend PR #5 https://github.com/christo4ferris/fabric-rfcs-proposal/pull/5 to reduce the criteria from *all* to majority

kostas (Sat, 02 Nov 2019 21:46:07 GMT):
Done.

dave.enyeart (Mon, 04 Nov 2019 20:38:59 GMT):
fabric v1.4.4 update - we plan to get last commits in this week, do some additional system testing, and then release v1.4.4 next week - we're bumping go to v1.12.12 - important fix for v1.4.4 was confirmed last week - *[FAB-16643] peer panic during a private data reconciliation scenario* - final v1.4.4 fixes for this week include: - *[FAB-15389] Endorsing peer is not honoring maxPeerCount for private data dissemination* - @danny working it) - *[FAB-16544] Need a way for new peers to know if orderer locations have changed* - @Jason working it) - *[FAB-16699] Gossip membership has conflict between pki-ids at the same address* - @yacov do you intend to CR? - *[FAB-16951] Alternative mechanisms to find pkcs11 key* - @gari did you intend for this one to go into v1.4.4? - I'll review Node OU issues FAB-16936 and FAB-16796 - Any other mustfix in v1.4.4?

dave.enyeart (Mon, 04 Nov 2019 20:38:59 GMT):
fabric v1.4.4 update - we plan to get last commits in this week, do some additional system testing, and then release v1.4.4 next week - we're bumping go to v1.12.12 - important fix for v1.4.4 was confirmed last week - *[FAB-16643] peer panic during a private data reconciliation scenario* - final v1.4.4 fixes for this week include: - *[FAB-15389] Endorsing peer is not honoring maxPeerCount for private data dissemination* - @caod working it) - *[FAB-16544] Need a way for new peers to know if orderer locations have changed* - @jyellick working it) - *[FAB-16699] Gossip membership has conflict between pki-ids at the same address* - @yacovm do you intend to CR? - *[FAB-16951] Alternative mechanisms to find pkcs11 key* - @mastersingh24 did you intend for this one to go into v1.4.4? - I'll review Node OU issues FAB-16936 and FAB-16796 - Any other mustfix in v1.4.4?

dave.enyeart (Mon, 04 Nov 2019 20:38:59 GMT):
fabric v1.4.4 update - we plan to get last commits in this week, do some additional system testing, and then release v1.4.4 next week - we're bumping go to v1.12.12 - important fix for v1.4.4 was confirmed last week - *[FAB-16643] peer panic during a private data reconciliation scenario* final v1.4.4 fixes for this week include: - *[FAB-15389] Endorsing peer is not honoring maxPeerCount for private data dissemination* - @caod working it) - *[FAB-16544] Need a way for new peers to know if orderer locations have changed* - @jyellick working it) - *[FAB-16699] Gossip membership has conflict between pki-ids at the same address* - @yacovm do you intend to CR? - *[FAB-16951] Alternative mechanisms to find pkcs11 key* - @mastersingh24 did you intend for this one to go into v1.4.4? - I'll review Node OU issues FAB-16936 and FAB-16796 - Any other mustfix in v1.4.4?

yacovm (Mon, 04 Nov 2019 20:42:31 GMT):
> [FAB-16699] Gossip membership has conflict between pki-ids at the same address yacovm do you intend to CR? Read a few comments above... I claim that I solved it in FAB-16651

yacovm (Mon, 04 Nov 2019 20:42:50 GMT):
I think his issue is the same problem, @dave.enyeart

yacovm (Mon, 04 Nov 2019 20:43:28 GMT):
as for FAB-16951 I saw a CR here: https://gerrit.hyperledger.org/r/#/c/fabric/+/34221/

robmurgai (Mon, 04 Nov 2019 21:11:51 GMT):
Has joined the channel.

dave.enyeart (Mon, 04 Nov 2019 21:30:50 GMT):
Thanks @yacovm , so do you want to go ahead and close FAB-16699 ?

yacovm (Mon, 04 Nov 2019 21:31:11 GMT):
No, I want him to confirm it indeed solved his problem

dave.enyeart (Mon, 04 Nov 2019 21:31:42 GMT):
ok, I push the 'More Info Required' button

dave.enyeart (Mon, 04 Nov 2019 21:31:42 GMT):
ok, I pushed the 'More Info Required' button to put it in 'Returned' state

cbf (Tue, 05 Nov 2019 14:10:27 GMT):
ok, Kostas updated the last PR on the RFCs proposal... are we ready to approve?

cbf (Tue, 05 Nov 2019 14:11:02 GMT):
@dave.enyeart @sykesm @mastersingh24

cbf (Tue, 05 Nov 2019 14:15:05 GMT):
@yacovm @jyellick @kostas @muralisr @guoger @aso @binhn @C0rWin @JonathanLevi @manish-sethi @pandrejko

cbf (Tue, 05 Nov 2019 14:15:23 GMT):
https://github.com/christo4ferris/fabric-rfcs-proposal/pull/5

cbf (Tue, 05 Nov 2019 14:15:41 GMT):
Please cast vote with a +1 here and I'll submit the CR

cbf (Tue, 05 Nov 2019 14:16:11 GMT):
check that, submit the request to @ry to create the repo

muralisr (Tue, 05 Nov 2019 14:16:45 GMT):
@cbf

muralisr (Tue, 05 Nov 2019 14:16:45 GMT):
@cbf +1

dave.enyeart (Tue, 05 Nov 2019 14:28:57 GMT):
+1

manish-sethi (Tue, 05 Nov 2019 14:37:49 GMT):
+1

guoger (Tue, 05 Nov 2019 14:57:17 GMT):
+1

jyellick (Tue, 05 Nov 2019 14:57:42 GMT):
+1

rjones (Tue, 05 Nov 2019 21:28:37 GMT):
@cbf LMK when you're ready

C0rWin (Wed, 06 Nov 2019 16:37:59 GMT):
+1

kostas (Wed, 06 Nov 2019 20:19:40 GMT):
+1

pandrejko (Fri, 08 Nov 2019 17:12:32 GMT):
+1

cbf (Mon, 11 Nov 2019 15:24:56 GMT):
@rjones LMK how you want to do this... one way could be for me to transfer ownership of the repo to you so you can transfer it into hyperledger

dave.enyeart (Mon, 11 Nov 2019 20:22:37 GMT):
@here As you all know we are shifting from Jenkins to Azure Pipelines for our CI and release processes. For us to have found a partner who will provide us a managed solution totally free of cost to our open source project was more than we could have hoped for. Microsoft provides us with free infrastructure for running CI on Linux, MacOS and Windows. One trade off (frankly, for any of the CI solutions we were looking at), is that there is no support for s390x that would enable us to build s390x binaries and docker images. With our first release from Azure Pipelines coming up (first for fabric-ca, and core fabric coming next), we are proposing that starting with v1.4.4 we will no longer publish s390x binaries or docker images as open source release artifacts. This change was expected for v2.0, but with Jenkins going away it looks like we will have to discontinue the s390x artifacts in v1.4.x as well. We have discussed with known s390x consumers, and they have confirmed that they build their own binaries and docker images regardless, and can continue to do so. We intend to socialize on the Fabric mailing list, but wanted to first check with the maintainers in case anybody wanted to raise a concern and suggest an alternative.

rjones (Mon, 11 Nov 2019 23:23:13 GMT):
@cbf please transfer the repo to me and I’ll move it under Hyperledger today.

cbf (Mon, 11 Nov 2019 23:23:38 GMT):
cool, just so I don't screw up, your GH ID?

rjones (Mon, 11 Nov 2019 23:23:53 GMT):
I’m in Singapore so apologies for my delayed response

cbf (Mon, 11 Nov 2019 23:23:59 GMT):
no worries

rjones (Mon, 11 Nov 2019 23:24:36 GMT):
‘ryjones’

rjones (Mon, 11 Nov 2019 23:25:10 GMT):
https://github.com/ryjones

cbf (Mon, 11 Nov 2019 23:26:24 GMT):
ball is in your court

rjones (Tue, 12 Nov 2019 00:29:46 GMT):
https://github.com/hyperledger/fabric-rfcs/ @cbf

rjones (Tue, 12 Nov 2019 00:31:51 GMT):
In case this generally helps people with the PR process: https://gist.github.com/ryjones/c7616d42bc6ea65d9fb2a831eb26dd1f

guoger (Tue, 12 Nov 2019 01:52:50 GMT):
is there a writeup that explains current process of building protos and use them in fabric? i fear i'm doing some weird hacks to get pieces work together (proto, proto-go, chaincode-go, fabric)

guoger (Tue, 12 Nov 2019 07:05:00 GMT):
also, i suppose we will need to remove `protos` target from Fabric makefile?

rjones (Tue, 12 Nov 2019 07:06:28 GMT):
I know some are published here: https://github.com/hyperledger/fabric-protos-go/

guoger (Tue, 12 Nov 2019 07:09:10 GMT):
Thx for reply. it seems update on fabric-protos will be automatically made available in fabric-protos-go via azp. Although, what's the process of updating *local* repo during dev?

rjones (Tue, 12 Nov 2019 07:09:28 GMT):
that I do not know :)

guoger (Tue, 12 Nov 2019 07:10:35 GMT):
i believe there should be a script somewhere... :thinking:

caod (Tue, 12 Nov 2019 16:01:33 GMT):
if you want to generate the protobuf locally for testing/development you can always use protoc to generate it and then move it to the vendored folder: `protoc --go_out=. && mv github.com/fabric-protos-go/ $GOPATH/src/github.com/hyperledger/fabric/vendor/github.com/hyperledger/fabric-protos-go/`

caod (Tue, 12 Nov 2019 16:01:33 GMT):
if you want to generate the protobuf locally for testing/development you can always use protoc to generate it and then move it to the vendored folder: `protoc --go_out=. && mv github.com/hyperledger/fabric-protos-go/ $GOPATH/src/github.com/hyperledger/fabric/vendor/github.com/hyperledger/fabric-protos-go/`

caod (Tue, 12 Nov 2019 16:01:33 GMT):
if you want to generate the protobuf locally for testing/development you can always use protoc to generate it to the vendored folder: `protoc --go_out=$GOPATH/src/github.com/hyperledger/fabric/vendor `

caod (Tue, 12 Nov 2019 16:01:33 GMT):
if you want to generate the protobuf locally for testing/development you can always use protoc (`go get -u github.com/golang/protobuf/protoc-gen-go`) to generate it to the vendored folder: `protoc --go_out=$GOPATH/src/github.com/hyperledger/fabric/vendor `

caod (Tue, 12 Nov 2019 16:03:16 GMT):
alternatively you could set the `--go_out` to point to the vendor folder in fabric repo

caod (Tue, 12 Nov 2019 16:04:09 GMT):
`protoc --go_out=$GOPATH/src/github.com/hyperledger/fabric/vendor `

caod (Tue, 12 Nov 2019 16:08:56 GMT):
could probably write your own simple script with that

caod (Tue, 12 Nov 2019 16:08:56 GMT):
could probably write your own simple script with that to shorten it

dave.enyeart (Tue, 12 Nov 2019 17:47:24 GMT):
Looks like we're good to go on the fabric-rfcs. Thanks @cbf !

dave.enyeart (Tue, 12 Nov 2019 17:47:33 GMT):
Who wants to be the first to suffer through the process?

dave.enyeart (Tue, 12 Nov 2019 17:47:43 GMT):
https://github.com/hyperledger/fabric-rfcs/

guoger (Wed, 13 Nov 2019 01:33:52 GMT):
thx for reply. yes that's what i did, although was thinking if there's something available already. we used to do `make protos` (which i believe should be removed?) it's a bit painful to work with multiple repos (fabric, chaincode-go, proto-go), especially when two of them are using modules and i have to modify go.mod with `replace` directive to point to my local copy... so i'm wondering if there's a better way to do this

dave.enyeart (Wed, 13 Nov 2019 13:00:03 GMT):
@here Agenda for contributor meeting next hour... anything else to add? v1.4.4 - We are preparing for release this week. - Remaining CR that needs to get reviewed (raft orderering): https://gerrit.hyperledger.org/r/#/c/fabric/+/34324/ - Draft release notes (now uses markdown syntax): https://gerrit.hyperledger.org/r/#/c/fabric/+/34364/ v2.0.0-beta targeted for December, remaining items that we are trying to close down: - external chaincode documentation - external chaincode as a server - state database cache for improved performance - upgrade documentation - node sdk v2.0 refactoring - in master split fabric-client into fabric-base (for transactions) and fabric-admin (for v2.0 lifecycle support) SCM and CI update - We will attempt our first release from Azure Pipelines using fabric-ca v1.4.4 - All Gerrit references being removed from contribution guide documentation - Azure increased our number of CI nodes to 50 - We should be able to shift fabric repository from Gerrit to Github after the v1.4.4 release... let's make a final push to get Gerrit CRs merged or abandoned so that contributors won't be impacted. Today's deep-dive: - High level contract api for Go chaincode - Andy Hurt

dave.enyeart (Wed, 13 Nov 2019 13:00:03 GMT):
@here Agenda for contributor meeting next hour... anything else to add? v1.4.4 - We are preparing for release this week. - Remaining CR that needs to get reviewed (raft orderering): https://gerrit.hyperledger.org/r/#/c/fabric/+/34324/ - Draft release notes (now uses markdown syntax): https://gerrit.hyperledger.org/r/#/c/fabric/+/34364/ v2.0.0-beta targeted for December, remaining items that we are trying to close down: - external chaincode documentation - external chaincode as a server - state database cache for improved performance - upgrade documentation - node sdk v2.0 refactoring - in master split fabric-client into fabric-base (for transactions) and fabric-admin (for v2.0 lifecycle support) fabric-rfcs repository is live - we will post to mailing list as well: https://github.com/hyperledger/fabric-rfcs/ SCM and CI update - We will attempt our first release from Azure Pipelines using fabric-ca v1.4.4 - All Gerrit references being removed from contribution guide documentation - Azure increased our number of CI nodes to 50 - We should be able to shift fabric repository from Gerrit to Github after the v1.4.4 release... let's make a final push to get Gerrit CRs merged or abandoned so that contributors won't be impacted. Today's deep-dive: - High level contract api for Go chaincode - Andy Hurt

dave.enyeart (Wed, 13 Nov 2019 13:00:03 GMT):
@here Agenda for contributor meeting next hour... anything else to add? v1.4.4 - We are preparing for release this week. - Remaining CR that needs to get reviewed (raft orderering): https://gerrit.hyperledger.org/r/#/c/fabric/+/34324/ - Draft release notes (now uses markdown syntax): https://gerrit.hyperledger.org/r/#/c/fabric/+/34364/ v2.0.0-beta targeted for December, remaining items that we are trying to close down: - external chaincode documentation - external chaincode as a server - state database cache for improved performance - upgrade documentation - node sdk v2.0 refactoring - in master split fabric-client into fabric-base (for transactions) and fabric-admin (for v2.0 lifecycle support) fabric-rfcs repository is live - we will post to mailing list as well: https://github.com/hyperledger/fabric-rfcs/ SCM and CI update - We will attempt our first release from Azure Pipelines using fabric-ca v1.4.4 - Changed fabric-ca default branch to master and confirmed pull request template is now active. Will make same change on other repositories (I don't have permissions on 'fabric'... we need to review permissions all around). - All Gerrit references being removed from contribution guide documentation - Azure increased our number of CI nodes to 50 - We should be able to shift fabric repository from Gerrit to Github after the v1.4.4 release... let's make a final push to get Gerrit CRs merged or abandoned so that contributors won't be impacted. Today's deep-dive: - High level contract api for Go chaincode - Andy Hurt

dave.enyeart (Wed, 13 Nov 2019 14:01:12 GMT):
@here Is anybody able to start the zoom meeting? I cannot...

dave.enyeart (Wed, 13 Nov 2019 14:01:32 GMT):
It says a host must start the meeting, this is new...

dave.enyeart (Wed, 13 Nov 2019 14:01:47 GMT):
https://zoom.us/my/hyperledger.community.3

jyellick (Wed, 13 Nov 2019 14:02:24 GMT):
Same error here

knagware9 (Wed, 13 Nov 2019 14:03:25 GMT):
Same error here

C0rWin (Wed, 13 Nov 2019 14:03:35 GMT):
It say to wait for host to start a meeting

dave.enyeart (Wed, 13 Nov 2019 14:04:36 GMT):
ok, let's use my webex instead this week: https://ibm.webex.com/join/enyeart

dave.enyeart (Wed, 13 Nov 2019 16:01:52 GMT):
@Silona @rjones I wasn't authorized to start zoom https://zoom.us/my/hyperledger.community.3 today... does it really require host privilege to start now? how do i get such priv?

Silona (Wed, 13 Nov 2019 17:02:57 GMT):
@dave.enyeart I sent you the code in the DM but it shouldn't REQUIRE it to open the room only to record.

Silona (Wed, 13 Nov 2019 17:03:18 GMT):
I'll look into it this afternoon - solid meetings ATM

awjh (Thu, 14 Nov 2019 13:22:49 GMT):
Hi, I am looking to get a repo for the contract api for go work. Preferably `fabric-contract-api-go`. @heatherp and myself would be maintainers. Do people approve of this repo being created for this purpose?

sstone1 (Thu, 14 Nov 2019 13:28:26 GMT):
^ requested by Matt as per PR comment here: https://github.com/hyperledger/fabric-chaincode-go/pull/13#pullrequestreview-316407848

cbf (Thu, 14 Nov 2019 15:47:14 GMT):
please use the newly approved fabric-rfcs process https://github.com/hyperledger/fabric-rfcs/

cbf (Thu, 14 Nov 2019 15:47:14 GMT):
@awjh please use the https://github.com/hyperledger/fabric-rfcs/ process thanks

cbf (Thu, 14 Nov 2019 15:47:14 GMT):
@awjh

cbf (Thu, 14 Nov 2019 15:47:14 GMT):
@awjh ^^

dave.enyeart (Thu, 14 Nov 2019 16:10:17 GMT):
Since Andrew @awjh reviewed go programming model on contributor call before the fabric-rfcs process was announced, and since it doesn't deviate in design from the existing node and java chaincode implementations, we told Andrew he could be grandfathered in. But yeah, given the suggestion to create a new repository, makes sense to do an 'abridged' fabric-rfc that points to the reviewed material, if nothing else to make sure the new process is smooth and set a precedent.

dave.enyeart (Thu, 14 Nov 2019 16:11:38 GMT):
We are proceeding with fabric and fabric-ca v1.4.4 releases today. One final CR for fabric: https://gerrit.hyperledger.org/r/#/c/fabric/+/34359/

dave.enyeart (Thu, 14 Nov 2019 16:12:01 GMT):
fabric release notes: https://gerrit.hyperledger.org/r/#/c/fabric/+/34364/

dave.enyeart (Thu, 14 Nov 2019 16:12:01 GMT):
fabric release notes: https://gerrit.hyperledger.org/r/#/c/fabric/+/34364/ (I'll update it for the above CR)

dave.enyeart (Thu, 14 Nov 2019 16:12:09 GMT):
fabric-ca release notes: https://github.com/hyperledger/fabric-ca/pull/66

cbf (Thu, 14 Nov 2019 16:18:58 GMT):
@dave.enyeart yeah, could be an abbreviated request that we merely document for this one. Would be good though to get used to this and to have a single model for @ryjones etc to follow for creating new repos

dave.enyeart (Thu, 14 Nov 2019 17:40:29 GMT):
I've changed default branch to be `master` for all fabric repositories except for the chaincode and sdk repositories. @heatherp @mbwhite @andrew-coleman you can update those, and use the same pull request template if you like: https://github.com/hyperledger/fabric-ca/blob/master/.github/PULL_REQUEST_TEMPLATE.md

heatherp (Thu, 14 Nov 2019 17:42:18 GMT):
thanks Dave :) what permissions do you need on a repo to be able to do this?

dave.enyeart (Thu, 14 Nov 2019 17:46:29 GMT):
@rjones Added me to a fabric-admins group, so I could do it for all the repositories if you like. Although I would like to understand from Ry the overall group permissions scheme... @rjones would you recommend to have a SDK/chaincode admin in fabric-admins, or use separate groups per sdk/chaincode language?

dave.enyeart (Thu, 14 Nov 2019 18:02:14 GMT):
After talking to Heather I've gone ahead and changed all chaincode/sdk repositories to have master as default branch as well.

rjones (Thu, 14 Nov 2019 18:27:41 GMT):
A thread on the state of `GitHub` persimmions as it relates to Fabric codebases and the like and etc etc

rjones (Thu, 14 Nov 2019 18:28:07 GMT):
This is the parent team of all of the maintainer teams for Fabric repos on GitHub: https://github.com/orgs/hyperledger/teams/fabric-maintainers/teams

rjones (Thu, 14 Nov 2019 18:28:53 GMT):
This is a work in progress, and there are certainly oversights and the like as @BrettLogan and I are creating groups ad hoc

rjones (Thu, 14 Nov 2019 18:29:25 GMT):
This has lead to changes like this: https://gerrit.hyperledger.org/r/#/c/fabric-sdk-py/+/34362/

rjones (Thu, 14 Nov 2019 18:30:33 GMT):
and bugs like this: https://jira.hyperledger.org/browse/FAB-16374

rjones (Thu, 14 Nov 2019 18:31:05 GMT):
as we try to implement the MAINTAINERS.[rst|md] we find stuff like this

rjones (Thu, 14 Nov 2019 18:31:56 GMT):
Also note: https://github.com/orgs/hyperledger/teams/fabric-maintainers/repositories

dave.enyeart (Thu, 14 Nov 2019 22:41:59 GMT):
Release v1.4.4 update - Fabric-CA was completely released using Azure Pipelines, including generating the binaries, publishing to DockerHub, tagging, and created the GitHub release for us. You can check it out here https://github.com/hyperledger/fabric-ca/releases/tag/v1.4.4.

dave.enyeart (Thu, 14 Nov 2019 22:43:29 GMT):
Thanks to @BrettLogan for all his hard work switching us to Azure Pipelines... it is already paying off big time!

dave.enyeart (Thu, 14 Nov 2019 22:44:18 GMT):
Given that the fabric-ca binaries are published to Github rather than Nexus, we are going to do the same thing for the fabric binaries, and then update the bootstrap.sh script to pull from Github rather than Nexus.

dave.enyeart (Thu, 14 Nov 2019 22:44:48 GMT):
We'll try to finish that out tomorrow

dave.enyeart (Thu, 14 Nov 2019 22:44:48 GMT):
We'll try to finish that out tomorrow and then announce on the mailing list

mbwhite (Fri, 15 Nov 2019 08:59:59 GMT):
Thanks Dave; The codeowners have the power to adjust the description and tags, and what 'merge policies' are possible only. We can't update any branch protections etc.

sanket1211 (Fri, 15 Nov 2019 09:12:00 GMT):
Has joined the channel.

awjh (Fri, 15 Nov 2019 10:45:27 GMT):
@dave.enyeart @cbf Requested RFC for Go contract API -> https://github.com/hyperledger/fabric-rfcs/pull/13

dave.enyeart (Fri, 15 Nov 2019 15:39:16 GMT):
fabric v1.4.4 released and tagged - https://github.com/hyperledger/fabric/releases/tag/v1.4.4

dave.enyeart (Fri, 15 Nov 2019 15:40:38 GMT):
bootstrap.sh download script is being switched to pull binaries from Github instead of Nexus

dave.enyeart (Fri, 15 Nov 2019 15:40:44 GMT):
https://gerrit.hyperledger.org/r/#/c/fabric/+/34400/

dave.enyeart (Fri, 15 Nov 2019 15:40:56 GMT):
We'll post the prior releases to Github as well

dave.enyeart (Fri, 15 Nov 2019 15:40:56 GMT):
We'll post the prior release binaries to Github as well

dave.enyeart (Fri, 15 Nov 2019 15:41:23 GMT):
@cbf could you review

knagware9 (Fri, 15 Nov 2019 15:47:09 GMT):
@dave.enyeart fabric- samples also released? Its not getting donwloaded & also cant see 1.4.4 tag

dave.enyeart (Fri, 15 Nov 2019 15:47:22 GMT):
We'll tag fabric-samples next

rjones (Fri, 15 Nov 2019 18:02:52 GMT):
https://github.com/hyperledger/fabric-contract-api-go

dave.enyeart (Fri, 15 Nov 2019 19:32:21 GMT):
All done with Fabric and Fabric-CA v1.4.4 releases. Images published to dockerhub, binaries published to Github, bootstrap.sh download script updated to pull binaries from Github.

dave.enyeart (Fri, 15 Nov 2019 19:32:28 GMT):
All looks good.

dave.enyeart (Fri, 15 Nov 2019 19:33:03 GMT):
Thanks to @BrettLogan for making our first release using Azure Pipelines and Github releases a success!

dave.enyeart (Fri, 15 Nov 2019 19:35:03 GMT):
Next week we intend to switch fabric repo from Gerrit to Github for source control. Let's get as many Gerrit CRs merged or abandoned as possible.

dave.enyeart (Fri, 15 Nov 2019 19:35:03 GMT):
Next week we intend to switch 'fabric' core repo from Gerrit to Github for source control. Let's get as many Gerrit CRs merged or abandoned as possible.

rjones (Fri, 15 Nov 2019 19:35:51 GMT):
All of the remaining repos?

dave.enyeart (Fri, 15 Nov 2019 19:36:42 GMT):
'fabric' core next week. there's not many left after that.

rjones (Fri, 15 Nov 2019 20:34:21 GMT):
OK.

rjones (Fri, 15 Nov 2019 21:16:09 GMT):
@dave.enyeart https://jira.hyperledger.org/browse/FAB-16662 is where I'm keeping track :)

jtonline (Mon, 18 Nov 2019 11:40:52 GMT):
Would anyone be able to merge a couple of small fabric doc updates please? They should fix some broken links https://gerrit.hyperledger.org/r/c/fabric/+/34418 https://gerrit.hyperledger.org/r/c/fabric/+/34405 /cc @pandrejko

knagware9 (Mon, 18 Nov 2019 18:27:35 GMT):
still getting this message===> Checking out v1.4.4 of hyperledger/fabric-samples error: pathspec 'v1.4.4' did not match any file(s) known to git.

dave.enyeart (Mon, 18 Nov 2019 18:31:41 GMT):
it is tagged here: https://github.com/hyperledger/fabric-samples/tree/v1.4.4

dave.enyeart (Mon, 18 Nov 2019 18:31:52 GMT):
maybe try a new local directory?

dave.enyeart (Mon, 18 Nov 2019 18:31:52 GMT):
maybe try a new local directory for a fresh clone?

knagware9 (Mon, 18 Nov 2019 18:33:39 GMT):
Thanks , I could see the 1.4.4 tag but while using curl to download 1.4.4 then fabric-samples not downloading

knagware9 (Mon, 18 Nov 2019 18:35:58 GMT):
it works when I used new directory any reason why its not working for same directory which is "hyperledger"

dave.enyeart (Mon, 18 Nov 2019 18:37:24 GMT):
The original clone should work as well if you fetch latest changes (which would include the tag)

knagware9 (Mon, 18 Nov 2019 18:54:52 GMT):
okay Thanks

MHBauer (Tue, 19 Nov 2019 20:26:22 GMT):
How do I run a test network of fabric@master? I'm used to going to fabric-samples repo, but that seems hardcoded to deployed images and the last fabric 2.0 is from april.

yacovm (Tue, 19 Nov 2019 20:43:08 GMT):
the docker compose file has the references to the docker images, you can just build your own docker images and change the reference

dave.enyeart (Tue, 19 Nov 2019 21:22:12 GMT):
i assume yacov means `make docker-clean docker` in fabric.

dave.enyeart (Tue, 19 Nov 2019 21:23:14 GMT):
I do that fairly often, but even more often I just make the binaries and test with them.

dave.enyeart (Tue, 19 Nov 2019 21:23:14 GMT):
I do that fairly often and then test with byfn and whatever extensions I'm currently trying out, but even more often I just make the binaries and test with them.

dave.enyeart (Tue, 19 Nov 2019 21:25:04 GMT):
Not too difficult using a solo orderer and single peer with the /sampleconfig artifacts and SampleOrg... gets a lot more painful to bring up multiple orderers and peers.

MHBauer (Tue, 19 Nov 2019 21:26:36 GMT):
okay, how do I do that?

dave.enyeart (Tue, 19 Nov 2019 21:26:44 GMT):
I've been thinking of writing up this approach, as I've helped had to help several people through it

dave.enyeart (Tue, 19 Nov 2019 21:26:44 GMT):
I've been thinking of writing up this approach, as I've had to help several people through it

MHBauer (Tue, 19 Nov 2019 21:26:54 GMT):
for the samples I'm having to move around all the binaries, and I'm still not there yet.

MHBauer (Tue, 19 Nov 2019 21:27:42 GMT):
Happy to write it up.

MHBauer (Tue, 19 Nov 2019 21:27:58 GMT):
Should start a blog anyawy

MHBauer (Tue, 19 Nov 2019 21:29:03 GMT):
But I've never heard of the sampleOrg setup yet.

dave.enyeart (Tue, 19 Nov 2019 21:29:40 GMT):
@MHBauer I can dump my notes to bootstrap it... where would you like to collaborate?

MHBauer (Tue, 19 Nov 2019 21:30:06 GMT):
anywhere, everybody uses something different.

MHBauer (Tue, 19 Nov 2019 21:30:08 GMT):
wiki?

MHBauer (Tue, 19 Nov 2019 21:30:26 GMT):
is there a hyperledger docs or ethernote?

dave.enyeart (Tue, 19 Nov 2019 21:35:10 GMT):
how about https://wiki.hyperledger.org/display/fabric/Testing+with+Fabric+binaries

dave.enyeart (Tue, 19 Nov 2019 21:35:12 GMT):
for starters

dave.enyeart (Tue, 19 Nov 2019 21:35:20 GMT):
I'll dump some stuff there tonight

dave.enyeart (Tue, 19 Nov 2019 21:35:31 GMT):
if we like it we could submit to github

MHBauer (Tue, 19 Nov 2019 21:42:53 GMT):
I'll take a look, thanks.

dave.enyeart (Wed, 20 Nov 2019 15:39:38 GMT):
@here Just discussed with @BrettLogan and @jyellick , looks like we are on track to switch over `fabric` and `fabric-baseimage` and `fabric-lib-go` repositories from Gerrit to Github on FRIDAY.

dave.enyeart (Wed, 20 Nov 2019 15:39:43 GMT):
We're getting the CI azure pipeline and doc CRs finalized currently.

dave.enyeart (Wed, 20 Nov 2019 15:39:52 GMT):
We'll get a message out to mailing list tomorrow with more details, including links to the updated contribution guide.

dave.enyeart (Wed, 20 Nov 2019 15:40:07 GMT):
MAINTAINERS - This is your last chance to review Gerrit CRs and get them merged. As of Friday we'll abandon all remaining CRs in Gerrit and ask contributors to re-submit to Github.

bestbeforetoday (Wed, 20 Nov 2019 16:46:58 GMT):
Will this change where the v2 Docker images are published to or do we continue to find them at nexus3.hyperledger.org?

dave.enyeart (Wed, 20 Nov 2019 16:58:48 GMT):
As far as I understand, it is fabric-test repo that does the publishing. That won't be shifting this week. When we do shift fabric-test, for the short term we'll continue publishing to nexus. Longer term, we are asking Hyperledger to make a decision on the repository of choice, and we'll likely shift the publishing from fabric-test to fabric and fabric-ca pipelines after successful interop job execution. We'll discuss interop test and pipeline proposals more in coming weeks, but did I capture all that correctly at a high level @BrettLogan ?

dave.enyeart (Wed, 20 Nov 2019 16:58:48 GMT):
As far as I understand, it is fabric-test repo that does the publishing. That won't be shifting this week. When we do shift fabric-test, for the short term we'll continue publishing to nexus. Longer term, we are asking Hyperledger to make a decision on the repository of choice, and we'll likely shift the publishing from fabric-test to fabric and fabric-ca pipelines after successful interop job execution. We'll discuss more in coming weeks, but did I capture all that correctly at a high level @BrettLogan ?

rjones (Wed, 20 Nov 2019 17:41:28 GMT):
Could someone take a look at https://jira.hyperledger.org/browse/FAB-17106 ? it's a security issue

yacovm (Wed, 20 Nov 2019 18:26:52 GMT):
i think that only 1-2 maintainers have access rights to see security issues

BrettLogan (Wed, 20 Nov 2019 18:56:00 GMT):
That link is invalid Ry

BrettLogan (Wed, 20 Nov 2019 18:56:44 GMT):

Clipboard - November 20, 2019 1:56 PM

BrettLogan (Wed, 20 Nov 2019 18:57:03 GMT):
It doesn't even appear to have ever existed, is it hidden as a security issue, or did someone actually delete it

BrettLogan (Wed, 20 Nov 2019 18:57:08 GMT):
@rjones

jyellick (Wed, 20 Nov 2019 18:58:08 GMT):
No permission to view that issue. @rjones if you add me to the watchers, I'd be happy to take a look

rjones (Wed, 20 Nov 2019 19:14:34 GMT):
@BrettLogan as I said... it is a security issue.

rjones (Wed, 20 Nov 2019 19:15:39 GMT):
@jyellick I assigned it to you, I can't seem to add you as a watcher. Can you see it now?

jyellick (Wed, 20 Nov 2019 19:16:09 GMT):
@rjones Yes, I can, will look now

rjones (Wed, 20 Nov 2019 19:16:27 GMT):
Thanks.

jyellick (Wed, 20 Nov 2019 19:32:33 GMT):
It's a bug, but not a security issue. I've added a comment and removed the label so any other interested parties can view.

BrettLogan (Wed, 20 Nov 2019 19:58:02 GMT):
Yea, I didn't realize security issues were hidden, that's what I was asking. Jason explained to me there is a tag for it and those are hidden

MHBauer (Thu, 21 Nov 2019 00:20:33 GMT):
so some of what I had an issue with was binaries being the wrong version, and my fabric-samples was out of date and on gerrit version still. I can start the networks. first-network is a bit big for me, but it starts. Now I'm stuck on the new lifecycle.

BrettLogan (Thu, 21 Nov 2019 05:46:05 GMT):
Effective immediately we would ask that all Change Requests for Fabric you would put into Gerrit instead be opened as Pull Requests using the fabric GitHub repository. We will be cutting Fabric over to GitHub on Friday morning EST. The maintainers need to get through the CR backlog today and as such any new CR that comes in will not be reviewed. Come Friday morning any CR

BrettLogan (Thu, 21 Nov 2019 05:46:05 GMT):
Effective immediately we would ask that all Change Requests for Fabric you would put into Gerrit instead be opened as Pull Requests using the fabric GitHub repository. We have configured CI to run against PR's opened in GitHub already. We will be cutting Fabric over to GitHub on Friday morning EST. The maintainers need to get through the CR backlog today and as such any new CR that comes in will not be reviewed. Come Friday morning any CR's still left in Gerrit will be abandoned, so if you can move your CR from Gerrit to GitHub today if you don't think it will get in before then please do so

jyellick (Thu, 21 Nov 2019 05:46:39 GMT):
Are you sending this to the mailing list as well?

BrettLogan (Thu, 21 Nov 2019 05:48:21 GMT):
Dave is going to send that in the morning, I just wanted to get something out there before I hung it up for the night so development teams in Europe could get a heads up before we get in in the morning

BrettLogan (Thu, 21 Nov 2019 05:49:18 GMT):
Actually, I'll just do it now, so we blanket coverage as much as possible

MHBauer (Thu, 21 Nov 2019 20:04:36 GMT):
yay

BrettLogan (Fri, 22 Nov 2019 04:02:35 GMT):
Huge thank you to the Fabric maintainers for getting the Gerrit CR's down to less than 20 open, especially Dave Enyeart and Jason Yellick who really lead us through the home stretch on getting CR's reviewed and merged over the last 48 hours.

BrettLogan (Fri, 22 Nov 2019 04:03:10 GMT):
Just a reminder, tomorrow morning EST we will be migrating to GitHub with Fabric

BrettLogan (Fri, 22 Nov 2019 04:03:10 GMT):
Just a reminder, sometime tomorrow morning EST we will be migrating to GitHub with Fabric

dave.enyeart (Fri, 22 Nov 2019 06:47:58 GMT):
Down to 10. Any remaining will be abandoned upon switching.

dave.enyeart (Fri, 22 Nov 2019 06:48:14 GMT):
Pull request template is ready for merge: https://gerrit.hyperledger.org/r/#/c/fabric/+/34448/

dave.enyeart (Fri, 22 Nov 2019 06:48:14 GMT):
Pull request template is ready for another +2 and merge: https://gerrit.hyperledger.org/r/#/c/fabric/+/34448/

rjones (Fri, 22 Nov 2019 10:46:36 GMT):
https://gerrit.hyperledger.org/r/#/q/project:fabric-test+status:open https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric

rjones (Fri, 22 Nov 2019 10:46:36 GMT):
```10: https://gerrit.hyperledger.org/r/#/q/project:fabric-test+status:open11: https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric```

rjones (Fri, 22 Nov 2019 10:46:36 GMT):
```10: https://gerrit.hyperledger.org/r/#/q/project:fabric-test+status:open 11: https://gerrit.hyperledger.org/r/#/q/status:open+project:fabric```

dave.enyeart (Fri, 22 Nov 2019 12:06:41 GMT):
`fabric` will be shifted today. `fabric-test` will not.

dave.enyeart (Fri, 22 Nov 2019 12:06:41 GMT):
@rjones `fabric` will be shifted today. `fabric-test` will not.

BrettLogan (Fri, 22 Nov 2019 15:31:18 GMT):
We are in the process of Migrating Fabric to GitHub. We will let everyone know when we are done. Maintainers please do not merge any changes in Gerrit or GitHub until we give the all clear

rjones (Fri, 22 Nov 2019 15:46:06 GMT):
Here are people with a commit bit to `fabric`: https://github.com/orgs/hyperledger/teams/fabric-maintainers/members

rjones (Fri, 22 Nov 2019 15:46:37 GMT):
by proxy: https://github.com/orgs/hyperledger/teams/fabric-admins/members

BrettLogan (Fri, 22 Nov 2019 15:51:52 GMT):
And that is all, we are officially on GitHub. Maintainers can start the review process using GitHub moving forward

dave.enyeart (Fri, 22 Nov 2019 17:17:52 GMT):
@BrettLogan Great job leading the way on our transition... you've made it look very smooth, but we're all aware of just how much hard work went into making it look smooth. We've landed in a much more rational and understandable place in terms of contributions and CI. There's more to do, but let's celebrate this success for a moment!

dave.enyeart (Fri, 22 Nov 2019 17:18:57 GMT):
Let's also share tips as we find our way around. Brett and Danny shared two great resources already -

dave.enyeart (Fri, 22 Nov 2019 17:19:20 GMT):
https://hub.github.com/ - hub is an extension to command-line git that helps you do everyday GitHub tasks without ever leaving the terminal.

dave.enyeart (Fri, 22 Nov 2019 17:19:47 GMT):
https://desktop.github.com/ GitHub desktop

dave.enyeart (Fri, 22 Nov 2019 17:22:20 GMT):
And Yacov shared a linting and vetting option with great integration with GitHub: https://golangci.com/

rjones (Fri, 22 Nov 2019 19:07:54 GMT):
https://dev.azure.com/Hyperledger/Fabric/_dashboards/dashboard/b5334ea6-f0a0-420a-905b-fab621a9f288 (should be visible even if you aren't AUTHN)

dave.enyeart (Sat, 23 Nov 2019 13:52:20 GMT):
@BrettLogan @rjones I unchecked this one for Fabric

dave.enyeart (Sat, 23 Nov 2019 13:52:24 GMT):

Clipboard - November 23, 2019 8:52 AM

dave.enyeart (Sat, 23 Nov 2019 13:53:19 GMT):
Our policy to date has been that it is maintainer judgement whether a rebase and re-verify is required before merging.

dave.enyeart (Sat, 23 Nov 2019 13:54:23 GMT):
Otherwise we'll need to run all checks again before every merge, and as we know there are still flakes around

dave.enyeart (Sat, 23 Nov 2019 13:54:38 GMT):
I think we should uncheck for all repositories. Any concerns?

dave.enyeart (Sat, 23 Nov 2019 13:54:38 GMT):
I think we should keep uncheck for all repositories to align with our long standing policy of using maintainer judgement. Any concerns?

dave.enyeart (Sat, 23 Nov 2019 13:54:38 GMT):
I think we should keep unchecked for all repositories to align with our long standing policy of using maintainer judgement. Any concerns?

dave.enyeart (Sat, 23 Nov 2019 13:54:38 GMT):
I think we should keep unchecked for all repositories. Any concerns?

BrettLogan (Sat, 23 Nov 2019 13:55:15 GMT):
That was checked? I didn't think that was enabled

dave.enyeart (Sat, 23 Nov 2019 13:55:28 GMT):
yeah it was checked, maybe just by mistake

dave.enyeart (Sat, 23 Nov 2019 13:55:39 GMT):
i couldn't merge PRs as a result

BrettLogan (Sat, 23 Nov 2019 15:44:34 GMT):
https://github.com/hyperledger/fabric/pull/309

BrettLogan (Sat, 23 Nov 2019 15:45:08 GMT):
This fixes a bug introduced by a cherrypick in release-1.4

rjones (Sat, 23 Nov 2019 18:55:28 GMT):
@dave.enyeart this is why I would like to get GitHub repo settings into the repo :)

greg2git (Sun, 24 Nov 2019 17:29:38 GMT):
any plans to go beyond the default message here (About this project)? https://dev.azure.com/Hyperledger/Fabric

dave.enyeart (Sun, 24 Nov 2019 18:06:58 GMT):
@MHBauer Here's the instructions for testing with Fabric binaries:

dave.enyeart (Sun, 24 Nov 2019 18:07:01 GMT):
https://wiki.hyperledger.org/display/fabric/Testing+with+Fabric+binaries

dave.enyeart (Sun, 24 Nov 2019 18:07:18 GMT):
I was thinking of adding it to the contribution guide here: https://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html#

dave.enyeart (Sun, 24 Nov 2019 18:08:01 GMT):
Although, it could be used by end consumers as well, as a lightweight alternative to byfn sample

dave.enyeart (Sun, 24 Nov 2019 18:08:01 GMT):
Although, it could be used by end consumers as well after they download the binaries, as a lightweight alternative to byfn sample

dave.enyeart (Sun, 24 Nov 2019 18:08:15 GMT):
What does everybody think?

rjones (Sun, 24 Nov 2019 18:09:05 GMT):
what should I put in there? I notice a lot of the repos on GitHub don't have descriptions and the like

greg2git (Sun, 24 Nov 2019 18:11:12 GMT):
seems like a full circle has been made with github, on, off, back on, and now on Azure, so maybe something to that effect?

dave.enyeart (Sun, 24 Nov 2019 18:18:51 GMT):
Ry, you could put our generic description:

dave.enyeart (Sun, 24 Nov 2019 18:18:55 GMT):
```Hyperledger Fabric is an enterprise-grade permissioned distributed ledger framework for developing solutions and applications. Its modular and versatile design satisfies a broad range of industry use cases. It offers a unique approach to consensus that enables performance at scale while preserving privacy.```

rjones (Sun, 24 Nov 2019 18:34:49 GMT):
dome

rjones (Sun, 24 Nov 2019 18:34:49 GMT):
done

dave.enyeart (Sun, 24 Nov 2019 18:52:20 GMT):
@MHBauer Here's the instructions for testing with Fabric binaries:

dave.enyeart (Sun, 24 Nov 2019 18:52:26 GMT):
https://wiki.hyperledger.org/display/fabric/Testing+with+Fabric+binaries

dave.enyeart (Sun, 24 Nov 2019 18:52:33 GMT):
I was thinking of adding it to the contribution guide here: https://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/build.html#

dave.enyeart (Sun, 24 Nov 2019 18:52:38 GMT):
What does everybody think?

dave.enyeart (Mon, 25 Nov 2019 18:02:29 GMT):
Ah, good idea, I found the doc for it here: https://github.com/probot/settings We'll look into it.

dave.enyeart (Mon, 25 Nov 2019 18:02:29 GMT):
Ah, good idea, Brett found the doc for it here: https://github.com/probot/settings We'll look into it.

dave.enyeart (Mon, 25 Nov 2019 18:51:33 GMT):
GitHub tip: I've found the PR search filters to be not well documented. Here's how to filter on reviewable PRs - open non-draft PRs that have passed checks:

dave.enyeart (Mon, 25 Nov 2019 18:51:35 GMT):
https://github.com/hyperledger/fabric/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+draft%3Afalse+status%3Asuccess

dave.enyeart (Mon, 25 Nov 2019 19:04:39 GMT):
GitHub tip: The Reviewers list is the potential reviewers. You can also add Assignees if you'd like a specific person to review.

dave.enyeart (Mon, 25 Nov 2019 19:04:39 GMT):
GitHub tip: The Reviewers list is the potential reviewers based on the CODEOWNERS file. You can also add Assignees if you'd like a specific person to review.

rjones (Mon, 25 Nov 2019 19:07:07 GMT):
You could also make a much more granular CODEOWNERS file if you wanted.

dave.enyeart (Mon, 25 Nov 2019 19:15:40 GMT):
GitHub tip: When merging, Click `Rebase and merge` rather than `Create a merge commit` so that our commit history looks clean.

dave.enyeart (Mon, 25 Nov 2019 19:20:49 GMT):
Does anybody see a reason to ever `Create a merge commit` rather than `Rebase and merge`? If not, @rjones reminded me that we can remove that option...

rjones (Mon, 25 Nov 2019 19:21:42 GMT):
there is also the `squash and merge` option which, TBH, is not great

dave.enyeart (Mon, 25 Nov 2019 19:22:47 GMT):
yeah, we'll typically suggest to the code contributor that they should squash their own commits, but thought we may want to leave that option just in case.

dave.enyeart (Mon, 25 Nov 2019 19:22:47 GMT):
yeah, we'll typically suggest to the code contributor that they should squash their own commits (unless the stack of commits is actually interesting), but thought we may want to leave that option just in case.

mastersingh24 (Mon, 25 Nov 2019 20:17:09 GMT):
I think we still want the squash and merge option (in case people don't squash when the should and a maintainer wants to make a judgement call

guoger (Tue, 26 Nov 2019 02:03:28 GMT):
is it still possible to run IT or UT individually? is there a list of /azp commands documented? thx

guoger (Tue, 26 Nov 2019 02:17:04 GMT):
also, do we not require a jira in commit msg anymore? i see some PRs w/o it, and i don't see it in commit msg template..

BrettLogan (Tue, 26 Nov 2019 03:22:25 GMT):
@guoger As a maintainer, you can use the Checks tab to retrigger just UT or IT

BrettLogan (Tue, 26 Nov 2019 03:23:31 GMT):
Your PR got caught in some strange limbo though, not sure what happened, I did open a ticket with Azure so they could note it. The 4 sets of tests passed, but there is a stray (old) integration test that got canceled

guoger (Tue, 26 Nov 2019 03:24:52 GMT):
thx!! i was quite puzzled... also, i don't see a `trigger rebuild` button in check tab? should i log into azure pipeline or something?

BrettLogan (Tue, 26 Nov 2019 03:24:59 GMT):
You won't

BrettLogan (Tue, 26 Nov 2019 03:25:05 GMT):
Technically your 4 tests passed

BrettLogan (Tue, 26 Nov 2019 03:25:14 GMT):
Or do you mean on other PR's

guoger (Tue, 26 Nov 2019 03:25:57 GMT):
ah, i see a little `re-run` button

guoger (Tue, 26 Nov 2019 03:26:03 GMT):
yeah, i mean other PRs

BrettLogan (Tue, 26 Nov 2019 03:26:31 GMT):
Yea, as a maintainer you can use that to retrigger just the failed job

BrettLogan (Tue, 26 Nov 2019 03:26:48 GMT):
Non-maintainers don't get that button unfortunately

guoger (Tue, 26 Nov 2019 03:26:56 GMT):
then i assume contributors would be using `/azp run` to trigger whole build?

BrettLogan (Tue, 26 Nov 2019 03:26:59 GMT):
I did open a feature request to AZP on that

BrettLogan (Tue, 26 Nov 2019 03:27:16 GMT):
Actually /azp-run has the same limitation

BrettLogan (Tue, 26 Nov 2019 03:27:33 GMT):
https://github.com/hyperledger/fabric/pull/313

BrettLogan (Tue, 26 Nov 2019 03:27:51 GMT):
This is my proposal to provide that functionality to authors who aren't maintainers

BrettLogan (Tue, 26 Nov 2019 03:29:08 GMT):
I'm also looking for comments on this, I implemented Azure's parallel test strategy to split the load for integration tests, bring IT down to an hour instead of 1:45

BrettLogan (Tue, 26 Nov 2019 03:29:08 GMT):
I'm also looking for comments on this, I implemented Azure parallel test strategy to split the load for integration tests, bring IT down to an hour instead of 1:45

BrettLogan (Tue, 26 Nov 2019 03:29:10 GMT):
https://github.com/hyperledger/fabric/pull/312

guoger (Tue, 26 Nov 2019 03:30:11 GMT):
i was looking at that but i guess i'll need to familiarize myself with azp to some extent... looks promising though!

guoger (Tue, 26 Nov 2019 03:31:01 GMT):
also i assume parallel IT wouldn't interfere each other in terms of listening ports?

BrettLogan (Tue, 26 Nov 2019 03:31:12 GMT):
Correct, they run on discreet VM's

BrettLogan (Tue, 26 Nov 2019 03:31:50 GMT):
They have an intelligent load balancer as well (takes historical runtimes to load balance your test suite for you) but there is no adapter for GoLang yet

guoger (Tue, 26 Nov 2019 03:32:21 GMT):
i see, that's nice :)

guoger (Tue, 26 Nov 2019 03:33:31 GMT):
are we planning to take down gerrit server any time soon? would be nice to have an archive of it. i sometimes find it useful to dig into some history comments

BrettLogan (Tue, 26 Nov 2019 03:34:46 GMT):
We asked to keep it running for a few months into next year, but we should probably follow up on that request, that would give us some time to collect the data and archive it

BrettLogan (Tue, 26 Nov 2019 03:34:46 GMT):
I do believe we asked to keep it running for a few months into next year, but we should probably follow up on that request with Chris, that would give us some time to collect the data and archive it

BrettLogan (Tue, 26 Nov 2019 03:34:46 GMT):
I do believe we asked to keep it running for a few months into next year, but we should probably follow up on that request, that would give us some time to collect the data and archive it

BrettLogan (Tue, 26 Nov 2019 03:36:22 GMT):
Scrape it, put it into a json object and cache it in github so people can clone the repo and query it with jq

BrettLogan (Tue, 26 Nov 2019 03:36:22 GMT):
Scrape it, put it into a json object and cache it in an archive github repo so people can clone the archiv erepo and query it with jq

BrettLogan (Tue, 26 Nov 2019 03:36:22 GMT):
Scrape it, put it into a json object and cache it in an archive github repo so people can clone the archive repo and query it with jq

guoger (Tue, 26 Nov 2019 03:46:20 GMT):
this might sound dumb but is it possible to comment on lines that are not modified in a PR? (those collapsed ones)

BrettLogan (Tue, 26 Nov 2019 03:50:42 GMT):
Hmmm, it actually doesn't seem like it

BrettLogan (Tue, 26 Nov 2019 03:54:38 GMT):
Apparently GitHub's position is, since you can use git blame in the UI when doing a review, you should do a Git Blame and comment on the commit that last modified that line, which is something github allows

guoger (Tue, 26 Nov 2019 03:58:49 GMT):
oh i didn't know that.. and that comment will be included in current PR? (instead of history PR that actually contained that commit)

BrettLogan (Tue, 26 Nov 2019 04:02:37 GMT):
Doesn't propogate to the PR, looks like it just leaves it on the commit and sends an email to the parties involved in that commit https://github.com/btl5037/fabric/commit/a0032984b1e1bc8cb356788f1cdb6b054f5b5e7a

BrettLogan (Tue, 26 Nov 2019 04:02:45 GMT):
Scroll to the bottom

BrettLogan (Tue, 26 Nov 2019 04:03:12 GMT):
And for clarity, its the commit, not the PR, as we didn't have PR's for 3 years until this week in Fabric

BrettLogan (Tue, 26 Nov 2019 04:04:04 GMT):
Jason's going to wake up wondering why I commented on a 2 year old commit

BrettLogan (Tue, 26 Nov 2019 04:05:29 GMT):
Doesn't propogate to the PR, looks like it just leaves it on the commit and sends an email to the parties involved in that commit https://github.com/btl5037/fabric/commit/a0032984b1e1bc8cb356788f1cdb6b054f5b5e7a Scroll to the bottom And for clarity, its the commit, not the PR, as we didn't have PR's for 3 years until this week in Fabric Jason's going to wake up wondering why I commented on a 2 year old commit

rjones (Tue, 26 Nov 2019 08:03:55 GMT):
no need to scrape it at all. I have a 500 meg JSON export of Gerrit that's up-to-date for this weekend. I'll re-run the export when fabric-test is read-only

rjones (Tue, 26 Nov 2019 08:04:55 GMT):
I've been trying to figure out how to use jq to get anything useful

rjones (Tue, 26 Nov 2019 08:47:29 GMT):
https://github.com/ryjones/hyperledger-gerrit-export

rjones (Tue, 26 Nov 2019 08:47:44 GMT):
Once fabric-test is read-only, I'll add one more commit and archive the repo

dave.enyeart (Tue, 26 Nov 2019 12:55:22 GMT):
@rjones what are the options for querying the gerrit export? Is it possible to stand up a Gerrit server 'on the side', either central or on our local machines?

BrettLogan (Tue, 26 Nov 2019 16:35:31 GMT):
GitHub recently released `Autolinking References` so we can setup GitHub to automatically parse and link FAB numbers like we have historically so we get links to Jira in Commit messages, Commit headers and PR Descriptions: https://help.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources

BrettLogan (Tue, 26 Nov 2019 16:37:10 GMT):
I've tested it and it works well https://github.com/btl5037/fabric/pull/5/commits/43c5804d2bd4d3f40294ad6f709f6325ab26095b

rjones (Tue, 26 Nov 2019 17:31:00 GMT):
@dave.enyeart we have a lot of options. What do fabric maintainers want? One option, the most expensive, is to leave Gerrit in readonly mode.

rjones (Tue, 26 Nov 2019 17:37:08 GMT):
@BrettLogan cool. That option doesn't exist for `hyperledger` repos for some reason - I'll dig into it later

rjones (Tue, 26 Nov 2019 17:45:00 GMT):
@dave.enyeart one I worked on for a while uses scapy: https://github.com/ryjones/gerrit-static-archive it needs some work to support the Gerrit version we're running, and I didn't make the progress I wanted.

rjones (Tue, 26 Nov 2019 17:45:46 GMT):
https://review.source.kitware.com/%23/q/status:open/ is an example of the type of export that tool generates

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future of v2.1.0 so that we can see what is truly remaining. *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository This week Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future of v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed%20ORDER%20BY%20key%20ASC&startIndex=250 *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository This week Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future or v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed%20ORDER%20BY%20key%20ASC&startIndex=250 *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository This week Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future or v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed%20ORDER%20BY%20key%20ASC *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository This week Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future or v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository This week Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future or v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository This weeks Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future or v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - Mailing list discussion wrt creation of fabric-docs repository *Deep Dive* This weeks Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

dave.enyeart (Tue, 26 Nov 2019 19:47:53 GMT):
@here While we'll likely have a small turnout for the contributor meeting on Wednesday due to the US holiday, I'd like to proceed with the meeting since we have the v2.0 beta quickly coming up, not to mention all the recent SCM and CI activity. Agenda topics so far: *Release update* I suggest we target v2.0 beta for December 13th. There's about two weeks of close down work, and we don't want to butt up against the holidays. Remaining items that we are closing down: - finalize doc for items we'd like to showcase in the beta (lifecycle done, external chaincode and private data enhancements in progress) - external chaincode as a server - state database cache for improved performance (merged for couchdb, performance assessment to determine if it should be applied to leveldb as well) - upgrade documentation and test (won't gate a beta, but would be nice-to-have for people to preview) - Jira cleanup to ensure we don't overlook something half-baked - we haven't been very disciplined lately... 291 open issues with FixVersion of v2.0.0. Please clean up items in your respective wheelhouses... either Close or set FixVersion to Future or v2.1.0 so that we can see what is truly remaining. https://jira.hyperledger.org/issues/?jql=fixVersion%20%3D%20v2.0.0%20AND%20status%20!%3D%20closed *SCM and CI update* - Switched `fabric` and `fabric-baseimage` and `fabric-sdk-node` repository from Gerrit to Github last week. Nice job closing down the Fabric review backlog. Kudos to Brett Logan for a smooth transition. - Last Gerrit repo to switch over in December is fabric-test - We expect to shift from Nexus to Azure Artifacts for storage of non-release artifacts - Mailing list discussion wrt creation of fabric-docs repository *Deep Dive* This weeks Deep Dive in preparation for v2.0 beta is *External chaincode - Matt Sykes*

troyronda (Tue, 26 Nov 2019 20:40:53 GMT):
We like golangci-lint but we ended up just running it inside GitHub Actions / AZP.

guoger (Wed, 27 Nov 2019 04:41:31 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=PNZjibuybXaRhbfod) do we want to advocate for addressing review comments in *separate commits*, and squash merge when approved? So it's easier to view what have been changed, whether it actually resolves comments, and new changes.

guoger (Wed, 27 Nov 2019 04:41:50 GMT):
instead of amending current commit and `push -f`

dave.enyeart (Wed, 27 Nov 2019 14:01:00 GMT):
@here contributor meeting starting https://zoom.us/my/hyperledger.community.3 ... looks like phone dial-in has been disabled

davidkhala (Wed, 27 Nov 2019 16:08:33 GMT):
if there is some extreme case like a big PR (over 500 lines), the first commit is library|functional change signed by author A, the second commit is correspondingly test covering this change while signed by collaborator author B.

davidkhala (Wed, 27 Nov 2019 16:08:33 GMT):
if there is some corner case like a big PR (over 500 lines), the first commit is library|functional change signed by author A, the second commit is correspondingly test covering this change while signed by collaborating author B.

rjones (Wed, 27 Nov 2019 19:36:29 GMT):
I can't find the channel where we were discussing jira linking. That is a paid feature and it would cost about $3500/month to enable. Sorry.

BrettLogan (Wed, 27 Nov 2019 23:00:58 GMT):
We have merged the change to the make the `/ci-run` comment active. Maintainers and the Pull Request author can comment `/ci-run` to retrigger failed CI. *Note:* It does retrigger all of the jobs, maintainers, next week after the holiday, I will get instructions out on how to create Azure DevOps accounts so you can trigger individual jobs rather than all of them. For those maintainers whose companies have Azure Active Directories, and your github email being one that is registered in Azure AD using SSO, this causes a minor headache in that Microsoft doesn't let you use your GitHub ID to login (which is required to make all of the functionality work), but there is a very, very simple work around. In the meantime, I ask that you not use the "re-run" option on the Checks tab, as it seems to have a flake in it that causes multiple jobs to register, but only one succeeds and thus prevents PR's from being merged.

guoger (Thu, 28 Nov 2019 06:52:09 GMT):
@davidkhala i'd like to see incremental changes for fat PR, as you described. But what i was saying is actually about *how to address review comments*. IMO, they should be made as explicit commits as well, and squashed at very end when ready to merge.

guoger (Thu, 28 Nov 2019 06:52:53 GMT):
(simply due to the fact that Github, unlike gerrit, cannot display diff between pushes)

dave.enyeart (Thu, 28 Nov 2019 13:51:45 GMT):
@guoger I think for larger changes we'd encourage multiple commits and then use judgement whether to squash or not upon merge. For smaller commits just amend the commit. But this is my first time using GitHub at scale...

dave.enyeart (Thu, 28 Nov 2019 13:52:52 GMT):
Besides making it easy for people shifting from Gerrit, one of my objectives of creating https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html#updating-a-pull-request was to put our own spin on it... feel free to edit and add the multi-commit recommendation...

dave.enyeart (Thu, 28 Nov 2019 13:52:52 GMT):
Besides making it easy for newcomers and people shifting from Gerrit, one of my objectives of creating https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html#updating-a-pull-request was to put our own spin on it... feel free to edit and add the multi-commit recommendation...

davidkhala (Thu, 28 Nov 2019 14:46:05 GMT):
for beginner or git GUI tool fans (indeed I am), the multi-commit is more natural since some of GUI tools don't allow us to do this. They consider `force push`is a bit dangerous, causing the remote to lose commit

davidkhala (Thu, 28 Nov 2019 14:46:05 GMT):
for beginner or git GUI tool fan (indeed I am), the multi-commit is more natural since some of GUI tools don't allow us to do this. They consider `force push`is a bit dangerous, causing the remote to lose commit

davidkhala (Thu, 28 Nov 2019 14:50:40 GMT):
Beside squash, we could emphasis a bit about run `git push -f` in CLI. A funny story happened to me that I had squashed my edited commits into one, but forget adding force token to git push,. Boom.

guoger (Mon, 02 Dec 2019 04:24:09 GMT):
just learned that you can click on `force-pushed` to view diff between old and new commits, just like gerrit: https://github.com/isaacs/github/issues/999#issuecomment-441028146

BrettLogan (Mon, 02 Dec 2019 04:36:28 GMT):
Nice! Didn't know this either.

guoger (Mon, 02 Dec 2019 06:07:27 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=ppxqmkwGcZQnePXHj) i think we should emphasize on adding details to commit messages, *not only* PR message. Commit message goes to git history, which should be one click away from linked JIRA issue. Especially if no merge commit is created, in which case PR msg get lost.

santmukh (Mon, 02 Dec 2019 14:36:30 GMT):
Has joined the channel.

santmukh (Mon, 02 Dec 2019 14:38:26 GMT):
Hi, I tried to create network with one static organization and 5 orderer based on Raft consensus. Peer is not able to connect to orderer. Attached is the file of errors.

santmukh (Mon, 02 Dec 2019 14:39:54 GMT):

Error-1.txt

BrettLogan (Mon, 02 Dec 2019 14:40:27 GMT):
Please move this question to #fabric or #fabric-questions

santmukh (Mon, 02 Dec 2019 14:46:35 GMT):
Sure

medikent (Mon, 02 Dec 2019 23:38:15 GMT):
Can I get meeting notes for this meeting? I am interested in the upgrades to BYFN.

medikent (Mon, 02 Dec 2019 23:41:49 GMT):
I'd like to help with this. What work, if any, remains to be done?

dave.enyeart (Mon, 02 Dec 2019 23:47:03 GMT):
@medikent here's links to contributor meeting recording, the doc workgroup where byfn updates are being discussed, and app developer workgroup where contract apis are being discussed

dave.enyeart (Mon, 02 Dec 2019 23:47:07 GMT):
https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

dave.enyeart (Mon, 02 Dec 2019 23:47:30 GMT):
https://wiki.hyperledger.org/display/fabric/2019+11+22+DWG+Agenda

dave.enyeart (Mon, 02 Dec 2019 23:48:12 GMT):
https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call

dave.enyeart (Mon, 02 Dec 2019 23:48:12 GMT):
https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call - see nov 28th recording

medikent (Tue, 03 Dec 2019 02:40:55 GMT):
thanks!

medikent (Tue, 03 Dec 2019 02:45:38 GMT):
I didn't see the nov 28th recording on the community call list.

mbwhite (Tue, 03 Dec 2019 17:34:39 GMT):
Hi; I've just started work on a RFC; though I like github I admit I find the default format for Markdown a little 'confining'. We've done a lot with gh-pages in the past... so I wondered if we could use gh-pages to help with the RFCs. As I'd forked the RFC repo anyway I thought a quick experiment was in order. https://mbwhite.github.io/fabric-rfcs/ is the result Very simple navigation, with search! Changes are 1 simple config file, and an index.md file Very simple front matter needed on the markdown files. Thoughts welcome!

mbwhite (Tue, 03 Dec 2019 17:35:09 GMT):
(oh click on RFCs on the left for a list of all the currently accept ones... think I need to rename that!)

Silona (Tue, 03 Dec 2019 17:50:40 GMT):
The Hyperledger Fabric Developer (CHFD) exam is scheduled to launch in late Q1 2020 and we are now looking for Beta testers. Interested parties should complete the CHFD Beta Sign-up Form by January 15, 2020. The CHFD Beta is FREE for the first 20 who qualify and after that it will be available at the low discount of $100. https://training.linuxfoundation.org/certification/certified-hyperledger-fabric-developer/ https://docs.google.com/forms/d/e/1FAIpQLScPxgBt6GvuTcrtjYCkWqW2D6o-2YrNd4vR--KXFGUw-5Ctsw/viewform

cbf (Wed, 04 Dec 2019 14:05:53 GMT):
@mbwhite nice! I like it. Seems like a simple tweak. What do others think? @all

mbwhite (Wed, 04 Dec 2019 16:42:18 GMT):
Thanks for the thumbs=up... is it worth creating a PR for just the changes? can be reviewed and discussed as needed?

rjones (Wed, 04 Dec 2019 19:02:05 GMT):
Many of these repos are missing tags, descriptions, etc. If you have `maintain` or `admin` permissions, you should be able to edit them directly. https://github.com/hyperledger?utf8=%E2%9C%93&q=fabric&type=&language=

dave.enyeart (Wed, 04 Dec 2019 19:19:08 GMT):
@mbwhite yep, go ahead and PR, thanks!

guoger (Thu, 05 Dec 2019 04:11:22 GMT):
well... the bad thing is if you amend *and* rebase in one push, it shows all files touched in those intermediate commits... :(

jyellick (Thu, 05 Dec 2019 04:41:45 GMT):
Yes, I ran into this very problem earlier today. It's is a raw diff between the two commits, not what you would expect/want

andrew-coleman (Thu, 05 Dec 2019 11:21:35 GMT):
RFC for implementation of fabric programming model in the Go SDK: https://github.com/hyperledger/fabric-rfcs/pull/14

mbwhite (Thu, 05 Dec 2019 13:22:12 GMT):
PR for the gh-pages updates. https://github.com/hyperledger/fabric-rfcs/pull/15

dave.enyeart (Thu, 05 Dec 2019 14:18:40 GMT):
Does anybody see a compelling reason to release a fabric-ca v2.0 concurrent with fabric v2.0?

dave.enyeart (Thu, 05 Dec 2019 14:19:06 GMT):
No important changes in fabric-ca master... and all bugs have been going into release-1.4 branch regardless

dave.enyeart (Thu, 05 Dec 2019 14:19:06 GMT):
No important changes in fabric-ca master... and all bug fixes have been going into release-1.4 branch regardless

dave.enyeart (Thu, 05 Dec 2019 14:27:33 GMT):
The only significant change I see in fabric-ca master that is not in release-1.4, is the shift to apline images

rjones (Thu, 05 Dec 2019 18:40:06 GMT):
I have completed mirroring Gerrit to GitHub: https://github.com/hyperledger-gerrit-archive I'm interested in feedback if this is _good enough_.

dave.enyeart (Thu, 05 Dec 2019 19:37:11 GMT):
@rjones I think we'd need some story for querying gerrit review history

icarrascol (Thu, 05 Dec 2019 20:32:49 GMT):
Has joined the channel.

davidkhala (Fri, 06 Dec 2019 03:41:05 GMT):
@dave.enyeart One of community developer complained about fabric-ca 1.4 has dependency tagged with fabric 2.0-alpha. What is your idea?

wangdong (Fri, 06 Dec 2019 09:04:37 GMT):
@rjones we still can not track issues from github now for fabric projects now?

wangdong (Fri, 06 Dec 2019 09:06:43 GMT):
gerrit stil the choice?

santmukh (Fri, 06 Dec 2019 11:36:58 GMT):
Hi, can any one share the link of how to create RAFT over cluster VMs?

dave.enyeart (Fri, 06 Dec 2019 12:18:24 GMT):
Please provide a link to show what you are talking about

dave.enyeart (Fri, 06 Dec 2019 12:20:50 GMT):
Issue tracking is still done in Jira https://jira.hyperledger.org/issues/?jql=project%20%3D%20FAB

wangdong (Fri, 06 Dec 2019 23:15:56 GMT):
OK

BrettLogan (Sat, 07 Dec 2019 00:26:44 GMT):
https://github.com/btl5037/fabric-gerrit

BrettLogan (Sat, 07 Dec 2019 00:26:44 GMT):
https://github.com/btl5037/fabric-gerrit/tree/master/fabric

BrettLogan (Sat, 07 Dec 2019 00:27:20 GMT):
I wrote a small program to parse and convert the Gerrit server output into markdown

BrettLogan (Sat, 07 Dec 2019 00:27:20 GMT):
I have to split up the directories into logic units of 100 each, but this is the gerrit server converted into markdown, wrote a small program to parse and convert it

BrettLogan (Sat, 07 Dec 2019 00:27:20 GMT):
I have to split up the directories into logical units of 100 each, but this is the gerrit server converted into markdown, wrote a small program to parse and convert it

BrettLogan (Sat, 07 Dec 2019 00:27:57 GMT):
The file names are the gerrit ID and you can search the repo using the standard search box at the top

BrettLogan (Sat, 07 Dec 2019 00:27:57 GMT):
The file names are the gerrit ID, and they are sorted into directories of 100, where the directory names are the range of the gerrit ID's inside the directory. You can search the repo using the standard search box at the top

BrettLogan (Sat, 07 Dec 2019 00:28:40 GMT):
Ran it against all projects, so everything should be there

BrettLogan (Sat, 07 Dec 2019 00:33:29 GMT):
Need to do some clean up on it as well, to fix minor formatting errors when data isn't present as well, but you get the idea

BrettLogan (Sat, 07 Dec 2019 03:24:01 GMT):

Clipboard - December 6, 2019 10:23 PM

BrettLogan (Sat, 07 Dec 2019 03:24:44 GMT):
When you do a search, if you want to limit it to the raw JSON data (which is easier to read in the search than looking at markdown and html), you can select JSON on the left after searching

dave.enyeart (Sat, 07 Dec 2019 13:45:29 GMT):
@BrettLogan looking good! I'm able to search by FAB number which is probably the most common pattern. The only thing I see missing in the markdown is inline review comments.

BrettLogan (Sat, 07 Dec 2019 16:16:17 GMT):
I see the problem, there is a comment block in the PatchSet block I missed, I'll add that

rjones (Sun, 08 Dec 2019 18:04:59 GMT):
@dave.enyeart I was thinking this could go to a GitHub pages site off of the archive org - do you think that would be OK?

dave.enyeart (Sun, 08 Dec 2019 18:56:34 GMT):
think so, i like the idea of capturing the old reviews in markdown

rjones (Sun, 08 Dec 2019 19:02:00 GMT):
The data is there to point to the lines where the comments were. I was thinking an iframe or something to embed the diff at the place of a comment? I'm not sure how much work should be put into this

dave.enyeart (Sun, 08 Dec 2019 19:21:09 GMT):
Did you look at Brett's archive with reviews in markdown?

rjones (Sun, 08 Dec 2019 19:23:46 GMT):
Yes. I was suggesting the GitHub pages/iframe solution in public; it was one I was already discussing with @BrettLogan in private

BrettLogan (Sun, 08 Dec 2019 20:27:02 GMT):
https://github.com/btl5037/fabric-gerrit/blob/master/fabric/34246-34448/34350.md

BrettLogan (Sun, 08 Dec 2019 20:28:04 GMT):
Newest revision has all comments pertaining to an individual patchset in it. The comments also have links to that commit in GitHub, so if you click it, it will take you to the exact commit and line that the comment was made on

rjones (Sun, 08 Dec 2019 21:30:35 GMT):
would you be willing to re-license this as Apache 2 so we could move this to the Hyperledger org?

BrettLogan (Sun, 08 Dec 2019 23:18:14 GMT):
Added the LICENSE file

rjones (Mon, 09 Dec 2019 14:36:00 GMT):
I saw a reference to ISC in one of the files

rjones (Mon, 09 Dec 2019 14:41:36 GMT):
https://github.com/btl5037/fabric-gerrit/blob/459efb78810be514a60a9de6161f25013d354d21/package.json#L11

BrettLogan (Mon, 09 Dec 2019 15:22:34 GMT):
Let me address that

BrettLogan (Mon, 09 Dec 2019 15:27:29 GMT):
Fixed, thanks Ry

dave.enyeart (Mon, 09 Dec 2019 15:59:17 GMT):
We are working on a v2.0.0-beta this week for announcement next week, remaining items that we are trying to close down by EOD Wednesday: - external chaincode as a server - @muralisr could you help with the docs? anything else must-do for beta in this area? - external chaincode documentation - @sykesm is working on docs. - state database cache for improved performance - confirmed cache improves performance, but looking into other v2.0 performance regressions - finalize upgrade doc - https://github.com/hyperledger/fabric/pull/299 - finalize private data doc - https://github.com/hyperledger/fabric/pull/380 - what's new for beta, release notes (Dave with doc team) - new sample test network to replace BYFN (Nik will present progress at contributor meeting on Wednesday) https://github.com/hyperledger/fabric-samples/pull/80 https://github.com/hyperledger/fabric/pull/369 - any other high priorities for beta?

dave.enyeart (Mon, 09 Dec 2019 15:59:17 GMT):
We are working on a v2.0.0-beta this week for announcement next week, remaining items that we are trying to close down by EOD Wednesday: - external chaincode as a server - @muralisr could you help with the docs? anything else must-do for beta in this area? - external chaincode documentation - @sykesm is working on docs. - state database cache for improved performance - confirmed cache improves performance for read-heavy workloads on couchdb, but looking into other v2.0 performance regressions - finalize upgrade doc - https://github.com/hyperledger/fabric/pull/299 - finalize private data doc - https://github.com/hyperledger/fabric/pull/380 - what's new for beta, release notes (Dave with doc team) - new sample test network to replace BYFN (Nik will present progress at contributor meeting on Wednesday) https://github.com/hyperledger/fabric-samples/pull/80 https://github.com/hyperledger/fabric/pull/369 - any other high priorities for beta?

rjones (Mon, 09 Dec 2019 17:08:08 GMT):
@BrettLogan do you want to set up a GitHub pages branch or no?

rjones (Mon, 09 Dec 2019 17:08:46 GMT):
or I can just dump it into the other org and we can point people to it. @dave.enyeart is where it is good enough?

muralisr (Mon, 09 Dec 2019 17:48:17 GMT):
@dave.enyeart will get the docs by Thursday... also trying to get an example into fabric-samples.

muralisr (Mon, 09 Dec 2019 17:49:02 GMT):
I assume the sample can go in after the beta cut ?

Silona (Mon, 09 Dec 2019 21:47:15 GMT):
Reminder if you haven't submitted yet the Hyperledger Fabric Developer (CHFD) exam is scheduled to launch in late Q1 2020 and we are now looking for Beta testers. Interested parties should complete the CHFD Beta Sign-up Form by January 15, 2020. https://training.linuxfoundation.org/certification/certified-hyperledger-fabric-developer/ https://docs.google.com/forms/d/e/1FAIpQLScPxgBt6GvuTcrtjYCkWqW2D6o-2YrNd4vR--KXFGUw-5Ctsw/viewform

dave.enyeart (Tue, 10 Dec 2019 04:05:43 GMT):
Yes...samples and doc updates can be made at any time... we'd like to have at least an anchor for the docs pre-beta... we can always extend afterwards if needed.

dave.enyeart (Tue, 10 Dec 2019 04:07:32 GMT):
i'm getting a bit lost about about the "it" and the "other org"... could you reset all of us on the details of the current proposal?

rjones (Tue, 10 Dec 2019 04:17:32 GMT):
I propose to either copy or transfer @BrettLogan 's repo that has .md files to the https://github.com/hyperledger-gerrit-archive org; pointing at the repos in that org (which have all of the unmerged commits)

rjones (Tue, 10 Dec 2019 04:18:07 GMT):
@BrettLogan has added pointers in the new .md files to point to unmerged commits by line.

dave.enyeart (Tue, 10 Dec 2019 12:34:16 GMT):
@BrettLogan @rjones When looking at an abandoned change such as https://github.com/btl5037/fabric-gerrit/blob/17b9fd79fb8e318821bfdd071b1e586ee9459838/fabric/33151-33431/33257.md , how to navigate to the corresponding unmerged commit?

dave.enyeart (Tue, 10 Dec 2019 12:35:41 GMT):
I see the links for inline comments to the unmerged commit, but is there a general link to the unmerged commit?

BrettLogan (Tue, 10 Dec 2019 13:04:35 GMT):
Under the Patchset, there is a field called, unmergedRevision

dave.enyeart (Tue, 10 Dec 2019 13:34:22 GMT):
cool, the repo has everything i was looking for then

rjones (Tue, 10 Dec 2019 17:58:22 GMT):
@BrettLogan is there a trivial way to wrap lines? some of the comments leave the page to the right. If there isn't a completely trivial solution, don't spend any time on it

rjones (Tue, 10 Dec 2019 17:59:23 GMT):
like the last comment on https://github.com/btl5037/fabric-gerrit/blob/17b9fd79fb8e318821bfdd071b1e586ee9459838/fabric/33151-33431/33257.md from jyellick, on my display I have to scroll to the right to see all of it

BrettLogan (Tue, 10 Dec 2019 18:16:01 GMT):
There isn't a trivial way. I wrapped the output in

tags to preserve the formatting, but the commenter didn't hit return at all when typing the comment, so there is no `\n` for it to format on, I suppose I could force wrap it on a character cound

BrettLogan (Tue, 10 Dec 2019 18:16:01 GMT):
There isn't a trivial way. I wrapped the output in

tags to preserve the formatting, but the commenter didn't hit return at all when typing the comment, so there is no `\n` for it to format on, I suppose I could force wrap it on a character count

rjones (Tue, 10 Dec 2019 18:19:24 GMT):
OK. sounds like a _wrap_ to me lol

BrettLogan (Tue, 10 Dec 2019 18:26:53 GMT):
https://www.tutorialspoint.com/How-do-I-wrap-text-in-a-pre-tag-in-HTML

BrettLogan (Tue, 10 Dec 2019 18:27:01 GMT):
So maybe it wont be as hard as I made it out to be lol

rjones (Tue, 10 Dec 2019 18:30:43 GMT):
This is a thread about the wonderful world of NPM

rjones (Tue, 10 Dec 2019 18:31:18 GMT):
@mastersingh24 @BrettLogan @dave.enyeart please tell me exactly which packages at NPM I have broken and how I can resolve this.

rjones (Tue, 10 Dec 2019 18:33:59 GMT):
When I look here: https://www.npmjs.com/settings/hyperledger/packages?page=0&perPage=100

rjones (Tue, 10 Dec 2019 18:34:20 GMT):
I see some packages published as `@hyperledger` and some that are not.

rjones (Tue, 10 Dec 2019 18:35:41 GMT):
If I understand, even the ones without the `@hyperledger` decoration are still published as `@hyperledger/something`, right?

rjones (Tue, 10 Dec 2019 18:36:07 GMT):
like, when I go here: https://www.npmjs.com/package/fabric-protos

rjones (Tue, 10 Dec 2019 18:36:22 GMT):
if I understand correctly, someone could name squat that package?

rjones (Tue, 10 Dec 2019 18:38:07 GMT):
compared to https://www.npmjs.com/settings/hyperledger-lf/packages?page=0&perPage=100

BrettLogan (Tue, 10 Dec 2019 18:42:49 GMT):
@mbwhite @sstone1

mbwhite (Tue, 10 Dec 2019 18:52:21 GMT):
The @hyperledger prefix forms part of the unique name of the package... @hyperledger/foo is different from just foo. What a developer has to install is different

rjones (Tue, 10 Dec 2019 18:52:54 GMT):
OK. To the point: what have I broken, and what do I need to do to unbreak things.

mbwhite (Tue, 10 Dec 2019 18:54:17 GMT):
We're going to need changes to all the examples and samples, developer docs etc to reflect a name change

rjones (Tue, 10 Dec 2019 18:57:00 GMT):
if this is about the two PRs I submitted, I do not care if those are rejected. I was trying to do the thing Burrow was doing.

rjones (Tue, 10 Dec 2019 18:57:23 GMT):
if this is about a change I made to NPM recently when I was trying to sort out package ownership, I need to fix it.

mbwhite (Tue, 10 Dec 2019 19:00:03 GMT):
It's purely the name in the PRs.. so long as the pipelines can still publish to NPM I'm not worried

rjones (Tue, 10 Dec 2019 19:00:23 GMT):
OK so reject those PRs and this is over?

mbwhite (Tue, 10 Dec 2019 19:01:16 GMT):
How those credentials are created managed etc is not an issue for me..

rjones (Tue, 10 Dec 2019 19:01:31 GMT):
OK. I closed the two PRs.

mbwhite (Tue, 10 Dec 2019 19:01:52 GMT):
All sorted 😀

rjones (Tue, 10 Dec 2019 19:01:53 GMT):
My understanding was that I had broken things by trying to transfer them to the Hyperledger org in the UI.

rjones (Tue, 10 Dec 2019 19:01:59 GMT):
thank goodness :)

rjones (Tue, 10 Dec 2019 19:03:18 GMT):
thank you @mbwhite I was worried I had broken something in the past, not caused future problems :u6307:

rjones (Tue, 10 Dec 2019 19:03:18 GMT):
thank you @mbwhite I was worried I had broken something in the past, not caused future problems :)

Rajatsharma (Wed, 11 Dec 2019 09:02:59 GMT):
Hi, I had mentioned a change in documentation (https://jira.hyperledger.org/browse/FAB-13176). But as I got to know Fabric has removed system chaincode plugins. The thing is we have developed an application using System chaincode plugin and now it's almost ready to release. This is really important for all of us here. Could anyone please help us, if fabric stops system chaincode plugin then how should we plan our application's future releases. Will fabric have any alternative for system chaincode?

Rajatsharma (Wed, 11 Dec 2019 09:02:59 GMT):
Hi Everyone, I had mentioned a change in documentation (https://jira.hyperledger.org/browse/FAB-13176). But as I got to know Fabric has removed system chaincode plugins. The thing is we have developed an application using System chaincode plugin and now it's almost ready to release. This is really important for all of us here. Could anyone please help us, if fabric stops system chaincode plugin then how should we plan our application's future releases. Will fabric have any alternative for system chaincode?

Rajatsharma (Wed, 11 Dec 2019 10:01:20 GMT):
@jyellick @mastersingh24 could you help me with this. This is really important for all of us here.

mastersingh24 (Wed, 11 Dec 2019 10:09:18 GMT):
We removed plugins but not the concept of system chaincode. You can still build your own peer binary which includes your system chaincode. https://github.com/hyperledger/fabric/blob/master/internal/peer/node/start.go#L713

Rajatsharma (Wed, 11 Dec 2019 10:29:53 GMT):
So instead of plugins, I'll have to use it the way we have lsscc ,vscc ?

mastersingh24 (Wed, 11 Dec 2019 10:30:36 GMT):
correct ... which is how system chaincode worked originally

Rajatsharma (Wed, 11 Dec 2019 10:31:27 GMT):
Okay !! Thanks a lot !! We all got a bit concerned on seeing that ticket.

mbwhite (Wed, 11 Dec 2019 11:05:12 GMT):
FYI - submitted a RFC PR for Ledger API (https://github.com/hyperledger/fabric-rfcs/pull/16) also the RFC GH-Pages update PR (https://github.com/hyperledger/fabric-rfcs/pull/15)

dave.enyeart (Wed, 11 Dec 2019 14:01:04 GMT):
Contributor meeting topics for today: v2.0.0-beta release update - We are trying to get everything merged for beta by end of day today, so that we can verify release process in Azure by end of week and announce next week. Closing down a few documentation tasks today including: - external chaincode https://github.com/hyperledger/fabric/pull/386 - upgrade https://github.com/hyperledger/fabric/pull/299 - what's new and release notes - I'll open a PR based on https://docs.google.com/document/d/1-rFiQy9VhqzZCz7ZPwk4sysRbn8x7vPSCovWVUTZPm8/edit?usp=sharing - any other high priority PRs for beta? Fabric Sample Test Network - Nik Gupta High level programming model for Go SDK - Andrew Coleman Introduction to ledger-api - Matthew White

dave.enyeart (Wed, 11 Dec 2019 14:01:47 GMT):
@here meeting starting: https://zoom.us/my/hyperledger.community.3

ravinayag (Wed, 11 Dec 2019 14:06:54 GMT):
Has joined the channel.

dave.enyeart (Wed, 11 Dec 2019 14:52:21 GMT):
We'll plan to skip the next meeting due to the holidays, next meeting therefore would be January 8.

muralisr (Wed, 11 Dec 2019 15:40:48 GMT):
@dave.enyeart missed the meeting this AM (apologize..!). Will get a google doc on chaincode-as-service by this PM and ping @pandrejko @joe-alewine ... @binhn and I are still working on it but here's the WIP https://docs.google.com/document/d/1WhJmbHt7JXNCStXWyM7eaTxUaA9PAlfHwVPI5RUnOAQ

muralisr (Wed, 11 Dec 2019 15:41:21 GMT):
@jyellick ^^^

joe-alewine (Wed, 11 Dec 2019 15:45:45 GMT):
It takes time to format and edit a doc to make it ready to be merged into the docs, so this PM seems way too late to me. @muralisr @dave.enyeart @pandrejko

muralisr (Wed, 11 Dec 2019 15:46:10 GMT):
ok

joe-alewine (Wed, 11 Dec 2019 15:46:10 GMT):
Also we are already heads down trying to finish our other docs

muralisr (Wed, 11 Dec 2019 15:46:35 GMT):
understood

mbwhite (Wed, 11 Dec 2019 15:48:53 GMT):
What's the best approach for RFC approval do we think? Process says there is a period of discussion, then a final week.

pandrejko (Wed, 11 Dec 2019 15:52:35 GMT):
@muralisr Can you grant me access to the google doc so I can take a look? patestibm@gmail.com

joe-alewine (Wed, 11 Dec 2019 15:52:56 GMT):
I've also requested access ^^^

rjones (Wed, 11 Dec 2019 15:53:13 GMT):
or consider putting it in the wiki please

muralisr (Wed, 11 Dec 2019 15:53:55 GMT):
of course... let me first grant access and I'll put it in wiki in a bit @rjones

muralisr (Wed, 11 Dec 2019 15:54:10 GMT):
@joe-alewine your email pl. ?

muralisr (Wed, 11 Dec 2019 15:57:06 GMT):
shared @pandrejko

joe-alewine (Wed, 11 Dec 2019 15:57:43 GMT):
@muralisr jalewine@gmail.com

muralisr (Wed, 11 Dec 2019 15:58:09 GMT):
on its way, Joe

dave.enyeart (Wed, 11 Dec 2019 18:37:20 GMT):
@here Please review What's New in v2.0 Beta doc: https://github.com/hyperledger/fabric/pull/395

dave.enyeart (Wed, 11 Dec 2019 18:39:02 GMT):
Formatted version: https://github.com/hyperledger/fabric/blob/0d743efc7a428b643d80668dd6b3917304324c0d/docs/source/whatsnew.rst

dave.enyeart (Wed, 11 Dec 2019 22:03:16 GMT):
Fabric doc builds are failing in Azure due to an Azure outage... I can force merge any PRs that are failing due to doc build

dave.enyeart (Wed, 11 Dec 2019 22:04:54 GMT):
Please highlight here any PRs that you'd like reviewed for v2.0 beta

dave.enyeart (Wed, 11 Dec 2019 22:05:03 GMT):
I'll start a list here...

dave.enyeart (Wed, 11 Dec 2019 22:05:09 GMT):
https://github.com/hyperledger/fabric/pull/299 upgrade doc

dave.enyeart (Wed, 11 Dec 2019 22:05:09 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/upgrade.html upgrade doc MERGED

dave.enyeart (Wed, 11 Dec 2019 22:05:22 GMT):
https://github.com/hyperledger/fabric/pull/395 what's new doc

dave.enyeart (Wed, 11 Dec 2019 22:05:22 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html what's new doc

dave.enyeart (Wed, 11 Dec 2019 22:05:22 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html what's new doc MERGED

dave.enyeart (Wed, 11 Dec 2019 22:05:22 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html what's new doc MERGED. Need to add links.

dave.enyeart (Wed, 11 Dec 2019 22:05:42 GMT):
https://github.com/hyperledger/fabric/pull/386 external launcher doc

dave.enyeart (Wed, 11 Dec 2019 22:05:58 GMT):
https://github.com/hyperledger/fabric/pull/399 chaincode as external service doc

dave.enyeart (Wed, 11 Dec 2019 22:06:42 GMT):
what else is important for beta?

greg2git (Wed, 11 Dec 2019 23:02:42 GMT):
when will it show up here: https://github.com/hyperledger/fabric ?

dave.enyeart (Thu, 12 Dec 2019 01:47:06 GMT):
We hope to tag the release by end of week

dave.enyeart (Thu, 12 Dec 2019 01:47:06 GMT):
We'll work through release process tomorrow, expect to tag v2.0.0-beta in the coming days.

Rajatsharma (Thu, 12 Dec 2019 08:01:38 GMT):
@mastersingh24 , I know it's under development. But would you reccomend shifting to https://github.com/hyperledger/fabric-contract-api-go even in our system chaincode. Once v2.0.0 rolls out ?

mastersingh24 (Thu, 12 Dec 2019 08:39:35 GMT):
on the system chaincode side, it would be up to you ... you can likley reduce some of the "boilerplate" code you use to dispatch functions via Invoke but other than that you are probably better off using the stright chaincode API as you'll have less depedencies moving forward

mastersingh24 (Thu, 12 Dec 2019 08:39:35 GMT):
on the system chaincode side, it would be up to you ... you can likely reduce some of the "boilerplate" code you use to dispatch functions via Invoke but other than that you are probably better off using the stright chaincode API as you'll have less depedencies moving forward

Rajatsharma (Thu, 12 Dec 2019 08:42:26 GMT):
@mastersingh24 thanks !! We'll like to go ahead with chaincode API only. As we won't need to change the code too much.

pandrejko (Thu, 12 Dec 2019 14:51:21 GMT):
@dave.enyeart Could we get this one in the beta if Nik addresses the comments? https://github.com/hyperledger/fabric/pull/369

dave.enyeart (Thu, 12 Dec 2019 14:52:28 GMT):
Yes, that's desired.

dave.enyeart (Thu, 12 Dec 2019 15:40:22 GMT):
https://github.com/hyperledger/fabric/pull/403 v2.0.0-beta release notes for review

dave.enyeart (Thu, 12 Dec 2019 15:40:22 GMT):
@here https://github.com/hyperledger/fabric/pull/403 v2.0.0-beta release notes for review

dave.enyeart (Thu, 12 Dec 2019 15:40:25 GMT):
Not as comprehensive as I'd like... ran out of time... we can add more details for the final release, but please review for any glaring omissions.

dave.enyeart (Thu, 12 Dec 2019 16:05:02 GMT):
Besides a few final doc PRs coming in... does anybody else have a PR to merge before we start v2.0.0-beta release?

BrettLogan (Thu, 12 Dec 2019 16:05:36 GMT):

Clipboard - December 12, 2019 11:05 AM

BrettLogan (Thu, 12 Dec 2019 16:06:15 GMT):
For those viewing Dave's doc, there is a button in the top right corner of the diff page to convert it to Rich Format which will render it in markdown for you (it the button to the right of the angle brackets)

yacovm (Thu, 12 Dec 2019 16:07:41 GMT):
features like these dull our programming skills...

yacovm (Thu, 12 Dec 2019 16:07:41 GMT):
features like these dull our programming skills... what's next? HTML rendering? :rolling_eyes:

dave.enyeart (Thu, 12 Dec 2019 16:09:03 GMT):
hmmm, I guess GitHub is better than Gerrit after all.

BrettLogan (Thu, 12 Dec 2019 16:09:13 GMT):
Nah, text-to-speech, it just reads you the diff

BrettLogan (Thu, 12 Dec 2019 19:05:07 GMT):
https://github.com/hyperledger/fabric/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+404+405

BrettLogan (Thu, 12 Dec 2019 19:05:17 GMT):
Two minor doc changes for fabric samples

BrettLogan (Thu, 12 Dec 2019 19:05:17 GMT):
Two minor doc changes in fabric for byfn

dave.enyeart (Thu, 12 Dec 2019 19:21:25 GMT):
merged

dave.enyeart (Thu, 12 Dec 2019 19:21:56 GMT):
MERGE FREEZE IN MASTER

dave.enyeart (Thu, 12 Dec 2019 19:21:56 GMT):
We got all the docs merged, so.... MERGE FREEZE IN MASTER

dave.enyeart (Thu, 12 Dec 2019 19:22:05 GMT):
v2.0.0-beta release PR: https://github.com/hyperledger/fabric/pull/406/files

dave.enyeart (Thu, 12 Dec 2019 20:03:27 GMT):
@here i've done a lot of force merging today.... but would ask for a NACR on the final beta release PR above.

dave.enyeart (Thu, 12 Dec 2019 20:04:06 GMT):
that is, if i've screwed the whole thing up today, i'd like to bring somebody else down with me

BrettLogan (Thu, 12 Dec 2019 20:04:49 GMT):
Thanks Chris!

dave.enyeart (Thu, 12 Dec 2019 20:05:37 GMT):
sucker

dave.enyeart (Thu, 12 Dec 2019 20:05:37 GMT):
merged

BrettLogan (Thu, 12 Dec 2019 20:45:07 GMT):
https://github.com/hyperledger/fabric/pull/409

BrettLogan (Thu, 12 Dec 2019 20:45:23 GMT):
One more +2 so we can get a merge when this is done in CI

BrettLogan (Thu, 12 Dec 2019 20:46:11 GMT):
bootstrap.sh won't work with the current release until this gets in

dave.enyeart (Thu, 12 Dec 2019 21:08:40 GMT):
merged

dave.enyeart (Thu, 12 Dec 2019 21:10:28 GMT):
fabric v2.0.0-beta release all good, tagged

dave.enyeart (Thu, 12 Dec 2019 21:10:46 GMT):
MERGE FREEZE LIFTED

dave.enyeart (Thu, 12 Dec 2019 21:11:09 GMT):
https://github.com/hyperledger/fabric/pull/411 Prepare for next release

guoger (Fri, 13 Dec 2019 04:03:04 GMT):
This commit should be able to fix the flakiness of release-1.4 branch: ``` commit 02d9adc86ff4a212a726baff3791a899482d8d78 Author: Will Lahti Date: Tue Feb 5 11:51:52 2019 -0500 Deliver can send multiple blocks when seeking newest When seeking just the newest block (i.e. starting and stopping at newest), there is a timing bug that can lead to more than one block being sent. This happens if a block is committed just after Deliver acquires a ledger iterator. The logic for newest would then set the stop number to the ledger height minus one, which has changed since the iterator logic evaluated the ledger height. FAB-14063 #done Change-Id: I34da107938980f2834def9ea6e3adac48c44dbaf Signed-off-by: Will Lahti ``` created https://github.com/hyperledger/fabric/pull/413 to cherry-pick. cc @wlahti

guoger (Fri, 13 Dec 2019 04:08:00 GMT):
a few more words on the flake - deliver server sends a `STATUS_SUCCESS` to client after sending blocks, which is flushed by client via an additional call to `Recv()`. However, if an extra block is sent by server, that flush call actually gets a `BLOCK`. When next request is sent by client on the same stream, it would get the leftover `STATUS` prior to the block expected, and fails the test

Hengming (Fri, 13 Dec 2019 04:08:29 GMT):
Great post for this year’s Mentorship Program. Thanks Hyperledger community! https://www.hyperledger.org/blog/2019/12/12/2019-summer-mentee-project-update-hyperledger-fabric-sdk-for-node-js-security-extension

guoger (Fri, 13 Dec 2019 04:08:33 GMT):
hopefully this cherry-pick would relieve the pain of rerunning 1.4 CI

BrettLogan (Fri, 13 Dec 2019 04:39:35 GMT):
https://github.com/hyperledger/fabric/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+391+413

BrettLogan (Fri, 13 Dec 2019 04:41:04 GMT):
To piggy back off that, these are the two cherry-pick fixes to address flakiness in 1.4. Jay's cherry pick failed on something Jason's attempts to address. Hopefully between the two of them it helps stabilize it

BrettLogan (Fri, 13 Dec 2019 04:42:19 GMT):
@guoger If you could review Jason's cherry-pick :)

BrettLogan (Fri, 13 Dec 2019 04:46:39 GMT):
I think both of these will help, master has been quite a bit less flaky since Jason got that change in. There is still an open flake in common/cluster that we are hitting (it has 3 open Jira's, and 6 closed ones that were meant to address it over the last year) frequently enough to be annoying

guoger (Fri, 13 Dec 2019 05:15:34 GMT):
@BrettLogan thx! right, i think both of them are addressing top 2 frequent flakes on release-1.4. I'll put them into single PR so we make CI green again :P

guoger (Fri, 13 Dec 2019 05:20:43 GMT):
actually... how can i do that? cherry-pick a commit to @jyellick 's PR

guoger (Fri, 13 Dec 2019 05:28:30 GMT):
anyway, cherry-picked to my PR: https://github.com/hyperledger/fabric/pull/413

guoger (Fri, 13 Dec 2019 05:28:46 GMT):
should I do `git push origin pull/xxx/head` ?

BrettLogan (Fri, 13 Dec 2019 05:29:18 GMT):
You would want to check Jasons out and then push to his branch

BrettLogan (Fri, 13 Dec 2019 05:30:03 GMT):
if you have `hub` installed its `hub fetch` `hub checkout ` `hub commit ` `hub push`

BrettLogan (Fri, 13 Dec 2019 05:30:03 GMT):
is you have `hub` installed its `hub fetch` `hub checkout

BrettLogan (Fri, 13 Dec 2019 05:30:03 GMT):
if you have `hub` installed its `hub fetch` `hub checkout

BrettLogan (Fri, 13 Dec 2019 05:30:03 GMT):
if you have `hub` installed its `hub fetch` `hub checkout ` `hub push`

guoger (Fri, 13 Dec 2019 05:30:33 GMT):
but i shouldn't have permission to push to the branch of Jason's repo, no?

BrettLogan (Fri, 13 Dec 2019 05:31:21 GMT):
You're a maintainer, by default they can, when you open a PR you have to explicitly disable that checkbox if you don't want maintainers to push to your branch

BrettLogan (Fri, 13 Dec 2019 05:32:41 GMT):

Clipboard - December 13, 2019 12:32 AM

BrettLogan (Fri, 13 Dec 2019 05:34:24 GMT):
You have to use your judgement, but its not quite as big of a deal as it was in gerrit. Since you can't chain PR's together like you chained CR's in gerrit, your push on top of it won't affect child PR's (because there is no such thing)

guoger (Fri, 13 Dec 2019 05:35:48 GMT):
that works! thank you

guoger (Fri, 13 Dec 2019 05:36:21 GMT):
closed mine

BrettLogan (Fri, 13 Dec 2019 05:37:44 GMT):
Awesome, thanks Jay, appreciate the help tracking this down. I am leaving on vacation next Tuesday, and the current state of CI flakes has me a little stressed

guoger (Fri, 13 Dec 2019 05:39:07 GMT):
sorry for bothering you at midnight :)

BrettLogan (Fri, 13 Dec 2019 06:46:15 GMT):
And you hit the only other flake 😂

guoger (Fri, 13 Dec 2019 07:51:47 GMT):
:joy: i think that test is actually completed, but teardown was failed...

guoger (Fri, 13 Dec 2019 07:57:17 GMT):
wait... it's actually the `peer chaincode instantiate` process that did not exit...

rjones (Fri, 13 Dec 2019 16:42:45 GMT):
https://github.com/hyperledger/fabric-rfcs/pulls there is no code owners for this repo, I'm not sure who that would be so I won't create one

dave.enyeart (Fri, 13 Dec 2019 19:03:02 GMT):
Since nobody raised a need for `Create a merge commit`, we've removed that option to help keep commit history clean. You can now choose `Rebase and merge` or `Squash and merge` (although it is recommended that the contributor squash their own commits if there is not a good reason to keep them separate)

dave.enyeart (Fri, 13 Dec 2019 19:03:02 GMT):
Since nobody raised a need for "Create a merge commit", we've removed that option to help keep commit history clean.

dave.enyeart (Fri, 13 Dec 2019 19:04:08 GMT):
You can now choose "Rebase and merge"

dave.enyeart (Fri, 13 Dec 2019 19:04:11 GMT):
or "Squash and merge" (although it is recommended that the contributor squash their own commits if there is not a good reason to keep them separate)

rjones (Fri, 13 Dec 2019 19:10:57 GMT):
did you roll this out over `*fabric*` or a subset?

dave.enyeart (Fri, 13 Dec 2019 19:11:45 GMT):
yes, all `*fabric*` are consistent now

dave.enyeart (Fri, 13 Dec 2019 19:11:45 GMT):
yes, all `*fabric*` are consistent now for these two merge options

rjones (Fri, 13 Dec 2019 19:13:20 GMT):
did you enable linear history?

dave.enyeart (Fri, 13 Dec 2019 19:13:31 GMT):
didnt touch that

rjones (Fri, 13 Dec 2019 19:13:55 GMT):
cool.

BrettLogan (Sun, 15 Dec 2019 14:45:17 GMT):
https://github.com/hyperledger/fabric/pull/391

BrettLogan (Sun, 15 Dec 2019 14:45:40 GMT):
Can we get a look at this, its a cherry-pick of two flake fixes from master into 1.4

mbwhite (Mon, 16 Dec 2019 08:50:20 GMT):
Hello - we've this JIRA https://jira.hyperledger.org/browse/FABCJ-128 to provide a cross chaincode test suite; primary purpose to ensure consistency in function, and also act as a reference for any new chaincode implementations. We'd like to create a new repo to hold this - as it's effectively a test tool. With the RFCs process in place - what are the thoughts if this will need an RFC - or we're happy to request a new repo on fabric-ci?

dave.enyeart (Mon, 16 Dec 2019 14:58:41 GMT):
@mbwhite fabric-test is the repository that has cross-repo tests... why not put it in there?

dave.enyeart (Mon, 16 Dec 2019 14:59:01 GMT):
I wouldn't think an RFC is needed for tests...

mbwhite (Mon, 16 Dec 2019 15:02:51 GMT):
We'll check into fabric-test thanks.

joe-alewine (Mon, 16 Dec 2019 15:18:20 GMT):
So despite the deprecation of Kafka and Solo support, the ordering service concept doc still mentions them: https://hyperledger-fabric.readthedocs.io/en/master/orderer/ordering_service.html Should we remove references to Solo and Kafka in master (2.0 beta, in other words) or mention them with the caveat they've been deprecated?

dave.enyeart (Mon, 16 Dec 2019 16:22:36 GMT):
@joe-alewine I'd keep them in for now, with a mention that they've been deprecated and that Raft is recommended.

dave.enyeart (Mon, 16 Dec 2019 16:23:18 GMT):
@here Here's a draft of the v2.0 Beta announcement that I'll send out... let me know in the next couple hours if you'd like any edits...

dave.enyeart (Mon, 16 Dec 2019 16:23:23 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the Fabric v2.0 Beta release. Since the time of the v2.0 Alpha release, the scope of the Fabric v2.0 release has changed. While decentralized chaincode governance is still a primary release theme, the native token functionality has been removed so that token features can be further evaluated for a potential future release. The ability to build and launch chaincode on the technology platform of your choice has been added, as well as private data enhancements and performance improvements. There is also a new test network to try out, and instructions for how to upgrade to the eventual v2.0 release. See details of these new features in the What's New documentation: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html In addition to core Fabric, the Fabric programming model SDKs have also been released for this beta, with the following versions; gateway-java: 2.0.0-SNAPSHOT and node-sdk: 2.0.0-beta.2. They both contain a simplified wallet structure, providing a pluggable persistent data format which is portable across the different language implementations. Finally, the java and node contract APIs have been updated to support LTS releases of Java 11 and Node.js 12, respectively. Please give the v2.0 Beta a try and let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). We expect to release version 2.0 early in 2020 after Beta feedback is evaluated. Note that the v1.4.x long term support release will continue to receive maintenance even after v2.0 is released so that current users will have time to evaluate their eventual upgrade to v2.0. Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Mon, 16 Dec 2019 16:23:23 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the Fabric v2.0 Beta release. Since the time of the v2.0 Alpha release, the scope of the Fabric v2.0 release has changed. While decentralized chaincode governance is still a primary release theme, the native token functionality has been removed so that token features can be further evaluated for a potential future release. The ability to build and launch chaincode on the technology platform of your choice has been added, as well as private data enhancements and performance improvements. There is also a new test network to try out, and instructions for how to upgrade to the eventual v2.0 release. See details of these new features and links to the release notes in the What's New documentation: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html In addition to core Fabric, the Fabric programming model SDKs have also been released for this beta, with the following versions; gateway-java: 2.0.0-SNAPSHOT and node-sdk: 2.0.0-beta.2. They both contain a simplified wallet structure, providing a pluggable persistent data format which is portable across the different language implementations. Finally, the java and node contract APIs have been updated to support LTS releases of Java 11 and Node.js 12, respectively. Please give the v2.0 Beta a try and let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). We expect to release version 2.0 early in 2020 after Beta feedback is evaluated. Note that the v1.4.x long term support release will continue to receive maintenance even after v2.0 is released so that current users will have time to evaluate their eventual upgrade to v2.0. Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Mon, 16 Dec 2019 16:23:23 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the Fabric v2.0 Beta release. Initially introduced in the Fabric v2.0 Alpha, the new decentralized chaincode governance remains a primary release theme. The Beta brings a few other significant additions to Fabric - the ability to build and launch chaincode on the technology platform of your choice has been added, as well as private data enhancements and performance improvements. There is also a new test network to try out in the fabric-samples repository, and instructions for how to upgrade to the eventual v2.0 release. Note that the native token prototype that was available in the v2.0 Alpha release has been removed so that token features can be further evaluated for a potential future release. See details of these new features and links to the release notes in the What's New documentation: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html In addition to core Fabric, the Fabric programming model SDKs have also been released for this beta, with the following versions; gateway-java: 2.0.0-SNAPSHOT and node-sdk: 2.0.0-beta.2. They both contain a simplified wallet structure, providing a pluggable persistent data format which is portable across the different language implementations. Finally, the java and node contract APIs have been updated to support LTS releases of Java 11 and Node.js 12, respectively. Please give the v2.0 Beta a try and let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). We expect to release version 2.0 early in 2020 after Beta feedback is evaluated. Note that the v1.4.x long term support release will continue to receive maintenance even after v2.0 is released so that current users will have time to evaluate their eventual upgrade to v2.0. Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Mon, 16 Dec 2019 16:23:23 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the Fabric v2.0 Beta release. Initially introduced in the Fabric v2.0 Alpha, the new decentralized chaincode governance remains a primary release theme. The Beta also brings a few other significant additions to Fabric - the ability to build and launch chaincode on the technology platform of your choice has been added, as well as private data enhancements and performance improvements. There is also a new test network to try out in the fabric-samples repository, and instructions for how to upgrade to the eventual v2.0 release. Note that the native token prototype that was available in the v2.0 Alpha release has been removed so that token features can be further evaluated for a potential future release. See details of these new features and links to the release notes in the What's New documentation: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html In addition to core Fabric, the Fabric programming model SDKs have also been released for this beta, with the following versions; gateway-java: 2.0.0-SNAPSHOT and node-sdk: 2.0.0-beta.2. They both contain a simplified wallet structure, providing a pluggable persistent data format which is portable across the different language implementations. Finally, the java and node contract APIs have been updated to support LTS releases of Java 11 and Node.js 12, respectively. Please give the v2.0 Beta a try and let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). We expect to release version 2.0 early in 2020 after Beta feedback is evaluated. Note that the v1.4.x long term support release will continue to receive maintenance even after v2.0 is released so that current users will have time to evaluate their eventual upgrade to v2.0. Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Mon, 16 Dec 2019 16:23:23 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the Fabric v2.0 Beta release. Initially introduced in the Fabric v2.0 Alpha, the new decentralized chaincode governance remains a primary release theme. The Beta also brings a few other significant additions to Fabric - the ability to build and launch chaincode on the technology platform of your choice has been added, as well as private data enhancements and performance improvements. There is also a new test network to try out in the fabric-samples repository, and instructions for how to upgrade to the eventual v2.0 release. Note that the native token prototype that was available in the v2.0 Alpha release has been removed so that token features can be further evaluated for a potential future release. See details of these new features and links to the release notes in the What's New documentation: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html In addition to core Fabric, the Fabric programming model SDKs have also been released for this beta, with the following versions; gateway-java: 2.0.0-SNAPSHOT and node-sdk: 2.0.0-beta.2. They both contain a simplified wallet structure, providing a pluggable persistent data format which is portable across the different language implementations. Finally, the java and node contract APIs have been updated to support LTS releases of Java 11 and Node.js 12, respectively. Please give the v2.0 Beta a try and let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). We expect to release version 2.0 early in 2020 after Beta feedback is evaluated. Note that the v1.4.x long term support release will continue to receive maintenance and bug fixes even after v2.0 is released so that current users will have time to evaluate their eventual upgrade to v2.0. Thank you, The Hyperledger Fabric maintainers```

dave.enyeart (Mon, 16 Dec 2019 16:23:23 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of the Fabric v2.0 Beta release! Initially introduced in the Fabric v2.0 Alpha, the new decentralized chaincode governance remains a primary release theme. The Beta also brings a few other significant additions to Fabric - the ability to build and launch chaincode on the technology platform of your choice has been added, as well as private data enhancements and performance improvements. There is also a new test network to try out in the fabric-samples repository, and instructions for how to upgrade to the eventual v2.0 release. Note that the native token prototype that was available in the v2.0 Alpha release has been removed so that token features can be further evaluated for a potential future release. See details of these new features and links to the release notes in the What's New documentation: https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html Download instructions: https://hyperledger-fabric.readthedocs.io/en/latest/install.html In addition to core Fabric, the Fabric programming model SDKs have also been released for this beta, with the following versions; gateway-java: 2.0.0-SNAPSHOT and node-sdk: 2.0.0-beta.2. They both contain a simplified wallet structure, providing a pluggable persistent data format which is portable across the different language implementations. Finally, the java and node contract APIs have been updated to support LTS releases of Java 11 and Node.js 12, respectively. Please give the v2.0 Beta a try and let us know what you think! Contact us via this Hyperledger Fabric mailing list ( https://lists.hyperledger.org/g/fabric ) or RocketChat ( https://chat.hyperledger.org/ ) should you have any feedback or questions. We will also be watching for any issues reported to Hyperledger JIRA ( https://jira.hyperledger.org/ ). We expect to release version 2.0 early in 2020 after Beta feedback is evaluated. Note that the v1.4.x long term support release will continue to receive maintenance and bug fixes even after v2.0 is released so that current users will have time to evaluate their eventual upgrade to v2.0. Thank you, The Hyperledger Fabric maintainers```

tsharris (Mon, 16 Dec 2019 16:27:49 GMT):
Has joined the channel.

mastersingh24 (Mon, 16 Dec 2019 16:42:57 GMT):
I'm ok with this ... although I think it would be better to move the token stuff to somewhere later in the statement ... you want to kick things off with what we have not what we don't

dave.enyeart (Mon, 16 Dec 2019 16:55:40 GMT):
makes sense, edited above

muralisr (Mon, 16 Dec 2019 16:55:41 GMT):
Also ` While decentralized chaincode governance is still a primary release theme, the native token functionality has been removed so that token features can be further evaluated for a potential future release.` seems tying token and decentralized chaincode governance together ... not sure if that was intended

dave.enyeart (Mon, 16 Dec 2019 16:55:50 GMT):
addressed

joe-alewine (Mon, 16 Dec 2019 17:33:53 GMT):
@dave.enyeart Ok pushed here: https://github.com/hyperledger/fabric/pull/425/

dave.enyeart (Mon, 16 Dec 2019 19:47:18 GMT):
Release announcement sent!

dave.enyeart (Mon, 16 Dec 2019 19:47:18 GMT):
Release announcement sent! https://lists.hyperledger.org/g/fabric/message/7427

mbwhite (Mon, 16 Dec 2019 19:48:46 GMT):
💯

guoger (Tue, 17 Dec 2019 02:23:48 GMT):
posted in #fabric-orderer-dev but would appreciate some inputs from others as well: https://chat.hyperledger.org/channel/fabric-orderer-dev?msg=mrMYZ6G3sXEiLGJMF

HLFPOC (Tue, 17 Dec 2019 05:01:55 GMT):
Hi Team, I am not able to find balance-transfer app in fabric-samples of v2.0 beta. Is it removed ? Is there is any other sample app which explains the use of new features (specifically interested in chaincode lifecycle feature) using node sdk?

BrettLogan (Tue, 17 Dec 2019 06:21:40 GMT):
@guoger I added some debug statements around the `Eventually` which lead me to the problem. The issue ended up being we are deploying the 3 chaincodes in parallel which is stressing the cpu and essentially deadlocking the process. I was able to recreate the problem by deploying it to a VM with 2CPU/4GB. I pushed a PR to change deploying the chaincode to a serial process instead. Doing it serially only adds about 15 seconds to the test, presumably because the processor isn't under such heavy load

BrettLogan (Tue, 17 Dec 2019 06:21:40 GMT):
@guoger I added some debug statements around the eventually which let me to the problem. The issue ended up being we are deploying the 3 chaincodes in parallel which is stressing the cpu and essentially deadlocking the process. I was able to recreate the problem by deploying it to a VM with 2CPU/4GB. I pushed a change to change deploying the chaincode to a serial process instead. Doing it serially only adds about 15 seconds to the test, presumably because the processor isn't under heavy load

BrettLogan (Tue, 17 Dec 2019 06:21:40 GMT):
@guoger I added some debug statements around the eventually which lead me to the problem. The issue ended up being we are deploying the 3 chaincodes in parallel which is stressing the cpu and essentially deadlocking the process. I was able to recreate the problem by deploying it to a VM with 2CPU/4GB. I pushed a change to change deploying the chaincode to a serial process instead. Doing it serially only adds about 15 seconds to the test, presumably because the processor isn't under heavy load

BrettLogan (Tue, 17 Dec 2019 06:21:40 GMT):
@guoger I added some debug statements around the eventually which lead me to the problem. The issue ended up being we are deploying the 3 chaincodes in parallel which is stressing the cpu and essentially deadlocking the process. I was able to recreate the problem by deploying it to a VM with 2CPU/4GB. I pushed a PR to change deploying the chaincode to a serial process instead. Doing it serially only adds about 15 seconds to the test, presumably because the processor isn't under heavy load

BrettLogan (Tue, 17 Dec 2019 06:21:40 GMT):
@guoger I added some debug statements around the eventually which lead me to the problem. The issue ended up being we are deploying the 3 chaincodes in parallel which is stressing the cpu and essentially deadlocking the process. I was able to recreate the problem by deploying it to a VM with 2CPU/4GB. I pushed a PR to change deploying the chaincode to a serial process instead. Doing it serially only adds about 15 seconds to the test, presumably because the processor isn't under such heavy load

BrettLogan (Tue, 17 Dec 2019 06:21:56 GMT):
https://github.com/hyperledger/fabric/pull/426

guoger (Tue, 17 Dec 2019 06:33:41 GMT):
looks reasonable, though i wonder why did CI seem to complete tests successfully

BrettLogan (Tue, 17 Dec 2019 06:36:01 GMT):
I think its because we defer the `GinkgoRecover()` which tells ginkgo the test fails, but allow it to succeed. We shouldn't have used it as we use the --keepGoing flag

BrettLogan (Tue, 17 Dec 2019 06:36:01 GMT):
I think its because we defer the `GinkgoRecover()` which tells ginkgo the test fails, but allow it to "succeed". We shouldn't have used it as we use the --keepGoing flag

BrettLogan (Tue, 17 Dec 2019 06:36:01 GMT):
I think its because we defer the `GinkgoRecover()`. It looks like a collision between using GinkgoRecover and the fact we use the `--keepGoing` flag when we invoke Ginkgo

BrettLogan (Tue, 17 Dec 2019 06:36:01 GMT):
I think its because we defer the `GinkgoRecover()` which tells ginkgo the test fails, but allow it to "succeed". It looks like a collision between using GinkgoRecover and the fact we use the `--keepGoing` flag when we invoke Ginkgo

BrettLogan (Tue, 17 Dec 2019 06:36:36 GMT):
So even on a true failure, we do a ginkgorecover

guoger (Tue, 17 Dec 2019 06:38:51 GMT):
i was expecting the test to explicitly fail when we assert on the invocations on chiancodes?

guoger (Tue, 17 Dec 2019 06:40:56 GMT):
that test seemed to run till the last step (`deployChaincode` returned), however we did have a `wg.Wait()`. This was the point that puzzled me..

guoger (Tue, 17 Dec 2019 06:42:06 GMT):
(not saying your solution doesn't work :P obviously you reprodeced it and solved it there), just trying to understand it better

BrettLogan (Tue, 17 Dec 2019 06:58:03 GMT):
I see what you're saying now, I missed the part that the test actually ran to full completion

BrettLogan (Tue, 17 Dec 2019 06:59:29 GMT):
And of course, the integrations passed on the first try, but I hit the one outstanding Unit test flake we have :grin:

BrettLogan (Tue, 17 Dec 2019 06:59:29 GMT):
And of course, the integrations finally passed, but I hit the one outstanding Unit test flake we have lol

BrettLogan (Tue, 17 Dec 2019 06:59:29 GMT):
And of course, the integrations finally passed, but I hit the one outstanding Unit test flake we have :grin:

guoger (Tue, 17 Dec 2019 07:14:26 GMT):
actually, is history ci output visible somewhere?

BrettLogan (Tue, 17 Dec 2019 07:15:15 GMT):
It is. If you go to your run, you can see previous attempts

BrettLogan (Tue, 17 Dec 2019 07:16:17 GMT):
https://dev.azure.com/Hyperledger/Fabric/_build/results?buildId=3847&view=logs&jobId=4c66e10c-0fd8-5a92-dd62-668e591d0491

BrettLogan (Tue, 17 Dec 2019 07:16:35 GMT):
On this page, scroll down in the left tab to "Previous Attempts"

guoger (Tue, 17 Dec 2019 07:17:56 GMT):
gotcha, thx!

knagware9 (Tue, 17 Dec 2019 09:13:55 GMT):
yes,, its removed. You can refer commercial sample app now

HLFPOC (Tue, 17 Dec 2019 10:27:13 GMT):
Thanks, but I am not able to see any commands related to chaincode lifecycle in this sample. Is it updated as per v2.0 beta changes ?

knagware9 (Tue, 17 Dec 2019 11:31:01 GMT):
In 2.0 Beta test-network has cli node ? I cant see any CLI container running & even not in docker-compose file. Read the docs have instruction to use cli to commuicate with peer node using cli. Can someone please confirm about this

knagware9 (Tue, 17 Dec 2019 11:33:39 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#install-define-chaincode

yacovm (Tue, 17 Dec 2019 11:33:40 GMT):
@BrettLogan In jenkins on LF VMs it always worked fine for a year. Is AZP running on RPi or something

yacovm (Tue, 17 Dec 2019 11:33:50 GMT):
?

knagware9 (Tue, 17 Dec 2019 11:34:04 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/commands/peerlifecycle.html

BrettLogan (Tue, 17 Dec 2019 15:01:39 GMT):
I mean its running on a system with 2CPU/8GB. I had absolutely no problem invoking the problem on an AWS VM of the same specs (using dedicated hardware, not shared). Our old hardwaree was 4cores/16GB (which we will get back to next year when they introduce scale sets). But to be fair, we did hit this problem, there are at least 3 Jiras that were opened for this test in the last year

BrettLogan (Tue, 17 Dec 2019 15:03:33 GMT):
I'm sure we just did what we always did, ignore it and type `Run UnitTest`, now people are being forced to actually look at things and solve them because of the hardware, and the fact its not as simple to retrigger runs

BrettLogan (Tue, 17 Dec 2019 15:03:33 GMT):
I'm sure we hit the problem more frequently, we just did what we always did, ignore it and type `Run UnitTest`, now people are being forced to actually look at things and solve them because of the hardware, and the fact its not as simple to retrigger runs

yacovm (Tue, 17 Dec 2019 15:45:46 GMT):
@BrettLogan , Isn't 2 cores with 8GB of RAM a bit low? :/

BrettLogan (Tue, 17 Dec 2019 15:59:31 GMT):
Imo, yes, which is why tests take a little longer than in Jenkins, but we were able to get around that by splitting the tests. That is the only system available to us right now, and it's the only option for dynamic nodes, otherwise we would have to use static nodes and maintain them. Early next year they are adding support for Azure Scale Sets to bring your own dynamic nodes. So we will be able to use that then to choose our own size nodes. @yacovm

yacovm (Tue, 17 Dec 2019 15:59:54 GMT):
cool

BrettLogan (Tue, 17 Dec 2019 16:01:27 GMT):
https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/design/byos.md

HLFPOC (Tue, 17 Dec 2019 16:09:55 GMT):
but these commands are executed through CLI, do we have any sample app which executes chaincode lifecycle commands using Node SDK? @BrettLogan

BrettLogan (Tue, 17 Dec 2019 16:14:33 GMT):
The new lifecycle isnt supported yet in the SDKs, watch the mailing list for an announcement regarding it's availability

BrettLogan (Tue, 17 Dec 2019 16:14:58 GMT):
They are working to make an announcement about it

HLFPOC (Tue, 17 Dec 2019 16:15:15 GMT):
Sure, thanks for informing

heatherp (Tue, 17 Dec 2019 16:27:26 GMT):
Regarding support for the new chaincode lifecycle and the java/node SDKs: For node, we are in the process of separating out admin capabilities, into a new fabric-admin package, which will support the new chaincode lifecycle feature. We’re tracking this work under https://jira.hyperledger.org/browse/FABN-1416. The 2.0 java-sdk supports the new chaincode lifecycle feature in the Fabric v2.0-beta.

negupta (Tue, 17 Dec 2019 21:23:51 GMT):
Has joined the channel.

negupta (Tue, 17 Dec 2019 21:23:53 GMT):
Hey @knagware9 You can use the peer CLI to communicate with the peer without the tools container. You can see more info here: https://hyperledger-fabric.readthedocs.io/en/latest/test_network.html#interacting-with-the-network

BrettLogan (Wed, 18 Dec 2019 05:51:18 GMT):
I am going to be out on vacation starting today until January 6th. I will be in Russia, so I will not be entirely glued to RocketChat like I normally am all hours of the night. I think we’ve done all we can to stabilize CI and flakes. I ask that any flakes you encounter moving forward, please start opening Jira’s again so we can triage and get the right resources on it. I will finish the Nexus to Artifactory migration in the coming days, so maintainers, please look out for those changes. If your builds are failing, please comment `/ci-run` to retrigger the builds. Let’s get through the holidays and then look forward to fine-tuning and polishing CI on the other side of the new year.

knagware9 (Wed, 18 Dec 2019 06:16:38 GMT):
okay let me try

atirekg (Wed, 18 Dec 2019 10:23:13 GMT):
Has joined the channel.

andreevym (Wed, 25 Dec 2019 17:41:17 GMT):
Has joined the channel.

konda.kalyan (Thu, 26 Dec 2019 06:00:18 GMT):
Has joined the channel.

Rajatsharma (Thu, 02 Jan 2020 17:48:27 GMT):
I wanted to use discovery service on a multi-host network(which we're using for production). But I wanted to run the node service in such a way, that even if I don't run the service in the same docker swarm, all the request go through. So I had looked the way people normally use fabric discovery : ``` await channel.initialize({discover:true, asLocalhost:true}) ``` I can't use it this as `asLocalhost`, replaces the hostname with localhost. Moreover, even if the port for peer is not mapped at 7051 the code does not work. So ideally I was looking for a way to map the returning hostname and port, with one in configuration. I looked inside the code https://github.com/hyperledger/fabric-sdk-node/blob/v1.4.4/fabric-client/lib/Channel.js#L253, I found out that if we're using service discovery there's no flag or a way to change the url mapping. So using fabric's service discovery with multi-host network is not possible ?

dave.enyeart (Thu, 02 Jan 2020 19:08:28 GMT):
@Rajatsharma This channel is for Fabric maintainer discussion. Please direct usage questions to #fabric-questions or SDK specific questions to #fabric-sdk-node , or use fabric mailing list.

Rajatsharma (Thu, 02 Jan 2020 19:16:01 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=7tGX3JjeFu4E4mAAt) @ I thought this was really important. That's why I had messaged this here. Anyways I've removed this. Thanks for your suggestion !!

rjones (Thu, 02 Jan 2020 19:39:18 GMT):
the channel #fabric-questions would be better for this discussion

guoger (Mon, 06 Jan 2020 03:28:25 GMT):
do we plan to auto close inactive PRs after certain period of time? (or it's already the case?)

BrettLogan (Mon, 06 Jan 2020 04:27:12 GMT):
During migration I think Stalebot was disabled, so it's a question of if we should reenable it and what settings do we want to use (how long until a stale notification is sent, and how long until autoclose)

dave.enyeart (Mon, 06 Jan 2020 12:33:48 GMT):
We have agreed to and documented an aging policy: https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#pr-aging-policy

dave.enyeart (Mon, 06 Jan 2020 12:34:23 GMT):
So yeah, now that we are migrated, I think we could simply configure stale bot for 14 days until stale, and 14 more days until auto-close

dave.enyeart (Mon, 06 Jan 2020 12:34:47 GMT):
It looks like any PR comment will make it un-stale again.

dave.enyeart (Mon, 06 Jan 2020 12:35:30 GMT):
So I think the biggest open question is whether to configure some kind of nagging for reviews... anybody know if there are bots for that?

yacovm (Mon, 06 Jan 2020 13:26:29 GMT):
nag maintainers or nag PR owners?

dave.enyeart (Mon, 06 Jan 2020 14:25:06 GMT):
PR owners would be nagged by the stale bot automatically... I'm talking about whether we want to nag maintainers about the outstanding PRs...

dave.enyeart (Mon, 06 Jan 2020 14:27:10 GMT):
With the move to single +2, one thing I suggested was that anybody could add named 'Assignees' to a PR to indicate a review request... that could be enough nagging for maintainers...

dave.enyeart (Mon, 06 Jan 2020 14:28:06 GMT):
To be honest, with all maintainers on the Reviewers list, I get more emails than I can monitor.

dave.enyeart (Mon, 06 Jan 2020 14:28:06 GMT):
To be honest, with all maintainers on the 'Reviewers' list for every PR automatically, I get more emails than I can monitor.

dave.enyeart (Mon, 06 Jan 2020 14:29:25 GMT):
Thoughts?

dave.enyeart (Mon, 06 Jan 2020 15:34:55 GMT):
@rjones Hi Ry, we've noticed that the Fabric maintainer lists have been refactored in GitHub... could you keep us informed of your objectives, what's been done, what remains?

yacovm (Mon, 06 Jan 2020 15:50:59 GMT):
I recall he just removed the gerrit nicknames

rjones (Mon, 06 Jan 2020 18:33:25 GMT):
pretty much. I was tasked with removing references to Gerrit. On a couple of the lists, they had pointers to missing documentation. On a couple, they weren't in alpha order.

sykesm (Mon, 06 Jan 2020 21:22:16 GMT):
I talked with Ry earlier. A number of sub-groups were added to the fabric maintainers group. That resulted in us losing the "core" group. That's been addressed by adding a new group. Tomorrow I'll go through the repositories and update the CODEOWNERS as appropriate to use the correct group(s). If done correctly, nothing will break; if not, just yell at me.

rjones (Mon, 06 Jan 2020 21:30:32 GMT):
I also went and changed the pending requests to only update the maintainers file itself

rjones (Mon, 06 Jan 2020 22:03:39 GMT):
@sykesm I think I have a fix that won't involve a lot of effort.

rjones (Mon, 06 Jan 2020 22:05:51 GMT):
basically, move the teams under the existing "maintainers" group over to the "contributors" group.

rjones (Mon, 06 Jan 2020 22:06:24 GMT):
then the pointer to fabric-maintainers and fabric-core-maintainers becomes moot until another cleanup pass

dave.enyeart (Tue, 07 Jan 2020 04:54:23 GMT):
Several of us have discussed that the requirement for 'majority of maintainers' is too high a burden for an RFC to enter final comment period. Also it was unclear which Fabric repositories should be considered when determining the majority. Here's a PR proposing to change the language from 'majority' to at least three interested maintainers. This is just for entrance into the final comment period week. Any maintainer or community member may still raise objectives during final comment period, so the intent here is to simply lower a process bar, not to lower the bar on general consensus around RFCs. Please indicate your approval or concerns within the PR: https://github.com/hyperledger/fabric-rfcs/pull/17

dave.enyeart (Tue, 07 Jan 2020 04:54:23 GMT):
Several of us have discussed that the requirement for 'majority of maintainers' is too high a burden for an RFC to enter final comment period. Also it was unclear which Fabric repositories should be considered when determining the majority. Here's a PR proposing to change the language from 'majority' to at least three interested maintainers. This is just for entrance into the final comment period week. Any maintainer or community member may still raise objections during final comment period, so the intent here is to simply lower a process bar, not to lower the bar on general consensus around RFCs. Please indicate your approval or concerns within the PR: https://github.com/hyperledger/fabric-rfcs/pull/17

mbwhite (Tue, 07 Jan 2020 15:22:52 GMT):
On the subject of RFCs - could I propose the gh-pages support RFC I put up goes into 'final review please'

mbwhite (Tue, 07 Jan 2020 15:22:53 GMT):
https://github.com/hyperledger/fabric-rfcs/pull/15

dave.enyeart (Tue, 07 Jan 2020 18:19:21 GMT):
@mbwhite since it is essentially a metadata change to fabric-rfcs, rather than a change to a fabric repo, I don't think it needs to go through formal RFC process. I commented in the PR:

dave.enyeart (Tue, 07 Jan 2020 18:19:27 GMT):
I'm happy to get this merged, review the usage experience, and then tweak as needed. A sample of the experience would be found at: https://mbwhite.github.io/fabric-rfcs/

dave.enyeart (Tue, 07 Jan 2020 18:22:49 GMT):
Also, does anybody know why there is a 0000-template.md at root of fabric-rfcs, as well as a text/0000-dummy.md file? They seem to have same content...

dexhunter (Wed, 08 Jan 2020 02:03:58 GMT):
Has joined the channel.

mrudav.shukla (Wed, 08 Jan 2020 05:56:27 GMT):
Has joined the channel.

mbwhite (Wed, 08 Jan 2020 09:23:17 GMT):
I wondered the same thing about the template files..

dave.enyeart (Wed, 08 Jan 2020 13:53:51 GMT):
@here contributor meeting at the top of the hour: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 08 Jan 2020 13:54:00 GMT):
Agenda items below... anything else? Release update CI and SCM update Maintainer housekeeping topics - release-2.0 branch - release cadence and LTS - fabric-rfcs - Process for merging doc content

ZainabM (Thu, 09 Jan 2020 11:51:06 GMT):
Has joined the channel.

Silona (Thu, 09 Jan 2020 20:17:50 GMT):
Last chance! The Linux Foundation worked with Hyperledger Fabric Developer subject matter expert volunteers to identify the core domains and competencies for the Certified Hyperledger Fabric Developer (CHFD) exam, scheduled to launch in March 2020. Are you interested in participating in the Beta and receiving an early peek? The CHFD Beta is FREE for the first 100 who take the exam. Complete the CHFD Beta Sign-up Form by January 15, 2020 for your chance. If you pass you will be CHFD Certified!

mbwhite (Fri, 10 Jan 2020 11:11:27 GMT):
Announce: the gh-pages fabric-rfc PR has been merged... the site URL is https://hyperledger.github.io/fabric-rfcs Hope is provide cleaner way to read and search RFCs. @rjones could you modify the description of the repo to include the docs url please?

dave.enyeart (Fri, 10 Jan 2020 14:11:55 GMT):
Done!

dave.enyeart (Fri, 10 Jan 2020 14:12:51 GMT):
Update to RFC maintainer language merged!

rjones (Fri, 10 Jan 2020 15:42:25 GMT):
Thank you, Dave

yacovm (Mon, 13 Jan 2020 17:15:17 GMT):
fabric-protos repository has only a master branch, yet we are about to release v2.0 and then v2.1 How does that work with protobuf changes that should go into v2.1 but not into v2.0 ? :thinking: I want to merge https://github.com/hyperledger/fabric-protos/pull/23 into the only branch in fabric-protos and this change only adds boolean fields to a discovery message, so it should be safe to merge even if someone updated v2.0 branch with the protobuf. Should I wait for v2.0 to be released, or can we merge it into the `fabric-protos` under the assumption that we won't update the master branch of fabric until v2.0 is cut with new protobufs ?

sykesm (Mon, 13 Jan 2020 17:22:40 GMT):
Proto changes should always be forward and backwards compatible. To help consumers determine the "right" version, I expect we'll tag the commit we consume in fabric proper for each of the minor releases. If we need branches in protos, we can do it, but I don't think it really adds much and may make incompatible changes more likely. Instead of aggressively creatnig branches here, I'd like to defer that until we need it. If I'm wrong (and I may be), it seems fixable.

medikent (Mon, 13 Jan 2020 18:29:23 GMT):
I am definitely interested in this.

medikent (Mon, 13 Jan 2020 18:30:28 GMT):
Where is the beta sign up form?

medikent (Mon, 13 Jan 2020 18:36:43 GMT):
Found it. Thanks!

heatherp (Tue, 14 Jan 2020 13:04:25 GMT):
Just to repeat the mailing list announcements I sent out this morning, I'm requesting we enter the final comment period for both the Ledger-api and Programming Model Go SDK updates RFCs. I'm proposing that they are merged in a week. We're looking for any final comments, objections, or even support :), from other fabric maintainers. Programming Model Updates for Go SDK RFC: https://github.com/hyperledger/fabric-rfcs/pull/14, contact @andrew-coleman Ledger api RFC: https://github.com/hyperledger/fabric-rfcs/pull/16, contact @mbwhite

Silona (Tue, 14 Jan 2020 16:49:51 GMT):
Help Us Help you! Attend the Developer Relationship Meeting with Myself and our Marketing Dept. tomorrow at 9:00am Pacific Time. For the agenda and Dial in info https://wiki.hyperledger.org/display/Marketing/2020-01-15+Meeting+notes

Silona (Tue, 14 Jan 2020 17:01:16 GMT):
Calling all Projects! We will have a special Kiosk setup at Hyperledger Global Forum for Projects. We are asking that all projects sign up to do 10 minute presentations. https://wiki.hyperledger.org/display/HGF/Projects+Kiosk We will close this page on Feb 28 for printing reasons.

YashShukla (Wed, 15 Jan 2020 02:28:23 GMT):
Has joined the channel.

YashShukla (Wed, 15 Jan 2020 02:33:29 GMT):
Is there any Inbuilt solution to this Three organizations A, B, and C are on the same channel. All 3 organizations perform a transaction with a value x. There is a chaincode that chooses the organization whose value of x is the highest and declares it as a winner. All the organizations are the endorsers to keep the system decentralized. The problem is that the organizations will be able to see what the value x of other organizations and input there value accordingly. Is there any solution to it, which allows every organization to see other organization's input x only after the winner is declared while keeping the system decentralized with trust? and want it to do everything in 100 ms (real-time).

awjh (Wed, 15 Jan 2020 09:45:55 GMT):
Hi, I am looking to resolve https://jira.hyperledger.org/browse/FAB-17382 which is around the creation of an NPM module which chaincode implementations e.g. fabric-chaincode-java would import as part of their azure test runs and run as a CLI. It will provide a standardised set of integration tests so we can know that all our chaincode implementations work as expected and remove duplicate workload of creating an integration test setup for each of the chaincode implementations (node, java and go + future languages). It had been suggested that the best location for this would be to put it in the fabric-test repo however having looked at that repo it seems that there is not a natural place to put it as the repo is structured to be one large testing tool and this would be a seperate package requiring its own release cycle. It also seems to function in the inverse of how fabric-test is used which seems itself to take in repos at a certain level rather than have the other repos take it in. It would be great to have maintainers' opinions on the best course of action for resolving this JIRA and getting the tool ready. If it should go in the fabric-test repo where is the best place for it, or should it have its own repository?

heatherp (Wed, 15 Jan 2020 09:54:39 GMT):
@BrettLogan @scottz would appreciate your thoughts, this was what I was poorly articulating on the squad leads calls on Monday :)

dave.enyeart (Wed, 15 Jan 2020 10:26:15 GMT):
@YashShukla With a trusted 3rd party to run the auction, you can have a private data collection between each organization and the 3rd party. Each org would submit their bid to their pairwise collection (and perhaps also to the 3rd party's own collection to ease the bid evaluation). 3rd party would name the winner in a subsequent transaction and mention the winning bid. The other parties can compare the winning bid to the hash from the winning orgs collection, to verify that they really placed the bid before the auction ended. For more details about these types of solutions see https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data. Without a trusted 3rd party to run the auction, there may be truly decentralized options using homomorphic encryption in the chaincode. But please, keep this channel reserved for maintainer topics. Follow-on questions should use a different channel or Fabric mailing list.

dave.enyeart (Wed, 15 Jan 2020 10:26:15 GMT):
@YashShukla With a trusted 3rd party to run the auction, you can have a private data collection between each organization and the 3rd party. Each org would submit their bid to their pairwise collection (and perhaps also to the 3rd party's own collection to ease the bid evaluation). 3rd party would name the winner in a subsequent transaction and mention the winning bid. The other parties can compare the winning bid to the hash from the winning orgs collection, to verify that they really placed the bid before the auction ended. For more details about these types of solutions see https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data. Without a trusted 3rd party to run the auction, there may be truly decentralized options using homomorphic encryption in the chaincode to find the maximum of the encrypted public bids. But please, keep this channel reserved for maintainer topics. Follow-on questions should use a different channel or Fabric mailing list.

dave.enyeart (Wed, 15 Jan 2020 10:26:15 GMT):
@YashShukla With a trusted 3rd party to run the auction, you can have a private data collection between each organization and the 3rd party. Each org would submit their bid to their pairwise collection (and perhaps also to the 3rd party's own collection to ease the bid evaluation). 3rd party would name the winner in a subsequent transaction and mention the winning bid. The other parties can compare the winning bid to the hash from the winning orgs collection, to verify that they really placed the bid before the auction ended. For more details about these types of solutions see https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data. But please, keep this channel reserved for maintainer topics. Follow-on questions should use a different channel or Fabric mailing list.

YashShukla (Wed, 15 Jan 2020 10:32:28 GMT):
Thank you so much. Thanks.

YashShukla (Wed, 15 Jan 2020 10:41:05 GMT):
Hey Dave, thanks for the answer. I just wanted to know that according to you which will be the best way to make it completely decentralized i.e every one will be able to see each other's bid without a trusted 3rd party. while keeping it a real-time system (under 50ms)

dave.enyeart (Wed, 15 Jan 2020 10:42:30 GMT):
I asked for you to please use the mailing list rather than fabric-maintainers channel: https://lists.hyperledger.org/g/fabric

BrettLogan (Wed, 15 Jan 2020 14:37:37 GMT):
Let me talk to Dave on this one

rjones (Wed, 15 Jan 2020 17:11:48 GMT):
Repos are free. If you need another one just to publish to NPM, we could do that

rjones (Wed, 15 Jan 2020 17:12:08 GMT):
like the fabric-photos and fabric-photos-go setup

scottz (Wed, 15 Jan 2020 21:57:00 GMT):
We use fabric-test to house tools and tests, and import the images and things to be tested from various fabric family project repositories. It is a great place for a tool to exist that can run an acceptance test, for example to run a standard test scenario using different versions of fabric, or a chaincode written in different languages. We recently removed some outdated or maintenance-heavy tools, and focus on using go and ginkgo to drive some test suites - which explains where there are not a lot of tools there anymore - but anyone can certainly add a new tool under the fabric-test/tools/ directory. It so far is not a place to store artifacts or libraries to be used elsewhere. I suppose if you are planning to copy or import it to a selection of other repos and just run it, then it might make sense to put here.

dave.enyeart (Wed, 15 Jan 2020 22:01:29 GMT):
More comprehensive response provided on mailing list: https://lists.hyperledger.org/g/fabric/message/7554

awjh (Thu, 16 Jan 2020 10:05:36 GMT):
Seems like it suits being put in that test folder, we can then either have the other repos clone it in and use it or work out a process for publishing the tool to NPM when needed.

heatherp (Thu, 16 Jan 2020 13:03:17 GMT):
I've created a jira board to track the sdk/chaincode backlogs and I'm looking to create sprints, but I don't have permissions to do so: "You need the Manage Sprints permission for all projects in the origin board to create a sprint. Learn more". Can someone help me out with permissions. The projects I'm interested in tracking are: Chaincode Java, Chaincode Node, Contract API Go, Gateway Java, SDK Java, SDK Node and SDK Go. Thanks

heatherp (Thu, 16 Jan 2020 13:03:17 GMT):
I've created a jira board to track the sdk/chaincode backlogs and I'm looking to create sprints, but I don't have permissions to do so: "You need the Manage Sprints permission for all projects in the origin board to create a sprint. Learn more". Can someone help me out with permissions? The projects I'm interested in tracking are: Chaincode Java, Chaincode Node, Contract API Go, Gateway Java, SDK Java, SDK Node and SDK Go. Thanks

dave.enyeart (Thu, 16 Jan 2020 14:46:17 GMT):
@heatherp , @rjones can likely help, although the official answer is to open a ticket at https://jira.linuxfoundation.org/servicedesk/customer/portals . The

rjones (Thu, 16 Jan 2020 15:33:54 GMT):
give me a bit

rjones (Thu, 16 Jan 2020 15:41:25 GMT):

roles.png

rjones (Thu, 16 Jan 2020 15:45:23 GMT):
@dave.enyeart (and maintainers in general): do more admin-type functions need delegated in JIRA? When I was adding @heatherp to the "Maintainer" role for those projects, I noticed many of them only have one other person with any admin capabilities

dave.enyeart (Thu, 16 Jan 2020 16:07:52 GMT):
@rjones I'd be happy to an admin on all Fabric* projects, if you can make that happen

rjones (Thu, 16 Jan 2020 16:17:33 GMT):
Done

medikent (Thu, 16 Jan 2020 21:30:44 GMT):
I just scheduled my exam for Saturday. What do you recommend I study? I've written Go and Java chaincode (in Kotlin) and connected to Fabric with both the Go and Java SDKs. I've installed, instantiated, and upgraded chaincode as well as read through the majority of the documentation on Hyperledger Fabric.

medikent (Thu, 16 Jan 2020 21:30:55 GMT):
I'm thinking I might be ok though I'd like to fill in the missing gaps.

medikent (Thu, 16 Jan 2020 22:09:40 GMT):
How far along is the Idemix ZKP imeplementation in Fabric? I'd like to help it along.

medikent (Thu, 16 Jan 2020 22:11:18 GMT):
Who would I work with to help along the Idemix implementation? I'd like to help with Revocation

medikent (Thu, 16 Jan 2020 22:11:44 GMT):
I'd also like to help with the Idemix Peer endorsement implementation.

mbwhite (Fri, 17 Jan 2020 10:34:51 GMT):
Just for the avoidance of doubt; when the 2.0.0 GA is released will the tag 'latest' for docker images be mapped to the 2.0 or the 1.4 LTS images?

dave.enyeart (Fri, 17 Jan 2020 11:46:32 GMT):
@mbwhite This issue first came up when we did the 2.0.0-alpha back in April. At that time there was general agreement that `latest` tag in docker hub caused too much confusion, and we decided to stop using it as of v2.0.

dave.enyeart (Fri, 17 Jan 2020 11:47:05 GMT):
So, we will not tag v2.0 as latest, not now, nor when v2.x becomes LTS.

dave.enyeart (Fri, 17 Jan 2020 11:48:14 GMT):
We will likely remove the existing `latest` tag on v1.4.x images sometime before v2.x goes LTS

dave.enyeart (Fri, 17 Jan 2020 11:48:14 GMT):
We will likely remove the existing `latest` tag on v1.4.x images sometime before v2.x goes LTS, to avoid all confusion

dave.enyeart (Fri, 17 Jan 2020 11:49:40 GMT):
So the next question is what to do with the `latest` tag for chaincode images in core.yaml: https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L510-L519

dave.enyeart (Fri, 17 Jan 2020 11:50:57 GMT):
My opinion is that users should not rely on automatic dockerhub pulling. Rather, they should pull the exact version they want, which gets tagged locally as `latest`

dave.enyeart (Fri, 17 Jan 2020 11:50:57 GMT):
My opinion is that users should not rely on automatic dockerhub pulling. Rather, they should pull the exact version they want (bootstrap.sh script automatically pulls javaenv and nodeenv tag matching the requested fabric version, e.g. 2.0.0) , which then gets tagged locally as `latest` after the pull.

dave.enyeart (Fri, 17 Jan 2020 11:52:35 GMT):
Therefore, I think the core.yaml entries can remain as-is. And we should document that users should update them to point to the exact javaenv and nodeenv tags that they want to use. I think you took a todo to document this at one point.

dave.enyeart (Fri, 17 Jan 2020 11:52:49 GMT):
What do you think?

mbwhite (Fri, 17 Jan 2020 12:46:59 GMT):
@dave.enyeart ... first impression is that I'm good with that approach. npm module tags only have official meaning for 'latest' - so wanted to follow the same definition of latest.. 1.4 or 2. But if the docker isn't being tagged, then I suspect we'll tag 2 with latest, maybe an lts tag for 1.4

dave.enyeart (Fri, 17 Jan 2020 15:19:39 GMT):
Also related to tagging... we tag each x.y.z release in docker hub also as x.y, e.g. 1.4.4 and 1.4 tags point to the same thing. SDK team requested this so that SDK tests could pull 1.4 and always get the latest. I wasn't thrilled with the x.y tag. Is it sill needed/useful @BrettLogan @heatherp ?

dave.enyeart (Fri, 17 Jan 2020 15:20:21 GMT):
Specifically, the 2.0 tag created for fabric-ca 2.0.0-alpha is very misleading, and minimally that one should be deleted since we won't deliver fabric-ca 2.0

sstone1 (Fri, 17 Jan 2020 15:28:42 GMT):
@dave.enyeart I can't answer the needed/useful question, but why are you opposed to the x.y tag? Lots of projects on Docker Hub publish tags like this, e.g. Node.js (https://hub.docker.com/_/node/) publishes x, x.y, and x.y.z tags

dave.enyeart (Fri, 17 Jan 2020 15:29:30 GMT):
ok, if it is well trod pattern i guess it's ok, it just seems that it would cause confusion between 1.4.0 and 1.4

BrettLogan (Fri, 17 Jan 2020 15:30:17 GMT):
I agree with Simon, is a very common pattern that 1.4 would mean the latest 1.4.x image

dave.enyeart (Fri, 17 Jan 2020 15:30:46 GMT):
ok, are we at least in agreement that fabric-ca 2.0 tag should be deleted at this point?

sstone1 (Fri, 17 Jan 2020 15:31:10 GMT):
yeah if there's no 2.0.0 release of the CA then the 2.0 tag doesn't make sense

sstone1 (Fri, 17 Jan 2020 15:31:33 GMT):
I do think that having a mix of Fabric versions (1.4 for CA, 2.0 for everything else) is a bit confusing but I'm guessing that discussion has already occurred?

dave.enyeart (Fri, 17 Jan 2020 15:32:15 GMT):
yes, it was discussed on contributor call last week... the consensus was that having a v2.0 fabric ca release with no changes since v1.4.4 would be even more confusing.

BrettLogan (Fri, 17 Jan 2020 15:33:05 GMT):
Do you want to have it removed now Dave? It doesn't make sense to leave it around if we arent releasing 2.0 CA

dave.enyeart (Fri, 17 Jan 2020 15:33:23 GMT):
I say delete fabric ca 2.0 tag now

dave.enyeart (Fri, 17 Jan 2020 15:33:23 GMT):
I say delete fabric ca 2.0 tag next week

dave.enyeart (Fri, 17 Jan 2020 15:34:27 GMT):
If the removal will break any test pipelines (e.g. sdk integration tests), speak up today!

heatherp (Fri, 17 Jan 2020 15:56:26 GMT):
I was gonna mention this next monday but we discussed on scrum today that in line with this, we won't do a fabric-ca-client v2.0.0 release, which is one of the modules fabric-sdk-node publishes

bestbeforetoday (Fri, 17 Jan 2020 18:18:50 GMT):
I think this will break the Node and Java SDK master branch builds where they pull down v2 Docker images for all the Fabric components. It's too late in the day for me to change those builds now

dave.enyeart (Mon, 20 Jan 2020 04:42:57 GMT):
As we approach v2.0 release the week of Jan. 27th, we need to use some extra caution when merging PRs. As such I've created `release-2.0` branch in fabric and fabric-chaincode-go. PRs should continue to be opened against `master` branch, and then upon merge to master, consider whether you'd like to cherry pick to `release-2.0` to get the commit into v2.0.

dave.enyeart (Mon, 20 Jan 2020 04:48:31 GMT):
The cherry pick decision should be based on a conversation between the PR owner and maintainer that merges the PR (if both sides take the responsibility to follow up, there is less chance for a missed cherry pick).

kostas (Mon, 20 Jan 2020 23:31:29 GMT):
Who owns the fabric-rfcs repo?

BrettLogan (Mon, 20 Jan 2020 23:59:29 GMT):
The Linux Foundation

BrettLogan (Mon, 20 Jan 2020 23:59:29 GMT):
The Linux Foundation, why?

kostas (Tue, 21 Jan 2020 00:05:17 GMT):
Touché. Let me rephrase: who's got administrator rights on that repo?

BrettLogan (Tue, 21 Jan 2020 00:06:45 GMT):
I wasn't being smart, Chris owned the original iteration. What are you looking to do to it, I would assume Chris, Gari and Dave have admin privileges on it, but that assumes Ry added the fabric admins team to the repo.

BrettLogan (Tue, 21 Jan 2020 00:07:31 GMT):
And not all functionality is available to them, so assuming it's in the scope of their permissions they could can do it

rjones (Tue, 21 Jan 2020 01:05:10 GMT):
This team has maintain: https://github.com/orgs/hyperledger/teams/fabric-release-maintainers/members

rjones (Tue, 21 Jan 2020 01:05:32 GMT):
This team has admin: https://github.com/orgs/hyperledger/teams/fabric-admins/members

sykesm (Tue, 21 Jan 2020 20:00:29 GMT):
I'd suggest reaching out to @aso or @adc for pointers.

dave.enyeart (Tue, 21 Jan 2020 21:32:46 GMT):
For commits merged into master that we want in release-2.0, instead of the cherry pick approach, submitter can simply open PR in fabric and choose their fork and feature branch as the source, like this:

dave.enyeart (Tue, 21 Jan 2020 21:32:50 GMT):

Clipboard - January 21, 2020 4:32 PM

dave.enyeart (Tue, 21 Jan 2020 21:33:23 GMT):
@wlahti you've got two that were merged today that should go to release-2.0

heatherp (Wed, 22 Jan 2020 09:50:07 GMT):
Do we have any thoughts on how we can better track what commits should go into what branches? I've definitely had zero fun finding closed jiras and missing commits in branches they were needed in

yacovm (Wed, 22 Jan 2020 11:31:36 GMT):
I think it's easier to look at the `git log` than to look in JIRA. As for "what commits should go into what branches" - usually, if it's a bug fix it's backported, if it's an easy and trivial usability enhancement like a logging message improvement, it is also backported. other stuff usually don't.

heatherp (Wed, 22 Jan 2020 12:05:31 GMT):
I understand the process for when we should backport, but currently we're relying on people to remember to do it. I'd prefer an automated process that doesn't rely on people remembering, because it's caused me pain the past. I don't have a solution though

BrettLogan (Wed, 22 Jan 2020 12:25:09 GMT):
I'm not sure about a fully automated solution, but, there are a number of bots out there that can do a cherry pick for you. So a maintainer, while doing review on a PR, can simply comment `/cherry-pick release-2.0` and it will add a `cherry-pick-release-2-0` label to the PR, then when the original PR is closed, it will open a PR for you against the 2.0 branch. This would lower the effort to get a cherry-pick in and take the oneous off any one person (the original commiter) to remember to cherry pick their change

BrettLogan (Wed, 22 Jan 2020 12:25:09 GMT):
I'm not sure about a fully automated solution, but, there are a number of bots out there that can do a cherry pick for you. So a maintainer, while doing review on a PR, can simply comment `/cherry-pick release-2.0` and it will open a PR for you against the 2.0 branch. This would lower the effort to get a cherry-pick in and take the oneous off the any one person (the original commuter) to remember to cherry pick their change

BrettLogan (Wed, 22 Jan 2020 12:25:09 GMT):
I'm not sure about a fully automated solution, but, there are a number of bots out there that can do a cherry pick for you. So a maintainer, while doing review on a PR, can simply comment `/cherry-pick release-2.0` and it will open a PR for you against the 2.0 branch. This would lower the effort to get a cherry-pick in and take the oneous off any one person (the original commuter) to remember to cherry pick their change

BrettLogan (Wed, 22 Jan 2020 12:25:09 GMT):
I'm not sure about a fully automated solution, but, there are a number of bots out there that can do a cherry pick for you. So a maintainer, while doing review on a PR, can simply comment `/cherry-pick release-2.0` and it will open a PR for you against the 2.0 branch. This would lower the effort to get a cherry-pick in and take the oneous off any one person (the original commiter) to remember to cherry pick their change

BrettLogan (Wed, 22 Jan 2020 12:27:52 GMT):
The bots can even be configured to not generate the PR until the merge of the source PR happens, so you are certain you have the final revision of the code

BrettLogan (Wed, 22 Jan 2020 12:52:26 GMT):
This does have DCO implications now that I think about it

BrettLogan (Wed, 22 Jan 2020 13:49:43 GMT):
With some afterthought, this does not solve the problem we were trying to avoid, we still need to cherry pick, as we can see in Will's PR it presents the same problem

dave.enyeart (Wed, 22 Jan 2020 13:53:10 GMT):
Contributor meeting agenda for today... anything else?

dave.enyeart (Wed, 22 Jan 2020 13:53:10 GMT):
@here Contributor meeting agenda for today... anything else?

dave.enyeart (Wed, 22 Jan 2020 13:53:55 GMT):
Release update Release cadence and LTS Process for merging doc content Deep dive: Decentralized application patterns in Fabric v2.0

dave.enyeart (Wed, 22 Jan 2020 13:54:27 GMT):
https://zoom.us/my/hyperledger.community.3

BrettLogan (Wed, 22 Jan 2020 15:04:08 GMT):
FYI: Jira is undergoing maintenance at the moment, should be up within the hour

rjones (Wed, 22 Jan 2020 16:53:59 GMT):
I argue cherry picking is better than merging since you are explicitly bringing in that one commit

dave.enyeart (Fri, 24 Jan 2020 20:31:22 GMT):
I haven't heard any dissent on the 'doc maintainer' proposal... if you agree please add your 'endorsement' to https://github.com/hyperledger/fabric/pull/526 so that we can get the process moving

rjones (Fri, 24 Jan 2020 20:33:02 GMT):
I've added the `mergify` tool per request from @BrettLogan , so once 526 is in, a small bit of yaml and `mergify` will be there for you

rjones (Tue, 28 Jan 2020 00:07:00 GMT):
`fabric-core-doc-maintainers` added and has rights to repo: https://github.com/orgs/hyperledger/teams/fabric-core-doc-maintainers/repositories

rjones (Tue, 28 Jan 2020 00:07:00 GMT):
`fabric-core-doc-maintainers` populated, added, and has rights to repo: https://github.com/orgs/hyperledger/teams/fabric-core-doc-maintainers/repositories

awjh (Tue, 28 Jan 2020 10:07:08 GMT):
@BrettLogan Any ideas why this would be happening for tool/chaincode-integration in fabric-test? It says cannot merge as it never gets a result from the base fabric-test CI. Example: https://github.com/hyperledger/fabric-test/pull/66

BrettLogan (Tue, 28 Jan 2020 12:59:00 GMT):
I'm working on that. I need to finish setting up mergify which will handle it for you. I did merge the change for you

awjh (Tue, 28 Jan 2020 13:00:35 GMT):
I saw that, thanks :)

medikent (Tue, 28 Jan 2020 14:23:15 GMT):
I did not pass. The exam was somewhat surprising. Is there a way I could give it another go?

medikent (Tue, 28 Jan 2020 14:26:45 GMT):
Who are @aso and @adc?

awjh (Tue, 28 Jan 2020 14:48:23 GMT):
@BrettLogan Do you have any recomendations around how I could setup a deployment pipeline for the chaincode-integration test tool? Other fabric projects I've worked on use the github release and tagging process but since this will be a pipeline just for one part rather than releasing everything I am unsure on how we could target just that folder?

awjh (Tue, 28 Jan 2020 14:48:23 GMT):
@BrettLogan Do you have any recomendations around how I could setup a deployment pipeline for the chaincode test tool? Other fabric projects I've worked on use the github release and tagging process but since this will be a pipeline just for one part rather than releasing everything I am unsure on how we could target just that folder?

BrettLogan (Tue, 28 Jan 2020 15:09:38 GMT):
What artifacts come out of this? An NPM module? Anything else?

BrettLogan (Tue, 28 Jan 2020 15:10:22 GMT):
Also, how often do you intend to release the artifacts, on every merge, or only when you are ready to release

awjh (Tue, 28 Jan 2020 15:11:12 GMT):
Just an npm module, just want to get it published to npm. Ideally we would have it publish an unstable on each merge to chaincode-integration and also release a specific version when we are ready

BrettLogan (Tue, 28 Jan 2020 15:13:04 GMT):
So for the unstable, obviously we can put that in the regular pipeline. For the release version Fabric and Fabric-CA have a separate release pipeline which we trigger manually

BrettLogan (Tue, 28 Jan 2020 15:13:50 GMT):
Which is trivial to do

awjh (Tue, 28 Jan 2020 15:14:07 GMT):
Okay cool :) How do they do that?

awjh (Tue, 28 Jan 2020 15:14:22 GMT):
Is it via PRs or a github tag?

awjh (Tue, 28 Jan 2020 15:14:25 GMT):
Something else?

BrettLogan (Tue, 28 Jan 2020 15:16:06 GMT):
You can do it via the Azure Pipelines UI. We just need to grant permission to the tool Maintainers to trigger the pipeline. And then it's just click one button

awjh (Tue, 28 Jan 2020 15:19:33 GMT):
Guess thats just a config in the YAML to make it release on that button then? And that'll use NPM credentials from azure

BrettLogan (Tue, 28 Jan 2020 15:22:12 GMT):
https://github.com/hyperledger/fabric/blob/master/ci/azure-pipelines-release.yml

BrettLogan (Tue, 28 Jan 2020 15:22:25 GMT):
Actually, you need only specify:

BrettLogan (Tue, 28 Jan 2020 15:22:28 GMT):
```trigger: none pr: none```

BrettLogan (Tue, 28 Jan 2020 15:22:42 GMT):
So it wont run on merge or PR

BrettLogan (Tue, 28 Jan 2020 15:23:06 GMT):
And then when we enable the pipeline we restrict access to who can run it

BrettLogan (Tue, 28 Jan 2020 15:23:06 GMT):
And then when we restrict access to who can run it

awjh (Tue, 28 Jan 2020 15:23:48 GMT):
Nice thanks :)

awjh (Tue, 28 Jan 2020 15:38:51 GMT):
I assume the script will need to access the NPM credentials, are these already existent in the azure-pipeline env for fabric-test or will these needed to be added also

BrettLogan (Tue, 28 Jan 2020 15:43:45 GMT):
I gave fabric-test the same access and credentials fabric-sdk-node has to NPM

BrettLogan (Tue, 28 Jan 2020 15:43:52 GMT):
So you should be able to follow their model

awjh (Tue, 28 Jan 2020 15:46:29 GMT):
Cool thanks a lot

BrettLogan (Tue, 28 Jan 2020 15:48:37 GMT):
Though I would much prefer we use the simplified service connection model: https://docs.microsoft.com/en-us/azure/devops/pipelines/artifacts/npm?view=azure-devops&tabs=yaml

BrettLogan (Tue, 28 Jan 2020 15:50:09 GMT):
In this one you just set the working directory as the root of the project (which needs a .npmrc file pointing to npmjs.org) and then you just call that task

awjh (Tue, 28 Jan 2020 15:51:01 GMT):
:thumbsup:

BrettLogan (Tue, 28 Jan 2020 15:55:03 GMT):
So theoretically, that would just look like this:

BrettLogan (Tue, 28 Jan 2020 15:55:05 GMT):
```- task: Npm@1 inputs: command: publish workingDir: $(Agent.BuildDirectory)/tools/chaincode-integration publishEndpoint: 'npm'```

BrettLogan (Tue, 28 Jan 2020 15:55:35 GMT):
Everything is configured for that to work as well

awjh (Tue, 28 Jan 2020 15:55:59 GMT):
Awesome!

dave.enyeart (Wed, 29 Jan 2020 14:13:32 GMT):
@here I'm preparing for fabric v2.0 release... please limit changes in release-2.0.0 to those truly required. This morning I'm working on some final doc and release note updates, e.g. https://github.com/hyperledger/fabric/pull/588 . Then we'll tag and cut release this afternoon.

dave.enyeart (Wed, 29 Jan 2020 14:13:32 GMT):
@here I'm preparing for fabric v2.0 release... please limit changes in release-2.0 to those truly required. This morning I'm working on some final doc and release note updates, e.g. https://github.com/hyperledger/fabric/pull/588 . Then we'll tag and cut release this afternoon.

dave.enyeart (Wed, 29 Jan 2020 17:40:51 GMT):
ok, i believe this is the second to last PR for the release, needed on master and release-2.0: https://github.com/hyperledger/fabric/pull/594

dave.enyeart (Wed, 29 Jan 2020 17:46:02 GMT):
the final PR will be to increment the release number and tweak release notes in release-2.0

dave.enyeart (Wed, 29 Jan 2020 17:46:27 GMT):
any other final changes needed?

baohua (Wed, 29 Jan 2020 18:34:12 GMT):
@dave.enyeart Add one comment on suggesting to have a fabric ca v2.0.0 release, too, instead of using v1.4.4.

baohua (Wed, 29 Jan 2020 18:34:12 GMT):
@dave.enyeart Add one comment on suggesting to have a fabric ca v2.0.0 release, too, instead of using v1.4.4. Thanks!

dave.enyeart (Wed, 29 Jan 2020 18:57:31 GMT):
Thanks Baohua, understand the concern, however in prior contributor meeting the maintainers decided not to keep releasing Fabric CA concurrently, as we don't expect changes each quarter.

dave.enyeart (Wed, 29 Jan 2020 18:58:04 GMT):
@here I've extended the release notes and switched to md format. Please take a look and comment if you think anything else needs to be mentioned. https://github.com/hyperledger/fabric/pull/595

dave.enyeart (Wed, 29 Jan 2020 22:55:23 GMT):
Fabric v2.0 release is now available. There will be a series of announcements tomorrow, including blog and mailing list.

JonathanLevi (Wed, 29 Jan 2020 22:56:27 GMT):
:woo: :fabric: :woo:

awjh (Thu, 30 Jan 2020 10:22:11 GMT):
Is there a plan to release fabric-chaincode-go?

awjh (Thu, 30 Jan 2020 10:22:54 GMT):
Or is the plan people will just use the latest master rather than a git tagged version?

awjh (Thu, 30 Jan 2020 10:43:58 GMT):
Likewise with fabric-protos-go

dave.enyeart (Thu, 30 Jan 2020 13:46:25 GMT):
At this point, there is no intent to create a release branch in these repos. There is intent to use a tag so that people know which commit level has been tested with a given Fabric release, but they should be able to use latest master. If there comes a time that we need to support/maintain a specific version of these libraries, we can always create a release branch at that time.

dave.enyeart (Thu, 30 Jan 2020 13:47:15 GMT):
In terms of the actual tag that we use, I'm open to ideas. I believe @sykesm mentioned to use version 0.x format, rather than align with Fabric version

awjh (Thu, 30 Jan 2020 13:48:44 GMT):
Okay thanks, I ask as I am looking to release fabric-contract-api-go at some point so was looking to pin down a version in the go.mod file. I shall wait until the tags have occurred and people can use master of that module as well for now

dave.enyeart (Thu, 30 Jan 2020 13:58:34 GMT):
The Hyperledger blog post is live: https://www.hyperledger.org/blog/2020/01/30/welcome-hyperledger-fabric-2-0:-enterprise-dlt-for-production

dave.enyeart (Thu, 30 Jan 2020 13:59:05 GMT):
I'll send the mailing list announcement out in a bit, but in case other maintainers want to review the message, here's a draft: https://docs.google.com/document/d/1-RwBEe2NdhLO13CmW2ljUNC5t3WPE475-m2R9MobLvA/edit?usp=sharing

dave.enyeart (Thu, 30 Jan 2020 14:56:30 GMT):
Announcement sent to mailing list: https://lists.hyperledger.org/g/fabric/message/7662

rjones (Thu, 30 Jan 2020 15:13:57 GMT):
https://old.reddit.com/r/hyperledger/comments/ew6uj5/announcement_email_hyperledger_fabric_v20_is_now/

medikent (Thu, 30 Jan 2020 17:38:22 GMT):
I imagine there is room for a lot of supporting documentation, examples, tutorials, and guides to assist with the transition to 2.0. What is the best way to contribute to that?

baohua (Thu, 30 Jan 2020 18:32:31 GMT):
Interested to see whether it is possible to upgrade HLF v1.4 to v2.0.0, certainly with Raft consensus.

pandrejko (Thu, 30 Jan 2020 21:46:45 GMT):
Upgrade documentation is here: https://hyperledger-fabric.readthedocs.io/en/release-2.0/upgrade.html We welcome your contributions!

pandrejko (Thu, 30 Jan 2020 21:46:45 GMT):
@medikent Upgrade documentation is here: https://hyperledger-fabric.readthedocs.io/en/release-2.0/upgrade.html We welcome your contributions!

dave.enyeart (Fri, 31 Jan 2020 15:57:31 GMT):
In addition to upgrade, it would be good to get more eyes on the new test network sample and doc.

dave.enyeart (Fri, 31 Jan 2020 15:57:31 GMT):
In addition to upgrade, it would be good to get more eyes on the new test network sample and doc. Does it work for you? Is it clear? Are there gaps that you'd like to plug?

dave.enyeart (Fri, 31 Jan 2020 15:58:37 GMT):
See upgrade info starting here https://hyperledger-fabric.readthedocs.io/en/release-2.0/whatsnew.html#upgrading-to-fabric-v2-0

dave.enyeart (Fri, 31 Jan 2020 16:00:26 GMT):
@BrettLogan @rjones With Gerrit gone, can you remind us where to find the historical review info?

rjones (Fri, 31 Jan 2020 16:03:14 GMT):
@dave.enyeart https://github.com/hyperledger-gerrit-archive

sykesm (Fri, 31 Jan 2020 16:03:23 GMT):
For versioning of the go items, I'm recommending we avoid using a vXXX tag or label because of the implication to the go tooling. While we want to avoid incompatible changes, if we go with a vXXX tag, the tools will assume we're using proper semver. (I don't think we're quite there yet.) Stepping back even further, I initially said that I didn't think we needed branches cut and I think that was hasty. I believe it makes sense to have a release-2.0 and master branch for fabric-chaincode-go, fabric-protos, and fabric-protos-go. While we still want changes to be versioned, it will be nicer for consumers to depend on a branch associated with their target instead of pinning to commits.

BrettLogan (Fri, 31 Jan 2020 16:03:49 GMT):
https://github.com/btl5037/fabric-gerrit I'm not sure if we ever moved it to the hyperledger or, but this is it

BrettLogan (Fri, 31 Jan 2020 16:04:58 GMT):
https://github.com/btl5037/fabric-gerrit I'm not sure if we ever moved it to the hyperledger or, but this is it

sykesm (Fri, 31 Jan 2020 16:05:41 GMT):
You might say I was wrong; others would say that my thinking has evolved...

rjones (Fri, 31 Jan 2020 16:06:40 GMT):
I unarchived https://github.com/hyperledger-gerrit-archive/hyperledger-gerrit-export if you want to do a PR or a github pages thing

rjones (Fri, 31 Jan 2020 16:09:09 GMT):
added you as an admin.

BrettLogan (Fri, 31 Jan 2020 16:23:47 GMT):
Thank you, I'll open a PR to add the content to it

dave.enyeart (Fri, 31 Jan 2020 16:31:02 GMT):
Ok, maybe I'm just slow... the btl5037 link holds the review histories (it should really be moved to a hyperledger project rather than btl5037). What does Ry's link hold?

rjones (Fri, 31 Jan 2020 16:34:12 GMT):
My link is the data Brett's link is based on

BrettLogan (Fri, 31 Jan 2020 16:34:14 GMT):
Ry's is the export of the data, which I then used to generate the markdown files. I need to migrate my markdown to his repo so the raw data and the markdown are next to each other and in a hyperledger repo

rjones (Fri, 31 Jan 2020 16:35:00 GMT):
everything is hiding in the git repos on Gerrit-named branches. Brett's code exposes it in a nicer way

dave.enyeart (Fri, 31 Jan 2020 16:36:19 GMT):
got it. yeah, being next to each other, and having logical names, would really help!

rjones (Fri, 31 Jan 2020 16:37:12 GMT):
Brett: if you want to make a new repo over there, that just has one commit, that's fine.

rjones (Fri, 31 Jan 2020 16:39:18 GMT):
OK. You're all org owners now. Please tread lightly :)

medikent (Fri, 31 Jan 2020 16:47:05 GMT):
I see. I'll start by taking a look at the test network.

davidkhala (Wed, 05 Feb 2020 03:55:36 GMT):
A question after review the 20200122 contributor meeting video record. In Transaction2 diagram, how could OrgA client know the content inside colB about AgreeToBuy? Does it mean the new `Implicit Collecion` feature can index `Asset1` across collections automatically?

dave.enyeart (Wed, 05 Feb 2020 05:37:16 GMT):
test

dave.enyeart (Wed, 05 Feb 2020 05:38:37 GMT):
@davidkhala Various options. Often times the transactors will agree on details out of band first, and then just settle the transaction on chain. If you want all the communication done on chain, then B can allow A to query on B's peer, or B can write the agreement to both B and A private collections. For a description of options, see https://hyperledger-fabric.readthedocs.io/en/release-2.0/private-data/private-data.html#private-data-sharing-patterns

dave.enyeart (Wed, 05 Feb 2020 05:39:20 GMT):
for some reason, i couldn't reply in thread...

dave.enyeart (Wed, 05 Feb 2020 05:39:20 GMT):
for some reason, i couldn't reply in thread...400 error

dave.enyeart (Wed, 05 Feb 2020 13:59:43 GMT):
@here contributor meeting starting https://zoom.us/my/hyperledger.community.3

mauricio (Wed, 05 Feb 2020 14:01:06 GMT):
Has joined the channel.

awjh (Fri, 07 Feb 2020 11:06:59 GMT):
I remember with gerrit I could issue commands to make builds rebuild by adding a comment on the CR, is there something similar with github and azure?

BrettLogan (Fri, 07 Feb 2020 13:31:14 GMT):
/azp run

CarlitoIBM (Mon, 10 Feb 2020 14:27:41 GMT):
Has joined the channel.

dave.enyeart (Tue, 11 Feb 2020 16:34:24 GMT):
@BrettLogan reminder to move the gerrit markdown archive to hyperledger... multiple people have said they can't find the link... e.g @Senthil1

BrettLogan (Tue, 11 Feb 2020 16:35:41 GMT):
Thanks, I'll do it now @dave.enyeart

dave.enyeart (Tue, 11 Feb 2020 21:37:16 GMT):
After about three years I thought it was time to add dockerhub information for our images :)

dave.enyeart (Tue, 11 Feb 2020 21:37:24 GMT):
See the Overview section at https://hub.docker.com/r/hyperledger/fabric-peer

dave.enyeart (Tue, 11 Feb 2020 21:37:51 GMT):
I've also pushed a PR to manage this content going forward: https://github.com/hyperledger/fabric/pull/662

dave.enyeart (Tue, 11 Feb 2020 21:38:12 GMT):
Please provide your feedback in the PR and I'll make any edits, then apply it to the other images as well.

dave.enyeart (Tue, 11 Feb 2020 21:38:51 GMT):
I'm also promoting the pattern of providing a core.yaml file to the container, rather than passing in a hundred environment variables :)

rjones (Tue, 11 Feb 2020 21:56:17 GMT):
@dave.enyeart I added two comments that I don't feel super strong about.

dave.enyeart (Tue, 11 Feb 2020 22:11:25 GMT):
Anybody know why the existing fabric samples mount volume `- /var/run/:/host/var/run/` ?

dave.enyeart (Tue, 11 Feb 2020 22:11:29 GMT):
https://github.com/hyperledger/fabric-samples/blob/master/test-network/docker/docker-compose-e2e.yaml#L127

dave.enyeart (Tue, 11 Feb 2020 22:12:08 GMT):
I did not include that mount in the new docker instructions... didnt seem necessary

MHBauer (Tue, 11 Feb 2020 22:12:11 GMT):
talk to docker socket?

BrettLogan (Tue, 11 Feb 2020 22:40:14 GMT):
I believe Morgan is correct, its so the peer can make use of the hosts docker socket

dave.enyeart (Tue, 11 Feb 2020 22:42:48 GMT):
ok, i'll add it

BrettLogan (Tue, 11 Feb 2020 22:46:23 GMT):
I don't know why they mount all of `/var/run` across though, the only thing needed is docker.sock `-v /var/run/docker.sock:/var/run/docker.sock`

BrettLogan (Tue, 11 Feb 2020 22:46:23 GMT):
I don't know why they mount the whole thing across though, the correct volume is `-v /var/run/docker.sock:/var/run/docker.sock`

BrettLogan (Tue, 11 Feb 2020 22:46:23 GMT):
I don't know why they mount the whole `/var/run` across though, the correct volume is `-v /var/run/docker.sock:/var/run/docker.sock`

BrettLogan (Tue, 11 Feb 2020 22:46:23 GMT):
I don't know why they mount the whole `/var/run` across though, the only thing needed is docker.sock `-v /var/run/docker.sock:/var/run/docker.sock`

BrettLogan (Tue, 11 Feb 2020 22:47:55 GMT):
That would also make it explicit for people to what is being mounted, instead of it being magic

MHBauer (Tue, 11 Feb 2020 22:59:53 GMT):
docker is literally the only thing I know about, and I've seen it enough to be my first guess. no idea if it's correct.

negupta (Wed, 12 Feb 2020 03:11:47 GMT):
I tried running the test network while mounting only docker.sock - I hit an error when trying to commit the chaincode definition

negupta (Wed, 12 Feb 2020 03:12:21 GMT):
Error: failed to retrieve endorser client for commit: endorser client failed to connect to localhost:9051: failed to create new connection: context deadline exceeded

BrettLogan (Wed, 12 Feb 2020 03:54:26 GMT):
Did you mount it to `/var/run/docker.sock` or `/host/var/run/docker.sock`? Wondering, as I noticed they were mounting it to /host

BrettLogan (Wed, 12 Feb 2020 03:54:26 GMT):
Did you mount it to /var/run/docker.sock or /host/var/run/docker.sock? Wondering, as I noticed they were mounting it to /host

BrettLogan (Wed, 12 Feb 2020 03:59:11 GMT):
Some quick googling, it looks like it looks for it in /host when a client connects to the socket

negupta (Wed, 12 Feb 2020 14:16:52 GMT):
I mounted ` - /var/run/docker.sock:/host/var/run/docker.sock`

KartikChauhan (Thu, 13 Feb 2020 11:36:19 GMT):
Hello All, Does Fabric supports chinese letters in enrollment id during enrollment? I tried to register & enroll a user with the name 苏南 on Fabric-CA. The registration is getting successful but getting below error ``` error: [FabricCAClientService.js]: Failed to enroll 苏南, error:%o message=Enrollment failed with errors [[{"code":0,"message":"asn1: invalid UTF-8 string"}]], stack=Error: Enrollment failed with errors [[{"code":0,"message":"asn1: invalid UTF-8 string"}]] ``` The error clearly says that the letters are not supported in UTF-8 encoding. Can I change the default encoding while enrolling? If yes, which enoding scheme do I've to use to support chinese letters?

Silona (Thu, 13 Feb 2020 18:23:48 GMT):
Howdy Contributors and Maintainers! Are you wondering about tapping into Developer marketing for your group or project? Do you have a blog post idea? An awesome announcement? Please attend our Contributor/marketing meeting! https://wiki.hyperledger.org/display/Marketing/2020-02-19+Meeting+notes

ZainabM (Fri, 14 Feb 2020 06:06:44 GMT):
Can we create channels dynamically? I mean we create channel.tx file using cryptogen tool first which is a manual process. Can we do it using SDK?

ZainabM (Fri, 14 Feb 2020 06:06:44 GMT):
Can we create channels dynamically? I mean we create channel.tx file using cryptogen tool first which is a manual process. Can we do it using SDK? Any other idea is also welcome.

ZainabM (Fri, 14 Feb 2020 06:06:44 GMT):
Can we create channels dynamically? I mean we create channel.tx file using configtxgen tool first which is a manual process. Can we do it using SDK? Any other idea is also welcome.

japidei (Fri, 14 Feb 2020 07:32:57 GMT):
Has joined the channel.

Satoshi24 (Fri, 14 Feb 2020 07:47:18 GMT):
Has joined the channel.

dave.enyeart (Fri, 14 Feb 2020 13:31:16 GMT):
@KartikChauhan @ZainabM Good questions, but please reserve this channel for maintainer topics. If you cannot get an answer in other channels, you could use stackoverflow or mailing list.

dave.enyeart (Fri, 14 Feb 2020 13:31:53 GMT):
v1.4.5 release notes for review - https://github.com/hyperledger/fabric/pull/670

dave.enyeart (Fri, 14 Feb 2020 13:32:08 GMT):
We expect to release v1.4.5 next week.

Silona (Mon, 17 Feb 2020 22:18:13 GMT):
Are you wondering about tapping into Developer marketing for your group or project? Do you have a blog post idea? An awesome announcement? Please attend TOMORROW! https://wiki.hyperledger.org/display/Marketing/2020-02-19+Meeting+notes

nekia (Tue, 18 Feb 2020 03:22:50 GMT):
Has joined the channel.

nekia (Tue, 18 Feb 2020 03:26:35 GMT):
Hi, can I propose an agenda topic for the next contributors meeting?

nekia (Tue, 18 Feb 2020 03:29:41 GMT):
Topic is about the proposal of block archiving for Hyperledger Fabric, that is one of projects in Labs. [HLF Block Archiving - Google Slides](https://docs.google.com/presentation/d/1tzD6l8VwLUeDytYeEChqigsIaqMw4Z2NQj9pNah8Msc/edit?usp=sharing&authuser=0)

nekia (Tue, 18 Feb 2020 03:51:18 GMT):
Presenter is Anand Konchery and Atsushi Neki. It will be enough 15 - 20 min for sharing and discussing.

nekia (Tue, 18 Feb 2020 03:56:53 GMT):
[In this discussion at Mailing list](https://lists.hyperledger.org/g/fabric/topic/58600016?p=Created,,,20,1,0,0), it’s pointed out that our assumption is incorrect. So now we’ve redesigned the logic and we’re about to move forward to development. Before moving on to the development, we think it had better to have more feedback for the new approach from the community.

nekia (Tue, 18 Feb 2020 03:57:01 GMT):
@dave.enyeart

nekia (Tue, 18 Feb 2020 04:00:06 GMT):
We are in AEDT.

anand.fast (Tue, 18 Feb 2020 05:55:39 GMT):
Has joined the channel.

dave.enyeart (Tue, 18 Feb 2020 15:03:00 GMT):
@nekia Good timing, there is a contributor meeting tomorrow (9am US Eastern). would you be ready for that one?

swetha (Tue, 18 Feb 2020 16:56:02 GMT):
@dave.enyeart We would like to talk about Fabric Private Chaincode and our upcoming RFC on the meeting tomorrow. Presenters will be Jeb Linton, Marcus Brandenburger. They will need about 20 min. WIll that be possible to add to the agenda? One of the presenters has a conflict, so earlier in the meeting schedule would be preferable.

dave.enyeart (Tue, 18 Feb 2020 17:02:15 GMT):
@swetha yep, you all can go first after we do some quick maintainer business

swetha (Tue, 18 Feb 2020 18:56:49 GMT):
Thanks!

nekia (Tue, 18 Feb 2020 22:55:23 GMT):
Thanks, we are ready for the meeting tomorrow.

dave.enyeart (Wed, 19 Feb 2020 13:04:36 GMT):
Ok @swetha @nekia , you are both on in one hour!

dave.enyeart (Wed, 19 Feb 2020 13:57:49 GMT):
@here Contributor Meeting starting in a few minutes: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 19 Feb 2020 17:01:41 GMT):
We plan to release fabric and fabric-ca v1.4.5 today... does anybody have any final PRs to go in?

dave.enyeart (Wed, 19 Feb 2020 19:45:53 GMT):
fabric release PR - please approve: https://github.com/hyperledger/fabric/pull/695

rjones (Wed, 19 Feb 2020 21:11:03 GMT):
@BrettLogan who will trigger this job? https://dev.azure.com/Hyperledger/Fabric/_build?definitionId=52&_a=summary

BrettLogan (Wed, 19 Feb 2020 21:12:09 GMT):
@rjones I do, but Dave and Matt also have permission.

BrettLogan (Wed, 19 Feb 2020 21:15:54 GMT):
Starting the release process now

rjones (Wed, 19 Feb 2020 21:18:12 GMT):
the stages view is nice

BrettLogan (Wed, 19 Feb 2020 21:19:13 GMT):
Very, I always enjoy watching it

BrettLogan (Wed, 19 Feb 2020 21:35:14 GMT):
Release is done

KartikChauhan (Fri, 21 Feb 2020 09:18:23 GMT):
@nekia Where can I find more info about HLF Block Archiving?

nekia (Fri, 21 Feb 2020 13:26:33 GMT):
You can find more info at [Github repo](https://github.com/hyperledger-labs/fabric-block-archiving) besides [the above slide](https://docs.google.com/presentation/d/1tzD6l8VwLUeDytYeEChqigsIaqMw4Z2NQj9pNah8Msc/edit?usp=sharing) @KartikChauhan

KartikChauhan (Mon, 24 Feb 2020 10:43:07 GMT):
I cloned binaries and fabric-samples repo for v1.4.5 from the documentation and I don't see any basic-network directory there. Could you please provide any reason to why it has been removed in this version?

dave.enyeart (Mon, 24 Feb 2020 12:52:48 GMT):
We had first-network, basic-network, and now test-network. The intent is to consolidate all three into test-network in master. Actually release-1.4 branch still has it: https://github.com/hyperledger/fabric-samples/tree/release-1.4/basic-network. Your issue is probably that we haven't tagged fabric-samples v1.4.5 yet, so you've probably got master. You can checkout v1.4.4 or just release-1.4 until we tag it.

dave.enyeart (Mon, 24 Feb 2020 12:53:37 GMT):
@sstone1 @heatherp Can we tag fabric-samples v1.4.5 now? Anything else you want merged there first?

heatherp (Mon, 24 Feb 2020 13:06:29 GMT):
Not that I can think of

dave.enyeart (Tue, 25 Feb 2020 11:26:44 GMT):
Since releasing v1.4.5 last week, a few more fixes have come in. I think it would be good to scoop these fixes up in a v1.4.6 release... no need to wait a couple months.

dave.enyeart (Tue, 25 Feb 2020 11:26:52 GMT):
v1.4.6 release notes: https://github.com/hyperledger/fabric/pull/736

dave.enyeart (Tue, 25 Feb 2020 11:27:49 GMT):
We also expect a v2.0.1 release this week to deliver the first set of fixes on v2.0

rjones (Tue, 25 Feb 2020 15:42:51 GMT):
@dave.enyeart was there a decision on homebrew? I have this pending: https://github.com/hyperledger/homebrew-fabric/pull/12 but if Fabric is going to curtail support, we could put the repo into the archive.

dave.enyeart (Tue, 25 Feb 2020 17:38:21 GMT):
@cbf do you have thoughts on this? I think the homebrew came from you?

dave.enyeart (Tue, 25 Feb 2020 17:38:46 GMT):
could i get a review for v1.4.6 release notes: https://github.com/hyperledger/fabric/pull/736

BrettLogan (Tue, 25 Feb 2020 18:01:58 GMT):
We initially proposed archiving homebrew, but Gari asked that we keep it. So updating it is should probably be done

rjones (Tue, 25 Feb 2020 18:07:26 GMT):
OK. Feel free to merge 12 and I can do the next update or you can add it to CI

dave.enyeart (Tue, 25 Feb 2020 23:20:48 GMT):
Fabric and Fabric CA v1.4.6 released today. All good.

dave.enyeart (Wed, 26 Feb 2020 14:29:56 GMT):
To continue our release saga... there are some important fixes in release-2.0 since fabric v2.0.0 release, so we'll release v2.0.1 this week. Does anybody have any important PRs to merge before we release v2.0.1?

dave.enyeart (Wed, 26 Feb 2020 14:30:27 GMT):
And as a reminder...we're back on track with minor releases each quarter, so that means v2.1 is scheduled for April.

dave.enyeart (Wed, 26 Feb 2020 19:57:13 GMT):
v2.0.1 release PR https://github.com/hyperledger/fabric/pull/748

dave.enyeart (Wed, 26 Feb 2020 19:57:13 GMT):
v2.0.1 release PR https://github.com/hyperledger/fabric/pull/750

dave.enyeart (Wed, 26 Feb 2020 19:57:35 GMT):
please review release notes

dave.enyeart (Wed, 26 Feb 2020 22:20:54 GMT):
v2.0.1 released. all good.

dave.enyeart (Fri, 28 Feb 2020 21:56:15 GMT):
With several people traveling next week to Hyperledger Global Forum, I propose we cancel the March 4th contributor meeting. Are there any topics that can't wait for the March 18th meeting?

pandrejko (Fri, 28 Feb 2020 22:09:48 GMT):
We merged Joe's new Deploying a production network overview topic last week. Here's the first attempt at describing the process to deploy a CA using the binaries: https://github.com/hyperledger/fabric/pull/764. Comments welcome!

dave.enyeart (Tue, 03 Mar 2020 13:59:28 GMT):
Reminder - Fabric contributor meeting canceled this week.

dave.enyeart (Tue, 03 Mar 2020 13:59:59 GMT):
I've cleaned up the 'roadmap' dashboard for v2.x items: https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104

ahmedsajid (Wed, 04 Mar 2020 13:57:05 GMT):
Has joined the channel.

ravinayag (Sat, 07 Mar 2020 03:47:29 GMT):
Hello, I'm using basic network sample of 1.4.2 binaries. I did chain code upgrades multiple times. I need a help on this. 1. Can we remove/delete old cc containers after cc upgrade ? E.x. mycc version 1.0 later mycc version 1.1 , 1.2 Can I delete version 1.0 container ? 2. Its vague , My cc upgrade taking/ creating random containers from previously deployed chain code. I don't know why ? Don't know how to trace it. The current workaround i do, full fab network down with volume prune and remove containers from docker image rm commands. Then start again from fresh... Appreciate you help

troyronda (Thu, 12 Mar 2020 19:34:24 GMT):
I posted last year about starting efforts on our TrustBloc project. I thought it might be interesting to some to see an update about our Fabric-related progress. I’ve shared the update and links to the repos at https://docs.google.com/document/d/1b5AHZyklexolzUIZ4Yz_Ma1atKM2mudpD6-SNplGJu0/

Abhishekkishor (Thu, 12 Mar 2020 19:41:03 GMT):
Has joined the channel.

yacovm (Thu, 12 Mar 2020 19:49:12 GMT):
``` What’s still upcoming? Cluster and cache optimizations. Investigate local collection policy. <------ Investigate Fabric 2.0 chaincode lifecycle. Formal release efforts including performance and resiliency. Update Sidetree implementation as formal spec is being created. ```

yacovm (Thu, 12 Mar 2020 19:49:25 GMT):
What do you mean by that, @troyronda "Investigate local collection policy" ?

troyronda (Thu, 12 Mar 2020 20:02:14 GMT):
Data that is kept to an organization. Might have named that wrong in the doc.

dave.enyeart (Wed, 18 Mar 2020 01:16:36 GMT):
Agenda for March 18th Contributor Meeting:

dave.enyeart (Wed, 18 Mar 2020 01:16:53 GMT):
- Release update - Dave Enyeart - Update on channel config APIs - Danny Cao - Hedera Consensus Service - Donald Thibeau

dave.enyeart (Wed, 18 Mar 2020 01:16:53 GMT):
- Release update, LTS RFC https://github.com/hyperledger/fabric-rfcs/pull/23/files?short_path=2816768#diff-28167684f06775a34bcbd29070fc8f4a - Dave Enyeart - Update on channel config APIs - Danny Cao - Hedera Consensus Service - Donald Thibeau

dave.enyeart (Wed, 18 Mar 2020 01:17:21 GMT):
As always, agendas, details, and recordings available at https://wiki.hyperledger.org/display/fabric/Contributor+Meetings

dave.enyeart (Wed, 18 Mar 2020 12:59:21 GMT):
@here Contributor meeting starting: https://zoom.us/my/hyperledger.community.3

tock (Sun, 22 Mar 2020 07:50:34 GMT):
Hello maintainers, here is an RFC for your review: https://github.com/hyperledger/fabric-rfcs/pull/24

tock (Sun, 22 Mar 2020 07:50:34 GMT):
Hello maintainers, here is an RFC for your review: https://github.com/hyperledger/fabric-rfcs/pull/24 Channel participation API without system channel

tock (Sun, 22 Mar 2020 07:50:34 GMT):
Hello maintainers, here is an RFC for your review: https://github.com/hyperledger/fabric-rfcs/pull/24 Channel participation API without system channel - joining, removing, and listing channels without the system channel.

dave.enyeart (Mon, 23 Mar 2020 15:00:52 GMT):
@here Release update - this is the last week for dev work for the Fabric end-of-Q1 release. We expect to create branch release-2.1 next week, and then release 2.1 in mid-April as soon as we are comfortable with the release from a system test perspective (e..g. automated upgrade tests are being updated currently). As we approach a release boundary, be cautious about merges, you may want to hold off on any big changes for master until after we create the release-2.1 branch. I'll highlight three RFCs - we welcome feedback comments from all, and require maintainers to review:

dave.enyeart (Mon, 23 Mar 2020 15:00:59 GMT):
https://github.com/hyperledger/fabric-rfcs/pull/25 config transaction library - we'd like to fast-track this so that we can remove the new config library code from Fabric repo before creating release-2.1 branch. The config library would go to a different repo since it is not tied to Fabric releases.

dave.enyeart (Mon, 23 Mar 2020 15:00:59 GMT):
https://github.com/hyperledger/fabric-rfcs/pull/25 config transaction library - intent is to shift the library from Fabric to a new repo where clients can consume it

dave.enyeart (Mon, 23 Mar 2020 15:01:05 GMT):
https://github.com/hyperledger/fabric-rfcs/pull/23 LTS release stratgy - we need to finalize this RFC and then move on to the discussion of which release will be LTS for v2.x.

dave.enyeart (Mon, 23 Mar 2020 15:01:11 GMT):
https://github.com/hyperledger/fabric-rfcs/pull/24 Channel participation API without system channel - Not for 2.1 timeframe, but we ned to make progress on the RFC.

dave.enyeart (Thu, 26 Mar 2020 14:15:36 GMT):
Nominate Danny Cao and Brett Logan as Fabric maintainers

dave.enyeart (Thu, 26 Mar 2020 14:15:36 GMT):
@here Nominate Danny Cao and Brett Logan as Fabric maintainers

dave.enyeart (Thu, 26 Mar 2020 14:15:38 GMT):
https://github.com/hyperledger/fabric/pull/921

dave.enyeart (Thu, 26 Mar 2020 14:15:47 GMT):
https://github.com/hyperledger/fabric/pull/920

dave.enyeart (Thu, 26 Mar 2020 14:15:52 GMT):
Please add your approval if you agree

MHBauer (Fri, 27 Mar 2020 18:54:59 GMT):
Is https://jira.hyperledger.org/browse/FAB-10562 still a relevant issue? Is there discussion somewhere?

dave.enyeart (Sat, 28 Mar 2020 12:06:53 GMT):
@sykesm is our expert in this area, so I've mentioned him in the Jira comment

dave.enyeart (Sat, 28 Mar 2020 12:59:33 GMT):
Concerning the maintainer nominations, I've realized that the Contribution guide does not mention anything about criteria for becoming a maintainer. So, what is the criteria?

dave.enyeart (Sat, 28 Mar 2020 12:59:40 GMT):
First, what is a maintainer? "Maintainers are responsible for reviewing and merging all patches submitted for review, and they guide the overall technical direction of the project".

dave.enyeart (Sat, 28 Mar 2020 12:59:52 GMT):
Therefore, what we look for is a demonstrated track record of PR reviews (both quality and quantity), demonstrated thought leadership in the project, and demonstrated shepherding of project work and contributors.

dave.enyeart (Sat, 28 Mar 2020 12:59:57 GMT):
Basically, if you are already acting like a maintainer, the nomination should be a mere formality to enable the commit privileges.

dave.enyeart (Sat, 28 Mar 2020 13:00:39 GMT):
I've also opened a PR to clarify the criteria, please add your feedback/comments to the PR so that we guide future maintainers and nominations: https://github.com/hyperledger/fabric/pull/931

MHBauer (Tue, 31 Mar 2020 15:22:14 GMT):
an attempt https://github.com/hyperledger/fabric/pull/954 last case stuck on is externalbuilder. looking for some ideas.

dave.enyeart (Tue, 31 Mar 2020 18:12:12 GMT):
@here I've created release-2.1 branch for fabric, fabric-protos, fabric-protos-go repositories

dave.enyeart (Tue, 31 Mar 2020 18:12:31 GMT):
We intend to do the same for fabric-test and fabric-samples

dave.enyeart (Tue, 31 Mar 2020 18:16:00 GMT):
Obviously new work continues to go into master, and we judicially backport anything important to release-2.1

dave.enyeart (Tue, 31 Mar 2020 18:16:00 GMT):
Obviously new work continues to go into master, and we judiciously backport anything important to release-2.1

dave.enyeart (Tue, 31 Mar 2020 18:16:09 GMT):
As of now, I see no point in a v2.0.2, so I consider release-2.0 'done', no need for backports to it

dave.enyeart (Tue, 31 Mar 2020 18:16:09 GMT):
As of now, I see no point in a v2.0.2, so I consider release-2.0 'done' from code perspective (I expect any further backports would be for things like doc fixes)

MHBauer (Tue, 31 Mar 2020 20:41:01 GMT):
is there a way to enable the azure build on my fork so I don't have to push a PR to see what happens? It's also way faster than building locally.

rjones (Tue, 31 Mar 2020 20:51:35 GMT):
you can set it up on your own, if that's what you mean. Anyone with a GitHub account can create an Azure org for free - it's what I've done to test some stuff

rjones (Tue, 31 Mar 2020 20:52:34 GMT):
Enabling builds on forks makes exfiltration of secrets easy

dave.enyeart (Wed, 01 Apr 2020 12:58:52 GMT):
@here Contributor meeting starting: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 01 Apr 2020 12:58:58 GMT):
Agenda:

dave.enyeart (Wed, 01 Apr 2020 12:59:02 GMT):
Release and RFC update

dave.enyeart (Wed, 01 Apr 2020 12:59:09 GMT):
Channel participation API without system channel - Yoav Tock

VipinB (Wed, 01 Apr 2020 13:36:11 GMT):
Are slides from Yoav available?

dave.enyeart (Wed, 01 Apr 2020 16:32:46 GMT):
@tock Thanks for today's review. It sounds like there is consensus on the RFC, just need to close out the RFC comments and then we can put it in Final Comment Period. Therefore I think you could go ahead and open a Jira Epic and link the related Stories to it. You could post the charts in the Epic.

dave.enyeart (Wed, 01 Apr 2020 16:34:52 GMT):
@caod @BrettLogan Congratulations on the maintainer nomination approval! @rjones let us know if we need to submit a formal request for adding the permissions.

BrettLogan (Wed, 01 Apr 2020 16:42:34 GMT):
Thank you Dave, especially for the nomination!

BrettLogan (Wed, 01 Apr 2020 16:43:49 GMT):
Ry will need to update the core-maintainers and core-release-managers teams in GitHub

rjones (Wed, 01 Apr 2020 16:47:17 GMT):
eh?

rjones (Wed, 01 Apr 2020 16:47:17 GMT):
@dave.enyeart @BrettLogan @caod added

BrettLogan (Wed, 01 Apr 2020 16:50:05 GMT):
Thanks Ry!

rjones (Wed, 01 Apr 2020 16:50:30 GMT):
thank you for being a contributor!

tock (Thu, 02 Apr 2020 06:02:34 GMT):
Thanks Dave. Will do.

tock (Thu, 02 Apr 2020 06:03:12 GMT):
I'll post the slides in the Epic I am going to open.

nileshv (Thu, 02 Apr 2020 06:09:23 GMT):
Has joined the channel.

VipinB (Thu, 02 Apr 2020 14:19:27 GMT):
Thanks!

BrettLogan (Thu, 02 Apr 2020 14:50:03 GMT):
Ry, it doesn't seem that Danny and I have been added to the `fabric-core-maintainers` team in github

BrettLogan (Thu, 02 Apr 2020 14:50:25 GMT):
My addition to release-managers worked

rjones (Thu, 02 Apr 2020 14:51:05 GMT):
I didn't know that your nominations succeeded

BrettLogan (Thu, 02 Apr 2020 14:52:19 GMT):
Ah, sorry, should have mentioned that, home confinement is getting to me

tock (Sun, 05 Apr 2020 07:51:13 GMT):
Here it is: https://jira.hyperledger.org/browse/FAB-17712

tock (Sun, 05 Apr 2020 07:51:56 GMT):
Here it is: https://jira.hyperledger.org/browse/FAB-17712

jramps9 (Tue, 07 Apr 2020 15:50:54 GMT):
Has joined the channel.

jramps9 (Tue, 07 Apr 2020 15:50:55 GMT):
Hello Fabric maintainers! Friendly reminder to pls join us for the Marketing Committee-DevRel call tomorrow, 4/8 at 9am PT. This is a great opportunity to learn how you can get involved in many aspects of Hyperledger marketing including overall messaging, events, content, social media, PR etc. Feel free to add items to the agenda: https://wiki.hyperledger.org/x/_QjcAQ Hope to see you there :slight_smile:

dave.enyeart (Wed, 08 Apr 2020 16:08:40 GMT):
@here Proposal to retire inactive maintainers: https://github.com/hyperledger/fabric/pull/1028 Please add your approval if you agree. This is not a role that I enjoy, but our policy is to retire inactive maintainers since it is often challenging to get a majority opinion on important maintainer decisions.

dave.enyeart (Wed, 08 Apr 2020 16:08:40 GMT):
@here Proposal to retire inactive maintainers: https://github.com/hyperledger/fabric/pull/1028 Please add your approval if you agree. This is not a task that I enjoy, but our policy is to retire inactive maintainers since it is often challenging to get a majority opinion on important maintainer decisions.

rjones (Fri, 10 Apr 2020 17:34:37 GMT):
Hi - talking with @BrettLogan about putting the org in the code; I ran `peribolos` against our orgs. [The output here may be of interest](https://github.com/ryjones/orgstuff). We're also discussing how to use Probot to put the org in the org for other parts - peribolos and Probot serve similar, but not identical, roles, and I think we'd need both

BrettLogan (Fri, 10 Apr 2020 18:52:17 GMT):
What Ry and I are trying to achieve here is GitHub configuration as code. So the repository settings would be managed by a configuration file contained within the repo. This way instead of people just changing repository settings behind the scenes (and no one knowing who did it), a PR is submitted to do things like: enable GitHub actions, change the rules for requirements for a merge, or what branches are covered under the checks policies, and what those policies are. This would also cover the members of teams. So when we need to add or remove people from team (like the maintainers) instead of going to Ry and asking him to add people, we could simply open a PR to edit the team configuration.

BrettLogan (Fri, 10 Apr 2020 18:52:17 GMT):
What Ry and I are trying to achieve here is GitHub configuration as code. So the repository settings would be managed by a configuration file contained within the repo. This way instead of people just changing repository settings behind the scenes, a PR is submitted to do things like: enable GitHub actions, change the rules for requirements for a merge, or what branches are covered under the checks policies, and what those policies are. This would also cover the members of teams. So when we need to add or remove people from team (like the maintainers) instead of going to Ry and asking him to add people, we could simply open a PR to edit the team configuration.

cbf (Tue, 14 Apr 2020 13:16:57 GMT):
+100

dave.enyeart (Tue, 14 Apr 2020 19:16:07 GMT):
@here Any topics you want to add to the contributor meeting agenda for tomorrow?

nekia (Wed, 15 Apr 2020 00:44:49 GMT):
Can I share the latest status of our block archiving project to get feedback on it from the community? It'll be enough 10-15min . Anand Konchery and Atsushi Neki will attend it.

nekia (Wed, 15 Apr 2020 00:44:55 GMT):
@dave.enyeart

dave.enyeart (Wed, 15 Apr 2020 11:52:41 GMT):
@nekia sure thing

nekia (Wed, 15 Apr 2020 12:02:57 GMT):
Thanks

nekia (Wed, 15 Apr 2020 12:48:29 GMT):
https://docs.google.com/presentation/d/10yBF0Nrprdp2qjtBqJY7un_HU40FjQFVX86UVsuvSHA/edit?usp=sharing This is slide of the topic we'd like to share.

jyellick (Wed, 15 Apr 2020 13:04:04 GMT):
For those who usually expect @dave.enyeart to poste it here (likie myself) contributor meeting starting https://zoom.us/my/hyperledger.community.3

jyellick (Wed, 15 Apr 2020 13:04:04 GMT):
For those who usually expect @dave.enyeart to post it here (like myself) contributor meeting starting https://zoom.us/my/hyperledger.community.3

lehors (Wed, 15 Apr 2020 13:11:26 GMT):
https://adlrocha.substack.com/p/adlrocha-performance-best-practices

lehors (Wed, 15 Apr 2020 13:11:26 GMT):
Here is the reference to the series Jessica referred to: https://adlrocha.substack.com/p/adlrocha-performance-best-practices

rjones (Wed, 15 Apr 2020 13:38:14 GMT):
@dave.enyeart was the host issue figured out?

dave.enyeart (Wed, 15 Apr 2020 13:47:14 GMT):
@rjones sadly no... not able to record today's since we didn't have a host code

rjones (Wed, 15 Apr 2020 14:55:02 GMT):
the host code is the same, I verified in the UI. What is different is apparently you have to log in with your zoom account to use it. I'll document this.

rjones (Wed, 15 Apr 2020 14:55:14 GMT):
(I wasn't able to claim host, either)

lehors (Thu, 16 Apr 2020 13:52:36 GMT):
I just realized that we haven't tagged fabric-samples for 2.x since 2.0.0-beta, as we release fabric 2.1 I think we should tag and have a 2.1 release for fabric-samples as well

lehors (Thu, 16 Apr 2020 13:52:55 GMT):
a lot of the samples have been updated for 2.0 and won't even work with 1.4 anymore

dave.enyeart (Thu, 16 Apr 2020 19:48:24 GMT):
@lehors several of us discussed today and our plan is to tag current fabric-samples master with v2.1.0, but not create a release-2.1 branch. Basically just keep master going and only create a release branch if/when something incompatible comes up.

dave.enyeart (Thu, 16 Apr 2020 19:48:56 GMT):
people that download fabric using our curl/bootstrap script would get the known working v2.1.0 tag

dave.enyeart (Thu, 16 Apr 2020 19:49:47 GMT):
i can also tag for v2.0.0... we've been waiting to do that until some of the recent test network PRs merged, which is done now

dave.enyeart (Thu, 16 Apr 2020 19:49:50 GMT):
sound good?

dave.enyeart (Thu, 16 Apr 2020 20:54:18 GMT):
I think this is the final commit needed before tagging fabric-samples: https://github.com/hyperledger/fabric-samples/pull/161

dave.enyeart (Fri, 17 Apr 2020 03:08:10 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v2.1 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/8091 ----------------------------------------------------------------------

knagware9 (Fri, 17 Apr 2020 12:23:01 GMT):
we alwast get that error while running script .error: pathspec 'v2.1.0' did not match any file(s) known to git.thesre should be tag with relevent version on fabric-samples. Is fabric-sample master branch is pointed to 2.1.0 ?

dave.enyeart (Fri, 17 Apr 2020 12:36:18 GMT):
yes, fabric-samples now uses v2.1.0 dependencies, we'll tag as v2.1.0 shortly so that the error message goes away...

dave.enyeart (Fri, 17 Apr 2020 12:36:18 GMT):
yes, fabric-samples now uses v2.1.0 dependencies, it is now tagged so you should be all good now.

rjones (Fri, 17 Apr 2020 17:20:57 GMT):
Hey, all. Paul O'Mahoney figured out why people couldn't claim host: you need to be running the most recent Zoom client. @dave.enyeart

rjones (Fri, 17 Apr 2020 17:21:40 GMT):
This explains why I was unable to claim host last Friday and was able to on Monday with no account settings changed.

dave.enyeart (Fri, 17 Apr 2020 20:18:17 GMT):
yep, updating my Zoom client worked!

dave.enyeart (Fri, 17 Apr 2020 20:18:17 GMT):
yep, updating my Zoom client fixed it!

ahmedsajid (Tue, 21 Apr 2020 20:56:27 GMT):
Has left the channel.

jyellick (Wed, 22 Apr 2020 13:49:58 GMT):
@rjones Looks like you just created a v1.0.6 branch which is just master?

jyellick (Wed, 22 Apr 2020 13:49:58 GMT):
@rjones Looks like you just created a v1.0.6 branch which is just master? (Or maybe I accidentally did, I was just checking something on v1.0.6, seems like an odd coincidence that it suddenly appeared)

jyellick (Wed, 22 Apr 2020 13:54:14 GMT):
Actually, I'm really pretty sure this was me who accidentally created this branch. Apparently if you type a branch name and hit enter in the UI, and it doesn't match any branch name, it creates that branch. Seems like kind of undesirable behavior.

rjones (Wed, 22 Apr 2020 13:55:20 GMT):
yeah, such is life.

rjones (Wed, 22 Apr 2020 13:55:35 GMT):
I saw you do that, and I wondered what was going on :)

jyellick (Wed, 22 Apr 2020 13:56:03 GMT):
Looks like I actually have two branches out there, also a `,release-1.4` (I guess a typo when I was searching at one point)

jyellick (Wed, 22 Apr 2020 13:56:03 GMT):
~Looks like I actually have two branches out there, also a `,release-1.4` (I guess a typo when I was searching at one point)~ Maybe not... I guess I will delete the v1.0.6 branch, anyone know if there's a way to make it harder to accidentally create these branches

rjones (Wed, 22 Apr 2020 13:57:41 GMT):
You want them gone?

jyellick (Wed, 22 Apr 2020 13:57:53 GMT):
Looks like I can delete it myself

rjones (Wed, 22 Apr 2020 13:57:59 GMT):
When I look here I don't see it: https://github.com/hyperledger/fabric/branches

jyellick (Wed, 22 Apr 2020 13:58:02 GMT):
Just wanted to make sure I wasn't undoing something purposeful

rjones (Wed, 22 Apr 2020 13:58:28 GMT):
err https://github.com/hyperledger/fabric/branches/all

jyellick (Wed, 22 Apr 2020 13:58:41 GMT):
I've deleted them, thanks

dave.enyeart (Fri, 24 Apr 2020 15:58:04 GMT):
For PRs that reference a Jira, please remember to close them when you merge/close the PR. I'm seeing an increased number of Jiras left orphaned.

heatherp (Mon, 27 Apr 2020 12:29:22 GMT):
well if we used github for issues... ;)

caod (Mon, 27 Apr 2020 17:19:52 GMT):
Now that https://github.com/hyperledger/fabric-rfcs/pull/25 is merged anyone have objections on the naming for the new repo containing the configtx package to be named `hyperledger/fabric-config`?

rjones (Mon, 27 Apr 2020 17:43:54 GMT):
@caod is this starting with a blank repo?

rjones (Mon, 27 Apr 2020 17:59:52 GMT):
https://github.com/hyperledger/fabric-config

rjones (Mon, 27 Apr 2020 18:01:28 GMT):
are the maintainers for this repo the same as for `hyperledger/fabric' ?

rjones (Mon, 27 Apr 2020 18:01:28 GMT):
are the maintainers for this repo the same as for `hyperledger/fabric` ?

caod (Mon, 27 Apr 2020 18:05:58 GMT):
yep

caod (Mon, 27 Apr 2020 18:07:17 GMT):
Thanks @rjones!

rjones (Mon, 27 Apr 2020 18:07:59 GMT):
if you could do a PR to update the description here: `https://github.com/hyperledger/fabric-config/blob/master/.github/settings.yml` I'd appreciate it. :)

caod (Mon, 27 Apr 2020 18:08:17 GMT):
Will do

caod (Mon, 27 Apr 2020 18:18:59 GMT):
I pushed the PR if you could merge it, I have a followup one soon that will add CODEOWNERS as well as other necessary files for CI/contributing

caod (Mon, 27 Apr 2020 18:19:20 GMT):
actually I guess I can just merge it for now

caod (Mon, 27 Apr 2020 18:20:33 GMT):
oh I see you already added CODEOWNERS just now

BrettLogan (Mon, 27 Apr 2020 18:20:44 GMT):
Im quick on the PR draw

rjones (Mon, 27 Apr 2020 18:21:00 GMT):
everything should work now

dave.enyeart (Wed, 29 Apr 2020 12:04:43 GMT):
@here Agenda items for Contributor Meeting next hour: - Roadmap update - I'll ask people working on roadmap items to give a quick update - Ledger Checkpoint RFC Deep Dive - Manish Sethi

dave.enyeart (Wed, 29 Apr 2020 12:04:49 GMT):
Anything else to add?

lehors (Wed, 29 Apr 2020 12:55:24 GMT):
Common repo structure :)

lehors (Wed, 29 Apr 2020 12:56:01 GMT):
plus https://chat.hyperledger.org/channel/fabric-pr-review?msg=Nzu44wA4cmkc5YBbs

dave.enyeart (Wed, 29 Apr 2020 13:00:39 GMT):
@here meeting starting: https://zoom.us/my/hyperledger.community.3

lehors (Thu, 07 May 2020 16:26:38 GMT):
hey maintainers, I'm proposing to add Nik Gupta as a maintainer of fabric-samples, I think he largely deserves it and in fact has been much more active than many of the existing maintainers, see: https://github.com/hyperledger/fabric-samples/pull/180

lehors (Thu, 07 May 2020 18:11:10 GMT):
@bretharrison @cbf @dave.enyeart @mastersingh24 @jyellick @mbwhite @sstone1 ^^^

sstone1 (Thu, 07 May 2020 18:11:33 GMT):
Already approved 👍

jramps9 (Wed, 13 May 2020 12:13:03 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT TODAY, 5/13! Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-05-13+Meeting+notes

dave.enyeart (Wed, 13 May 2020 12:34:25 GMT):
@here Contributor Meeting in 30 minutes. Agenda: - Release Update - Doc Update - Config transaction library overview and demo – Danny Cao and Tiffany Harris Anything else?

dave.enyeart (Wed, 13 May 2020 12:34:25 GMT):
@here Contributor Meeting in 30 minutes. Agenda: - Release Update - Samples Update - Doc Update - Config transaction library overview and demo – Danny Cao and Tiffany Harris Anything else?

dave.enyeart (Wed, 13 May 2020 12:59:24 GMT):
@here meeting starting: https://zoom.us/my/hyperledger.community.3

dave.enyeart (Thu, 14 May 2020 08:01:46 GMT):
Release notes for v1.4.7: https://github.com/hyperledger/fabric/pull/1264

dave.enyeart (Thu, 14 May 2020 08:02:08 GMT):
Does anybody have any other PRs before we release v1.4.7?

dave.enyeart (Thu, 14 May 2020 17:09:24 GMT):
ok, proceeding with fabric and fabric-ca v1.4.7 release...

knagware9 (Fri, 15 May 2020 04:11:22 GMT):
FAB-17778: Fix policy support of multiple signatures from single organization Fix de-duplication logic to ensure sufficient number of signatures are received to satisfy policies that require multiple signatures from the same organization. This problem is rare since most users have policies that require signatures from different organizations, not policies that require multiple signatures from the same organization.

knagware9 (Fri, 15 May 2020 04:12:11 GMT):
How I can test it ? Not much details in JIRA

lehors (Mon, 18 May 2020 19:52:58 GMT):
fabric-maintainers, I would like to consider adopting the Fabric-docs-CN lab https://github.com/hyperledger-labs/fabric-docs-cn and the new Fabric-docs-ML one (https://github.com/hyperledger-labs/fabric-docs-ml as part of Fabric proper

lehors (Mon, 18 May 2020 19:52:58 GMT):
fabric-maintainers, I would like us to consider adopting the Fabric-docs-CN lab https://github.com/hyperledger-labs/fabric-docs-cn and the new Fabric-docs-ML one (https://github.com/hyperledger-labs/fabric-docs-ml as part of Fabric proper

lehors (Mon, 18 May 2020 19:52:58 GMT):
fabric-maintainers, I would like us to consider adopting the Fabric-docs-CN lab https://github.com/hyperledger-labs/fabric-docs-cn and the new Fabric-docs-ML one https://github.com/hyperledger-labs/fabric-docs-ml as part of Fabric proper

lehors (Mon, 18 May 2020 19:53:16 GMT):
there is no good reason for these doc efforts to not be part of Fabric

lehors (Mon, 18 May 2020 19:53:54 GMT):
we can just adopt them as separate repos with the same maintainers they already have

lehors (Mon, 18 May 2020 19:54:18 GMT):
it will only increase the overall number of Fabric maintainers and diversity

lehors (Mon, 18 May 2020 19:54:40 GMT):
and properly recognize these efforts

lehors (Mon, 18 May 2020 19:55:54 GMT):
when the chinese one was first created people were reluctant to making part of Fabric proper for fear of inheriting something that we couldn't understand and manage

lehors (Mon, 18 May 2020 19:55:54 GMT):
when the chinese one was first created people were reluctant to making it part of Fabric proper for fear of inheriting something that we couldn't understand and manage

lehors (Mon, 18 May 2020 19:56:14 GMT):
but we need to get over that fear and trust the community who knows and cares about it

lehors (Mon, 18 May 2020 19:56:28 GMT):
they've already demonstrated their commitment

lehors (Mon, 18 May 2020 19:56:44 GMT):
there is no reason to worry that they will suddenly disappear and leave us holding the bag

lehors (Mon, 18 May 2020 20:00:05 GMT):
please, @dave.enyeart , put this on the agenda of the next maintainers call

lehors (Mon, 18 May 2020 20:00:42 GMT):
thanks

dave.enyeart (Wed, 20 May 2020 03:42:18 GMT):
@here Always sad to see our colleagues move on, but we're due for another round of inactive maintainer retirement:

dave.enyeart (Wed, 20 May 2020 03:42:21 GMT):
https://github.com/hyperledger/fabric/pull/1296

dave.enyeart (Wed, 20 May 2020 03:42:48 GMT):
https://github.com/hyperledger/fabric-ca/pull/158

dave.enyeart (Wed, 20 May 2020 03:43:51 GMT):
Please hit approve if you agree

dave.enyeart (Wed, 27 May 2020 06:34:55 GMT):
For contributor meeting today, I know @lehors wanted to discuss doc translation, and @mbwhite may want to discuss Wasm.

dave.enyeart (Wed, 27 May 2020 06:35:01 GMT):
I'm out of office and won't be available at that time, can anybody volunteer to facilitate the meeting?

dave.enyeart (Wed, 27 May 2020 06:35:19 GMT):
Same meeting id as always: https://zoom.us/my/hyperledger.community.3

BrettLogan (Wed, 27 May 2020 06:36:08 GMT):
I'll take care of it Dave

lehors (Wed, 27 May 2020 08:40:11 GMT):
there is a risk I may not be able to make the call today unfortunately. I will try but don't be surprised if I'm MIA. Sorry about that.

BrettLogan (Wed, 27 May 2020 12:58:42 GMT):
Community call starting now: https://zoom.us/my/hyperledger.community.3

BrettLogan (Wed, 27 May 2020 19:03:12 GMT):
Per the proposal on the community call this morning, the proposal has been brought forward to make the documentation translation work part of the official fabric repository and remove it from the Hyperledger Labs where it is currently hosted. We will open this up for discussion here for anyone who would like to comment

jyellick (Wed, 27 May 2020 19:23:47 GMT):
No objections here, though I'd feel better with a vote of approval from @pandrejko or other doc maintainers.

rjones (Wed, 27 May 2020 19:26:19 GMT):
it would be nice if it was alongside the other docs, so tools like Transifex could work

pandrejko (Wed, 27 May 2020 20:00:50 GMT):
I can relay what the original decision was based on from my recollection: - There was a concern about the the additional GitHub PR and Issue tracking "noise", potentially in other languages, that it would introduce to Fabric repo. - Also, there was a concern about the translate effort being abandoned in any language. But maybe that is normal for open source? See an example of Mozilla translation status here https://pontoon.mozilla.org/projects/mdn/ - We have no way to validate or address the quality of the translations. The Chinese translation was done as a POC and now we see some traction being gained with other languages which is fantastic. I'm not entirely opposed to merging it into the Fabric docs as long as the Fabric Maintainers understand the considerations listed above. I'm unclear though how the maintainers list would work for each language. (Sorry I was not able to be on the call this morning due to a conflict with another standing meeting at the same time.)

dave.enyeart (Fri, 29 May 2020 12:53:20 GMT):
Hello, we are about ready to release v2.1.1 with some fixes on top of v2.1, does anybody else want to merge anything before releasing?

dave.enyeart (Fri, 29 May 2020 12:54:54 GMT):
@baohua @yacovm @jyellick @guoger I see https://github.com/hyperledger/fabric/pull/1311 is about ready on master... what's your assessment of criticality/risk of getting it backported to release-2.1?

guoger (Fri, 29 May 2020 16:28:56 GMT):
it can only be reproduced (deterministically though) in a very corner case, which IMO is not critical enough to block release. We could use some more time to massage the tests. @dave.enyeart

yacovm (Fri, 29 May 2020 22:19:18 GMT):
It's not critical since you need to shoot yourself in the foot to reproduce it ;)

dave.enyeart (Mon, 01 Jun 2020 11:56:47 GMT):
Ok, since the PR hasn't moved since last week, we'll go ahead with v2.1.1 release now.

dave.enyeart (Mon, 01 Jun 2020 11:57:14 GMT):
v2.1.1 release commit: https://github.com/hyperledger/fabric/pull/1357

dave.enyeart (Mon, 01 Jun 2020 11:57:14 GMT):
Fabric v2.1.1 released: https://github.com/hyperledger/fabric/releases/tag/v2.1.1

jramps9 (Tue, 09 Jun 2020 15:53:14 GMT):
Hi Fabric maintainers! Reminder the Marketing Committee-Dev Relations call is tomorrow, 6/10 at 9am PT. Hope to see you there! https://wiki.hyperledger.org/display/Marketing/2020-06-010+Meeting+notes

dave.enyeart (Wed, 10 Jun 2020 12:45:27 GMT):
@here contributor meeting in 15 minutes

dave.enyeart (Wed, 10 Jun 2020 12:45:40 GMT):
Agenda - Release Update, Samples Update, WASM RFC. Anything else?

dave.enyeart (Wed, 10 Jun 2020 13:00:25 GMT):
@here meeting starting https://zoom.us/my/hyperledger.community.3

rmnattas (Wed, 10 Jun 2020 17:17:24 GMT):
Has joined the channel.

mbwhite (Thu, 11 Jun 2020 09:29:14 GMT):
Hello; based on the contributor call yesterday, I've added a couple of comments to the Wasm Smart Contract RFC based on discussion. Based on this can ask the maintainers to indicate agreement on the PR as-per the RFC process; thanks!! https://github.com/hyperledger/fabric-rfcs/pull/28

dtomczyk (Thu, 11 Jun 2020 15:46:51 GMT):
Has joined the channel.

rjones (Fri, 12 Jun 2020 20:23:23 GMT):
Hi, @pandrejko @odowdaibm @nikhilgupta @cmgabriel @joe-alewine - any reason not to merge the Chinese, Japanese, and Malayalam doc translations into the main repo? I think it would be great to bring all the docs under one roof, so-to-speak. I've pestered @lehors about it before

cmgabriel (Fri, 12 Jun 2020 20:23:23 GMT):
Has joined the channel.

rjones (Fri, 12 Jun 2020 20:25:39 GMT):
I see it was on the agenda for the 27-MAY-2020 meeting, but there's no recording AFAIK

pandrejko (Fri, 12 Jun 2020 20:31:30 GMT):
Hi Ry. We did discuss this and agreed it would be better to keep the languages in their own Fabric documentation internationalization repo instead.

pandrejko (Fri, 12 Jun 2020 20:31:30 GMT):
Hi Ry. We did discuss this and agreed it would be better to keep the languages in their own Fabric documentation internationalization repo instead. So we would use that instead of the Hyperledger Labs repo.

lehors (Fri, 12 Jun 2020 20:32:35 GMT):
@rjones, I don't know that we want it all in the same repo but when I presented the idea of having all the translations within the fabric umbrella instead of labs the idea was well received

rjones (Fri, 12 Jun 2020 20:33:14 GMT):
OK, will all of the docs split off into that repo?

rjones (Fri, 12 Jun 2020 20:33:31 GMT):
My concern is a second-class-citizen for the translations if they're kept apart.

lehors (Fri, 12 Jun 2020 20:35:06 GMT):
English will remain the reference - just like W3C for instance has translations for several of its specifications but the English version is always the reference

lehors (Fri, 12 Jun 2020 20:35:26 GMT):
this is so that in case of conflict between two versions there is no ambiguity

lehors (Fri, 12 Jun 2020 20:35:57 GMT):
one needs to know which version "wins"

rjones (Fri, 12 Jun 2020 20:36:16 GMT):
OK. Should I create a new repo for this, so that the code currently elsewhere can be under one umbrella?

lehors (Fri, 12 Jun 2020 20:37:11 GMT):
I would expect each of the existing repo under the labs to then move within the fabric umbrella, each keeping the same set of maintainers it already has

lehors (Fri, 12 Jun 2020 20:37:11 GMT):
I would expect each of the existing repos under the labs to then move within the fabric umbrella, each keeping the same set of maintainers it already has

rjones (Fri, 12 Jun 2020 20:39:47 GMT):
so a new repo for each language?

lehors (Fri, 12 Jun 2020 20:41:33 GMT):
well, is it "new" if it already exists in the labs?

lehors (Fri, 12 Jun 2020 20:41:49 GMT):
but yes, one for each language

rjones (Fri, 12 Jun 2020 20:47:22 GMT):
OK - tell me when to start moving stuff and I'll do it

rjones (Fri, 12 Jun 2020 20:47:52 GMT):
@lehors I was looking to the future, where a new language comes on board

lehors (Fri, 12 Jun 2020 20:48:13 GMT):
ah ok

lehors (Fri, 12 Jun 2020 20:53:21 GMT):
@BrettLogan who chaired the call I presented this to brought this up for discussion here, see https://chat.hyperledger.org/channel/fabric-maintainers?msg=9rywFxfZWyeHcjBZH but the discussion didn't go very far

lehors (Fri, 12 Jun 2020 20:54:53 GMT):
I think @pandrejko's recollection of the initial hesitation is correct https://chat.hyperledger.org/channel/fabric-maintainers?msg=CjEL5q2L5dWSjdf3g

lehors (Fri, 12 Jun 2020 20:55:15 GMT):
but I think it is time to move beyond our fear

lehors (Fri, 12 Jun 2020 20:56:07 GMT):
the Chinese translation group has shown dedication and there is no reason not to trust them to continue

lehors (Fri, 12 Jun 2020 20:57:17 GMT):
of course there is always a risk for a translation effort to wind down but it's no different for this than it is for any project

lehors (Fri, 12 Jun 2020 20:58:27 GMT):
and as long as we make it clear that the English version is the absolute reference the risk of confusion is pretty low

lehors (Fri, 12 Jun 2020 20:59:14 GMT):
if one translation effort were to fall behind, people would be able to see that and revert to using the English version

pandrejko (Fri, 12 Jun 2020 23:25:16 GMT):
I think we wanted 1 Fabric docs internationalization repo with each language in a folder under that.

pandrejko (Fri, 12 Jun 2020 23:25:16 GMT):
I think we wanted 1 Fabric docs internationalization repo with each language in a folder under that. But I am not sure how the maintainer approvals would work for that, because we would want different maintainers for each language. I would suggest we think through this and make sure we can do what we want before we create any new repos.

BrettLogan (Sat, 13 Jun 2020 03:02:58 GMT):
I agree with this sentiment. The original request was that it didn't make sense for the internationalization work to be part of Hyperledger Labs. From a maintenance perspective it would be far simpler to have this be a standalone repo `fabric-docs-i18n` or something of the sort. Each language would be its directory within the repo, and maintainers could be handled the CODEOWNERS process. For each language we create a GitHub team, and each team is made up of its maintainers. And then within the CODEOWNERS files, we set ownership by directory to the relevant team. We can then use mergify like we do within the Fabric repo to have them attach a `merge` label and let mergify do it's magic

BrettLogan (Sat, 13 Jun 2020 03:02:58 GMT):
I agree with this sentiment. The original request was that it didn't make sense for the internationalization work to be part of Hyperledger Labs. Pulling it our of the `hyperledger-labs` org and moving it to its own repo in `hyperledger` makes way more sense from a maintenance perspective. It would be far simpler to have this be a standalone repo `fabric-docs-i18n` or something of the sort. Each language would be its directory within the repo, and maintainers could be handled the CODEOWNERS process. For each language we create a GitHub team, and each team is made up of its maintainers. And then within the CODEOWNERS files, we set ownership by directory to the relevant team. We can then use mergify like we do within the Fabric repo to have them attach a `merge` label and let mergify do it's magic

pandrejko (Mon, 15 Jun 2020 12:18:14 GMT):
Thanks @BrettLogan I was hoping for confirmation that that was possible.

dave.enyeart (Mon, 15 Jun 2020 13:26:46 GMT):
@here Nominate Senthil as Fabric maintainer: https://github.com/hyperledger/fabric/pull/1400 , please approve if you agree.

odowdaibm (Mon, 15 Jun 2020 13:32:22 GMT):
Slightly frustrating constantly changing the approach. I would like to see this converged under a single repo, though we will need to work with quite a few teams who have started down another path under HL Labs.

odowdaibm (Mon, 15 Jun 2020 13:34:40 GMT):
Let's create the repo @BrettLogan @lehors @pandrejko and then we can discuss this week how we populate, and build. Don't get me wrong, I'm in favour -- it's just a shame we could have decided this at the outset - it's not like international languages are a surprise ;) ?

lehors (Mon, 15 Jun 2020 13:35:43 GMT):
:-)

lehors (Mon, 15 Jun 2020 13:36:27 GMT):
I suggested just moving the existing repos from the labs because I thought it would be less disruptive than forcing a merge into a single repo

odowdaibm (Mon, 15 Jun 2020 13:36:35 GMT):
I'd propose that we start the process with Renato and Br_Pt and then fold the other languages like ML etc in underneath.

lehors (Mon, 15 Jun 2020 13:37:13 GMT):
but I'm fine either with either approach

lehors (Mon, 15 Jun 2020 13:37:13 GMT):
but I'm fine with either approach

odowdaibm (Mon, 15 Jun 2020 13:37:16 GMT):
Sure -- moving existing is just fine, but I think we'd like to converge

odowdaibm (Mon, 15 Jun 2020 13:37:30 GMT):
ty @lehors

BrettLogan (Mon, 15 Jun 2020 13:58:32 GMT):
I totally agree. Sometime we let process get in the way of progress, and this was one of those times. But better to correct our past mistakes now, rather than putting it off another year I suppose. I will work with Ry to get the repo setup and configured with GitHub, read-the-docs, and CI. Can we get a vote on a name for the repo, I proposed `fabric-docs-i18n`, does this make sense, or does someone want to propose something else?

lehors (Mon, 15 Jun 2020 13:59:26 GMT):
SGTM

odowdaibm (Mon, 15 Jun 2020 14:04:53 GMT):
OK, we're agreed - let's use that and we can start by incorporating Br_Pt. Once you have it in place, let me know, and I will do a doc update for this new process. Ty @BrettLogan @lehor

odowdaibm (Mon, 15 Jun 2020 16:35:22 GMT):
benchamrk file you mean?

rjones (Mon, 15 Jun 2020 17:09:44 GMT):
@odowdaibm pt_BR ?

rjones (Mon, 15 Jun 2020 17:10:07 GMT):
https://lh.2xlibre.net/locale/pt_BR/ for instance

rjones (Mon, 15 Jun 2020 17:17:14 GMT):
@SaraG here is the discussion on i18n for Fabric - Iroha might use this model?

SaraG (Mon, 15 Jun 2020 17:17:15 GMT):
Has joined the channel.

odowdaibm (Mon, 15 Jun 2020 18:17:09 GMT):
@rjones yes that's right. Renato is staring a Pt_Br translation but hasn't yet requested a HL Labs repo -- would could populate the i18n repo with his as a pro-forma for others -- to get us going with an examplar. I've asked Renato to join the chat

odowdaibm (Mon, 15 Jun 2020 18:17:09 GMT):
@rjones yes that's right. Renato is staring a Pt_Br translation but hasn't yet requested a HL Labs repo -- we could populate the i18n repo with his as a pro-forma for others -- to get us going with an exemplar. I've asked Renato to join the chat

rjones (Mon, 15 Jun 2020 19:13:35 GMT):
https://github.com/hyperledger/fabric-docs-i18n ?

rjones (Mon, 15 Jun 2020 19:13:38 GMT):
https://github.com/hyperledger/fabric-docs-i18n

BrettLogan (Mon, 15 Jun 2020 19:20:10 GMT):
Thank you @rjones, I will get CI and stuff set up for it

odowdaibm (Tue, 16 Jun 2020 06:08:25 GMT):
Great - this looks fine @rjones I will update docs with @pandrejko later in the week, and create some instructions. Thanks.

odowdaibm (Tue, 16 Jun 2020 07:26:09 GMT):
Making @renatost aware, as leader for Br-Pt

renatost (Tue, 16 Jun 2020 07:26:09 GMT):
Has joined the channel.

renatost (Tue, 16 Jun 2020 12:11:15 GMT):
Thanks Anthony and hello everyone! I will glad to work on this action and we can use the pt_BR translantion as a pilot for this new process for sure.

rjones (Tue, 16 Jun 2020 17:06:51 GMT):
let me know if you need a hand, or if you're blocked.

renatost (Tue, 16 Jun 2020 18:30:17 GMT):
Hi @rjones , I really appreciate have your support in this moment. I created a fork and added the last version of pt_BR translation code (https://github.com/rst77/fabric-docs-i18n) in it. Now I just need to create a PR asking the merge?

renatost (Tue, 16 Jun 2020 18:36:10 GMT):
Or I need to create on JIRA issue also?

rjones (Tue, 16 Jun 2020 18:47:10 GMT):
just create a PR

rjones (Tue, 16 Jun 2020 18:48:31 GMT):
@renatost as far as JIRA issues - that's a fabric thing; the code merge is via PR. I defer to Andrew and Pam on JIRA

renatost (Tue, 16 Jun 2020 18:55:51 GMT):
Done, any questions let me know...

rjones (Tue, 16 Jun 2020 18:59:50 GMT):
OK. I see that the code reviewers have been added. https://github.com/hyperledger/fabric-docs-i18n/pull/2 shows two groups added

renatost (Tue, 16 Jun 2020 19:05:25 GMT):
Yes, was defined automatically. I only filled the PR description.

odowdaibm (Wed, 17 Jun 2020 08:50:56 GMT):
Right now, a single JIRA might help mark the work item, but I wouldn't worry too much about it. Later it will help to organize translation activities into separate JIRAs. Maybe a single placeholder right help -- Something a bit like this Renato: https://jira.hyperledger.org/browse/FAB-17967

odowdaibm (Wed, 17 Jun 2020 08:50:56 GMT):
Right now, a single JIRA might help mark the work item, but I wouldn't worry too much about it. Later it will help to organize translation activities into separate JIRAs. Maybe a single placeholder might help for your work right now Renato. Something a bit like this https://jira.hyperledger.org/browse/FAB-17967 You can then refer to it in your PRs, and notify others as you make progress.

dave.enyeart (Thu, 18 Jun 2020 19:29:34 GMT):
Here's my plan for v2.2 timing...

dave.enyeart (Thu, 18 Jun 2020 19:29:42 GMT):
End of dev and create release-2.2 branch Friday June 26th.

dave.enyeart (Thu, 18 Jun 2020 19:29:50 GMT):
Soft landing - don't drop any bombs the days before.

dave.enyeart (Thu, 18 Jun 2020 19:29:56 GMT):
Stabilization and final fixes in release-2.2 branch by Friday July 3rd (holiday in US).

dave.enyeart (Thu, 18 Jun 2020 19:30:02 GMT):
Cut release July 8th.

SaraG (Fri, 19 Jun 2020 08:36:39 GMT):
Thank you!

SaraG (Fri, 19 Jun 2020 08:37:11 GMT):
Hi! So do I understand it correctly that it was decided on not using any CATs?

dave.enyeart (Wed, 24 Jun 2020 12:29:57 GMT):
@here Contributor meeting in 30 minutes.

dave.enyeart (Wed, 24 Jun 2020 12:30:01 GMT):
Agenda topics - Release update - Deprecations - Documentation update

dave.enyeart (Wed, 24 Jun 2020 12:30:01 GMT):
Agenda topics - Release update - Deprecations discussion - Documentation update

dave.enyeart (Wed, 24 Jun 2020 12:30:04 GMT):
Anything else?

dave.enyeart (Wed, 24 Jun 2020 13:00:01 GMT):
@here meeting starting : https://zoom.us/my/hyperledger.community.3

jyellick (Wed, 24 Jun 2020 13:21:28 GMT):
Can we please follow the instructions noted here https://techcrunch.com/2020/03/20/psa-yes-you-can-join-a-zoom-meeting-in-the-browser/ to fix our host settings to display a link to join from a browser rather than requiring a random closed source app to participate? I stumbled across joining in the browser when the old client refused to join new meetings -- a much nicer experience. With a little fighting, it's possible to do this manually, by rewriting the `*.zoom.us/j//*` to `*.zoom.us/wc//join`, but it would make everyone's life easier if the join link actually displayed this option.

BrettLogan (Wed, 24 Jun 2020 15:49:14 GMT):
I'll ask Ry to do this for us

BrettLogan (Wed, 24 Jun 2020 15:49:14 GMT):
I'll ask LF to do this for us

rjones (Wed, 24 Jun 2020 15:51:12 GMT):
Hi! I'm LF. do what?

rjones (Wed, 24 Jun 2020 15:52:12 GMT):
I turned on "require zoom account" for web joining a while ago.

jyellick (Wed, 24 Jun 2020 15:52:13 GMT):
Looks like you can enable the LF zoom account to display "join via the web" links, so that in order to join the community calls, you can just use a browser, rather than install the Zoom client (which is pretty awful on Linux, for instance, and closed source).

rjones (Wed, 24 Jun 2020 15:52:17 GMT):
because... reasons.

jyellick (Wed, 24 Jun 2020 15:53:17 GMT):
At least in my browser, when you click on a link like https://zoom.us/my/hyperledger.community.3 it basically says "open in the zoom app, or download the zoom app"

jyellick (Wed, 24 Jun 2020 15:53:32 GMT):
But we should be able to make it say "Or join via the web" or something like that

jyellick (Wed, 24 Jun 2020 15:54:12 GMT):
Which, especially for an OSS project, requiring the zoom app to participate seems like an unnecessary barrier, when the web client works just fine.

rjones (Wed, 24 Jun 2020 15:55:40 GMT):
That was already enabled on 2 of the 3 zoom accounts, I've enabled it on the other

jyellick (Wed, 24 Jun 2020 15:55:42 GMT):
You _can_ join via the web client, if you go through the web client, and explicitly enter the meeting ID. But, it's sufficiently hard, and you have to know to do it. At least according to the original link, there's an account setting which will provide web links in addition to app links (whereas only the latter is available by default).

jyellick (Wed, 24 Jun 2020 15:55:56 GMT):
Great, thanks @rjones

rjones (Wed, 24 Jun 2020 15:56:29 GMT):
of course, only `.3` didn't have it

BrettLogan (Wed, 24 Jun 2020 15:58:32 GMT):
Thank Ry!

BrettLogan (Wed, 24 Jun 2020 15:58:32 GMT):
Thanks Ry!

rjones (Wed, 24 Jun 2020 16:09:54 GMT):
The fact that there was only 1 of 3 accounts that didn't have that set was the source of my confusion above

dave.enyeart (Wed, 24 Jun 2020 17:11:26 GMT):
so do we need to provide people a different link?

BrettLogan (Wed, 24 Jun 2020 17:12:03 GMT):

Clipboard - June 24, 2020 1:12 PM

BrettLogan (Wed, 24 Jun 2020 17:12:11 GMT):
No, the link now appears on the launch page

BrettLogan (Wed, 24 Jun 2020 17:12:23 GMT):
It did not before

dave.enyeart (Wed, 24 Jun 2020 17:13:53 GMT):
hmmm, i still don't see that browser option when i click on https://zoom.us/my/hyperledger.community.3

dave.enyeart (Wed, 24 Jun 2020 17:14:27 GMT):
maybe because i already have the client?

BrettLogan (Wed, 24 Jun 2020 17:14:45 GMT):
You have the client installed, in order to see it you have to click `launch meeting` on that page and then you will be able to see it

rjones (Wed, 24 Jun 2020 17:15:04 GMT):
huh. I opened it in a private window and it didn't show a link

BrettLogan (Wed, 24 Jun 2020 17:16:22 GMT):
I'm seeing what happens on a VM without the client installed at all

dave.enyeart (Wed, 24 Jun 2020 17:20:31 GMT):
i had to use a different browser, select don't allow, then select launch meeting, then cancel out the client, and now I see the web link :)

BrettLogan (Wed, 24 Jun 2020 17:26:01 GMT):
Yea, so if you dont have the client, you still need to click the launch meeting button

jyellick (Wed, 24 Jun 2020 17:26:06 GMT):
Yeah, you apparently have to click "If you have the zoom client installed, launch meeting"

jyellick (Wed, 24 Jun 2020 17:26:17 GMT):
Which seems like just awful UX, since... you can launch the meeting without the client

BrettLogan (Wed, 24 Jun 2020 17:26:18 GMT):
Guess thats better than nothing

jyellick (Wed, 24 Jun 2020 17:26:31 GMT):
But a least now I won't have to manually rewrite the URL

jyellick (Wed, 24 Jun 2020 17:26:31 GMT):
But at least now I won't have to manually rewrite the URL

BrettLogan (Wed, 24 Jun 2020 17:26:53 GMT):
Does Zoom have a linux client?

jyellick (Wed, 24 Jun 2020 17:27:00 GMT):
It does, and it's awful

rjones (Wed, 24 Jun 2020 17:27:45 GMT):
what are your thoughts about setting up an actual Zoom meeting instead of using the personal meeting room?

jyellick (Wed, 24 Jun 2020 17:27:45 GMT):
It tries to float a preview of the UI when I switch to other workspaces. Then, when I switch back, it doesn't notice that the window has focus, and I have to manually return it.

jyellick (Wed, 24 Jun 2020 17:28:16 GMT):
I'm not sure what the difference between "an actual Zoom meeting", and the "personal meeting room" is?

BrettLogan (Wed, 24 Jun 2020 17:28:56 GMT):
It becomes a recurring event, and with that I think the output of the meeting actually includes all the relevant info in the invite

rjones (Wed, 24 Jun 2020 17:28:59 GMT):
It would have a new URL, and have distinct settings. I'm thinking about doing it with the TSC call

rjones (Wed, 24 Jun 2020 17:29:17 GMT):
I don't want to make the world worse, so I won't do anything this week

BrettLogan (Wed, 24 Jun 2020 17:29:52 GMT):
Cant be worse than when we got locked out of Zoom and had to use our IBM WebEx to host the meetings lol

dave.enyeart (Wed, 24 Jun 2020 17:29:57 GMT):
i personally like the personal meeting https://zoom.us/my/hyperledger.community.3 , very simple (at least for those of us not using linux)

dave.enyeart (Wed, 24 Jun 2020 17:30:44 GMT):
and it is not used much by other projects so we can use it often

dave.enyeart (Wed, 24 Jun 2020 17:30:44 GMT):
and it is not used much by other projects so we can re-use it often

BrettLogan (Wed, 24 Jun 2020 17:30:58 GMT):
That link would still work, as the meeting is specific to a room, isn't it Ry? Its a recurring event on the room

BrettLogan (Wed, 24 Jun 2020 17:31:29 GMT):
I could be wrong, just going off my experience of setting it up for my mother in law to host here classes online

BrettLogan (Wed, 24 Jun 2020 17:31:29 GMT):
I could be wrong, just going off my experience of setting it up for my mother in law to host her classes online

rjones (Wed, 24 Jun 2020 17:32:06 GMT):
well I don't know and I'm super not into more Zoom tech support :)

BrettLogan (Wed, 24 Jun 2020 17:32:11 GMT):
HA

rjones (Wed, 24 Jun 2020 18:03:08 GMT):
WRT your call this morning - might [minifab](https://github.com/litong01/minifabric) solve some of the "play with it" space?

jyellick (Wed, 24 Jun 2020 18:21:19 GMT):
I wasn't able to chime in, because the zoom android client (which I was using until I could figure out the web-client link) wouldn't let my audio through, but you absolutely can migrate from Solo to Raft. In fact, we have an integration test that covers it.

jyellick (Wed, 24 Jun 2020 18:22:17 GMT):
We don't advertise this feature in the doc, because it's more work to migrate from Solo to Raft, than to just start as a single node Raft, but, I do think it's worth noting that users haven't entirely backed themselves into an inescapable corner if they use Solo for a production system accidentally.

jyellick (Wed, 24 Jun 2020 18:29:49 GMT):
I really don't have an issue with removing solo, if that's what we decide we want to do. But I think we need to clearly articulate why we're doing it. It is simply not a burden from a code perspective. The only real 'code' in it is about 50 lines. And its dependencies are quite limited. It's been hit a few times when import paths of protos have changed, but the last actual code change was from Sept 2018.

jyellick (Wed, 24 Jun 2020 18:30:49 GMT):
It seems the concern is that solo "confuses" users. And that we find people out there running solo who shouldn't. But, I'd suggest that this is also evidence that users find it easy to configure a solo network than a Raft network, which implies that it is providing some value to those users.

jyellick (Wed, 24 Jun 2020 18:30:49 GMT):
It seems the concern is that solo "confuses" users. And that we find people out there running solo who shouldn't. But, I'd suggest that this is also evidence that users find it easier to configure a solo network than a Raft network, which implies that it is providing some value to those users.

dave.enyeart (Wed, 24 Jun 2020 18:36:49 GMT):
The doc and orderer startup warning are pretty clear not to use Solo for production, so I'm good with keeping it. It is also nice to have at least one other simple option besides Raft, if you don't want to configure TLS, or you want to compare with Raft behavior for some reason (e.g. if you suspect a Raft bug).

dave.enyeart (Wed, 24 Jun 2020 18:39:11 GMT):
For "play with it" users, the new Test Network has proved pretty effective... it automatically brings up a small toy network if you like, and the scripts are pretty simple if you want to see how it is working or modify it.

dave.enyeart (Wed, 24 Jun 2020 18:39:43 GMT):
Tong is going to demonstrate Minifab at the next contributor meeting, so that will be a good chance to evaluate and discuss it.

rjones (Thu, 25 Jun 2020 14:45:37 GMT):
Hi. I propose archiving homebrew-fabric: the stats @BrettLogan showed me show that almost all of the downloads are me testing it out. https://github.com/hyperledger/homebrew-fabric/pull/21

BrettLogan (Fri, 26 Jun 2020 20:23:54 GMT):
ReadTheDocs now has a `Build Pull Requests` feature. It will build your doc for all Pull Requests (including on every push) and will report a check back to GitHub, and allows you to view your doc directly in readthedocs before we approve and merge anything.

BrettLogan (Fri, 26 Jun 2020 20:24:08 GMT):

Clipboard - June 26, 2020 4:24 PM

BrettLogan (Fri, 26 Jun 2020 20:24:29 GMT):
https://hyperledger-fabric--1473.org.readthedocs.build/en/1473/

BrettLogan (Fri, 26 Jun 2020 20:24:41 GMT):
Example of the check, and when you click Details, it takes you to the ReadTheDoc build for your doc

BrettLogan (Fri, 26 Jun 2020 20:24:41 GMT):
Example of the check, and when you click `Details`, it takes you to the ReadTheDoc build for your doc

BrettLogan (Fri, 26 Jun 2020 20:24:47 GMT):
I've opened this PR as a place to make comment on this (I am also going to post in RC): https://github.com/hyperledger/fabric/pull/1473

BrettLogan (Fri, 26 Jun 2020 20:24:47 GMT):
I've opened this PR as a place to make comment on this: https://github.com/hyperledger/fabric/pull/1473

BrettLogan (Fri, 26 Jun 2020 20:24:47 GMT):
I've opened this PR as a place to comment on this: https://github.com/hyperledger/fabric/pull/1473

BrettLogan (Fri, 26 Jun 2020 20:24:47 GMT):
I've enabled it as a test and opened this PR as a place to comment on this: https://github.com/hyperledger/fabric/pull/1473

rjones (Sat, 27 Jun 2020 04:13:30 GMT):
https://tinyurl.com/y82f45ux I'm working on affiliation.

dave.enyeart (Wed, 01 Jul 2020 13:04:46 GMT):
fabric v2.2 release notes for review: https://github.com/hyperledger/fabric/pull/1512

dave.enyeart (Wed, 01 Jul 2020 13:05:38 GMT):
We've talked about v2.2 being the next LTS release. Any concerns with announcing that with the release?

dave.enyeart (Wed, 01 Jul 2020 13:05:38 GMT):
We've talked about v2.2 being the next LTS release. Any concerns with announcing that with the release next week?

dave.enyeart (Wed, 01 Jul 2020 19:36:14 GMT):
We discussed deprecations on the June 24th contributor call. These deprecations have now been added to proposed v2.2 release notes, please review: https://github.com/hyperledger/fabric/pull/1512

odowdaibm (Thu, 02 Jul 2020 17:58:08 GMT):
wonderful, thanks Brett @BrettLogan

dave.enyeart (Mon, 06 Jul 2020 11:16:12 GMT):
Last call for release note and deprecation feedback: https://github.com/hyperledger/fabric/pull/1512 Release v2.2 on target for Wednesday.

dave.enyeart (Mon, 06 Jul 2020 11:16:12 GMT):
Last call for release note and deprecation feedback: https://github.com/hyperledger/fabric/pull/1512 Release v2.2 on target for Thursday.

dave.enyeart (Wed, 08 Jul 2020 12:10:24 GMT):
@here Contributor meeting next hour. Agenda - quick release update, minifabric from Tong Li. Anything else?

dave.enyeart (Wed, 08 Jul 2020 12:59:43 GMT):
@here meeting starting - https://zoom.us/my/hyperledger.community.3

dave.enyeart (Thu, 09 Jul 2020 15:34:07 GMT):
Fabric v2.2 released, all good, I'll put together the announcement

dave.enyeart (Thu, 09 Jul 2020 16:20:00 GMT):
@here I want to make sure I position LTS correctly in the release announcement, please respond if you have any edits:

dave.enyeart (Thu, 09 Jul 2020 16:20:05 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v2.2.0! v2.2 continues to build on the v2.0 foundation with additional improvements and fixes. For details, check out the release notes: https://github.com/hyperledger/fabric/releases/tag/v2.2.0 Additionally we are happy to announce that v2.2 is the next long-term support (LTS) release for Hyperledger Fabric. This means that v2.2.x will be the be the target release for most fix backports, while the most important fixes will continue to be backported to v1.4.x as well. More details of the LTS strategy can be found in the RFC that was merged earlier this year: https://github.com/hyperledger/fabric-rfcs/blob/master/text/0000-lts-release-strategy.md Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. We felt that the tag was too confusing, given that there is a combination of regular releases and LTS releases available now - the definition of 'latest' may not be the same for everyone. Give v2.2 a try and let us know what you think! https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html```

dave.enyeart (Thu, 09 Jul 2020 16:20:05 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v2.2.0! v2.2 continues to build on the v2.0 foundation with additional improvements and fixes. For details, check out the release notes: https://github.com/hyperledger/fabric/releases/tag/v2.2.0 Additionally we are happy to announce that v2.2 is the next long-term support (LTS) release for Hyperledger Fabric. v2.2.x will be the be the target release for most fix backports, while the most important fixes will continue to be backported to v1.4.x as well. More details of the LTS strategy can be found in the RFC that was merged earlier this year: https://github.com/hyperledger/fabric-rfcs/blob/master/text/0000-lts-release-strategy.md Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. We felt that the tag was too confusing, given that there is a combination of regular releases and LTS releases available now - the definition of 'latest' may not be the same for everyone. Give v2.2 a try and let us know what you think! https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html```

dave.enyeart (Thu, 09 Jul 2020 16:20:05 GMT):
```The Hyperledger Fabric maintainers are pleased to announce the availability of Fabric v2.2.0! v2.2 continues to build on the v2.0 foundation with additional improvements and fixes. For details, check out the release notes: https://github.com/hyperledger/fabric/releases/tag/v2.2.0 Additionally we are happy to announce that v2.2 is the next long-term support (LTS) release for Hyperledger Fabric. v2.2.x will be the target release for most fix backports, while the most important fixes will continue to be backported to v1.4.x as well. More details of the LTS strategy can be found in the RFC that was merged earlier this year: https://github.com/hyperledger/fabric-rfcs/blob/master/text/0000-lts-release-strategy.md Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. We felt that the tag was too confusing, given that there is a combination of regular releases and LTS releases available now - the definition of 'latest' may not be the same for everyone. Give v2.2 a try and let us know what you think! https://hyperledger-fabric.readthedocs.io/en/release-2.2/install.html```

caod (Thu, 09 Jul 2020 16:21:22 GMT):
grammar here: `This means that v2.2.x will be the be the target release for most fix backports`

dave.enyeart (Thu, 09 Jul 2020 16:22:35 GMT):
fixed

caod (Thu, 09 Jul 2020 16:22:37 GMT):
otherwise looks good :)

baohua (Thu, 09 Jul 2020 17:35:08 GMT):
Great to see v2.2 LTS is here!

dave.enyeart (Thu, 09 Jul 2020 20:42:46 GMT):
announcement sent to mailing list: https://lists.hyperledger.org/g/fabric/message/8643

Abhishekkishor (Fri, 10 Jul 2020 05:26:37 GMT):
Hello Guys, Hope you are doing well. I need your help and guidance in Hyperledger Fabric. Can you please suggest me good resources on how to generate crypto materials (manualy) using fabric ca in hyperledger? Also the answers of few questions My questions are: 1) which testing framework to use for fabric contract api chaincode (node.js) testing? 2) How to handle crypto certificates in production projects? How to generate certificates ? Where & how to store certificates ? I'll be waiting for your all your response and suggestions. Thanks & regards, Abhishek

metadata (Fri, 10 Jul 2020 05:42:35 GMT):
@Abhishekkishor ask it in #fabric group

AbhishekAadi (Fri, 10 Jul 2020 05:42:53 GMT):
Has joined the channel.

AbhishekAadi (Fri, 10 Jul 2020 05:43:33 GMT):
@metadata sure

BrettLogan (Fri, 10 Jul 2020 15:30:35 GMT):
Hey Abhishek, we are working on an example for unit-testing node chaincode. I recently publish an example for Go chaincode using `mocks` in the fabric-samples repo. We are working on the node one though. You should watch: https://github.com/hyperledger/fabric-samples/tree/master/asset-transfer-basic/chaincode-javascript

BrettLogan (Fri, 10 Jul 2020 15:30:45 GMT):
This is where the example tests will be published

BrettLogan (Fri, 10 Jul 2020 15:31:03 GMT):
You can take a look at: https://github.com/hyperledger/fabric-samples/blob/master/asset-transfer-basic/chaincode-go/chaincode/smartcontract_test.go

BrettLogan (Fri, 10 Jul 2020 15:31:56 GMT):
Which is the Go example. Essentially new the new programming model uses mocks to perform testing. In NodeJS this is achieved using: https://sinonjs.org/

chintanr11 (Mon, 13 Jul 2020 04:41:02 GMT):
Has joined the channel.

davidkhala (Mon, 13 Jul 2020 06:47:15 GMT):
Github crashs at this moment.

rjones (Mon, 13 Jul 2020 06:54:58 GMT):
yes? that's not Fabric's problem.

rjones (Mon, 13 Jul 2020 06:55:32 GMT):
https://www.githubstatus.com/

davidkhala (Wed, 15 Jul 2020 05:02:58 GMT):
Sure, it is purely Github infra problem. I posted it as a reminder

AurelienGasser1 (Thu, 16 Jul 2020 02:23:23 GMT):
Has joined the channel.

AurelienGasser1 (Thu, 16 Jul 2020 02:23:24 GMT):
> Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. Although I absolutely understand the rationale behind this change, this sudden change caught us by surprise and caused significant disruption in our production environment running HLF 1.4. Naturally, this happened at the worst possible moment for us: during a scheduled test session involving 15+ people over multiple countries. Maybe this retiring was announced before, in which case we unfortunately missed it.

AurelienGasser1 (Thu, 16 Jul 2020 02:23:24 GMT):
> Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. Although I absolutely understand and share the rationale behind this change, this sudden removal caught us by surprise and caused significant disruption in our production environment running HLF 1.4. Naturally, this happened at the worst possible moment for us: during a scheduled test session involving 15+ people over multiple countries. Maybe this retiring was announced before, in which case we unfortunately missed it. I thought this feedback might be valuable as we might not be the only having faced this inconvenience.

AurelienGasser1 (Thu, 16 Jul 2020 02:23:24 GMT):
> Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. Although I absolutely understand and share the rationale behind this change, this sudden removal caught us by surprise and caused significant disruption in our production environment running HLF 1.4. Naturally, this happened at the worst possible moment for us: during a scheduled test session involving 15+ people over multiple countries. Maybe this retiring was announced at a prior date; if that's the case then we unfortunately missed it. I thought this feedback might be valuable to you, as we might not be the only having faced this inconvenience. Thanks again for the good work.

AurelienGasser1 (Thu, 16 Jul 2020 02:23:24 GMT):
> Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. Although I absolutely understand and share the rationale behind this change, this sudden removal caught us by surprise and caused significant disruption in our production environment running HLF 1.4. Naturally, this happened at the worst possible moment for us: during a scheduled test session involving 15+ people over multiple countries. Maybe this retiring was announced at a prior date; if that's the case then we unfortunately missed it. I thought this feedback might be valuable to you, as we might not be the only users having faced this inconvenience. Thanks again for the good work.

AurelienGasser1 (Thu, 16 Jul 2020 02:23:24 GMT):
> Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. Although I absolutely understand and share the rationale behind this change, this sudden removal caught us by surprise and caused significant disruption in our production environment running HLF 1.4. Naturally, this happened at the worst possible moment for us: during a scheduled test session involving 15+ people over multiple countries. Maybe this retiring was announced at a prior date; if that's the case then we unfortunately missed it. I thought this feedback might be valuable to you as we might not be the only users having faced this inconvenience. We'll be migrating to HLF 2.x as soon as time permits. Thanks again for the good work.

AurelienGasser1 (Thu, 16 Jul 2020 02:23:24 GMT):
@dave.enyeart You wrote: > Finally, it is worth noting that the 'latest' tag on dockerhub images has been retired. Although I absolutely understand and share the rationale behind this change, this sudden removal caught us by surprise and caused significant disruption in our production environment running HLF 1.4. Naturally, this happened at the worst possible moment for us: during a scheduled test session involving 15+ people over multiple countries. Maybe this retiring was announced at a prior date; if that's the case then we unfortunately missed it. I thought this feedback might be valuable to you as we might not be the only users having faced this inconvenience. We'll be migrating to HLF 2.x as soon as time permits. Thanks again for the good work.

Kelvin_Moutet (Thu, 16 Jul 2020 12:37:31 GMT):
Has joined the channel.

cmgabriel (Mon, 20 Jul 2020 17:31:31 GMT):
For working with the Fabric CA, try this: https://hyperledger-fabric-ca.readthedocs.io/en/latest/

AbhishekAadi (Mon, 20 Jul 2020 18:39:20 GMT):
@cmgabriel thanks

dave.enyeart (Mon, 20 Jul 2020 20:46:18 GMT):
The retirement of `latest` tag on dockerhub has tripped up some v1.4 deployments since by default peer tries to use `fabric-ccenv:latest` for building chaincode. Therefore we're thinking we'll go ahead and release a Fabric v1.4.8 to get the default updated to use `fabric-ccenv:1.4` (plus there's some other minor fixes since v1.4.7 got released two months ago)

dave.enyeart (Mon, 20 Jul 2020 20:46:27 GMT):
See release notes: https://github.com/hyperledger/fabric/pull/1621

dave.enyeart (Tue, 21 Jul 2020 21:15:41 GMT):
At the contributor meeting on Wednesday we'll see if there are any last minute backports for release-1.4, then plan to release v1.4.8

dave.enyeart (Tue, 21 Jul 2020 21:15:51 GMT):
Any other topics for contributor meeting?

dave.enyeart (Wed, 22 Jul 2020 12:59:54 GMT):
@here Fabric contributor meeting starting: https://zoom.us/my/hyperledger.community.3

kleebeard (Wed, 22 Jul 2020 20:53:16 GMT):
Has joined the channel.

dave.enyeart (Wed, 22 Jul 2020 21:41:35 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v1.4.8 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/8703 ----------------------------------------------------------------------

egits (Tue, 04 Aug 2020 15:03:25 GMT):
Has joined the channel.

davidkhala (Wed, 05 Aug 2020 04:51:47 GMT):
Could I add a topic to contributor meeting 10 hours later?

davidkhala (Wed, 05 Aug 2020 05:57:51 GMT):
proposed topic: a npm package as admin capability portion presenter name: yuxiang Liu, David Expected duration: 30 mins

dave.enyeart (Wed, 05 Aug 2020 12:02:44 GMT):
@davidkhala sounds good

dave.enyeart (Wed, 05 Aug 2020 12:03:52 GMT):
@here At today's contributor meeting in one hour, we'll quickly review the Fabric Roadmap at https://jira.hyperledger.org/secure/Dashboard.jspa?selectPageId=10104#Filter-Results/12436 , then move on to David's proposal.

davidkhala (Wed, 05 Aug 2020 12:42:27 GMT):
Thanks Dave, I will keep it slim.

dave.enyeart (Wed, 05 Aug 2020 12:59:00 GMT):
@here Contributor meeting starting: https://zoom.us/my/hyperledger.community.3

rjones (Wed, 05 Aug 2020 15:20:22 GMT):
https://youtu.be/cyUalVLx3xU

rjones (Wed, 05 Aug 2020 15:20:22 GMT):
[05 AUG 2020 contributor call video](https://youtu.be/cyUalVLx3xU)

dave.enyeart (Wed, 05 Aug 2020 18:30:44 GMT):
@rjones I post all contributor meetings here: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2020. Are you going to post all meetings to youtube going forward?

rjones (Wed, 05 Aug 2020 18:35:10 GMT):
I haven't made a decision, but youtube can't be exclusive due to market restrictions.

rjones (Wed, 05 Aug 2020 18:35:25 GMT):
I thought the YouTube link is easier to digest, add links to timestamps, and the like.

rjones (Wed, 05 Aug 2020 18:35:38 GMT):
If the videos don't get any traction, I'm not going to do extra work :)

jramps9 (Tue, 11 Aug 2020 00:09:16 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT this Weds 8/12. Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-08-12+Meeting+notes

davidkhala (Sun, 16 Aug 2020 14:14:53 GMT):
@dave.enyeart proposed topic: modular interface for crypto service in Fabric presenter name: yuxiang Liu, David; jiannan Guo, Jay Expected duration: 40 mins

dave.enyeart (Wed, 19 Aug 2020 12:36:55 GMT):
@here Contributor meeting at the top of the hour

dave.enyeart (Wed, 19 Aug 2020 12:37:07 GMT):
We'll do a ledger checkpoint early playback

dave.enyeart (Wed, 19 Aug 2020 12:37:38 GMT):
@davidkhala you could present yours afterwards, or in two weeks, your choice

dave.enyeart (Wed, 19 Aug 2020 12:37:51 GMT):
Any other agenda topics?

davidkhala (Wed, 19 Aug 2020 12:41:53 GMT):
emm, I am discussing with Jay

davidkhala (Wed, 19 Aug 2020 12:57:24 GMT):
We prefer to present our topics in the call two weeks later

davidkhala (Wed, 19 Aug 2020 12:57:24 GMT):
@dave.enyeart We prefer to present our topics in the call two weeks later

dave.enyeart (Wed, 19 Aug 2020 12:59:39 GMT):
ok

dave.enyeart (Wed, 19 Aug 2020 13:01:25 GMT):
@here contributor meeting starting: https://zoom.us/my/hyperledger.community.3

rjones (Thu, 20 Aug 2020 16:42:56 GMT):
Hi. I've been asked to enable org-level projects on GitHub - you can have up to 25 repos linked to a project. You might take a look? It would delegate a lot of management away from, well, me. https://github.com/orgs/hyperledger/projects

davidkhala (Fri, 21 Aug 2020 02:01:04 GMT):
Github Project is good one but to me it is somehow works similar to JIRA issue. So I think maintainer will chose either one of it as focus.

davidkhala (Fri, 21 Aug 2020 02:01:04 GMT):
Github Project is good one but to me it somehow works similar as JIRA issue. So I think maintainer will chose either one of it as focus.

troyronda (Wed, 26 Aug 2020 13:37:48 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-go?msg=Gpt4hS2tXxbMTFhW2

donnie.stewart (Thu, 27 Aug 2020 16:16:03 GMT):
Has joined the channel.

donnie.stewart (Fri, 28 Aug 2020 19:10:14 GMT):
Hey everyone, I am Setting up the development environment to build fabric and I keep getting this error:`DEP: Checking for dependency issues.. ./scripts/check_deps.sh Building golang.org/x/tools/cmd/goimports -> goimports LINT: Running code checks.. ./scripts/golinter.sh Checking with gofmt Checking with goimports ./scripts/golinter.sh: line 29: goimports: command not found make: *** [linter] Error 127 ` Can anyone help with solving this issue?

dave.enyeart (Wed, 02 Sep 2020 12:19:19 GMT):
@here Fabric Contributor meeting next hour, agaenda: Modular interface for crypto service in Fabric - David Liu, Jay Guo @davidkhala @guoger Fabric doc, peer deployment guide - Joe Alewine @joe-alewine

dave.enyeart (Wed, 02 Sep 2020 12:19:19 GMT):
@here Fabric Contributor meeting next hour, agenda: Modular interface for crypto service in Fabric - David Liu, Jay Guo @davidkhala @guoger Fabric doc, peer deployment guide - Joe Alewine @joe-alewine

dave.enyeart (Wed, 02 Sep 2020 12:59:50 GMT):
@here meeting starting - https://zoom.us/my/hyperledger.community.3

davidkhala (Wed, 02 Sep 2020 14:22:21 GMT):
@dave.enyeart Sorry to everyone, I am occupied in another meeting until this moment .:disappointed_relieved:

davidkhala (Wed, 02 Sep 2020 16:35:17 GMT):
Could we have another chance to speak at next time?

dave.enyeart (Fri, 04 Sep 2020 14:45:31 GMT):
@davidkhala yes, I pushed yours to the Sept 16th meeting - https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2020

rjones (Fri, 04 Sep 2020 15:14:20 GMT):
@dave.enyeart I'd like some guidance on which meetings you, the maintainers, want in the `/dev/weekly` email announcements.

jramps9 (Mon, 14 Sep 2020 17:36:37 GMT):
Hello Fabric Maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT on 9/16 this week. Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-09-16+Meeting+notes

dave.enyeart (Tue, 15 Sep 2020 11:34:43 GMT):
Do you want recurring meetings in that announcement? probably the most important is the every other week Fabric contributor meeting, but there are also recurring meetings for Fabric app developers, documentation workgroup, and samples workgroup.

dave.enyeart (Tue, 15 Sep 2020 11:37:41 GMT):
@here We intend to release v2.2.1 and v1.4.9 fix releases in the coming days, aligned with our LTS release strategy. There are also some fixes queued up in release-2.1, so we could do a final v2.1.2 release as well. Alternatively just recommend everybody shift to v2.2 LTS since there are no breaking changes. Thoughts?

davidkhala (Tue, 15 Sep 2020 12:34:28 GMT):
@dave.enyeart Does it mean there are some fixes done in 2.2.x back ported to v2.1.x?

rjones (Tue, 15 Sep 2020 14:01:28 GMT):
take a look at the archive - I've been adding samples, docs, and app dev

rjones (Tue, 15 Sep 2020 14:01:51 GMT):
https://wiki.hyperledger.org/display/HYP/2020

rjones (Tue, 15 Sep 2020 14:02:21 GMT):
https://wiki.hyperledger.org/pages/viewpage.action?pageId=39618472 is the most recent

dave.enyeart (Tue, 15 Sep 2020 15:12:22 GMT):
yes, the most important fixes were also backported to release-2.1 branch, since we know some deployments went to v2.1 prior to v2.2 LTS release, so we could cut a v2.1.2, but at the same time we want to encourage all production users to be on a LTS release.

dave.enyeart (Wed, 16 Sep 2020 11:07:47 GMT):
Probably should have been doing this all along... but for Fabric Contributor Meeting reminder and agenda I'll start posting to mailing list

dave.enyeart (Wed, 16 Sep 2020 11:07:52 GMT):
Today's meeting: https://lists.hyperledger.org/g/fabric/message/9020

dave.enyeart (Wed, 16 Sep 2020 12:59:47 GMT):
@here Contributor meeting starting: https://zoom.us/my/hyperledger.community.3

lehors (Wed, 16 Sep 2020 13:17:07 GMT):
frustrating, I can hear you guys just fine...

lehors (Wed, 16 Sep 2020 13:17:22 GMT):
I'm fine with the plan and will open a Jira for it

lehors (Wed, 16 Sep 2020 13:17:59 GMT):
we do have a sample for the external builder with an extensive README that should give a good starting point for the doc

lehors (Wed, 16 Sep 2020 13:18:30 GMT):
thanks

mbwhite (Fri, 18 Sep 2020 13:19:37 GMT):
[ANN] We've formally released the Tech Preview of the Rust Smart Contracts and Wasm Chaincode Today; read more here https://lists.hyperledger.org/g/fabric/message/9031 and watch the demo https://www.youtube.com/watch?v=9QChDsuKwgc&feature=youtu.be

rjones (Tue, 22 Sep 2020 14:39:42 GMT):
Howdy, folks. Any blockers for setting up https://github.com/hyperledger/fabric-website to render on https://fabric.hyperledger.org? should I put some placeholder content there?

rjones (Thu, 24 Sep 2020 14:57:09 GMT):
Howdy. Currently, the permissions on https://github.com/hyperledger/fabric-rfcs/ only allow merges from admins and release managers, not Fabric maintainers. Is this on purpose, or an oversight? @C0rWin is trying to merge https://github.com/hyperledger/fabric-rfcs/pull/35 but doesn't have the permissions he expects.

C0rWin (Thu, 24 Sep 2020 14:59:20 GMT):
I have figured it out, the merge policy requires 3 maintainers to review and approve, I've overlooked that part

rjones (Thu, 24 Sep 2020 14:59:43 GMT):
Well, maybe it should, but it doesn't. The current permissions only require one approval.

C0rWin (Thu, 24 Sep 2020 15:02:43 GMT):
em, this what I was told

rjones (Thu, 24 Sep 2020 15:03:24 GMT):
two groups have merge bits: fabric-admins, fabric-release-managers. The current settings require one approval to merge any change.

rjones (Thu, 24 Sep 2020 15:03:36 GMT):
if it is supposed to be three, I need to change that.

dave.enyeart (Wed, 30 Sep 2020 12:02:16 GMT):
@rjones Since maintainers of any Fabric repo can approve RFCs, we didn't want to use only the Fabric project maintainers. So we kept it judgement based, with the recommendation that we get three maintainers from any project to approve before merging. If it is not difficult for you to enforce that by adding all the existing maintainer groups, that would be fine. Otherwise the admins and release managers can watch over it.

dave.enyeart (Wed, 30 Sep 2020 12:02:16 GMT):
@rjones Since maintainers of any Fabric repo can approve RFCs, we didn't want to use only the core Fabric project maintainers. So we kept it judgement based, with the recommendation that we get three maintainers from any project to approve before merging. If it is not difficult for you to enforce that by adding all the existing maintainer groups, that would be fine. Otherwise the admins and release managers can watch over it.

dave.enyeart (Wed, 30 Sep 2020 12:02:16 GMT):
@rjones Since maintainers of any Fabric repo can approve RFCs, we didn't want to use only the core Fabric project maintainers. So we kept it judgement based, with the recommendation that we get three maintainers from any project to approve before merging (one author/sponsor and two others). If it is not difficult for you to enforce that by adding all the existing maintainer groups, that would be fine. Otherwise the admins and release managers can watch over it.

dave.enyeart (Wed, 30 Sep 2020 12:16:41 GMT):
Note - We are expecting to release Fabric v1.4.9 and v2.2.1, and Fabric CA v1.4.9 this afternoon.

dave.enyeart (Wed, 30 Sep 2020 12:59:03 GMT):
@here Contributor meeting starting - https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

dave.enyeart (Wed, 30 Sep 2020 12:59:13 GMT):
Note that passwords are now required

rjones (Wed, 30 Sep 2020 13:16:21 GMT):
@dave.enyeart OK

rjones (Wed, 30 Sep 2020 13:27:14 GMT):
@dave.enyeart I'll leave the permissions on `fabric-rfcs` as is

troyronda (Wed, 30 Sep 2020 13:59:45 GMT):
In today's contributor call during the gateway service topic, I mentioned that we have built a transaction service into our (extended) Fabric peers. This service (based on fabric-sdk-go) enables a peer to sign proposals, collect endorsements, and submit to an orderer. The base transaction service code is here: https://github.com/trustbloc/fabric-peer-ext/tree/master/pkg/txn One of our uses of this service is to enable decentralized identifier (DID) operations. We have a higher layer REST API for decentralized identifier operations that is exposed by the peer. These operations result in peers obtaining endorsement for batches of these operations and submitting to the orderer. As such, the signing is performed by the peer. Here is the API for these decentralized identifiers: https://trustbloc.github.io/sidetree-fabric/docs/api/

troyronda (Wed, 30 Sep 2020 13:59:45 GMT):
In today's contributor call during the gateway service topic, I mentioned that we have built a transaction service into our (extended) Fabric peers. This service (based on fabric-sdk-go) enables a peer to sign proposals, collect endorsements, and submit to an orderer. The base transaction service code is here: https://github.com/trustbloc/fabric-peer-ext/tree/master/pkg/txn One of our uses of this service is to enable decentralized identifier (DID) operations. We have a higher layer REST API for decentralized identifier operations that is exposed by the peer. These operations result in peers obtaining endorsement for batches of these operations and submitting to the orderer. Here is the API for these decentralized identifiers: https://trustbloc.github.io/sidetree-fabric/docs/api/

bestbeforetoday (Wed, 30 Sep 2020 14:59:15 GMT):
Thanks for sharing, Troy. That's really interesting

bestbeforetoday (Wed, 30 Sep 2020 15:14:09 GMT):
One significant difference jumping out at me between this and the Fabric Gateway proposal is that (if I'm understanding correctly?) the transaction service has its own identity and is signing transactions on behalf of many clients. The intent with Fabric Gateway is that clients still sign their own proposals and transactions, with the gateway just doing the legwork of getting those proposals endorsed and "queries" executed by the right peers

bestbeforetoday (Wed, 30 Sep 2020 16:16:54 GMT):
@jmason900 I think you requested the presentation on the Fabric Gateway proposal from today's contributor call? There is now a link to an epic with the presentation attached in the meeting minutes wiki page: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2020

troyronda (Wed, 30 Sep 2020 18:22:20 GMT):
@bestbeforetoday The transaction service code has the capability of orchestrating the full transaction flow (create proposal, collect endorsements, commit/send to ordering). Note: the service is also capable of doing only the commit phase: https://github.com/trustbloc/fabric-peer-ext/blob/65f6ce7fed7d1df6bdb9b0e91263be21e16f8ac6/pkg/txn/api/service.go#L26

troyronda (Wed, 30 Sep 2020 18:28:19 GMT):
In the case of the decentralized identifier scenario I mentioned, the peer is performing the full transaction flow.

dave.enyeart (Wed, 30 Sep 2020 22:40:59 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v1.4.9 and v2.2.1 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/9088 ----------------------------------------------------------------------

greg2git (Thu, 01 Oct 2020 14:28:55 GMT):
good news, but that makes me 0.0.5 releases behind

bbehlendorf (Sun, 11 Oct 2020 18:21:08 GMT):
While trying to better inform myself on the differences between Rust, Go, and other modern stacks, I came across this piece: https://matklad.github.io//2020/09/20/why-not-rust.html This was written by a senior Rust developer, one who might ordinarily be expected to be highly defensive about their chosen language and dismissive of alternatives, or quick to couch Rust deficiencies as actually advantages or the cost of doing things "right". Instead, it's a very honest comparison that addresses both the technical issues (opinionated build system) with the more social issues (such as maturity, lack of stable ABI or specification, etc). While I've programmed in neither Rust nor Go nor plan to any time soon, I feel like if I were about to jump into a new project I'd be much better informed about whether or not to pick Rust. It's sort of like the Wikipedian "neutral point of view". It makes me much more confident that were I to pick Rust, I wouldn't be pushed into it by unreasonable claims and left holding the bag when reality hits. I can imagine a senior Go, C++, or LLVM developer reading that essay and having few things to counter or add, but not disagreeing with most of it. And, such essays are likely pretty useful when read by other core Rust devs to understand where to take the language next. Now I'm hungering for similar essays regarding other technologies... and of course, our own. Like, what would such an essay look like re Fabric? What are the valid reasons someone very well versed in Fabric might concede a different tool is better for someone or their needs? It may feel counter-intuitive for someone deep in Fabric to write a "Why Not Fabric" essay, but it would also likely be helpful to nudge more users into becoming contributors. Anyone interested in working on this, if it's not already been done?

yacovm (Mon, 12 Oct 2020 07:46:18 GMT):
For Fabric it's pretty easy- it lacks fundamental blockchain features like BFT, tokens, full anonymity, etc.

bbehlendorf (Mon, 12 Oct 2020 16:13:10 GMT):
I think a good essay would help folks understand whether those are intentional omissions based on some overarching project-wide perspective, or features that are yet to be implemented and followed other critical needs but aren't fundamentally at odds with how Fabric is architected or with that project-wide perspective.

yacovm (Mon, 12 Oct 2020 18:31:08 GMT):
Fabric's architecture is extremely modular and flexible, so there is really not technical reason why all 3 aspects I listed can't be successfully integrated. In fact, native token support was there in v2.0-alpha and then was reverted, and I know of at least one fork of Fabric [which has successfully integrated BFT](https://github.com/SmartBFT-Go/fabric/). For anonymity, I know of private forks that have integrated a PoC of full anonymity.

yacovm (Mon, 12 Oct 2020 18:31:08 GMT):
Fabric's architecture is extremely modular and flexible, so there is really no technical reason why all 3 aspects I listed can't be successfully integrated. In fact, native token support was there in v2.0-alpha and then was reverted, and I know of at least one fork of Fabric [which has successfully integrated BFT](https://github.com/SmartBFT-Go/fabric/). For anonymity, I know of private forks that have integrated a PoC of full anonymity.

davidkhala (Tue, 13 Oct 2020 01:46:18 GMT):
It reminds me some often dicussed topics. Basically it step back to question "What does Fabric refer to when critic review and comment Fabric. " Can any forks of Fabric or commerial product based on Fabric could be taken into concern? Can some in or out side of Hyperledger open source projects playing, orchestrating, helping usage of Fabric be taken in to concern? I believe it is also intented strategic position of Fabric, to trade-off between Fabric community and Fabric maintainer. And I also believe a proper response to critics can be provide a Fabric "awesome" list of these reviewed and selected third-party projects and product, right inside Fabric core documentation and timely updated by maintainers.

BrunoVavala (Tue, 13 Oct 2020 23:34:10 GMT):
Has left the channel.

vanitas92 (Wed, 14 Oct 2020 10:11:12 GMT):
That would be very helpful, I think it will set a base on what fabric is not ready at this moment and what can be improved in the future. Also, would help a bit other potential users to acknowledge what fabric is not good at in choosing a blockchain framework for their use case.

dave.enyeart (Wed, 14 Oct 2020 13:01:00 GMT):
@here contributor meeting starting - https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

VipinB (Wed, 14 Oct 2020 14:02:40 GMT):
Matklad's piece is quite interesting. Most of the piece can be tagged as problems due to the lack of maturity. It takes time and effort to create IDEs, tooling, better compilers even with loads of practitioners- Template programming in C++ needs a high degree of sophistication for example. I know because I have done it, badly in the beginning, when template support was inadequate and my own understanding was limited. As templates matured, more IDE support was available, so was standards support. In the end, I wrote several critical and generic functions using templates. I concur 100% that systems programming need not be used everywhere. Appropriate tools for the appropriate job. Similar to the use of blockchains. In this vein, Fabric as with the rest of blockchain space needs to mature with time and effort. More of the core functions of blockchain can be more easily integrated and disappears into lower layers of the stack. But a feature like tokens which is in direct conflict with the concept of channels (or in Corda the bilateral or even multi-lateral flows) may never be implemented in the substrate- but somehow riding on top. ... Eager to see a honest evaluation from a Fabric maintainer or practitioner.

jramps9 (Wed, 14 Oct 2020 14:07:15 GMT):
Hello Fabric Maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT TODAY. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-10-14+Meeting+notes

dave.enyeart (Wed, 28 Oct 2020 12:59:48 GMT):
@here contributor meeting starting - https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

jramps9 (Thu, 29 Oct 2020 13:53:19 GMT):
Hello! we're low on project news and updates for the dev/weekly newsletter going out tomorrow 10/30. If there's anything you'd like to suggest, please do so in the comments here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=41584474

troyronda (Fri, 30 Oct 2020 18:47:30 GMT):
fyi: we updated our fabric peer extension's content addressable storage (CAS) implementation to store objects and files into a Fabric network using IPFS encodings (and chunking) and using IPFS content identifiers (CIDs). https://github.com/trustbloc/fabric-peer-ext/commit/b3fd86c182126293da4e16f7e306ee90740685f8

troyronda (Fri, 30 Oct 2020 18:52:00 GMT):
we are using this capability in our implementation of a decentralized identifier (DID) registry based on DIF Sidetree.

troyronda (Fri, 30 Oct 2020 18:52:00 GMT):
we are using this capability in our implementation of a decentralized identifier (DID) registry based on DIF Sidetree. (https://github.com/trustbloc/sidetree-fabric).

davidkhala (Wed, 04 Nov 2020 14:14:57 GMT):
@troyronda interesting topic!

davidkhala (Wed, 04 Nov 2020 14:14:57 GMT):
@troyronda interesting topic! Troy, will you consider host a sharing session in coming contributor meeting about this cross-over?

jramps9 (Mon, 09 Nov 2020 18:13:26 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT on 11/11 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-11-11+Meeting+notes

Jemal (Wed, 11 Nov 2020 05:31:24 GMT):
Has joined the channel.

dave.enyeart (Wed, 11 Nov 2020 13:58:47 GMT):
@here contributor meeting starting - https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Jemal (Wed, 11 Nov 2020 14:07:43 GMT):
Has left the channel.

troyronda (Wed, 11 Nov 2020 14:09:31 GMT):
A future sharing session makes sense - we are first hoping to finish our milestone and docs.

nnAb (Mon, 16 Nov 2020 06:49:38 GMT):
Has joined the channel.

dave.enyeart (Wed, 18 Nov 2020 04:07:21 GMT):
`release-2.3` branch created from `master`. `master` will now be used for v2.4 development.

dave.enyeart (Wed, 18 Nov 2020 04:07:37 GMT):
Reminder, if there higher risk things to do, it is better to do it in master early in a release cycle. e.g. any higher risk refactoring. We also plan to update Go version and open source dependencies, @Brett has volunteered to start looking into that.

dave.enyeart (Wed, 18 Nov 2020 04:07:57 GMT):
We haven't talked about which release will be the next LTS release yet. Probably will be 2.4 or 2.5. That allows us to get some feedback on the new features like channel participation api and ledger snapshot.

dave.enyeart (Wed, 18 Nov 2020 04:08:22 GMT):
Fix PRs should generally be backported to `release-2.2`. You can also backport to `release-2.3` at your discretion, for example any channel participation api or ledger snapshot fixes would make sense to backport to `release-2.3`.

dave.enyeart (Wed, 18 Nov 2020 04:08:22 GMT):
Fix PRs should generally be backported to `release-2.2` (latest LTS release). You can also backport to `release-2.3` at your discretion, for example any channel participation api or ledger snapshot fixes would make sense to backport to `release-2.3`. And any critical fixes should go to `release-1.4` (prior LTS release).

dave.enyeart (Wed, 18 Nov 2020 04:08:30 GMT):
2.3.0 will be tagged and released on Wednesday.

dave.enyeart (Wed, 18 Nov 2020 04:08:35 GMT):
We'll likely do v1.4.10 and v2.2.2 in mid-December.

dave.enyeart (Wed, 18 Nov 2020 20:36:17 GMT):
---------------------------------------------------------------------- Hyperledger Fabric v2.3.0 RELEASE ANNOUNCEMENT: https://lists.hyperledger.org/g/fabric/message/9302 ----------------------------------------------------------------------

jramps9 (Thu, 19 Nov 2020 17:46:54 GMT):
congrats - We'll add to dev/weekly tomorrow @dave.enyeart

troyronda (Thu, 03 Dec 2020 15:08:22 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-go?msg=RXM9tumF6w44JiRwL

bur (Fri, 04 Dec 2020 13:53:24 GMT):
Hi, we are happy to share the new Fabric Private Chaincode (FPC) RFC. We have updated the FPC architecture addressing the concerns from previous discussions. Please have a look! We welcome your feedback! https://github.com/hyperledger/fabric-rfcs/pull/40

troyronda (Mon, 07 Dec 2020 15:06:43 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-go?msg=iNmPD637CC2sSfaLs

jramps9 (Mon, 07 Dec 2020 17:59:41 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT on 12/9 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-12-09+Meeting+notes

SamYuan1990 (Wed, 09 Dec 2020 11:20:27 GMT):
Has joined the channel.

davidkhala (Thu, 10 Dec 2020 04:25:13 GMT):
@dave.enyeart Dear Dave, I can not find recent 2 contributor meetings video record in confluence wiki. Have they been uploaded yet?

vanitas92 (Mon, 14 Dec 2020 09:24:20 GMT):
Hi all appreciated maintainers, i have a question regarding gossip protocol. Since v2.2 the gossip block dissemination has been deprecated in favour of pulling blocks directly from the orderer. I would like to know the reason behind this or some document documenting this decision if that is possible? Thank you very much!

yacovm (Mon, 14 Dec 2020 17:23:37 GMT):
Gossip based data dissemination is meant for huge networks with thousands of nodes, such as bitcoin. Fabric users usually deploy two-three peers in an organization, and there are not that many organizations in a typical network. It is simply not worthwhile to use gossip to send blocks because it is wasteful. You get a lot of duplication of information sent over the wire in the push/forwarding approach, and in any method that compares digests, it is slower than just pulling blocks from the orderer hence increases latency.

qpqp (Thu, 17 Dec 2020 13:49:11 GMT):
Has joined the channel.

qpqp (Thu, 17 Dec 2020 13:49:11 GMT):
Hello there everyone, like many I am coming here to seek help from other fellow hyperledger developers, I am glad I found such a place. I was wondering if any of you is familiar with the following warnings and errors inside orderers containers' logs : "slow fdata sync" "Your disk is too slow and may cause loss of quorum and trigger leadership election" "Fail to send StepRequest because send queue overflown" But then the election fails and you have no Raft leader and there is no new elections and your network isn't working until your restart your orderer containers... I am working on Hlf1.4, is anyone familiar with such a problem ?

rjones (Mon, 21 Dec 2020 16:16:45 GMT):
Howdy. [A new automerge feature is in beta at GitHub](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request); feel free to enable it per-repo if you desire.

sanket1211 (Wed, 06 Jan 2021 06:37:03 GMT):
m getting an error as ....SSL certificates cannot be trusted for orderer and peer service .....can anyone help me out to understand why is this vulnerability caused? is it something to do with docker?

jramps9 (Mon, 11 Jan 2021 15:27:37 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT on 1/13 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2021-01-13+Meeting+notes

rjones (Mon, 11 Jan 2021 17:46:26 GMT):
@dave.enyeart take a look: https://github.com/hyperledger/fabric-website/settings/access

tatsu-sato (Tue, 12 Jan 2021 22:42:55 GMT):
Hello, Fabric Maintainers. As I sent a message to the Fabric mailing list, we just released a smart contract-based system operation tool for Hyperledger Fabric-based systems named "OpsSC", which aims to enable efficient decentralized system operations across multiple organizations. https://lists.hyperledger.org/g/fabric/message/9464 We would like to contribute to the Fabric community with this OpsSC. As the first step, we want to start this as a "hyperledger-labs" project. So, now we are looking for a sponsor who could help us open a repository in hyperledger-labs. Also, we would like to introduce this OpsSC in the contributor meeting (Expected duration: 30 mins).

rjones (Thu, 14 Jan 2021 15:35:45 GMT):
Hi. @dave.enyeart , others: are there any [projects here that I could mark as read-only](https://jira.hyperledger.org/secure/project/BrowseProjects.jspa?selectedCategory=all&selectedProjectType=all&contains=fabric&sortColumn=projectCategoryId&sortOrder=ascending&s=view_projects)? Are the project owners correct (I suspect no)

dave.enyeart (Thu, 14 Jan 2021 16:47:37 GMT):
@rjones the projects all look valid with correct owner

rjones (Thu, 14 Jan 2021 16:48:54 GMT):
@dave.enyeart thanks. @BrettLogan jumped in and gave me a hand to update them :)

troyronda (Thu, 14 Jan 2021 17:57:43 GMT):
PR for fabric-sdk-go 1.0.0: https://github.com/hyperledger/fabric-sdk-go/pull/160

troyronda (Thu, 14 Jan 2021 17:58:13 GMT):
Following up from the announcement on the mailing list: https://lists.hyperledger.org/g/fabric/message/9367

pandrejko (Thu, 14 Jan 2021 19:07:58 GMT):
zoom

dave.enyeart (Tue, 19 Jan 2021 16:39:21 GMT):
@tatsu-sato sorry i missed your message last week - could you present at contributor meeting tomorrow (January 20th)

tatsu-sato (Tue, 19 Jan 2021 22:15:44 GMT):
@dave.enyeart Thank you for you response. We are going to join the contributor meeting tomorrow to introduce our OpsSC. We will present this with the following materials: - Slides: https://github.com/satota2/fabric-opssc-materials/blob/main/materials/OpsSC_for_Hyperledger_Fabric_v2.x_pub.pdf - Demo movies: https://github.com/satota2/fabric-opssc-materials#demo-movies

dave.enyeart (Wed, 20 Jan 2021 05:19:58 GMT):
Great, talk to you in 9 hours!

tatsu-sato (Wed, 20 Jan 2021 16:04:28 GMT):
@dave.enyeart Thank you for today's meeting and helping us open a repository for OpsSC in the labs. I'm preparing the proposal of OpsSC to the labs as follows: https://github.com/satota2/hyperledger-labs.github.io/blob/fabric-opssc/labs/fabric-opssc.md I would appreciate it if you would give us any comment on the contents of the proposal. If it's OK, I'm going to submit the PR to the labs repository later.

rjones (Mon, 25 Jan 2021 18:32:39 GMT):
Hi, the following repos still use `master` as the default branch: `fabric, fabric-amcl, fabric-baseimage, fabric-ca, fabric-chaincode-go, fabric-chaincode-java, fabric-chaincode-node, fabric-chaintool, fabric-cli, fabric-config, fabric-contract-api-go, fabric-gateway, fabric-gateway-java, fabric-lib-go, fabric-protos, fabric-protos-go, fabric-rfcs, fabric-samples, fabric-sdk-go, fabric-sdk-java, fabric-sdk-node, fabric-sdk-py, fabric-test`. `main` [is the current guidance for naming](https://github.com/github/renaming).

jtonline (Wed, 27 Jan 2021 14:22:44 GMT):
Hi, I _think_ I have a PR ready for review to make a start on implementing the Fabric Gateway RFC - https://github.com/hyperledger/fabric-rfcs/blob/master/text/0000-fabric-gateway.md - in the peer. This is just to get a feature flag in so that we can start development without surfacing the new feature to everyone until it's ready. Let me know if there's anything I missed/should have done differently. Thanks v much. https://github.com/hyperledger/fabric/pull/2314

yacovm (Wed, 27 Jan 2021 14:38:41 GMT):
So the decision is to embed the gateway inside the peer and not be decoupled from it?

jtonline (Wed, 27 Jan 2021 14:41:30 GMT):
Yes, the decision was to start with the embedded implementation first

troyronda (Tue, 02 Feb 2021 11:54:37 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-go?msg=YKdRb4FKS7g8WKNt7

troyronda (Tue, 02 Feb 2021 15:15:03 GMT):
https://chat.hyperledger.org/channel/fabric-sdk-go?msg=92yaWX9GMPatJxf5r

bestbeforetoday (Wed, 03 Feb 2021 16:01:05 GMT):
The recording of today's contributor call is now available on the wiki: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2021

jramps9 (Mon, 08 Feb 2021 15:15:21 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT on 2/10 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2021-02-10+Meeting+notes

rjones (Fri, 12 Feb 2021 19:30:19 GMT):
Hi. Is there any plan for another Fabric LTS this year? From JIRA, it doesn't look like it.

dave.enyeart (Tue, 16 Feb 2021 06:27:35 GMT):
Ry, the big thing being worked in 2021 is the Fabric Gateway integration into the peer to make submitting transactions from client applications simpler. When that stabilizes, we'll likely release it in a new LTS, likely sometime this year.

dave.enyeart (Tue, 16 Feb 2021 06:36:35 GMT):
If you'd like more details on that one, see the Feb 3 contributor meeting recording: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2021

rjones (Tue, 16 Feb 2021 15:54:37 GMT):
thank you.

rjones (Wed, 17 Feb 2021 19:21:10 GMT):
Hi, fabric maintainers. While working on the `maintainers` email list, I found a couple invalid emails: ```$ grep -Rl guojiannan hyperledger/* hyperledger/fabric/MAINTAINERS.md hyperledger/fabric-amcl/MAINTAINERS.md hyperledger/fabric-chaincode-evm/MAINTAINERS.md```

rjones (Wed, 17 Feb 2021 19:21:41 GMT):
```$ grep -Rl slanka hyperledger/* hyperledger/fabric-test/MAINTAINERS.rst ```

Helen_Garneau (Wed, 17 Feb 2021 20:00:31 GMT):
Has joined the channel.

dave.enyeart (Thu, 18 Feb 2021 05:54:45 GMT):
@guoger is the email correct at https://github.com/hyperledger/fabric/blob/master/MAINTAINERS.md ?

guoger (Thu, 18 Feb 2021 05:57:35 GMT):
i think my email addr is correct there. @rjones was your mail rejected?

dave.enyeart (Thu, 18 Feb 2021 06:59:00 GMT):
@guoger actually it looks like only https://github.com/hyperledger/fabric-chaincode-evm/blob/main/MAINTAINERS.md is incorrect, could you PR that file?

guoger (Thu, 18 Feb 2021 07:02:45 GMT):
https://github.com/hyperledger/fabric-chaincode-evm/pull/33

rjones (Thu, 18 Feb 2021 13:03:44 GMT):
Thanks. Invite sent

awjh (Mon, 22 Feb 2021 15:02:40 GMT):
Hi, I'm looking to merge my two separate github accounts. I have one which is used for hyperledger awjh-ibm and am looking to instead move my maintainerships across to my other account awjh. I remember everything is now based around CODEOWNERS and I think I need to add my other account to the teams for the respective repos. That account however seems to need to be in the hyperledger organization before I can add it to the team. I do not seem to be able to do this myself does anyone know who can?

rjones (Mon, 22 Feb 2021 15:44:26 GMT):
@awjh invite sent

rjones (Mon, 22 Feb 2021 15:45:20 GMT):
If you're going to delete your other GitHub account, be sure to associate the email addresses from that account with your new one first.

awjh (Mon, 22 Feb 2021 15:47:00 GMT):
Thanks :) I'm likely to rename the old one and keep it around incase something has gone horribly wrong

Helen_Garneau (Wed, 10 Mar 2021 13:00:17 GMT):
Hello Fabric Maintainers: Reminder to please join the DevRel Marketing Committee call at 9am PT today. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/x/Nqx6Ag

Helen_Garneau (Wed, 10 Mar 2021 14:44:43 GMT):
(Please note new zoom info!)

andrew-coleman (Wed, 31 Mar 2021 13:01:36 GMT):
Contributors call now starting

andrew-coleman (Wed, 31 Mar 2021 13:01:37 GMT):
https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

vanitas92 (Tue, 13 Apr 2021 08:30:42 GMT):
Hi Fabric Maintainers. We are dealing with the following setting that i want to bring your awareness in that maybe some defaults on peer config can be made or in some documentation. We have 3 fabric networks that represent 3 different environments, a test environment with 5 peers, a second UAT environment with 13 peers and the production one with 25 org, 2 peers per org which amounts to 50 peers. We use a single channel and private data in a way its is mapped that we have a PDC mapping of one org to another one, so in production we have almost 80+ pdc collections defined. As we have been progressing in the environments and the applications that consume fabric, we have been aware of many warning messages about the gossip network not being able to keep up with all the alive checks that the peers are making between each other to check whether a peer is alive or not, although the peer is up and running fine. The pattern of messages are as follows on the peers: ``` 2021-04-13 07:50:26.215 UTC [gossip.discovery] getDeadMembers -> WARN 089 Haven't heard from [124 66 156 88 222 183 251 2 97 95 87 184 199 246 173 36 189 251 65 131 112 195 81 133 47 188 127 16 1 146 156 60] for 25.211143745s 2021-04-13 07:50:26.216 UTC [gossip.discovery] expireDeadMembers -> WARN 08a Entering [7c429c58deb7fb02615f57b8c7f6ad24bdfb418370c351852fbc7f1001929c3c] 2021-04-13 07:50:26.216 UTC [gossip.discovery] expireDeadMembers -> WARN 08b Closing connection to Endpoint: peer0-org10:7051, InternalEndpoint: , PKI-ID: 7c429c58deb7fb02615f57b8c7f6ad24bdfb418370c351852fbc7f1001929c3c, Metadata: 2021-04-13 07:50:26.217 UTC [gossip.discovery] expireDeadMembers -> WARN 08c Exiting 2021-04-13 07:50:26.217 UTC [comm.grpc.server] 1 -> INFO 08d streaming call completed grpc.service=gossip.Gossip grpc.method=GossipStream grpc.peer_address=192.168.169.196:36774 grpc.peer_subject="CN=peer0-org10,L=San Francisco,ST=California,C=US" grpc.code=OK grpc.call_duration=6m53.18863927s 2021-04-13 07:50:27.168 UTC [gossip.channel] reportMembershipChanges -> INFO 08e [[mychannel] Membership view has changed. peers went offline: [[peer0-org10:7051 ]] , current view: [[peer0-org8:7051 ] [peer0-org6:7051 ] [peer0-org1:7051 ] [peer0-org4:7051 ] [peer0-org11:7051 ] [peer0-org7:7051 ] [peer0-org2:7051 ] [peer0-org9:7051 ] [peer0-org3:7051 ]]] 2021-04-13 07:50:37.167 UTC [gossip.channel] reportMembershipChanges -> INFO 091 [[mychannel] Membership view has changed. peers went online: [[peer0-org10:7051 ]] , current view: [[peer0-org1:7051 ] [peer0-org4:7051 ] [peer0-org11:7051 ] [peer0-org8:7051 ] [peer0-org6:7051 ] [peer0-org10:7051 ] [peer0-org9:7051 ] [peer0-org3:7051 ] [peer0-org7:7051 ] [peer0-org2:7051 ]]] ``` This makes us believe that either the default values of fabric in gossip alive are too aggressive or the peers might be under-resourced on CPU, since gossip protocol uses TLS and may create a bit of overhead. Interestingly, we don't see this messages in test environment with 5 peers, we see some happening in UAT with 13 peers and lots of this in production with 50 peers. I have checked the defaults on this and might be a bit aggressive the defaults when we are dealing with a lots of peers (reference https://github.com/hyperledger/fabric/blob/main/sampleconfig/core.yaml#L158): ``` # Alive check interval(unit: second) aliveTimeInterval: 5s # Alive expiration timeout(unit: second) aliveExpirationTimeout: 25s # Reconnect interval(unit: second) reconnectInterval: 25s ``` I am thinking that these default values might work fine for low density networks but not on large ones as it creates overheads of the checks that fabric is making between peers. The consequence on that "disconnections" is that we see quite a lot of private data errors on the client with failed dissemination errors like this: ``` Chaincode status Code: (500) UNKNOWN. Description: error in simulation: failed to distribute private collection, txID 13cb711c9f12a5830ebe1798359c7fec14ccfc133e356e198521327d645029d4, channel mychannel: Failed disseminating 1 out of 34 private dissemination plans ``` Does anybody have experience with that when dealing with large networks? All perspectives will be welcomed here :)

vanitas92 (Tue, 13 Apr 2021 08:30:42 GMT):
Hi Fabric Maintainers. We are dealing with the following setting that i want to bring your awareness in that maybe some defaults on peer config can be made or in some documentation. We have 3 fabric networks that represent 3 different environments, a test environment with 5 peers, a second UAT environment with 13 peers and the production one with 25 org, 2 peers per org which amounts to 50 peers. We use a single channel and private data in a way its is mapped that we have a PDC mapping of one org to another one, so in production we have almost 80+ pdc collections defined. As we have been progressing in the environments and the applications that consume fabric, we have been aware of many warning messages about the gossip network not being able to keep up with all the alive checks that the peers are making between each other to check whether a peer is alive or not, although the peer is up and running fine. The pattern of messages are as follows on the peers: ``` 2021-04-13 07:50:26.215 UTC [gossip.discovery] getDeadMembers -> WARN 089 Haven't heard from [124 66 156 88 222 183 251 2 97 95 87 184 199 246 173 36 189 251 65 131 112 195 81 133 47 188 127 16 1 146 156 60] for 25.211143745s 2021-04-13 07:50:26.216 UTC [gossip.discovery] expireDeadMembers -> WARN 08a Entering [7c429c58deb7fb02615f57b8c7f6ad24bdfb418370c351852fbc7f1001929c3c] 2021-04-13 07:50:26.216 UTC [gossip.discovery] expireDeadMembers -> WARN 08b Closing connection to Endpoint: peer0-org10:7051, InternalEndpoint: , PKI-ID: 7c429c58deb7fb02615f57b8c7f6ad24bdfb418370c351852fbc7f1001929c3c, Metadata: 2021-04-13 07:50:26.217 UTC [gossip.discovery] expireDeadMembers -> WARN 08c Exiting 2021-04-13 07:50:26.217 UTC [comm.grpc.server] 1 -> INFO 08d streaming call completed grpc.service=gossip.Gossip grpc.method=GossipStream grpc.peer_address=192.168.169.196:36774 grpc.peer_subject="CN=peer0-org10,L=San Francisco,ST=California,C=US" grpc.code=OK grpc.call_duration=6m53.18863927s 2021-04-13 07:50:27.168 UTC [gossip.channel] reportMembershipChanges -> INFO 08e [[mychannel] Membership view has changed. peers went offline: [[peer0-org10:7051 ]] , current view: [[peer0-org8:7051 ] [peer0-org6:7051 ] [peer0-org1:7051 ] [peer0-org4:7051 ] [peer0-org11:7051 ] [peer0-org7:7051 ] [peer0-org2:7051 ] [peer0-org9:7051 ] [peer0-org3:7051 ]]] 2021-04-13 07:50:37.167 UTC [gossip.channel] reportMembershipChanges -> INFO 091 [[mychannel] Membership view has changed. peers went online: [[peer0-org10:7051 ]] , current view: [[peer0-org1:7051 ] [peer0-org4:7051 ] [peer0-org11:7051 ] [peer0-org8:7051 ] [peer0-org6:7051 ] [peer0-org10:7051 ] [peer0-org9:7051 ] [peer0-org3:7051 ] [peer0-org7:7051 ] [peer0-org2:7051 ]]] ``` This makes us believe that either the default values of fabric in gossip alive are too aggressive or the peers might be under-resourced on CPU, since gossip protocol uses TLS and may create a bit of overhead. Interestingly, we don't see this messages in test environment with 5 peers, we see some happening in UAT with 13 peers and lots of this in production with 50 peers. I have checked the defaults on this and might be a bit aggressive the defaults when we are dealing with a lots of peers (reference https://github.com/hyperledger/fabric/blob/main/sampleconfig/core.yaml#L158): ``` # Alive check interval(unit: second) aliveTimeInterval: 5s # Alive expiration timeout(unit: second) aliveExpirationTimeout: 25s # Reconnect interval(unit: second) reconnectInterval: 25s ``` I am thinking that these default values might work fine for low density networks but not on large ones as it creates overheads of the checks that fabric is making between peers. The consequence on these "disconnections" is that we see quite a lot of private data errors on the client with failed dissemination errors like this: ``` Chaincode status Code: (500) UNKNOWN. Description: error in simulation: failed to distribute private collection, txID 13cb711c9f12a5830ebe1798359c7fec14ccfc133e356e198521327d645029d4, channel mychannel: Failed disseminating 1 out of 34 private dissemination plans ``` Does anybody have experience with that when dealing with large networks? All perspectives will be welcomed here :)

vanitas92 (Tue, 13 Apr 2021 08:30:42 GMT):
Hi Fabric Maintainers. We are dealing with the following setting that i want to bring your awareness in that maybe some defaults on peer config can be made or in some documentation. We have 3 fabric networks that represent 3 different environments, a test environment with 5 peers, a second UAT environment with 13 peers and the production one with 25 org, 2 peers per org which amounts to 50 peers. We use a single channel and private data in a way its is mapped that we have a Private Data Collections (PDC) mapping of one org to another one, so in production we have almost 80+ PDCs defined. As we have been progressing in the environments and the applications that consume fabric, we have been aware of many warning messages about the gossip network not being able to keep up with all the alive checks that the peers are making between each other to check whether a peer is alive or not, although the peer is up and running fine. The pattern of messages are as follows on the peers: ``` 2021-04-13 07:50:26.215 UTC [gossip.discovery] getDeadMembers -> WARN 089 Haven't heard from [124 66 156 88 222 183 251 2 97 95 87 184 199 246 173 36 189 251 65 131 112 195 81 133 47 188 127 16 1 146 156 60] for 25.211143745s 2021-04-13 07:50:26.216 UTC [gossip.discovery] expireDeadMembers -> WARN 08a Entering [7c429c58deb7fb02615f57b8c7f6ad24bdfb418370c351852fbc7f1001929c3c] 2021-04-13 07:50:26.216 UTC [gossip.discovery] expireDeadMembers -> WARN 08b Closing connection to Endpoint: peer0-org10:7051, InternalEndpoint: , PKI-ID: 7c429c58deb7fb02615f57b8c7f6ad24bdfb418370c351852fbc7f1001929c3c, Metadata: 2021-04-13 07:50:26.217 UTC [gossip.discovery] expireDeadMembers -> WARN 08c Exiting 2021-04-13 07:50:26.217 UTC [comm.grpc.server] 1 -> INFO 08d streaming call completed grpc.service=gossip.Gossip grpc.method=GossipStream grpc.peer_address=192.168.169.196:36774 grpc.peer_subject="CN=peer0-org10,L=San Francisco,ST=California,C=US" grpc.code=OK grpc.call_duration=6m53.18863927s 2021-04-13 07:50:27.168 UTC [gossip.channel] reportMembershipChanges -> INFO 08e [[mychannel] Membership view has changed. peers went offline: [[peer0-org10:7051 ]] , current view: [[peer0-org8:7051 ] [peer0-org6:7051 ] [peer0-org1:7051 ] [peer0-org4:7051 ] [peer0-org11:7051 ] [peer0-org7:7051 ] [peer0-org2:7051 ] [peer0-org9:7051 ] [peer0-org3:7051 ]]] 2021-04-13 07:50:37.167 UTC [gossip.channel] reportMembershipChanges -> INFO 091 [[mychannel] Membership view has changed. peers went online: [[peer0-org10:7051 ]] , current view: [[peer0-org1:7051 ] [peer0-org4:7051 ] [peer0-org11:7051 ] [peer0-org8:7051 ] [peer0-org6:7051 ] [peer0-org10:7051 ] [peer0-org9:7051 ] [peer0-org3:7051 ] [peer0-org7:7051 ] [peer0-org2:7051 ]]] ``` This makes us believe that either the default values of fabric in gossip alive are too aggressive or the peers might be under-resourced on CPU, since gossip protocol uses TLS and may create a bit of overhead, but we have reserved almost a 1 vCPU per each peer. Interestingly, we don't see this messages in test environment with 5 peers, we see some happening in UAT with 13 peers and lots of this in production with 50 peers. I have checked the defaults on this and might be a bit aggressive the defaults when we are dealing with a lots of peers (reference https://github.com/hyperledger/fabric/blob/main/sampleconfig/core.yaml#L158): ``` # Alive check interval(unit: second) aliveTimeInterval: 5s # Alive expiration timeout(unit: second) aliveExpirationTimeout: 25s # Reconnect interval(unit: second) reconnectInterval: 25s ``` I am thinking that these default values might work fine for low density networks but not on large ones as it creates overheads of the checks that fabric is making between peers. The consequence on these "disconnections" is that we see quite a lot of private data errors on the client with failed dissemination errors like this: ``` Chaincode status Code: (500) UNKNOWN. Description: error in simulation: failed to distribute private collection, txID 13cb711c9f12a5830ebe1798359c7fec14ccfc133e356e198521327d645029d4, channel mychannel: Failed disseminating 1 out of 34 private dissemination plans ``` Does anybody have experience with that when dealing with large networks? All perspectives will be welcomed here :)

yacovm (Tue, 13 Apr 2021 09:26:36 GMT):
> This makes us believe that either the default values of fabric in gossip alive are too aggressive or the peers might be under-resourced on CPU, since gossip protocol uses TLS and may create a bit of overhead, This has nothing to do with TLS, gossip uses long lasting TLS connections, and TLS only uses lots of CPU during the handshake, but afterwards it's just symmetric encryption (either AES GCM or ChaCha20-Poly1305) which is super cheap

yacovm (Tue, 13 Apr 2021 09:27:00 GMT):
The issue, is that gossip sends heart beats that contain signatures, and peers verify these signatures.

yacovm (Tue, 13 Apr 2021 09:27:10 GMT):
If you have lots of peers you need to tune the heart beat intervals

yacovm (Tue, 13 Apr 2021 09:27:21 GMT):
otherwise your CPU will get overloaded with verifying ECDSA signatures

yacovm (Tue, 13 Apr 2021 09:29:28 GMT):
There is a similar issue with channel heartbeats, so if you have lots of channels it is also amplified

yacovm (Tue, 13 Apr 2021 09:30:51 GMT):
50 peers and a heartbeat every 5 second means verifying a heartbeat once per 100 milliseconds, it's not that much.

yacovm (Tue, 13 Apr 2021 09:30:51 GMT):
50 peers and a heartbeat every 5 second means verifying a heartbeat once per 100 milliseconds on average, it's not that much.

yacovm (Tue, 13 Apr 2021 09:32:45 GMT):
But what Fabric version are you using ?

vanitas92 (Tue, 13 Apr 2021 10:31:29 GMT):
We are using latest LTS 2.2.2

yacovm (Tue, 13 Apr 2021 10:41:40 GMT):
ok

vanitas92 (Tue, 13 Apr 2021 11:16:22 GMT):
We are now going to try to change the above setting to at least `aliveTimeInterval: 60s`, `aliveExpirationTimeout: 40s` and `reconnectInterval: 30s` and see if we can decrease a bit the CPU consumption, as this environment we see that the peers are consuming more cpu than other environments when idle

yacovm (Tue, 13 Apr 2021 11:52:34 GMT):
I suggest that expiration will be higher than alive interval

yacovm (Tue, 13 Apr 2021 11:52:53 GMT):
preserve the ratio of 5 or make it 3 times more at least

vanitas92 (Tue, 13 Apr 2021 12:09:43 GMT):
Thank you we will set to 180s then, i will let you know if there is results

vanitas92 (Tue, 13 Apr 2021 14:56:04 GMT):
We applied all peers the recommended configuration `aliveTimeInterval: 60s`, `aliveExpirationTimeout: 180s` and `reconnectInterval: 30s` and the logs output way less errors than before so that is good news, thanks for the recommendation on the ratio. CPU, on the other hand, we do not appreciate a considerate reduction so we will look deeper on what is causing this high consumption while network is idle. Thank you!

tkuhrt (Fri, 16 Apr 2021 18:40:48 GMT):
Hi, Fabric Maintainers. What language is best supported for Chaincode development?

yacovm (Fri, 16 Apr 2021 19:04:08 GMT):
Go

yacovm (Fri, 16 Apr 2021 19:04:52 GMT):
Now Dave K will say "javascript" but don't believe him

davidkel (Fri, 16 Apr 2021 19:05:42 GMT):
I was going to say my order of preference would go/typescript/javascript/java from a performance point of view

yacovm (Fri, 16 Apr 2021 19:06:02 GMT):
I agree that Java would be last

davidkel (Fri, 16 Apr 2021 19:06:31 GMT):
Go is a great language for chaincode but equally I think typescript is as well

yacovm (Fri, 16 Apr 2021 19:06:53 GMT):
Not that I hate java, it's just that I think it's the implementation that got the least "friction" in the community, therefore probably less bugs were discovered

yacovm (Fri, 16 Apr 2021 19:07:58 GMT):
In contrast, when we introduce a new feature to chaincode, we do it for Golang first, and also the Fabric core integration tests use Golang by default, and it was the first chaincode to be used, so it is the most "tested" implementation there is.

tkuhrt (Fri, 16 Apr 2021 19:08:33 GMT):
Perfect. Thank you yacovm and davidkel.

ankitm123 (Thu, 06 May 2021 18:28:30 GMT):
Has joined the channel.

nao (Mon, 10 May 2021 07:58:58 GMT):
Has joined the channel.

davidkhala (Wed, 26 May 2021 04:05:50 GMT):
Hi Fabric Maintainers,could we accept some PR about bump some vendor version on release-1.4 branch to support chaincode developer to use `go mod vendor`?

davidkhala (Wed, 26 May 2021 04:05:50 GMT):
Hi Fabric Maintainers,could we accept some PR about bumping some vendor package version on release-1.4 branch to better support chaincode developer using `go mod vendor`?

dave.enyeart (Wed, 26 May 2021 10:17:13 GMT):
Since 1.4 is not actively in support anymore, the recommendation is to move to Fabric v2.2.x. But could you summarize the issue you see?

davidkhala (Thu, 27 May 2021 02:54:52 GMT):
Basically it is due to hard pinning `github.com/fsouza/go-dockerclient` to 1.3.0 and if developer did not following and repeat this hard version pin in his own `go.mod` file, go module will automatically assign 1.7.2 to it, which has a different data property type and will fail a simple `go test` or `go build`

davidkhala (Thu, 27 May 2021 02:54:52 GMT):
Basically it is due to hard pinning `github.com/fsouza/go-dockerclient` to 1.3.0 and if developer did not recognize this and repeat this hard version pin in his own `go.mod` file, go module will automatically assign 1.7.2 to you, which has a different data property type and will fail a simple `go test` or `go build`

davidkhala (Thu, 27 May 2021 02:58:22 GMT):
I finally come up with a workaround yesterday, by both of - a touch function to prevent `go mod tidy` clean it up https://github.com/davidkhala/fabric-common-chaincode-golang/blob/release-1.4/workaround.go - follow the hard versioning in my own `go.mod` https://github.com/davidkhala/fabric-common-chaincode-golang/blob/release-1.4/go.mod

BrettLogan (Mon, 31 May 2021 00:49:48 GMT):
What happens if you just use a replace directive, I don't think replace affects transitive dependencies:

BrettLogan (Mon, 31 May 2021 00:49:51 GMT):
```module github.com/davidkhala/fabric-common-chaincode-golang go 1.14 replace github.com/fsouza/go-dockerclient v1.3.0 => github.com/fsouza/go-dockerclient v1.7.2 require ( github.com/Knetic/govaluate v3.0.0+incompatible // indirect github.com/Shopify/sarama v1.28.0 // indirect github.com/davidkhala/goutils v1.4.0 github.com/fsouza/go-dockerclient v1.3.0 // indirect github.com/golang/protobuf v1.4.3 github.com/hashicorp/go-version v1.3.0 // indirect github.com/hyperledger/fabric v1.4.12 github.com/hyperledger/fabric-amcl v0.0.0-20210319225857-000ace5745f9 // indirect github.com/hyperledger/fabric-lib-go v1.0.0 // indirect github.com/miekg/pkcs11 v1.0.3 // indirect github.com/onsi/ginkgo v1.16.1 // indirect github.com/onsi/gomega v1.11.0 // indirect github.com/op/go-logging v0.0.0-20160315200505-970db520ece7 // indirect github.com/spf13/viper v1.4.0 // indirect github.com/sykesm/zap-logfmt v0.0.4 // indirect github.com/syndtr/goleveldb v1.0.0 // indirect ) ```

BrettLogan (Mon, 31 May 2021 00:50:23 GMT):
I believe the replace directive will only affect your top level and not the transitive dep in fabric

davidkhala (Mon, 31 May 2021 01:47:27 GMT):
I have done so in transitive dependencies. It can works for its own build, but later if we build a top app upon it the top app build process will fail, since the stupid go module auto versioning cannot take care of our 1.3.0 pinning and it believe `1.7.2 should be OK`

davidkhala (Mon, 31 May 2021 01:47:27 GMT):
I will have a try for it. But still it is another workaround, so won't help too much.

davidkhala (Mon, 31 May 2021 01:47:27 GMT):
I will have a try for it. But still it is another workaround, so won't help too much. pinning to 1.7.2 or 1.3.0 are both pinning.

davidkhala (Mon, 31 May 2021 01:52:36 GMT):
The fundamental problem is go module. Go module cannot smartly detect fabric's version pinning during go mod tidy or go mod vendor

BrettLogan (Mon, 31 May 2021 02:06:52 GMT):
Well it can, if the underlying dependency uses Go Modules. 1.4 fabric unfortunately didn't use go modules, we used `govendor` to manage our deps back then. If you Fabric had used modules in 1.4 none of this would be happening

BrettLogan (Mon, 31 May 2021 02:06:52 GMT):
Well it can, if the underlying dependency uses v2 Go Modules. 1.4 fabric unfortunately didn't use go modules, we used `govendor` to manage our deps back then. If you Fabric had used modules in 1.4 none of this would be happening

BrettLogan (Mon, 31 May 2021 02:06:52 GMT):
Well it can, if the underlying dependency uses v2 Go Modules. 1.4 fabric unfortunately didn't use go modules, we used `govendor` to manage our deps back then. If Fabric had used modules in 1.4 none of this would be happening

davidkhala (Wed, 09 Jun 2021 11:55:37 GMT):
@BrettLogan indeed.

sanket1211 (Tue, 15 Jun 2021 10:10:39 GMT):
Issue while Upgrading fabric from 1.4.4 to 2.2 we are able to update peer and orderer components to the latest version but while updating the channel capababilities to fetch the config block,peers are not able to connect with the orderer Error: could not not connect to ordering service:could not dial endpoint:dial tcp:lookup orderer.example.com on 192.168.0.1:53 :no such host channel=mychannel attaching the logs for more details

sanket1211 (Tue, 15 Jun 2021 10:10:51 GMT):

Screenshot from 2021-06-14 14-39-30.png

sanket1211 (Tue, 15 Jun 2021 10:10:52 GMT):

Screenshot from 2021-06-14 14-39-41.png

toddinpal (Mon, 21 Jun 2021 15:46:27 GMT):
Can someone explain the rationale of removing the management and administrative functions from the Node.js SDK? Requiring using a CLI is a huge step backward.

yacovm (Mon, 21 Jun 2021 16:24:21 GMT):
@mbwhite / @bestbeforetoday :arrow_double_up:

bestbeforetoday (Tue, 22 Jun 2021 08:54:56 GMT):
My understanding is that the burden of duplicating admin capability across multiple language SDKs was too high. There is a finite amount of community development resource to do this work. So the focus is on maintaining CLI commands for admin tasks and not investing further in admin capabilities in the SDKs

bestbeforetoday (Tue, 22 Jun 2021 08:56:40 GMT):
The internals of the Node SDK specifically were significantly re-written for the v2 release, which is why the admin capabilities disappeared from the v2 Node SDK. In contrast, the Java SDK internals were not re-written so some admin capability still exists there, although it may be lacking some v2 features

bestbeforetoday (Tue, 22 Jun 2021 08:57:21 GMT):
You can still continue to use the v1.4 admin capabilities in the v1.4 Node SDK with v2 Fabric

toddinpal (Wed, 23 Jun 2021 14:24:10 GMT):
Thanks for the explanation. Do you have a rough idea of the effort to add back in the admin capabilities to the Node SDK? We may be able to find the resources to work on it.

toddinpal (Wed, 23 Jun 2021 17:27:55 GMT):
I'm curious as to how others are planning on supporting admin APIs? We have a console used to manage and administer our Fabric instances. Spawning CLI commands from our API server seems precarious at best.

bestbeforetoday (Thu, 24 Jun 2021 08:20:29 GMT):
@davidkhala has already re-implemented many (if not all?) of the admin capability on top of the v2.2 Node SDK internals, so he probably has a good feel for how much (if any!) work there is to be done: https://github.com/davidkhala/fabric-common/tree/master/nodejs/admin

bestbeforetoday (Thu, 24 Jun 2021 08:22:26 GMT):
I guess for me the main concern about rolling this into the existing SDK is ongoing maintenance and development of those admin capabilities. I really don't have the bandwidth to take that on. Others might have other opinions of course :)

andrew-coleman (Thu, 24 Jun 2021 09:10:09 GMT):
Just to expand on what Mark said, the existing SDKs have evolved over time in parallel with the development of the Fabric core. The SDKs were owned by different maintainer groups with different requirements and different ideas on what abstractions (if any) should be exposed. Consequently, they diverged in capability and user complexity, but in general they were fairly low level and mixed client application and administrative capabilities into the same classes. Bottom line is that they are hard to use and even harder to maintain. We started a strategy about 3 years ago to build some higher level abstractions across all SDKs specifically aimed at making it easier for client application developers to submit and evaluate (query) transactions. Originally built as a layer on top of the existing SDKs, this ‘gateway’ programming model is currently being written into the peer for version 2.4 with new lightweight SDKs on the client side (which expose these same high level abstractions). You can find out more about this at github.com/hyperledger/fabric-gateway Administrative tasks don’t fit into this gateway model, nor should they be in the new SDK libraries because they have different abstractions and different end users. I have no problem at all with the idea of a fabric-admin library (and David’s could be the basis for that), but that’s not on the roadmap at the moment, hence we recommend the CLI.

davidkhala (Thu, 24 Jun 2021 11:44:29 GMT):
Hi I am the David mentioned here. around more than 1 year ago I create some alternative way to do so and welcome comment and usage. I would like to contribute it in the Apache way but so far I have not got enough thumbs for my work. so it is not in high priority in my open source time. but it is still under actively maintained as my personal project. the project is nodejs only and also under Apache license Anyone can create issue, star or fork to show your interest

davidkhala (Thu, 24 Jun 2021 11:47:06 GMT):
Actually it is all in my mind except for external chain code and legacy chaincode lifecycle

toddinpal (Thu, 24 Jun 2021 18:35:43 GMT):
@andrew-coleman I guess I'm somewhat at a loss for words. I agree the admin APIs (such as those provided by the fabric-client module) aren't necessarily used by a consumer of a Fabric network, they are absolutely required by the provider of a Fabric network. We need tools that can manage, administer, etc., a Fabric network and forcing those tools to use a CLI interface makes integration extremely difficult. Trying to sanitize the arguments to the CLI to prevent injection attacks, interpreting the output of the CLI, and that this output may change is subtle ways that won't affect human users of the CLI but likely break servers trying to understand that output is insane. APIs first, CLIs second where the CLIs are built on the APIs, but those same APIs are available to OA&M servers.

toddinpal (Thu, 24 Jun 2021 18:35:43 GMT):
@andrew-coleman I guess I'm somewhat at a loss for words. I agree the admin APIs (such as those provided by the fabric-client module) aren't necessarily used by a consumer of a Fabric network, they are absolutely required by the provider of a Fabric network. We need tools that can manage, administer, etc., a Fabric network and forcing those tools to use a CLI interface makes integration extremely difficult. Trying to sanitize the arguments to the CLI to prevent injection attacks, interpreting the output of the CLI, and that this output may change in subtle ways that won't affect human users of the CLI but likely break servers trying to understand that output is insane. APIs first, CLIs second where the CLIs are built on the APIs, but those same APIs are available to OA&M servers.

davidkhala (Fri, 25 Jun 2021 07:11:29 GMT):
So you always have an option like what I chose: build admin sdk on your own, if you dislike CLI. All admin task is based on playing grpc and protobuf which are ready to use in npm `fabric-protos`. I spent 2 months as individual to work out.

bestbeforetoday (Fri, 25 Jun 2021 08:12:45 GMT):
There is also a package here that is embedded inside the IBM Blockchain Platform VS Code extension, which does Fabric v2 lifecycle chain installation, although I'm not sure how easy it would be to extract or reuse this code outside of that VS Code extension: https://github.com/IBM-Blockchain/blockchain-vscode-extension/tree/master/packages/blockchain-fabric-admin

bestbeforetoday (Fri, 25 Jun 2021 08:12:45 GMT):
There is also a package here that is embedded inside the IBM Blockchain Platform VS Code extension, which does Fabric v2 lifecycle chaincode installation, although I'm not sure how easy it would be to extract or reuse this code outside of that VS Code extension: https://github.com/IBM-Blockchain/blockchain-vscode-extension/tree/master/packages/blockchain-fabric-admin

ankitm123 (Wed, 07 Jul 2021 10:44:13 GMT):
Very minor PR up for review: https://github.com/hyperledger/fabric-samples/pull/459 (Just a minor yaml simplification of `configtx.yaml`)

jmaric (Mon, 12 Jul 2021 16:38:55 GMT):
Has joined the channel.

Helen_Garneau (Tue, 13 Jul 2021 13:24:20 GMT):
Hello Fabric maintainers! Reminder to please join the DevRel Marketing Committee call at 9am PT tomorrow- 7/14. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/x/sANCAw

Maginaro (Wed, 21 Jul 2021 10:04:10 GMT):
Has joined the channel.

gentios (Tue, 27 Jul 2021 12:07:43 GMT):
Has joined the channel.

guoger (Tue, 27 Jul 2021 16:34:27 GMT):
while trying to trigger build with `/ci-run`, i got gh action failure saying ``` Run org=$(jq -r ".repository.owner.login" "${GITHUB_EVENT_PATH}") % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 19097 0 19097 0 0 46351 0 --:--:-- --:--:-- --:--:-- 46351 WARNING: Extension 'azure-devops' is already installed. ERROR: Failed to authenticate using the supplied token. Error: Process completed with exit code 1. ``` not exactly what's going on, any help? https://github.com/hyperledger/fabric/pull/2707#issuecomment-887424616

ankitm123 (Tue, 27 Jul 2021 18:46:42 GMT):
I started looking at this issue: https://jira.hyperledger.org/browse/FAB-18409 Is there a reason why `peer lifecycle chaincode package` or `peer lifecycle chaincode install` does not have (chaincode) name as a flag? I can install chaincodes with invalid names, and only get notified of the error, when executing - `peer lifecycle chaincode approveformyorg`. I think it makes sense to validate the name from the packaging stage, and tell the end user (will prevent invalid chaincode to be installed on the peers). Also I see that `peer chaincode install` had a name flag. I am thinking about opening a PR with the name flag added, does that sound right?

ankitm123 (Wed, 28 Jul 2021 01:22:48 GMT):
https://github.com/hyperledger/fabric/pull/2795 - opened a PR on adding a validation check for chaincode name when creating a package.

ankitm123 (Thu, 29 Jul 2021 15:44:55 GMT):
Would be nice to get some reviews from the maintainers (is it's even worth having this change)

ankitm123 (Thu, 29 Jul 2021 15:44:55 GMT):
Would be nice to get some reviews from the maintainers (if it's even worth having this change)

dave.enyeart (Thu, 29 Jul 2021 20:23:15 GMT):
thanks for the contribution @ankitm123 ! I explained why name is not included in the package step in the Jira issue and the PR.

ankitm123 (Thu, 29 Jul 2021 20:28:57 GMT):
I see, that makes sense!

pritam_01 (Tue, 03 Aug 2021 19:52:14 GMT):
Has joined the channel.

pritam_01 (Wed, 04 Aug 2021 16:26:04 GMT):
opened a PR , to support async signing of message https://github.com/hyperledger/fabric-sdk-node/pull/479

pritam_01 (Wed, 04 Aug 2021 16:26:04 GMT):
opened a PR for fabric-sdk-node, to support async signing of message https://github.com/hyperledger/fabric-sdk-node/pull/479

BrettLogan (Thu, 12 Aug 2021 15:38:50 GMT):
Good morning maintainers. GitHub recently launched a set of new tools called Codespaces. As part of that they launched `github.dev` which is a fully-fledged VSCode instance running in your browser. One of the cool features of it is you can launch it from anywhere in your repo by pressing `.` (period) and it will launch VSCode running completely in your browser. You can also launch it to review a PR. Simply navigate to any Pull Request (for example https://github.com/hyperledger/fabric/pull/2783) and press `.` (period). VSCode will launch in your browser in the context of the PR. On the left you will now see only the files that are part of the PR. When you select one, you will see a rich diff on the right, where you can make PR comments and reviews just like you would have in the browser, but now you have the power of VS Code to aid you in reviewing.

rjones (Thu, 12 Aug 2021 16:48:49 GMT):
@lehors : this is a lot like Gerrit :)

bestbeforetoday (Thu, 12 Aug 2021 17:38:10 GMT):
This sounds great. I just tried it on a PR I was reviewing and got lots of messages like this but things did eventually load OK: > Error loading webview: Error: Could not register service workers: NotSupportedError: Failed to register a ServiceWorker for scope ('https://0a30bbaa-df14-48bd-8079-2d993ce8eb02.vscode-webview.net/stable/379476f0e13988d90fab105c5c19e7abc8b1dea8/out/vs/workbench/contrib/webview/browser/pre/') with script ('https://0a30bbaa-df14-48bd-8079-2d993ce8eb02.vscode-webview.net/stable/379476f0e13988d90fab105c5c19e7abc8b1dea8/out/vs/workbench/contrib/webview/browser/pre/service-worker.js?id=0a30bbaa-df14-48bd-8079-2d993ce8eb02&swVersion=2&extensionId=vscode.markdown-language-features&platform=browser&vscode-resource-base-authority=vscode-resource.vscode-webview.net'): The user denied permission to use Service Worker..

rjones (Thu, 12 Aug 2021 17:41:54 GMT):
It works for me in Safari and Edge, but there are a lot of console errors

bestbeforetoday (Thu, 12 Aug 2021 17:47:26 GMT):
Many thanks for the contribution and sorry holiday got in the way of reviewing earlier! A signing implementation that needed an async Node implementation was something I suspected existed, but it's nice to have Vault Transit Engine/PKCS#11 Proxy confirmed as a specific use case. That's exactly why I defined an async signing implementation for the Fabric Gateway client API currently under development: https://hyperledger.github.io/fabric-gateway/main/api/node/modules.html#signer

lehors (Thu, 12 Aug 2021 18:08:18 GMT):
Indeed! Amazing, GitHub is slowly catching up! ;-)

pritam_01 (Thu, 12 Aug 2021 21:05:46 GMT):
Happy to hear this was in TODO. Actually I'm one of the mentee under hyperledger mentorship for this year. Currently I am working on supporting multiple type of message. For now I'm able to implement vault transit engine. And planning to supporting singing by transport layer such as websockit, grpc ( bidirectional streaming). By supporting singing via a transport layer, I am trying to achieve a metamask like singing capabilites, wherein private key will be stored with client's extension . Organisations's Node applications will get the messages signed via back n forth messing between client's extension and server. You can find more details here https://github.com/Zzocker/blockchain-carbon-accounting/tree/secureFabric/secure-fabric Thank and hope you enjoyed your holiday 🙏

pritam_01 (Thu, 12 Aug 2021 21:05:46 GMT):
Happy to hear this was in TODO. Actually I'm one of the mentee under hyperledger mentorship for this year. Currently I am working on supporting multiple type of message signing . For now I'm able to implement vault transit engine. And planning to supporting singing by transport layer such as websockit, grpc ( bidirectional streaming). By supporting singing via a transport layer, I am trying to achieve a metamask like singing capabilites, wherein private key will be stored with client's extension . Organisations's Node applications will get the messages signed via back n forth messing between client's extension and server. You can find more details here https://github.com/Zzocker/blockchain-carbon-accounting/tree/secureFabric/secure-fabric Thank and hope you enjoyed your holiday 🙏

pritam_01 (Thu, 12 Aug 2021 21:05:46 GMT):
Happy to hear this was in TODO. Actually I'm one of the mentee under hyperledger mentorship for this year. Currently I am working on supporting multiple type of message signing . For now I'm able to implement vault transit engine. And planning to supporting singing by transport layer such as websockit, grpc ( bidirectional streaming). By supporting signing via a transport layer, I am trying to achieve a metamask like signing capabilites, wherein private key will be stored with client's extension . Organisations's Node applications will get the messages signed via back n forth messing between client's extension and server. You can find more details here https://github.com/Zzocker/blockchain-carbon-accounting/tree/secureFabric/secure-fabric Thank and hope you enjoyed your holiday 🙏

pritam_01 (Thu, 12 Aug 2021 21:05:46 GMT):
Happy to hear this was in TODO. Actually I'm one of the mentee under hyperledger mentorship for this year. Currently I am working on supporting multiple type of message signing . For now I'm able to implement vault transit engine. And planning to supporting singing by transport layer such as websockit, grpc ( bidirectional streaming). By supporting signing via a transport layer, I am trying to achieve a metamask like signing capabilites, wherein private key will be stored with client's extension . Organisations's Node applications will get the messages signed via back n forth messing between client's extension and server. You can find more details here https://github.com/Zzocker/blockchain-carbon-accounting/tree/secureFabric/secure-fabric Thanks and hope you enjoyed your holiday 🙏

BrettLogan (Fri, 13 Aug 2021 04:42:23 GMT):
Launch day was a little more overwhelming than they were expecting. Given that they weren't advertising this feature, they weren't expecting it get the demand it did. once Reddit and Twitter caught wind of it though and it started trending it took off like crazy. While the instance runs in your browser, some of the setup work occurs on our servers. Demand was so high, our Azure scale sets weren't quite able to keep up with demand. Things h as be stabilized and they deployed more scale sets to handle spikes in demand now

BrettLogan (Fri, 13 Aug 2021 04:42:23 GMT):
The launch was a little more overwhelming than they were expecting, even with us slowly rolling it our over 2 days to 80 million users. Given that they weren't advertising this feature, they weren't expecting it get the demand it did. once Reddit and Twitter caught wind of it though and it started trending it took off like crazy. While the instance runs in your browser, some of the setup work occurs on our servers. Demand was so high, our Azure scale sets weren't quite able to keep up with demand. Things h as be stabilized and they deployed more scale sets to handle spikes in demand now

BrettLogan (Fri, 13 Aug 2021 04:42:23 GMT):
The launch was a little more overwhelming than they were expecting, even with us slowly rolling it our over 2 days to all 80 million users. Given that they weren't advertising this feature, they weren't expecting it get the demand it did. once Reddit and Twitter caught wind of it though and it started trending it took off like crazy. While the instance runs in your browser, some of the setup work occurs on our servers. Demand was so high, our Azure scale sets weren't quite able to keep up with demand. Things h as be stabilized and they deployed more scale sets to handle spikes in demand now

BrettLogan (Fri, 13 Aug 2021 04:42:23 GMT):
The launch was a little more overwhelming than they were expecting, even with us slowly rolling it our over 2 days to all 80 million users. Given that they weren't advertising this feature, they weren't expecting it get the demand it did. once Reddit and Twitter caught wind of it though and it started trending it took off like crazy. While the instance runs in your browser, some of the setup work occurs on our servers. Demand was so high, our Azure scale sets weren't quite able to keep up with demand. Things have been stabilized and they deployed more scale sets to handle spikes in demand now

SamYuan1990 (Thu, 14 Oct 2021 13:54:33 GMT):
Hi Guys, I am not sure here is right place for questions below or not, please forgive me for any mistakes. - I hearing from Jay before, for https://github.com/hyperledger/fabric-rfcs/pull/34 this pr, we'd better to have a online meeting for discussion. May I know what should be prepared for the online meeting? - Ref to result for the strategic survey, I want to know is there any tools we uesd for fabric performance? or if we plan to do any or performance improvements for commit phase, is there any tools we planned and will used to make benmark? caliper? tape? golang benmark testing? https://github.com/Hyperledger-TWGC/tape Thanks Sam Yuan

rjones (Thu, 14 Oct 2021 14:14:55 GMT):
Hi, @SamYuan1990 . The next meeting is in a little less than two weeks: https://lists.hyperledger.org/g/fabric/viewevent?repeatid=24800&eventid=1272126&calstart=2021-10-27 I would email fabric@ or see if you can get on the agenda here: https://wiki.hyperledger.org/display/fabric/Contributor+Meetings+2021

SamYuan1990 (Thu, 14 Oct 2021 14:17:06 GMT):
hi rjones, before apply for coming meeting, I want to know what should I prepared for the meeting, for example, if I need to go through the RFC, by any slides or draft codes/POC?

SamYuan1990 (Thu, 14 Oct 2021 14:21:16 GMT):
my currently plan is 1. figure out what need to be prepared for the meeting 1. together with other twgc members get ready 1. schedule the meeting with you and we can go through it make sense?

rjones (Thu, 14 Oct 2021 14:27:56 GMT):
I would reach out to @dave.enyeart - he runs those meetings - his email is enyeart@us.ibm.com. please include email to community-architects@hyperledger.org

SamYuan1990 (Thu, 14 Oct 2021 14:28:26 GMT):
thanks

rjones (Thu, 14 Oct 2021 14:28:47 GMT):
sure thing.

SamYuan1990 (Fri, 03 Dec 2021 13:00:39 GMT):
Hi Guys, we plan to introduce https://github.com/hyperledger/fabric-rfcs/pull/34 on 8th Dec meeting. cc: @davidkhala

dave.enyeart (Tue, 07 Dec 2021 21:10:25 GMT):
meeting agenda confirmed!

SamYuan1990 (Fri, 10 Dec 2021 15:11:13 GMT):
hello fabric maintainers, can anyone take a look at https://github.com/hyperledger/fabric-rfcs/pull/34#issuecomment-991047119 before Christmas ? (and I also send a mail about it)

SeanBohan (Fri, 17 Dec 2021 20:01:35 GMT):
Has joined the channel.

rlnrajesh (Sat, 08 Jan 2022 02:22:35 GMT):
Has joined the channel.

rlnrajesh (Sat, 08 Jan 2022 02:22:35 GMT):
hi

s.vahidi (Sat, 22 Jan 2022 10:03:50 GMT):
Has joined the channel.

s.vahidi (Sat, 22 Jan 2022 10:15:06 GMT):
hello fabric maintainers, An error occurred while installing the chaincode and then chaincode wasn't installed completely and we want to uninstall it, please help me?

rjones (Sat, 22 Jan 2022 16:49:17 GMT):
@s.vahidi the mailing list is probably a better place to ask. https://lists.hyperledger.org/g/fabric

s.vahidi (Sun, 23 Jan 2022 12:18:09 GMT):
thanks

rjones (Mon, 24 Jan 2022 01:10:33 GMT):
Sure thing

sbohanlf (Tue, 25 Jan 2022 15:20:14 GMT):
Has joined the channel.

SamYuan1990 (Sat, 05 Feb 2022 02:41:24 GMT):
hi Guys, could you please take a look at https://github.com/hyperledger/fabric/pull/3202 ?

rjones (Fri, 11 Feb 2022 23:24:53 GMT):
this chat has moved to [discord](https://discord.gg/hyperledger)

rjones (Wed, 23 Mar 2022 17:24:57 GMT):