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
