It be disheartening if one has pulled to fix one thing and another
committer fixes it under another huge fix without collaborating with one.
This happens occasionally with superstars and it is enough to stop new
committers contributing at all.
Steph


On Fri, Oct 19, 2018 at 9:44 AM Malcolm Upayavira Holmes <u...@odoko.co.uk>
wrote:

> My wayback was to 2002/3, when I was playing with Cocoon. Their CLI was
> implemented as a large monolithic Java class, and quite impenetrable. I had
> spent an age working on a large refactoring that made it much clearer and
> more usable. Unfortunately, it also broke backwards compatibility.
>
> Vadim Gritsenko, who was mentoring me refused to accept this patch. He
> told me to do it in small reversible changes. This was really annoying at
> the time, as I had spent so much time on it. Accepting his feedback, I
> started again. This time, I presented the same change, as a sequence of
> smaller changes, each of which he accepted. The net result was the same
> refactoring, in a way that he, and the community could absorb. Oh, and the
> new version was back compatible.
>
> That, for me, was a very powerful lesson in how open development can work
> effectively.
>
> Upayavira
>
> On Fri, 19 Oct 2018, at 2:10 PM, Jim Jagielski wrote:
> > Large code drops are almost always damaging, since inherent in that
> > process is the concept of "throwing the code over a wall". But sometimes
> > it does work out, assuming that continuity and "good intentions" are
> > followed.
> >
> > To show this, join me in the Wayback Machine as Sherman and I travel to
> > the year 1995...
> >
> > This is right around the start of Apache, back when Apache meant the web
> > server, and at the time, the project was basically what was left of the
> > NCSA web server plus some patches and bug fixes... Around this time, one
> > of the core group, Robert Thau, started independent work on a re-
> > architecture of the server, which he code-named "Shambala". It was
> > basically a single contributor effort (himself). One day he simply said
> > to the group, "Here, I have this new design and architecture for Apache.
> > It adds a lot of features." So much of what defines httpd today can find
> > its origin right there: modular framework, pools, preforking (and, as
> > such, the initial gleaming towards MPMs), extendable API, etc...
> >
> > In many ways, this was a large code drop. What made it different is that
> > there was *support* by the author and the community to work on
> > integrating it into the whole. It became, basically, a community effort.
> >
> > Now compare that with a different scenario... Once httpd had picked up
> > steam, and making sure that it was ported to everyone's favorite *nix
> > flavor was important, SGI had done work on a set of patches that ported
> > httpd to their OS and provided these patches (a set of 10 very large
> > patch-files, iirc) to the group. What was clear in those patches is that
> > there was no consideration at all on how those patches affected or broke
> > anyone else. They rewrote huge swaths of code, optimizing for SGI and
> > totally destroying any sort of portability for anyone else. And when we
> > responded by, asking for more information, help with chatting with their
> > developers to try to figure things out, and basically trying to figure
> > out how to use and merge this stuff, SGI was basically just silent. They
> > sent it to us and that was the beginning and the end of their
> > involvement as far as they were concerned.[1]
> >
> > Way, way too many large code drops are the latter. Hardly any are the
> former.
> >
> >
> > 1. I have paraphrased both the Shambala and SGI events
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Reply via email to