Jakarta EE TCK, 6 Apr 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TCK call #9

Description

April 6, 2022 Jakarta EE Platform TCK call #9. Minutes can be viewed via https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#bookmark=kix.fztdgtxwyhh8

A

A

B

I'm going to share my screen, see.

C

It's not yet recording or sharing the screen.

B

All right, so you should see the um agenda. um Yes, okay, and I can't see what I'm sharing, of course, but.

C

It's totally perfect, um it's kind of it's not recording yet.

B

It's not okay. Let me.

C

No not yet, oh, it should be recording. Yes, let's start, I think it is recording. I just didn't see it. Yeah yeah, okay, awesome.

B

All right, let's see so um before I started recording I was just saying um it's been crazy. I haven't had time to organize anything specific for the agenda, so let me just um I'll just throw on um ee 10 um tcks, which is always a good. You know a good um subject and open up the floor for whoever wants to talk about anything specific about ee, 10, tcks.

D

Yeah so scott, I wanted to follow up on and it's kind of a side issue for the 10cck, but one that we had been working on um the what to do about java, 18 and beyond the security manager stuff.

D

So obviously, you accepted my change to disable that for higher levels of java, but is there more we need to do or who do we need to talk to to like define the process for how an implementation would go about claiming support on a higher level of java, like it seems like we've identified the tests that don't work pretty well, so then, is the solution to just ignore those failures to exclude those tests and the results, or what do we?

D

What do we see down the road as what people need to submit if that makes sense,.

B

Let's see, let's see 18 plus um yeah, so so it's not just java sc 18 um yeah, you know the the road to the road to um um oops, got caps lock on uh so say that you know the road to um I'll. Just say you know, java sc20, you know 21 um is not yeah far away and that's you know the next um lts right.

D

B

B

Llts, so a related issue is, um you know, you know what you know, what will be removed um um in sc 21 with security manager. Exactly is is, um um and I I I think from the platform call. um I I heard interest in um um um in working with the you know: jdk team, that's designing, you know 21, you know what we'll be in 21., um but um I don't think we have clarity yeah.

B

Yet this you know um what will be in 21 um um so other than you know the the thing the current thinking is that the security manager will be removed which breaks compatibility with um ee10.

B

So um um I I think yeah um um so you know compatibility. You know um I'll say you know: ee 10 compatibility.

B

Is probably impacted by removing um security manager um but um yeah? I think you know at this point. The only thing we can really say is um you know in the future.

B

You know we will need to determine what um um ee compatibility.

B

On um java, sc21 means- and I don't I don't think we can answer that today, but I don't know if that's ee 11, I don't know if that's ee, 10 or 10 dot something, but um but do you know, do we really I'm going to stop talking on this, but do we really? You know you know you know, do we really know enough now as compared or is it better to wait until we do know um to make a decision on that um and um not that we would decide in this call?

B

But I I mean, as a community, that's driving, you know ee10.

B

When do we decide what happens with the ee10, and um I pro I propose that it would probably be when we actually know what's going to be in 21, for compatibility with ee10, whether that's nothing or a way of dealing with ee 10 applications that do use the security manager and what what happens? Those applications do they just? Are they just not secure?

B

Is it are these applications that are you know that yeah that were used in the security manager and now the security manager calls are stubbed out and whatever they were doing, they don't do or is it mapped to something, or is it handled differently? Yeah it just yeah. So I don't think we can just figure that out. um That's my viewpoint on it, so they can't I'll stop talking now so yeah. What do others think about that.

C

So to be recalling names, if no one wants to speak.

A

So does it mean that for certification of application servers like glass wish, we knew what target uh java sc 18 or java sc 18, which is already in release mode? uh Should we be limited to uh uh jakarta java, sc um 17 yeah, the current e10 release for certification of, say, glass, fish? We need not work on java 18., even if glasses supports java 18.

A

We need not certify glass. Fish with dc case.

A

A

What we are thinking um since security manager is removed in java, sc 18, and we will, we might be able to run on run dc case or might not be able to, or what's the mandate by platform team on certifying the app servers with java 18, which claimed to support java 80.

B

B

Yeah so there's multiple implementations and we have ee10 ee10 only defines you know jdk, 11 and 17, but um um you know the the the idea of um running on 18. I I think you'd you, you would have to enable the security manager um and um for implementations that um don't enable the security manager support on on um 18.

