On how to fork a GNOME Core app without meaning to do so

And if you did not know already, that Core app is Evince, now renamed to Papers and submitted to Incubation this week. But if you’re still interested after the spoiler, let’s start from the beginning.

From some hacky patches to 80+ Merge Requests

How it all started

So for anybody that does not know me, I have been until now foremost a postmarketOS maintainer. GNOME is my platform of choice, and we often encounter bugs downstream. However, postmarketOS’s policy is upstream first, so I ended up doing a lot of things in GNOME. Most of those were small patches for various projects, and many of the issues we had with sizing and Phone usage have been polished through the years with help from people all across the stack. A big chunk of those was fixed through GTK4 ports and implementing new libadwaita patterns and widgets. However, Evince seemed to have been stuck on porting to GTK4, and we were still carrying some ugly patches. So I tried to do my best, and more than 1 and a half year ago pushed my first MR. What followed was a roller-coaster of emotions.

How it all continued

Sending a first patch to a project is something I have learned to really enjoy. It has that mix of excitement for the unknown, looking forward to that this is great, thanks, and the knowledge that I will certainly learn something in the process. But since one patch would not get a massive GTK4 MR solved, I did not stop there, and continue pushing MRs. After some time, I learned some things:

• Germán was the only active maintainer. So sometimes, things would move fast and he would merge a bunch of my MRs altogether. And sometimes they would stay there without a comment for weeks. And certainly time to answer questions and get me on-boarded into decades-old Evince code was certainly sparse. The few times he was able to, I learned a bunch, but it was still too little for the time I had available.
• Evince code is old, for the good, and for the bad. For the good, it concentrates the wisdom of years of development creating a Document Viewer. The authors had taken and tested many design decisions, and overall created a very solid application. For the bad, there was code that probably already existed in pre-glib times. And many things that are now straight-forward to do, had been re-implemented in a custom way. I am still very proud of having removed some non-functional code that if alive would have the right to vote in most countries that do.
• Evince is not just an application, but two libraries, libdocument and libview, which must remain stable. So many of the cleanups I would have wished to do would had to wait.

All these things created a dynamic where: I would have lots of time and motivation; hack in Evince to do some cleanups and forward-port stuff from the GTK4 MR; feel super happy about it and send some MRs; wait for some period that felt long to get any feedback; get totally demotivated about it; sometimes wait some more weeks until getting feedback, context-switching to something else; then get some feedback, but feel bad about it; finally get some motivation back, address the feedback, and back to the beginning. Of course, this wasn’t sustainable.

Getting help and reaching for help

In the middle of this process, FOSDEM 2023 happened. And it was a wonderful experience. I got to meet all these postmarketOS people I had been working with for more than a year, as well as many GNOME people from whom I knew, but that were certainly less aware of me. Despite that, everybody was super welcoming, and encouraging. And specially Tobias pushed me a bit and managed to get me apply for a grant (that I did not get) to improve Evince. In that process, we tried to approach Germán to talk, and see how could I help with Evince from a more “maintainership” role. Unfortunately, that did not work out. However, that did not solve the adaptability problems for Evince in mobile, so I had to continue trying.

Through all this process, Qiu Wenbo, the author of Evince’s GTK4 port, had continued to tirelessly rebase the GTK4 port on whichever changes we did. And we started to interact, as I moved from back-porting things to reviewing their MR more in-depth. But we still would not get where we wanted to be at full-speed with Germán’s limited time availability. So I reached to the Release Team at GUADEC, and then again some months later, and managed to schedule a very nice call with Germán. We talked about Evince, how would it be possible for me to help, and he created the evince-next branch. There it was (and still is) allowed to break the libraries’ API, remove deprecated functions and be less conservative. Of course, Qiu Wenbo and I sent a lot of MRs, and I tried to get myself entitled to merge stuff, but I was certainly not the main maintainer, and most things still needed Germán’s review. At some point, things to back-port run out. Any work I would like to do would require some hard and careful rebase of the GTK4 branch, and Qiu Wenbo had already context-switched to improvements after the port. It was clear, unfortunately, that the amount of human-power we were able to provide was well above Germán’s availability, and therefore, the changes we were dreaming of likely not fitting within Evince.

From a casual chat to Incubation in less than two months

Forking was an option that had been suggested to me since FOSDEM, and reiterated multiple times later. At first, I did not feel ready to take over the code-base. And when I did, I was terrified to do so alone. So mid-December, I asked Qiu Wenbo if he would be willing to fork and maintain the fork with me, with the goal of porting to GTK4, implement new mockups, and modernize the application. He was extremely enthusiastic about the idea, so we started to work on it, notifying both the Release Team and Germán. Our goal was getting the GTK4 MR in by the (gregorian) New Year, to then take care of the breakage later. And I have to admit, the results of the fork are already surpassing all my expectations. In less than 2 months, we’ve managed to merge close to 40 MRs, and already got some external contributors (Chris and FineFindus, yay!), with more people having showed interest. We also started the rebranding (still missing a slick icon!), and this week, applied with Papers for Incubation.

So the overall outcome, nowadays, is net positive. Although it will all depend a bit on the Incubation phase. At the same time, a fork is most of the times the result of some sort of failure. Probably not just of us individual contributors, but of the community as a whole. It is also a big shame to not have Germán next to us in this process. He holds extremely valuable knowledge about PDFs and documents in general, and certainly avoided me messing up more than once. At the same time, life is life, and we’re all volunteers doing our best. I can say, I am sincerely thankful from everything he has taught me, and wish him success in their endeavors. For us, we hope to see Papers flourish, and encourage others to jump on the train to make a modern, adaptive, touch, and multi-device-friendly document viewer for GNOME.

Happy Hacking!