Richard Lowe wrote: > 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).
What happens when the changeset is the roll-up of changes from multiple people, or does Mercurial not work like that? And if someone does a merge, aren't they the author of the resulting merge? >> 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. I have no information about webrti, so I can't really comment. >> 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? No, they will have to have an account, they will have to have registered a SSH key, they will have to have registered a SCA, they will have to have raised a RTI and I'm assuming someone will have to grant them permission to commit to a given repo somehow. The existing scm console probably won't work very well for the number of likely commiters to ON (hundreds) as, for example, there are no facilities for searching or paginating the user lists associated with a repository. The Auth webapp on the other hand is being designed to allow management of 100,000+ users. >> 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. No, but there needs to be a substantive discussion about it *before* we get much further. >> 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. That's what I am concerned about. > 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? Sounds reasonable. The question is, are those attributes the same as the current Project Lead / Project Committer ones, or do we need something separate, and if so, how is that information going to be managed and where is it going to be held? -- Alan Burlison --
