On 04/17/2015 04:33 PM, Andrew Savchenko wrote: > On Fri, 17 Apr 2015 14:50:00 +0200 hasufell wrote: >>>> If you have followed the recent discussions about gentoos organizational >>>> structure, review workflow and overlay situation you would know that >>>> there is a pretty simple solution for this problem. >>> >>> I have followed them and I have seen no solution usable in real >>> world. >>> >> >> The solution is that for example the ruby project assigns a few >> reviewers (e.g. project lead) and if someone wants to bump ruby >> packages, he submits a pull request and the assignee is going to be the >> ruby project. What's the problem? > > The problem is double effort: previously one developer effort was > needed, now effort is doubled at least: reviewers must dig into > details how submitted code works, test it and only then commit. Now > remember that reviewers are also developers. This means that pull > requests will hang for weeks, months, forever due to a lack of time. > On top of all this thinks about maintainer-needed packages or > packages that can't be categorised into some single project, e.g. > *-misc categories. >
Not really. The depth of reviews will depend on a) what package/subsystem is it? Is it just an end-user app, is it a library, is it toolchain...? b) who sent the pull request? Was it a random user or a developer I trust? In the latter case I might just check that repoman doesn't choke and pull the stuff in. Currently... some gentoo projects who enforce strict reviews have very poor workflow. Because bugzilla is completely useless for reviews, people end up doing IRC reviews. IRC is not a proper review platform either, especially not for drive-by contributions or people who don't have time to read 500 lines of scrollback or whatever. >> Do you think the usb-subsystem maintainer of the kernel is going to >> fiddle with the cryptography subsystem all by himself? That's not the >> case. And that's why the linux kernel workflow works: competence, >> subsystems and trust. > > As I pointed above comparision of Gentoo with Linux kernel is > invalid. We have different resources. Another argument that > connectivity between subsystems is much higher in the Linux kernel. > It is perfectly valid. It is a huge system just like gentoo. The workflow in detail might differ, but in the end we deliver a system that should be coherent and work. We have little to no QA on that and our workflow is one of the fundamental things that need to be fixed if we want that to change. If people say they don't care about it, that's fine. But then I'm not sure what we need a QA team for, except for running repoman on the tree. Unfortunately, repoman cannot tell you if an ebuild wipes your hard drive in pkg_postinst. >> All that is done in real world. And there are tons of tools to automated >> such a workflow easily without dumping everything to a single mailing list. > > Reviews cannot be automated. A human being is still needed to read, > understand and test proposed code. All tools like pull requests and > so automate only a small bit of real work. > You misread. I said the WORKFLOW can be automated. There are tools to do that. Neither bugzilla, nor CVS is one of them. We have enough google employees here in gentoo, who should be fairly familiar with these things. >> Global reviews will only happen when stuff is actually of global >> importance, like non-trivial eclass changes or far-reaching technical >> decisions. > > We already have that with gentoo-dev mail list. And I'm happy with > current solution. If you can't handle patchset from e-mails, learn > houw to use tools, e.g. quilt. > You misread again. I didn't say we lack a tool for global reviews. I said that ebuild reviews must not happen randomly on a single mailing list. That would be chaos. >> Other distros successfully use such workflows. > > Other distros are binary based. Last I checked exherbo is source based and has USE flags.
