Cedric Blancher via Cygwin writes: > We are VERY concerned that this plan will backfire. Basically nothing > here works right now, and we are still trying to determinate the root > causes. Plural. Too many bugs.
I've said it before, but if you really didn't recognize it until now: Cygwin is a following a rolling release distribution model, which means it can literally break at any time and for any length of time. Now, I've also used (and am still using, albeit on a smaller scale) Cygwin in a corporate / production environment (which I belive is what you are talking about when you say "here"), so these things are in my view necessary to even think about such a deployment: - independent (internal) access to all sources and binaries - a separate test and build environment - periodic test builds of packages and Cygwin itself - full control over the package selection including version locks and the ability to roll back single packages or even full installs In the above scenario you could either decide to hold off on an update or fork and fix it yourself. If you can't do either of that, then sorry to say: this is first and foremost your problem and you get to keep the broken pieces. Secondly, correlation is not causation; you have AFAICS not yet shown that there is a bug in Cygwin. Even if there was, you still do not get to command what the project does to handle that situation. If you want to help it along, at least send actionable bug reports, reproducers would be better, better yet would be patches. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
