From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by mail.openembedded.org (Postfix) with ESMTP id DA2036041D; Fri, 26 Jul 2013 14:54:20 +0000 (UTC) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 26 Jul 2013 07:54:21 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,752,1367996400"; d="scan'208";a="376607053" Received: from unknown (HELO helios.localnet) ([10.252.122.182]) by fmsmga002.fm.intel.com with ESMTP; 26 Jul 2013 07:54:20 -0700 From: Paul Eggleton To: Phil Blundell , openembedded-members@lists.openembedded.org Date: Fri, 26 Jul 2013 15:54:19 +0100 Message-ID: <2088951.PevEKBo15A@helios> Organization: Intel Corporation User-Agent: KMail/4.10.5 (Linux/3.8.0-26-generic; KDE/4.10.5; i686; ; ) In-Reply-To: <1374793592.2861.60.camel@pb-ThinkPad-R50e> References: <1371572589.20823.143.camel@ted> <51DB0A16.7090103@mentor.com> <1374793592.2861.60.camel@pb-ThinkPad-R50e> MIME-Version: 1.0 Cc: tsc@lists.openembedded.org, openembedded-core@lists.openembedded.org Subject: Re: OE, the TSC and the future X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 14:54:21 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday 26 July 2013 00:06:32 Phil Blundell wrote: > On Mon, 2013-07-08 at 13:51 -0500, Sean Hudson wrote: > > it seems to me that the need for a group to > > arbitrate on technical matters is valuable enough, by itself, to keep > > the TSC. > > This applies even if that function is utilized infrequently. > > I remain slightly dubious about that, not least because the TSC's recent > track record in terms of having its decisions implemented hasn't been > entirely stellar. As far as recent history goes, my recollection is we've only had one decision (on shell function indentation) that was backed out by maintainers. I think I speak not just for myself when I say those on the TSC that were opposed didn't feel it was big enough of an issue to try to battle for the original decision to be upheld. That doesn't mean that we aren't prepared to resolve technical disputes in future, as per the original TSC mandate, nor does it mean that there won't be a need for that in future. > It's also been quite noticeable that, except for Richard (who started > this thread), none of the current members of the TSC have offered any > opinion on what the future role of that body ought to be or what value > it brings. I guess I hadn't responded yet because I felt like this thread was for others outside the TSC to express their thoughts first. > > In considering the future of the TSC, I offer the opinion that in the > > future, > > tactical concerns shouldn't be the primary business for the TSC. Rather, > > I'd like to see the TSC become more strategically focused. In particular, > > I'd like > > to have the TSC produce a vision for OE in the 2-3 year time frame > > ... this is a good suggestion; I'm sure we'd benefit from a bit more of > a strategic vision and perhaps this is indeed the direction that the TSC > ought to evolve in. FWIW, I agree. I don't think we should necessarily lose sight of the TSC as a body for resolving technical disputes however. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre