On Fri, Jul 20, 2018 at 06:21:48AM +0200, Matthieu Huin wrote: > Here's another reason to apply the Tech Preview model that I painfully > became aware of while working on my upstream patches: a lot of my work > in SF itself depends on my upstream patches being included in Zuul. > The tenant-scoped web API in Zuul implies work on cauth and sf-config > to support the JWT auth. If I wait for upstream to merge my patch, I > cannot start implementing these changes in cauth and sf-config since > our version of zuul won't have the needed feature. > > Is there any way to circumvent that, or should we accept that a lot of > our dev will be slowed down by upstream? > Yup, can see how that is a blocker. I guess my question would be, if SF decided to work to land features in upstream zuul master first, then wait to make changes to sf-config / cauth only after a tagged release, what would that looking?
Actually, as long as we are not releasing SF before a tagged version of upstream zuul, depends-on here should work. And shouldn't block any development of sf-config / cauth patches right? I think the key thing here, is we won't be able to land the new RPM on sf.io (rdoproject / ansible tenants) due to upstream not releasing a tag, but nothing saying we cannot do the testing in a staging environment first. - Paul _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
