<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Thanks Clark and Jeremy for comments<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 21. Jun 2022, at 17:34, Clark Boylan <<a href="mailto:cboylan@sapwetik.org" class="">cboylan@sapwetik.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">On Tue, Jun 21, 2022, at 8:03 AM, Artem Goncharov wrote:</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Hi all,<br class=""><br class="">During the summit we had some nice conversations and I wanted to<span class="Apple-converted-space"> </span><br class="">actually use the chance and try to formalise the discussion to gather<span class="Apple-converted-space"> </span><br class="">broad opinions and ideally solutions.<br class=""><br class="">Sidenotes:>>>>><br class="">- I enjoy opendev<br class="">- I really enjoy gerrit and find it an ultimate code review system<br class="">- I can understand people not able to cope with additional complexity<span class="Apple-converted-space"> </span><br class="">and prefer pull request pattern to the change pattern<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">I think we should be careful with the assertion that Gerrit is more complex. It is different, but I'm not sure it is more complex. Pushing to Gerrit isn't any more complex than pushing to Github. Github even has the extra step of needing to open a pull request explicitly. But it is different and does require learning a different process.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>Ok, accepted. Personally I agree and disagree with your statement, cause I went multiple times through explaining “change” model to both experienced and unexperienced people and is usually painful. In the Outreachy we also have same practice each time and this is for people just harder to understand (I see project on GitHub, why can’t I open PR here like I would do for every other project on GitHub). But that is not relevant here. I will try to avoid statement “more complex” in future communication.</div><div><br class=""></div><div>BTW, are we absolutely and unbendable strict on using change methodology vs pull? I mean would there be conceptual disagreement on using PR approach on <a href="http://opendev.org" class="">opendev.org</a> with purely gitea for those “ecosystem” tools? The process (and UI) feels exactly like GitHub and I guess we could cover lot of concerns. I know we currently do not have Zuul support for gitea API, but I would be willing to contribute to that once this is an option at all. My experience show that when there is huge conceptual barrier it is possible to guide people through by moving them slowly into this direction and showing them advantages while going forward (first move them from GH to opendev keeping PR style, then once people see limitations of PR model show how “change” model addresses those concerns) - doing small steps.</div><div><br class=""></div><div>Practically this would mean we need:</div><div> - introduce auth on <a href="http://opendev.org" class="">opendev.org</a> (integrate with existing accounts?)</div><div> - be ready for the git storage to grow (due to forks)</div><div> - extend infra maintenance tools to cope with projects configuration</div><div> - introduce gitea driver in Zuul</div><br class=""><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">- I use PR change pattern for relatively simple projects (and lot of<span class="Apple-converted-space"> </span><br class="">other huge projects do it this way)<br class="">- I am not blaming and not going to blame anybody here<br class="">End sidenotes>>>>>><br class=""><br class="">- Some month ago gophercloud folks came to us and wanted to give source<span class="Apple-converted-space"> </span><br class="">code under the foundation. Feedback from us was more or less: you<span class="Apple-converted-space"> </span><br class="">either host on opendev and use gerrit or not at all. Members of gopher<span class="Apple-converted-space"> </span><br class="">cloud rejected proceeding this way with detailed reasoning. I can fully<span class="Apple-converted-space"> </span><br class="">understand reasonings and I also observe similar issues with<span class="Apple-converted-space"> </span><br class="">auto-closed GitHub PRs (for SDK or OSC) and the fact that those changes<span class="Apple-converted-space"> </span><br class="">in most of the cases never really reach gerrit. Especially in the SDK<span class="Apple-converted-space"> </span><br class="">area it would have been very useful to get various SDKs under single<span class="Apple-converted-space"> </span><br class="">team to spread the know how and synchronise their feature sets. Maybe<span class="Apple-converted-space"> </span><br class="">even use shared credentials to public OpenStack clouds to verify and<span class="Apple-converted-space"> </span><br class="">publish their coverage.<br class=""><br class="">- Some software solutions (especially those based on Golang) were<span class="Apple-converted-space"> </span><br class="">designed with GitHub in mind and are actually not really working<span class="Apple-converted-space"> </span><br class="">outside. For example in order to publish provider for HashiCorp<span class="Apple-converted-space"> </span><br class="">Terraform into their registry your product must be hosted on GitHub<span class="Apple-converted-space"> </span><br class="">(particularly you must upload build artifacts as release on GH). There<span class="Apple-converted-space"> </span><br class="">is sadly no other possibility.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">This isn't the only instance we've run into this. The CNCF's Cloud Native landscape (</span><a href="https://landscape.cncf.io/" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://landscape.cncf.io/</a><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">) requires open source projects be hosted on Github (not not proprietary systems....). From my perspective, I think this calls out why it is important for us to continue to push back against these rules. Software is built in a number of places and if we force people to use Github (and other proprietary tools) we move away from part of the mission here.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>I agree we need to support making landscape flexible. But I am not 100% sure we should currently (due to general lack of contributions) simply refuse those willing to contribute into OpenStack . Terraform is a very prominent example here as well - you must be on GitHub to publish your artefacts. Don’t we want to have official TF provider following our best practices (therefore this is not an infrastructure only question)?</div><div><br class=""></div><div>As mentioned above - if we address concerns of developers by starting supporting also PR model we can have more arguments to strengthen our position.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="">- My company has created HashiCorp secretstore plugin for OpenStack and<span class="Apple-converted-space"> </span><br class="">we are willing to donate this under the foundation to have proper<span class="Apple-converted-space"> </span><br class="">ownership of the software (not to have our company name in the hosting<span class="Apple-converted-space"> </span><br class="">path since it is pretty confusing). From features point of view there<span class="Apple-converted-space"> </span><br class="">is still place to evolve and it would be cool to get other interested<span class="Apple-converted-space"> </span><br class="">parties to participate. We would be able to OpenDev without conceptual<span class="Apple-converted-space"> </span><br class="">issues and are going to request projects for that, but that still has<span class="Apple-converted-space"> </span><br class="">one issue: publishing of binary artifacts - not immediately available<span class="Apple-converted-space"> </span><br class="">in opendev (afaik). On GitHub we publish it as GH Release.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">OpenDev supports publishing of binary artifacts through a number of mechanisms. OpenStack wheel packages are pushed to pypi, docker images are pushed to Docker Hub and Quay and so on,<span class="Apple-converted-space"> </span></span><a href="http://tarballs.opendev.org/" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">tarballs.opendev.org</a><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>hosts other random artifacts as well. It sounds like you specifically need Github Releases though. Can you not trigger releases against mirrored content? I think that should work? You might need to be more specific about what the actual needs are here.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>Awesome hint. I completely forgot we have <a href="http://tarballs.opendev.org" class="">tarballs.opendev.org</a>. This is absolutely sufficient for my case, but in general we may explore publishing to GitHub mirror releases while still doing development on gitea. That requires having GH app token though (that is actually where those Vault plugins are being useful - you just fetch the token from vault and it expires afterwards).</div><br class=""><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="">As such the point I am trying to address is that we as a very big<span class="Apple-converted-space"> </span><br class="">project should be bit more open to the world of tools around OpenStack<span class="Apple-converted-space"> </span><br class="">(I mean explicitly **not** the OpenStack itself) and allow easy<span class="Apple-converted-space"> </span><br class="">integration for those who want to extend OpenStack ecosystem. Depending<span class="Apple-converted-space"> </span><br class="">on the particular application this may set certain limitations on the<span class="Apple-converted-space"> </span><br class="">solution (i.e. must be on GitHub, must use Jira, whatever) which might<span class="Apple-converted-space"> </span><br class="">be not compatible out of box with the OpenDev scheme. Do we as a open<span class="Apple-converted-space"> </span><br class="">community want to set strict boundaries or can we ease some of those<span class="Apple-converted-space"> </span><br class="">for the ecosystem around of OpenStack?<br class=""><br class="">- Would it be possible for the project hosted outside opendev be<span class="Apple-converted-space"> </span><br class="">governed by OIF and somehow visually belong to OpenStack? (As a user I<span class="Apple-converted-space"> </span><br class="">would definitely choose to use <a href="http://GitHub.com/openstack/project_x" class="">GitHub.com/openstack/project_x</a> rather<span class="Apple-converted-space"> </span><br class="">then <a href="http://GitHub.com/some_crappy_nic/project_x" class="">GitHub.com/some_crappy_nic/project_x</a>)<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">OIF does have projects that are not hosted on OpenDev. Whether or not OpenStack wants to have projects hosted outside of OpenDev is probably the major item to sort out here.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>Precisely this is the point. I am sure we can solve technical issues, but we need to have structural things clarified first - thus this discussion.</div><div>@foundation/tc - please comment.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">- Can such project enjoy Zuul integration not being part of opendev git<span class="Apple-converted-space"> </span><br class="">hosting? Technically it is surely possible (Ansible modules were tested<span class="Apple-converted-space"> </span><br class="">this way), but requires in my eyes precise definition.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">The OpenDev team tried to provide CI integration with Github provided projects (some Kata repos) and found that we weren't able to do it at a level that was maintainable. Github itself poses a number of challenges, but we also found that projects there being even more disconnected were even less likely to be involved in helping themselves which is something that we currently rely on to make this collaboratory successful. All that to say we (the OpenDev team) cannot provide CI resources to Github repos.</span></div></blockquote><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">We do provide third party CI for a small number of projects with the expectation that people on the OpenDev hosted project side are able to care and feed for that.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>Fair point. That is why I wrote that I would be able to support this (due to having maintainable solution working on our side). There should be just willingness and allowance to move into this direction.</div><br class=""><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">I think this calls out the fundamental disconnect here. We use open source tools because we believe that open source needs and should be built with open source tools. That does require a little bit of investment from the project side to ensure the tooling functions as needed and is maintained.</span><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""></div></blockquote><div><br class=""></div><div>I would rather disagree with such statement: just because you host your code on a proprietary hosting (but make it freely available) does not mean your are violating this mission. I also believe we should be using open source tools (and we do that), but that doesn’t mean everyone else is breaking bad [not meant to be abusive statement].</div><div><br class=""></div><div><br class=""></div><div>Generally we have again here the same “infra” concerns in the discussion (which are already known historically, but anyway thanks for making them clear again), but what about other opinions? Are there any other thoughts or am I the only one interested to get this sorted out?</div><div><br class=""></div><div>Just to repeat, my current case is really about a very strong desire and, I would say even need, to have gophercloud be very close to OpenStackSDK. Can we at least think about placing them under OpenStack GitHub org without Zuul access to have a better affiliation with OpenStack (gopher folks, hope you do not mind of such step. Or maybe we try to demonstrate here how to make this manageable with Zuul - reach me out if there is interest)?</div><br class=""><blockquote type="cite" class=""><div class=""><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><br class="">P.S. For the case when zuul/github integration (management) is the only<span class="Apple-converted-space"> </span><br class="">limiting factor I will be gladly supporting the integration and<span class="Apple-converted-space"> </span><br class="">maintenance, since we have created an Ansible collection for managing<span class="Apple-converted-space"> </span><br class="">of GitHub organisations/projects/teams/members (in the project-config<span class="Apple-converted-space"> </span><br class="">spirit) which we use to manage our deployment (and I know others are<span class="Apple-converted-space"> </span><br class="">using it as well).<br class=""><br class=""><br class="">Tell me what you think and let us, please, focus on how to cope with<span class="Apple-converted-space"> </span><br class="">different expectations rather which one is right and which is wrong.<br class=""><br class="">Thanks a lot,<br class="">Artem</blockquote></div></blockquote></div><br class=""></body></html>