Jakarta EE TCK, 2 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TCK call #7

Description

February 2, 2022 Jakarta EE Platform TCK call #8.

Minutes can be viewed via https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#heading=h.5w3pxh56e9xx

A

This meeting is being recorded.

B

Okay and let me um oh let me um I will post there's amelia I'll I'll post the agenda link in the chat room before I share the slot. um The agenda screen good.

C

Morning, everyone good.

B

Morning, amelia, how are you.

C

Good happy 2022 to everyone, especially u.s cats and kids,.

B

Oh, thank you. Let's see: okay, hi dimitri um for those who just joined, I already started the recording I'm going to share my screen. Let's see.

B

Great okay, close that.

D

B

That's is that big enough, the um um the screen.

E

Looks good for me.

B

Great, that's awesome, okay, um so I don't know if anyone has items to add to the agenda, um I'm I'm trying to be more mindful of listening during these calls. um Yeah very typically, I'm a very quiet person. I tend to just talk a lot at these because I don't you know, talk much, you know typically, but uh I will try to you know to listen. I I um added um I mentioned um stack overflow issue, which guru had reported he's not here. Maybe we can skip that.

B

That's just an implementation issue, probably not um that important to handle during this call. But the second item, I added the pull request to create the new standalone faces, tck, and if that you know, if that is interest to discuss here, I wanted you know it. It seems relevant to.

B

To just mention that there's a pull request. um Sorry, let me back up a second. I I misspoke there. Okay, this pull request is to update the um um jakarta faces, tck test in the platform tck, um and currently we can't compile the uh the platform tck due to um the um the changes that have to be accounted for, and um so, if any, if anyone else wants to review that, oh, let me let guru in. Let me just do that.

B

Okay, great, um if anything, if anyone wants to um participate in the review of those changes that would be great sort of related to. That is what you know. What I had mentioned before is there's a new standalone faces. Tck that um brings about what's been discussed, a lot, which is you know. Now we have we're going to have duplicate test in the platform tck, and um that is yeah.

B

I I I did a different issue, which is you know that you know that we'll have to um um address, which is we'll have duplicate tests and let's look okay, let's see so that's you know, that's um something that will have to be um addressed.

B

uh Let's see, um like kind of I guess, I'm jumping ahead. The the fourth item talks about that. So, but let's just wait now: let's, let's just wait a minute, um the oh! I should listen, okay, any any feedback on either of these two issues: um the stack, overflow or updating the faces tests in the platform. Tck. Is there anything to discuss there.

F

Yeah uh hi scott: uh this is alvin here uh yeah, so uh for uh the face ck. I think there is a general plan to create a separate uh standalone, tck, uh so probably I'll ping. The uh issue uh link url here uh yeah. So I think all the issues related to the faces tck can come under probably under this section. So one is the pull request that you mentioned here.

F

That is one of the items that need to be addressed for faces: tck yeah. Another is the um yeah the assertion ids. That needs to be created for this new standalone tck, I'm gonna.

B

So yeah, I'm sorry the interrupt. I'm just gonna move um the third item down below just so that the two face. The two faces, related items are, you know, are kind of next to each other. Okay, yep yep. Sorry go, you know, keep going so assertions is right there in the next one, so yeah.

F

Right so uh regarding the pull request, I think, if someone who has some experience with the uh json for the faces api, I think if they can review or go through like uh that, would be helpful either from the tck team or uh we can check with the uh asus dev team. uh Probably I will email the uh team, the faces, dev team after this call to review it. uh That will be a start uh about to how to fix the faces source for the new version.

F

So there is also a plan to create this new standalone dck that will use this source from the jakarta idck and also uh uh at the sake that was created in the mahara repository. So uh so I think uh uh that also need to be uh addressed. I believe so.

F

uh Yeah fixing the tck tests in the jakarta itc case, I think, is just one of the items that we need to address.

F

We should also be assisting in uh creating this new standalone tck that will have tests from the other repositories.

F

