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.
