On Thu, Aug 14, 2014 at 8:48 PM, Óscar Fuentes <[email protected]> wrote:
> The bug is about an specific CMake module when used with certain input > and the zone touched by the patch is several years old, so we can assume > that the problem is far from being a common one. There is no reason for > hurry. > I have no interest in getting in a long philosophical discussion on the matter so this will be my last post... As far as there being no reason to "hurry", I can't build my program today with the bug, the patch fixes the bug for me. Specially with cmake upstream, I've found bugs that have been reported for over a year without any action upstream, so sorry if I'm in a "hurry". They seem to work on what they care about. Which is unfortunate since overall I really like the product and much prefer it to autotools. OTOH when you apply a patch you are forking the project. This has severe > consequences for the community (and creates extra work for the > maintainers.) Right now MSYS2 CMake has a single, simple patch which is > related to MSYS2 itself, while your patch addresses a CMake bug which is > not MSYS2-specific. The moment Alexey applies it, he is taking the role > of CMake maintainer. Multiply this by the hundreds of packages MSYS2 > has... > I'm a Fedora and RPM Fusion maintainer and I maintain dozens of packages (I really need to count it up sometime). Probably about 50% of them require some level of patching to build properly or to comply with the packaging guidelines. This is pretty normal. Some of them I get upstreamed, others they have no interest in, life goes on. If you're going to limit yourself to a distribution or packages without any disto level patches you're going to have to come up with your own distro and it will have a very limited selection of libraries and programs. Calling the addition of a patch a fork of an entire project is a rather extreme viewpoint. IMHO MSYS2 should limit itself to patches required by the specific needs > of this environment (and perhaps some MinGW-w64 patches.) Broadening the > scope is a recipe for maintainer burn-out. Sometimes maintaining patches, especially large ones can be a PITA, which I try to avoid, once again, life goes on. At the end of the day it's about having access to software that does what you need it to. Having a canonical upstream distribution that doesn't work serves no one. Thanks, Richard
------------------------------------------------------------------------------
_______________________________________________ Msys2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/msys2-users
