Bug 263181

First look at this review :

Have a look to lastest PECL Guidelines (approved but not yet inline) :
http://fedoraproject.org/wiki/PackagingDrafts/PHP

You should note :
- API check : php(zend-abi)
- Register the extension

You could have a look, in rawhide, to php-pecl-phar or php-pecl-memcache recent
package.

AS package name is svn, you must use php-pecl-svn (lowercase)

No need to "strip" library, this is done by rpmbuild (need for -debuginfo
subpackage)

No Need for the License file (Guidelines says If (and only if) the source
package includes the text of the license(s) in its own file, then that file,
containing the text of the license(s) for the package must be included in %doc)

You should also note that :
- this is a "beta" version
- no update since 2006/03
- 13 open bugs

Updated Spec URL: http://akahl.fedorapeople.org/php-pecl-svn.spec
Updated SRPM URL: http://akahl.fedorapeople.org/php-pecl-svn-0.2-2.fc7.src.rpm

Fixed issues:
- removed license file
- changed pecl name to lowercase-only
- adapted fedora php packaging guidelines
- removed redundant manual binary stripping
- renamed patch0
- added missing dependency neon-devel

--

I've been using this extension for a while and it works quite well for me, I'm
using it in both standard and custom Phing tasks. Do you think it's not suitable
for inclusion because of the apparently immature state it was left in once?

I think the issue is that you as the maintainer of a package with no upstream
need to be prepared to essentially take over development in order to fix
problems and keep the package building for new Fedora releases while the
packages that you depend on may go through incompatible API changes and such.

That said, the updated package looks reasonable and builds without problems.  I
would most likely approve it with some minor tweaks, but it's important to make
sure you understand the responsibilities that come with an inactive upstream.

After considering your explanations for a while, I start to understand the
implications. At least the source code of php-pecl-Svn doesn't look cryptic, it
is just quantity because it needs to expose the whole API of Subversion to PHP,
thus I'd have to learn the module API and rewrite lots of code as soon as there
are such incompatible API changes on either side as you've mentioned. 

Now I have to weigh up the use of this package to the community against the work
caused by becoming de facto upstream myself and I must say I'm not sure about this.

Jason, do you think many people will need pecl Svn?

I honestly can't say.  I don't know a whole lot about PHP.

That said, the state you'd be in is not really uncommon; upstream developers go
away all the time, and all you can do is deal with it when it happens.  You say
you've been using and relying on the software so you're probably in a far better
position than most to work on it.  The situation we're really trying to prevent
by asking these difficult questions is the inclusion of software in Fedora  that
ends up being completely unmaintained, with accumulating bugs which all involved
lack the ability to fix.  Plus the security team eventually has to fix every
security-related bug that isn't fixed by someone else regardless of how much we
have to learn about PHP internals in the process.

Of course, if things get bad enough we'll just drop the software and everything
that depends on it in the next Fedora release, but we always want to avoid doing
that kind of thing because it's not nice to the end users to have software
disappear between releases.

Don't forget that this is a community and you can always ask for help; my advice
is to try to talk to the maintainers of other PHP packages and see if they'd be
willing to help you out if you need it.

Thank you for your insightful thoughts, Jason. After some consideration I think
I'm going to focus on packages more useful to the community, or helping out by
reviewing myself.