Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Sean Hudson <sean_hudson@mentor.com>
To: <openembedded-members@lists.openembedded.org>
Cc: tsc <tsc@lists.openembedded.org>,
	openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: OE, the TSC and the future
Date: Mon, 8 Jul 2013 13:51:02 -0500	[thread overview]
Message-ID: <51DB0A16.7090103@mentor.com> (raw)
In-Reply-To: <1373068016.2074.72.camel@pb-ThinkPad-R50e>

On 7/5/13 6:46 PM, Phil Blundell wrote:
> On Tue, 2013-06-18 at 17:23 +0100, Richard Purdie wrote:
>> In brief summary the TSC has been doing two main things, acting as a
>> task force and also being able to make a decision when needed. The
>> latter has not happened much at all, the main work was as a task force
>> on various issues, firstly engaging with the Yocto Project and figuring
>> that out, more recently dealing with infrastructure issues and generally
>> ensuring the health of OE.
> It's certainly true that most of the current TSC members have been doing
> a fine job on the "task force" front and I think we'd all be glad to see
> them continue with that.  What's rather less obvious to me is whether
> they actually need to be an elected body in order to do so; any group of
> individuals who wish to form a task force are obviously free and welcome
> to do so at any time.
>
> As you note, the requirement for the TSC to actually make decisions has
> been minimal/nonexistent of late and, again, it's not totally obvious
> that having an elected body of experts on perpetual standby just in case
> a decision might be needed is entirely necessary.
>
> In the many-layered world that we now inhabit, it seems reasonable to
> let the individual layer maintainers (in consultation with their peers
> when necessary) make the decisions that they think best for their own
> trees.  Recent experience seems to suggest that, practically speaking,
> this is already what's happening and when it comes to a contest of wills
> the TSC have not shown any interest in overruling layer maintainers who
> disagree with their stated position.
>
> Plus, of course, we already have two bodies who are empowered by the OE
> e.V. statutes to make decisions, namely the board and the GA.   Both of
> these have wide discretion to do what they think best, and of course
> they can convene a panel of expert advisers if they feel that any
> particular issue needs specialist knowledge that they don't have.
>
> So, all in all, I feel that we've come to the point where the TSC (as an
> organisation) is no longer providing us with any particular benefits and
> could be disbanded without causing any real hardship.  This would avoid
> the administrative overhead of running elections for each of its seats,
> which have recently been uncontested in any case, and would also avoid a
> certain amount of potential ambiguity over where the TSC's jurisdiction
> ends and the board's starts.
>
I believe that Phil Blundell raises a valid question about the continuing
need for the TSC. However, 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.

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. As 
another
OE board member, I support Phil Balister's offer to have the 
non-technical matters
fall to the board to handle, with the caveat that the TSC becomes more 
focused on
the long term evolution and improvement of OE as a whole

Regards,
      Sean
  
Sean Hudson | Embedded Linux Architect
Mentor Embedded™
Nucleus® | Linux® | Android™ | Services | UI | Multi-OS



  reply	other threads:[~2013-07-08 18:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18 16:23 OE, the TSC and the future Richard Purdie
2013-06-27 14:48 ` Philip Balister
2013-06-27 15:38   ` Richard Purdie
2013-06-27 16:08     ` Mark Hatle
2013-07-05 23:46 ` Phil Blundell
2013-07-08 18:51   ` Sean Hudson [this message]
     [not found]     ` <1374793592.2861.60.camel@pb-ThinkPad-R50e>
2013-07-26 14:54       ` Paul Eggleton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51DB0A16.7090103@mentor.com \
    --to=sean_hudson@mentor.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=openembedded-members@lists.openembedded.org \
    --cc=tsc@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox