Hello, It's time to wrap this discussion up and decide on some actions.
On our side of things, we should "freeze" our distgits patches wise so that we don't add any new "tech previews" to them. Personnally I understand the need for that, but I'd really like to see the admin REST API stuff make the cut. Anything else we should add before the freeze? On the upstream side of things: * we need to help with more reviews * we need to convey the usefulness of our contributions to maybe gently tug reviewing and merging efforts towards them * in particular, something we need most at the moment is for zuul and nodepool to have a more "plugin-friendly" architecture, so we can work on our own add-ons without being dependent on upstream for integration. There'd always be a possibility for upstream to graduate third party plugins into their codebase if needed. Anything else to do? MHU On Thu, Aug 2, 2018 at 9:24 AM, Tristan Cacqueray <[email protected]> wrote: > On July 20, 2018 2:45 pm, Paul Belanger wrote: >> >> 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? >> > That would be ideal, but without a release schedule and some sort of > blueprints/expected features, it's not realistic. > > For example, the /tenant/job REST api[0] (to enable simple things like > exposing > the location of a job) has been submitted 8 months ago already... > > Similarly, I proposed an implementation[1] of the container build resource > right after we agreed on the design at Vancouver, more than 2 months > ago. > > We don't know what will be in the next version of Zuul or > when it will be released. > SF developments are blocked without tech-previews. > >> 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? >> > Note that we are already waiting for tagged version upstream to release SF > and > we often work on the upstream blockers to make the releases happen. > >> 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. >> > Technically, I do not think the tech previews need a staging environment as > they > are fairly isolated from the zuul/nodepool logic. > For example, the extra nodepool drivers are optional. > > Regards, > -Tristan > > [0] https://review.openstack.org/527579 > [1] https://review.openstack.org/570667 > > _______________________________________________ > Softwarefactory-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/softwarefactory-dev > _______________________________________________ Softwarefactory-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/softwarefactory-dev
