2017-11-04 23:43 GMT+01:00 Helmut K. C. Tessarek <tessa...@evermeet.cx>:

> On 2017-11-04 18:25, Graham Leggett wrote:
> > 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.
> This attitude is exactly the reason why Apache is losing marketshare
> against Nginx.
> > 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).
> Seriously? You must be joking. Also, I'm not the one who suggested to
> replace it, but pointed out a few arguments for git, which was suggested
> by Stefan Priebe. Or the be exact, he asked "why not git?".
> > 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.
> Yes, most projects have their own conventions and yes, I tailor my
> contributions towards their processes as well.
> However, there are projects, which processes are too extrem and tedious
> and I don't contribute because of them.
> I did not suggest to replace your precious work flow, I only showed up
> why people _might_ be put off by it.

I agree with what Graham and Yann wrote before me, but I'd like to add some
info about committing code to the httpd project. I recognize that the
github model is handy to share code and get some credit for it, but in my
opinion with complex projects like httpd the majority of the time to change
even a line of code is spent in research and testing to avoid shipping
broken features or introducing regressions that impact users.

In the beginning it might seem cumbersome to learn the differences about
trunk and 2.4.x for example, but from my experience (I am relatively new to
the project) it is unlikely that a knowledge gap prevents you completely
from shipping new code, unless of course you want to change important core
parts like HTTP protocol handling or MPM internals. In these cases there
are a lot of experienced people that are willing to help and follow up if
the change is worth it, it is just a matter of asking to the community :)

New code can be easily submitted via a patch in bugzilla, discussed in
there and eventually see it merged (if the code/tests pass certain
standards) by one of the httpd committers. Credits will be added to the
commit to recognize merit, and usually good attitude and participation to
the dev community daily life leads to a committer account (as Yann said,
everybody is happy to see new people joining the project!). This is not
that different from what you can currently do in github, but I admit that
the "interface" is way less immediate and user friendly.


Reply via email to