Closed Bug 170291 (cvs_account_gisburn) Opened 22 years ago Closed 18 years ago

CVS access request for Roland Mainz

Categories

(mozilla.org :: Repository Account Requests, task)

Product:
mozilla.org
Component:
Repository Account Requests
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: roland.mainz, Assigned: marcia)

References

Details

I would like to apply for cvs write access.
I have had my code committed previously through various other people but I and
most other mozilla.org staff (for example see bug 168873 comment #4) think it's
time to get my own account (after filing a few hundred patches over the last
~~three years...).

I'll send the required paperwork via FAX this week and add a comment when it's
being done...
BTW: I'd like to have CVS access to both source tree and docserver - are there
any special things ToDo for that ?
Blocks: 85429
sr=roc+moz

I'm tired of checking in Roland's patches!
Roland: If you want docs access now, all you would need is a voucher.  If you
want to wait until you get SRs for your write access, I can always activated
your docs access at the same time.  1 SR down, 2 to go... I would suggest adding
some of your patches to this bug, or adding some SRs.
Status: NEW → ASSIGNED
sr=bzbarsky.  Just fix printing to not suck, please.  ;)
i'll vouch, i'm also tired of checking in his patches and owning blame for huge
parts of xprint :)
Alias: cvs_account_gisburn
FAX send Wed Sep 25 22:21:52 MET DST 2002.
Marcia Knous:
Did you get the FAX ?
fax received. 
sr=rbs

gisburn has been a long time contributor and, amongst other things, his tireless
effors have helped to keep the xlib port alive in the midst of those earthquakes
that often happen in the Mozilla codebase as we know.

<nice-to-have>
A short e-mail address so that the tabular listing of checkin comments in bonsai
remain readable after he is granted checkin rights. His e-mail is going to mess
mozilla.org's "New Checkins" link :-)
</nice-to-have>
rbs wrote:
> sr=rbs

Thanks!
> <nice-to-have>
> A short e-mail address so that the tabular listing of checkin comments in 
> bonsai remain readable after he is granted checkin rights. His e-mail is going
> to mess mozilla.org's "New Checkins" link :-)
> </nice-to-have>

I can't help here much, it's the domain name which makes my email that long (I
already used "gisburn" instead of "roland.mainz" in the FAX to save some space),
but it cannot be made shorter without risking that our X.500 may not be able to
find the full email address.
For the log:
(Always) Up-to-date contact information is available from
http://www-x500.uni-giessen.de:8890/Rcn%3dRoland%20Mainz%2cou%3dinformatik%2cou%3dFB11%2co%3dUniversitaet%20Giessen%2cc%3dDE
Marcia Knous:
What will happen next ?
As always, in the monthly SR meetings, we consider all undecided nominations for
CVS write access and/or SR status and discuss as a group.  In the SR meeting
held on 26 September 2002, we discussed providing Roland Mainz (gisburn) with
CVS write access to the mozilla repository.  Though some SR's approved, there
was a tenor of reluctance.  One negative factor cited is Roland's tendency to
(want to) push patches through even when review or super-review has highlighted
some weakness, with intent to `fix it in the next patch' (see, for instance,
http://bugzilla.mozilla.org/show_bug.cgi?id=71587#c23 and
http://bugzilla.mozilla.org/show_bug.cgi?id=82486).  Enthusiasm is a valuable
resource, and Roland has plenty of it.  In fact, too much.  In this case it
colored his judgement; in other cases it has colored his ability to communicate.

It would be easy, though wrong and un-happy for everybody, if you took this as
some kind of personal slight, Roland.  Hopefully, it never occurred to you to
take this personally.  Our general policy is that when there is reasonable
question about CVS write access in the SR meeting, that we don't provide access
for that candidate at that time.  We don't want this potentially temporary
denial to stop you from working on mozilla.  So don't take this personally, but
_do_ take this professionally: you are a prolific and enthusiastic contributor,
but as a group, SRs would like to see you deepen some of the secondary skills so
valuable on projects of this size --- communication/interaction (that is,
without overwhelming the people you are trying to communicate with), good value
judgement applied to the scope and applicability of patches, and even the code
near to the fixes you implement.  Obviously, for some SRs, you already meet the
criteria we expect from CVS committers, so you may not have far to go to sway
the others.  If you continue to submit patches, and strive to demonstrate your
good judgement and communications skills, then this could be just a temporary
delay, and not a permanent denial.

'FUTURE' doesn't seem to be one of the bug resolutions anymore.  'INVALID' seems
insulting in this case, and neither 'FIXED' nor 'WORKSFORME' seem to express the
current state.  I'm going to close this bug as 'WONTFIX' to take it out of the
queue until the concensus is to re-open it.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
OK, a simple question:
I am getting pestered since _months_ by many many people to get my own CVS Write
account to avoid that others have to care about that (which takes huge amounts
of my own and other engineers time, one reason why my bug list is contantly
growing (currently 75 bugs, and I was hoping that I can - with the help of this
CVS Account - reduce that to at least the half until december (remember that I
was trying to cut my work on Mozilla down to 1-2h/day; seeking for someone to
checkin, preparing, discussion, begging etc. currently takes 2-3days/patch))) -
and then this request gets a WONTFIX.
That's looks a little bit silly.
scott: later was removed, there never was a future resolution, it has always
been a target milestone.
Target Milestone: --- → Future
err
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Roland, scc has pretty much summed up the situation.  We all agree that you're
doing valuable work and the problem was that some people had some reservations
about your willingness to address review comments....  I, personally, would
appreciate it if you just went ahead and proved them wrong in their estimates of
your ability to work with the review system.
Boris Zbarsky wrote:
> scc has pretty much summed up the situation.  We all agree that you're
> doing valuable work and the problem was that some people had some reservations
> about your willingness to address review comments.... 

This comment is simply INVALID[1] since I said (and promised that more than
once) not to checkin any patch which has not it's r=/sr=/a=/etc. stamp.

Getting patches checked-in is one of the most time consuming part of doing
contributions to mozilla.org and prevents me from spending this time to other -
more valuable - tasks (for example having some free time to look at older code
and doing some cleanup).

[1]=just to note:
1.  The example given above is ~~18 months old, e.g. half the time I am
contributing to mozilla.org
2. The followup bug (bug 82486) was never assigned to me
3. The problem described in the bug doesn't really effect users (the "possible"
buffer overflow would require to paste more than a few thousand(!!) to the
matching input field (read bug 82486 comment #6)). We've discussed the bug
up&down and finally decided to fix it "some day".
4. Please give me the name of at least _one_ person with CVS write permision who
don't have such dead bugs lying around. Obviously there is no such person. Noone
is perfect.
Just to say this that you don't forget it:
I have _FIXED_ tons of other "simple" issues (object&&memory leaks, buffer
overflows, non-existing or wrong error checking, compiler problems, getting rid
of obsolete code and much much more...) in the past as part of my other bugs or
new bugs I investigated and filed even if it wasn't my job or part of the bug I
was working on just to clean up the _mess_ OTHERS have caused. And I have
usually have cleaned-up the issues I have caused, too.

And NOW I am PUNISHED for one of my OLD mistakes which got forgotten long long
ago.
The bug scc cited was just one (the most memorable) of a number of instances of
a problem that I ran into when I reviewed your code.  Those problems were often
related to your insistence that your patches be checked in immediately whether
they were correct or not -- an attitude that you claimed was caused by your use
of source tarballs rather than cvs, which makes managing changes much more
difficult.

Are you now using anonymous cvs to manage your changes?  (Judging from a sample
size of one bug that you've fixed in the past month, bug 168043, you aren't.)  
When you do, perhaps some of us who refused to review your code in the past (due
to the problems I mentioned in the previous paragraph) might be willing to try
working with you again.  And, frankly, since it seems that you don't, I'd like
to see evidence that you can work well with anonymous cvs before grating you the
keys to writable cvs.
One more (more light-hearted, perhaps) note, in response to comment 14.  Getting
cvs access won't (at least if not misused) reduce the amount of time it takes to
get the reviews necessary to get something checked in.  In fact, it will
probably reduce the percentage of your time working on Mozilla that you spend
working on writing code, since you'll have to spend more time watching the tree
than you used to.

Most of the time I spend working on Mozilla is not writing code.  It's analyzing
and commenting on bugs, describing my own code, asking for reviews and
super-reviews, checking in, watching the tree, and doing reviews, super-reviews,
and approvals for other people.
Marcia, I hope you don't mind if I change this to ASSIGNED from REOPENED status.

/be
Status: REOPENED → ASSIGNED
Target Milestone: Future → ---
no activity since 2002. Closing this one out due to inactivity. Please free to reopen if you disagree.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 18 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.