um Yeah yeah. I just wanted to bring about yeah bringing up.

B

So you mentioned assertion ids and um we discussed assertion ids on the platform tck and it didn't seem to get a lot of attention from what I recall. um um But what yeah one one one question is: is you know, does the new faces tck um need um to to do insertion? You know to include assertion ids or could they just reference?

B

The javadoc and the you know, and you know and the you know the spec sections um with descriptives. You know you know it. You know with this. You know descriptive. You know you know description of what they're testing about that section. They can maybe the specs. You know section I'd. You know um your number and and all that, like I know, there's some tooling that we've used in the in the past. But do you like? Do your users really like for the new tcks? Do users need assertion ids or can?

B

Is it enough for them to have a description.

F

I I think uh aryan uh had uh listed this as one of the uh items that need to be addressed. So, regarding the assertions like we have two types of assertion: ids like one is spike assertions and another is the api or the javadoc assertion. So most of the tools that we have uh like for pa uh and for jack saras we had. uh We have had tools to generate javadoc assertions but for spec assertions. uh Historically, it looks like uh they were done manually.

F

I mean for a new uh requirement in the spec document, so probably uh for spec assertions. uh Somebody will have to go through the spec document and create new spec ids for that, uh but for the api yeah, who.

B

Who uses the spec ids? I mean sorry, sorry, the assertion ids, I mean sorry.

F

I'm not very sure, but I think historically we had this. uh Both the spec and uh api assertion documents in the pc case, um yeah.

D

So the assertions.

F

D

The assertions are there to provide traceability right so um in and- and I guess I'll say it's not adhered to in all um all specifications, but um this gives you a um you know this. This uh says: well, um somebody does a complete in an abstract fashion. Someone will do a complete um review of the spec and the um javadocs and they will like identify that's. This is where the magic is uh each uh testable of each assertion in the in the api.

D

Then someone decides, is this testable or not? And if it's testable, do we write a tcp? You know a compatibility test for it or not right.

D

um So generally, I think assertions are only used if someone's having trouble with tests they're trying to figure out. Where was this, you know what what's the source of this test and um you know do I have to do it. So, if someone's trying to lower the spec and wants to get, you know to form a challenge, that's what the assertions help you do.

B

Okay, it's definitely referenced in the in the current tck process, but that was I you know like for for challenges. I I would think that you could identify. um You know the test.

B

um Just you know just as well that's failing and include any description like the you know, test description and you know if the tests describe the spec. Basically, what I'm asking is. Would it be enough to you know for news, tck writers, to use the you know? You know to be descriptive about the spec section and what's being tested about that spec and in the same for apis you know: what's the field, what's the class? What's the method, you know you know um that's being tested like?

B

Is that or I wanted to see if we can get input on that, because I just haven't gotten much in in feedback before so? Would that be? Would that be worthwhile to replace assertion ids and then it would be easier and less processed to you know to generate the assertion ids. I think.

F

Okay, um all right, I think it would be up to the uh spec team also like what what they really want. uh Maybe we should uh also check with the faces team.

D

F

What their uh expectation would be.

F

At least for uh the faces tck.

B

B

So so possibly um we could. I I think, there's some this. There may be some. This more discussion may be needed, but so but possibly we could defer to spec.

B

Possibly defer to spec team to determine if they do if they use assertion, ids, oops, ids and pcgs. Okay, all right! I just wanted. I wanted feedback about that, because I wasn't quite sure if that was something that we should look at and it just. We happened to be in the moment of creating this and someone needs to create assertion ids for the faces tck. It's it's an action item but yeah. I wanted to understand.

B

You know if there's alternatives. So that's so that's a you know.

D

That's a good thing, so you know what what you're describing is. You know it is uh you're you're you're, creating an identifier. That's going to you know, validate an assertion. These searches are realized in the test right and um you know how that happens. It is you know it is kind of ad hoc right now and you know many of the lists of assertions you know are kind of we carry them forward, um but I I don't think they're maintained, particularly well.

D

