rjones (Sun, 17 Jun 2018 16:26:13 GMT):
amundson

rjones (Sun, 17 Jun 2018 16:26:20 GMT):
Has left the channel.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_1 added by amundson.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_2 added by amundson.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_3 added by amundson.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_4 added by amundson.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_5 added by amundson.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_6 added by amundson.

amundson (Sun, 17 Jun 2018 16:40:16 GMT):
User User_7 added by amundson.

honeyjills (Tue, 19 Jun 2018 09:10:40 GMT):
Has joined the channel.

zac (Tue, 19 Jun 2018 20:30:27 GMT):
Has joined the channel.

tungdt_socoboy (Thu, 21 Jun 2018 11:44:20 GMT):
Has joined the channel.

rootDistress (Wed, 27 Jun 2018 07:23:33 GMT):
Has joined the channel.

Dan (Thu, 05 Jul 2018 17:02:28 GMT):
@kelly_ channel just mentioned

kelly_ (Thu, 05 Jul 2018 17:04:10 GMT):

Potential Roadmap Items

kelly_ (Thu, 05 Jul 2018 17:04:55 GMT):

Roadmap Items - sawtooth.docx

amundson (Thu, 05 Jul 2018 20:56:20 GMT):
@kelly_ nice!

mfford (Wed, 11 Jul 2018 14:16:30 GMT):
Has joined the channel.

dplumb (Wed, 11 Jul 2018 14:19:46 GMT):
Has joined the channel.

Gandalf (Wed, 11 Jul 2018 14:20:13 GMT):
Has joined the channel.

FrankCastellucci (Wed, 11 Jul 2018 14:20:35 GMT):
Has joined the channel.

benoit.razet (Wed, 11 Jul 2018 14:23:02 GMT):
Has joined the channel.

benoit.razet (Wed, 11 Jul 2018 14:28:22 GMT):
@kelly_ thanks for posting this roadmap. Are there any approximative release dates for 1.1 or 1.2 ?

kelly_ (Wed, 11 Jul 2018 16:48:34 GMT):
@benoit.razet this was mostly a brain storming session so not everything on there will neccesarily make it into 1.1/1.2

kelly_ (Wed, 11 Jul 2018 16:48:54 GMT):
I believe we are looking at a 1.1 preview in the next couple months give or take a few weeks

kelly_ (Wed, 11 Jul 2018 16:50:19 GMT):
if there are any features you see that you'd like to contribute please let us know though :)

kelly_ (Wed, 11 Jul 2018 16:51:00 GMT):
hoping to formalize the list/releases a bit more in the next couple weeks

FrankCastellucci (Wed, 11 Jul 2018 17:05:51 GMT):
@kelly_ (Hand raise to your question): Encryption, zksnark...

benoit.razet (Wed, 11 Jul 2018 17:09:59 GMT):
@FrankCastellucci you mean removing the `?` on the `zk stuff?` item ;)

benoit.razet (Wed, 11 Jul 2018 17:12:10 GMT):
@kelly_ what about the `explorer`, I don't see it mentioned on the list. Maybe it's considered done

benoit.razet (Wed, 11 Jul 2018 17:12:10 GMT):
@kelly_ what about the `explorer`, I don't see it mentioned on the list. Maybe it's considered already done

kelly_ (Wed, 11 Jul 2018 17:12:37 GMT):
@FrankCastellucci would love to hear what you have in mind

kelly_ (Wed, 11 Jul 2018 17:13:04 GMT):
@benoit.razet I saw an e-mail today from the hyperledger-explorer team looking at integration

kelly_ (Wed, 11 Jul 2018 17:13:39 GMT):
I believe Gini/Chris from PD we're involved in a conversation with that team

kelly_ (Wed, 11 Jul 2018 17:13:46 GMT):
though to be honest I'm not sure exactly where that is at

kelly_ (Wed, 11 Jul 2018 17:14:56 GMT):
oh and Joe

FrankCastellucci (Wed, 11 Jul 2018 17:23:15 GMT):
@kelly_ As much as we can "permission" sawtooth, the merkle tree is open to discovery as the data is not consistently encrypted (meaning unless the application/TP encrypts it is at best serialized data). Is there an opportunity to add an encryption layer in the Merkle DB and validator to encrypt at rest and in flight data.

kelly_ (Wed, 11 Jul 2018 17:24:19 GMT):
if the TP (and therefore host) has access to the encryption key, what good is encrypted data in the merkle-trie

kelly_ (Wed, 11 Jul 2018 17:25:33 GMT):
we have a project/sample app that will be coming into Hyperledger in the next month or two that puts the TP inside of an enclave with a key that is only available in the enclave and is unable to extracted

kelly_ (Wed, 11 Jul 2018 17:27:32 GMT):
The difficulty with encryption in a blockchain is that there is usually a trade-off between checking the integrity of a transaction, and the confidentiality of that transaction. so you either need to not check the txn is valid and just store encrypted blobs, or you need to check that a transaction is valid and therefore it needs to be in clear text to processed. two exceptions are homomorphic encryption/zkp and trusted hardware

kelly_ (Wed, 11 Jul 2018 17:28:34 GMT):
that all being said, noted on adding encryption for data-at-rest and in-flight

kelly_ (Wed, 11 Jul 2018 17:29:34 GMT):
just wanted to be clear that the data at rest piece doesnt necessarily solve any confidentiality problems. though I guess if your transaction processor was isolated from your merkle trie DB then it would provide confidentiality there

FrankCastellucci (Wed, 11 Jul 2018 17:33:00 GMT):
@kelly_ I hear your point but let's bring EC Diffie-Hellman into the equation. I'm not suggesting the solution is "just add it", clearly there would be a dance between sawtooth and consumers to create the secret through well defined protocols.

kelly_ (Wed, 11 Jul 2018 17:34:13 GMT):
is that just a TLS connection between a client and the validator he is talking to?

kelly_ (Wed, 11 Jul 2018 17:34:37 GMT):
and/or tls between validator nodes

kelly_ (Wed, 11 Jul 2018 17:36:15 GMT):
the data-at-rest problem ultimately seems like something that would be handled by a transaction processor, in addition to choosing your serialization you would also choose a deterministic encryption algorithim e.g. aes-siv with a key stored somewhere

FrankCastellucci (Wed, 11 Jul 2018 17:36:46 GMT):
That is one of the questions to answer in the a analysis/solutioning no?

