This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Please address this urgently, as we are close to a beta release and cannot afford to have unauthorized, unreviewed changes. There has been a source commit in the web module by "genero" who is a member with observer access but who does not have developer access. There has also been a source commit in the j2eeserver module by "capSS" who is not a member of this module at all. I will attach the CVS logs.
Created attachment 13149 [details] CVS commit logs
Both genero and capSS have "grandfather" access, hence are allowed to commit anywhere. I've never heard of either of them, and I did not grant them that access. Policy is to mail nbdev with any new requests for grandfather access, unfortunately I think not everyone follows this procedure. I can't find any posts to nbdev including those usernames. There are very few people who could have granted this access - I'm cc'ing some of them. New cc-ees, do you know : a) who they are b) who granted them grandfather c) if they really should have grandfather I'm assuming the commits weren't malicious - we can always contact them and ask for an explanation ?
I strongly agree that for all users with grandfather access, we should know the identity of these users. Is it possible to at least find out when they were granted grandfather access, if not by whom? I think there were good intentions behind those commits, however, when we are close to the release cycle, there should be some shared understanding regarding the direction of the codeline.
Ok, now we know the identity of both these users - they are contractors from a sustaining group in Russia, but it would still be useful to find out how they got grandfather access.
Also, although the commits are not malicious, they have been updating bugs, marking bugs as invalid or enhancements based on a misunderstanding of what the bug report meant. It is very time consuming for us to have to reopen bugs because of these invalid assessments.
Well I was hoping for an update telling us who gave htem the privs by now ... I'm not sure what to do here. They are real users, someone gave them grandfather for some reason, so we can't just remove the accts. I also can't just remove commit privs to web & j2ee, it would be better to know explicitly what modules they need commit perms for, and then just add them (and nothing else). Wow I just found that the "Audit log" in SourceCast works! For a very long time it has been broken. Anyway, I've found who granted this access (the same person did for both accounts), and I'll need to ask them for details of why. Ana, Petr, what would you like to do ? Is removal of their commit privs to the modules in question necessary, or is the answer just better communication/policy on who commits where ?
It sounds to me that these contributors were given commit privileges by virtue of being Sun contractors. It's not necessary to remove commit privileges now, there are other means how we can address our issues (solution already in progress).
OK. Looks like we might change the way grandfather roles are handled, or even remove the role alltogether. That's another discussion ... but in the short, what to do with this issue ?
Changing to INVALID, as this is clearly not the infrastructure bug, but our process issue. Will address it in a different way.
We recently moved out from Collabnet's infrastructure