Okay, I know I I, for example, I don't think many of them have been added.

D

Many new assertions have been added um from the specification documents. New insertions may have been called out of the um job knocks.

B

Okay yeah. I know there was a a recent persistence test change to add a test and in that pull request they ran the tooling and um um I think what I think was jam. Jan spool.

B

Okay, um um that um did you know but, and it covered like they were like it. It added um miss. You know missing, missing assertion, ids for other tests that seem to be, you know covered, which was you know great, but um okay, it just seemed heavy weight and I wasn't sure if we needed to do it, so I wanted to get feedback. So that's good. We should probably go on, though I think.

E

um One question to the assertion: ids: these are unique ids over all tcks or unique for one spec tck.

B

um Let's see basically.

D

They include a spec identifier, so they're unique across all.

E

D

But there yeah it's supposed to provide traceability, so you know I don't know how um how fully imported they are. It's more of a concept than anything else to me.

B

As a long time as a long time, you know user of of tcks, you know, or you know, someone who's run tcks a lot and reported many challenges.

B

Yeah, I uh yeah, I always found it enough to have the t you know to have the information about the test, that's failing from the point of view of reporting what field and the jtr file, and also the javadoc and the um spec reference. Like you know, all I did with the assertion. Id was look up in the other file that had a list of what spec section I should look at and if I just had the spec section or the java doc coordinates directly. I would I would have been perfectly happy with that.

B

It would have saved me as a user. From the extra step of following a pointer to some of the file. I had to find and um so kind of slowed me down. You know it, it could slow. You know slow users down, but um I think.

G

B

It may have served another purpose too. Maybe spec these, like the section ids weren't known early on, or you know, maybe like if they changed. If you had the indirection, maybe that helped you know like if you read back like if you re, if you're moving dots, you know spec doc around like for new sections, you know and changing you know, like section ids, a lot you know, um or you know, if that could happen, then you know maybe they they helped with that.

D

So long ago you know, like I said, the uh a complete list of assertions will be created. Then a decision will be made. Is this testable and then another decision would be made? Do we write a test for it right and as part of the go, no go decision for the specification we would evaluate.

D

Have enough of the um testable assertions been been tested or are there you know, and that was that was represented as a code coverage number right, and so we had we had marks. You know we.

G

D

You know we would evaluate that and say you know you need to write more tests because there's not enough code covered here. It's not and that's a different kind of cloud coverage than what was what is traditionally, you know used by some. You know: mapping the actual execution path.

D

So so assertions had other uses. I you know we don't. Okay adhere to those at this point.

B

Okay, thank you for adding the you know the actual historical. I was just guessing on what I had said it. It seemed like a like a possible function of it, but I never really it.

D

Is it does provide trade? It is a traceability uh element. Yes, it just has. There are other aspects, you know you know this is or these are all you know turn of the century. um uh You know um our our uh ideas about how to how to manage code. I think things have changed.

B

Yeah good, thank you and um we are being recorded for those who who join let um late, and we now you know. Thank you for that. Excellent description of you know the historical background there does anyone else have anything else about the standalone faces um and the assertion id. So can we move on.

G

Can we backtrack actually to the stack overflow, scott.

B

G

Since we passed over that, I was doing some research while that conversation was going on, so we actually hit this in our liberty testing back last spring um and we worked around it just by specifying you know an increased stack size on a particular invocation in the ts jte, where I think by default. It gives you like 1024k.

G

We just doubled it to 2048k and that took care of all our problems, and we saw it when we were tinkering around with different jdks, so different versions and different vendors, some of the vendors would tip over the stack and some would be just fine. So.

B

Excellent, um I I know we we saw it before with glass, fish testing. I google, I I searched my email, I couldn't find like yeah I'd, look for a stack overflow and I I looked for the. I know we had issues like last fish issues or tck issues, and I don't know I'm just looking. I look for the wrong thing, but I did try to learn.

A

