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 81171F3A for ; Wed, 5 Sep 2018 13:35:55 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1463DA8 for ; Wed, 5 Sep 2018 13:35:54 +0000 (UTC) Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 7177FAE6B for ; Wed, 5 Sep 2018 13:35:53 +0000 (UTC) Date: Wed, 05 Sep 2018 15:35:53 +0200 Message-ID: From: Takashi Iwai To: ksummit-discuss@lists.linuxfoundation.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [Ksummit-discuss] [MAINTAINER SUMMIT] How can we treat staging drivers better? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , The staging driver is a wonderful process to promote the downstream code to the upstream, but I have doubt whether it's working really as expected for now. - Often the drivers live forever in staging although they should have been moved to the upper, properly maintained, subsystems. - Code changes in staging are mostly only scratching surfaces, minor code style cleanups, etc, what checkpatch suggests. - There are little communications with the corresponding subsystem; already a few times I was surprised by casually finding a staging driver code by grepping for preparing API changes. - Then some drivers are pushed back after long time stay in staging (lustre is the recent remarkable case); it's understandable, but is definitely no happy end in both sides, after all. So, I'd like to hear how we can improve the staging driver situation, a better communication with staging driver people and the subsystem / core devs. thanks, Takashi