On 04 Nov 2017, at 10:49 PM, Helmut K. C. Tessarek <tessa...@evermeet.cx> wrote:
> Let's say I have a patch for the current version of Apache: 2.4.29. What > now? I have to get it first into 2.5.0 or trunk, which might not even be > compatible? Yes. > So I have to figure out how the code in trunk works? Yes. > Then I > have to do what? Learn SVN and how to use the STATUS file? Yes. > I can't even > commit to a branch (let alone the fact that feature banches do not > exist) without a userid on svn.apache.org. Yes. > All I want to do are 2 steps: Commit the patch to the 2.4.x branch (as a > new feature or patch branch) and send a PR. (X reviewers are required, > and boom it gets merged. Don't forget all the nice CI that can be > triggered before or after the merge.) If you aren’t willing to do the four things you’ve mentioned above, your code has pretty much disqualified itself from consideration, and what you want is largely irrelevant. Apache projects are not drive-by code dumps. You need to care about the community around you who uses and develops this code. Is your code complete and bug free, so other developers aren’t burdened with cleaning up after you? Does your submission follow the established conventions, so everyone else doesn’t have to constantly figure out what special flavour-of-the-month process you’re following today? Did you take the time to figure out how the documentation works, so that people know your code exists and how it works? Have you made your code work in the next development version of httpd on trunk and soon v2.5.0, and not just the current one, so future users don’t see your code suddenly vanish in the next version? What about the last version of httpd, is it relevant there too? > While I still learned how to use CVS and SVN (which I also used in > personal projects and hated btw), used other ones like clearcase for > huge projects (like IBM DB2), the new generation of developers did not > and - believe me - they don't want to. (I definitely wouldn't want to, > if I had ever be involved in a project that used git.) > > A move to git doesn't mean that this project will gain hundreds of new > developers over night, but it might give you a chance to streamline the > current development *and* release process. The rest will follow. We have a development and release process that has been in place and served us well for almost two decades, and most of the popular release processes that are in vogue today are just more complex versions of our existing workflow. I would recommend learning how our release process works before suggesting it be replaced (with a workflow not unlike our existing). Every project I’ve been involved in, from Apache C projects to Maven based Java projects, to other open source projects like freeradius and gstreamer, has its own set of conventions and ways of doing things. In each case I tailor my contribution to fit the existing project, I don’t expect the project to rearrange itself around me. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