The issue post, the jdk 11 build of the platform dck uh before that uh it was not seen and it is seen with the glass fish. Also, let me run with the glass fish uh uh six with jdk 11 uh platform. Tck so has bran said uh uh what uh what's the stack size uh which helped uh for open liberty.

G

Yeah it was, we just doubled it to 2048 and that exactly matches uh our situation. So when we were doing java 8 stuff, it was fine, but it's when we switched to java 11 certain vendors. We just tipped over the stack okay.

G

um And I can, uh I can add, to the um the issue out there in the repo with more detail of of what we did.

A

Yeah, that would definitely help and save some more debugging time for us. Thanks brain.

G

B

Let's see okay, it's um so I added an item for um um you know whether it's yeah, basically, I um um whether it's time to and to update or to look for any stage, spec api um updates that we haven't updated the platform tck build for yet and um the reason why I'm? The reason why I uh I wanted to ask is uh because of you know what we saw with face.

B

You know jakarta faces once we updated the faces api spec api we've got build failures and I guess the question is: do we want to just keep those keep changing to the latest spec apis and maybe get even more build failures, possibly um yeah, I'm not quite sure if that would happen or not, but that would I thought that would be worth po imposing to you know for input. um You know if there's concern concerns about changing too much at once.

B

um You know so do others have any opinion on that, um and this is what the platform tck um build uses to compile. All of the current tests.

A

uh Basically, uh in my opinion, uh uh uh having the stage spec apis and uh using them as soon as as early as possible gives us the clear visibility on the changes we need to make to our repo, basically, the jakarta atck repo and have the changes done instead of in when, uh when the apis are integrated with the glass fish, so it having using the staged api is giving us early visibility into the changes we need to make.

A

For example, in web socket, we had to have some more make some changes to the test and also for faces. We had to make the changes. Updating the apis gave us the early visibility that we had to make changes and not wait for the spec to be released.

A

G

A

Some changes which breaks these now fixes we do then, and it causes the regression for the fixes we do. Then there will be a problem, but I think api pros, um spec apis are released and test are done in a very good process. uh I don't think we will have some regression after making the fixes for bill changes.

A

B

That's good, that's helpful, um I'm trying to be mindful of other implementations. You're not really like. Just I know, glass fish is very active, but any any other.

B

Is is anyone yeah seeing problems because we're you know frequently, you know we keep we're we're moving too quickly on updating the new spec apis that are staged.

E

I think this is a really good idea, so it offers failing fast and yeah, don't waste time and get.

E

Yeah surprises at the end when everybody is in hurry, so that is very good. One thing that need to be managed- um and I think that is managed manually now- some of these um spec apis on the staging repo got removed after 60 days.

E

So we have to make sure that at least that version that is referenced has a built on the staging repo, but that could, on the other hand, ensure that for others who want to integrate and need that too, so.

B

Great good good feedback. Thank you.

B

So I will um um well anyone can anyone that feels like updating. Those should certainly go ahead and and do that the um um let's see, let me see I'll just add my note.

B

Api artifacts, based on and I'll just put the link there.

E

Maybe that tooling, we are developing and introduced regarding.

E

Creating a documentation, a graphical documentation and report on the dependencies of the apis that could help, because, if you run the tool you can see in the logs already of jqa or jq assistant, that spec versions are missing on the staging repo. If you configure the staging repo as a target for the analysis. Well,.

B

That's great yeah. We we, we have a jenkins job that um builds the um um like. You know the signature um that it'll.

G

B

Basically, take the spec apis that are referenced currently and and it'll it'll um generate the signatures and you can generate the signature map file. You can download the signature map files, um you know it's one of the artifacts and so maybe that job could um um or another job could generate the dependency um um um report and what you know you.

G

B

I guess I yeah, I guess that would be. Maybe it should maybe be a different one, but same or different, um and is there a um do? You have a link that you can. um I mean I remember.

E

Seeing the output.

B

But if you add that.

E

I will link the repo um and there were a lot of changes since the last introduction last week,.

E

B

B

