Geekosophical

Nearly three months ago now I left Australia and moved to New Zealand. I was fortunate enough to essentially transfer within the company I work for, so it was reasonably painless (except for the 9 weeks of waiting for my boxes of stuff to get shipped).

The office here is significantly larger than the Australian office (being where the company started and all) and I’m really enjoying having lots of smart people around and getting to work on a much larger variety of projects.

As with how these things go in free/libre/opensource-land, one can accidentally get involved in the projects of colleagues.

Libravatar is an AGPL federated alternative for the Gravatar service, allowing domain holders to serve their own avatars for email and openid from their own infrastructure, rather than trusting external closed services. Francois will be presenting about it at OSCON. He has stickers.

One of the things we’re working on to make for better adoption of Libravatar is making sure there are libraries available for various languages so applications can incorporate it as easily as they can Gravatar (or easier!). I volunteered to have a crack at making a PEAR package.

I’d never done PEAR before. The documentation is somewhat obscure, but I found a good article on, of all places, Zend.com.

So that’s sweet. Write your class (in the correct file structure), copy and customise the makepackage.php file from the docs for PEAR_PackageFileManager2 (pear install PEAR_PackageFileManager2), run php makepackage.php make to generate the xml build instructions (which expire at midnight for fun!) and then simply pear package. Voila, you made a PEAR package. Amazingly simple once you know how.

The next part, however, isn’t simple.

If you want your package to be in the Official PEAR Channel, you have to walk over some burning coals, hop through a ring of fire and some random other tribulations thrown in for good measure.

The easiest of this is getting your code to comply with the PEAR Coding Standards. I strongly recommend employing phpcs aka PHP_CodeSniffer (it’s a PEAR package! pear install PHP_CodeSniffer).

You may be tempted to have some documentation generated with phpdoc in your actual package. Because it’s useful and will make your stuff more usable. You can’t. The .css files don’t pass the PHP_CodeSniffer PEAR standards tests. It took me nearly a month to get a definitive answer on whether it was possible to keep them in.

The next part is the peer review. I first proposed the package about a month ago. I got some suggestions about style, some pointing at the coding standards and file structure, and a suggestion to depend on a PEAR package to do what a core php function does better. Because of php 5.2. Which is EOL’d. I refused the dependency for dependency sake suggestion. Because, lolwat?

What this review stage didn’t pick up was a handful of bugs that made the package not work right. They’ve been fixed.

Earlier this week I moved the proposal to the voting stage. Now, apparently, this is where the code review actually starts. So far I’ve had suggestions to… basically rewrite it, and dependency for dependency sake, again. This was stated as conditional for a +1 vote.

Sigh.

Well, I’ll see how it goes. I cannot see technical reasoning other than preference for the suggestions, and nor can others who are fed up with the PEAR proposal process just from watching me go through it. Even if it fails to get into the main PEAR channel, it’s not game over.

Back when I was looking for an answer as to whether I could keep the phpdoc generated documentation in the package, I asked a friend who is involved in the php community if she knew. She asked around for me, and the overwhelming response she got was that PEAR was out of fashion because of the politics, and to not bother. Given how other languages successfully manage to have extension management, and how predominant php is, it’s truly a crying shame.

The cpan library and pypi library have been available for a while now either as part of the gravatar library (cpan) or independently (pypi). PEAR doesn’t even offer a Gravatar library. Just sayin’!

I’m in the web development business. I realise fully that consolidating signon stuff is complex and all that but surely, surely, there’s got to be something better than this:

1. Clicking a login link on Ubuntu wiki to tend to a page.
2. Being told that the “OpenID verification requires that you click this button”
3. Being redirected to a form for my username and password.
4. Being logged in and reaching the SSO profile page with the list of places I’ve logged in to ever. No indication of a “where you tried to log in to” link.
5. Clicking the wiki.ubuntu.com one because that’s where I was trying to get to.
6. Getting sent to the front page of wiki.ubuntu.com… logged out.
7. Clicking the login link, again.
8. Being told that the “OpenID verification requires that you click this button”
9. Confirm that the information on the screen is me.
10. Getting sent back to the wiki.ubuntu.com front page.
11. Now all I have to do is find the page I was trying to edit.

I’m really hoping this was not normal operation, or I that did something wrong.

Is this really what our new contributors face?

Please say no. Pretty please. With a cherry…