[Rpm-maint] Interested in helping...

[James Olin Oden]

Hi All,

I just recently got the news about this new fork() of rpm meant to be
"the" upstream source of rpm for vendors.  Frankly, I think this has
been waiting far too long and am happy to see it.  That being said I
would definately like to be a part of this and help in anyway I can,
as a representitive for my company which operates in the telophony
space.

To wit I figured I should list the sort of things that I/we are interested in:

- continue to enhance and harden the rollback mechanism.
- add tools to help manage rollbacks.
- complete perl bindings, capable of:
   - driving builds.
   - installation/upgrade.
   - reporting.
   - distribution analysis.
- better build API (haven't thought too deeply about this, but I know
I would like to
  from an API perspective drive rpm builds).
- continue to harden pre-transactional checks.
- better automatic dependency detection.
- help rpm become a more intuitive tool to use (vague, I know)
- drill in some sane way to allow for alternate policies within rpm.
- continue to harden rpm in general.

Anyway, I can't say that any decision has been made to go with this
version of rpm versus any other version yet, but I do very much like
the idea of there being a reasonably supported upstream version that
is backed by major vendors, and I would like to help with that in any
way possible.

I think the first thing I could probably start helping with is picking
up where Chip Turner left off with the perl bindings.  Rollbacks is
another discussion that we could deal with later.  I haven't read all
the information on your source control but I'll look at that and
probably have questions.

Is the help welcome?

Thanks...james