 and can move along. Okie-dokie. Now I lost my place. Okie-dokie. So we have released taxonomy discussion followed by review and final approval hopefully of Bawa's proposal for a Hyperledger PY Python SDK. Then Todd will go over the hackfest preparations. Brian and Todd will talk about the wiki and hopefully everybody's had a chance to play with it or at least take a look and get familiar. And then there's another update on communication tools from Brian. And then we'll have workgroup updates. I'd like to add one more thing, Todd, at the end of the, or I guess between action items and workgroup updates. And that is just a reminder about the, and an update around the collaboration around the blockchain explorer. That's it. Unless anybody has any other items I'd like to add. Ok. So first up is the release taxonomy. And I was just going through noticing and get a chance to that there was a bunch of comments. So for those of you, and I think everybody who's commented is on. So maybe we should just go through them and review. Is everybody ok with that? I'll go with it. Yes, then. Ok. So the first one was from Dan sent in just two seconds ago. Assuming these are optional and not required. The tags? Yes. Alright. So the first thing is I think we discussed last week on Slack there was some discussion about using developer preview or not as a tag. And I'm a little bit torn. I think you probably need something to indicate the status. I wouldn't want to just a naked release out there and somebody thinking that it's real or you know not in some sort of a pre-release state even though it may have been released. Not pretty sort of a pre-general availability kind of a state. I'd just like to get other people's thoughts on that. We could maybe shorten it to be dev-prev or something. But I think yeah I think that the thing that had come up and I don't remember the details unfortunately was some of the tooling. There's some obstacle to including freeform text like that rather than just using numeric values. Right. I think it was something to do with dashes. I haven't seen anything and like I said I did a bunch of research on other projects and they all seem to be using hyphenated appendages. I mean I'm willing to say that this is a general set of guidelines that we should follow. I don't know if we and Brian I don't know what you think but I'm not necessarily wedded to that I'll shout absolutely positively because if we may have a project join that doesn't do this and I wouldn't want to be in a situation where we're trying to make them change how they how they do their stuff but this is a set of as they would say in the Pirates of the Caribbean these are a set of guidelines right that we can follow. I think it's somewhere between strongly encouraged and required for me. You know I think it's about consistent communication about making sure that somebody familiar with one project can easily go to the next. I think if there was a project that was resistant then we should probably talk about you know evolving the tech economy but somewhere around strongly encouraged for me. Okay yeah and I think the intent is that the numeric means are still consistent across the projects and assuming that there's a way around whatever the technical limitations were on dashes or alpha characters then there's no there's no substantive disagreement from the Sawtooth project. So should I change this to say something like strongly encouraged to use the following tags? Brian? I don't know exactly the wording but I think it has to be along the lines of this is what you should use unless you have a really good reason not to. So something along the line or should is I think what we are looking for. Except that we're avoiding the all caps yelling. Okay I changed it to is also strongly encouraged that projects should use the following tags as permitted by December. Yeah and then projects that fall behind are left behind unless you just really wanted to get away from your pirates of the Caribbean reference. Yeah good one okay next one was from Hart, why six? I agree it should be seven and I miscounted. Okay so I changed that and then the next one was from Brian who says it's the Shaw 256 and just check it says it's the Shaw one hash. Oh okay I'm going to pick Shaw one. Yeah okay next up was Greg just using snapshot, which is both a common well understood nomenclature. Okay reading that again Chris I think there's a higher level discussion which is you know what is what is this thing that we're tagging because there's releases and then there's this like state of the tree or a nightly build kind of thing and I I always look at it from the perspective of the only thing that's a release is something that has a first-class simver tag that a release engineer or whoever's in charge of you know bumping that set out there and that's the only you know release and anything else is a nightly build kind of thing so I guess that's the first thing we should resolve is are you are you going for the more formal release kind of thing which might include the you know the Shaw or is this more the nightly build scenario. So I'm thinking and I've been sort of thinking also about that just the whole process for doing releases but I'm thinking that we would have you know periodic releases some of which we would consider to be stable and suitable for public consumption that may not be a formal release right but you know we this is the product of a given sprint or what have you and that you know those may those may be interspersed with periodic unstable builds that people you know I mean a lot of projects tend to put out even the unstable build for some people to be able to pull down and play with but that we should between what's stable and what's unstable. I think that separation is definitely important and should be captured the only concern I would have about anything that's construed as a somewhat formal release even if it's an intermediate is that the Shaw stuff doesn't play well with that in terms of you know versioning packaging systems and whatnot so that would be my only concern there. You know the set December tag plays perfectly with it but when you start throwing git hashes in there that they have no you know evaluate which one's newer. That's a true. Okay we could we could omit that then I don't have a problem with that. It's just that even for our own internal testing and so forth we probably want to have a really clear idea about which build we're dealing with. Well I think at the very least you know if there is that aspect like I said when I wrote that I was thinking the nightly build scenario and I think that the snapshot kind of thing makes a lot of sense for the nightly build scenario so I you know maybe that's captured as a second sub-clause of that different paragraph to what you were just talking about there but in terms of these intermediate releases you know it just decided I think it makes sense but in my mind you know you know why mess around if it's a new release make it 06-1 or 06-2 whatever I guess it's kind of hard because I know what you're going for like you're saying well there's there might be some merit and some thing more formal than the nightly build but it's not quite an 06-1 is there a way to capture that you know. That's right I'm going for something in between a release right. So I wonder I wonder you know would it be better to be like 06-0-1 as opposed to 06-0 with a shy you know that that kind of thing or is that still too formal. I think that's still too formal and I mean I guess we like an 06-1 and then latest I don't know I was going for something that's like it's it's you know it's in a branch it's still evolving but we do want some people to pull it and test it and then we need to be able to sort of clearly make an association back to exactly which one they're talking about right if they're multiple to these things. For what it's worth I mean I've seen this kind of thing in other other systems like Maven coordinates and they use this snapshot for that. So that just designates that it's a moving target that represents some state of the tree that's in in queue to be whatever the first level. So we would do this it wouldn't necessarily be published. Certainly not to any you know Docker hubs or anything like that but we may have it you know available for people to just sort of pull. And just to be clear you could push those a darker hub if you want to do it just it's just going to. We could. It would be compatible. I could go with snapshot I could I could I could do that. Okay so for subsequent builds then subsequent I would say for subsequent releases of a tag release obviously we go from 06 to 06-1 but for interim builds we'll go with snapshot. Does that make sense? I'll fix that up later. Chris I had a quick follow question about that. Yeah I assume it's obvious or explicit but somebody's always going to be able to grab this tag and recreate the builds straight straight from the versioning system right. So we're telling somewhere we're saying this is actually going to be used as one of the tags you can use to extract. I think it would be something that's a product of a build and Greg correct me if you think otherwise but so that if somebody did a local build for a particular for a particular commit level it would be reflected. We did talk about whether and then we also talked about doing something so that if you're doing a local build indicating whether or not there's any uncommitted changes although that could be trickier. Jeremy I think to your point you were getting at if I did a local build of a given commit level it would produce the same tagged version as if we were to do that out of a you know out of our Jenkins build. Is that right? Yeah essentially my question is if somebody sees this tag set can they recreate the build because it's a the assumption here is not just that we need to use this to communicate some sort of understanding of the state of this thing but also that we can it's how easy it is to reproduce. So my thoughts there that for formal releases that's you know absolutely positively has to be nailed down to a concrete rough spec you know so 06 developer preview is going to be a tag and that's reproducible and then from the perspective of the nightly builds it can go either way most systems I've seen tend to just say snapshot and it's kind of like it's the latest of of the development for the projective release you know projected next release and you can't necessarily pin it from the version number to a specific commit I think we've gone one step further and said okay well we are going to attach a shot a shot to that so that we can correlate it to a specific commit if we want to at least within reason as Chris pointed out we you know we would need an extra level of detail if this was you know truly the commit level or if you had local changes which we don't currently capture in the in the fabric side so it's a question of how important it is most subsystems I've dealt with don't seem to care too much it's supposed to be an ephemeral snapshot but we can do better than that if we think that's important. Well I was just thinking in terms of if if somebody pulls down a build they find that they think it's a bug they post something on the slack of the emails it could be that we just asked them to recreate it with the most recent one or somebody is trying to help to go and pull it if they have it if they have if they knew say the snapshot number right and that's and that's where the shot comes in right so that if we if we add an additional component of those to the tag which includes the shot we at least have some semblance of hope of figuring out where it came from and I think that's pretty cheap to add the only extra level of complexity is you know whether it's truly that commit level or had local changes and even that's not that hard I just I couldn't get to work in a short time frame so I gave up but I think it's achievable and not you know obviously if they if they're build indicates they had local changes we can't necessarily say well these are the changes you had but we can at least know that it wasn't you know what the shy applies exactly and that's probably good enough right okay all right so I'll clean that part of it up should be an N for RC and not sure where this goes oh I see add one yes okay I agree with that our no had the next one I find the unclosed state terminology clunky open state okay I'm okay with that that's obviously minor editorial stuff yeah Jeremy is throughput latency performance at risk we want to characterize I don't know what I want to reopen the the prior risk risk management discussion but that was just the where that question was coming from just a question of what what expectations are we managing towards right this implied this this as written currently written would suggest performance as opposed to say hard suggestion around the security flaws and the I guess the question is the risk to whom is it the risk to the reputation of the project or is it a risk to those who use the release because those are two different groups I think I think it's probably I mean I think from from a nomenclature perspective you know maybe we can omit this but I do think you know to your point Jeremy that we probably do want to make sure that there's clear set of published expectations that one might have from an alpha right I mean we may want to publish it and it may be slow as molasses but it does everything that we claim it to do and we understand what the problem is and we're going to fix it in the beta kind of the same right and so we might go out and just set the expectations that well this will only achieve 500 a second or whatever throughput we understand what the problem is and we're gonna address that in subsequent releases but this is suitable for testing I think as long as we are clear on setting expectations when we do a release that we will be covered but I mean again I wouldn't want to necessarily say well we can't put an alpha out because it's slow I don't want to just sort of make it would be too dictatorial here I understand where you're coming from I think it's important that we set that expectation I'm just wondering if it's worthwhile putting in here from a no one closure perspective as predetermining the expectations for what costs would constitute an alpha Chris just the is there a reason why you're specifically pulling performance out here as opposed to I mean performance security and did there's a bunch of sort of minimal criteria that have been discussed in different forums about that's right and so this is Jeremy's is not mine you know we had that that conversation yeah a couple of weeks ago that we beat that one to death I thought we did but I again I don't know Jeremy do you think that is there a reason to the performance would you know if we started enumerating all these things and I think we get back into the whole characterization of what can be released and so forth right right exactly and so I think the easiest thing to do would be to say it needs the you know it's been it is how well we think it's been tested against the requirements that have been enumerated whatever those may be functional non-functional because I think what you're just implying is just yeah it's just how much confidence or process has gone into it so the easiest thing to do is just to say how something defective how much we think it's how closely we think it's to doing what it's as you said we say it's doing how about if we just change this to say so the PSEs can be done within the bounds of established published a rather expectations perfect sounds good doki think aside from resolving oops I clicked the wrong one Jeremy oh I kept the other good one so I think there's just that one bit that I need to noodle on in terms of the the snapshot release so I'll do that and what we can do is I'll just circulate this and we can do an email agreement okay don't next up is the oh and feel free to any typos obviously okay thank you everyone next up is the hyperledger pie SDK for the fabric how can you ping the link to that in the yeah one sec thanks I really I always want to go click a little viewer it doesn't do anything that why are you on yes I'm awesome okay so hopefully people have had a chance to have a look review and comment see a couple from Raleigh Peter and by well it looks like you've addressed the two no one of them anyway so what do people think this ready for approval people want more time to review any concerns I think one of the things that we had asked about what to do is to go back and see what additional support he could garner to help and sort of to augment from a development perspective to get additional people to commit to to helping with the development I don't know about did you get a chance to get any feedback on that yes actually I got several feedbacks and I also ask people send me the series their rhythm and after checking I select those four people to also from IBM and the other two one is from nice skill and another one from the John University with the students I guess all these four people are very exciting to support this project okay and and in terms of how the project proceeds my understanding is this is sort of being is going to then follow the there's a guess between the Python the Java the node and I think a go proposal sort of in the wings where everybody's collaborating on a sort of a specification for the for the SDK and so I'm I trust that the intention here is that if we start this project that it'll follow whatever we all collectively agree to as the sort of the framework for the SDK hey hey Chris this is Morali from DTC so just want to clarify so the restful even though the initial version of the Python SDK is will have some restful API invocations but later on will be replaced by GRPC is that the the thought process there it's gonna have to because the rest APIs are eventually going away so okay yeah yeah so that that's the intention Morali Mao I believe that you are also part of that SDK working group right I mean it's not a formal working group a number of folks get together led by folks from DTC see Morali and you know so I guess this this would be one of the implementation then Chris that's that yeah that's what I was trying to get clarify on clarity on rather yeah okay so I think we should de-emphasize the rest support here and you know start looking to to 1.0 instead and focus more on GRPC what what why don't we do this so bella I mean I assume because you are part of that informal working group can you just update this to reflect that the Python SDK will follow the you know whatever we collectively agree to is the specification for the SDKs as opposed to specifics about rest or GRPC we just sort of say that that you know this this this SDK will follow the the guidance from the the SDK working group let's just call it for that for lack of a better term yes actually the initial implementation of the project is based on the rest for it while if you if you look at the project code now you can find there are several branch named the reservoir one and also the GRPC one so respectfully they will implement on different ways while the community now more and more people think GRPC one more practical so maybe we can put more effort to the GRPC implementation okay but what all I was really asking is in the proposal itself just to replace the discussion of rest or GRPC and just say that you will follow the approach agreed to by the SDK working group yeah yeah yeah yeah okay that's all I'm asking and so so you have sound like four or five people interested in contributing that's good and it's a diverse community that's a good thing and so I I guess we could put it to a vote Todd you want to run a roll yeah there was just one chat from Dan Middleton that said the only remaining comment was around the project naming I don't know if we we tackled that yeah I'm definitely think we should make it you know fabric PY either the PY hello fabric client PY maybe I'm in Raleigh so I think Chris got pulled away forgot to go in here by any objection fabric client PY okay all right some moderator can you Chris yeah it looks like by why you suggested fabric SDK API is that better or worse than fabric client PY I'm not sure fabric KPY them good to me so are we going with API or SDK I think we should stick to SDK okay looks like Dan and Greg are also plus one on fabric SDK PY comments in the dog I don't know if Chris has returned yet or not sorry I I'd take a call and I just needed I'm back discussing the name at the top oh I see yeah changing that fabric SDK PY that sounds good to me Chris I don't know if you have actual editing on the talk I think I'm suggesting to okay yeah okay okay somebody I have to go through and edit the other references but I had to drop off for a second there but are we all good I couldn't I didn't get the results we didn't vote oh we didn't vote okay I'm sorry I thought a bunch of us already voted in the chat yeah so I can walk through really quickly now I think we still have forum even though Dan dropped so I'll just do a quick quick run through so Arno yes okay Ben yes Chris yep Greg yep part Jeff Mick yeah Morali yes Tamash so that passes unanimously okay I'll have Roy set up a project and and I'll I'll ping you Boa with where you can pour it into okay next up is you've hackfest yep just really quick update for that the hackfest is confirmed it's in Amsterdam October 3rd and 4th we do have a registration page now live so if you're planning to attend that please register as soon as possible I'll send the link out again with the minutes that'll go out later today in addition though there will also be a hackathon that weekend October 1st and 2nd also in Amsterdam slightly different location and as soon as that registration page is live we'll certainly share it out with the community could we also have a wiki page that folks could tear up some big agenda items yeah we can do we do have a wiki that's up next for discussion right yeah I think in the past we've done a Google doc that people can dump information into for agenda planning is that what you're talking about been yeah yeah something like that yes okay I will get one created and send a link out with the minutes as well cool okay next up so annoying well here we go if the wiki the wiki my discussion yeah right yeah so this is Brian you know we stood up a test wiki on Thursday it may have been the end of summer labor day things for for many of us but I know I didn't get a chance to work with it as much as I would have liked and we had a few you know a few people touching it but I would suggest we try to take another week to give folks on the TFC and elsewhere a chance to get their hands dirty with it before we commit but I haven't heard any complaints so far except for him sorry Jeremy you did you did have a negative experience trying to copy some content over well I wouldn't characterize it as a complaint it's just an observation it's not cut it's not cut the past it's pretty well the whining I didn't pretty see pretty simple but I I moved over one of the complex wiki pages and documented what I had to change to get it to work and that's presumably going to be that because it's more one of the more complicated one presumably everything else would be easier down and just as an observation I did a gift dump of the existing hyper ledger hyper ledger repo wiki supposed to say the fabric wiki and there are probably 110 pages some of which we can move some of which we can just leave might make sense to leave behind so this is this is Greg I I don't have a strong opinion about this this is just my comments I tried bringing a page over yesterday just for the experience playing with it and I wasn't overly blown away although I you know still haven't really given it a fair chance to understand the different nuance of the interface and whatnot but I guess what I was curious of is my experience was similar I I dumped the original give help wiki and and tried to port a page over and then I basically had to rework almost all the syntax it wasn't compatible so I'm just kind of curious like what why did we choose this one was there something where others evaluated and we picked this one for a certain reason or is it just we picked one randomly because maybe there's one that's more compatible with the github markdown than what we have currently yeah this is so there's a set of wikis that the Linux Foundation IT department is willing to support it was this and I believe it was told at one point that that confidence was supported but then it was suggested that instead of conflicted by the Linux Foundation IT department that we go to docu a key instead and that's been a little opaque to me now there is a markdown module that installed on this and I don't know how to invoke it I don't know if it's like a set of tags that you use at the beginning or at the end of the stretch of content that you paste into the the edit window but there is some documentation available for that when I was looking at it before so I don't know if people would have a chance to look at that let's see if I can dive into into this and find it were you were you reworking mark markdown into the docu wiki markup language or were you cutting and pasting the markdown as is and needed to just rework the markdown so I dumped the github to you know I exported the git tree whatever that mechanism is that github has and I copied the raw markdown over and then I had the port you know from the hash hash to the equal equal kind of headings and things like that you know like I said I don't have a strong opinion it just was not as smooth as I would have liked that I couldn't I still don't know how to do things like the you know in the github markdown like you know back tick back tick back tick gives you the you know the raw like kind of text output and that wasn't compatible with docu wiki so I have to go figure out what the syntax is to mark that as raw text and things like that it seemed it like in the past I've played with things like T wiki and confluence even and they seemed a little bit more natural to me to figure out from just using the interface for two minutes than this did but like I said that's not really a fair evaluation because I only looked at it for a minute but it did seem to be at least in the form that I was using it a little bit of work to go from the old format to the new but maybe there's that module you mentioned that could make that easier let me get let me try to find the link for the markdown documentation the if you go to the wiki page that I migrated I put links to the syntax for each and I think I'll post the page that I ported the original in the one I implemented as well it is a pretty complex page though and it does look pretty nice but I mean that's this I mean I'll definitely say this this is better than github wiki so it you know this has a real this has a table editor this has a better navigation mechanism so this is in this end this is definitely an improvement in that way but like I don't know if it has for example emacs plug-in some other things the other thing I was going to say is just in terms of 110 things to move a lot of those are just meeting minutes coming that are essentially cut and pasted from Google Docs so those should be either really easy to move or depending on what the the policy is with me minutes might not need to move them at all yeah yeah thanks for starting up spreadsheet I think that'll be key when we start moving some content over I feel like there's probably still some hesitancy to committing to the do we do we want to take another week to play with it it's probably good so it sounds like the only choices really we really have without you know asking for some other support not currently not supported thing is is docu wiki and confluence is that right or is there any other options those are the two options I have that are support oh Todd is media wiki available from yeah I believe that was the other one that they would support I don't have any experience with that so I can't come I mean like I said Mike I don't have a strong opinion I guess playing with it for another week it seems prudent but I'm sure it's fine we just need to adapt to the new markup style and if there's an importer function that we can help with the existing pages that would be awesome yeah so I just copied over a URL for a plug-in that we do have installed the mark the php markdown extra plug-in and it says if you use you know a markdown tag and then a flash markdown tag at the end the stuff in between those two will be parsed as markdown rather than the docu wiki format so I don't know if you've seen that when you're starting your your migration cool I'll take a look okay all right I would suggest then Brian to your to your point that we take another week and do a little bit more exploration and and I don't think media wiki has a mark markdown support I think we gravitated towards the specifically for markdown support media wiki is very sophisticated so that's used to support the wikipedia so that's an option people want to consider you know I just want to get us through this let's take another week and then the last topic is communication tools the second last time right Todd you want to talk about yeah just really quickly as of early this morning we do have our discourse instance up that we can poke around with it is a trial version for several weeks and we can decide if we want to move forward with that we just need to go in and do a little bit of configuring and then we will send the link out to everyone so they can kick the tires of that and we can regroup next week on any learnings or questions comments concerns with that evaluate just as we are with the docu wiki right now okay sounds good and and on a potential replacement for slack there's a tool called rocket chat somewhat claimed to be a slack clone it's open source it's also something that like now we would probably use as a hosted tool but I'm putting a link to a demo to it it's something people want to also check out and give an opinion on that would be good and it's something we'd have to look at you know can we integrate it with the Linux foundation ID can we make sure that we can deploy it in a way that's accessible from China because for me that's one the two main things that I'd like to get from a slack replacement are a getting past the 10,000 message limit and be being able to be accessed from China which slack is not and so rocket chat is an open source call is appealing from both those perspectives if they actually need it actually running into the hosted environment we have to deal with the business terms on that are but if we like the UI we can make the case the Linux foundation ID that they support it and that's the other okay so just to be sure I'm clear so we would play around with this hosted version but if we like it then basically we're going to look to see if the LFIT staff can host it so that we don't have an archiving issue right so yeah the first step should be evaluate the functionality if we like it then we will see if Linux foundation ID will support it if not or not on the time frame that we like then we look at running it in a hosted environment and rocket chat does have a host you know the company that makes the open source product also does you know provide a host platform for it so we can look at the business terms around that and if they're not as on or if it's black then we can run it then we can look at I mean it has to be a decision on the side of it yeah if those business terms are too on earth then we have to look at other options but I'll work on the different issue as long as others can look at the tool and yeah and if they think that'd be great thanks so it sounds like people need to get out there and oh it's kind of cool little okay don't go to that site because oh my god then you'll just be playing around with the little dots all day that's exactly what I was doing because I was talking to you I just noticed that you could you could play with them yeah okay the next topic then is thanks Brian the next topic is I just wanted to sort of do a reminder to people so we have the blockchain explorer project up and I think we added three maintainers and I think was one each from Intel IBM and DTCC but we also put the two plus two rule on there and and so we've had some commits you know some chainsets submitted and none of them have ever landed and been reviewed and merged so I just what I did was I asked for I this morning to reduce it to non-author core review and which means only one of the maintainers needs to review and approve to get it merged obviously we want to grow that project and grow the set of maintainers for that project over time but I had to make that change because otherwise I just suspect that we'll be sitting around waiting forever to get code merged rather than actually starting to make some progress so hopefully is a temporary thing but I would just remind all three and anybody actually you know to to not neglect the baby that we're creating in between the sawtooth lake and the hyperledger fabric projects and so this really just you know a public service announcement you will to to make sure that we're all paying attention and helping to get the thing off the ground so okay next up is work group reviews and the first one is requirements hi good morning okay here well I've been working on the derivatives use cases pretty much closing up will be financial use cases that we have I started the discussion section and the requirements document as to privacy so that's that's where we are pretty much I'm rallying the group to start writing the main document and the progress there has been a little slow hopefully I'll get someone to help me with supply chain use cases and use cases that are not my primary expertise otherwise I'm handling most of the financial use cases and tackling privacy and confidential transactions okay hopefully I think you know summer is over and everybody's back to school and back to work and hopefully the the summer doldrums are over and we can start seeing a lot more collaborative contribution but thank you very much I hope so thank you next up is Rom got a note from Rom he's out this week no significant updates to report and he will report in on progress next TSE meeting okay next up is Dave hi yes thanks yes the working group white paper working group met yesterday and key thing that we discussed was the walk through of the white paper again our you know our goal is to be able to move out of remove the draft labeling I'm for the segos event which is at the end of this month so we wanted to be able to have the walk through get everyone give everyone the opportunity to provide their feedback and put before we do that before we remove the draft labeling so we we all agreed that where we will be available a week from yesterday so next Wednesday at 1 p.m. so that was sort of the same time that we originally were planning I guess the the virtual hackfest before but we're reached out to Todd hopefully you can help us with the web conferencing and and also you know one of the things that we want to make sure those we get good attendance and you know best way to get the word out that this event's going to happen and and so that that was a key thing so we're aiming to have the white paper walk through next Wednesday you know similar to the same format we were doing our meetings here and that was a key thing I think that's it I'll get a I'll get a WebEx created for that shortly after this call if anyone is interested in joining that wants to get added directly to the WebEx please just shoot me a note or a chat and then go to meeting yeah I hope I can do it but I'm not positive that I will I'm doing some sort of a talk in Atlanta and I just don't know what time I'm done this is one o'clock Eastern one o'clock Eastern but you know I mean if I'm just sort of thinking a lot I should have we should have probably discussed but maybe it might be a good idea to put out a little poll to see how many people we could actually get on that date and if and if there's a an alternate date it's just that we want to get this done you know in time that we can get the feedback get the edits and review them prior to this CBO so yeah actually I asking for some feedback here do you think we should just go ahead and schedule this for 1 p.m. next week or should we do a poll to find out what would be most convenient for everyone I think you should go ahead with as many as we can get if it's really lightly attended then maybe we should try and find another time you know the other alternative I suppose would be we have an hour and a half next week on Thursday and we could take maybe an hour and try and get that you use that time for that purpose well so why don't we why don't we go ahead and yeah yeah so so we could have we could just schedule it for next Wednesday we'll do it and if attendance is particularly light then we can either you know depending on the agenda for next week's working to see meeting we could either cover some of it there or schedule a follow-up you know a day or two later for people that were unable to attend sounds good let's talk let's let's do that let's put an hour on the agenda for next week regardless okay sounds good okay all right next up is Christopher all day maybe okay and then lastly it's CI and that's me last week I promised that the build but they're not I think we're still a little bit I don't know I think it's getting better but we still have a little bit of flakiness and especially in some of the behave tests and the fabric side and I'm not actually sure you know we probably are going to CI and only run them periodically because it's really annoying to have to constantly re-verify because we have indeterminate test results I don't know great to be a Webex had a hiccup on the audio channel sorry about that sorry so what was the question again well I was saying that the behave tests are still really annoyingly flaky oh yeah and in the fabric and I mean it's almost to the point where it's so annoying that we should maybe just remove them until they can be stabilized yeah I definitely can appreciate the sentiment obviously the downside to it is removing it means they'll be even let's like wash out the issue but I mean when it's at the point that you can't make forward progress it probably needs to have some kind of alternate thing so when I wonder if I wonder if there's anything we can do in terms of like having you know I don't know how the hyperledger the Linux Foundation's Jenkins setup is but I know on Jenkins that I've run on my own projects it's generally fairly flexible in terms of you know the type and breadth of jobs you have so you could have even though even though we only have one fabric it you could have multiple jobs that do different things in response to changes to fabric it so would it be possible to have kind of like just one job that's looking at the unit test and another one that's looking at behave and at least the behave that the folks that are impacted by whatever's wrong with behave would still have that can that CI benefit but it wouldn't necessarily block the the Garrett notion of what's ready to go or something low in those lines I mean is the problem is the problem reproducible and local behavior or is it only happening in the Jenkins setup I've noticed I've noticed flakiness of some of the some of the tests right on both on Jenkins and and locally I mean same it seems locally because it's only you know like 10 minutes as opposed to a half an hour on Jenkins but I mean it seems it seems like if there's a test that's notoriously flaky that's reproducible on local you know maybe we should just remove that particular test from the mainstream suite if we're having general problems with behave specifically in Jenkins and not locally maybe that would be where we consider that that alternate job path to just so that we keep the you know the notion of whether it's working or not available to the people that need to fix it I don't know that's the only thing I could think of it I could definitely I could I could see it going that you know because in the alternative is just leave things the way they are and that motivates people to fix it but at the same time it's painful for everybody else it's not in that path to have their Garrett jobs get a minus one right then I used to lawn I mean is there something we can do to I mean I know Jeff is working pretty hard on this but it just it's it's really painful yeah I'm still on but I'm not sure what I guess some of us need to get together and look at the problems well some of them have been related to you know bad a bunch of images or yeah but but there's interspersed with that is a constant steady stream of failing behave tests that you read you know you rerun them and they run fine so yeah it needs some analysis and it needs some attention I think I know Jeff's on vacation this week but maybe we can yeah just disable them tip periodically and then get them back in as soon as possible so have you noticed that it's about timing or is that trying to get stuff I haven't done the deep analysis on the failures to understand other than it's always the same few tests that fail I haven't really done the analysis to see what's causing the failure other than if it's behave I usually rerun it and if it comes back with success that I know oops and so good so it just needs a little analysis to figure out which ones are bad maybe and to work on getting them stabilized it could be timing you know it and I don't know why Jenkins is so slow but like I said I can run the behave test on my laptop in about 10 minutes right and it takes a half an hour or more to run them on Jenkins so I don't know if it could be a performance thing but I have noticed that they fail locally as well so it's not just a Jenkins thing okay I guess so we take that up next week when Jeff is back okay in the meantime then in the meantime then I guess we should disable it yeah so I'll have Ramesh turn them off until we can have Jeff take a closer look yeah because it really is starting to slow things down okay I guess that's it any other items if not everybody gets about 15-20 minutes back and we'll talk to y'all next time thank you guys thanks