Alan Burlison <Alan.Burlison at sun.com> writes: > 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?
They are the author of the merge, but they are still transferring N other changesets (the bits they merged in), the majority of which they will not be the author of. >>> 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. Well, that was the idea they mentioned on scm-migration-dev not so long ago. We actually pointed them in your direction (well, website-discuss) so they could figure out how to do authentication. >>> 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.p >> >> 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. Ah, then I completely misunderstood the paragraph above. >>> 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 agree entirely. Much of the problem is that there are 3 or 4 closely related projects intending to deliver not necessarily together (scm, dts, rti, your auth bits). Each of us, I believe, hoping that our connection to the other 3 could be minimized. >>> 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? I would assume it would be held in the auth systems, but I'm not certain of that. I don't believe that the gate staff are the same as a project leader, at least as far as I make such distinctions. The webapp, historically, makes them very differently however. Advocates, certainly, aren't "anyone who's a project leader", the gk's aren't advocates, and neither are various other leaders of, for instance, onnv. I think the ability to putback (as far as auth is concerned) doesn't need change, though anyone with that ability needs the ability to file an RTI. There's no reason I can think of to prevent someone who *can't* putback filing an RTI. Given that would further reduce the burdon on sponsors. We would like to be able to prevent any putback without an associated RTI, which in most practical cases would be far more restrictive than any per-user auth (I imagine no more than 4 or 5 people ever having the real ability to put something back at the same time), that isn't possible to implement at this time, however, but it seemed worth mentioning. -- Rich
