 Welcome. This is the Jenkins User Experience Special Interest Group. It's the 13th of April, 2022. Great to have you here. Topics that I've got on the agenda. I've sent a proposal to delay the LTS selection by two or four weeks. And that's one other UI improvements. We had put this on the list that there was a proposal out for some script security UI improvements. And then we usually like to allow a time slot that Jan and Tim could share what current things are going on. We also had a topic from Uli, but with Jan, Tim and Uli not here yet, I'd propose let's let's spend some time on the first topics and see where we get from there. Any other topics that need to be put on the agenda. Okay, we can adapt the agenda as needed. But let's let's go with the topics we've got and continue the discussion there. So I had opened an email thread just a few hours ago. Sorry for the late start on it, but this email thread is proposing. Oh, good. And Alex you've, oh, Alex good is already very good. Thank you. So I had started this this discussion. And I see Alex you'd given us a reply maybe we take the time right here to have some discussion. The idea was that we've got more regressions in the current weekly releases than are typical for a an LTS baseline selection. So my thought was we should intentionally choose to delay the LTS baseline selection while we work to resolve those regressions. And as we resolve them, then we can we can choose the LTS baseline based on a weekly that has has confidence for us. I hadn't yet read your reply so maybe you can take us through what what your observations were there. Oh yeah this is just what I quickly wrote on a few minutes ago. I've basically rearranged your list of issues into blocker major minor and trivial issues with a short explanation how I experienced them. Because if I remember correctly, they're all labeled as major or blocker currently on JIRA. So I went ahead and rearrange them here in the email threat. Good. Okay, so well and, and I think it's a this is a this is already a worthwhile conversation for us about. Hey, how should, for me, the, the one you put up as blocker is is, well, in the sense that it makes the UI ugly, because it doesn't stop me from using the product. It just renders really badly and it's a very early page that I see this bad rendering on. So for me that was the that was why this one. And I'm, yeah, it was, it was uncomfortable because of the bad rendering I'm used to Jenkins usually looking orderly consistent. It's not always pretty it at least looks orderly and consistent. So, so then you were noting on the, these are let's see this is. Oh, this, this is the one that's the labels. Is that right the. Yeah, these are the drop down ones. Good. Okay, good. All right, so again you and I are sort of agreed here that this one is really uncomfortable. Oh, I lose functionality and some things. Yeah, this just outlined only affect the credentials plugin but I'm aware that the main integration or the note label plugin for example are affected by it as well because they use the same drop downs here. Right. Okay. And then, then your idea of this, the tool tips when the reason I was so concerned about the tool tips one is that it's a, that's a place where it's without that hint it's really hard to deal with. What does that cell mean that I'm clicking in that matrix of permissions and array of things so. So, but I think I understand your point here that you you're saying hey maybe we don't don't delay the LTS. I think your, your revisit gives us a good indication should we consider how we how we classify these things. And give ourselves regular status reports hey here's how we're doing on these on the ones that are classified this way. Yeah I think the matrix one is currently the only plugin that is labeled as as losing tool tips. I didn't find something else on JIRA earlier. On the other hand, I don't have such an older Jenkins release at hand at the moment to replicate it. But if I remember correctly if you hover over the columns of the matrix or plugin, you have tool tips what it does as well. So I'm not sure at least I don't know out of my mind, which kind of tool tips actually are affected here. Okay so so needs needs more discussion and more more investigation. I agreed fair enough. Yeah. So the columns of the matrix or plugin, like what each each permission does works fine. Okay. So, so then the next point of what I might call is disagreement would be the, the broken icons thing so share with us your your logic here and let's let's talk some about it. I also labeled major on JIRA, but I wouldn't say that as a major issue or actually a blocker, because the plugins affected by it, like I said, in the email post, do not use the API provided by Jenkins but the actual path of the icon. Okay, look into slash SVG slash or the 2424 or 4848 directory for the icon. Yeah. And Jan started the PR, I think, in November last year. And around that time I started to migrate a few plugins away, according to my GitHub profile I may graduate over 70 plugins by now. And this is more a more an ongoing task, I guess, rather than something you have to do before this can be shipped. I also published a blog post of an old blog post upgrade guide about it on Jenkins I owe how to go about it in groovy and in jelly. So this is not something that is hard to migrate from. So then in this case it would be a situation where we identify things that have the issue and use the fact that they have the issue as a way of flagging. Hey, this is one that if if we don't. If this one, this plugin does not get a new release to include this change, then when it's when this release when the LTS comes available that does this, it will no longer display those icons. It will, because it was depending on non API based icon access. Yeah, I have addressed these issues in a few other plugins as well, but I basically went the way to go through the repository permission updater adopt the plugin perform a release and remove myself from it again if it's a plugin from 2012 or 13 or something that is definitely not no longer maintained. This is as easy as updating the icon path to the API. Good, good insight so so now we're having having conversations about this one in terms of, are there other alternatives for us. The tables to divs upgrade went through a similar process and it's been a rather painful experience in with with 30 or 40 open bug reports currently on tables to divs, but I, I think you're right we don't really want to resurrect an eight year old plug in just to make this change when we weren't confident it will matter to users. So there's a there's a balance there that I'm not sure how to how to strike I'm open to others, opinions and ideas or suggestions on it. Okay, my idea would be something like we didn't choose LTS baseline yet, but once we have created the email thread and her and our own the step of the release candidate creation, we could highlight it and make sure people actually report these issues. So they can be addressed before the first official release lands in place. And that would be one way to highlight it and give giving it extra attention, because we can only take care of plugins with our own Jenkins the eye in which our public prior plugins must be addressed separately by the people themselves. Yeah, I think that's a good idea, but the risk we run there is that there aren't very many people necessarily running the weeklies and think many people will not discover these bugs until the LTS is shipped. I noticed, you know, they're just recently we, we found two issues that have been a weeklies for a very long time that were not noticed until they were delivered in an LTS release. So, one of the things that I did in the guava migration was to proactively enumerate all of the plugins that we're using the old guava APIs, so I made a big list of them. And then from there, I was able to, once I had that entire list, I was able to go through them one by one inside. Is this something that we care about or not. And if we do care about it, then I opened a poll quest to update the guava usage. And if we didn't care about it, then that went to a separate bucket where we explicitly decided that we're not going to fix this. But I think it was important to actually go through them one by one, and make that decision consciously, rather than just waiting for a user to complain about it months or weeks later. So I think that was that was really a useful exercise that I did when I was doing the guava work. And now, Alex, you had noted that they weren't using the API. So is this a searchable detectable condition? Like, I've seen cases where Felix did reports of bugs to plugins that were detected to be using tables that contained UI. Is this a similar kind of thing where it's feasible to search or does this require a human being to actually look for it? So you can actually query cs.github.com for like having PNG or GIF or the typical older icon paths and a regex clause and use that as starting base. Okay, all right, so it is, so it is a detectable thing. Good. Okay, so then, as you had suggested, we could start tracking, start tracking this thing in Jira and say, All right, here's this, we know this issue exists. And then, then we've got the risk. Yes, plugins that are abandoned may not get a fix, right? They, but we at least we know then. Good. Okay. So, and Alex, would you be willing to coach on how to do those searches or is it is it as simple as look for, look for PNGs or SVGs that have the 24 by 24 or 36 by 36 in their string? Yeah, I mean, it's the input is rather simple. You can either use the GitHub search or if you are in the technology preview, you can use cs.github for that and search all repositories on the Jenkins CI organization. And yeah, then you can take a look for the last SCM activity and if it was in 2014, you can likely say the plugin is abandoned and rank it more down the list on Jira. Excellent. Okay, so you say that was cs.github.io or cs.github.com. Yeah, okay, thanks. All right. So that feels like a very reasonable approach to me. Let's let's set ourselves the objective that we're going to do a detailed review. This, I think this is a lot healthier than one of my thoughts was, Oh, should we just put all the pictures back. But then the problem with putting all the pictures back is now we never know how to get rid of them, right? Whereas what what you've done this way, starting down the process, let's continue it and identify things that have the issue and then see if we can find people to help us work on them. Yeah, the process is rather simple. Behind the ease of migration is the Jenkins IO blog post I linked there how to go about it to do in Jelly and in Groovy. Didn't have a Java example at hand at the time right off writing this, but like you can see the process is rather simple and doesn't require much work. Yeah, okay. Good. All right, so that that feels like we've got an idea here for that one I like that one very much. Excellent. Okay, so, so pulling up to the higher level question. Are there any strong objections to the idea that we should consider taking time to work on these regressions before we choose the LTS baseline. Am I missing something by by not holding us to the rigorous cadence that next Wednesday we will choose an LTS baseline. Okay, I'm taking the silence as a scent that's a dangerous assumption. Are you all okay with me assuming a cent. No, I agree, Mark, I mean, I think it's good to take the time to make sure that the selections that we have to choose from are all worthy selections with a low rate of regression. So I think that's a great idea. Yeah, I think postponing it for a couple of weeks is fine. The RC creation of the last three releases and even up yet. So we have at least four more weeks until the first point release arrives. So, yeah, giving us more than a plenty of time to address the outstanding blockers. Good. Okay. Excellent. So just the difference between the two weeks and four weeks with two weeks it just we reduce a bit the time that we are keeping exactly the same schedule as usual. With the four weeks we are delaying the next LTS version. See and we want to speed up a bit of things. Good. I was assuming that the two weeks was like, that's a good point I was assuming two weeks applied across all releases. All releases this this year. So that was what I was assuming. But that may if we go beyond two weeks we now may have used up the cushion that we have so that the cadence is 12 weeks. So we use 48 weeks of the year a week is 52 weeks. If we, if we use more than two weeks we may actually spill over and, and risk that we're end up doing a release late in December I haven't run the calendar yet for that so. Vodex got a good point. What, what does it mean just perhaps do not care too much about the number of LTS per year. It's not that important. Just about the number of things that we are doing per year. It's not a big deal. What is more concerning is what we want to do. We want to postpone the LTS release or just the selection of LTS release because between the LTS selection when we decide which weekly we are taking it will influence the RC the release candidate and then the LTS. We have some times between the selection date and the first RC it's four weeks. If we are following the four weeks proposal there, we can do the release candidate the same day as the selection, perhaps not a good idea, perhaps it's better to delay the LTS release as well. It just about is kind of thing that are also other option we have there. Good, good point so my assumption was, I was assuming that the delay applied to everything. It was an intentional moving of the whole calendar. And it's a good point but I could that we could choose something different but for me it was much easier to think about not attempting to take time out of other things. And for the information there, the release candidate is also something where we are pushing the backport. So for security release, the backport of security release in this case it will not be a security release, but if you find some regression you want to correct, you have to backport them to the release candidate. Meaning if we are doing that the same day, it will be impossible. There will be no time to review the thing. If it's only two weeks, it means that we have only two weeks left for the release candidate to receive the backport. In the case we don't want to change the LTS release time. If we want to just postpone everything. It's the same process as usual. It just that the calendar need to be updated this kind of thing. Good. And my bias is do the calendar update without attempting to compress anything else. Are there others who have a different opinion there who would lobby no we need to, we need to do something else other than just move everything. Or four weeks later to, to allow us time to get a more stable weekly release. Okay, so I think, I think we'll continue discussion there. We'll continue discussion in the email thread. Certainly our release officer Tim has to be, has to be consulted. And so this is, this is not a decision. This is just a proposal, and, and we we work from that proposal. Any other refinements there that I need to be need to be noting in the notes or that need to be expressed here. So perhaps if you want to have close to zero impact in the long term, we can propose to do a dot for release the next time, and to have the next LTS being just dot one plus the two. So long time support of two months instead of three months. That could be another approach so that in six months there will be no impact at all. I see what you're saying right so if, if calendar cycles are somehow important or are important in ways we didn't realize we could release 2.332.4 in June. And then could release. Let's call it 2.3. 5x. It's not going to be that big but let's call it that one in July, then dot to in August and then September, it is the next uses a new baseline. Did I understand what you're saying about it. Exactly. Okay, just to be clear, no strong opinion just explaining the different option we have some potentially are better than others. Great. Okay, good. Anything else on this topic. Okay, then the other topics we had were really relative to propose pull requests for a script security improvement. I'm not sure anybody on this call has comments to make. Are there, I guess, Vada are there things with this one specifically that you would like to discuss here. Perhaps just hide the date of the pull request. It's a pretty hard one. So just for the information there, I don't know why the topic is coming there in the in the meeting but anyway, that pull request is to improve a bit the user experience in script security, especially about the approval tab. The approval tab currently is mainly that you have to approve it once and the hash of the Apple script will be stored. Nothing else, no metadata. So you don't know where, when it was approved, why it was approved by who and so on. So with this pull request, you can see with the screenshot there. There's a version where you have more information, more metadata to help the administrator to decide where they want to reduce the number of approval to remove some approval in particular, and also to have the possibility to revoke one approval or multiple. Currently, you have to remove everything. The other option is to go to the XML file and to remove the thing manually, which is not really a great experience. So that's a bit the idea with that pull request. And the main issue is that we discovered the bug in the pipeline approval logic. It's about the real approval of things. You can see the detail with the ticket we open after that pull request. It's mainly a bug that is not occurring a lot in practice nowadays because of the lack of features, but with this new approach, we are revealing more than that bug to the people. So that's a bit annoying and that was the request to correct the bug before going forward with that pull request. That's a bit. So, so there's more there. I thought one of Jesse's objections here was, he wasn't confident that we wanted to do anything more on this because his preferences know when should ever approve any script. Right. Am I overstating Jesse's case. I think it's a regret from him to have the script approval feature in general. Okay, because because this this truly does open some risk that now you're allowing certain certain forms of execution that may not be safe inside your Jenkins controller. All right, so I think that just stays as it is then I'm not sure we need any make any further progress there. Any other topics for today I'm hesitant to talk anything about upcoming UI improvements without young and Tim here. And without really I did his code coverage plug in work I think continues I believe his students are active and he's working making progress. All right, if no other topics and I'm going to go ahead and propose we end the session and I'll make a recording available within the next 24 hours. Anything else that we need to discuss here today. Okay, thanks everybody just one point I forgot. Due to the situation we have nowadays, what I would propose is that we are stopping merging new feature in Jenkins call until we have a more stable solution stable weekly. So that we don't have a new introduction of bugs regression while we are correcting the existing one. If we are not doing that and continue merging things, we are just in a situation where we cannot really stabilize the stuff. So just an idea there probably be very careful if you merge something. He could add new regression that we have to correct and due to the fact that we know that it's currently unstable, we have to correct a lot of regression. It could be better to not add new one. That's a bit what we were doing in the past before security release, do not introduce new thing to prevent people to have the choice between stability and security. In this case, it's mainly between stability and features. So at the end, create the same. So prefer to delay new feature merges in favor of work on stabilization. Yeah, exactly. It does not mean that you cannot open new pull request review pull request, but just it's about the merging of things, especially big pull request. That could be a bit annoying. Yeah, but to add, but to add our products, the question is actually a good idea that maybe need to be expanded to further LTS election to not pull in new features, right before the next LTS based on the selected to focus on stabilization and not to introduce many issues in the first release of the next LTS candidate. So it was a bit, I will say implicit in the past, when we had the selection coming close. It was mainly we want to have at least that feature. So stop introducing new feature for the next weekly to be sure it was a bit stable. So your point is just not explicit in the dark, I think. But yeah, it's just a matter of good habits I will say in general. Good. Yeah, so make the current implicit behavior more explicit by documenting it by describing it. We've had that we've had that behavior right we see, we've seen tables to divs was merged into a weekly one or two weeks after LTS baseline was selected to give it maximum exposure. Likewise with the UI changes that came in 2.332 and the UI changes that are now that each arrived just a week after LTS baseline was selected so we had maximum exposure. So yeah, I think that's good. And let's we can certainly describe it in more clear clear clear terms if it's not already described there. Very good. Thanks. Any other observations or points we need to include in the notes. Oh, I've got a chat message here. Oh, great. Okay. Good. Thanks everyone.