On Sat, Nov 4, 2017 at 11:43 PM, Helmut K. C. Tessarek
> 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.
Possibly, Apache httpd isn't really doing marketing either..
Anyway, your opinion on our weakness in attracting new contibutors is
not to be neglected.
You seem to point to a complicated workflow, and I don't think it is
(really) once you are a committer, so maybe the complication is to
become a committer?
[quote from the other message]
> 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.)
I read this as an easier access to or better consideration of
pull/merge requests (à la git-hub/lab), am I correct?
Our github mirror allows this already, but we may not be good at
treating them quickly enough (I try from time to time, but there are
requests on our mailing lists and bugzilla that busy me and each
How about if this requests were (auto-)routed to our dev@ mailing list
(in both ways, if that's ever possible), do you think it will help
git-ers to contribute more?
It shouldn't be a matter of the used SCM (ISTM that committers can
already use git to commit to httpd), and I don't feel that our
branchs' handling is more complicated than anywhere else.
Could you please elaborate on a concrete contribution procedure you would use?