Hi all,
well of course there will be off-list development, if something new is donated
to the ASF.
I guess Myrle's point is, that for an existing project, features that are
communicated and implemented off-list and are brought back after some time is
damaging.
I fully agree with that assumption.
Of course, there is off-list discussion, but the important parts of these
events, discussions whatsoever always have to find their way back to the list.
I was driving my co-workers nuts in the PLC4X project, as one of them was
sitting directly next to me. When we discussed things I asked him to post a
summaries to the list.
As he didn't do it I usually wrote them for him and after a while started
responding with things like: "I will gladly discuss this with you, if you ask
it on the list" ...
I think in the meanwhile he got the hang of it and things are going smoothly.
Also whenever I got important feedback or discussed things outside the project
itself, I wrote summaries and posted them on the list, just to keep the others
on the loop.
The important thing is: Someone interested in a project should always be able
to follow the major directional discussion.
Off-list collaboration without timely feedback to the list, cuts off others and
that's not the Apache way.
Chris
Am 24.10.18, 17:43 schrieb "Alex Harui" <aha...@adobe.com.INVALID>:
This is just a nitpick, but it is the subject line that is bothering me.
Having a "no large code drops" mantra is not the same as a "limit off-list
collaboration" mantra which is different from a "no off-list development"
mantra.
For Flex, Adobe made something like 5 large code drops. It simply took so
long to clear the various chunks of code being donated to Apache through
Adobe's approval process that it was done in stages. In fact, if I had time,
the Flex/Royale community wanted it, and I could get Adobe to support it, I'd
bestow a couple of other large code drops to Apache. It is all pre-existing
code, but again, the subject line makes it sound like any large code drop is
bad, which is not true.
To say "no off-list development" could be construed as some limit on how
many lines of code you can write as an individual before making it available to
others to review.
I think the real key here is "off-list collaboration". There will always
be off-list collaboration, and I'll bet some really significant things can
happen at a hackathon. That should not be prohibited. I think you are simply
trying to express the notion that groups, especially groups defined by having a
common employer, don't do too much collaboration off-list before inviting
others into the conversation.
My 2 cents,
-Alex
On 10/24/18, 7:17 AM, "Myrle Krantz" <my...@apache.org> wrote:
Hey all,
I'd like to invite anyone with relevant positive or negative
experiences with off-list development or large code drops to share
those experiences. The ASF policy of "no off-list development" is
implemented in a wide variety of ways in various communities, but
there are still may be some things that we can agree are absolute
no-goes. I'd like to figure out what things we see as:
* You might get away with that once, but don't try it twice. That's
damaging to the community.
* Avoid doing that unless you have a really good reason that the
community has accepted.
* That has a bit of a smell to it. Have you discussed that with your
community?
* That's fine. You're helping your community.
* What a wonderful idea! Absolutely do that if you and your community
want to!
I'm hoping to put together a diagnostic tool for offlist development
that can help communities help themselves. Something similar to
Beck's Depression Inventory. Because like mental health, community
health is complex, and sometimes it is not clearly 'good' or 'bad'.
In order to do that though, I'd like to read your stories. Especially
from the people who've been around a few projects and seen a few
things. The stories Malcolm, Chris, and Jim already shared are
exactly the sort of thing I'm looking for, so if y'all would like to
elaborate that'd be really cool too.
Best Regards,
Myrle
On Sat, Oct 20, 2018 at 6: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
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
?B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB�?�?[��X��ܚX�K??K[XZ[?�??]�][��X��ܚX�P?��[][�]?K�\?X�?K�ܙ�B��܈?Y??]?[ۘ[??��[X[�?�??K[XZ[?�??]�Z?[???��[][�]?K�\?X�?K�ܙ�B�B
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