B

I think that would mean that they would see you know they would. Certainly you know. They're gonna, they're gonna see um a small number of tck failures and they could try to challenge those tests.

B

I guess would be one path you know like like. Let let's say if it's glass fish, let's say um um I, you know the glass fish scripts for running the tck. Don't up, you know, don't run with the um the sc 18 flags that allow the security manager to be used. So glass fish would probably see that you have a small number of failures when they run without the security manager on 18 and um because, let's say hypothetically, that's how glass fish team decided? That's how they're going to run the tck.

B

They could challenge those tests and see what the um um yeah, what what the finding is on those challenges.

B

That would be one path, um but um um for you know you know, as someone who works on t on running tcks, also in my case for wildfly, um I would you know I would expect wildfly to you know to enable the the security manager um um on 18s, because it's still, you know it's still in the jdk, and it's still allowed you just have to you know change the flags to allow it, um and so that I mean that's what I would do so if glass, fish or others wanted to do that they could.

B

um The the real problem, though, is is no one really knows. What's going to be in 21. and you could say, 18 is kind of like getting ready for what might be in 21, but what will be in 21 and and how? How do we? You know? How do we deal with this? It's above my you know it. It's not my call, but uh but I mean those are some ideas of what you could do so does it help you help guru.

A

uh Yeah so long term we are looking for sc 21 and a roadmap in sc21 is not defined, so we will have to wait um one for sc-29 roadmap, how the security manager is it completely removed.

A

Based on that, we will take a call on tck test, with security manager for jdk 18 onwards. Is that what we are thinking for long term.

B

Yeah yeah, I think I think that's a good summary and um going back to what brian had said, I think um for sc 18. If you wanted to run without the security manager, then you'd have to challenge those tck tests that do feel because of the security manager not being enabled in the configuration that you you know that you run in and see what happens with that. I I can't predict what would come out of that.

D

I guess that that's the the center of my question right is like. Would that necessarily rise to a challenge like we?

D

We have a well understood set of failures right, so I I suppose one could try to submit a certification with those failures showing and just be like you know, we determined in our pre-release exploration that these are the things that would fail, and then you guys decide whether to approve this or not kind.

B

D

B

Think that's definitely worth trying and just you know I wouldn't make it a huge challenge. I wouldn't like go to a huge effort to like. um Well, you could, if you it's up to you, it's your challenge.

D

I mean especially because it wouldn't be a single challenge right, because the tests are in like four different areas,.

B

That, then, just start with one yeah. You.

D

B

Start with one of the areas- and uh you know, challenge challenge, you know it's a few different areas like but start somewhere and challenge that and then and then maybe you can mention you can challenge the other areas. But you know you're looking to start somewhere and right.

C

B

And I don't really know if it's is it going to be in that, like let's say you do it for the security api um tests, will the guidance come only from the security team, or does it come from the security team and the platform team or in other? I don't know it'll be interesting, though it'll be an interesting process and it may be mocked and valid. It may be accepted.

B

I have no idea, but um I I think it your best off just try it for one area and then, if it succeeds, then do it, then it's it it's you know, then you do it for the other others as well or do it for the others too. It's up to you. You know whether you just do them all right um and I'm yeah, I'm I'm more concerned about like what. What does it mean that um um an ee implementation runs? That way?

B

um What's that mean to applications um that that do depend on the security manager? You know that the fact that you're- not you, know that you that you're not enabling or allowing those applications to use the security manager, what you know. What does that mean to those applications?

B

And um um I don't I don't like the idea of giving the impression that, yes, you can run still, but there's you know, there's there's less security, it's just like a general. It's like a general dig against ee that I don't you know. I don't like to see happen. That's all that! That's my concern about that that we, you know, I don't want to see ee 10, have the reputation that there's less security.

C

Yeah and brian you nailed it there. You said the implementations will be used will will I don't know if you said this, but you mentioned that when the implementations that choose to be compatible with jakarta e-10, he said he said: are they going to? uh Is it is the system or the process I want to allow them to have optional security or not. This is something um actually beyond this call, and it's really really good question.

C

