Frans Meulenbroeks wrote:
2010/7/27 Chris Larson <[email protected]>
On Tue, Jul 27, 2010 at 3:19 AM, Frans Meulenbroeks <
[email protected]> 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
_______________________________________________
Openembedded-devel mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel