On a related note, here's an other case to consider: yesterday on #zuul, it was explained that parameterized jobs are unlikely to ever be a feature in zuul (see http://eavesdrop.openstack.org/irclogs/%23zuul/%23zuul.2018-07-17.log.html#t2018-07-17T19:56:26 ) This is however a very common use case and desired feature for some of our identified users. What can we do in that case ?
On Wed, Jul 18, 2018 at 7:30 PM, Paul Belanger <[email protected]> wrote: > 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