I think jared brought it in and he should become a threat in the tck forum, because the specification committee, not only is not the only one that needs to decide on this, but the entire community testing in security. We talk about cvs, who is going to make the patches not only that, as this is linked with our users and intent, is the first release with features if we fail now on this release the current users of the my migrates or just to migrate from ee7.

C

That has like way back java e to finally jakarta e10 might completely dropped the technology, because security is a major concern and it has been for a while. We are open source and we are fully responsible for all the code, the maintenance, the application.

C

So I highly recommend that I think it was brian or jared who who asked the question about security and how to deal with it and then, because there are a few, um um I recommend the the the one of you that that asks the questions follow up in the forum and says hey. We went on this call and I asked this question and I think this needs a major over. It cannot be overlooked. Let's start the discussion.

A

Well, we had the discussion on the platform call and I thought.

C

Yeah jared, that call is too small in the sense that if it doesn't make it to the forum, it actually didn't happen. If we talk about open source, let's use the apache way right. The call has like 15 maximum 20 people. Do you believe that that represents the entire jakarta ee technology on dusk? On those call attendants, no decisions should be making in schools, especially when we are talking about security.

C

It should be in writing so that 100 or 900. I would be as serious as sending a message to the community forum that has close to 900 uh jacquarte's, because if we fail jakarta e10, that is the first release. We are going to lose most of the users that have been waiting for any features. There has been no reason to move to jakarta, ee's previous releases, because there are no new features, so either the user is awaiting and using the past technology of java, ee or migrating to another technology right.

C

So we can't be complacent with just the platform or the community.

A

Yeah, so what the platform was, the leading of the groups that were at the meeting. Looking back at the minutes, we do not support 18 plus with the ee10, because there is no 21 at the release of ee10 and they are saying that we will look at 21 when we get to 11.

A

I.E next year, because that's when it's more appropriate to have if a 10.1 becomes necessary, then we'll consider a 10.1 similar to what we did with nine with a 9.1 yeah. But it's kind of we're putting the cart in front of the horse here, a little bit as scott continually points out, because we don't know what 21 is going to for sure. Look like at this point.

C

Totally agree with you on on the wait and see for the technology.

A

But if they make significant changes at 21 that ee10 can't support because they're breaking changes, it's a moot point anyway, because none of ee10 will work on it because none of the api's been updated to handle that if they remove certain things that we need to update to say, hey yeah, they deprecated this back in um nine or something like that now they're removing it at 21.

A

We should have moved over to the new api within the ee api, so the java sc api in the ee- that's a possibility. That's happened obviously in the past and if we had to accommodate for that, so it's going to be a wait and see at this point and I think we're going to have to continue that- and that was the opinion of the people on the platform call.

B

And I was on the call too, and I completely agree with every everything that jared just said.

C

So then that means we don't need the email. Then this has been tacked out and we are moving forward to keep ee 10 away from 18. Then.

B

All right we yeah yeah correct. We actually have a I'm gonna get the link. We have a um a tracking issue which is um yeah. um I know for some um can be better because it github issues can be updated and by anyone, whereas email, not everyone wants to join the platform.

B

Tck mailing list, which I disagree with, but um I know I've gotten feedback from certain from some people that refuse to join yet another mailing list, but they're happy to update an issue. But uh let me get the.

B

The issue out here it is okay, I'm just gonna, add the link to the agenda. Let's see.

B

Second issue is that.

B

All right yep there it is so 743- and um it's already you know, has gotten a lot of discussion and uh you know brian added um results from running with open liberty and brian helped me see that my results I had attached initially were wrong and then I had added, I added more results that pretty much matched what brian had uh found. So the wildfly and open liberty had found you.

A

B

Pretty much the same results so yeah.

B

Let's see so um um yeah, congratulations, brian! I I I don't remember now, brian, when you you know, brian decker became a committer on the on on the platform. Tck, it's been a while, but uh yeah.

C

It's been a while, but you see I'm bringing it up because I think not only do we need to talk about code or like the application and new tests, and things like this in this call, but actually acknowledge the growing community of the committers not to change this. But you know every single month. If we have new committees of new contributors, we should highlight them here, even if they don't attend right. Yep. um Definitely.

B

C

Right so I just added a tweet of you know, brian who was here. I chose him to be the first one, and I was like oh yeah he's a committer here and just to make a point.

