[oe] Package Maintenance

[Frans Meulenbroeks]

Having read all of the responses let me explain the (admittedly
chaotic) way I work.

My interest is mostly in application packages. I added several recipes
for them in the past.
Also I've been using several packages that were already present (e.g.
for the beagleboard james project).
If I start doing so, I typically check whether the package is more or
less current. If the package is at 1.3 and the src is already at 2.4
I've updated the package if possible (as I felt it was probably
orphaned). Mainly I did so because I needed a newer version of that
package, but I do not desire to take ownership of all those packages.

If I find a trivial problem in a package that can be repaired easily
and with a low risk I also tend to fix it (e.g. a missing DEPENDS).
This is mostly independent of the package.
Not sure if that is the right way though.

Generally my attitude is: if you need something and detect that is
broken, don't whine about it, but fix it if possible (probably asking
advice on #oe or the mailing list)
And of course in due time I learned who to consult/contact/push for
specific packages.

Wrt the statistics to get a (proposed) maintainer. Good idea.
And if there is a (near) draw: As far as I am concerned it would be
perfectly ok if a package has two maintainers.

One last note. sometimes I created packages just because another
package needed them. My interest in that package is then a little bit
secondary. E.g.if I want package A and it does not exist I create it,
and if A needs B I probably need to create that one too, but keeping B
up to date might be less interesting if A does not need the newer B.

and a last last thing: about the vetting: not sure whether I fully
understand the idea, but is a lot of this info on what builds on what
not already present in tinderbox?

Frans