Hi markewaite ! Thanx a lot for reply! I think I did what you suggest: "...tap-plugin/pull/38 does, and that is opened (via its closed predecessor since december 2022. The PR is battle tested in production for longer then year."

But most likely I miss something. The plugin from ci.jenkins.io (vanilla usptream) suffers the issue. My fork (source of PR) have it fixed. If you have better advertise of binary .hpi from my fork, can yuo please elaborate a bit more?

If you're already using the build of PR-38 successfully, then that's all that I was suggesting.

Thanx! Yes, we have PR38 in production since before the PR even existed. From its first stable version, over all reviewer's nit up to currently rebased (over recent CVE). In original PR were also some screenshots, but they ar enow a bit obsoleted. The PR does it jobn pretty well.

I would be probably ok living from fork, but we have also very public version of the jenkins, and that runs only from official repositories. Gosh, every time I have to switch to that public instance, the digging in results become somehow harder.

Thanx a lot for suggestions!

I haven't had time to review it again.

The last time I did there were still usability issues, the CSS could be changed to match Jenkins', and there were cases where I thought users could get confused. From what I recall the unit tests were missing too but I offered to try to copy the tests from active choices that are newer and use Jenkins harness code.

That was pointed out in a review feedback, but the PR OP did not agree, which created an impasse.

I wanted to take some time to review it again taking into consideration OP's point of view, and write tests and propose the CSS changes.

My reviews were taking some time (mea culpa). The PR OP then created an issue to become maintainer of the plugin and to merge the PR. I agreed my reviews were not as fast as some users coul be expecting (I am a volunteer after all).

The OP request for maintainership was rejected. I updated the pom.xml to fix spotbugs warnings, then liaised with CloudBees to fix a security bug (xss).

A new version was released, and I started looking at bugs in the plug-in.

As far as I understand, this issue is a new feature. I was replying to this issue first whenever I could as the OP was pushing for their change.

But given the impasse, I prefer to focus on bugs and performance first. Note, however, that running code for a long time in your environment does not really mean it is generic for all users, nor bug free, nor perfect, so it is normal to go through some discussions to adjust the code (if it works for you but not others, then an impasse is created and a maintainer could in theory overrule and modify or close a PR – I prefer to reach consensus or find compromises, although slower).

Bruno

hi!

Nice to see you are alive! Really!

I agree with everything you wrote here. When the review is slow, even super slow, then it is ok. But it must be somehow clear from the discussion that it is slow, not dead.

The only exception are tests: I understood they can be added later and you do not insists on them immediately. I admit I have no idea how to do a proper JS interactive tests with jenkins in background, but if it would be clear that you insists, I would at least try.

The issue (both this and (mainly) the https://issues.jenkins.io/browse/JENKINS-73483 ) can be considered as new feature. But are not. Both are bug, because the plugin can not be properly used without both of them. Still, you are main maintainer, I honour that, so lets consider that as features.

I definitely agree on discussion, but first there must be someone to participate in discussion. Slow maybe, but clear that it is not stalled.

Also I definitely agree on agreement. Really. Whatever you suggest, I would try to oncorporate (if it will be still doing what it shod be).

On projects, where maintenance is rare, even sporadic, I have bad habit to bring PR first, issue then. It usually pays off, but not always (as we see here).

year in production indeed do not guarantee it is generic for all users, nor bug free, nor perfect, and IT IS indeed ABSOLUTELY NECESSARY to walk it through some discussions! I supported to much products to argue on this. But it means that the feature was tuned, and that it have some target audience which is so happy to have it, that are rather running from fork.

Sorry for keep pushing this, I'm same volunteer as you are, only am still using those nots. It is too common in opensource world, that some really good features are rotting in various unknown forks serving jsut people who knows them, and very often even maintainers do not know about them. Where such features would nearly always benefit to all. If both parts would try just a small bit harder this would not be happening.
Also I have seen death of to much good projects, just because maintainer disappeared. Then there is fork war, and one goes out again, but so much wasted energies....

Looking forward for your comments and suggestions.
J.

As decrypted from the kinow answer, the unittes were, and are blocker. Please next time, when you see long time active PR, which you do not disapprove, jsut highlight what you miss. People will be eager to follow. I had added first set of tests. Will add more. in meantime

kinow in this way I can continue to add any tests it needs, but that do not seem exactly right until we have agreement on impl.

The ball is now in your hand.

wou. Note: https://github.com/jenkinsci/tap-plugin/pull/38#issuecomment-2310971645 ; Shelly is Eclipse board member. They use tap plugin quite lot, eg: https://ci.adoptium.net/ ; and they already noticed thst PR. They can not run from random fork.

kinow as you keep pushing to master, and I keep rebasing. Can you please help with merging the PR, provide your own implementation (especially to https://issues.jenkins.io/browse/JENKINS-73483), or to close as no go?

Currently working on active choices, then will come back here. There is another issue in tap with higher priority too (see fix in latest release... one page is still affected by the issue in that release)

ok. TY!