If you think that you can go about the software librarian business by just following the cycle described above, I am sorry to tell you that this will not be the case. If you want real software quality, you will have to invest into communication between yourself and the developers and among the developers themselves. You will want to make the goals and procedures crystal clear to everybody. You will want to make testing and other quality assurance procedures so easy that no developer or user can excuse themselves on the basis that they did not know or that it was too difficult for them. You will want to keep track of bug reports, route them to the package coordinators, and ensure they get addressed in an orderly fashion. This is not yet even a start on a big software project, but already results in a sizable amount of work.
My best advice at the moment is that you start with e-mail and the Web as your communication backbones. If you want to support distributed development, the Web is your dream come true--you just have to find the ways to exploit it. It is possible to let developers start via the Web builds on platforms they do not have. It is possible to launch test jobs to collect metrics, to analyse the code for style guide conformance, or to execute regression tests, all through the Web--the developers need not even have access to these tools (or the computing resources they take) if you cannot provide for it. Only the Web server hosts need to have access to the tools.
[FIXME: setting rules on who can access what: part of procedures]
One of the first steps you need to take in your communication with the developers is to establish release plans, probably together with the project manager. Establish goals for each significant release, and ensure that the goals will be met. If you fail, make sure you know why it happened. Take corrective action based on your findings: you may need to change future release plans, rearrange your manpower allocation or live with the deficiencies for a while.
Ideally this task will not be performed by you--at least not in your role as a software librarian--but since you are the one whose work it directly affects, you may have to make sure that it does happen. Basically this is the task of the project manager and partly that of the chief system architect, although they need your input as well. You probably need to make sure that developers provide the input to the decision makers so that the goals will be realistic, and on the other hand you may need to push your developers a bit so that the goals will be met.
The single most important issue about the planning is to be specific. State your expectations exactly. If you fail, state that exactly--but do not to criticise the people, only the results. Hiding the reality will not buy you anything, but it can make your project late and sick without anybody noticing.
Examine and use the contributed tools on your own risk. Remember that they are really contributed and not necessarily very well packaged: you may need to edit them to adjust them to your environment. Some of them contain hard-coded mail addresses and paths you will most certainly have to update before use.
This is a perfect example of post-install steps you could carry out in your boot makefiles.