Re: cvs: pearweb /public_html/trackback trackback-admin.php

On Fri, 21 Oct 2005 22:43:55 -0400, Greg Beaver wrote: > I think the best thing to do is to test prior to commit, or to post a > patch and ask for testing if it's not possible to test. Committing a > broken patch is far worse than not committing a possible fix. > > Committing broken code to the live website that represents the PEAR > project is a really big deal, which brings me to a another point: why is > this even *possible*? We all know the answer, but I think it is not a > good one :). This is more the question about security then about if the code broke or not, I'd think that for Pierre to do this all by him self on a private server or even if we helped would have taken way too much time compare to the security issues we had before register globals was turned off, so I rather want to have a half broken site that we fix on the fly (i.e. when we spot the issues, be it in the code or on the site it self) then have massive security problems that could lead to worse PR and just plain problems if someone exploits these problems. > As it stands now Chiara_PEAR_Server is not at all a good alternative. That would be right. > The package uses a customized database instead of the pearweb one. In > addition, it has no unit tests and requires PHP 5. When it is ready, it > can be aptly named PEAR_Server or PEAR_Channel_Server, or whatever, > obviously. Last time I saw it had like 5x backends, kinda mind buggling. > I have a small team working on getting important features implemented, [a lot of chit chat here] > These last three points are hugely important for obvious reasons. Well I'm not all that sure if I'd be interested in seeing the channel server on pear or pecl, it would have to out preform pearweb quite a lot before I'd even consider it, compare to now it's not even handling half of the load PEAR has and even tho the current code is weekend hacks and such, well pearweb is not what one calls a master piece you know. > Until we get those implemented, we must be more stringent about > committing bad code. I propose a new policy for pearweb: > > 1) if you haven't tested the code, don't commit it 2) if you can't test > it, post a patch to pear-webmaster 3) if you've tested it, commit it 4) > if it's obvious you haven't tested it, you get a warning. On the second > commit of obviously untested code, your cvs karma is revoked for 4 > weeks, minimum. > > I don't think we need to be overly harsh about this. For folks who are > admins, I think a self-imposed revocation would be enough (sort of a > penance by posting patches and not committing for 4 weeks). Everyone > makes mistakes, but it is important to take responsibility for them so > we don't build up resentment in any way. Are you trying to keep the webmaster team intact or what ? Seriously, we are not that many that we can just put some month probation on each other, at the best we are 5 all in all that do anything and it's every now and then that any one of those 5 actually has time, it's hard enough to get people to work on PEAR code but the pearweb code, that's almost impossible, keep that in mind and rethink that policy. - Helgi