B

Oh, it's great, um I'm gonna nominate a few people um um I just haven't. I haven't um um done it yet, but um um I I think um yeah we we have like. I think we have like. I don't know like 15 or 16 committers on the platform tck. um I want to see.

B

Increased number of people, um um yes um to help with switch to um achillian, killian and maven. um um You know just it it it it it. It didn't seem like didn't, seem like um we had of um enough hands, um and I that was you know. One idea I had: um let's let you know there, there are people who have been helping create the newer kilian um tcks and um our killian-based tcks, and um anyone that isn't a committer, that's interested in in helping out with that. um um You don't have.

B

No one has to be a committer on any project to help out, but um any you know anything I can do to get more hands on the effort I think will would be welcome to um um so that you know. I wanted to mention that if you know in case there are you know if, if you know of people or if anyone here on the call that isn't a committer that wants to you, know work on killian and maven um you're switching over to those.

B

um I I I think roughly, if we're, if we like, if we're, if we were to complete the refactoring of the tc, the platform tck over to maven and our killian in the ee 11 time frame, I think that we would probably need like one roughly one person per test area, and um I don't think that we have that now. So I'm just I'm kind of concerned that we might run out of time again. If we don't have enough time during the ee 11, not that we know what the time frame is for 11 yet.

B

But um so it's kind of why I'm pushed to get more people.

B

D

B

Involved so yep any feedback on that.

C

100 agree with you and the concerns yep great.

B

All right, uh any any other topics.

C

I do have a topic. I know that um you started the conversation about moving uh the tck repo after ee10, and I just wanted to make sure that that is still the plan so that immediately after the tck after the release of 10, that we don't continue to postpone it right.

B

Let's see, I'm just going to add the um let's see so um discussion about moving the platform tck repo to there. um I.

D

B

I think I think that um I think there's there's some follow-up on that on the spec mailing list, too.

C

Yes and then I I think there are like different threats on it, so I I got lost, but I what I want to show it is that it continues to be a priority for the tck project to move immediately after ee10 is completed. It seems to me that that was approved over two years ago by the specification committee and escapee were part of it, and we continue to postpone it, and we have no excuse it's just that.

C

We have to do the work, and this will continue to be postponed if we are not serious on prioritizing it. I have no idea. Why continues to be a problem? um Hey cesar.

E

Hello yeah- I just pasted here um I think, is this: a pending conversation that ivar needs to open in the spec uh the spec calls, or um that is related to how to you know, reorganize a bit the the repos I see in the in the link. I sent you here over the chat.

E

I I see the tck repo uh stay um moving from eclipse ee4j into the jakarta ee, um so I left that as a reference uh when, when that conversation um goes into the main list coming from these slides, because the slides still doesn't have the the context it's just have the the the before and after, but there is no context about the. Why, and that is one of the things that I think you are was going to to add in the slide and open an email thread.

B

um I don't know if I shared my entire browser or can others see my.

E

We are seeing your your your, the google slides. Yes,.

B

Okay, so you can see the jakarta ee repositories, yes, okay, good, I just didn't know if I had all of my tab sheets open or just one of them, okay, so yeah, I'm just I just switched to you know to you know to to that. But uh okay um yeah, I was kind of like yeah. When I first got asked to move the platform tck repository, my response was: are we organizing or yeah? Are we all moving? Are we doing it all together?

B

But I also, I also said: um can we wait until the ee10 release is complete because I don't want to you know to disrupt you know anyone's work, um and I know it's. You know it's. It's all. You know it's supposed to be safe and you know um the old. The link is, you know.

B

The old repo link is supposed to work still and everything, but I just don't want to cause problems in the middle of the release, but um but I'm I I I I think it's a great idea if we all move together at the same time um so but I'm not so I'm not agai, I'm not against moving the repo. um It sounds like it's gonna, you know it should happen, but um I'd like to do it with you know. You know.

C

With with everyone, yeah together.

B

C

um And scott, I agree with you, but um we you know every project is independent right, so some create features, features for releases that are included and they're in a major release. Another other specification, all other specifications won't, so you have. We have to be careful with expectations because we cannot force the the migration cesar. Do you know what is the eta with ivar on the.

C

