On Thu, Apr 4, 2024 at 8:00 PM Arnie T via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. Careful, for now you're approaching another scalability issue of the community development model. I mean, as chill as he is, even Daniel Stenberg [1] must have a limit on the amount of beers he can handle. > > > 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 [1] https://daniel.haxx.se -- _______________________________________________ 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