So the um the the last item on the agenda- anyways- I just wanted to mention so people- are aware- and you may have seen the discussion on the the tck mailing list. um Scott um um um kurtz who's who's here um uh found a regression in the um um sig test tool that we use for signature testing. In that, um let's say you're um like let's say someone adds a new sub package to persistence, um near jakarta, persistence and they add jakarta dot, persistence, dot.

B

My you know my new api um class and that isn't currently being detected. That's the that's the you know, that's the regression, and I wanted to mention that for awareness and um scott um created the pull request for the sig test, the netbeans sig test tool that is merged, which was great to see, um and you know we'll do we'll do more. You know testing of that, but um just wanted to kind of raise that awareness.

B

I I know about the super, the no super setting and no subsetting, I'm not quite sure if adding a new class package to a spec api is that is that um is, is would that be considered? You know, you know super setting.

B

It kind of sounds like it would be, but I'm not I'm not 100 sure if that you know if that is or isn't included in that you.

G

B

And in the concern of the no super and subsetting require rules.

D

Well, I also don't claim to know the rules. um I was more reacting to my impression of what I interpreted the intent to be but yeah. I couldn't point to a firm answer myself and you know I just at least wanted to socialize. Whatever decision we made, um I don't know I mean if we, if we ask the person who maintains that repo to release a new version, you know I don't know if we can expect him to actually do that him or her. I'm not sure.

B

Yeah, I think I I I think he'll be responsive. I I just I yeah the one you know. Let me just add um I I I'd like to yeah. I think I mentioned it um um somewhere on on the issue or something, but um you know we should um you know we should. We should verify um the fix. That's all and I.

G

B

Know what you know you've done. I don't know exactly what you've done. I know locally. I've done some validation that it that it is a problem, um and so I can take like I already built um the test tool and I just didn't run it again yet to I, I want to verify with um ee 91 tck that it does detect that case.

D

I did a local test, but yeah. It would be good to get other testing too.

B

And and then like, if there's if we find other k other city yeah, if if for some reason, yeah, we find that there's still problems, and maybe we would wait to ask for the build until we know you.

G

B

Satisfied that um but yeah, maybe there's other things, there's other testing it's it's um it's interesting like when I did the testing for ee 91, I manually modified classes to add methods, to remove methods, to add fields, to remove fields and to me you know those were obvious: um super setting and subcla sub sub um sub um setting examples where someone either is adding their own methods or cl fields or the removing methods or fields from a api class.

B

I don't know to me the like: adding a new class doesn't sound good and it's good that we'll validate that also, but that almost sounds almost you know like I don't know um different. It sounds different, but I'm not sure.

B

So I'm glad we have it on.

D

The main list and another if anyone else thought there was any other changes needed for this next release, we're going to ask, or we should ask at the same time, but I don't think I'm not aware of anything like that. Okay, um it looks like you know. The the um release is set to 2-0 snapshot now, so I don't know if that was an intention of this being a bigger.

D

You know maybe breaking or major change that would be such that he'd not be ready to release it, because it's a bigger change versus a smaller point release like a 1. 1.6.

D

So we can I, what do you think scott just see if anyone chimes in on the matterhouse the next day and then go ask for a release? Do you feel, like you already have a channel going there.

B

Yeah, I I think I I think it'd be yeah, so once we've validated it and I don't, I don't really expect more feedback on the mailing list. To be honest, um um we might get it and if we do that's great, but I I think um yeah once we've validated that the identified problem is solved, I think we should request every a release and for the platform tck I'd like you know what what I'll do is I'll create a um like one update in the library.

B

I believe the processes, when you add a library or update a library to a new version that you create a cq, a check in question there and I'll do that for the platform tck and I'd like to have the time for that. You know you know you know so I'd like to have the release as early as possible.

B

You know so that you know there's time for that cq to be processed for ee10, but yeah. For that reason, um I'd, like you know, I'd like to do it early but uh yep or as early as possible.

D

Thank you. Thanks for handling that.

A

Also, the test repository, I believe, currently it's we use from a private fork.

