Packaging Open Journal System for Debian

[jerico]

I've seen that HEAD of the pkp project contains further libraries:
- jQuery
- phputf8
- PHP Quick Profiler
- parts of the Zend framework

Will all of these be required to run OJS 2.3.x?

[asmecher]

Hi Florian,

The parts of the Zend Framework that are included are unmodified and are optional (currently only used by the PKP Harvester, and that in the form of an optional plugin). Likewise, JQuery is unmodified, but we'll be using it more and more as time progresses so it's likely to be a required library if it isn't already.

The profiler is optional, but I believe it's been modified for compatibility with PHP4.

I'll check if the phputf8 library is stock or if we've modified that -- stay tuned. It's required.

Regards,
Alec Smecher
Public Knowledge Project Team

[asmecher]

Hi Florian,

We'll do our best to help with this as time permits -- it is a lot of work, but it would be wonderful to see it pay off.

I asked our guy who works on UTF8 issues about the PHPUTF8 library and he says it should be unmodified. However, PQP is indeed heavily modified and probably won't be easy to reconcile. If it's an issue, I'd suggest leaving it out of the Debian package entirely, since it's optional.

Meanwhile, I'll get back onto the ADODB guys about incorporating some of the patches. As a secondary solution, having Debian incorporate the patches would be fine with me, but I don't know how much work it would entail -- obviously the best solution would be to have the original maintainer integrate them.

Regards,
Alec Smecher
Public Knowledge Project Team

[jerico]

I asked our guy who works on UTF8 issues about the PHPUTF8 library and he says it should be unmodified.

ok, great.

However, PQP is indeed heavily modified and probably won't be easy to reconcile. If it's an issue, I'd suggest leaving it out of the Debian package entirely, since it's optional.

This would be ok. We do this often in such a case.

obviously the best solution would be to have the original maintainer integrate them.

I agree.

Another question out of interest: How do you currently integrate upstream changes (bug fixes, security fixes, feature upgrades) into your modified software? Isn't this a big maintenance issue? I have so far always avoided modifying upstream software in a way that doesn't allow for automatic merges of upstream releases. If you maintained a set of patches (as you did when you started to fix ADOdb) it would be easier to keep track of upstream changes and it will be a lot easier to maintain the Debian package.

[asmecher]

Hi Jerico,

We've unfortunately fallen a bit behind in terms of integrating upstream releases of libraries, and for the stable releases we're likely to keep things as they are; however, for the development line, we'll be keeping more up-to-date and will be returning to maintaining current patch files against the upstream release to ease transitions between library releases. In our stable releases, we've been maintaining several copies of nearly identical code (i.e. between OJS and OCS), which imposes major maintenance overhead; now that this has been reconciled into a separate library, we'll be a bit more nimble.

Regards,
Alec Smecher
Public Knowledge Project Team

[jerico]

we'll be keeping more up-to-date and will be returning to maintaining current patch files against the upstream release

This sounds great! BTW, won a new OJS customer yesterday. I've got some urgent project things to resolve here. But soon I'll start to help you sort out the compatibility layer for ADOdb.

Florian

[asmecher]

Hi Florian,

Great -- meanwhile, Matt on our team has provided some of our modifications to the Smarty maintainers in the hopes that they'll be able to pick some of it up.

Regards,
Alec Smecher
Public Knowledge Project Team

[asmecher]

Hi Florian,

One more question -- we're trying to keep our intellectual property as clear as possible at the moment, as we're clearing up a few details. Would it be acceptable to you if we credited you in the code headers, but left the copyrights assigned to John Willinsky as per the rest of the code?

Regards,
Alec Smecher
Public Knowledge Project Team

[jerico]

Would it be acceptable to you if we credited you in the code headers, but left the copyrights assigned to John Willinsky as per the rest of the code?

This is ok for me, but it probably won't reliably protect you from copyright issues once you try to depart from the license under which community members contributed. AFAIK copyright is unalineable in most jurisdictions of the world. Just not mentioning authors' copyright doesn't mean that it ceases to exist. IMHO you just introduce some legal uncertainty for your users if you don't make them fully aware of the copyright holders of your code. I am not a lawyer though and my opinion is based on the legal systems I know a little better.

I'll however license all my contributions to OJS under the GPL v2 (or later if you like) which is your usual license anyway. Therefore this shouldn't be a problem as long as your software always remains free (in the sense of the GPL). I wouldn't contribute if you could make my code proprietary one day. (Have a look at Alfresco if you want and example of what kind of hassle you have to organize for your community contributors if you want to coerce them into providing proprietary code.)

[asmecher]

Hi Florian,

Not to worry -- we have no plans to move away from GPL; we're considering how/when/if to transfer copyright over to Public Knowledge Project officially, and the fewer individuals named under copyright in the code, the easier it'll be to coordinate.

Regards,
Alec Smecher
Public Knowledge Project Team

[jerico]

Hi Alec,

today and on the weekend I'll have time to take care of the ADOdb bugs. I just wanted to make sure beforehand that we don't duplicate efforts. AFAICS you've not started to work on these bugs, did you?

I think we should continue to package the stable branch (2.2.x). But before I write patches: Is it ok for you to introduce a compatibility layer into the 2.2.x branch? Or is this too intrusive for a maintenance branch?

Florian

[asmecher]

Hi Florian,

That sounds great; I'll watch out for those bugzilla entries and comment on anything that comes to mind.

Could you describe what you have in mind for a compatibility layer?

Regards,
Alec Smecher
Public Knowledge Project Team

[jerico]

Could you describe what you have in mind for a compatibility layer?

A patch says more than 1000 words. I'll attach it to #4357.

[jerico]

Patch has been attached to #4357, I'll now start to create patches that require the compatibility layer to be installed. I'll just do one or two examples so that you can comment before I go on.

[jerico]

Hi Alec!

Have you already considered introducing unit tests (PHPUnit or the like)? I am missing them quite dearly while doing regression testing for my compatibility layer changes. Now that you are introducing a shared framework unit tests may be even more useful. (Maybe they exist and I just didn't see them?)

Florian