Discussions about how to organize further maintenance of this library

[k00ni]

Based on the latest commit in master (over a year old) as well as 16 pending pull requests, i assume @smalot is not maintaining this library anymore. That's fine, he will have his reasons.

In this issue i would like to discuss where the community around this library should continue the work? There are some who already developed their own strain, for instance:

• @amooij with https://github.com/amooij/pdfparser
• @gyselroth with https://github.com/gyselroth/pdfparser
• @lausek with https://github.com/lausek/pdfparser
• @limweb with https://github.com/limweb/pdfparser

Found them using https://github.com/smalot/pdfparser/network

Any ideas?

---

EDIT: Removed fork from @lausek (ref).

[lausek]

My fork does not contain any changes of value. Sorry.

[amooij]

We actively use this library for internal projects and we've fixed several issues, but we don't have the resources to become the lead maintainer. We are more than willing to share all our work.

…

On Wed, Apr 15, 2020 at 1:46 PM lausek ***@***.***> wrote: My fork does not contain any changes of value. Sorry. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#286 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADYMTFTFUDQR4OI2X5U75DRMWNDBANCNFSM4MIOUOTA> .

[k00ni]

That sounds great! I can support with ~1 hour per week to help with organizing issues, tests and pull requests.

@smalot it would be nice to hear what you plan / think.

[NoxxieNl]

I moved to a paid service setasign.com, does everything I need as a reader and soooo much more, maybe that is an option?

[k00ni]

Thank you for the tip, but i dont think that this is an option for everyone. For myself, the current state of pdfparser works decent, but switching could be an option, sure.

[NoxxieNl]

You could go for the free version that support til pdf v1.4 (everything above is in the paid service). Fpdi is the package, for trading works great and integrates with allot of writer packages also.

Better alternative for my taste and those packages are better maintained, not saying you should move away, but a pdf parser is Allot of work... :)

Just my 2 cents...

[smalot]

Hi all,
Indeed, I'm not as available as before. I'll try to validate some PR or make some feedback if needed.
Thanks

[j0k3r]

@smalot maybe you can add one or two maintainers so they will ba able to help you.

[smalot]

Hi @j0k3r , I noticed you work at 20 minutes
Would you be interesting in working on this project ?

[k00ni]

Dont forget the post from @amooij

Quote:

We actively use this library for internal projects and we've fixed several
issues, but we don't have the resources to become the lead maintainer. We
are more than willing to share all our work.

[smalot]

That sounds great! I can support with ~1 hour per week to help with organizing issues, tests and pull requests.

@smalot it would be nice to hear what you plan / think.

Hi @k00ni
I just sent you an invite to work on this project if you are still interested on

[smalot]

Hi @amooij
I just sent too an invite to you if you have time to spend on this library

[k00ni]

@smalot, thank you for the invite.

I saw that you invited further people besides me. How do you want to organize this repository with you and 3+ further maintainers/helpers? Any preferences?

[j0k3r]

Maybe you should first define at least one approval review to merge a PR.

It means at least 1 person have checked the code and if a maintainer submit a PR, at least 2 maintainers have seen the code.

[smalot]

This library is very used and followed. I don't know if TDD is a good solution, but in the past I saw PR with bad approach using strpos instead of preg_match which could break some syntax patterns or some other issues.
I tried to cover it with some useful unit tests. So I would appreciate to continue to maintain quality as first goal.

@j0k3r made a good suggestion.

Currently you seems to be more aware about real issues and have more time to spend on this library to make it alive.
In my company we use to validate PR with 👍 ou 👎 to indicate if more work is required or if we can merge. Being 3 or 4 can create a useful debate for any evolution.

What do you think about it ?

[k00ni]

I support @j0k3r's suggestions, but it shouldn't matter who made a PR. For me at least the approval (+ review) of 1 maintainer is sufficient.

We should aim for basic but long term oriented "rules", because everyone of us mostly likely has a job and life too. So i would suggest we start with:

