On 2017-11-04 19:18, Graham Leggett wrote: > No, you expressed a definite unwillingness to follow our process, > which starts by creating a patch for trunk.
I think you misunderstood, at least partly. I don't really care, because I don't have time to contribute to this project anyway. I was just talking about why others _might_ not want to. Why would I do that, you may ask. The topics of VCS and release strategy came up several times during the past years and the discussions never really changed anything. If I really wanted to start writing code (new features, internals, ...) for httpd, I'd be willing to learn the process. However, I would not do the same for patches. If I were to find a bug and had a patch for it, I'd not want to follow your process. I'd send off the patch to the list and you can do whatever you want with it. I would not be wasting my time to learn a tedious process for submitting a patch. And I am not talking about core developers, but people who find something, fix it, and want to contribute their fix back to the project. A lot of projects live because of these casual contributions and Apache httpd would attract more devs for these kind of contributions with an easier process. That's all that I'm saying. >> Yes, most projects have their own conventions and yes, I tailor my >> contributions towards their processes as well. > Except in this case. Yes and no, as mentioned before there's a difference between core developer, casual contributor, and one time contributor. On the other hand, my hint towards CI was not without reason. I do not know your current CI pipeline or if you even have one, but working with git and branches, triggers and plugins makes the process very convenient. Although I'm sure you can get this done with SVN as well. How often was a release thrown out because some tests failed after tagging? If you used CI and after every commit or a merge to a certain branch the entire test suite were triggered (on all OSes/systems), wouldn't that make your job a lot easier? Just saying... ...not forcing anything on you... (To be clear, this is my opinion, not telling you what to do.) > Unfortunately you’re pointing out the obvious. There are a number of > ways of doing things, and projects make different decisions to meet > their needs and objectives. That way is sometimes not your favoured > way. If we constantly changed our process, we’d not serve our > community, and ultimately serving our community is the point. As you mentioned before, you haven't changed anything for the last 2 decades, so talking about changing something constantly is a bit of stretch, isn't it? I've worked on IBM DB2 were coding a line item took maybe a few days, but getting it into the source tree took up to 6 or 8 weeks. That process was necessary with 2,500 developers and 40,000,000 lines of code. So, I do understand that certain processes make sense, some others are just bureaucracy, and others exist because people just do not want to change them. I can also tell you that I had patches available for other projects and I did not contribute them, because I would have had to create yet another userid for another system, or sign up for another forum, or subscribe to another mailinglist - just because there was no way to do a fire-and-forget method of submitting a patch. Please note, there are differences in contributions and how much a dev is willing to do for each of them. "I fix something and they want me to jump through hoops? Sorry, not with me." - This attitude is quite common, especially if it is a one time contribution. -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */