On Mon, 13 Dec 2021 at 09:06, zyx <z...@gmx.us> wrote: > Could you remind me why you made a fork of the PoDoFo project?
You probably read my lengthy pdfmm introduction[1]. I can add that as a part of a contract I'm working on I'm required to enlarge the feature set and scope of the original PoDoFo library. I realized the development pace required to implement these features in a timely manner is incompatible with the current development state of PoDoFo, where the focus is being put in security fixes, API stability and compiler support as part of being packaged in Linux distributions. I would have loved to push all these new features and bugfixes in PoDoFo upstream code, but the first citizen Unicode/UTF-8 API support required me more than two months (weekends included) of full time work and frenzied development, and I consider it the minimum time needed to achieve the improvements and cleaning that were introduced. The amount of regressions, subsequently fixed, and the API modifications introduced have been huge (pdfmm requires a C++17 compilers and also uses some C++20 features, like span/fmt/date). It would be irresponsible to expose the current users of PoDoFo to such heavy changes in such a short time frame, breaking all the tools and the unit tests as well. I began to fix the latter only couple of weeks ago and I still have to finish. > Did you ever tried to ask Dominik about taking over the project? He's > willing to give commit rights. He gave it to mabri, because it seemed > he'll be active on the project. That worked for some time, but then has > got muted. I thought about it, but I didn't ask for. In short I prefer first to show my vision of what a C++ PDF manipulation library should be like in the 2020s instead of promising that I will take care of merging patches and do security fixes, while doing all the other stuff that I'm much more interested (and already erode all my working and free time) in a community driven development process. I admit maybe I'm not cut out for that kind of commitment in a open source project. My current pace and general lack of time "require" me to add untested code, stupidly breaking the API, causing avoidable regressions and fix all of these abominations 1,2 or 3 commits later. This could change with time when I'm done with my current targets. If there's a common interest, at a later stage, I could think about proposing to reconsolidate all my work in a community driven PoDoFo2 project that will take care of porting all the tools, which I basically left behind in pdfmm, and offers a degree of API stability that is compatible with releasing in Linux distributions. I cannot promise the same amount of commitment in dealing with security fixes and regular patches review duties, though. Also I have some considerations to add about current licensing in PoDoFo, but I would like to discuss this in a separate thread another time. > If it was my reviews and the way I make them that discouraged you, then > I think it's not fair for the PoDoFo project as such. There's nothing personal with you and your reviews actually helped me understanding what I should better check before sending a contribution in a open source project. It's true that some commentary on some topics (like the already mentioned C++11 compiler support) didn't help me in trying to be more open about what I was doing with the PoDoFo codebase, but this again could be a communicative limit on my side. Regards, Francesco [1] https://www.mail-archive.com/podofo-users@lists.sourceforge.net/msg04628.html _______________________________________________ Podofo-users mailing list Podofo-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/podofo-users