Doing this kind of work or starting this work, is he going to do this before 10 or after? Like I mean the preparation should happen before 10 is completed, and then we can start the work on 11..

C

E

I don't know the the the estimated time um this is an item on on on the agenda for today's spec cometical. um So I think a follow-up on this will be. Will we mention it uh because the last time, the the last call when, when that I was in um that- was the the next step right to to to add more context into the slides and open animal thread. But I will ask today to to to labor.

C

And cesar, can you make sure that the information doesn't stay in a vacuum of that call and it goes into the platform. I think it was over a month ago when um this was discussed or two months ago, and we still haven't seen them the email to the platform uh uh forum right. So we need to. um You know, make sure that that email lands, even if no one is fixed at all. We should be much more transparent because the migration will happen and it needs to happen this year.

C

Even if some will not want to do the work we need to do it. It is just good business. So if anyone disagrees so be it, but this is important and it was voted in two years plus ago.

C

So, thank you. Thanks, says r for, for speaking up and bringing this to, um I don't think you have to send the email to the public forum, but I think it should be ivar, since he chose to do the work right to at least initiate the work.

D

I would bring up another repository level backlog item. um We still need to rename the master branch to something else. Would we be looking at like doing those two pieces of work? At the same time, more or less.

B

Sure yeah yeah no reason not to.

C

Oh brian, you brought out this is something a forgotten um topic. Can you bring the the link to that um because it has been so long holy cow.

D

I'm not sure where I I just it was something in my mind. I don't know where the item or.

B

The email is it's on the platform, it's on the tck mailing list, but um um it didn't get a lot of you know responses, but.

D

B

Say we're moving the repo moving tck repo and, and you know one of the things is it. You know. I I've heard before that. It's like a u.s thing also, but it doesn't mean that we can't do it.

B

That was just some of the feedback I got from some people.

C

Did it happen in the melanies, because brian brought something- and I think maybe only one person commented it was so long ago. I will do my best to find uh that thread, but it's just maybe brian can find it faster. I mean I'm not throwing you as a volunteer to find it.

B

But I'm just saying it's so old and we've got so little feedback um yeah we can. We can. We can discuss here too as well, but.

A

B

Know it's in there somewhere, but um um can we can we move? um Can we so can we can we change the default.

B

Branch from master um to I'll just say main, because that's the typical um um you know: that's the typical. uh You know um default choice alternative, but the I mean there's other ones that um you know yeah. That could be nice as well, um could call it trunk. Was it trunk? Isn't it trunk what we used to call it on subversion or was it cvs? I don't remember now, but uh that would be.

C

A bad naming cbs is a pharmacy right.

A

At ibm, we're using things like main or release, though I think that means two that we're using.

B

So maine are what was the other main r.

A

Release is the other one that we've used.

B

Our release so releases, like the main like like the main yeah, would be the replacement for master okay.

A

B

Okay, um I don't have serious thoughts about this, but um um and I thought a little uh yeah if um like if we rename- let's see it might be kind of confusing, but um um um what would we actually at the like to look? Because I don't remember now what do we call our um version? Oops, our versioned branches, now, okay, it's like 9 1 x, so I guess so so um I guess the equivalent equivalent to that would be um our 10 um dot, o dot x.

B

um um Yes, I'll just say that 10 dot x.

B

Instead of master- and I I think we get into confusing situations, but um we later create a um you know, say a 10.1.x or.

B

B

um um It could get confused and um that's the only concern about that. Like you know, at the end of a release.

C

Yeah, but don't we do we have documentation on on this written? I think david wrote. It wrote about a bunch of the documentation for for for for the platform. Don't we have something like this or a mommy statement on.

B

Have we have we had a discussion on branch and on you know, on on, like calling releases, you know branches like 10.0 or 10.0, um 10.1.x or 10.0.x.

B

um um We had some discussion on that, um but we- but this is this- the the idea here would be just kind of eliminate the idea of a master branch or a main branch that later gets renamed, which causes all of our jenkins jobs to break our need, or should say it causes all of our jenkins jobs to need to be updated after the release in order to handle tck challenges so like after 10.0 was released.

B

um Since we did all all the ci jobs run against um on the master branch they're all out of date after the after um the release is done, and we have to update them to do tck challenges so.

D

B

