Bug 263181 - Review Request: php-pecl-Svn - PHP Subversion Wrapper
Review Request: php-pecl-Svn - PHP Subversion Wrapper
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-08-29 08:45 EDT by Alexander Kahl
Modified: 2007-11-30 17:12 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-03 18:04:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexander Kahl 2007-08-29 08:45:09 EDT
Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SPECS/php-pecl-Svn.spec
SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/7/SRPMS/php-pecl-Svn-0.2-1.fc7.src.rpm
Description: This extension implements PHP bindings for Subversion (SVN), a version control system, allowing PHP scripts to communicate with SVN repositories and working copies without direct command line calls to the svn executable.


I am still searching for a sponsor but will release all my packages step by step so you can see I'm serious about contributing.
Comment 1 Remi Collet 2007-09-09 02:15:42 EDT
First look at this review :

Have a look to lastest PECL Guidelines (approved but not yet inline) :

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

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

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
Comment 2 Alexander Kahl 2007-10-01 17:05:17 EDT
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?
Comment 3 Jason Tibbitts 2007-10-23 18:13:28 EDT
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.
Comment 4 Alexander Kahl 2007-10-25 04:08:04 EDT
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?
Comment 5 Jason Tibbitts 2007-10-25 12:03:56 EDT
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.
Comment 6 Alexander Kahl 2007-11-03 18:04:53 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.