Best way to help a maintainer?

[Michael Schwendt]

On Wed, 01 Feb 2006 10:22:16 +0000, Andy Burns wrote:

> For a few packages in extras I've filed bugs, made patches and build 
> rpms locally to fix bugs, upgrade versions or see if rebuilds are all 
> that is required to get packages working again.
> 
> It is obvious that some (all!) maintainers are busy, that is fair 
> enough, we all have "day jobs" that will get priority, but sometimes 
> it's frustrating to have helped out (only a tiny bit) and yet it doesn't 
> lead to an updated package becoming available.
> 
> I'm not talking about situations where a packages needs "rescuing" by 
> having a new maintainer, A) who's to say that new is better, B) I don't 
> want to seem ungrateful for the work of the maintainers.
> 
> In general, what is the best way to see if any patch/upgrades that I 
> think are beneficial, are really the whole story, i.e. will work on 
> multiple arches, won't confuse the build system and are not retrograde 
> changes?

In theory, any well-made package that builds locally for you, _should_
also build in the FE build system (provided that build dependencies are
complete). Testing the binaries at run-time is the other side of the
story, however. Many packagers don't have access to more than a single
platform. They rely on the upstream projects and on feedback which they
get for upgrades published in Fedora Extras Development some time before
they perform upgrades for older FC versions.

> As a non-maintainer, is it possible to do this all locally, is plague 
> required, can we have access to the build system, just to be able to 
> test out patches up to the point where it possible to hand it back to 
> the maintainer, as a hopefully simple option for them to verify and 
> commit it?

Running test-builds in "mock" should suffice. For many packages, running
ordinary rpmbuilds should be enough.

> I suppose I'm asking is the situation, one package, one maintainer, one 
> bottleneck?

I cannot repeat it often enough. There is always the opportunity to build
small teams of people who maintain a package together, provided they share
thoughts and common ways of packaging up things. If different people only
stepped on eachother's feet by reformatting spec files and by applying lots
of other unimportant changes, a team would not become possible. Just talk
to the current official package owner and find out. Also, it may be that
the owner might give away a package if he gets the impression that a
dedicated new package owner would be beneficial. The current "owners.list"
in CVS already has the possbility to enter multiple people to CC in
new bugzilla tickets.