airflow-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Riccomini <criccom...@apache.org>
Subject Re: Airflow Contributors Meeting (June 01, 2016) : Minutes
Date Thu, 09 Jun 2016 18:07:56 GMT
>    - Discussed forking however this doesn't seem to be the right thing for
   all the parties. In Airbnb's case there is a significant interest in
   maintaining a healthy community and Airbnb running on a separate fork
will
   not be good for the community.

This is not an easy decision to make, but a very important one, IMO. Huge
thanks.

On Tue, Jun 7, 2016 at 12:23 PM, Maxime Beauchemin <
maximebeauchemin@gmail.com> wrote:

> Hi,
>
> We had notes to share on our side as well, sorry they're coming a bit late.
> They are complementary to Sid's notes so I thought we'd share them here:
>
> *>>*
> *Participants*
> Maxime Beauchemin
> Bolke de Bruin
> Dan Davydov
> Paul Yang
> Arthur Wiedmer
> Swaroop Jagadish
> Gurer Kiratli
> Jeremiah Lowin
> Chris Riccomini
> Siddharth Anand
> Paul Hordes
>
> *Meeting Notes*
>
>    - Talked about pain points, here are the identified pain points:
>       - We had to rollback releases two in the most release. Then we had to
>       dive deeper in the logs for diagnosing issues and trying to work
> with the
>       owners of the changes to fix the problems.
>       - There is not enough unit and end to end testing. Airbnb becomes the
>       only end to end testing environment.
>       - Some PRs were rushed. Merges happened w/o review.
>
>
>    - What should be the process around taking ambitious amount of work to
>    the Core?
>    - Have a design document hence have a soft lock on the area as in people
>       are aware that you are working on this core area of Airflow. Solicit
> this
>       thru the dev-list.
>       - Not all the work can have a meaningful design document in the
>       beginning sometimes you have to get your hands on the code. In
> these cases
>       the PRs can be accepted as design documents. However be ready to
> have the
>       PR to be rejected as easily as a design document.
>       - Folks who are undertaking work in the core has to make sure
>       appropriate unit and end to end tests are available if not the
> scope should
>       include creation of those.
>       - Get PR reviews and approval from at least 2 committers. Do not
>       merge-then-review.
>    - For all the changes if there is not enough unit and end to end testing
>    the committer should cherry pick that change into their branch and run
> in
>    their production.
>    - All PRs need to have a committer champion it to be reviewed and
> merged.
>    - We should feel comfortable saying No on the non-priority improvements.
>    - Discussed forking however this doesn't seem to be the right thing for
>    all the parties. In Airbnb's case there is a significant interest in
>    maintaining a healthy community and Airbnb running on a separate fork
> will
>    not be good for the community.
>    - Releases should be community driven. Committers should probably
>    release together.
>    - We will have to revisit our roadmap. One deliverable that we need
>    focus on is an end to end testing framework.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message