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