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?


> So I have to figure out how the code in trunk works?


> Then I
> have to do what? Learn SVN and how to use the STATUS file?


> 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.


> 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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to