3 ms·
I think Drew makes a good point about the fact that distributions implicitly perform a 'review' step for packages, but I'm not certain I agree with the idea tha
by jka 4y ago
I think Drew makes a good point about the fact that distributions implicitly perform a 'review' step for packages, but I'm not certain I agree with the idea that leaving all packaging to distributions is the best approach overall.
Generally I think that the ability for individuals to upload packages and for those to be available immediately for consumption is an incredible benefit for developer productivity and pace.
I'd also agree that review steps are important, so perhaps the defaults for application-side package managers should err more towards pinning to specific versions, rather than automatic updates (with the possible exception of security-related updates).
To me there are two common modes of software distribution:
- "Building-out" phase distribution: this is while applications and the libraries that they rely on are in active development -- they're 'leaf nodes' if we consider them as a dependency tree. This is where pace and the ability to iterate quickly is beneficial. Code and dependencies are likely not installed from the OS distribution, because that may not evolve quickly enough to support development.
- "Baking-in" phase distribution: the applications and libraries are maturing and have proven their worth in multiple production environments. Stable releases exist, and may have support offerings associated with them. This is where distribution-packaging shines; it makes trusted, well-tested software immediately and easily available to a very large number of users in a way that is reliable and doesn't introduce unnecessary support burdens on the distribution packaging teams.
I'd love to see more code review at various stages of software development; we typically do it during changeset development (pull requests), but I think that pre-release code review would make sense, and I also believe that post-release 'diff' code reviews would be valuable (what has changed between v1.1 and v1.2? do reviewers agree that it is safe, correct and documented?).
The growth areas I'd expect to see in software development careers are in maintenance and review. Perhaps not hugely exciting compared to feature development, but (again, my opinion only) more important for stability and overall software quality long-term.
- nickitolas 4y ago> I think Drew makes a good point about the fact that distributions implicitly perform a 'review' step for packages, but I'm not certain I agree with the idea that leaving all packaging to distributions is the best approach overall. As was mentioned in this reddit comment on this very topic (https://www.reddit.com/r/linux/comments/uohnzg/when_will_we_learn_drew_devault_of_rusts_and/i8fl5e0/?utm_source=reddit&utm_medium=web2x&context=3 https://www.reddit.com/r/linux/comments/uohnzg/when_will_we_...) package managers usually do not have a review process for updates: > System package managers do not have a review process for package updates. Not for all packages, at least, and I would argue not for many packages. > (...) > The job of a package maintainer is to package software, not to perform security audits. They probably even lack the skills for performing security audits, because they are package maintainers, not security experts. Now, you could make an argument that any filter, if not necessarily an audit or review cycle, just some time delay and having to convince a person that it's worth adding, is enough to add some measure of security. But equating it with "review" is just a misrepresentation of reality. And keep in mind that (To my understanding) distributions handle a vastly smaller set of packages than the tools Drew is proposing they replace. And I often hear about how they struggle to keep up with that. I doubt he doesn't know all this, so it's hard to read this as anything other than a bad faith argument to bash on things he doesn't like.