So if we, if we used like a versioned approach, it would you know we wouldn't have to yeah, we would you know we wouldn't have to switch uh from from main to you know, 11.0.x or whatever yeah with the the branch. Would the the new branch for the release would be this determines before we start um coding against it, but it it might be kind of weird for developers.

B

You know on our local machine, you're working against the main branch and then suddenly, you know you know. 10 is released.

B

Sorry, you wouldn't be developing against the main branch you'd be developing against the yeah. I guess that would work yeah because you'd be you, you just wouldn't have a main branch to develop, against which it could be weird, and it could be weird and in ways were you know in some ways um when that branch changes, but I I guess you just kind of like you know like when the new branch is created for the next release. You just you'd you'd, carry that work over. I guess um would there be any impact there like?

B

Let's, let's just say, yeah there were changes you had on the the 10.0.x branch that didn't get merged and you didn't finish. You want to move them to a new to the 11 branch instead of just keeping that on the main branch until you're done it could be several years um you're going to kind of keep moving to new branches every time. There's a new ee release so.

C

So, scott, let me go in here: what is it stopping us from from adopting a the name? They they change to to the release number on 10. I mean if, if we know that we're going to acquire uh codet in the future, why don't we terminate that um process and just try something new? um This definitely should be considered heavily for for 10, because it is going to a new future, something that we might do wrong might happen, as it always does like 9.1 right.

C

We discovered that we needed to do a bunch of adjustments that were minor quote-unquote. So why? Wouldn't we I? What is stopping us for changing it? Now.

B

Yeah, I'm not agai, I'm not against it. um uh Well right now. We I think we would do it after the release is done just again, because I um um I don't like I don't want to um you know I don't want everyone to have to rename their branch and lose changes, possibly and other other things that happen. When you know when you change branch names in the middle middle of a release, I just don't want to disrupt everyone, um we're probably just weeks away from finishing, um but that's gonna. You know change.

B

If we, you know if we cause people to lose their work, somehow accidentally um that that's just you know me being paranoid, I guess, but uh that that's why I would wait until 10 is released. I'm you know it's done and then do it, but, um but I think people should think about this version. You know approach and we could consider doing that. You know when 10 is done either we switch to main or we switch to um a version approach and just because I suggested it doesn't mean I really want to do it.

B

I I like the idea. I just don't know if there's any problems that it creates, so I think we should.

C

Think about it, yeah, so so um in the micro performance side, we do the web by version by release, and it has helped us greatly because um it helps with our um users and also developers. There might be someone yeah. So it might be someone that wants to use this release because it has something specific that is valuable to them and for their products and then there's another user that wants this release and then just go directly to the version, and then you know do all the work in there.

C

I think we should just my recommendation is sure um it's not a being paranoid. It's just that. You have a point. This needs to be socialized, and that means via writing and if rushing it will not be a good thing right just to do it just because we want to and sign up pull requests without any conversation. That's just not the way to go, but uh if you see you have the two branches right, but then within it you can go master and then yeah.

C

We continue to update all branches. Oh come on, it's like it's telling me yeah.

B

um So I just I, I see the one.x so there's one.x and then and and there's master.

B

So one so one dot x is is okay. You know from four four years ago and master it has been updated. Is everything that over the past four years? But uh I I guess with what I was suggesting there would be no master branch, there would be a it would just be 1.x and 2.x right, so yeah yeah, whereas we see there is no 2.x, you know branch there's just ma, you know they call it master so that you know that would be equivalent to what we do now.

B

You know which we'll switch to maine, but I was saying you know the equivalent and micro profile would be where they don't have a master or main branch. They have a 2.x branch which is the current. So it looks that looks a little different than what we're talking about here.

B

I'm just going to put the.

C

B

C

Yeah, if you can do that, we have had problems with it. Sometimes um we have to have to revert because of it. So I know this is a constant conversation on the microprofile side on reversion and imagine reverting from the master. It's just very complicated, so this is. This is why um I was thinking we.

C

We use a release, link for our blogs and things like that, and then we forget about everything else, just because right, like that's how we communicate- and maybe it might not match what we're talking here in the level of hey, let's clean it even more, but if we have the opportunity- and we have no one- can stop um the coders from cleaning the the future debts in the maintainance so be it. The attachment seems to me the best way to go um on this matter.

