> [ Requiring two party sign-off on every change ] > > I wonder if it would make sense to organize some kind of "office > > hours" for code reviews and code testing best practices and > > guidance... > > As someone working in a very large organization where this is required: > That's fine in a company setting. It is not in a volunteer setting, > unless you introduce very firm expectations about turnaround times. As > much as I would see the benefit of that, Debian with its highly > asynchronous work ethics is not that environment.
To me the whole free and open source movement is about collaboration, transparency and the ethos of "given enough eyeballs, all bugs are shallow". I don't think code reviews is a luxury reserved for corporate employees, but something we can and should do in Debian. Given the correct tooling, it should work well (and is already working well in many teams). I don't subscribe to turnaround time requirements. We don't have deadlines like in corporations. We publish code and review when we have time. Code reviews are asynchornous by nature and not in conflict with Debian or general open source practices. If somebody wants to team up and work intensly on something, they can if they want. People can have miniconfs etc. Sure it requires a bit of patience sometimes - one of my patches to Redis took 6 years before it was merged, and in Debian for example I have been waiting for example for lintian.debian.org to come back online for almost 2 years now - but that is how volunteers collaborate. Projects that have active collaborators and good collaboration practices will go further. Hopefully Debian can have a future with increased collaboration and teamwork. > It is not a problem of best practices and guidance. It is one of > available time, motivation (spoons), and commitment. In a work place you > can demand that and if necessary, reassign to some other team member > whose job it is to review. The whole point of DEP18 is to streamline/unify the basic packaging stuff that is essentially undifferentiated and should not be as complex and multi-faceted as it is now. That frees up to do more fun things. To me the fun in open source boils down to design discussions, running code and code reviews. If you don't have time for code reviews in Debian, maybe indeed best practices and guidance is needed so you can do it without feeling it is a burden? > Insider risk concerns aside, maybe we should focus on making mistakes > easier to roll back. That is very heavyweight today. And that many > Debian services do not have appropriate staging environments is also a > problem - orthogonal to code review but related to testing practices. That is an interesting idea. I wonder how it would look like in practice? The cleanup after the xz issue was simply to revert in git and reupload. How can such "rollback" work be made easier or faster? Detection of oddities in upstream tarballs can for sure be made easier when git-buildpackage is used correctly, and having more team-maintenance as actual teams with reviews will help prevent problems slipping through. I can't come up with ideas how to make roll backs easier without increasing the risk of rollbacks of rollbacks, but perhaps somebody else can brainstorm this area.