• new pull request: 1 approval of a maintainer is enough for a merge (besides no objections by failing tests etc.)
• new issue: maintainer may add/remove labels, moderate and take care of things
• new release: I'd say if needed. All maintainer can file a draft and open an issue to discuss it.

Besides these, i would suggest that we try to setup tooling to automate as much as possible. Hound checks PR's and helps with code reviews. @smalot: Can you add support for https://coveralls.io so that we have an overview about the test coverage? Here is a good tutorial: https://kizu514.com/blog/setting-up-coveralls-io-with-travis-ci-and-phpunit/
I am sure there are other tools, which can make our life easier.

My 2 cents, what do you think?

[smalot]

Currently, unit tests are made using Atoum which was quite enough until now.
http://atoum.org/
You can run unit test and code coverage using this command line:

./vendor/bin/atoum -d src/Smalot/PdfParser/Tests/

I tried to increase code coverage, but I agree that's not a goal by itself.
That's why I've included some pdf sample to test in real conditions.
Last reports are available here : https://travis-ci.org/github/smalot/pdfparser

[k00ni]

Is a switch to PHPUnit an option for you @smalot?

[j0k3r]

I'm 👍to move to PHPUnit.
Also adding https://scrutinizer-ci.com/ could be a good thing.

[smalot]

I've just reactivated my scrutinizer account:
https://scrutinizer-ci.com/g/smalot/pdfparser

don't hesitate if you need specific settings on this tools

[smalot]

No problem to use PHPUnit instead of Atoum, but I'm not sure to have time to work on it.
The main advantage I found about Atoum when I choose it, it is really strict about typing.
I suppose PHPUnit is too a good tool, but I'm not aware about all its capacities

[smalot]

It should be interesting to move Tests into a specific namespace and folder declared only in "autoload-dev".
I let you create a dedicated issue to follow the work

[smalot]

I granted you a "Developer Access" on Scrutinizer.
I hope it help you

[rubenvanerk]

Any plans on closing some issues? There are issues that are last updated over 6 years ago and questions for which an answer is no longer needed.
I'm interested in helping with some issues but there are a lot and it's not clear which issues need attention and which do not.

[k00ni]

Hi @rubenvanerk, i am still in the process of getting a birds eye view. Therefore i am focusing on recent issues and PRs and trying to get in touch with people to solve things. As you can see, not all responded.

The most important PRs for me are my own (#299, #300) for now, so we have a stable basement in the long run. I also prefer pull requests like #297, where the author is cooperative and helpful.

On the issue side: bug reports and issues about missing functionality should be handled with priority. Questions and everything else is secondary to me, due to lack of time.

If you wanna help it would be cool if you check issues and comment on it with an status update. For instance, an answer is no longer needed, because ... or something like that. @j0k3r or me can later decide how we handle it.

What do you think?

[rubenvanerk]

I think I'm just going to work through the issues from most recent to least recent.
I assume you and @j0k3r are monitoring the issues from time to time? Or should I tag you when I think an issue can be closed?

[j0k3r]

We monitor them :)

[k00ni]

@j0k3r and the others, what features and plans do you have or working on? Maybe we can coordinate up front and help each other?

Ref: #306

For me: i am good for now and don't plan anything particular. But i am still available for issues and PRs.

[j0k3r]

I don’t want to work on sth particular. Just wanted to provide enough tools to ease the maintain of the lib (phpunit, cs-fixer, phpstan, etc).

[k00ni]

I wanna make a proposal: If one of the collaborators assigns himself to a PR, he will take care of merge.

Also, a PR should be kept open for a while, so that our community has a chance to comment. Even after it is ready to be merged, a window of 1+ week 2-3 days should be used to allow further comments. Closing it right away prevents that possibility.

Hope that is fine with you guys.

[k00ni]

@amooij I saw that you received collaborator rights but saw no activity from you in the last couple of months, which is totally fine. I propose we limit collaborator rights to active people to keep it simple and organized. What do you think?

CC @smalot

[k00ni]

I just want to let you know, that I wont have much spare time to spend here in the near future. If I can I will help out here and there, but for the most part I am not available.

