I am currently in Zurich, after spending the last week in a farmers house in the moutains of Switzerland. This is a pretty relaxing time for me, although I am constantly working on tweaking my thesis paper (actually its not a thesis paper, its a german "Diplomarbeit"). I am more or less done and now I am just working on getting the kinks and typos out.
Aside from that it looks like I will unfortunately not make it to the international PHP and OpenDB conference this year. My proposals were not accepted and all this time spend on my thesis paper cut into my finances a bit. Anyways I want to stress again how important conferences on open source databases are in my opinion. But I am really hopeful that next year we might even see two conferences, one in north american and another one in europe. Stay tuned!
Aside from that I have followed through with my plan of stepping down from active PEAR development as I have announced a while ago. Actually I have not stepped down completely just yet, as I am still actively working on MDB2 for now. I guess with me and Pierre leaving it did spawn a lot of energy about how to organize PEAR in the future. I am still participating in this discussion to some extent, mainly functioning as the historian who can explain why things are the way they are etc in order to prevent people from making rash decisions or even worse repeating old mistakes.
Personally I think some of the proposals are fairly unrealistic. I think the best would be to keep the "old" PEAR around and create a new separate PEAR2 repository (this one everybody seems to agree on). A new expanded coding style regulation should be put into place for this new repository. For example, it should cover things like method naming and some of the new PHP5 OO features. It should also define minimal rules for tests and documentation. But I would not get overly strict here. We have to remember that PEAR does not have paid developers. For the most part, atleast in the past, packages were created during real world development and were submitted due benefit from user feedback. Making things too beaucratic will drastically reduce incentives to come to PEAR.
Instead I think each of the categories should manage itself more. So packages approval would be handled within the category. The same for QA'ing etc. This way new developers would not be facing this gigantic community. I think this is simply overwhelming. Even for old developers it becomes impossible to feel "at home" in a project of the size of PEAR. By splitting things up a bit, but with a common foundation in the PEAR CS, things will become a lot more "human". If necessary representatives of each of the categories could also more efficiently discuss large cross category decisions. Of course people could be members of multiple categories at the same time. Anyways, those are just my ideas and the important bit is that those people investing their time right now find a setup they are comfortable with.
For example, it should cover things like method naming and some of the new PHP5 OO features. It should also define minimal rules for tests and documentation. But I would not get overly strict here. We have to remember that PEAR does not have paid developers.
There are quite a few developers writing code for free who do unit tests. Why not try to communicate the benefits of doing so?
OTOH, since I don't participate in PEAR at all, you might choose to ignore me!