Trying to keep this short ... Well I think it's important to keep the others in the loop no matter what it's about. Especially if it's about code.
The probably most extreme example is the Edgent incubating project. After IBM pulling the plug, it's sort of only me still being involved. So right now I have a project, I know 100% of the build, but about 10% of the code. Now people are asking me questions, I just can't answer, which is damaging. From my point of view, it feels like a huge code drop (even if I know it wasn't). My 2,5 cents, Chris Outlook for Android<https://aka.ms/ghei36> herunterladen From: mike peoni <mapster1...@gmail.com> Sent: Saturday, October 20, 2018 7:01:47 AM To: dev@community.apache.org Subject: Re: Why are large code drops damaging to a community? In talking about https MyOpj.VisibleEh would this be appropriate for a large Apl so you wouldn't raise flags and further more i put 2 Apl on face book just anonymized on my page then they put up a developers page and i liked it and i went to close my account and my Apl where there In the dev, page and i was told I would forfit my data I'm deeply concerned because they tried to issue a visa for a substantial amount but not what the Apl worth they have been negotiating as of now i don't know where i stand "please comment as to the dev, page Apache is neg, on fees. As far as big data goes if th framework was done right there shouldn't be a problem with it intergrating unless it's branched invasively. On Sat, Oct 20, 2018, 12:41 AM Myrle Krantz <my...@apache.org> wrote: > Hey Jim, > > I’d say they are a symptom *and* a problem. But putting that aside, can you > unroll what you mean please? > > What was that code drop from SGI a symptom of? > > What did Robert Thau do (or not do), before during or after to ensure the > success of httpd? > > Best Regards, > Myrle > > On Sat 20. Oct 2018 at 00:28 Jim Jagielski <j...@jagunet.com> wrote: > > > I would say that, in general, large code drops are more a *symptom* of a > > problem, rather than a problem, in and of itself... > > > > > On Oct 19, 2018, at 5:12 PM, Alex Harui <aha...@adobe.com.INVALID> > > wrote: > > > > > > IMO, the issue isn't about large code drops. Some will be ok. > > > > > > The issue is about significant collaboration off-list about anything, > > not just code. > > > > > > My 2 cents, > > > -Alex > > > > > > On 10/19/18, 1:32 PM, "James Dailey" <jamespdai...@gmail.com> wrote: > > > > > > +1 on this civil discourse. > > > > > > I would like to offer that sometimes large code drops are > unavoidable > > and > > > necessary. Jim's explanation of httpd contribution of type 1 is a > > good > > > example. > > > > > > I think we would find that many projects started with a large code > > drop > > > (maybe more than one) - a sufficient amount of code - to get a > project > > > started. When projects are young it would be normal and expected > for > > this > > > to happen. It quickly gets a community to a "thing" that can be > added > > to. > > > > > > It obviously depends on the kinds of components, tools, frameworks, > > etc > > > that are being developed. Game theory is quite apropos - you need a > > > sufficient incentive for *timely* collaboration, of hanging > together. > > > > > > Further, if your "thing" is going to be used directly in market > (i.e. > > with > > > very little of a product wrapper ), then there is a strong > > *disincentive* > > > to share back the latest and greatest. The further from market > > immediacy > > > the easier it is to contribute. Both the Collaboration space and > > > Competitive space are clearly delineated, whereas in a close to > market > > > immediacy situation you have too much overlap and therefore a built > in > > > delay of code contribution to preserve market competitiveness. > > > > > > So, combining the "sufficient code to attract contribution" metric > > with the > > > market-immediacy metric and you can predict engagement by outside > > vendors > > > (or their contributors) in a project. In such a situation, it is > > better, in > > > my view, to accept any and all branched code even if it is dev'd > > off-list. > > > This allows for inspection/ code examination and further exploration > > - at a > > > minimum. Accepting on a branch is neither the same as accepting for > > > release, nor merging to master branch. > > > > > > Now, the assumption that the code is better than what the community > > has > > > developed has to be challenged. It could be that the branched code > > should > > > be judged only on the merits of the code (is it better and more > > complete), > > > or it could be judged on the basis that it "breaks the current > build". > > > There can be a culture of a project to accept such code drops with > the > > > caveat that if the merges cannot be done by the submitting group, > > then the > > > project will have a resistance to such submissions (you break it, > you > > fix > > > it), or alternatively that there will be a small group of people > that > > are > > > sourced from such delayed-contribution types - that work on doing > the > > > merges. The key seems to be to create the incentive to share code > > before > > > others do, to avoid being the one that breaks the build. > > > > > > ~jdailey67 > > > > > > > > > > > > > > > On Fri, Oct 19, 2018 at 6:10 AM Jim Jagielski <j...@jagunet.com> > > 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 > > > > > Outlook for Android<https://aka.ms/ghei36> herunterladen
