On Fri, Jul 13, 2018 at 09:27:23PM +0200, Matthieu Huin 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? > I'd actually like to hear more thoughts from the SF team here, so far we've only gotten TristanC and mhu. Please take a moment and reply within the next week.
Thank you, Paul _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