A

I believe we should copy to.

A

Which can be deleted? uh uh The risk we have is that we are using the source from individual uh uh github uh fork. Okay, so.

B

So consider forking the netbeans.

A

Or we can copy the source to jakarta, tck tools, repo, where all the contributors can maintain it.

D

You know, presumably there's exclusive ownership to the maven coordinates though so it's it's not like. This is just any fork. It's identified by the maven coordinates and if we agree at the jakarta level that we like this project, it doesn't seem like it has to be a jakarta lawn unless we're faced with issues like this or we need a jakarta release at a certain time frame, and we don't want to rely on this release.

D

B

Yeah, I I there's probably reasons to do it. My concert concern with forking it or copying. It would be um maintenance. um You know right now. I I know of three people who have contributed, um but the the people, the people who will contribute to that is going to be higher.

B

If you keep the current repo, the netbeans repo and it's kind of like someone's personal repo, but it's still the official netbeans repo, we could propose moving it somewhere, but um I'm not sure that it should move under yeah, I'm not sure where it should move, and I don't know I mean I I want to see the need.

B

I want to see us meet the need, um and I don't I don't know. I think we should just. I think that should be brought up on the tck mailing list and discuss there.

B

Just because it's yeah, I don't think I don't think we're going to figure it out. You know right away. I think it's going to take a while to figure that one out, but I don't know.

D

If we can get a release in time for e10, that would seem to speak to this being a good mode of operation in the current project. I'd be happy with it then.

B

Sorry, if, if for ee 10, if we, if we, what.

D

Well, I mean so here or facebook needing to release at the relatives last minute, and if we can get this to work out, I would say that this plan is probably fine yeah. I think I could.

D

A

Yes, we can use, we can discuss about uh the signature tool or the source being in a private repo yeah uh current release. We we can keep it as it is.

B

And I'm just gonna add, and I don't to I don't want to waste the remaining time. I'm just going to add this before I forget it, but um consider creating new signature test tool, but yeah, I'm not going to you know, say what I mean by that, but because I really want to get on to the next one, because because um um it's um let's see we lost okay, I guess we already lost. We lost dimitri. I was hoping to get to it while he was still here.

B

um So I just wanted to call out um the um on the platform issue 339, which I'll here, let me open that up here. Let's just so, we can just look at that for a second.

B

I took a shot at describing the actions that I think should be taken for removing duplicate tests from the platform to tck most of from the discussion last week at the recorded tc call we had last week and um if people could give feedback on that or comment on that, I think that would be great. I didn't really email around this around um and I kind of jammed it into the issue for need to define how specification the pcks that reference other specification containers are handled and I kind of thought.

B

Okay, that's sort of that sounds like that. That's the platform tck. It also would be like if we created other like integration tcks, um but you could. You could also say that that could also apply to any tck that does integra integrate with other other.

B

You know with with ee container or vehicles um if you will to build platform requirements um as well, and I kind of jammed it in there, and so I don't know if anyone else had noticed that- and I didn't really send email about that. But I wanted to mention this to people here, and um so if people have feedback on that, I guess they can add it directly there. But I'm just going to stop talking about that and you know just open it up. If anyone has feedback go go, you know, please speak up.

C

um Hey hey scott, I do this seems like a checklist and I didn't miss it. Even though I watched the repo, um I think what is helpful is if there is something like a checklist to pull it first on a google doc so that we suggested edit you can well. We can you know the technical departees can go in there and say this is missing. This is missing easier, um it's nice to have the tracing and the link and they get issue. However, it's not conducive to actually contributing to write-up.

C

um You know it's not just much more effective with google, I'm not sure if you have access to the new drive for the ie, but the pck should have a folder where these minutes go in and where we can create documents that will become wikis. I know we have a struggle, especially in the tck side, to update the past documentation so that the single developer can run one test, submit a pr and be like hey, I'm a contributor of the project, but it's really hard to do so.

C

