On 10/27/2015 03:26 AM, Graham Leggett wrote:
On 27 Oct 2015, at 12:40 AM, Tim Bannister <is...@c8h10n4o2.org.uk>
wrote:
That may not be easy. You need to find someone who'll be
interested in an idea or patch, and has the time to review it.
Plus, the community as a whole to agree it's a good idea, or at
least not actively oppose it.
I wonder if workflow would be improved if we had named
maintainers for particular parts of the codebase - for example
individual modules? Not necessarily to do all the work, but to
take primary responsibility to see that your ideas don't just
fall through the gaps and get ignored?
How does the word “sponsor” sound?
It rhymes with “bureaucracy”. :)
Remember the end goal is to improve quality without causing
stagnation,
I agree that adding process always carries the risk of red tape (more so
when people like me, outside an organization, propose processes for
people inside it). We all want to avoid a stagnant codebase. I would
also like to de-stagnate the communication, that's all.
and giving people the impression that they need to ask a “sponsor”
first who may no longer be involved with the project will cause that
stagnation.
My first thought is, "then don't give people that impression." To me,
Nick and Tim's suggestions sounded more like "community liaison" than
"code owner".
The most exciting work on httpd for me has been Christophe Jaillet’s
memory optimisation patches. With each patch the code gets cleaner
and the server gets faster. We need more of this kind of stuff.
How would you improve the process and encourage those sorts of patches,
then, from someone who _isn't_ in the httpd committers list? It seems to
me that optimization needs to be done by experts in a codebase, not by
newbies. And code cleanup is difficult when you don't already have a
clear direction to push the code in.
--Jacob
