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: [RFC] recipe owners
Date: Wed, 28 Jul 2010 18:40:06 -0700	[thread overview]
Message-ID: <4C50DBF6.6040807@mentor.com> (raw)
In-Reply-To: <AANLkTin-WKHX0m7yU7pLGFV=g2X6kwcCdYEEUJ541SKq@mail.gmail.com>

Frans Meulenbroeks wrote:
> 2010/7/27 Chris Larson <clarson@kergoth.com>
> 
>> On Tue, Jul 27, 2010 at 3:19 AM, Frans Meulenbroeks <
>> fransmeulenbroeks@gmail.com> wrote:
>>
>>> PS: I think part of the problem is that most recipes do not have a
>>> well-defined owner who is responsible for maintaining them. I know we use
>>> to
>>> have them  mentioned in the recipes. That had some issues, but at least
>> it
>>> was more clear who felt responsible for what, and it was also more clear
>>> who
>>> to bother to fix a recipe (and it was more clear which recipes are
>> orphaned
>>> or become orphaned when the maintainer leaves).
>>
>> I very strongly agree with this, but there have been issues with it in the
>> past, due to people leaving the project, vacations, hiatus, they become a
>> bottleneck.  But conceptually, maintainership seems like a very good idea
>> to
>> me.  If I considered myself the maintainer of a set of recipes, I'd do my
>> best to ensure that they're always buildable and the recipes are always up
>> with current conventions.  *shrug*
>>
> 
> Chris, thanks for your reply.
> I've turned this into a separate thread.
> 
> I'm well aware of the issues that caused us to leave recipe owners (and move
> to the MAINTAINERS file).
> However for lots of recipes it is now completely in limbo who maintains them
> (if anyone).
> As such the current solution seems to be less than the solution with
> maintainer(s) per recipe.
> 
> Wrt the issues you mention: I understand this. It is unavoidable that people
> e.g. leave, so we could take that into account.
> Some ideas to tackle this:
>  - still allow others to do small changes even if the maintainer cannot be
> contacted (this is what to some  (this is similar to what we have in our
> current commit policy:
> 
>  * It's fine to fix a recipe you don't maintain, but its polite to talk to
>    any else actively maintaining that recipe. Try to contact the maintainer
>    or, if no maintainer is listed, send a note to the OE developer mailing list.
> 
> - if people maintain a recipe but they become non-responsive without known
> cause (e.g. no holidays, known issues, business trips, ...) the recipe
> becomes orphaned and someone can step up to become the new maintainer (I
> assume that someone is interested in the recipe, otherwise the orphanage of
> the recipe would probably not be noticed). Btw: it is quite ok for me if a
> recipe has >1 maintainer (and for core recipes I would even encourage that).
> We can define some terms to quantify non-responsiveness if needed (e.g. not
> responding to ML messages concerning your recipes for 3 weeks)
> 
> What do others feel about this ?

I think this could help in some ways.  But here's the other problem I 
see.  There's a handful of complex recipes and a handful of complex 
classes that support recipes.  But by and large recipes are short and 
shouldn't be hard to understand.  So if there's a problem, fix a 
problem.  Most people, I hope, should feel OK editing most recipes.

That said, we shouldn't be too afraid to remove recipes.  We've got an 
scm and any given recipe shouldn't be more than a git revert <hash> 
along with a follow up commit to fix things from coming back.

-- 
Tom Rini
Mentor Graphics Corporation




  reply	other threads:[~2010-07-29  1:40 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-28  6:37 [RFC] recipe owners Frans Meulenbroeks
2010-07-29  1:40 ` Tom Rini [this message]
2010-07-29  2:40   ` Chris Larson
2010-07-29  7:52     ` Michael 'Mickey' Lauer
2010-07-29  6:41   ` Frans Meulenbroeks

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=4C50DBF6.6040807@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.