We still have not lowered the var to entry to to to make anyone comfortable anyone that is not currently committing for the project to to test right. I think we do have a few um non-committers here, but uh it's just complicated. So this is a great opportunity for us to say: hey, um google doc. This is we're doing x, jump in and we do have a really good forum um and the mailing list.

B

Yeah we could easily um you know like this, would like copy and paste right into. I think into a dock.

C

And then we can go in there and be like um other stuff, I'm not sure what else um who who else have comments on this? um What.

B

So I'll just say what I was trying to do. I was trying to capture I I I rewrote this. You know um section um like three three or four times it was really messy. You know initially and even the third time it was still pretty messy and I'm just trying to make it, simplify it and and reduce the you make it as um yeah, streamlined and and process.

B

You know um friction fl. You know free on the prosthetic side as as possible, but not lose anything that was identified last week. So um so it's it's it's kind of here, but if, if if people want to discuss it so want to revise it via a google doc, that sounds fine too no issues there. So.

C

And you know it's kat when you said because the call of last week, sorry I missed it.

B

It was recorded yeah. Actually I.

C

Will check it? I I just really checked those over hours, so I will in six in the morning. You know that's too hard but anyway.

C

So so what I said is you have been working on this and it's amazing right, but there is no tracing aside from an edit that doesn't show you know it's not that you are working on a pr that will show the review. You are working blindly and not showing your work. So I'm saying, let's protect the work by using google docs if you're not going to use a pr, because it's fine, you know piano would mean that it needs to be merged and reviewed by others right um endless use.

C

Google drive, google drive could protect the tracing and the improvements as it is. There is no tracing aside from whatever happened and how it started. I am a hoopla and, as you know, as showing how things get today, because for developers um you know showing the the the goal is not all of it. We need to show the pain that goes through it and it's not easy right. It's humble! So, let's do that, put it on a google doc.

C

Add it to the link, I don't think it issue, and that would be my recommendation and go from there because you did most of the work already you're. Like just saying: hey, you guys come in review. I need extras.

B

I may have done most of the work it. It all depends on what how others feel about. You know that all you know also were in the call last weekend, whether I covered what's important to them, and it there's a lot of subjective aspects to what we talked about last week.

B

You know as well and and and no matter what we do. It's one of those things we're going to lose something, no matter what so um it's actually it's it it it's. You know it's um summarized in the in the um the notes um from last from last week's as well agenda, but our minutes. So um so let me so that sounds like a great, so that sounds like a great um way to handle it so good. um I think the google cloud same doc. Okay, does anyone else we have 10 minutes.

B

Does anyone else have any um issues that they would like to raise for our last 10 minutes.

E

One add-on I might have um one drawback of using google doc for editing is that that is not the developer's preferred tool.

E

I would like to do it within my ide and if we would write these documents in ascii doc docs and create a wiki out of it that could be exported, for example, to the website too automatically when released.

E

That will be another option to have that traceability and transparency about the changes who made what changes at what time, but the developers could use their preferred tool. The ide.

B

So let me throw an idea just because it was fresh on my mind, um just be sorry amelia, let me just throw it out there and then I'll I'll turn it over. um um Should we you know should, should you know, should we should we um have a um um um like a notes, uh folder and platform? You know tck for um design uh discussions. um You know um I should say design.

B

Maybe the process just discussions, um because then that would have- um and we would have you know, pull requests um um for discussion and revision and all that um and that kind of gets us out of, and then we just have like mock-up either yeah. It could be markdown as well should say.

B

Such I'll just add, you know so mark markdown um would be the other yeah other. You know the other popular option there, but um um so just would you would you know, would others like to see that and um amelia? What were you going to say.

C

I was going to say that that um working on accident is a fantastic way to also trace things, and it will make it easier for anyone working on this to become a potential committer, because that would be the facing with pr smurf and all that data. If it's done under the tck repo will be added to the next release. So all those committers, because we have the pulling card all the activity, gets pulled and said these people were audited and are helped, and you know if they want.

C

