Hello Kevin, > I'm hopeful some things will come out of this as it's a chance for us to > look at our processes and improve them. I'm glad that's happening. It seems to me that improving those processes would be Distro decisions. Which I keep understanding don't really exist. At least not quickly. So I'm confused still. But glad. > > 1] Lack of committer 'Real' identity confidence and verification is a problem. > IMHO this isn't a problem. We don't have a right to demand anything from > open source projects. We can ask, we can urge, we can contribute and > change things, we can choose to not use something, or fork something. I really don't suggest 'demanding' anything. I do think it's wise to make choices to avoid it. Like just my example of a critical-path XZ with one developer vs a critical-path ZSTD built & maintained in a Facebook FOSS project. I know from just a business view I would never enter into a 'critical' contract without "knowing" the principal persons. Of course you must know what you need "knowing" to be. > > 2] Undetected differences source + packaging in repo vs tarballs are unchecked. > > > Yeah, a lot of the discussion has been in this area. > > I'm wondering if perhaps we shouldn't revisit source-git, or at least > a variant of it where we keep the upstream sources in a branch always > and apply packaging on top of that and build from there. I'm not sure what the packaging tools and rules are here. It seems to me that repo source with an attested commit (signature? published hash?) can serve as the one source of truth. Then users can pull the commit or the on-demand API-generated tarball. I guess that could be subject to for example Github's or Gitlab's API tarball generators being hacked. But that seems less probable of a concern. > > 3] Under-resourced development creates risk; 'Many eyes' bench depth in development is needed. > > Yep. I think also visibility of changes can be improved. > So, maintainers know more about whats in a new version and how it works. You can implement tools to increase the visibility for sure. And procedures. Also just the "given enough eyeballs, all bugs are shallow" that comes with using a larger project helps. Thanks for the discussion. Cheers! Arnie -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
