Mailing-List: contact dev-help@avro.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@avro.apache.org
MIME-Version: 1.0
In-Reply-To: <CAAER68CcpiMdjC3GfJW6=JJAv_Jxm2zbRbkdCF43bNz9A3aFiQ@mail.gmail.com>
References: <CAO4re1mn0UmKVwhi=OMdBDR3wxEK5e+3xCR8QUsDxkZ_8PHDdQ@mail.gmail.com>
 <CAK7GPaZz6iF+RHUfj9XgTgC+buQNOK1Fhm15W-nyokcRG2s7gg@mail.gmail.com> <CAAER68CcpiMdjC3GfJW6=JJAv_Jxm2zbRbkdCF43bNz9A3aFiQ@mail.gmail.com>
From: suraj acharya <suraj.spa@gmail.com>
Date: Mon, 14 Nov 2016 09:26:57 -0600
Message-ID: <CAFK5+R+cjgPk9+vp7kwevXUOQSWeW3w=ps1BFywK57wmUfw4QQ@mail.gmail.com>
Subject: Re: [DISCUSS] Community engagement
To: dev@avro.apache.org
Content-Type: multipart/alternative; boundary=001a11446feeac245a0541447986
archived-at: Mon, 14 Nov 2016 15:27:32 -0000

--001a11446feeac245a0541447986
Content-Type: text/plain; charset=UTF-8

Hi,
I agree that there is a delay in code reviews and that is one reason for
the decline in participation.

Regarding the testing I agree we are a bit shorthanded. We need to setup
pre-commit tests and run some more testing regularly.
I agree with your problem of docker and I have seen  the same issue and
thought it was only me. I was wondering if we can move to a more stable
docker image. I started a thread here
http://mail-archives.apache.org/mod_mbox/avro-dev/201611.mbox/browser and
was wondering what others opinion on it was.

However, if we do split it we will need to see to it that all projects are
maintained well. For ex: we currently have 2 python implementations, is it
possible to get rid of one and just keep one?

Thanks

Suraj

-Suraj Acharya

On Mon, Nov 14, 2016 at 2:55 AM, Zoltan Ivanfi <zi@cloudera.com> wrote:

> Hi,
>
> I agree with the proposed changes.
>
> Regarding the mailing lists, I would like to suggest to separate not only
> the different languages from each other, but also the discussions from the
> pull requests, test results and JIRA notifications. When those are mixed
> together, discussions easily get lost
> <http://mail-archives.apache.org/mod_mbox/avro-dev/201611.mbox/browser> in
> the vast amount of automated mails. When subscibing to such mixed mailing
> lists, I always have to spend a good 5 minutes figuring out what criteria
> to use for setting up mail filters properly.
>
> Thanks,
>
> Zoltan
>
> On Mon, Nov 14, 2016 at 8:53 AM Simon Woodford <simonwoodford@gmail.com>
> wrote:
>
> > Hi all,
> >
> > CI testing seems an excellent idea. So does splitting the languages for
> > releasing.
> >
> > If the languages are split then I think it would be a good idea to have
> > separate mailing lists so that e.g.C++ devs don't get all the Java pull
> > requests. That should make review and commit turnaround times shorter.
> >
> > The only problem I can see is the danger that two languages interpret the
> > spec slightly differently and then drift away from being able to talk to
> > each other. So I suggest that we set up a basic set of data files that
> has
> > to be tested by all languages (reading tests and round-trip tests) and
> > insist that any time someone fixes a spec-violating bug in any language,
> > they add a test for this to the all-languages tests.
> >
> > Simon
> > On 13 Nov 2016 20:22, "Ryan Blue" <blue@apache.org> wrote:
> >
> > > Hi everyone,
> > >
> > > We tried to release Avro 1.8.2 this week, but the release vote failed
> > > because only two PMC members voted on the candidate and we didn't have
> > > enough binding votes to pass. There was a minor problem (in my opinion)
> > > with the candidate that could have been the reason why there weren't
> more
> > > votes. If there's anyone out there that didn't vote because of this,
> > please
> > > say so. Otherwise, this appears to be related to declining engagement
> in
> > > the community and that's a major problem I want to discuss.
> > >
> > > Right now, we aren't getting contributions reviewed, committed, and
> > > released in time for new contributors to become part of the community
> and
> > > refresh the set of active committers and PMC members. If that
> continues,
> > > this community is heading for the Attic. I think we can build back an
> > > active committer base and I'd love to discuss how to do that on this
> > > thread.
> > >
> > > To get us started, I have a couple of ideas.
> > >
> > > I think we need to make it easier to participate. I've brought up these
> > > ideas before when we moved to git: I think we need to separate the
> > > implementations into their own repositories and set up CI tests for
> each
> > > one.
> > >
> > > Right now, a contributor has to wait for a review to get feedback and a
> > > committer has to build a contribution and run tests. If we set up CI,
> > then
> > > the contributor gets automated feedback and committers can spend their
> > time
> > > on substantive review, rather than making sure the patch builds and
> tests
> > > pass. Making it easier for contributors and committers will help
> increase
> > > participation.
> > >
> > > Similarly, the build and release process is too difficult. It took me
> > hours
> > > to get the docker image built so I could make a release candidate,
> > because
> > > of a failure rate of about 1/500 downloading and installing packages. I
> > had
> > > to try ~20 times before one happily completed. While the docker image
> > helps
> > > a lot, the real problem we need to solve is how difficult it is to
> build
> > > all of Avro. The docker image helps, but no one really uses it until
> it's
> > > time to check a release. Instead, we all build and test how we are used
> > to
> > > for a particular language implementation: maven for Java, Rake for
> ruby,
> > > etc. That's why the build.sh scripts get broken and we don't notice,
> and
> > > why the only problem with the latest RC was that it didn't pass C#
> tests
> > > outside of docker.
> > >
> > > The current build also makes implementation releases dependent on one
> > > another. Last release, C and ruby problems caused a multi-week delay,
> and
> > > this release we want to get the C# test environment fixed before the
> next
> > > candidate. All of this makes it take longer for contributions to make
> it
> > > out, which undermines the motivation for people to contribute.
> > >
> > > Separating the implementations will allow us to structure each
> repository
> > > how the contributors and committers for that language expect it to be.
> We
> > > can also set up per-implementation CI easily through Travis CI. And the
> > > biggest benefit is separating the releases, so that Python, for
> example,
> > > can release a bug fix without waiting months for unrelated changes in
> > Java.
> > >
> > > From my perspective, these two things are a good place to start. To
> > > everyone still reading, what do you think?
> > >
> > > rb
> > >
> > >
> > > --
> > > Ryan Blue
> > >
> >
>

--001a11446feeac245a0541447986--