If you want your name added to as a contributor of particular release, it will have tracing, which is a huge plus one, even better than google. Google is just the basic you know just basic, but that one it looks like yes, this will clean up even more so young. A really good point.

B

Great um I I was thinking that yeah we really need. You know it would be great to capture historical information that anyone has to share in in such a you know. You know in such a folder, um even if they start out with something that's wrong like just like just the other day, we were talking about um how some some folders have e sorry. Some folders are called ee and sc in in in the tcka test folders, and that me yeah. That could mean um java.

B

You know standalone edition test, it could mean um you know jakarta or enterprise edition test, um or it could mean end-to-end tests, and I always you know I always thought ee was only you know a reference to you know it's. You know it's either a you know a package for you know if jakarta, but there's also e. You know end-to-end and there's probably other historical info that you know you know that could be shared.

B

um You know that for people that had and having a place for those kinds of notes would be great, so yep, okay, good.

B

Thank you any any other ideas. Last five minutes.

C

um I would like to recommend that um um maybe in the next call for 10 minutes, uh the college used to do a retrospective of 2021 and the work done for the um even for the newcomers.

C

If there are newcomers- and they were not related to the work done in 2021 and the tck, I think it's important to me to see what pr's are still open. What issues are still open? Why are they open and do the little cleaner to say you know? Ideally, the tck intro retrospective uses the pr's and say you know this one's for 2021.

C

We will work on them or not and just clean it and be like you know, xy I did say before we ended the year that that scott, you have done a fantastic job, bringing everything to the forum like no other specification under the jakarta. Ee really shows the amount of care, and it's a thankless job and like that many go in there and are doing a really good job as well, writing and commenting, but I think the retrospectives that's necessary should be recorded. It should be like 10 minutes in the microprofile site.

C

We use a one full hour for the first call of the year, and that is great for the tck. You know it's up to the group to decide. Do we use a full hour and it should be a special, but it's not something that you can force into people right and I'm saying that maybe you do something architectural, it's easier to talk about prs that are still open from last year. Why are they open and who is not taking them? Why are they still opening, and why should you cut be they want to own them?

C

It's not because you can do them. You could be doing all the work right. Who can we on board to do this kind of job, and that is what happens with retrospective when we see what we can drop from previous experience and move on, and are we doing the trainee trainer to enable others to highlight a potential release right like do we have that in mind? So I believe that it's extremely important, my recommendation is to schedule it for one hour make sure that there is a google.

C

You know a pool that says hey. Would you be interested in doing this and then move forward? That would be it.

B

So could this could that be like a triage call, that's kind of separate, so we could kind of like act. Just add a triage call.

C

Yes, it's not going to be technical in the level it's going to be a retrospective, and you should be pretty much the agenda on things like the pr's that are still open for 2021 things that many would like to see. You know um the potential new committee is someone that is working currently on the tck by the same no match who can enable him or her to become a committer.

C

That means the person needs to have much more responsibility than the average committee needs to have more handling in the level of being enabled, and that's like serious work and the microprofile side. We have at least two people leading and one newcomer, and that potential newcomer is doing a lot of the work in making the mistakes. We need to make more mistakes on this level, especially because we have 10 coming in. This is a fantastic opportunity for the project itself to be aggressive on onboarding, new members and making them feel responsible.

C

That means failing nicely and openly.

B

Okay, great all right, so that's good um agreed, and um you know no one. You know we'll be against that we'll. You know we'll have separate calls for that, and that sounds like a good organizational kind of thing. So it sounds good. Okay and.

E

B

Minute any anything else from anyone.

B

All right, thank you, enjoyed the rest of your day and thanks everyone.

C

And it's cat: hey we're the only ones in video socials.

C

I had to show my face a little bit to say moral support. My.

D

Everything this video, but my pc, chuck chokes way to do it so.

C

Next call uh next call the retrospective one. If we can do the respect retrospective in february, then everyone has the opportunity to show their nice jakarta t-shirts.

C

I will tweet, I haven't.