On Wed, 29 May 2002, Tom Jordahl wrote: > > One of the problems is that we don't *have* the experts in many areas > any more because they are (per the subject line) inactive in the > project.
That's one more reason to identify the code that is hard to understand and either refactor it or find people who understand it. People who send patches to code you don't understand are excelent candidates for this job, so instead of ignoring it would be much better to try to get more info out of them :-) No offense please - there are portions of axis that are pretty hard to understand ( even by tomcat3.0 or 4.0 standards :-). I had to debug a namespace problem ( which turned to be a trivial bug in our code ), and it was a painfull experience. Also the use of introspection in the SSL code and the lack of flexibility in that area is pretty bad, there are much cleaner solutions you can just cut&paste. ( the current code doesn't allow use of PureTLS which is much faster than JSSE, etc ) Costin > > We do have Glen, but he is only one man. :-) > > -- > Tom Jordahl > Macromedia > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 29, 2002 4:51 PM > To: [EMAIL PROTECTED] > Subject: RE: too many "inactive" committers > > > On Wed, 29 May 2002, Glyn Normington wrote: > > > change? I guess the problem is I'm hesitant to change code that I don't > > personally understand well, so I tend to leave this to the experts in a > > particular area, even though they may be too busy. Do I need to have > > thoroughly understood any change I commit or is it reasonable to put some > > trust in the submitter of the change? > > Most of the time I trust the submitter - based on the assumption that > he spent the time to write the patch and understand what's happening, > so probably he know more than I do on that area. You can ask questions - > and if someone more familiar with the code sees a problem he can > complain. > > But in general, if you can't understand the code - how are the new > people supposed to understand it ? I think the duty in this case is > a strong -1 on the code you don't unerstand ( and require a refactoring/ > more comments / better design / from those who are experts in that area). > > Costin > > >