FrankCastellucci (Wed, 11 Jul 2018 17:37:27 GMT):
We are currently doing the encryption (which can't be done in the TP)

kelly_ (Wed, 11 Jul 2018 17:37:38 GMT):
I think TLS for REST/ZMQ makes sense

FrankCastellucci (Wed, 11 Jul 2018 17:38:23 GMT):
The payload has to be encrypted before sending to the TP (one of the issues to solve with making it more core to the framework)

kelly_ (Wed, 11 Jul 2018 17:38:44 GMT):
also the TP would need to be able to access a key as well

kelly_ (Wed, 11 Jul 2018 17:39:13 GMT):
so it would be additions to the client and TP SDKs that would enable key storage/use

FrankCastellucci (Wed, 11 Jul 2018 17:40:02 GMT):
Again, if there is a thought of consideration to make it part of the core then we'd be happy to contribute in the analysis and solution design options

FrankCastellucci (Wed, 11 Jul 2018 17:40:23 GMT):
zksnark is a different animal, of course

kelly_ (Wed, 11 Jul 2018 17:40:34 GMT):
I think you are on the agenda at some point for the sawtooth tech forum right? maybe we could discuss there

kelly_ (Wed, 11 Jul 2018 17:40:54 GMT):
I know @amundson has mentioned adding encryption for data-in-flight across validators

FrankCastellucci (Wed, 11 Jul 2018 17:41:34 GMT):
Not on agenda yet but have chatted w/Dan about it... we are in the middle of trying to get zkPROOFs into our application (we've already baked zkSNARK in)

FrankCastellucci (Wed, 11 Jul 2018 17:42:34 GMT):
wanted to have the 3 legs (Encryption,zksnark and zkproof) in so we had a comprehensive discussion

kelly_ (Wed, 11 Jul 2018 17:43:20 GMT):
:thumbsup:

FrankCastellucci (Wed, 11 Jul 2018 17:45:42 GMT):
Thanks for the back and forth... look forward to these things coming to fruition

kelly_ (Wed, 11 Jul 2018 17:46:17 GMT):
likewise

kelly_ (Wed, 11 Jul 2018 17:46:40 GMT):
oh, and @FrankCastellucci - this blog came out today that you may find interesting - https://medium.com/daml-driven/keeping-smart-contracts-private-is-hard-unless-you-truly-understand-them-920b31d723e4

FrankCastellucci (Wed, 11 Jul 2018 17:50:57 GMT):
Yes, we're working with the 'experimental' bulletproofs implementation

FrankCastellucci (Wed, 11 Jul 2018 17:51:02 GMT):
good article, thanks

FrankCastellucci (Wed, 11 Jul 2018 17:56:30 GMT):
If we had a roadmap, this would be on it as well: https://dspace.mit.edu/bitstream/handle/1721.1/35401/31311897-MIT.pdf;sequence=2

FrankCastellucci (Wed, 11 Jul 2018 17:58:08 GMT):
I won't bring up quantum future here as that will take up my character limit :)

Dan (Thu, 12 Jul 2018 13:30:52 GMT):
What's special in that thesis?

FrankCastellucci (Thu, 12 Jul 2018 13:42:14 GMT):
chain proofs... ability to verify X without knowing where (beyond the exchange partner) in the back chain the commitment was from

FrankCastellucci (Thu, 12 Jul 2018 13:42:21 GMT):
If you were directing that to me

FrankCastellucci (Thu, 12 Jul 2018 14:17:59 GMT):
There are a few analogies that may simplify if you want

FrankCastellucci (Thu, 12 Jul 2018 14:21:14 GMT):
@kelly_ A few months ago, on an application call hosted by Mark Ford, there was a discussion about state generational data. Examples of implementations include Datomic which is based on Persistent data concepts (ala functional programming). Is there any plans that this becomes a reality for `state` management?

jsmitchell (Thu, 12 Jul 2018 14:42:50 GMT):
@FrankCastellucci is there a place I can learn more about 'state generational data'?

amundson (Thu, 12 Jul 2018 15:38:37 GMT):
reminder, this channel is soley for discussion about sawtooth governance topics (RFCs and other topics the root team needs to discuss). technical discussion should go to @sawtooth-core-dev, etc.

amundson (Thu, 12 Jul 2018 15:40:49 GMT):
FYI, @zac is proposing another supply chain RFC enter FCP on #sawtooth-supply-chain

amundson (Thu, 12 Jul 2018 15:43:03 GMT):
FYI - Bitwise IO is planning to update the bond transaction family

sidhujag (Thu, 12 Jul 2018 18:58:44 GMT):
Has joined the channel.

PHeinz (Thu, 12 Jul 2018 18:58:57 GMT):
Has joined the channel.

sidhujag (Thu, 12 Jul 2018 19:02:31 GMT):
can someone explain the decentralized governance as the whitepaper talks about it with voting on configuration variables? How exactly would that work. I can think of perhaps voting on a encryption key that changes every k blocks (k being the blocks after which the endpoint registery validators are re-attested by intel) so that you can offer encrypted contracts and also fall back to poet sgx security policy and not affect availability (if you have per enclave encryption keys for contracts now you have to trust that they will be available to execute your next update etc)

Dan (Thu, 12 Jul 2018 19:08:22 GMT):
heh - wrong governance. this channel is for the governance of how we manage the project. For talking about the on-chain governance feature of sawtooth (settings transaction processor) please bring this dicussion to #sawtooth

sidhujag (Thu, 12 Jul 2018 19:18:32 GMT):
ok thanks

FrankCastellucci (Thu, 12 Jul 2018 20:08:47 GMT):
@Dan @amundson Got it, @jsmitchell I will respond on #sawtooth-core-dev

Dan (Tue, 17 Jul 2018 15:32:50 GMT):
I would like to create a repo for the new version of PoET. Concern had been raised about the naming of that code and its repo. I think the gist is that if we call it PoET2 and deprecate PoET1 then we better be very confident in PoET2. To that end I'd like to recommend looking at the new version of the RFC and providing comments where you see any risk. Setting design validity aside, the benefit of a separate repo is that I don't think the two versions will share any code. PoET2 is being developed in rust and we probably don't want to bring any baggage (e.g. defaults) over into the new code. On deprecating PoET1 and some rationale for naming PoET2, I think that poet naming is confusing at this point (sim/sgx v cft/bft) if we further layer another poet version on top of that then we end up with a matrix and that's far far too confusing for users. Incidentally in PoET2 the approach to cft/enclave-simulation will be a compiler flag rather than a separate code path.

Dan (Wed, 18 Jul 2018 20:00:28 GMT):
I move that we archive the repo sawtooth-private-utxo

kelly_ (Thu, 19 Jul 2018 15:58:17 GMT):
Hey all - has everyone got a chance to review the 1.1 release spreadsheet Tom sent out? I only had view access so if you have any comments/changes to make I think you may need to request access from Tom

benoit.razet (Thu, 19 Jul 2018 17:57:14 GMT):
@kelly_ is the 1.1 release spreadsheet available to the public, or is it more internal?

kelly_ (Thu, 19 Jul 2018 19:01:15 GMT):
Internal right now, but similar to what was posted earlier

amundson (Mon, 23 Jul 2018 20:53:17 GMT):
@kelly_ not yet had a chance to look

amundson (Mon, 23 Jul 2018 20:56:24 GMT):
@Dan why not do PoET/NG in a fork of the current poet repo? are you sure both PoET/NG and PoET/CFT can't share the same code?

Dan (Mon, 23 Jul 2018 20:58:47 GMT):
Yep

TomBarnes (Mon, 23 Jul 2018 20:59:23 GMT):
I set the permission for the spreadsheet to "edit with link" so everyone should be able to modify it as they see fit. If your having problems, let me know. Heres the link: https://docs.google.com/spreadsheets/d/1NgryDYBm12r7GI_jR3O2VgotgfOJolExIFQuvqCia5A/edit?usp=sharing

Dan (Mon, 23 Jul 2018 20:59:44 GMT):
the way we'll handle no hw enclaves in poet2 is with a compile decision not with a separate code path.

amundson (Mon, 23 Jul 2018 21:09:47 GMT):
@Dan well, regardless of that, I'm more in favor of a branch than a new repo for PoET/NG. or call PoET/NG something besides PoET, then I'd support a new repo.

amundson (Mon, 23 Jul 2018 21:17:33 GMT):
@TomBarnes hopefully in the next week I'm going to do some roadmap planning and then will be able to help with that doc in a meaningful way. I still have a TODO to draft a high-level release process which I'll try and get to as well.

amundson (Mon, 23 Jul 2018 21:20:27 GMT):
@Dan I second your suggestion we archive sawtooth-private-utxo

amundson (Mon, 23 Jul 2018 21:21:46 GMT):
@Dan is the validator registry still relevant with PoET/NG?

Dan (Mon, 23 Jul 2018 21:32:09 GMT):
Yes validator registry is still relevant. Though I believe the signup data is slightly different.

Dan (Tue, 24 Jul 2018 18:29:51 GMT):
What does 1.1 mean to everyone? I was thinking of it collectively across features/repos. However I think others might be interpreting it purely as sawtooth-core. At odds is at least the SDKs which will each be on their own cadence. I would want for our user community though an easier, higher level interpretation of our versioning. It should be clear when they use a consensus engine, SDK, or sample app, what that implies.

amundson (Tue, 24 Jul 2018 19:41:23 GMT):
@Dan Interesting topic. I think it's mostly about sawtooth-core, but then also components that change because of it; not every component will be sensitive to the version change. other components (sdks, seth, sabre, supply chain) may support both 1.0 and 1.1 for a while. clearly consensus is impacted (but might not be between 1.1 and 1.2)

amundson (Tue, 24 Jul 2018 19:43:20 GMT):
from an apt repo perspective though, it is more of a distribution. 1.1 there probably means "things that work with sawtooth-core 1.1"

Dan (Thu, 26 Jul 2018 15:25:04 GMT):
Are you suggesting that each sdk, consensus, etc. tie it's version to the latest version of Sawtooth validator that it supports?

amundson (Thu, 26 Jul 2018 22:42:32 GMT):
@Dan no, definitely not

Dan (Fri, 27 Jul 2018 02:10:04 GMT):
Tell me more what you mean by '1.1 there probably means "things that work with sawtooth-core 1.1"'

amundson (Fri, 27 Jul 2018 04:10:49 GMT):
In terms of what we would put in the '1.1' apt repo

amundson (Fri, 27 Jul 2018 04:11:20 GMT):
so, a 1.0 sdk might end up in both the 1.0 and 1.1 apt repos

dokany (Tue, 31 Jul 2018 05:48:49 GMT):
Has joined the channel.

kelly_ (Tue, 31 Jul 2018 15:06:17 GMT):
Are folks available for a 1.1 features/timing meeting this week? Maybe 8am PST on Thursday?

amundson (Wed, 08 Aug 2018 00:53:52 GMT):
we would like root team members to approve this PR - https://github.com/hyperledger/sawtooth-rfcs/pull/21/files

kelly_ (Fri, 17 Aug 2018 15:08:04 GMT):
hey all! I got back from vacation a couple days ago and wanted to check in to see if there are any RFCs that need my immediate attention?

kelly_ (Fri, 17 Aug 2018 15:09:16 GMT):
I also wanted to get some feedback on where we could house links/testimonials from other sawtooth projects

kelly_ (Fri, 17 Aug 2018 15:09:27 GMT):
maybe a sawtooth-community repo?

kelly_ (Fri, 17 Aug 2018 15:09:46 GMT):
I know @amundson had discussed one for the website but would like to get something out there sooner rather than later

kelly_ (Fri, 17 Aug 2018 15:10:12 GMT):
idea would be a store for non-code collateral related to sawtooth e.g. whitepaper, image files, 'press kit', testimonials, etc

Dan (Fri, 17 Aug 2018 21:30:30 GMT):
I think just walk through the open PRs on the rfcs repo.

Gabe (Mon, 20 Aug 2018 04:15:51 GMT):
Has joined the channel.

amundson (Mon, 20 Aug 2018 14:03:53 GMT):
@kelly_ we can get the website repo setup short-term. I started looking at it again last week

kelly_ (Wed, 22 Aug 2018 16:04:34 GMT):
hey sorry missed this comment ^

kelly_ (Wed, 22 Aug 2018 16:04:48 GMT):
yea that would be great, just need a place to slap a markdown file for now

kelly_ (Wed, 22 Aug 2018 17:28:26 GMT):
@amundson do I need to contact someone at LF to get the repo setup?

amundson (Wed, 22 Aug 2018 17:42:20 GMT):
@kelly_ https://github.com/hyperledger/sawtooth-website

amundson (Wed, 22 Aug 2018 17:45:58 GMT):
I should have an initial PR up today

kelly_ (Wed, 22 Aug 2018 17:46:38 GMT):
how does this look for the 'users.md'

kelly_ (Wed, 22 Aug 2018 17:46:40 GMT):
Company: Use Case: Project Link: Code: Sawtooth Quote:

kelly_ (Wed, 22 Aug 2018 17:47:12 GMT):
this is where i'm at on the company collection

kelly_ (Wed, 22 Aug 2018 17:47:13 GMT):
PokitDok dotBlockchain Remme AmChart T-Mobile Wind River Filament Blockchain Technology Partners Vanig Bitagora Scantrust IntraEdge Bitwise TASE Farmobile Intel Cargill VMC.ai State Bank of India Haystack

kelly_ (Wed, 22 Aug 2018 17:47:31 GMT):
Maybe I should have a contact too

amundson (Wed, 22 Aug 2018 17:48:39 GMT):
.md files may be hard to publish on the site; we would need to identify a .md->.html converter.

amundson (Wed, 22 Aug 2018 17:49:07 GMT):
we haven't really solved this with the current stuff, we have .html files

kelly_ (Wed, 22 Aug 2018 17:49:16 GMT):
I'm really just looking for an easy to use place to collect these use cases for the community

kelly_ (Wed, 22 Aug 2018 17:49:29 GMT):
i think .md will be the easiest for people to edit/submit PRs against

kelly_ (Wed, 22 Aug 2018 17:49:42 GMT):
we can figure out how to convert to web later, but right now these are all scattered around

amundson (Wed, 22 Aug 2018 17:50:25 GMT):
i think at least it needs to be publishable

amundson (Wed, 22 Aug 2018 17:50:38 GMT):
we could maybe use jekyll

amundson (Wed, 22 Aug 2018 17:50:45 GMT):
https://jekyllrb.com/

kelly_ (Wed, 22 Aug 2018 17:51:00 GMT):
yea i've used jekyll

kelly_ (Wed, 22 Aug 2018 17:52:39 GMT):
I'd recommend this: https://github.com/poole/poole

kelly_ (Wed, 22 Aug 2018 17:53:32 GMT):
but its more blog focused

amundson (Wed, 22 Aug 2018 17:53:35 GMT):
that has the worst README.md ever

amundson (Wed, 22 Aug 2018 17:56:36 GMT):
I'm planning on putting this initial site stuff in sawtooth-website/htdocs/. we can then overlay that with stuff output from jekyll (if we are using jekyll)

kelly_ (Wed, 22 Aug 2018 17:57:52 GMT):
sounds good to me, i'm fine with whatever website wise, i just get questions once a week like who is using sawtooth, what are some example use cases

kelly_ (Wed, 22 Aug 2018 17:58:06 GMT):
so really trying to solve my own problem where i can say 'check this link'

kelly_ (Wed, 22 Aug 2018 17:58:29 GMT):
I also want to be able to post it in #sawtooth so those users can add their use cases, will give us more insight and moves from being something I have to collect/maintain :)

kelly_ (Wed, 22 Aug 2018 18:24:14 GMT):
@amundson do you have a preferred way of doing line breaks in MD?

amundson (Wed, 22 Aug 2018 18:24:34 GMT):
we have been wrapping at <80. is that what you mean?

kelly_ (Wed, 22 Aug 2018 18:24:52 GMT):
when i do this

kelly_ (Wed, 22 Aug 2018 18:24:52 GMT):
Company: Use Case: Project Link: Code: Sawtooth Quote:

kelly_ (Wed, 22 Aug 2018 18:24:54 GMT):
it wraps

amundson (Wed, 22 Aug 2018 18:24:54 GMT):
unix style

kelly_ (Wed, 22 Aug 2018 18:25:17 GMT):
so i can do a
or a double space or whatever to make a line break in the file

kelly_ (Wed, 22 Aug 2018 18:26:40 GMT):
or maybe it's that github just isn't it rendering correctly

amundson (Wed, 22 Aug 2018 18:27:27 GMT):
no opinions about it currently, probably whatever will look best in the output

amundson (Wed, 22 Aug 2018 18:31:03 GMT):
@kelly_ are you able to spin up docker compose stuff easy if we create a docker compose setup for the website?

amundson (Wed, 22 Aug 2018 18:31:56 GMT):
the idea would be that if it looks good in the docker environment, then we know it will look good when we deploy it

amundson (Wed, 22 Aug 2018 18:32:14 GMT):
maybe we even deploy as a docker image at some point

kelly_ (Wed, 22 Aug 2018 18:32:18 GMT):
yea docker-compose works fine for me

amundson (Wed, 22 Aug 2018 18:34:45 GMT):
is all the current website content creative commons?

amundson (Wed, 22 Aug 2018 18:34:53 GMT):
(including examples)

amundson (Wed, 22 Aug 2018 18:35:09 GMT):
this stuff: https://sawtooth.hyperledger.org/examples/

kelly_ (Wed, 22 Aug 2018 18:43:45 GMT):
it should be

kelly_ (Wed, 22 Aug 2018 18:49:33 GMT):
ok @amundson PR submitted

kelly_ (Wed, 22 Aug 2018 18:50:06 GMT):
https://github.com/hyperledger/sawtooth-website/pull/2

kelly_ (Wed, 22 Aug 2018 18:50:37 GMT):
once we get it merged I can shoot out an e-mail to some of the relevant parties to see if they want to update it and also post it in #sawtooth

amundson (Wed, 22 Aug 2018 18:51:33 GMT):
let's not post links to the website repo as if those urls are going to remain valid though, because we will almost certainly move the files around

amundson (Wed, 22 Aug 2018 18:52:03 GMT):
I should have a cut at a PR for existing stuff up shortly

amundson (Wed, 22 Aug 2018 18:54:24 GMT):
@kelly_ do you see this as eventually being a "users page" more than just a list? with a url like https://sawtooth.hyperledger.org/users/ ?

kelly_ (Wed, 22 Aug 2018 18:56:51 GMT):
right now I see it as a list predominantly of users/apps

kelly_ (Wed, 22 Aug 2018 18:57:03 GMT):
i'd at some point also like to have something like a 'providers' page

kelly_ (Wed, 22 Aug 2018 18:57:17 GMT):
where we could have like bitwise or accenture

kelly_ (Wed, 22 Aug 2018 18:57:26 GMT):
and then a deployment page, where we could have aws/azure/etc

amundson (Wed, 22 Aug 2018 18:57:27 GMT):
that might be contentious with HL folks

kelly_ (Wed, 22 Aug 2018 18:57:50 GMT):
why?

kelly_ (Wed, 22 Aug 2018 18:58:12 GMT):
i guess there are providers on HL, but that requires you to be a member

amundson (Wed, 22 Aug 2018 18:58:28 GMT):
it is also not curated

kelly_ (Wed, 22 Aug 2018 18:58:42 GMT):
right

amundson (Wed, 22 Aug 2018 18:59:08 GMT):
I don't want to defend that opinion, I just think it might exist based on some private conversations

kelly_ (Wed, 22 Aug 2018 18:59:18 GMT):
well, cross that bridge when it comes :)

amundson (Wed, 22 Aug 2018 19:00:29 GMT):
those pages plus a good main page at https://sawtooth.hyperledger.org/ would be good

amundson (Wed, 22 Aug 2018 19:00:54 GMT):
currently we redirect that to the docs, but as we add more content, it makes sense for us to have that be a real landing page

kelly_ (Wed, 22 Aug 2018 19:02:26 GMT):
i was also thinking of a 'collateral.md' or something

amundson (Wed, 22 Aug 2018 19:02:27 GMT):
@kelly_ your Signed-off-by has a bad email address

kelly_ (Wed, 22 Aug 2018 19:03:07 GMT):
it passed DCO, thats the only way I've been able to get it to pass the DCO

kelly_ (Wed, 22 Aug 2018 19:03:29 GMT):
if i use kelly.m.olson@intel.com in fails because its not associated with my github or something

amundson (Wed, 22 Aug 2018 19:04:15 GMT):
@kelly_ you can add email addresses in github.com preferences (more than one)

kelly_ (Wed, 22 Aug 2018 19:05:49 GMT):
is there an issue with the e-mail that I've used? other than it doesnt automagically get picked up for things like TSC vote

kelly_ (Wed, 22 Aug 2018 19:05:51 GMT):
"If you enabled email address privacy, then the commit author email address cannot be changed and is username@users.noreply.github.com by default."

kelly_ (Wed, 22 Aug 2018 19:06:32 GMT):
I have e-mail privacy turned on so that is my associated e-mail

kelly_ (Wed, 22 Aug 2018 19:06:33 GMT):
https://help.github.com/articles/about-commit-email-addresses/

kelly_ (Wed, 22 Aug 2018 19:06:38 GMT):
and therefore what i need to use for DCO

amundson (Wed, 22 Aug 2018 19:08:38 GMT):
@kelly_ still needs work, but its a start - https://github.com/hyperledger/sawtooth-website/pull/3

amundson (Wed, 22 Aug 2018 19:10:41 GMT):
hmm, meant for you to be in the reviewers list. something must be up with the perms, I don't see you listed. I'll have to check on that.

kelly_ (Wed, 22 Aug 2018 19:13:48 GMT):
no worries, it did let me review anyway

amundson (Wed, 22 Aug 2018 19:14:05 GMT):
is that a reasonable MAINTAINERS.md?

kelly_ (Wed, 22 Aug 2018 19:14:54 GMT):
lgtm

kelly_ (Wed, 22 Aug 2018 19:15:02 GMT):
minus the one comment i made

kelly_ (Wed, 22 Aug 2018 19:15:17 GMT):
github/rocket were switched and rocket name had an extra backslash

amundson (Wed, 22 Aug 2018 19:16:08 GMT):
I fixed the order

amundson (Wed, 22 Aug 2018 19:16:31 GMT):
you mean "kelly\_" - that backslash is for markdown, as _ bolds things (I think)

amundson (Wed, 22 Aug 2018 19:16:58 GMT):
this is what it looks like rendered - https://github.com/hyperledger/sawtooth-website/blob/b5b1ab9f0e7a96ac019875199dd90733f705898c/MAINTAINERS.md

kelly_ (Wed, 22 Aug 2018 19:17:23 GMT):
oh yea that looks fine, weird

kelly_ (Wed, 22 Aug 2018 19:18:15 GMT):
i think it's __text__ for bold

kelly_ (Wed, 22 Aug 2018 19:18:22 GMT):
"__"

kelly_ (Wed, 22 Aug 2018 19:18:27 GMT):
front and back

kelly_ (Wed, 22 Aug 2018 19:18:30 GMT):
two underscores

kelly_ (Wed, 22 Aug 2018 19:18:35 GMT):
but either way, it renders fine

amundson (Wed, 22 Aug 2018 19:19:12 GMT):
I just based it on vim complaining via syntax highlighting since I don't have a local github renderer here :)

kelly_ (Wed, 22 Aug 2018 19:34:18 GMT):
@amundson are you able to add reviewers to https://github.com/hyperledger/sawtooth-website/pull/2 and/or merge

kelly_ (Wed, 22 Aug 2018 19:34:26 GMT):
it won't let me add reviewers

amundson (Wed, 22 Aug 2018 19:36:00 GMT):
I added some people. I have to do some other perms changes, so I'll look into the root cause in a bit.

kelly_ (Wed, 22 Aug 2018 19:38:45 GMT):
ok thanks!

alchmeina (Thu, 23 Aug 2018 14:15:37 GMT):
Has joined the channel.

kelly_ (Fri, 24 Aug 2018 19:31:32 GMT):
@amundson do you know about this - https://help.github.com/articles/about-codeowners/

amundson (Mon, 27 Aug 2018 03:29:13 GMT):
@kelly_ we are experimenting a bit with that in the seth repo so it sets reviewers automatically

kelly_ (Mon, 27 Aug 2018 15:24:12 GMT):
ok cool, thought it may be useful

amundson (Fri, 31 Aug 2018 02:35:51 GMT):
I've submitted an RFC to create the core subteam - https://github.com/hyperledger/sawtooth-rfcs/pull/24

amundson (Fri, 31 Aug 2018 02:41:23 GMT):
I'm looking forward to chewing through these outstanding technical RFCs and getting them accepted. There are a lot of good RFCs in our backlog of RFCs.

amundson (Fri, 31 Aug 2018 02:43:46 GMT):
Root team members, please review this RFC, it will require your vote.

Dan (Fri, 31 Aug 2018 14:10:07 GMT):
Yeah I would like to get PBFT etc. finalized.

sureshtedla (Fri, 31 Aug 2018 17:32:02 GMT):
Has joined the channel.

amundson (Thu, 06 Sep 2018 19:12:45 GMT):
I am proposing the core team RFC be merged: https://github.com/hyperledger/sawtooth-rfcs/pull/24

amundson (Thu, 06 Sep 2018 20:17:09 GMT):
^ that RFC has now entered FCP

amundson (Thu, 06 Sep 2018 20:18:57 GMT):
I'd like to propose we set some target dates for core team voting on PoET and PBFT RFCs, maybe as soon as next week Friday (Sept 24). Discussion could delay the dates, which wouldn't be a big deal, but I think it will help move them along to have targets on when to get reviews done.

amundson (Thu, 06 Sep 2018 20:19:16 GMT):
Are PoET and PBFT the right high priority RFCs?

Dan (Fri, 07 Sep 2018 13:58:43 GMT):
Yeah I think those sound good. There's a little discussion going on with poet fork resolution now. Assuming that plays out by end of next week w/o design changes then we can vote on it.

amundson (Fri, 07 Sep 2018 15:09:24 GMT):
anyone on root team or future core team have a problem with creating a stable branch of the java sdk? (see #sawtooth-sdk-dev for background)

raviyelleni (Sun, 09 Sep 2018 09:09:48 GMT):
Has joined the channel.

arsulegai (Tue, 11 Sep 2018 18:56:30 GMT):
Has joined the channel.

kelly_ (Wed, 12 Sep 2018 18:20:37 GMT):
Hey All - we've been having a conversation in #sawtooth-next-directory about existing conventions in Sawtooth that may not be documented.

kelly_ (Wed, 12 Sep 2018 18:20:38 GMT):
Continuous Integration - Jenkins Issue Tracking - Jira Documentation - Sphinx publishing from .rst files Line Wrap - 80 characters File Names - All lower case Linting - ? Pull Requests - Documented here: https://sawtooth.hyperledger.org/docs/core/releases/1.0.5/community/contributing.html Commits/Messages - Documented here: https://sawtooth.hyperledger.org/docs/core/releases/1.0.5/community/contributing.html

kelly_ (Wed, 12 Sep 2018 18:21:02 GMT):
any additions/modifications to the above are happily welcomed

kelly_ (Wed, 12 Sep 2018 18:24:46 GMT):
another items would be builds/release naming conventions

kelly_ (Wed, 12 Sep 2018 18:25:13 GMT):
not sure if there is any other conventions around deployment tools e.g. docker etc

kelly_ (Wed, 12 Sep 2018 18:27:55 GMT):
here's one from @amundson Maintainers (write/merge permission): our current process has been: "1. before adding anyone new, generate a MAINTAINER.md file based on the commit history, excluding infrequent contributors; 2. any new maintainers need to be approved by all other maintainers; 3) github maintainers group for that repo should match the maintainers in the file" Usually I go adjust those maintainer groups. I'd like to bring this repo back into compliance with this so it's not an exception. So I propose we figure out that maintainer list based on historical activity and then vote new folks in.

pschwarz (Wed, 12 Sep 2018 18:54:35 GMT):
@amundson I think a stable branch is a good idea

Dan (Wed, 12 Sep 2018 19:19:54 GMT):
Argument for Jira: it's often hard to know what component is the root of an issue. If a bug is filed as a github rather than jira issue that may create an obstacle to routing it to the real root cause. For release processes we might want to set stories that touch multiple components and examples. Line Wrap: Need to specify for what. We have different lint requirements for different languages. In the case of markdown I don't personally care about line wrap because they are often authored and displayed in tools that will auto-wrap. File names: is that another language convention? Java file names match class names which are generally UpperCamelCase. Linting: should probably match across repos. this will facilitate static analysis for CII. Regarding maintainers, the threshold for adding maintainers should probably include something at least qualitative so that we don't have maintainers of some repo adding new maintainers in an inconsistent or indefensible manner. e.g. 2. any new maintainers need to be approved by all other maintainers and have shown a commensurate level of contribution in the commit history [or pull request reviews]. That last part might be controversial, but I expect that as repos get busier some people spend most of their time reviewing contributions.

Dan (Wed, 12 Sep 2018 19:34:29 GMT):
I don't have particular feelings on CI conformity. I think it's important for core to be on the LF servers for cost reasons and for availability reasons and that is what implies needing jenkins. If another company wants to host build servers for a repo that incurs some risk that the company could pull the plug to the detriment of sawtooth (in so far as the rest of sawtooth relies on that repo).

amundson (Wed, 12 Sep 2018 19:53:38 GMT):
@Dan I agree, we have an implied threshold for maintainers having been contributors for a while and having participated in the community long enough to know the processes/standards/culture/etc. These are probably best guidelines for decision making than strict rules; a.k.a "this is what you should be thinking about when you make someone a maintainer".

ChrisSpanton (Wed, 12 Sep 2018 20:48:16 GMT):
Has joined the channel.

adamgering (Thu, 13 Sep 2018 00:00:14 GMT):
Has joined the channel.

kthblmfld (Thu, 13 Sep 2018 00:08:01 GMT):
Has joined the channel.

colincmcc (Thu, 13 Sep 2018 15:48:46 GMT):
Has joined the channel.

amundson (Thu, 13 Sep 2018 16:53:28 GMT):
@Dan line wrap is for editors, yes, but also other tools like diff. also consistency, same as any linting. rust lint allows 120? characters and 120 was proposed for java as well. other places it is 80, so I agree the context matters. I much prefer linting handled by a tool, and probably the only thing we dont have a tool for now is markdown.

amundson (Thu, 13 Sep 2018 16:54:17 GMT):
those are excellent points wrt JIRA

amundson (Thu, 13 Sep 2018 17:02:11 GMT):
filenames are also context dependent, but in most contexts lower case. in the instance @kelly_ is thinking of specifically, it also effects the url in the browser and all (most) our sphinx urls are lower case

mtn206 (Thu, 13 Sep 2018 19:12:53 GMT):
Has joined the channel.

vishalce89 (Fri, 14 Sep 2018 11:32:33 GMT):
Has joined the channel.

amundson (Mon, 17 Sep 2018 15:04:50 GMT):
I propose adding PBFT as a Sawtooth component, which will require Root subteam approval. The starting point for this project would be the work Bitwise IO put into the implementation here - https://github.com/bitwiseio/sawtooth-pbft. This is currently a solid working prototype. There is a related RFC here - https://github.com/hyperledger/sawtooth-rfcs/pull/19. Once the Root subteam approves adopting PBFT, it will allow us to move the official repo to hyperledger and adopt our standard Sawtooth PR processes. This is important because we are expecting to make a push to take it from it's current prototype state to a "1.0"-level state in the next few months, and we want more reviewers during this process.

amundson (Mon, 17 Sep 2018 15:07:48 GMT):
We could have two separate votes, one for making it a component (Root team), and another to approve the RFC on technical grounds (core team). However, since the core is a subset of the Root team, I propose taking a single combined vote for both, unless others feel separate votes are desirable in this case.

amundson (Mon, 17 Sep 2018 15:07:48 GMT):
We could have two separate votes, one for making it a component (Root team), and another to approve the RFC on technical grounds (core team). However, since the core team is a subset of the Root team, I propose taking a single combined vote for both, unless others feel separate votes are desirable in this case.

jsmitchell (Mon, 17 Sep 2018 15:57:11 GMT):
where do we indicate our approval?

amundson (Mon, 17 Sep 2018 15:59:52 GMT):
I'll call for a vote/FCP within the RFC later this afternoon unless we need more time for discussion

amundson (Mon, 17 Sep 2018 16:06:27 GMT):
The core team RFC has been merged - https://github.com/hyperledger/sawtooth-rfcs/pull/24 - I will have a PR to fix the filename, etc. shortly.

amundson (Mon, 17 Sep 2018 17:09:33 GMT):
core subteam url is updated - https://github.com/hyperledger/sawtooth-rfcs/blob/master/text/0024-core-subteam.md

amundson (Tue, 18 Sep 2018 02:17:44 GMT):
A couple of people asked for an easier reference for finding subteam membership, so I created a PR to add a directory of the current subteams - https://github.com/hyperledger/sawtooth-rfcs/pull/27

amundson (Tue, 18 Sep 2018 02:23:12 GMT):
@adamludvik is this consensus engine RFC still up-to-date, or should we refresh it before FCP? https://github.com/hyperledger/sawtooth-rfcs/pull/4

adamludvik (Tue, 18 Sep 2018 02:23:29 GMT):
Needs to be refreshed

amundson (Tue, 18 Sep 2018 02:24:21 GMT):
@adamludvik same for blockmanager? https://github.com/hyperledger/sawtooth-rfcs/pull/5

adamludvik (Tue, 18 Sep 2018 02:24:50 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-governance?msg=wtb3Dpr4KnghBwpwD) @amundson I am in favor of this

adamludvik (Tue, 18 Sep 2018 02:25:31 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-governance?msg=wtb3Dpr4KnghBwpwD) this

adamludvik (Tue, 18 Sep 2018 02:26:01 GMT):
The Java SDK. Idk how to rocket chat apparently.

amundson (Tue, 18 Sep 2018 02:26:34 GMT):
huh?

adamludvik (Tue, 18 Sep 2018 02:29:10 GMT):
Sorry, I am behind on reading. I am good with a stable Java SDK branch.

amundson (Tue, 18 Sep 2018 02:30:18 GMT):
ok, there is a bunch of discussion on that SDK too in #sawtooth-sdk-dev

adamludvik (Tue, 18 Sep 2018 02:31:32 GMT):
The block manager RFC could be updated to reflect the removal of the "anchor" concept, but I think that is maybe more of an implementation detail than something that needs to be updated prior to FCP.

adamludvik (Tue, 18 Sep 2018 02:36:04 GMT):
It is important for us to establish good norms about how consistent the RFCs and their implementation are. I am in favor of letting the design evolve beyond the RFC as it is implemented, since in my experience new stuff often comes to light at that time. Whether it is important to go back and update the RFC after implementation in general is probably another norm to establish. How important that task is depends on where we want architectural documentation to live long term. If the RFC repo is meant to be the source of truth for architectural documentation, then it is very important in my opinion. If we want to write and keep up-to-date separate architectural documentation long term, and the RFC process is meant to drive consensus around ideas and not as long term documentation, then updating post-implementation is not very important.

adamludvik (Tue, 18 Sep 2018 02:39:44 GMT):
@Dan @kelly_, RE: conventions and sawtooth-next-directory, where can I go to read up on the conversation around that project and why I should be concerned about it?

adamludvik (Tue, 18 Sep 2018 02:40:19 GMT):
I have been very heads down working on core engineering and am very behind on these community conversations.

amundson (Tue, 18 Sep 2018 02:46:27 GMT):
I've proposed FCP for PBFT RFC here - https://github.com/hyperledger/sawtooth-rfcs/pull/19 ; Requires root subteam vote.

amundson (Tue, 18 Sep 2018 02:51:30 GMT):
@adamludvik I think they should at least be consistent at the time we vote them in - "what we thought correct at the time". as for keeping them up-to-date, I could see it being beneficial both ways. Maybe we should allow for a "Implementation Updates" or something which allow us to put in notes about how the actual implementation differs from the RFC. This would allow us to point out things like "This was outdated by X and not included in version 2.0" and such.

amundson (Tue, 18 Sep 2018 02:53:41 GMT):
though, if we just duplicate the content to an architecture doc, we could just link to the relevant section. that does seem more likely to be maintained.

adamludvik (Tue, 18 Sep 2018 15:48:18 GMT):
From the RFC process doc "In general, once accepted, RFCs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new RFCs, with a note added to the original RFC." I think I am on board with requiring RFCs to be "what we thought correct at the time" for FCP. Implementing RFCs before FCP is not a good practice in general. I consider the block manager and consensus RFCs outliers because there was an urgent need to implement them before the core team could be formed for formal approval.

Dan (Tue, 18 Sep 2018 16:32:41 GMT):
I think RFCs should be mostly accurate at the time that we FCP them and ideally the implementation follows after the RFC. We should keep our arch docs up to date and not worry about going to update previously committed RFCs. I view the RFCs as a checkpoint before changing / developing a [new] capability. Also useful as a pseudo-spec at the time we review PRs, but not as an ongoing spec.

adamludvik (Tue, 18 Sep 2018 16:35:51 GMT):
I think the PR reviews that implement the RFC are where any differences between spec and implementation should be sorted out.

amundson (Tue, 18 Sep 2018 16:45:19 GMT):
sounds like we are all basically on the same page then?

Dan (Tue, 18 Sep 2018 16:45:47 GMT):
no! fight fight fight :boxing_glove:

amundson (Tue, 18 Sep 2018 16:46:02 GMT):
sorry, we will have to go back to linting for a fight

adamludvik (Tue, 18 Sep 2018 16:48:09 GMT):
I think we need a separate file that tracks the version file which specifies which version of which linting tool is used with that version _starts video camera_

Dan (Tue, 18 Sep 2018 16:49:59 GMT):
I thought that's what we were already doing. Have you not been following that rule?

amundson (Tue, 18 Sep 2018 17:21:24 GMT):
you are supposed to just remember

amundson (Wed, 19 Sep 2018 00:30:05 GMT):
subteams PR is merged, so subteams are now documented in https://github.com/hyperledger/sawtooth-rfcs/tree/master/subteams

amundson (Wed, 19 Sep 2018 00:59:12 GMT):
PBFT RFC has entered FCP - https://github.com/hyperledger/sawtooth-rfcs/pull/19

amundson (Wed, 19 Sep 2018 01:02:51 GMT):
@pschwarz does this RFC need updating prior to FCP? https://github.com/hyperledger/sawtooth-rfcs/pull/8

adamludvik (Wed, 19 Sep 2018 13:08:46 GMT):
@amundson should we be discussing RFCs under the responsibility of the core team in #sawtooth-core-dev ?

amundson (Wed, 19 Sep 2018 16:10:02 GMT):
seems appropriate, especially for technical discussion

pschwarz (Wed, 19 Sep 2018 22:17:36 GMT):
Yes, I need to update that RFC

pgobin (Thu, 20 Sep 2018 20:35:33 GMT):
Has joined the channel.

askmish (Fri, 21 Sep 2018 04:34:13 GMT):
Has joined the channel.

kthblmfld (Fri, 21 Sep 2018 17:51:10 GMT):
Where is a good place to follow the decision making around the copyright section of the Apache 2 license? I understand it is a work-in-progress but am hoping to sort out an interim solution. Thanks

kthblmfld (Fri, 21 Sep 2018 17:55:33 GMT):
Personally, I like the way Kubernetes does it. Eg: Copyright 2016 The Kubernetes Authors.

kthblmfld (Fri, 21 Sep 2018 17:58:26 GMT):
Since we have a number of contributors from different corporations, the concept of ownership gets confusing when a person from Initech creates the file and then another contributor from Hooli adds most of the content.

adamgering (Fri, 21 Sep 2018 18:00:53 GMT):
There's also the question of whether a header is required to be placed on every file.

kthblmfld (Fri, 21 Sep 2018 18:13:10 GMT):
It is not required, but recommended by Apache 2 folks. They add the snippet at the end of the license and encourage adopters to add as a header in each file

kthblmfld (Fri, 21 Sep 2018 18:14:32 GMT):
... and that opens the matter of file type/format. A legal department will insist in adding it to every single file in the codebase

kthblmfld (Fri, 21 Sep 2018 18:14:32 GMT):
... and that opens the matter of file type/format. A legal department would likely recommend adding it to every single file in the codebase.

Dan (Fri, 21 Sep 2018 18:16:52 GMT):
I think the license banner is required at the top of all files.

Dan (Fri, 21 Sep 2018 18:17:35 GMT):
The copyright statement itself is in flux. HL recommended something like 'copyright hyperledger authors...' but that was not ratified by the legal committee yet.

kelly_ (Fri, 21 Sep 2018 18:24:05 GMT):
what's the recommended path currently @Dan - just add Hooli and Initech at the top? I have seen that for some files already

Dan (Fri, 21 Sep 2018 18:26:30 GMT):
the recommended path is the 'hyperledger project authors' or something like that. @tkuhrt do you have the recommended hyperledger copyright text?

tkuhrt (Fri, 21 Sep 2018 18:26:30 GMT):
Has joined the channel.

kthblmfld (Fri, 21 Sep 2018 18:27:13 GMT):
Ok deal. We will go with that in the meantime. Thanks!

tkuhrt (Fri, 21 Sep 2018 20:56:47 GMT):
@Dan : https://wiki.hyperledger.org/community/copyright-and-license-policy

tkuhrt (Fri, 21 Sep 2018 20:56:58 GMT):
`Copyright Hyperledger and its contributors.`

amundson (Fri, 21 Sep 2018 23:38:37 GMT):
Uh, no. That is not accurate as Hyperledger holds none of the copyright. I think we were close to settling on “Hyperledger Sawtooth contributors”.

amundson (Sat, 22 Sep 2018 01:43:12 GMT):
@kelly_ @Dan @kthblmfld the approach Kelly suggested works fine, and we have been doing that for Cargill and Bitwise IO contributions when they are significant enough to warrant it; but it's not a perfect system as we haven't consistently done it for small contributions. so on some files the copyright statement can be considered incomplete.

amundson (Sat, 22 Sep 2018 01:47:04 GMT):
We have debated this a lot already, and I feel like we have consensus generally to adopt another copyright line. If we still have consensus on taking that step, I think this is the right forum to debate what the line should say.

amundson (Sat, 22 Sep 2018 01:48:22 GMT):
Some of the options I though reasonable were "Copyright Hyperledger Sawtooth contributors", "Copyright Hyperledger Sawtooth Authors", and "Copyright The Hyperledger Sawtooth Team"

amundson (Sat, 22 Sep 2018 01:49:58 GMT):
Then we discussed previously putting a CONTRIBUTORS.md or AUTHORS.md or TEAM.md file in each repo with a list of the copyright holders (even minor ones) for reference. This includes listing companies as well as individuals.

adamludvik (Sat, 22 Sep 2018 14:36:49 GMT):
I am in agreement with what @amundson.

adamludvik (Sat, 22 Sep 2018 14:36:49 GMT):
I am in agreement with @amundson .

tkuhrt (Mon, 24 Sep 2018 16:32:00 GMT):
@amundson : It looks like this has recently been updated, but not yet put in the Wiki. Here is the latest suggestion: `Copyright contributors to Hyperledger ` so in this case `Copyright contributors to Hyperledger Sawtooth`

tkuhrt (Mon, 24 Sep 2018 16:32:14 GMT):
Going to update the Wiki now

kthblmfld (Mon, 24 Sep 2018 17:14:56 GMT):
Thanks. Created a backlog item to refactor the headers accordingly

amundson (Mon, 24 Sep 2018 18:26:50 GMT):
@tkuhrt excellent

phaniac (Mon, 01 Oct 2018 18:18:36 GMT):
Has joined the channel.

kthblmfld (Wed, 10 Oct 2018 19:27:21 GMT):
Does anybody know who owns the sawtooth git repos? Specifically: https://github.com/hyperledger/sawtooth-next-directory? We have been blocked for a month on a number of items (gitflow implementation, deleting mistakenly pushed branches, assigning default reviewers). It would be great to have at least @ChrisSpanton having admin access to the repo since he has driven this project from the start. Otherwise, can somebody with the privileges avail themselves for regular maintenance?

adamludvik (Wed, 10 Oct 2018 19:33:29 GMT):
@amundson ^

kthblmfld (Wed, 10 Oct 2018 20:40:04 GMT):
Thanks @adamludvik

amundson (Thu, 11 Oct 2018 04:16:57 GMT):
@kthblmfld a few of us have admin rights on repos but it is a touchy subject because HL has had some fairly recent issues with instances of circumventing HL requirements (such as DCO) (not w/Sawtooth specifically)

amundson (Thu, 11 Oct 2018 04:20:40 GMT):
in terms of gitflow - it is probably better to stick with the current Sawtooth PR norms of creating PRs against master as we have a large number of community members that know how that works now and we want to keep the ability for contributors to contribute to each of the components

kthblmfld (Thu, 11 Oct 2018 04:21:27 GMT):
Ah, good to have some context in this matter. Ok, it isn't a major blocker, but would be nice to have a point person to reach out to for config changes. We want to get CI/CD in place and could benefit from default reviewers, but are also experiencing fluctuation in contributors.

amundson (Thu, 11 Oct 2018 04:22:10 GMT):
the default reviewers can be done by creating a code owners file in the repo - example: https://github.com/hyperledger/sawtooth-seth/blob/master/CODEOWNERS

kthblmfld (Thu, 11 Oct 2018 04:22:35 GMT):
It is soon to consider gitflow since we aren't live anyways.

kthblmfld (Thu, 11 Oct 2018 04:22:54 GMT):
Excellent. Will do that tomorrow.

amundson (Thu, 11 Oct 2018 04:24:49 GMT):
it's important to see it as a community effort, not a corporate internal effort. there may be layers between the community effort and what you go live with from a corporate perspective (additional testing, how you do deployments, etc.)

amundson (Thu, 11 Oct 2018 04:26:25 GMT):
but, what I would suggest is when you get to a point where stability is super important, you should create a release branch. I'd be happy to go over how we handle that in the other repos. it's not super complex.

amundson (Thu, 11 Oct 2018 04:30:16 GMT):
@kthblmfld what I think makes sense for default reviewers is to put all the maintainers as that default

kthblmfld (Thu, 11 Oct 2018 04:36:09 GMT):
Understood. It is a challenge striking that balance between adding features and ensuring the code is of high quality. We are making great progress, but additional challenges arise as the dev community scales up

bongaquino (Thu, 11 Oct 2018 05:35:52 GMT):
Has joined the channel.

amundson (Thu, 11 Oct 2018 13:36:56 GMT):
@kthblmfld one approach we have used for sawtooth core, is that when a feature is big enough to potentially break things in a hard-to-resolve way, is that we will do additional testing of those PRs prior to merging them into master. for example, if we rewrite a piece of code that is critical, we will run it on a long-running network for a day or a few days (whatever convinces us we won't cause a regression)

amundson (Thu, 11 Oct 2018 13:37:35 GMT):
similar reasoning to the develop branch, but without changing the overall PR pattern

kthblmfld (Thu, 11 Oct 2018 16:19:42 GMT):
@amundson That is the direction we are headed. At this time we are increasing test coverage w/unit tests, improving integration tests to support setup/teardown/isolation.. any changes we can make to support end-to-end tests on the client. Last week we had a manual deployment to Azure, and intend to build out a delivery pipleline complete with tests so we can take on perf and soak.

kthblmfld (Thu, 11 Oct 2018 16:23:27 GMT):
It will be great to have a stable environment (or a few) we can rely on for exploratory tinkering, demos on demand, pen testing, etc.

Dan (Tue, 16 Oct 2018 14:35:26 GMT):
Reminder to root team, please review https://github.com/hyperledger/sawtooth-rfcs/pull/4

adamludvik (Tue, 16 Oct 2018 15:40:48 GMT):
Thanks @Dan, would be good to get that merged and propose further improvements/changes as new RFCs

grapebaba (Wed, 17 Oct 2018 01:52:05 GMT):
Has joined the channel.

yusra (Sun, 21 Oct 2018 06:44:44 GMT):
Has joined the channel.

Dan (Mon, 22 Oct 2018 19:30:09 GMT):
@adamludvik @agunde @jsmitchell @pschwarz please take a look at https://github.com/hyperledger/sawtooth-rfcs/pull/23 and see if there are any backwards compatibility risks or other feedback. The gist is facilitating transaction processors checking signatures themselves which is relevant at least for an enclave, but possibly other types of TPs.

adamludvik (Mon, 22 Oct 2018 19:55:29 GMT):
Interesting. I am considering something very similar with consensus messages.

adamludvik (Mon, 22 Oct 2018 19:55:36 GMT):
For similar reasons.

amundson (Mon, 22 Oct 2018 21:19:42 GMT):
@Dan what other TPs. I feel like that's a false statement. :)

adamludvik (Mon, 22 Oct 2018 22:09:12 GMT):
@amundson based on what evidence do you believe there is an absence of other TPs?

amundson (Tue, 23 Oct 2018 14:40:50 GMT):
@adamludvik it is a very specific use-case to want to re-verify txn signature within the TP because you don't trust the validator, driven by the use of an enclave in a very specific way

Dan (Tue, 23 Oct 2018 23:05:42 GMT):
is https://github.com/hyperledger/sawtooth-rfcs/pull/22/files an after the fact rfc? i.e. are these already implemented in the work to support truffle? Or are these additional features beyond that?

Dan (Tue, 23 Oct 2018 23:05:42 GMT):
Are the endpoints in https://github.com/hyperledger/sawtooth-rfcs/pull/22/files an after the fact rfc? i.e. are these already implemented in the work to support truffle? Or are these additional API endpoints beyond that?

Dan (Tue, 23 Oct 2018 23:19:06 GMT):
n/m I checked the code.

rbuysse (Wed, 24 Oct 2018 18:53:59 GMT):
Has joined the channel.

amundson (Wed, 24 Oct 2018 21:38:38 GMT):
is there general support for switching to something like "Copyright contributors to Hyperledger Sawtooth" on copyright headers?

Dan (Wed, 24 Oct 2018 21:47:08 GMT):
lemme check if that's officially through the HL legal committee

duncanjw (Wed, 24 Oct 2018 23:45:16 GMT):
Has joined the channel.

Dan (Thu, 25 Oct 2018 13:19:14 GMT):
@adamludvik @jsmitchell @amundson @agunde @pschwarz Apologies.. Shawn pointed out I didn't put a checklist on the RFC comment when I called for FCP. Please check your box. https://github.com/hyperledger/sawtooth-rfcs/pull/4

amundson (Thu, 25 Oct 2018 15:48:52 GMT):
@danintel and I propose adopting the FAQ (https://github.com/danintel/sawtooth-faq/) as the official sawtooth FAQ and moving it to a hyperledger repository. ben betts is going to work on integrating the FAQ with the new website so that we can publish it as part of the site. I'll call for a root team vote later after some time for discussion.

danintel (Thu, 25 Oct 2018 15:48:52 GMT):
Has joined the channel.

amundson (Thu, 25 Oct 2018 15:55:00 GMT):
I propose we treat the FAQ as part of the website from a maintainership perspective even if we keep it in a separate repository, or at least start with a similarly liberal maintainer list. And that we add @danintel as a maintainer on the website in addition to the FAQ.

amundson (Fri, 26 Oct 2018 14:47:32 GMT):
@danintel how strongly do you feel about keeping the FAQ in a separate repository? if we add it as a subdirectory in the website repo, it might encourage others to help with the website (because the FAQ is more approachable than other aspects of the site)?

danintel (Fri, 26 Oct 2018 15:27:26 GMT):
I see the website ad scaffolding more than anything else. But yes we can try that as one depository

amundson (Fri, 26 Oct 2018 16:47:47 GMT):
ok, we probably don't need a root team vote if we are going to pull the faq into the existing website repo, since it's not a separate component and we can just solicit maintainer PR approvals. if anyone disagrees, let me know.

amundson (Fri, 26 Oct 2018 16:49:35 GMT):
@danintel even with pulling it into the website repo, I'd like to keep the commit history. this is fairly easy. but before we create the PR, did you want to update the license to be CC in your repo?

danintel (Fri, 26 Oct 2018 16:52:26 GMT):
I updated to cc yesterday. FYI I am at a conference today

amundson (Fri, 26 Oct 2018 16:54:56 GMT):
oh, awesome!

athulramesh (Mon, 29 Oct 2018 13:24:50 GMT):
Has joined the channel.

chainsaw (Wed, 31 Oct 2018 14:29:15 GMT):
Has joined the channel.

rbuysse (Thu, 01 Nov 2018 16:05:51 GMT):
There's a proposal to move RFC# 25 to final comment period: https://github.com/hyperledger/sawtooth-rfcs/pull/25 @Dan @adamludvik can you take a look?

rbuysse (Thu, 01 Nov 2018 18:25:47 GMT):
Thanks!

rbuysse (Thu, 01 Nov 2018 18:49:59 GMT):
the docker-compose build RFC has been moved to final comment period: https://github.com/hyperledger/sawtooth-rfcs/pull/25

Dan (Thu, 01 Nov 2018 19:49:36 GMT):
cool. if you didn't already please hit the list

knkski (Fri, 02 Nov 2018 20:02:54 GMT):
Has joined the channel.

knkski (Fri, 02 Nov 2018 20:03:53 GMT):
The Seth JSON-RPC API RFC has moved to final comment period: https://github.com/hyperledger/sawtooth-rfcs/pull/22

agunde (Tue, 13 Nov 2018 15:16:29 GMT):
@kelly_ can you please take a look at https://github.com/hyperledger/sawtooth-rfcs/pull/16

kelly_ (Wed, 14 Nov 2018 17:10:37 GMT):
Approved! sorry for the delay I though I had already done that

kelly_ (Wed, 14 Nov 2018 17:11:21 GMT):
I had one question that isn't a hold up though - some of those JS capabilites like generating keys, constructing transactions, etc. seem like they would be broadly useful beyond supply chain

kelly_ (Wed, 14 Nov 2018 17:11:59 GMT):
so I was wondering if rather than being in the supply chain repo that would be some sort of client side library that could span repos (e.g. next-directory, marketplace, etc.)

kelly_ (Wed, 14 Nov 2018 17:16:47 GMT):
and then maybe some stuff like the UI or things specific to supply chain e.g. agents, would go in supply chain

amundson (Thu, 15 Nov 2018 18:53:40 GMT):
@kelly_ constructing transactions as an example -- we already have that capability generically in the Sawtooth Javascript SDK to construct and sign transactions -- this RFC is about providing a supply-chain-specific API to create supply-chain-specific transactions

nhrishi (Mon, 10 Dec 2018 17:23:37 GMT):
Has joined the channel.

DatNguyen (Tue, 11 Dec 2018 07:22:49 GMT):
Has joined the channel.

agunde (Thu, 13 Dec 2018 21:04:50 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/16 this entered FCP but we didn't put the normal comment on it at the time or properly mention it here. if there are no objections, we will merge it tomorrow

kelly_ (Fri, 14 Dec 2018 00:12:06 GMT):
good with me

agunde (Sat, 15 Dec 2018 19:24:02 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/16 has been merged

Dan (Mon, 17 Dec 2018 15:22:35 GMT):
Core team please add vote to: https://github.com/hyperledger/sawtooth-rfcs/pull/23

agunde (Wed, 19 Dec 2018 20:47:17 GMT):
@pschwarz @amundson @adamludvik looks like that rfc is waiting on your vote ^

pschwarz (Wed, 19 Dec 2018 21:07:13 GMT):
Added a couple of comments

merq (Sat, 22 Dec 2018 03:40:14 GMT):
Has joined the channel.

hidura (Thu, 27 Dec 2018 05:00:23 GMT):
Has joined the channel.

Dan (Thu, 27 Dec 2018 19:22:18 GMT):
@pschwarz can you see if those are now addressed? https://github.com/hyperledger/sawtooth-rfcs/pull/23

Dan (Thu, 27 Dec 2018 19:22:54 GMT):
@amundson @adamludvik please also review/approve.

agunde (Fri, 04 Jan 2019 14:35:59 GMT):
Please take the time to review this RFC https://github.com/hyperledger/sawtooth-rfcs/pull/32 @pschwarz @amundson @Dan @jsmitchell @adamludvik

satish67 (Wed, 09 Jan 2019 09:22:57 GMT):
Has joined the channel.

satish67 (Wed, 09 Jan 2019 09:23:06 GMT):
Hello, everyone, i have a general question regarding sawtooth architecture, as sawtooth can execute the parallel transaction processor, does it mean for each transaction processor ledger will be different like channel in fabric, thanks in advance

kelly_ (Tue, 15 Jan 2019 00:33:02 GMT):
if anyone has any updates they'd like to get into the next Hyperledger Sawtooth TSC, please @ me and let me know! https://wiki.hyperledger.org/groups/tsc/project-updates/sawtooth-2019-jan

kelly_ (Tue, 15 Jan 2019 00:33:04 GMT):
thanks!

agunde (Wed, 16 Jan 2019 13:28:38 GMT):
Please take a look at https://github.com/hyperledger/sawtooth-rfcs/pull/34 when you have time @pschwarz @amundson @Dan @jsmitchell @adamludvik

amundson (Thu, 24 Jan 2019 17:09:23 GMT):
going to start up a discussion in #sawtooth-release (mentioning it here incase not everyone is in that channel currently)

amundson (Fri, 25 Jan 2019 15:46:56 GMT):
Because of https://github.com/hyperledger/sawtooth-sdk-rust/pull/7 and maybe other upcoming API changes in the Rust SDK, I propose we create a branch for the current version and increment the minor version in master (and not release master until we think we have the near-term breaking changes done).

moulika (Mon, 28 Jan 2019 11:03:54 GMT):
Has joined the channel.

vinayak mahajan (Mon, 04 Feb 2019 15:42:25 GMT):
Has joined the channel.

rbuysse (Mon, 18 Feb 2019 19:51:34 GMT):
A 0-2 branch has been created for the Rust SDK. https://github.com/hyperledger/sawtooth-sdk-rust/tree/0-2

rbuysse (Mon, 18 Feb 2019 19:51:57 GMT):
Also, master has been incremented to 0.3.0.

agunde (Tue, 19 Feb 2019 14:16:56 GMT):
Please take a look at https://github.com/hyperledger/sawtooth-rfcs/pull/37 @adamludvik @Dan @jsmitchell @kelly_ @pschwarz @amundson @TomBarnes

duncanjw (Fri, 22 Feb 2019 11:02:36 GMT):
@agunde Hi. I'm keen to understand status/progress on https://github.com/hyperledger/sawtooth-rfcs/pull/34

agunde (Fri, 22 Feb 2019 14:09:29 GMT):
@duncanjw That RFC is still under review. Currently, there are several comments by the core team that have not been addressed.

jsmitchell (Fri, 22 Feb 2019 14:34:45 GMT):
A depth first search of any sub tree of the merkle trie seems like a bad idea from the TP in all but the most trivial cases. How would we ensure the call returns in a timely manner? Should we truncate results and have some kind of cursor support? A better idea would be to have the updates maintain some index structure that has some predictable characteristics in terms of number of accesses. The best idea would be to maintain that index in a query friendly database via the event system and shift the responsibility of understanding * out of the TP to the client code.

kodonnel (Fri, 22 Feb 2019 19:56:24 GMT):
Has joined the channel.

duncanjw (Fri, 22 Feb 2019 21:57:36 GMT):
@jsmitchell having talked to @kodonnel I think you are right _but_ looking at this from the client perspective is there anything we can do to assist them IE rather than tell them to RTFM so-to-speak give them some patterns to work with?

jsmitchell (Fri, 22 Feb 2019 21:58:07 GMT):
it's a challenge

duncanjw (Fri, 22 Feb 2019 21:58:12 GMT):
Otherwise we risk turning off developers - that's my concern

jsmitchell (Fri, 22 Feb 2019 21:58:26 GMT):
because spinning up the state delta export stuff is non-trivial

jsmitchell (Fri, 22 Feb 2019 21:59:16 GMT):
it would be nice if we had some data definition language approach where we could autogenerate domain specific materialization

jsmitchell (Fri, 22 Feb 2019 21:59:27 GMT):
and just provide some docker examples

duncanjw (Fri, 22 Feb 2019 22:03:14 GMT):
I'll let @kodonnel chime in on this as he is way more qualified than I am but anything we can do to help here would be great if we want to create a solid migration story here (as epitomised by ScanTrust webinar that asserted their code more or less ported across with the main thing being how to figure out what state should now be stored on chain etc)

duncanjw (Fri, 22 Feb 2019 22:03:45 GMT):
Maybe we need a separate sawtooth-dev-experience thread?

kodonnel (Fri, 22 Feb 2019 22:05:57 GMT):
@jsmitchell I'm conscious that we began the state delta export stuff and then faded out :) It's a good point though, if we had what we started describing the obvious thing would be just "how to"examples.

kodonnel (Fri, 22 Feb 2019 22:06:09 GMT):
or at least I faded out :)

agunde (Mon, 25 Feb 2019 19:08:16 GMT):
We have a series of PBFT RFCs that are in need of reviews please take a look at the following @pschwarz @amundson @Dan @TomBarnes @kelly_ @jsmitchell @adamludvik https://github.com/hyperledger/sawtooth-rfcs/pull/29 https://github.com/hyperledger/sawtooth-rfcs/pull/30 https://github.com/hyperledger/sawtooth-rfcs/pull/31

agunde (Mon, 25 Feb 2019 19:08:16 GMT):
We have a series of PBFT RFCs that are in need of reviews please take a look at the following @pschwarz @amundson @Dan @TomBarnes @kelly_ @jsmitchell https://github.com/hyperledger/sawtooth-rfcs/pull/29 https://github.com/hyperledger/sawtooth-rfcs/pull/30 https://github.com/hyperledger/sawtooth-rfcs/pull/31

ltseeley (Mon, 25 Feb 2019 19:20:48 GMT):
Has joined the channel.

amundson (Mon, 25 Feb 2019 21:42:57 GMT):
@duncanjw the delete-by-prefix RFC will likely do what that team needs and doesn't have the performance problems or support issues

haggs (Sun, 03 Mar 2019 21:39:37 GMT):
Has joined the channel.

mfford (Wed, 06 Mar 2019 19:29:21 GMT):
We'd like to start-up a monthly "Hyperledger Sawtooth Contributor Meeting" and I propose that we begin our first session on Monday, March 25th at 10am CDT. In preparation for each meeting, I would request agenda items from interested participants the week prior. Open to thoughts and feedback for moving forward in scheduling these meetings.

pankajcheema (Thu, 07 Mar 2019 05:51:24 GMT):
Has joined the channel.

arsulegai (Mon, 11 Mar 2019 17:50:01 GMT):
Thanks :)

amundson (Tue, 12 Mar 2019 16:57:33 GMT):
I'd like to propose we make a special push in the next week to move along some of the RFCs. There are probably several that could go into FCP but just need a read-through from some of us.

Dan (Wed, 13 Mar 2019 19:01:35 GMT):
Consider renaming the satooth tech form as the "Sawtooth Forum" so we can accomodate end usage presentations.

amundson (Thu, 14 Mar 2019 03:54:42 GMT):
seems fine to me

agunde (Tue, 19 Mar 2019 22:25:46 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/37 has a request to move the Swift SDK RFC to FCP. Root team please take a look. @amundson @Dan @TomBarnes @kelly_ @adamludvik @jsmitchell @pschwarz

agunde (Tue, 19 Mar 2019 22:34:12 GMT):
There are also 3 PBFT RFC that I am requesting enter the FCP and then be merged. https://github.com/hyperledger/sawtooth-rfcs/pull/29 https://github.com/hyperledger/sawtooth-rfcs/pull/30 https://github.com/hyperledger/sawtooth-rfcs/pull/31 Core team please take a look @amundson @Dan @jsmitchell @pschwarz @adamludvik

amundson (Thu, 21 Mar 2019 19:19:00 GMT):
@Dan @TomBarnes @kelly_ @adamludvik @jsmitchell ^

jsmitchell (Thu, 21 Mar 2019 19:20:26 GMT):
approved

Dan (Thu, 21 Mar 2019 19:21:48 GMT):
I'm batting like 500. As I understand baseball that makes me awesome.

agunde (Sat, 23 Mar 2019 00:23:59 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/29 has entered its final comment period. If there are no substantive requests for changes by March 29, 2019 it will be merged.

agunde (Mon, 25 Mar 2019 20:03:19 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/30 has entered the final comment period. If there are no substantive requests for changes by April 1st, 2019 it will be merged.

agunde (Mon, 25 Mar 2019 20:04:15 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/31 has also entered the final comment period and will be merged on April 1st, 2019.

amundson (Tue, 26 Mar 2019 19:00:20 GMT):
Given the discussion in #sawtooth-next-directory, we should consider archiving the hyperledger/sawtooth-next-directory repository, given T-Mobile is moving their development outside of hyperledger, and putting links to the tmobile repository instead. The project should stop using 'Sawtooth' in its name.

duncanjw (Wed, 27 Mar 2019 14:03:22 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-governance?msg=sReFdm4HKe8ax8pJ9) @amundson @amundson under ASL 2.0 any one can do this at any time and is free to use the same name. Also to put this in context @ChrisSpanton has made it clear that they will be contributing regular PRs to Hyperledger. Clearly this would be a non-starter for core Sawtooth development. However it sounds like a pragmatic approach in the case of a Sawtooth add-on/extension/app. BTW I am not sure what to all it exactly but FYI @Silona is working on HL wide revamp of project taxonomy so watch this space for correct classification

duncanjw (Wed, 27 Mar 2019 14:03:22 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-governance?msg=sReFdm4HKe8ax8pJ9) @amundson under ASL 2.0 any one can do this at any time and is free to use the same name. Also to put this in context @ChrisSpanton has made it clear that they will be contributing regular PRs to Hyperledger. Clearly this would be a non-starter for core Sawtooth development. However it sounds like a pragmatic approach in the case of a Sawtooth add-on/extension/app. BTW I am not sure what to all it exactly but FYI @Silona is working on HL wide revamp of project taxonomy so watch this space for correct classification

Silona (Wed, 27 Mar 2019 14:03:22 GMT):
Has joined the channel.

amundson (Wed, 27 Mar 2019 14:48:31 GMT):
@duncanjw This isn’t currently a licensing or trademark discussion; the presumption that the ASL is a guide for what we should do as a project is erroneous.

amundson (Wed, 27 Mar 2019 14:53:27 GMT):
Mirroring an external repo into a Hyperledger repo cannot be equated with the regular PR process, which is about community peer review.

amundson (Wed, 27 Mar 2019 14:59:03 GMT):
Having projects external to sawtooth, but open and visible like next directory, is really valuable and desirable, and lends credibility to the platform.

ChrisSpanton (Wed, 27 Mar 2019 16:24:08 GMT):
@duncanjw @amundson Thanks for the discussion. We're certainly happy to follow along with whatever provides the best conformity with project standards and goals. That said, it's been clear that the Next Directory project has not been properly homed in its current location.

ChrisSpanton (Wed, 27 Mar 2019 16:27:21 GMT):
I'd love for this to open a broader discussion about how Hyperledger can nurture its growing community of applications. My understanding is that top-level projects have been identified as a home for "tools and frameworks, not applications". In my opinion relegating applications to sub-projects or labs efforts seems to miss the mark - its production-ready applications which ultimately will grow this community

amundson (Wed, 27 Mar 2019 16:38:46 GMT):
I agree that we need to encourage that discussion and there should be some space for applications. Also agree that considering them sub projects would be the wrong direction, because it is awkward and apps should be encouraged to use more than one HL project (assuming it makes sense for the app).

amundson (Wed, 27 Mar 2019 16:44:03 GMT):
If next directory went to labs, it should be with intent to become its own HL project and further this discussion within HL. I would support that path and advocate/support as much as possible for a spot within HL to make it an app project.

agunde (Thu, 28 Mar 2019 13:17:43 GMT):
@adamludvik Has resigned from being a part of the Sawtooth Governance process. As such I put up a PR to remove him from the root and core team. https://github.com/hyperledger/sawtooth-rfcs/pull/42 Thanks Adam for all your hard work.

agunde (Thu, 28 Mar 2019 15:45:06 GMT):
The Swift SDK RFC has entered its final comment period https://github.com/hyperledger/sawtooth-rfcs/pull/37 If there are no substantive requests for changes by April 4th, 2019 it will be merged.

amundson (Thu, 28 Mar 2019 16:04:15 GMT):
awesome!

amundson (Thu, 28 Mar 2019 18:28:31 GMT):
@ChrisSpanton what are your thoughts about attempting labs->project approach?

ChrisSpanton (Thu, 28 Mar 2019 18:37:44 GMT):
@amundson I refreshed myself on the docs for Labs, and that doesn't really feel like a fit either. It seems like we'd move from one awkward home to another. I'd like to continue contributing to HL and Sawtooth specifically, but my opinion is that it needs to be done in a way that fits for both us, and HL/Sawtooth communities. I'd love to hear from TSC... @kelly_ and others?

amundson (Thu, 28 Mar 2019 18:49:07 GMT):
@ChrisSpanton I may agree re:labs. What specifically about labs feels not great from your perspective?

jsmitchell (Thu, 28 Mar 2019 18:49:59 GMT):
Introducing Hyperledger Apps

amundson (Thu, 28 Mar 2019 18:50:43 GMT):
hyperledger apps (a peer to hyperledger labs) is, ultimately, what I think we should push for

amundson (Thu, 28 Mar 2019 18:52:24 GMT):
we could propose it, though it won't be liked much by some, for sure

amundson (Thu, 28 Mar 2019 19:01:45 GMT):
@ChrisSpanton another ongoing discussion we've been having is to collapse all the non-framework code (like, sawtooth-mktplace, sawtooth-explorer, bond, battleship, etc.) into a sawtooth-contrib repository that we don't branch or do releases from, but also isn't expected to have the same rigor as applied to the other framework repos. This is what we are doing w/Grid. I think there is a fair amount of code that we could get contributed to such a repo that wouldn't meet the threshold of adding as an official component itself.

amundson (Thu, 28 Mar 2019 19:04:35 GMT):
(sawtooth-supply-chain would also go there)

ChrisSpanton (Thu, 28 Mar 2019 21:06:40 GMT):
"Examples of possible Labs include: projects too early for TSC approval as an incubator because there’s not a lot of code; demos; documentation examples; sample code from hackathons, research projects, etc." https://www.hyperledger.org/blog/2018/01/23/introducing-hyperledger-labs

ChrisSpanton (Thu, 28 Mar 2019 21:09:25 GMT):
None of this is close to "Complete enterprise grade blockchain applications, with hundreds of work-hours/week of contribution"

amundson (Thu, 28 Mar 2019 21:58:35 GMT):
@ChrisSpanton That description also seems consistent with the types of projects currently in labs, and probably how people think of labs.

danintel (Fri, 29 Mar 2019 04:36:22 GMT):
Fyi Kelly and Dan M. Are out on sabattical for now

agunde (Fri, 29 Mar 2019 14:32:16 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/29 has been merged

duncanjw (Sun, 31 Mar 2019 15:38:11 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-governance?msg=mdbwE6cSLKu85fhBk) @ChrisSpanton Agreed. This is something @Silona is looking into as Hyperledger Grid is not a framework so needs to be be reclassified. Likewise Next Directory. Both IMO should be top-level. How the taxonomy evolves we need to recognize the value of applications or services built on top of frameworks which are clearly way beyond labs/spikes. My 2c.

agunde (Mon, 01 Apr 2019 17:32:01 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/30 has been merged

agunde (Mon, 01 Apr 2019 17:32:39 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/31 has been merged

ChrisSpanton (Mon, 01 Apr 2019 17:35:24 GMT):
[ ](https://chat.hyperledger.org/channel/sawtooth-governance?msg=i5cJfBSfiuDPSvudn) @duncanjw Thanks @duncanjw. Is there anything I can be doing, conversations I can support, or effort that can otherwise help with to get us to the next phase here?

agunde (Mon, 01 Apr 2019 18:29:14 GMT):
As we have had several RFC get approved recently, I would like to keep up the momentum and continue discussion on two other RFCs. Core team (and others), please take the time to look at/comment on https://github.com/hyperledger/sawtooth-rfcs/pull/32 and https://github.com/hyperledger/sawtooth-rfcs/pull/39 @Dan @jsmitchell @pschwarz @amundson

kumble (Tue, 02 Apr 2019 01:19:57 GMT):
Has joined the channel.

Dan (Tue, 02 Apr 2019 21:31:00 GMT):
looks good to me

amundson (Tue, 02 Apr 2019 22:20:41 GMT):
I think for #32, we need to determine if Client* is the right place for this feature.

Kirill_Vusik (Wed, 03 Apr 2019 15:23:35 GMT):
Has joined the channel.

agunde (Thu, 04 Apr 2019 14:59:54 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/37 has been merged

Dan (Thu, 18 Apr 2019 13:59:52 GMT):
@TomBarnes @amundson you are both listed as reviewers of the state pruning RFC. Please indicate your approval (I assume) and we can enter FCP. https://github.com/hyperledger/sawtooth-rfcs/pull/8 p.s. it's almost 1 year old.

agunde (Thu, 18 Apr 2019 14:02:02 GMT):
@Dan I believe that RFC need to be updated to match the actual implementation. @pschwarz is that correct?

amundson (Thu, 18 Apr 2019 14:53:02 GMT):
we should probably focus on the two that Andi suggested before taking up others - https://github.com/hyperledger/sawtooth-rfcs/pull/32 and https://github.com/hyperledger/sawtooth-rfcs/pull/39

amundson (Thu, 18 Apr 2019 14:54:51 GMT):
I'm not comfortable adding #32 to the client API

amundson (Thu, 18 Apr 2019 14:55:49 GMT):
The capability in #32 is definitely desirable though

amundson (Thu, 18 Apr 2019 15:00:02 GMT):
#39 probably just needs to be cleaned up a bit

Dan (Thu, 18 Apr 2019 15:00:58 GMT):
ok, i will ping author on #39. looks like we have more to discuss in #sawtooth-core-dev or github on #32.

amundson (Thu, 18 Apr 2019 15:05:00 GMT):
I added a couple comments on #39. I think we might want to get more aggressive generally on opening up PRs against these RFC source branches to get things cleaned up.

Dan (Thu, 18 Apr 2019 15:06:28 GMT):
well actually before I tell the author that there's only text cleanup, can I get @jsmitchell to review #39?

jsmitchell (Thu, 18 Apr 2019 15:08:40 GMT):
seems like it would be just as easy for you to go in and make grammar corrections as it would me

jsmitchell (Thu, 18 Apr 2019 15:09:13 GMT):
i don't have issues with the semantic content

pschwarz (Thu, 18 Apr 2019 15:10:25 GMT):
That's true - there is a missing chuck of stuff that handles the duplicate entries in multiple tries

Dan (Thu, 18 Apr 2019 15:12:47 GMT):
@jsmitchell sure. it wasn't evident from the PR comments whether you had reviewed in any manner. Wanted to be sure if you did have design feedback that was logged before I asked for a final revision from the author.

jsmitchell (Thu, 18 Apr 2019 15:13:44 GMT):
ah, apologies. I thought you were asking for a editorial pass.

amundson (Thu, 18 Apr 2019 16:42:47 GMT):
@Dan I did add a question to #39 about what it would look like to overload this on the existing API.

amundson (Thu, 18 Apr 2019 17:07:19 GMT):
should we switch away from JIRA and start using github issues?

rjones (Thu, 18 Apr 2019 18:57:17 GMT):
Has joined the channel.

amundson (Thu, 18 Apr 2019 19:05:00 GMT):
In the DAML blog entry, there is mention of it being contributed to Sawtooth, but we haven't seen any source code or community involvement on that topic yet. Does anyone have any insight into the plans? Is there an RFC incoming?

rjones (Thu, 18 Apr 2019 19:08:16 GMT):
https://www.hyperledger.org/blog/2019/04/16/daml-smart-contracts-coming-to-hyperledger-sawtooth

amundson (Thu, 18 Apr 2019 19:15:35 GMT):
There are several good things about using JIRA, but I wonder if we would have more bugs and feature requests being reported if we were using github issues. HL projects seem pretty split as to which they are using. We are planning to take some Sawtooth and Grid backlog that @agunde and I have and enter it, and it would be good to validate which place is best for Sawtooth long-term before we start that process so we aren't wasting our time re-entering later.

amundson (Thu, 18 Apr 2019 19:15:50 GMT):
@Dan @mfford ^

mfford (Thu, 18 Apr 2019 19:22:06 GMT):
Part of the question would be what does JIRA provide that Github cannot? You can report issues, assign and respond in both.

Dan (Thu, 18 Apr 2019 19:22:14 GMT):
I'm inclined to stick with Jira unless there's significant benefit to change. I wonder if there's some way to test-drive github issues, like only for one repo, without just confusing people.

mfford (Thu, 18 Apr 2019 19:23:00 GMT):
Proposals for introducing features and capabilities are part of the governance process that doesn't rely on JIRA

rjones (Thu, 18 Apr 2019 19:28:14 GMT):
GitHub issues do not support secure disclosure.

rjones (Thu, 18 Apr 2019 19:29:07 GMT):
so, each project will need to maintain a JIRA presence so that security issues can be disclosed to trusted people.

rjones (Thu, 18 Apr 2019 19:30:01 GMT):
advantages of the GitHub workflow: you can refer to issues in PRs and close them, marking the issues as updated automagically.

rjones (Thu, 18 Apr 2019 19:30:19 GMT):
@dhuseby can address the first point.

dhuseby (Thu, 18 Apr 2019 19:30:20 GMT):
Has joined the channel.

Dan (Thu, 18 Apr 2019 19:32:39 GMT):
we have 423 repos. it might be hard for people to know where to log a bug/feature request.

rjones (Thu, 18 Apr 2019 19:32:58 GMT):
ah I think 434 as of this morning

Dan (Thu, 18 Apr 2019 19:33:08 GMT):
damn missed some

mfford (Thu, 18 Apr 2019 19:33:18 GMT):
@rjones Your point about" refer to issues in PRs and close them" feeds into my thought about reducing the barriers of participation for the community, by having less steps for engagement with these systems

rjones (Thu, 18 Apr 2019 19:34:20 GMT):
@mfford to be clear: I don't personally have strong feelings about JIRA versus GitHub issues. I think they're both woeful. If I put on my CA hat, I would beg you to use JIRA

rjones (Thu, 18 Apr 2019 19:34:44 GMT):
@amundson to your earlier point: https://github.com/digital-asset/daml/issues/616

agunde (Thu, 18 Apr 2019 19:35:21 GMT):
@Dan Thats a fair point but it would allow for SDK issues to be in the SDK repo the issue is related to. Instead of hidden by a bunch of core issues.

agunde (Thu, 18 Apr 2019 19:35:21 GMT):
@Dan Thats a fair point but it would allow for SDK issues to be in the SDK repo the issue is related to, for example. Instead of hidden by a bunch of core issues.

rjones (Thu, 18 Apr 2019 19:36:43 GMT):
@agunde it's kind of the same problem, though. I had a long conversation with someone trying to figure out where to file a bug for fabric. they have a bunch of distinct sub-projects in JIRA: https://jira.hyperledger.org/projects/FABN/issues/FABN-1205?filter=allopenissues for instance

jsmitchell (Thu, 18 Apr 2019 19:37:46 GMT):
@rjones i don't see any commits or branches in that repo that contain sawtooth TP like things

rjones (Thu, 18 Apr 2019 19:38:15 GMT):
@agunde this is a better link: https://jira.hyperledger.org/projects/FAB?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page

rjones (Thu, 18 Apr 2019 19:38:27 GMT):
@jsmitchell perhaps I found the wrong repo, then.

jsmitchell (Thu, 18 Apr 2019 19:38:52 GMT):
well, i think that was the open question

amundson (Thu, 18 Apr 2019 19:39:24 GMT):
@Dan re "we have 423 repos. it might be hard for people to know where to log a bug/feature request." - but, they can be reported on the repo that impacts it. maybe the maintainers would get better at opening up bugs.

rjones (Thu, 18 Apr 2019 19:39:33 GMT):
I know as much as anyone else in this channel. I am trying to provide some context.

jsmitchell (Thu, 18 Apr 2019 19:39:54 GMT):
so, we agree that none of us know anything about it ;)

rjones (Thu, 18 Apr 2019 19:40:06 GMT):
@amundson here is a real-world problem from this week: where to file a bug about an IDEMIX implementation?

rjones (Thu, 18 Apr 2019 19:40:58 GMT):
this is the issue: https://jira.hyperledger.org/projects/FABN/issues/FABN-689?filter=allopenissues OP added documentation and was expecting a design review, and I spent a long time trying to find someone to provide better direction

amundson (Thu, 18 Apr 2019 19:41:23 GMT):
@rjones I don't have the context for that DAML issue - are they proposing it as a HL project and that's some pre-work?

rjones (Thu, 18 Apr 2019 19:41:41 GMT):
is it a Fabric bug? a Fabric node issue? a crypto-lib issue?

rjones (Thu, 18 Apr 2019 19:41:53 GMT):
@amundson I think that's the repo under discussion, yes

rjones (Thu, 18 Apr 2019 19:42:28 GMT):
I've been running this dco check everywhere, and the results are not good.

amundson (Thu, 18 Apr 2019 19:43:35 GMT):
@rjones I looked through some of the default branch of daml and didn't see any sawtooth stuff, so I assume it is in a different repo.

rjones (Thu, 18 Apr 2019 19:43:35 GMT):
```sawtooth-core ry$ lftools dco check | grep ^ERR | wc -l 1378 ```

rjones (Thu, 18 Apr 2019 19:43:46 GMT):
@amundson OK.

amundson (Thu, 18 Apr 2019 19:47:45 GMT):
@rjones I assume those are all prior to the commit we added when sawtooth was moved to HL, a commit that essentially certified that the history was all contributed by Intel. thus effectively achieving the DCO on those commits retroactively.

rjones (Thu, 18 Apr 2019 19:49:25 GMT):
here's a random one on master: ```commit 72e3dda00fd9e7686a75f42314f87c46367179d0 Author: Adam Ludvik Date: Fri Mar 3 08:46:11 2017 -0600 Script building external debs. ```

rjones (Thu, 18 Apr 2019 19:50:18 GMT):
```commit 3a7c4b32350a77766c41c84e3aa520bf748afd16 Author: Shawn T. Amundson Date: Sat Aug 20 11:43:24 2016 -0500 Repo merge: move all files to subdirectory ```

rjones (Thu, 18 Apr 2019 19:50:57 GMT):
```commit 26d085995b626ac53559d7905a5ff5bcc59d2333 Author: Adam Ludvik Date: Fri Mar 3 08:15:29 2017 -0600 FIXUP remove unused directory and make work outside sawtooth-core ```

rjones (Thu, 18 Apr 2019 19:51:04 GMT):
so not all of them?

rjones (Thu, 18 Apr 2019 19:52:15 GMT):
https://github.com/digital-asset/daml/issues/616#issuecomment-484663798 wrong repo

jsmitchell (Thu, 18 Apr 2019 19:52:40 GMT):
@rjones is that script equivalent to `git log --no-merges --invert-grep --grep=Signed-off-by`?

rjones (Thu, 18 Apr 2019 19:54:55 GMT):
```status=0 while IFS= read -a line; do my_array+=( "$line" ) done < <( git branch -r | grep -v origin/HEAD ) for branch in "${my_array[@]}" do status=1 branch=$(echo "$branch" | xargs) echo "Checking commits in branch $branch for commits missing DCO..." git log $branch --no-merges --pretty="%H" --grep 'Signed-off-by' --invert-grep * | \ while read commit_hash; do echo "ERROR: Commit $commit_hash is missing Signed-off-by line." done done exit $status ```

rjones (Thu, 18 Apr 2019 19:55:23 GMT):
so, yes, iterating by branch.

Dan (Thu, 18 Apr 2019 19:56:28 GMT):
I think there was a point before DCO-bot came in where so long as we had developer attestations that satisfied the DCO obligation.

amundson (Thu, 18 Apr 2019 19:57:48 GMT):
well, and before that we had checks in Jenkinsfile, which are still there

amundson (Thu, 18 Apr 2019 19:57:53 GMT):
but before that, not

rjones (Thu, 18 Apr 2019 19:58:01 GMT):
@jsmitchell if you look at the gist I posted above, it shows installing lftools from pip

rjones (Thu, 18 Apr 2019 19:58:01 GMT):
@jsmitchell if you look here: https://gist.github.com/ryjones/07ac650dcc5e83c91e8308ec98bacda4, it shows installing lftools from pip

jsmitchell (Thu, 18 Apr 2019 20:00:53 GMT):
yeah, i seem to recall signing some document

jsmitchell (Thu, 18 Apr 2019 20:05:17 GMT):
presumably those are stored in the hyperledger vaults somewhere

amundson (Thu, 18 Apr 2019 20:10:49 GMT):
"Please consider this a retroactive Signed-off-by" from trbs at one point

amundson (Thu, 18 Apr 2019 20:14:44 GMT):
yeah, maybe we only did the commit for trbs because that wasn't Intel

amundson (Thu, 18 Apr 2019 20:15:12 GMT):
I suspect there is another commit though

rjones (Thu, 18 Apr 2019 20:17:19 GMT):
the inability of iroha to round up previous code contributors is what lead to the squash. I only became aware of this tool in the last two weeks; of course, after beating up iroha, I ran it on all the other repos.

amundson (Thu, 18 Apr 2019 20:17:40 GMT):
"Reverting as commit has lack of a Signed-off-by."

amundson (Thu, 18 Apr 2019 20:17:58 GMT):
that must be when we were cleaning stuff up, then later I think the commit with that contents came back

rjones (Thu, 18 Apr 2019 20:18:04 GMT):
they had 9 committers and they were only able to find one

rjones (Thu, 18 Apr 2019 20:19:59 GMT):
Here are the results as of last week: https://gist.github.com/ryjones/04f35c7610f2cdd17e517eea2ca072bf

amundson (Thu, 18 Apr 2019 20:20:24 GMT):
@rjones squashing the history doesn't really fix anything from a licensing perspective

amundson (Thu, 18 Apr 2019 20:20:43 GMT):
it's not like those other 8 contributors no longer contributed

rjones (Thu, 18 Apr 2019 20:21:11 GMT):
I'm using the guidance I have from our legal team.

amundson (Thu, 18 Apr 2019 20:21:21 GMT):
what's the PBFT commit?

amundson (Thu, 18 Apr 2019 20:21:48 GMT):
might need new lawyers. jk.

rjones (Thu, 18 Apr 2019 20:22:55 GMT):
¯\_(ツ)_/¯

rjones (Thu, 18 Apr 2019 20:23:22 GMT):
I'm having this conversation with indy right now, as they have a similar problem

rjones (Thu, 18 Apr 2019 20:23:48 GMT):
and they're splitting up repos, playing tetris, etc so it's an opportune time for `git filter-branch` shenanigans

rjones (Thu, 18 Apr 2019 20:24:05 GMT):
WRT: https://docs.google.com/document/d/1x9O2m-jr282srH1BRcOJQjTROes8T7lnosI2_IPB26E/edit?ts=5c3771d1

agunde (Thu, 18 Apr 2019 20:25:55 GMT):
@amundson https://github.com/hyperledger/sawtooth-pbft/commit/36b1a18ed6730bcee5ef5e727c7ebb10a61c0098

kodonnel (Thu, 18 Apr 2019 22:31:05 GMT):
Re: DAMl So our thinking is that the integration ends up similar to Seth or sabre - and so that means an RFC in all it's glory. Since the integration is a bit involved to do, the plan is to get a first functional pass done before the source is opened up. Obviously that's a pre-requisite to contributing it. Incidentally the integration is a separate project from DAML itself much like burrow is to Seth. So there's some dependency on what is going on there as well, but it's all heading in the right direction.

amundson (Thu, 18 Apr 2019 22:44:13 GMT):
@kodonnel cool, thanks. can’t wait to see it.

kodonnel (Thu, 18 Apr 2019 22:44:29 GMT):
Won't be too long 😁

Dan (Thu, 18 Apr 2019 23:17:33 GMT):
@kodonnel yeah super cool! I don't think you need to wait on functional code to put up the RFC. That way if there's something that sticks out in the RFC you get that feedback early.

kodonnel (Fri, 19 Apr 2019 00:12:27 GMT):
@Dan fair point

Dan (Fri, 19 Apr 2019 16:11:31 GMT):
I don't see any java style standards / lint enforcement in our project. If I missed it let me know. If not, then any objection to using google's style guide? https://google.github.io/styleguide/javaguide.html

kodonnel (Fri, 19 Apr 2019 17:19:21 GMT):
I don't love 2 space indents for java, but I don't hate it enough to make the argument :) google-checks works for me

Dan (Fri, 19 Apr 2019 17:29:57 GMT):
cool. thanks for pointing out the style checks for maven in the repo already. i had missed those.

amundson (Fri, 19 Apr 2019 19:02:11 GMT):
there is a checkstyle.xml in the repo already - no need to re-invent

amundson (Fri, 19 Apr 2019 19:02:31 GMT):
but, also, we should take this to #sawtooth-sdk-dev as this is not a governance discussion

maksimb (Mon, 22 Apr 2019 12:40:01 GMT):
Has joined the channel.

DavidAEdwards (Thu, 25 Apr 2019 13:10:15 GMT):
Has joined the channel.

paul.sitoh (Fri, 10 May 2019 08:59:12 GMT):
Has joined the channel.

amundson (Wed, 15 May 2019 17:43:53 GMT):
FYI - we will be modernizing Sawtooth's JIRA setup and making sure it's compatible with a multi-project kanban board we are configuring. @mfford is the point person on this effort. We will also be entering some stories and doing a bunch of backlog grooming over the next few weeks.

johnfranklin (Fri, 17 May 2019 05:30:59 GMT):
Has joined the channel.

amundson (Mon, 20 May 2019 16:22:14 GMT):
The current description of Sawtooth within in the greenhouse (see www.hyperledger.org) is "Permissioned & permissionless support; EVM transaction family"

amundson (Mon, 20 May 2019 16:22:25 GMT):
I don't think that's a very good description

amundson (Mon, 20 May 2019 16:23:49 GMT):
I think "Smart-contract-enabled Byzantine-fault-tolerant distributed database" would be better

amundson (Mon, 20 May 2019 16:31:04 GMT):
or "Smart-contract-enabled Byzantine-fault-tolerant distributed blockchain", since technically Sawtooth is a blockchain and several of the other frameworks are not

amundson (Mon, 20 May 2019 16:31:36 GMT):
Indy for example has no blocks

jsmitchell (Mon, 20 May 2019 16:45:23 GMT):
ship it

Dan (Mon, 20 May 2019 17:41:59 GMT):
I would guess most people assume that all the stacks are smart-contract enabled ... etc. Want something more differentiating there that doesn't require deep understanding to appreciate why that's a differentiating statement. Need something short and pithy for that graphic. "Maximizes Fault Tolerance & Programability" or something like that. ;)

arsulegai (Mon, 20 May 2019 18:17:39 GMT):
* distributed ledger technology framework?

jsmitchell (Mon, 20 May 2019 19:01:04 GMT):
People's bad assumptions are part of the communication opportunity

amundson (Mon, 20 May 2019 20:04:28 GMT):
I wasn't originally intending the phrase itself to be differentiating between projects I guess as much as accurate for what Sawtooth is.

amundson (Mon, 20 May 2019 20:06:08 GMT):
"Byzantine-fault-tolerant distributed database" is the phrase I've been using to describe when you would use Sawtooth within a larger architecture (such as those we are doing w/Grid). As in, "we use Sawtooth when we need a Byzantine-fault-tolerant distributed database".

amundson (Mon, 20 May 2019 20:07:08 GMT):
but, in a non-conversational sense, I think "Smart-contract-enabled Byzantine-fault-tolerant distributed blockchain" is probably better

rjones (Tue, 21 May 2019 15:55:13 GMT):
say that 1000 times on a show floor

Dan (Tue, 21 May 2019 18:06:51 GMT):
at first i read that as "shower floor".

amundson (Tue, 21 May 2019 19:04:33 GMT):
@rjones I've been saying "byzantine-fault-tolerant distributed database" a lot. You are right, it's not an easy thing to repeat over and over.

rjones (Tue, 21 May 2019 19:09:43 GMT):
When the question I get from everyone is "what is the difference between Fabric and Sawtooth?" I need help from you guys

amundson (Tue, 21 May 2019 20:04:16 GMT):
"byzantine-fault-tolerant distributed" is a good start

Dan (Wed, 22 May 2019 14:01:19 GMT):
or if you want words that people understand, I still like my off the cuff "Maximizes Fault Tolerance & Programability" from above. The details under that is that there's no point to running something you call a blockchain if it's centralized or has single (or a small number) of points of failure. So that leads to features we don't compromise on like cryptographically enforced state agreement and BFT protocols.

amundson (Wed, 22 May 2019 15:28:51 GMT):
what words don't you think people can handle? "byzantine-fault-tolerant"? it's actually good if they enter it into google and realize it's a thing.

amundson (Wed, 22 May 2019 15:29:25 GMT):
any way you soften it, it just makes it mushy and it feels "the same" as everything else

amundson (Wed, 22 May 2019 15:30:37 GMT):
"programability" - so, I agree with this, but it's an opinion, not a technical description, right? others could argue that other systems have a higher "programability" rating based on some criteria

agunde (Fri, 07 Jun 2019 15:01:07 GMT):
RFC for Add new peers without restarting a node https://github.com/hyperledger/sawtooth-rfcs/pull/32 has been reopened at https://github.com/hyperledger/sawtooth-rfcs/pull/44 due to the author loosing access to the previous branch.

bryangross (Fri, 14 Jun 2019 00:16:27 GMT):
Has joined the channel.

agunde (Sat, 22 Jun 2019 16:01:49 GMT):
The first PR to update maintainers has been opened against sawtooth-core https://github.com/hyperledger/sawtooth-core/pull/2175 This PR has the removals and a following PR will add the additions. This requires approval from all current active maintainers.

rjones (Tue, 09 Jul 2019 17:02:18 GMT):
Has left the channel.

AlexanderZhovnuvaty (Wed, 10 Jul 2019 14:48:54 GMT):
Has joined the channel.

amundson (Tue, 30 Jul 2019 18:43:49 GMT):
I think we should set a target date of August 13 for the Sawtooth 1.2 release.

jamesbarry (Wed, 31 Jul 2019 16:30:58 GMT):
Has joined the channel.

ArpanNag (Mon, 05 Aug 2019 14:17:10 GMT):
Has joined the channel.

amundson (Wed, 07 Aug 2019 22:01:38 GMT):
In a recent LR7 test with PoET, the network forked fairly early on, so several of us on the core team would like to delay the 1.2 release at least two weeks so that we can further diagnose. Suggest we discuss the technical detail in #sawtooth-core-dev.

RealDeanZhao (Thu, 08 Aug 2019 04:57:19 GMT):
Has joined the channel.

arsulegai (Thu, 08 Aug 2019 05:53:50 GMT):
Sure, please suggest to have a concrete plan for things to look at. From my point of view given that it was pretty stable for earlier releases of Sawtooth, it'll be good to start looking at features added in 1-2 or major design changes if any.

rbuysse (Fri, 23 Aug 2019 14:51:58 GMT):
Hi there! I've got a new RFC which proposes a sawtooth-contrib repository: https://github.com/hyperledger/sawtooth-rfcs/pull/49

pschwarz (Tue, 03 Sep 2019 20:22:00 GMT):
I've proposed RFC PR 49 be moved into Final comment period: https://github.com/hyperledger/sawtooth-rfcs/pull/49#issuecomment-527623001 The Root Team can vote on this move @agunde @Dan @jsmitchell @kelly_ @amundson @TomBarnes

rbuysse (Tue, 03 Sep 2019 20:41:32 GMT):
Thanks!

MHBauer (Sat, 05 Oct 2019 02:08:55 GMT):
Has joined the channel.

pschwarz (Mon, 14 Oct 2019 18:23:27 GMT):
https://github.com/hyperledger/sawtooth-rfcs/pull/49 has moved into *final comment period*, to be moved (based on approvals) on 21 Oct 2019

pschwarz (Mon, 21 Oct 2019 15:13:31 GMT):
*Final comment period* for Sawtooth RFC #49 has ended. https://github.com/hyperledger/sawtooth-rfcs/pull/49#issuecomment-544561089

pschwarz (Mon, 21 Oct 2019 15:14:09 GMT):
I have proposed that the RFC be merged. The root team must vote on this.

danintel (Mon, 28 Oct 2019 15:57:31 GMT):
Has left the channel.

tuckerg (Tue, 29 Oct 2019 08:37:43 GMT):
Has joined the channel.

Alwii (Wed, 30 Oct 2019 07:36:05 GMT):
Has joined the channel.

TomBarnes (Wed, 30 Oct 2019 22:14:40 GMT):
@pschwarz i've ticked my box

amundson (Wed, 29 Jan 2020 18:12:44 GMT):
there is a lot of HL backchannel discussions about GF, not sure there is a community forum for it, so if you are interested in those you should maybe ping HL staff

arsulegai (Wed, 29 Jan 2020 18:16:12 GMT):
@jamesbarry ^

jamesbarry (Wed, 29 Jan 2020 21:37:07 GMT):
@wkatsak and I are giving a talk https://hgf20.sched.com/event/ZdHX And we should be able to help talk about Sawtooth too.

wkatsak (Wed, 29 Jan 2020 21:37:07 GMT):
Has joined the channel.

amundson (Wed, 29 Jan 2020 22:40:30 GMT):
@jamesbarry cool, great topic, let me know if you need an help with content

jamesbarry (Wed, 29 Jan 2020 22:45:31 GMT):
@amundson thanks! I will zap you a pre-conference copy when we get nearer to that time for any comments/help. Will you be there? I am sure you might have some very relvant projects to discuss in combining functional modules to solve real business issues.

amundson (Wed, 29 Jan 2020 22:52:11 GMT):
I won't be there, but I'm happy to review and help with your presentation.

amundson (Wed, 29 Jan 2020 22:53:23 GMT):
we've taken the modules stuff a step further w/splinter too which telegraphs how I'm thinking of sawtooth 2

arsulegai (Thu, 30 Jan 2020 05:17:53 GMT):
@manju.ac and I will be presenting on sawtooth-sabre. We would need help as well :)

manju.ac (Thu, 30 Jan 2020 05:17:53 GMT):
Has joined the channel.

arsulegai (Thu, 30 Jan 2020 05:18:58 GMT):
Happy to sync up with you @jamesbarry & @wkatsak . I know one more person who's interested to speak about HL Sawtooth, joining from China. Don't know the HL RocketChat handler though.

Silona (Thu, 30 Jan 2020 20:31:04 GMT):
First i posted in the general Sawtooth channel about how projects can participate here https://wiki.hyperledger.org/display/HGF/Hyperledger+Global+Forum and then I spoke with @arsulegai and @mfford individually about signing up.

Silona (Thu, 30 Jan 2020 20:40:06 GMT):
https://chat.hyperledger.org/channel/hgf created

arsulegai (Fri, 31 Jan 2020 00:11:06 GMT):
Thank you Silona! We shall coordinate and make it good

Tomomi.Yamano (Mon, 03 Feb 2020 04:51:38 GMT):
Has joined the channel.

Tomomi.Yamano (Mon, 03 Feb 2020 05:01:02 GMT):
@arsulegai you are going to be at the global forum in Mar?

arsulegai (Mon, 03 Feb 2020 05:58:59 GMT):
Yes

Tomomi.Yamano (Mon, 03 Feb 2020 10:07:42 GMT):
:raised_hands:

Tomomi.Yamano (Mon, 03 Feb 2020 10:07:42 GMT):
for saw-tooth ?:raised_hands:

Tomomi.Yamano (Mon, 03 Feb 2020 10:07:42 GMT):
for sawtooth ?:raised_hands:

arsulegai (Mon, 03 Feb 2020 10:14:07 GMT):
:grinning: Yes

Tomomi.Yamano (Tue, 04 Feb 2020 09:34:45 GMT):
:woo:

Tomomi.Yamano (Tue, 04 Feb 2020 09:34:45 GMT):
cool :woo:

gandhikim (Thu, 06 Feb 2020 01:27:21 GMT):
Has joined the channel.

Dan (Tue, 11 Feb 2020 16:57:24 GMT):
I pinged the next directory sub-project last week and am awaiting response. Based on inactivity we need to start thinking about archiving that repo.

amundson (Tue, 11 Feb 2020 17:51:19 GMT):
I agree, it should be considered. Would be nice to get confirmation from someone from T-Mobile, but looks like the last activity on the upstream repo at T-Mobile is September so might not be active upstream anymore either.

amundson (Tue, 11 Feb 2020 17:51:48 GMT):
(also, it's an example app, not a sub-project, fwiw)

Dan (Mon, 24 Feb 2020 18:06:27 GMT):
I heard from Chris S. that he is cool with archiving the repo. I would like to force merge this PR that removes binaries causing licensing false positives and then archive the repo: https://github.com/hyperledger/sawtooth-next-directory/pull/1442 Any objections?

amundson (Mon, 24 Feb 2020 19:03:56 GMT):
sounds fine to me

amundson (Mon, 24 Feb 2020 19:10:00 GMT):
We could consider reducing the number of channels we have on RocketChat, maybe get rid of these:

amundson (Mon, 24 Feb 2020 19:10:08 GMT):
```#sawtooth-announce (we use #sawtooth-release instead) #sawtooth-infra (lack of traffic, topic can go on #sawtooth-core-dev) #sawtooth-outreach (lack of traffice, topic can go on #sawtooth-governance) #sawtooth-pr-review (discussions are better for #sawtooth-core-dev) #sawtooth-seth (questions without answers, we should redirect to #sawtooth) #sawtooth-sabre (active but overlaps with #sawtooth and #sawtooth-core-dev) #sawtooth-supply-chain (primarily moved to #grid) #sawtooth-next-dev, #sawtooth-next-directory (archived) ```

amundson (Mon, 24 Feb 2020 19:10:08 GMT):
```#sawtooth-announce (we use #sawtooth-release instead) #sawtooth-infra (lack of traffic, topic can go on #sawtooth-core-dev) #sawtooth-outreach (lack of traffic, topic can go on #sawtooth-governance) #sawtooth-pr-review (discussions are better for #sawtooth-core-dev) #sawtooth-seth (questions without answers, we should redirect to #sawtooth) #sawtooth-sabre (active but overlaps with #sawtooth and #sawtooth-core-dev) #sawtooth-supply-chain (primarily moved to #grid) #sawtooth-next-dev, #sawtooth-next-directory (archived) ```

Dan (Mon, 24 Feb 2020 19:29:58 GMT):
I'm going to create #sawtooth-chat-administration so we can discuss this over there. Except for the parts that we should discuss in #sawtooth-channel-naming

Dan (Mon, 24 Feb 2020 19:29:58 GMT):
I'm going to create #sawtooth-chat-administration so we can discuss this over there. Except for the parts that we should discussin #sawtooth-channel-naming

gokulalex (Fri, 20 Mar 2020 12:05:45 GMT):
Has joined the channel.

MHBauer (Thu, 16 Apr 2020 21:19:19 GMT):
Has left the channel.

DavidSetyanugraha (Tue, 05 May 2020 03:40:10 GMT):
Has joined the channel.

jmbarry (Mon, 18 May 2020 15:00:05 GMT):
Has joined the channel.

HichamTAHIRI (Sun, 14 Jun 2020 15:52:47 GMT):
Has joined the channel.

amundson (Tue, 11 Aug 2020 17:42:57 GMT):
As we discussed in the last sawtooth meeting, I'd like to move to using github issues for Sawtooth

infrared (Thu, 10 Sep 2020 17:46:16 GMT):
Has joined the channel.

Dan (Fri, 08 Jan 2021 19:57:01 GMT):
I'd like to archive raft. It's not really maintained and I don't think any of us have an interest in it for future sawtooth versions. Any opinions on the right way to mothball that piece?

amundson (Mon, 11 Jan 2021 18:13:27 GMT):
I'd still like to mothball it after we've moved the code into the upcoming consensus library, though the version of the raft library is aging there so whether its actually a good starting point is in question.

Dan (Mon, 11 Jan 2021 19:53:08 GMT):
It's broken right now so I think if someone is willing to volunteer to fix it then it makes sense to mothball it later. But if no one can volunteer to fix it now then I think that's a sign we should close it sooner.

amundson (Tue, 12 Jan 2021 18:09:59 GMT):
you mean in terms of addressing build lint?

amundson (Tue, 12 Jan 2021 18:11:58 GMT):
I guess I'm fine with it as long as the website gets updated to reflect or remove it

Dan (Wed, 13 Jan 2021 19:10:06 GMT):
I think it's the liveness test more than lint that's broken

rjones (Wed, 23 Mar 2022 17:35:57 GMT):