Alan Burlison <Alan.Burlison at sun.com> writes: > 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...
There are people other than project leads who may have cause to do this. With projects, whoever does a specific merge from the parent will be putting back changes they didn't author. There's also situations where people import an exported changeset as part sponsoring that change in, which will retain the authorship information of the external user (pkg are doing this). > 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. I believe webrti is replacing 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. Anyone wishing to putback to a gate on opensolaris.org must have an account on opensolaris.org. I can't think of any reasonable reason to change this. I'm aware that not everybody has an account at this moment, but I'd say it was on them to create an account for themselves. Am I missing something? > 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. Ok, well, I'm not the right person to answer much of that. > I am also not clear on who is going to manage commit rights for ON, > or how they are going to do so. To the best of my knowledge, neither are we. > 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. > Off the top of my head, and possibly entirely wrong. You'd want a way to say who may putback to a project, obviously. You'd want a way to note who the gate staff for a specific gate were (gk, tech lead, any others?) RTI would want to know who the advocates are for a specific gate, and perhaps also the gatelings? -- Rich
