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? On Thu, Jul 19, 2018 at 7:41 PM, Paul Belanger <[email protected]> wrote: > On Thu, Jul 19, 2018 at 07:11:44PM +0200, Matthieu Huin wrote: >> There shouldn't be that many patches at any given time that syncing >> the document manually would be a hassle. If that time comes, we can >> look into automation. The advantage of the Etherpad over Gerrit for >> this, IMO, is that you can expand on the rationale behind a patch or a >> given topic of patches, and thus explain why we see them as needed. >> Gerrit might not be the place for such a detailed explanation. >> > I agree, but why not just the zuul-discuss ML over etherpad? I found the list > that TristanC did in this tread to be really helpful. > >> On Thu, Jul 19, 2018 at 6:59 PM, Paul Belanger <[email protected]> wrote: >> > On Thu, Jul 19, 2018 at 06:06:32PM +0200, Fabien Boucher wrote: >> >> What about maintaining an etherpad with the list of patches we carry in >> >> our >> >> packaging ? >> >> >> > If the data is already in gerrit, moving it to etherpad just duplicates it >> > IMO. >> > Personally, I like using topics in gerrit to help organize patches, it >> > worked >> > very well for zuulv3 release, maybe we can start doing that with SF >> > specific >> > review. >> > >> > We also could consider creating a new dashboard in gerrit using >> > gerrit-dash-creator[1] to make it easy via web UI too. >> > >> > [1] http://git.openstack.org/cgit/openstack/gerrit-dash-creator >> > >> >> For instance, each patch line should include: >> >> >> >> - the upstream review >> >> - the current in-progress status (-1/0/+1/+2) >> >> - an explanation about why this patch is needed for us in SF. >> >> - maybe more ... >> >> >> >> Idea is to use that etherpad as a relay document between upstream and us. >> >> Maybe it can help, as a support, to promote our patches to be merged >> >> faster. >> >> >> > I like the idea, if we can solve the duplicate data issue from above, I >> > think >> > that is great. Giving upstream something too look at is the right >> > approach, I do >> > think a single topic in gerrit might be a great first step. >> > >> > - Paul >> > >> > _______________________________________________ >> > 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
