Richard Lowe wrote: >> 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.
What do the Hg hooks 'see' as the userid? >> 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. I haven't heard from them yet. >>>> 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. Well, I'm working on the assumption that everyone will have co communicate with the Auth application ;-) >> 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. At the moment I hold information about CGs and Projects. I also hold information about SCAs. Nothing else. > 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. There's nothing in the database at present to represent gate staff or advocates. However it *is* possible to define new collectives as well as relationships between the new and any existing collectives, without requiring application changes. We could therefore use the Auth application to manage 2 new collective types - Gatekeepers and Advocates. If you look at http://src.opensolaris.org/source/xref/website/auth/trunk/AuthDB/src/sql/populate_db.sql#73 onwards you can see how this is all modelled in the database. We can add new stuff in easily, but it needs to be thought about and carefully designed. > 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. Good point. > 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. It might be reasonable to hold the 'Who can potentially raise RTIs & commit changes' info in the Auth database, but the list of who has 'in flight' RTIs would probably be better if it was managed by the RTI application. Yet another question is if we should just subsume the committer management bit of the current SCM console into the Auth webapp, leaving the SCM console just to manage the process of creating the actual repositories. All the existing webapps are going to require rework to fit in wit the new Auth framework, that might be a good time to reconsider what functionality goes where. -- Alan Burlison --
