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