And to add to it - setting automation for those is "easy". We already have a selective check that determines the "type of change" (it's being rewritten in python to make it easier). We could easily update it to asses automatically that things are "trivial" (we actually already do that - we have a number of PRs when there is no need to build images at all (those are by definition trivial) and we can also immediately see if there is any change to any python files in Airflow code tree. We could even automatically set the "trivial" label for those PRs. Same with changes that only touch the "dev" folder where we only do some house-keeping of the dev environment.
All the other changes IMHO should have a "news" piece (maybe empty "trivial" news that will be skipped - but it should be there). There is of course question about splitting the news between providers and core - but this should also be easy - we could require NEWS piece to be created for "airflow" if there is a change in "airflow" and another NEWS piece in any of the "providers" if there is a change for that provider - that's all very easy to automate (happy to do so). Similarly another news piece for "chart". I can very easily imagine that the "NEWS" pieces will be actually different for each of those - there might be change concerning both "airflow core" and "provider", but you might want to emphasise different things in those two different news. I think starting to require the news by automation is really the only way we can introduce it quickly and "firmly". I am afraid if we just introduce it "softly" we will not even have a chance to learn what burden it will introduce and whether it is "bearable". And we can always revert it if we find it too "problematic". J. On Fri, Mar 18, 2022 at 6:35 PM Leah Cole <[email protected]> wrote: > > @Kaxil Naik thank you for those examples! I've looked at all of those before > so it's cool to know what's behind the scenes now :) > > I definitely echo Jarek's concerns about enforcement and the need for > automation - I think that having automation helps ensure consistency and it > reduces the mental load on release managers and committers to remember to add > it. For folks who are like me and work in repos in different spaces with > different policies daily, this is crucial. I agree that CICD can be used as > communication. Would an alternative instead of having it be optional be doing > something like a trial period, where we set a date to evaluate how it's going? > > Leah > > On Sun, Mar 13, 2022 at 4:48 PM Jarek Potiuk <[email protected]> wrote: >> >> I am just afraid that "optional" without stating what optionality >> means might lead to chaos (when is it optional ? how do we check it?) >> >> No need for automation as long as we "know" what to do and communicate >> to both committers and contributors (and we are able to deal with the >> aftermath of those not being followed).. >> >> I see CI automation mostly as a "communication" tool. What it does - >> it passes our intentions of what we want in an automated way - it >> should run the same checks that "committers" would do, and >> "communicate" what should be fixed to the "contributors' '. >> >> I see implementing/not implementing automation in CI as a trade-off between: >> >> * automating intentions of what we want to do (and teach people to >> react to errors) >> >> vs. >> >> * explaining and teaching all committers our intention (and at least >> attempting to make sure they read and understood it) >> * handling the aftermath for all cases where they did not >> understand/remember/knew/wanted to follow what to do (both committers >> and contributors) >> >> So if we have some way of explaining what to do and we think we can >> explain both committers and contributors what to do and we are ready >> to deal with the aftermath of those being misunderstood/forgotten/not >> followed, it's fine to skip automation initially (and it makes sense >> if we do not know what to do exactly and want to learn and we >> implement "little" or "no" automation). But the risk is that it won't >> be understood/followed/we won't learn from it and the aftermath will >> be difficult to handle. >> >> J. >> >> On Wed, Mar 9, 2022 at 10:56 PM Jed Cunningham >> <[email protected]> wrote: >> > >> > Good points Jarek. I mentioned it in the initial email, but I think we >> > should keep it optional to start with. I'd rather get the basics in place >> > first, as I think we are going to find some interesting scenarios as we >> > try and put rules around it. Even if only release managers touch it in the >> > short term, we still benefit from it (or at least I will). >> > >> > I have every intention of making it required down the road. I'm eager to >> > help spread the changelog workload around a bit more :) >> > >> > Just a single example of where things can get interesting is due to our >> > monorepo: setup.py changes could require a core newfragment, a provider >> > newsfragment (when we get there), or both. I'm sure we can sort it all >> > out, but I don't think we need to wait and have it all on day 1. We will >> > end up needing to handle 2 sources of changelog entries in the short term >> > regardless (and is part of my todo list). My gut tells me we should do >> > this incrementally instead. As long as we "catch up", when we start >> > requiring it shouldn't matter (the 2.3.0 fork is a natural time, but we >> > don't have to hit it dead on). In fact, I'll likely start putting >> > requirements on the helm chart first, as it is more isolated. > > > > -- > > Leah Cole (she/her) | Developer Programs Engineer, Data Analytics | > [email protected] | +1 (925) 257-2112 > My working hours may not be your working hours. Please ping me anytime if > you'd like a status update on anything we are working on together - my goal > is to never be a blocker for you. >
