On Thu Jan 30 2014 at 5:25:57 PM, Markus Hitter <[email protected]> wrote:
> - I've talked to many people by email, IRC, here, watched other > conversations. There's barely an acceptance problems actually exist. > Instead people try very very hard to find reasons for avoiding changes. > How can a piece of software evolve if the very first goal is to not > change it? > I'll take a bit different approach to commenting on this than Niels did :-) Note I didn't look at your patches, and will not get involved in Debian packaging right now; maybe in a few weeks. Consider this a rant. This type of question comes very often :-) and I can bring up two reasons: - Changes can break stuff. - People have other things to do as well. Unless there is a corporate sponsor backing exactly the kind of evolution you may want (so that there are people working full time on the evolution in the direction you may want), and unless changes you submit are noninvasive to other people's uses for GNUstep, that's how it's going to be. //// end of tl;dr summary. rant begins. //// This is not to discourage contributions, but it's a realistic look at why the responsiveness of the core contributors may seem a bit off-putting. Is your change easy to understand? Is it going to break an important contributor's use case? - The project doesn't and can't have a central hierarchical management structure, so every active contributor counts. - Contributors have a limited amount of time they can and/or are willing to spend understanding and fixing incoming patches. - Contributors have a limited amount of time they will invest in writing code; they won't necessarily be interested in spending this time researching what your problem entails, or writing code that serves just you, or figuring out how to fix an invasive patch, etc etc. My only occasion where I solicited a patch from a visitor to the mailing list, and where I actually received it, and where I actually tried to apply it -- well, it didn't cleanly apply and if it did, it would break several things that were simply commented out of certain configure and makefiles. Instead of testing whether code is compiling for the target platform, contributor instead provided a patch that disabled features blindly. And it took a while to figure out a proper way to apply these changes without breaking these features on x86 Linux, x86 FreeBSD, and many other platforms we support. Even pulling in changes is work. GNUstep isn't a day job for most active contributors; even where it is, contributors focus on solving a particular area and use case they need. You've mentioned gnustep-make. Whenever you touch gnustep-make, you risk breaking it for everyone for whom it currently works okay. That means any work on it must be very careful, and whoever reviews your patch must ensure nothing will die by applying your patch. That means work. Not only that, but it means work under GNU/Linux. Not only that, but it means work under Debian GNU/Linux. Maybe under several releases of Debian GNU/Linux? What about running under Windows? What if your patch breaks it? (I have not looked at your patches; I doubt it does. This is just a hypothetical.) Never underestimate the power of human laziness and disinterest. :-) ///// Side note regarding your latest email that came in as I was writing this one :-) You have mentioned that you're trying to satisfy a large portion of the open-source world (estimating people covered by the use case at 95%). FHS compliance is primarily important if you intend to send packages upstream. A lot of third-party software outside of repositories is simply installed in /opt even if shipped as .deb packages. Let's not lose sight of that either; just because a lot of people would be happier with FHS doesn't mean neat, easily available, easily buildable packages aren't the real goal here. We need FHS compliance -- but only to get the revised packages into Debian. :-) ///// Finally, I am personally thankful for your work on proper Debian packaging, and I personally consider it important. Thank you!
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
