Just to clarify my thoughts in case it is needed: it is not a *THEM* vs *US* discussion. Ultimately both upstream and SF benefit from added features. It is about how we can help Zuul and Nodepool land features we deem important for SF in a quicker way that fits our release model and our users' needs. We can also later share the results of our brainstorming with the winterscale community and see what they think.
On Fri, Jul 13, 2018 at 9:27 PM, Matthieu Huin <[email protected]> wrote: > Hello, > > I would like to poke the collective brainpower about the way we ship > upstream components to which we also contribute, namely zuul and > nodepool, and see what we can do to improve if possible. > > As you probably all know, we choose to package these components as > RPMs, which allows us to ship zuul and nodepool with extra patches > that we call *tech previews*. These patches are always related to > features we are either contributing upstream ourselves or closely > follow, but that are not merged yet. The important point is also that > we have some relative confidence that these patches will eventually > make it into upstream. Unfortunately, "relative" and "eventually" must > be taken with a grain of salt: > > 1. We usually cannot tell how long it'll take for our patches to land > upstream. I don't have numbers to support it, but from memory It can > vary between days (some bug fixes made it quickly into master > upstream) to months (we've had OCI as tech preview for months, and > it's still not merged upstream). Fabien or Tristan can certainly > provide numbers on that point. > 2. We cannot guarantee that the feature in tech preview will land > as-is. The upstream reviews are usually being discussed and can be > subject to change, meaning users should not consider any of the tech > preview features to be stable. > > Looking at our distgit for Zuul, we currently ship 12 extra patches as > tech preview (5 of which about to be merged or merged - thus the spec > must be updated), and this is bound to increase if we keep > contributing things faster than they can be reviewed and accepted > upstream. It can become quite hard to maintain the patch chain as > upstream evolves. We also face the very real risk that one of our use > cases (and thus our upstream contributions) might contradict > upstream's roadmap, leading to rejected patches: do we become a fork > then ? Are we actually effectively a fork, providing a "Zuul that > could be someday" but definitely not the current Zuul? > > Yet the tech preview system has obvious advantages that make it > difficult to just drop this model, namely providing much needed > features that make Zuul and Nodepool much more serious and versatile > contenders in the world of CI, CD and code quality control - this is > also why we believe our changes will eventually make it upstream. > > I guess the question we need to answer is: why is it so hard or long > to have upstream land the features we propose? And what can we do to > change that? If we can improve on this, the need for patching will > decrease until we can ship code as close as possible to master, or > even tagged releases. > > What are your thoughts on this? > > Cheers, > > MHU _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
