SRM Review
quick turn-around for SRM/dCache releases or patches:
it might be possible to release patch rpm that updates just one jar or batch, this should be dependent on particular rpm presence.
Having an ability for making quick emergency releases by any member of the team is desirable. Therefor we need a document.http://trac.dcache.org/projects/dcache/wiki/manuals/Release_and_Test and http://trac.dcache.org/projects/dcache/wiki/manuals/Release_lite.

decouple SRM/dCache releases and rpms:
Team: Not a good idea.

Exception handling is not very good as logged - site administrators are having a difficult time analyzing problems. The same is true with messages SRM returns back to the client. e.g. timeout when there is a missing host cert. All should look at SRM client and exit codes (fails with 0 exit code so can't script it but must parse output). Be considerate of backwards compatibility:
We continuously identify and remove problems. Specific reports would be a great help. Gerd:  we all should read our own log files when we come back home from the workshop. 

The system should tune as many parameters as possible dynamically based on
the configuration (system and hardware capabilities):
Certain complexity corresponds to features and can not be avoided. Reducing the number of configuration parameters can reduce number of configuration errors. Closed or opened control systems can calculate many parameters dynamically and automatically. Gerd: Even pool assignment (read/write/stage) could be automated. Patrick: If we are serious about implementing dynamic parameter selection and assignments of roles, where do we begin? Gerd: we could start with pool manager, create tags that are dynamically assigned to pools. Pools need to advertise their capabilities. 
Agreement: to make things simpler (reduce number of configuration parameters and  tune the system dinamically) for administrators we need to solve the hard problems ourselves via smart algorithms. 

Per user resource utilization limits (Pins, Space Reservations):
PAtrick: Production user should be able to go over the limits. We either honor the request or return an error, no partial lifetimes based on internal limits. Maximum lifetime per role may be required.