I considered writing a similar post myself a few days ago, and I also think it is time for winp to be retired, but there are a lot of challenges associated with removing winp in favor of a simpler implementation using native Java process handling or simpler Windows primitives. The existing native implementation is highly tuned and battle-tested, with such behaviors as attaching to the console and sending literal Control-C events at the console level. I can't think of a good reason for this, but it is an example of the stereotypical two-page function described in https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ as a "hairy mess." I am sure the high-level objectives of tracking child processes and terminating them gracefully (for some definition of "gracefully") could be achieved with a rewrite using simpler primitives, but I also fear this would introduce a high risk of regression—if anything, I suspect many consumers implicitly depend on the existing implementation details and that any change in behavior (even a justifiable one) would create some pushback for at least a subset of users.
While we do run basic test automation on Windows, we don't have much in the way of test automation that tests the edge cases of native process handling. That, coupled with the general difficulty of reviewing rewrites, means that we'd be relying on users of weekly releases to test the rewritten code and report issues. And the failure mode here is subtle: mistakes in process handling might not cause outright failures, but might cause leaked processes to accumulate over time, delaying the discovery of the problem. While we do encourage first-time contributors, I think it would be tricky for a first-time contributor to submit a rewrite like this, because potential problems might not be discovered for several weeks, at which point the motivation (or funding) to work on the project might have decreased. While not insurmountable, I think these challenges have caused me to have a preference for incremental improvement rather than a rewrite, especially given that the interest is coming from a first-time contributor. As annoying as it is to delve into an unfamiliar codebase and write a CI/CD script for an abandoned codebase, at least the problem is well-defined, and we can be assured that the result won't break existing use cases. With a rewrite, that risk increases and I think we would have to be very careful about review, testing, and (potential) regression management. If a long-time contributor like yourself proposed to do such a rewrite, I would feel more comfortable with it, especially if that long-time contributor promised to be around to deal with any regressions. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjqTOUehtZtVSvCL2T0g_a2guvektiy%3DTB2WCx6XsXi70g%40mail.gmail.com.
