Mike Kupfer wrote: > Mike> We could implement a policy [...] > > One thing to keep in mind about the policy-based approaches is that > there are situations where someone will need to push changes that > (s)he didn't commit (e.g., gatekeeper for release N+1 synching up with > the changes at the end of release N).
Hmm, perhaps something such as 'Project Leads are allowed to push changes they didn't commit' and then making only the GKers Project leads for the ON project might work... And of course, as well as the Hg hookery that's needed to make this bit of the process work, we also need to address the same sort of issues in whatever replaces webrti. We need to make some decisions about which bits of the 'Make a change to ON' process need what pieces of information, and then where they are going to get it from. For example, at the moment inside SWAN we can use LDAP lookups to map from a userid to an email, but we won't have access to SWAN LDAP when the gate moves outside, and even if we did, it doesn't have details on everyone we need to know about. I'd like to see use cases of how all this stuff is going to hang together, for example what happens right the way through from raising an RTI through to the associated commit operation, what happens when a new person joins, what happens when someone leaves (or is removed), who manages access rights and how, how auditing is performed and so forth. I am also not clear on who is going to manage commit rights for ON, or how they are going to do so. I'm assuming that some degree of cooperation with the new user management system I'm writing will be required, but at the moment there is nothing in there to manage commit rights, other than indirectly, by being able to assign people to CGs and Projects. The schema for the new application is more or less finalised and I'm working on very tight schedules, so telling me in 2 months that attribute X, table Y or feature Z is needed is unlikely to get a positive response. -- Alan Burlison --
