@Jakob What if we made it more generic, e.g. a +1 from any commiter from a company that is running at a certain scale (e.g. at least X workers) and willing to help stage releases in their prods until we have more comprehensive test coverage/an open source staging environment? This is in Airflow's best interests as otherwise stability will suffer.
On Thu, May 12, 2016 at 1:44 PM, Chris Riccomini <[email protected]> wrote: > @Sid, perhaps defining a cool-off window before a scheduler change can be > committed. That way, everyone that cares can have a look at it? Also, > having more than one +1 seems OK with me for scheduler changes. We will > have to decide what "scheduler change" means, though. > > On Thu, May 12, 2016 at 1:39 PM, Jakob Homan <[email protected]> wrote: > > > Hey Sid- > > Thanks for the discussion. It's a good chance to the new > > contributors to get more experience with the ASF. > > > > Unfortunately, what you propose is not possible in ASF. As a > > meritocracy, ASF does not recognize individual's employers (or lack > > thereof). Merit is earned by the individual and follows them as they > > move from organization to organization. This is true even for > > podlings. Employees of certain organizations are not given extra > > power over a project or vote due to their relationship with the > > employer. > > > > ASF does recognize that at times people will be representing their > > employer (with my $EMPLOYER hat on, is a common way of expressing > > this), but expects that everyone is acting in the best interest of the > > project. > > > > -Jakob > > > > On 12 May 2016 at 12:58, Siddharth Anand <[email protected]> wrote: > > > Hi Folks!As many of you know, Apache Airflow (incubating) came from > > Airbnb, where it currently still represents the largest Airflow > deployment. > > Airflow entered the Apache Incubator shortly over a month ago but still > > depends on Airbnb's production deployment to vet its release candidates. > As > > Airflow's adoption increases, we expect to leverage multiple companies in > > conjunction with Apache Infra resources to vet some of the more > performance > > critical pieces of the code base (e.g. scheduler). We're not there yet. > > > So, for future commits and PRs involving the scheduler (and possibly > > other components, e.g. executors), I propose a 2 vote system : at least 1 > > vote from an Airbnb committer and at least 1 vote from a non-Airbnb > > committer, separate from the PR author. This will more readily stabilize > > the Airbnb production system that we rely on to vet and cut releases, > > speeding up our release cycle. > > > Please share your thoughts on the matter along with a vote for/against. > > > -s > > >
