https://cwiki.apache.org/confluence/display/AIRFLOW/Releasing+Airflow <https://cwiki.apache.org/confluence/display/AIRFLOW/Releasing+Airflow>
(See higher up in the thread) Please make sure to address some of the outstanding Apache issues (see also quote below): 1. Your name is still mentioned somewhere as author. A patch wasn’t cherry picked earlier for this 2. Copyrights 2016-2017 Apache, before Airbnb / you 3. License file formatting Otherwise it won’t pass the IPMC. Quote from the IPMC: ==== +1, however there's a few issues with the LICENSE file: - Would be good to list out the locations of each file (or path to a group of files) (some have this, and others do not so its hard to follow) - There's errant /* .. */ around each license declaration, which should be removed. - Missing license bodies for FooTable v2, jQuery Clock Plugin, Likewise, your NOTICE has copyright 2011-2017, however Airflow hasn't been incubating that long. If you like, you can give origination notices to the original creators here to specify the original copyright dates. I would challenge the podling to see if there's a way to simplify their LICENSE by instead using npm or some other javascript packaging tool to build a distribution, rather than shipping the dependencies in the source release, makes it much easier to use. As the podling matures, would be good to see information about the author switch from an individual to a community (in setup.cfg, its already in setup.py so may have been a miss) It would be great to see a binary distribution in the next vote to see how that may work, its not clear how to build it from this. Likewise, don't hesitate to clean up your old release artifacts, I downloaded the wrong artifact at first. ==== Bolke. > On 18 May 2017, at 20:49, Maxime Beauchemin <[email protected]> > wrote: > > Chris & Bolke, do you have a TODO list / wiki detailing the step-by-step > process? > > Max > > On Thu, May 18, 2017 at 11:46 AM, Maxime Beauchemin < > [email protected]> wrote: > >> @Andrewm, we can only assume that the author of each commit in master on >> top of 1.8.1 wants their commits into 1.8.2. >> >> ------------------------- >> >> Ok cool, I'll take this on then, and I'm asking Arthur to see if he wants >> to help / oversee the process. >> >> I'm planning to make 1.8.2 essentially same as 1.8.1 plus the set of >> "cherries" that we use at Airbnb in production and every bugfix / minor >> feature that looks benign to us. Given that, we're committing to try out RC >> along with everyone else. >> >> What cadence are we aiming at? What should be the target date for the RC? >> >> Max >> >> On Thu, May 18, 2017 at 11:29 AM, Bolke de Bruin <[email protected]> >> wrote: >> >>> Hi Max, >>> >>> Sounds reasonable. For the Release Manager it is really mostly a >>> management job. Chasing, prioritising etc. While it is nice to have a rm >>> also being able to run the RCs themselves I don’t think it is an absolute >>> requirement. Especially, as I think we should trust the community to test >>> and then vote. >>> >>> As mentioned the 1.8.X release series should focus on bug fixes, >>> performance issue and minor feature updates (UI fixes, fixes to some >>> hooks/operators). 1.9.X is for the larger changes. So indeed please keep >>> 1.8.2 simple! >>> >>> Fully understand that business priorities can take precedence. I (and I >>> guess Chris as well) were just hoping that also some of the other >>> committers would chime in. >>> >>> Cheers >>> Bolke >>> >>> >>>> On 18 May 2017, at 20:18, Maxime Beauchemin <[email protected]> >>> wrote: >>>> >>>> Hey, >>>> >>>> Sorry about the delay answering, I wanted to sync up with the Airflow >>> team >>>> here at Airbnb before I replied here. >>>> >>>> Quick note to say that the folks at Airbnb are putting a plan together >>> as >>>> to how we can move towards smooth releases with higher confidence in the >>>> future. That plan involves improving the build/test process as well as >>> our >>>> staging infrastructure, possibly enabling progressive rollouts >>> internally. >>>> >>>> For context, the team that works on Airflow at Airbnb is "Data Platform" >>>> and is also on the hook for big chunks of non-Airflow-related >>>> infrastructure work that hit us recently and accounts for more than the >>>> team's bandwidth at this time. Given that, the team doesn't want to >>> commit >>>> the time/risk to deploy RCs in production in the short term. Clearly >>>> Airflow is still a priority for the team, but on the short term we have >>>> critical things prioritized above that. >>>> >>>> Part of the solution is for us to hire more engineers, and one of the >>> open >>>> seats is a dedicated role on Airflow tackling things from feature >>> building >>>> to release management. Hopefully we can widen our bandwidth shortly. >>>> >>>> In the meantime, I can commit the time to handle a release, but this >>>> release won't hit production at Airbnb for a little while, which makes >>> me >>>> wonder whether it's worth committing the time. Maybe there's a >>>> Fedora/RHEL-type scenario here (using a cutting-edge community edition >>> to >>>> stabilize LTS releases), but we know it's not ideal for Airbnb and for >>> the >>>> community. The end goal is clearly to have steady, high-confidence, >>> mostly >>>> automated, regular releases and it feels like time is best spent >>> working in >>>> that direction. >>>> >>>> Another option is to make [upcoming] 1.8.2 very simple, as 1.8.1 + the >>> few >>>> cherries we run in production already at Airbnb, holding the 50+ extra >>>> commits in master for 1.8.3. This is marginally useful but helps getting >>>> the release mechanics oiled up. >>>> >>>> I'm trying to be as transparent as I can here, and open to discuss the >>>> different ways we can move forward. >>>> >>>> Max >>>> >>>> On Sun, May 14, 2017 at 4:44 AM, Bolke de Bruin <[email protected]> >>> wrote: >>>> >>>>> Hi Folks, >>>>> >>>>> With 1.8.1 we have very much improved the reliability airflow, which is >>>>> great as many new features entered 1.8.0 and the gap from 1.7.1 was >>> huge. >>>>> What is also great is that we are slowly but surely increasing the test >>>>> coverage which mitigates some of the risk of regressions going >>> forward. As >>>>> you know the 1.8.X releases will continue to focus on improved >>> reliability, >>>>> performance improvements and minor feature updates. The 1.9.X release >>>>> cycle, which should start around September, will allow for larger >>> feature >>>>> updates. >>>>> >>>>> I expect 1.8.2 not to have too many PRs, so it will be a relatively >>> simple >>>>> release process: >>>>> >>>>> 1. Apply bug fixes >>>>> 2. Add performance fixes >>>>> 3. Fix some outstanding Apache requirements (Author, Licensing etc) >>>>> >>>>> The process of creating a distribution has been detailed by Chris here: >>>>> https://cwiki.apache.org/confluence/display/AIRFLOW/Releasing+Airflow >>> < >>>>> https://cwiki.apache.org/confluence/display/AIRFLOW/Releasing+Airflow> >>>>> >>>>> Now we just need a volunteer (preferably from the committers) to be the >>>>> Release Manager for 1.8.2 :-). >>>>> >>>>> Who is willing to take this on and make history? >>>>> >>>>> Regards, >>>>> Bolke >>>>> >>>>> >>>>> >>> >>> >>
