From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 43BBF11F1 for ; Mon, 10 Sep 2018 20:15:32 +0000 (UTC) Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6FBA793 for ; Mon, 10 Sep 2018 20:15:31 +0000 (UTC) From: Laurent Pinchart To: ksummit-discuss@lists.linuxfoundation.org Date: Mon, 10 Sep 2018 23:15:40 +0300 Message-ID: <2620504.doLR7ekjFm@avalon> In-Reply-To: References: <1536592110.4035.5.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: James Bottomley Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Monday, 10 September 2018 18:13:05 EEST Jiri Kosina wrote: > On Mon, 10 Sep 2018, James Bottomley wrote: > > 1. How do reviews happen? Non email projects tend to have only one > > review mechanism (gerrit, github, gitlab, etc.) and stick to it. Do > > we want to pick a technology or allow multiple? I don't think this > > is kernel wide, it could be a sybsystem choice. > > Yeah, but OTOH even now I've heard a lot of feedback about the irregular > contributors / newcomers being confused by different subsystems having > different processess and requirements; and those are basically just rather > "minor" things currently (bugzilla usage, patchwork usage, subscriber-only > mailinglists, etc), but it's still enough to confuse the hell out of > people. That's also one of my concerns. The differences between subsystems that all use an email-based review process can already be confusing, or just annoying to handle, especially when specific tools are mandated (the DRM dim tool or the ARM patch system come to mind). I dread to think about how painful it would be if one subsystem adopted gitlab, another one gerrit, ... That would also make changes that cross subsystem boundaries a nightmare to handle. Let's not forget that many developers are not confined within a single subsystem. On the other hand, I don't really see how switching the whole kernel to gitlab (or another system) could happen without frustrating a very large number of developers. We all know how conservative the community tend to be. One possible course of action would be to make the new tools optional and keep email as a common denominator. That way the old dinosaurs who won't adopt any tool introducing even the slightest disturbance in their work flow (it's not pleasant to realize that I may well be one of them) will still be able to work undisturbed, and all the other developers would be able to enjoy the myriad of amazing features offered by their tooling of choice. This would however put an extra burden on the new tools that would need to have first-class email compatibility. I don't know whether that would be feasible. -- Regards, Laurent Pinchart