On 22. Jun 2022, at 15:12, Jeremy Stanley fungi@yuggoth.org wrote:
On 2022-06-22 10:12:16 +0200 (+0200), Artem Goncharov wrote: [...]
I went multiple times through explaining “change” model to both experienced and unexperienced people and is usually painful.
And you also have less trouble explaining the convoluted GitHub "pull request" workflow to someone who has never heard of Git or GitHub?
Yes, I do. And there are much less people who has never heard of GitHub.
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).
[...]
OpenStack does its best in the org and repo descriptions on GitHub to highlight that they're convenience mirrors, and to point to the community's accepted workflows. Does that get overlooked? Is there something better that could be done to make it clear?
I doubt we can improve this. We mention in the project description it is mirror, but that is too easy to overlook. Otherwise every readme should start with bold statement: "do not open PRs here"
[...]
I think supporting multiple commit workflows and code review tools within the OpenDev Collaboratory would be even more confusing and add further conceptual barrier (what do you mean to commit to OpenStackSDK I need to use a different set of tools and review process than gophercloud, even though they're both in OpenDev?).
But from a technical feasibility standpoint, it's also more than just the lack of a Gitea driver for Zuul: our current Gitea server farm is read-only for technical reasons including lack of support in Gitea for a shared writeable storage backend, the fact that we would need to set up separate authentication/account management (we still need help from more people to make progress on our Keycloak SSO deployment), not to mention it would effectively double the security risk profile.
Thanks for adding more technical infos here, it was just an idea.
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)?
[...]
Is a source code mirror on GitHub not sufficiently "on GitHub" from Terraform's perspective?
Should be sufficient
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).
[...]
OpenStack's GitHub mirroring relies on a Zuul job with account credentials for the openstack org encoded as a secret in the job definition, and other projects do similarly for mirrors to their respective orgs as well. Performing other API interactions in jobs is similarly possible, so telling GitHub to make a "release" of something there would probably be a trivial addition.
Absolutely sufficient. Basically they refer on the webhook that gets triggered on pushing new “release”. But that is just one example of things requiring something different to how we work.
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].
You're spending your valuable time producing open source software, so you must see some value in your choice to make it open source and would rather users picked it over proprietary alternatives. I personally would feel rather hypocritical were I to claim that open source development is a good thing when it's the software I'm creating, but that I don't find the open source alternatives to proprietary code hosting and development tools similarly valuable and would rather choose what's convenient or popular instead. How can I expect the communities producing those tools to make traction against proprietary platforms if I choose to be part of that problem
For me the problem here is not whether GitHub is open source or not. Surely there are open source solutions, but that require company to actually run this hosting. You can try to to go opendev to do development there, but here you pay with gerrit.
rather than part of the solution? I feel similarly disheartened when I attend an open source software conference and see someone give a presentation extolling the virtues of these practices, while clearly running their slide deck from MacOS or Windows.
My company gives me laptop (and actually there are valid reasons for running some form of Enterprise stuff there). I have honestly no freedom in what I use to run slide decks. I would really love to have a purely Linux laptop, but I can’t. However I do my best to use open source tools to create my slide decks.
On the other side you mentioned gitea is lacking support for required piece and that is exactly the case where you eventually can’t chase open source anymore. We can try, but I doubt we are able to reimplement so many things in the purely open source style. I guess not even any car now runs with a purely open source firmware. Would you not use it because of that?
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?
If I can try to restate your request, it seems like you want to develop software using some different tool choices than those available in the OpenDev Collaboratory. All the software we run in OpenDev (and all the software we use to develop and maintain the services and deployment in OpenDev) is 100% open source, along with its configuration. If you want to run a different combination of those services for your community while reusing some of OpenDev's solutions, you absolutely can do that and a number of people do so already.
I know it is possible, but we didn’t proceed this way (most likely due to your statement in http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025663....)
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)?
[...]
I'm probably still misunderstanding what you mean by "very close to" in this statement. If the most important aspect of this is that gophercloud appears in the openstack org on GitHub, but you don't wish to actually use the development methodology and code review workflow of the OpenStack community, then that doesn't seem close at all. But maybe you mean "close" from a marketing perspective? Mirrors to GitHub are not something OpenDev sysadmins really even get involved with, it's just automation individual projects implement and maintain for themselves, so it's the OpenStack TC's choice as to what projects they'll allow to appear in their GitHub org, and really nothing to do with the OpenDev Collaboratory itself.
And one thing I still don't feel like you've covered is your earlier assertion that gophercloud project leadership was told the OpenInfra Foundation refused to legally represent them unless they hosted their development in the OpenDev Collaboratory. As I mentioned in my earlier reply, there are already OpenInfra projects which do all their software development in GitHub and run their own CI systems completely separate from OpenDev, so I really doubt you've been given an accurate account of what was discussed between foundation leadership and gophercloud folks. It would probably be good to seek further clarification there.
Maybe right. Afaik (at least what I followed) the discussion got stuck on a statement that the folks must move to opendev to achieve that and they could not agree on that due to fear of loosing contributors). I have only http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025884.... http://lists.openstack.org/pipermail/openstack-discuss/2021-November/025884.html as last message to refer to.
My ultimate goal (“very close”) would be to have gophercloud on opendev and be a delivery of SDK team so that we can use same tooling and standards to test them. If being located on opendev is not an option I would love to have it on ANY git hosting with opendev Zuul integration to still be able to use same tooling to test them. If this ANY hosting is GitHub I would prefer to see it under OpenStack organisation from marketing perspective. Same would be valid for terraform provider for OpenStack, especially from marketing point of view, but I do not really know whether its maintainers are having an interest in that at all. At the moment those 2 examples are affiliated with OpenStack, but they feel so much detached from OpenStack development, that it does not really look proper to me. Since we may talk generally about "OpenStack affiliated" products of course there might be some limitations.
I learned openlab got problems, so gopher and TF are not even able to run Zuul jobs anymore. So unless somebody offers Zuul they can’t even do proper gating.
Artem