C

So brian way to go on bringing this up, that we have forgotten.

E

Yeah, I think that one one one advantage of the second bullet you know to rename uh 10.0.x is that that gives um to to newcomers that gives right away um the meaning of main or master right, because when you go to other projects and you open the github project and you see main or master, then you go to the text to see master for what purpose master is being using right. So I think that's that's something that um I will say is not so common with the products.

E

I normally work on regular basis, but as as someone who work with with top with apache repositories, I know master main is the latest one. But when someone just jump in and and and and see this uh okay master means it could be development, it could be the stable release and everything else is being worked on another branch. So I think this is this. This is a good point.

B

Nice yeah good feedback. Thank you and yep. Thank you emilia too, for the micro profile uh yeah. You know example too. That was uh that's good, um so it yeah so it it sounds like something like like. We could try it for um yeah. We could try it and then, and then we can always.

C

Revert if if, if necessary, we have reverted in microprofile and it was painful, but we did it um because you know that's what happens when mistakes are done, you have to own it and there is no issue with it. It's just that socially socializing, the testing or the pilots is important. Things shouldn't just show up, especially on on on you know, on code development, and we have a serious issues a lot of times with jakarta that sometimes things show up, because maybe someone wants to do something amazing and it just follows.

C

There is nothing landing in the forums and then we continue to pile and I think we're acquiring a lot of debts. But at least that is my philosophy right, because there is less reviews, so maybe 10 give us an opportunity to move away from that and just simplify the code that we have brought from jakarta ee and it's cut. You know that we have not simplified the code at all. We just left some things out um that took us a while to to to things, and I think this is a great opportunity.

C

You know just changing the philosophy of how we even presented the new releases or the new code and the in the main one like cesar says. You know.

B

Okay, so we're almost at the end of the call, but I was just you you mentioned the word, simplify and then I couldn't resist. um um So we have a reflective refactoring branch and I I'm I'm thinking for um after ee10- um and I mentioned in this a few days ago on um in response to a.

A

B

Creating the new servlet tck, the suggestion is to move our refactoring to the I'll, say the I'll just call it the main branch. Whatever we end up, calling the main branch.

B

To be side by side with the java test, harness and based uh testing, um and um um just because you know we we didn't get to use any anything that we did for for ee10 in terms of refactoring um and um for yeah going forward. I was thinking you know that we should that we should just.

B

You know do you do it did do it this way and um we only have like we only have like one minute left, but if anyone has feedback on that idea of just let's just switch and incrementally add in maven support at the test, um the tck test level, so we currently see ant being used to run tests.

B

We would have a maven project introduced that replaces it and the tests are rewritten, and but so we end up with these maven projects in the middle of um the source tree where we see ant projects and the maven projects kind of replace the amp projects, and maybe that for 11 we don't finish changing all the projects, so we have a mix still, which would be unfortunate, but it's kind of the reality of what we're at now we have some refracted tcks that are separate, but but in the platform tck nothing is refactored.

B

So um that was one idea. So if anyone has feedback on that, that would be great. I'm just gonna disable there we go. um If anyone has feedback on that, that's that's great! Otherwise you know we can. We can just push it to the next call to just to discuss more.

C

We should put it in for the next call. It should be um because this is going to take a different conversation and also it's kind of recommend that you send a message to the tck forum saying this is going to be this class and last whole week. I started a discussion through writing right because yeah you're, like so amazing everyone here, has been amazing on um the activity on the written forum. This shouldn't wait for a month, um but it should be added. The agenda should be already added on to hey.

C

This is the next goal, and then so it's not forgotten.

B

Yep yep sounds great and um thank you everybody for showing up, even though I didn't send the reminder email today, I'm glad you all um came and uh yeah we got to talk. uh I think, we're. I think we're done um and.

A

B

Call is going to start for people.

C

But I wanted to say to everyone here: it's so much fun. I have missed these phone calls and next time I will show my video. I couldn't do it today, but everyone. Thank you so much and scott. Thank you so much because, even though you didn't send the minutes because of the activity we were able, I was able to join all in the melonist. It reminded me hey yes tomorrow, because you are not. You know. The project is not silent. It's so much activities awesome.

C

B

Thank you. Thank you for sharing and thank you, everybody and uh all right.

D

A