Last modified 3 years ago
Table of Contents
- Participants
- Agenda
- Status of work for 1.9.5
- New info service/info provider
- Active/passive fixes for SRM client
- Moving tape protection inside pool manager
- PnfsManager based listing in SRM
- Refactoring of Pin manager
- Terracotta and SRM
- PnfsManager based listing in dirDomain
- PnfsManager based permission handling in all doors
- new http door with https support
- xrootd mover reimplementation
- the p2p trigger-on-load
- Policy on fixing bugs in branch
- Issues from yesterday's Tier-1 meeting
- Outstanding RT Tickets
- Review of RB requests
- DTNM
[part of a series of meetings]
Participants
Agenda
[see box to the side]
Status of work for 1.9.5
A (quick?) review of activity needed for the 1.9.5 release
New info service/info provider
Active/passive fixes for SRM client
Moving tape protection inside pool manager
PnfsManager based listing in SRM
Refactoring of Pin manager
Terracotta and SRM
PnfsManager based listing in dirDomain
PnfsManager based permission handling in all doors
What happens with PnfsManager without ACLs
new http door with https support
xrootd mover reimplementation
the p2p trigger-on-load
Policy on fixing bugs in branch
Currently policy: changes must be bug-fixes to go into a patch-level release.
However, can a bug-fix be "too big" to go into a patch-level fix? If so, when does it become too big.
RB #536 is an example of a change that might be considered too big.
Issues from yesterday's Tier-1 meeting
Outstanding RT Tickets
[This is an auto-generated item]
Review of RB requests
DTNM
Proposed: same time, next week.
