On Sun Nov 24, 2024 at 4:45 AM CET, Otto Kekäläinen wrote: > > [ 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).
The "given enough eyeballs" always happened after the fact though. People scratched their own itch and wanted to publish the fruits of their work on their own schedule. See also the single maintainer in Nebraska meme. Allocating resources to code review means higher quality results, but probably less results overall. > I don't subscribe to turnaround time requirements. We don't have > deadlines like in corporations. People are already annoyed at not getting things done. Of course some of it is also due to us requiring review from a selected few (think NEW, or DSA for infrastructure changes), rather than the developer base at large. > 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. Good things come to those who wait. At the same time being able to quickly make changes when you have time and not context switch away for weeks until someone else had time to get back to you is a valuable motivator. I agree that in a team - and not a one-person show - the expectations can (and probably should) be different. > 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. Question is if it makes things worse. > 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? Or, you know, have other people around with enough spoons. [ Easier rollbacks ] > 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. That isn't entirely true. For a brief period we thought we needed to rollback and then recompile the archive to a state of many months prior. We would not have known how to do that, especially when it comes to versioning. The best we have to rollback packages is to push an entirely new build with a +really version (or an epoch). At no point it is "just a revert in git" or - the gold standard - a revert to the package built previously (it might also have been miscompiled). In enterprise environments the answer is pinning >= 1000. And keeping packages simple enough that downgrades keep working. I remember a couple of times where the Release team stepped in and reverted maintainer actions that were unfortunately timed - which comes with a large risk of conflict. We have fared ok with the current approach, but it is not an environment of "rollback first, ask questions later" - the overhead is high. Kind regards Philipp Kern