[siims-biz]

The last comment is from last year.
Did the state of information change? @smalot @amooij @k00ni

[k00ni]

In general the state is basically the same, @smalot is not available and we maintain this library in our spare time. Luckily we get pull requests from time to time so there is some development and optimization of the library. I try to help out here and there.

Did you mean something in particular?

[jzohrab]

Hi all here, I’m interested in this library for my php project, and could spend some cycles here. I haven’t even looked at the code, but this project shows up high in google results :-) My initial primary interest would be to add some integration level tests, basically parsing some real PHP files, if that’s not already there. (tests appear to be present, using files in samples/bugs). Then closing old issues because there are some that are very old. For existing maintainers, any suggestions on getting up to speed to become part of the team? Cheers! Jz

[k00ni]

Hello @jzohrab it is good to see interest in helping out here! Let me get you up to speed by introducing you to the current situation. Afterwards I will explain our processes and for what we aiming for.

Overview

Let me give you a short overview how things are going at the moment first. Currently @j0k3r and I are working as maintainers in our spare time, @smalot (owner of this repository) is not available. He gave us enough rights to maintain most of the repository, like merging code, label issues etc. Most of the contributions come from the community on a regular basis: We just released 2.6.0 with further fixes and new functionality (meta data). There is no project plan for this library, things get added/changed, if something breaks or someone wants a certain functionality. All in all, for the future I would aim to make the parser feature complete so it supports latest PDF specifications and fix all the stupid bugs, which there are many currently (many encoding/decoding issues lately).

Contributions

We introduced some standards a while ago, like coding style checks (using PHP-CS-Fixer) and static code analyzer (PHPStan). These and other precautions were intended to aid stable development and avoid some cliffs. All checks must be green for any new pull request. I value clear code, meaningful comments on code, references to specifications and a good test coverage. Usually we receive complex system(?) tests using a PDF file, but a handful of unit tests can also be sufficient sometimes. It depends on the type of contribution. Because this library is developed in no particular direction, it is crucial that at least each addition/change is documented in some way and references prior/related work.

Where to start?

I suggest you start by looking up latest merged pull request and get a feel how we managed them. @GreyWyvern did a good job in #606 for instance. Then its up to you, in my opinion the following areas should be addressed:

• Encoding issues: There are a lot of encoding issues, I managed to mark some of them: https://github.com/smalot/pdfparser/issues?q=is%3Aopen+is%3Aissue+label%3A%22de-%2Fencoding+issue%22+
• Test infrastructure:
  • Scrutinizer keeps failing for months, see Fix failing Scrutinizer CI tests #591. It provides good code analysis, that's why I would like to fix it. solved by Fixes Scrutinizer integration (mostly failing tests) #682
  • Check https://scrutinizer-ci.com/g/smalot/pdfparser/code-structure/master/hot-spots and https://scrutinizer-ci.com/g/smalot/pdfparser/issues/master to see open issues/problems with the code (e.g. unused code, performance problems, low test coverage)
  • Improve PHPStan level, currently its 3 of 10 (https://github.com/smalot/pdfparser/blob/master/phpstan.neon). Static code analysis helps tremendously and can detect errors one didn't think of. Each level increase provides benefits.
• Checking old bugs (e.g. trying the example again with latest code) and give feedback if the bug still exists would also be helpful.

Feel free to ask any questions. I try to comment/help out in your issues/pull requests whenever I have the time.

[k00ni]

Big shout out to @GreyWyvern: Thank you very much for all the work you have been doing in the last weeks! I am glad that we have a community here that contributes on a regular basis and is constructive and helpful. 👍

I wanted to write you via your homepage first but your contact form raised a deprecation warning and stopped working ...?

[k00ni]

@jzohrab How is it going? Are you still interested in helping out here?

[jzohrab]

Hey there @k00ni - thanks for the note, I actually ended up moving my whole project over to python :-) I'm no longer a reliable worker bee here. Cheers and best wishes, thanks for your contributions to the open-source world. 👋

[k00ni]

@jzohrab I wish you all the best.