All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: OE TSC Meeting 2011/02/21 Minutes
Date: Thu, 24 Feb 2011 09:20:36 -0700	[thread overview]
Message-ID: <4D668554.4050307@mentor.com> (raw)
In-Reply-To: <AANLkTim-WprzRfvaYnFMjoR4=19hj96qp3NioMjY0Axi@mail.gmail.com>

On 02/24/2011 01:20 AM, Frans Meulenbroeks wrote:
> Dear Richard,
>
> Thanks for the minutes.
>
> Below are a few suggestions/questions.
>
> 2011/2/23 Richard Purdie<richard.purdie@linuxfoundation.org>:
> [...]
>>
>> It was agreed to use a pull model for oecore with RP taking the top of
>> the pull tree role. For meta-oe, there was a lot of argument for
>> starting to use a pull model there too in an effort to also improve
>> quality, but, the TSC recognised this might be the cause of friction. It
>> was agreed to trial this for meta-oe whilst it becomes established and
>> to actively solicit member feedback on how this works out. It should be
>> stressed this is just a trial at this point.
>
> This raises a few questions and remarks:
> - I think we should try to come to some guidelines/suggestions/help on
> how to handle this from a developer viewpoint.
> This might e.g. be some additions to the git phrasebook, but I can
> imagine we also want to do (or refer to) some starter docs on how to
> set up a git, and some tips and tricks on how to work with it in a way
> that is convenient for the puller. E.g. "how to be a good oe-core git
> provider".
> (btw I am quite a n00b when it comes to git, so I am definitely not
> volunteering to write this section as i do not feel capable to do so).
> - What about reviews? OE now has an ack/nack review policy (at least
> for toolchain related parts)
> - who will take the pull master role for meta-oe
> - what about patches submitted to the mailing list? Do we expect the
> pull master to pick them up?  Or will the yocto people deal with
> mailed patches (for oe-core that is)?
> Or another scenario?

Not clear in the summary but from the logs is that we want to, as part 
of making this be transparent, publish guidelines for how this will 
work, based on what poky is doing now.  The high level plan is to follow 
the contrib tree model that poky has which means sending pull requests 
(which in turn also post the patches to the ML for review).

For changes that don't have a tree to pull from, someone with write 
access would need to pick them up.

-- 
Tom Rini
Mentor Graphics Corporation



  reply	other threads:[~2011-02-24 16:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-23 19:48 OE TSC Meeting 2011/02/21 Minutes Richard Purdie
2011-02-24  8:20 ` Frans Meulenbroeks
2011-02-24 16:20   ` Tom Rini [this message]
2011-02-24 22:55     ` OT: pull requests, merges and bisection (was: OE TSC Meeting 2011/02/21 Minutes) Paul Menzel
2011-02-24 23:33       ` Chris Larson
2011-02-25  0:24         ` OT: pull requests, merges and bisection Tom Rini

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=4D668554.4050307@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.