For X in gpt globus-core globus-libtool globus-openssl globus-common globus-common-setup globus-gsi-openssl-error globus-gsi-proxy-ssl globus-openssl-module globus-gsi-cert-utils globus-gsi-sysconfig globus-gsi-callback globus-gsi-credential globus-gsi-proxy-core globus-gssapi-gsi globus-callout globus-gss-assist gssapi-error globus-xio globus-io globus-ftp-control globus-ftp-client globus-gass-transfer globus-gass-copy globus-proxy-utils globus-rsl globus-rsl-assist globus-rls-client globus-usage globus-rls-server globus-rls-server-setup; do
Spec URL: http://www.grid.tsl.uu.se/repos/globus/fedora/9/info/$X.spec
SRPM URL: http://www.grid.tsl.uu.se/repos/globus/fedora/9/src/SRPMS/$X-*.*-0.1.fc9.src.rpm
The Globus Toolkit is an open source software toolkit used for building Grid systems and applications. It is being developed by the Globus Alliance and many others all over the world. A growing number of projects and companies are using the Globus Toolkit to unlock the potential of grids for their cause.
First submission - seeking sponsor.
This is...not going to work.
You need to submit one review ticket per package. You should submit a small
number of packages at a time, only a couple at first, so that you won't have to
revise 50 review tickets to incorporate review feedback which applies to
multiple tickets and to simply avoid bombing the reviewer pool (which is not
very large). You should set up proper dependencies on the tickets so that the
reviewers will know what to review first and in which order.
So you seem to have completely ignored my request about only submitting a couple
of tickets initially to avoid bombing the reviewer pool. Any particular reason why?
I had prepared the following comment for this ticket, but got a "mid-air collision" due to your comment #2
"OK, I have now made individual tickets for the first 15 packages. I hope this is not too much to start with.
I'll do the rest later when I have some feedback from this first batch."
So I guess you thought 15 was too much... My reason for choosing this set was that there would be some
useful programs in the first set and not only libraries.
For the packages which carry modified tarballs from upstream we need to have one of the following happen:
* Find out if upstream is willing to release multiple tarballs per component. Since they release multiple tarballs for their updates, this might not be a problem for them to do. having these split up will also help other distributions to package this software so it's something we should ask upstream about no matter what the results of the other option are.
* Get a ruling from the Packaging committee about whether this is a case where the tarball can be split up by us or if we have to use the vanilla upstream tarball. This is definitely not one of the cases envisioned by the FPC for the current Guidelines. However, it could be a new use case that they will add to the Guidelines. But you'll have to make your case.
Mattias has proposed:
I'm closing this as there's no package to review; sthe guidelines were approved, separate review tickets were filed properly and things are moving into the distribution.