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

Pierre wrote: > On Thu, 20 Oct 2005 20:50:57 -0000 > mj@php.net ("Martin Jansen") wrote: > > >>mj Thu Oct 20 16:50:57 2005 EDT >> >> Modified files: >> /pearweb/public_html/trackback trackback-admin.php >> Log: >> * This should fix approving and deleting trackbacks. >> >> # Guess who broke it ... > > > I think I did, while trying to fix/clean/secure this horrible thing. > > But seems to be very used.... The gulty commit is certainly this one: > $Id: trackback-admin.php,v 1.7 2005/01/29 17:46:33 pajoye Exp $ > > But well, who cares anyway? I think the answer to this is anyone who experiences a broken webpage as a result, no? The point is that as core PEAR developers, we are held to the same standard that others are. 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 :). I wonder if it might make sense to start thinking seriously about the future of cvs.php.net/pearweb and peclweb. We all agree that the code is security hole-laden, difficult to maintain or test, and very difficult to port. I'd like to investigate alternatives. As it stands now Chiara_PEAR_Server is not at all a good alternative. 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. I have a small team working on getting important features implemented, and think that after some refactoring with a pearweb-specific backend, it could be easily dropped in as a replacement for pearweb or peclweb. However, I am the first to admit that it needs a whole lotta redoing. A lot of it is weekend code that is fugly and needs serious re-factoring, documenting, and testing. This is where pearweb team comes in. Why not focus website efforts on getting this code to be usable as a channel server and then use it for PEAR and PECL? Once basic security holes are patched up at pearweb, we can focus more heavily on a much lighter web backend/frontend. A potential roadmap might include: - attempt to unify the database formats of pearweb and PEAR_Server, in any way possible - de-couple non-essential features from pearweb so that they can work independent of pearweb (i.e. remove calls to stuff in pear-database.php, and remove dependence on pear-prepend from PEPr, bug database, etc.) - develop a frontend for PEAR_Server that is pear.php.net-specific, and one that is pecl.php.net-specific - take the horrendous mess that is the administrative backend for PEAR_Server and make it beautiful and template-based. - use ApacheTest to develop a test suite for PEAR_Server. - use ApacheTest to develop a test suite for pear.php.net - make the website installable as a package, and remove the stupid cvs sync. These last three points are hugely important for obvious reasons. 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. Greg