Looking for maintainers

[bmaupin]

@andypillip @gonejack @pgundlach @ystyle @AmandaCameron @1l0 @propan @missdeer @Onelio @lucasew

First of all, my apologies for the spam. Secondly, I'm not abandoning this project :)

I created this project because I wanted to learn Go and at the time there weren't any decent EPUB libraries for it so it seemed like something fun to do. I had big plans to use Go, but in spite of all the amazing things about Go I didn't find it very fun to use, and moved on to other languages.

I don't actually use this library any more and I didn't expect it to get so popular, but it's gotten over 100 stars and I thought it might be good to actually have the people using it be more involved, e.g.:

• Helping review and merge pull requests
  • Mostly I've been making sure that the API stays as stable as possible (or the version number is bumped as needed) and that new changes are covered by tests as best as reasonably possible
• Making decisions about the direction of the project
  • I've tried to make sure that at the very least this library generates valid EPUBs. Beyond that, is it okay if it allows users to generate EPUBs that aren't valid? Or should every effort possible be made to make sure that doesn't happen? (for example, see #24)
  • At some point this project should probably hit v1, so it would be nice to maybe figure some of this out beforehand

I'm not completely sure how this works, but I think there are a few options:

• I can add collaborators directly to this repository
• I can create an organization just for this repository and transfer it there
• I can transfer this repository to an existing organization (I did reach out to gofrs a while back about this last option but never heard anything: https://github.com/gofrs/help-requests/issues/40)

At any rate, anyone who is interested feel free to follow up here. I am going to try to make an effort in the meantime to go through the issue/PR backlog and see if I can make some progress there :crossed_fingers:

Thanks!

[lucasew]

First option seems better. You can add collaborators on the project and they can have write permission on master.

I am using this lib on a project I use often but, at least for the epub part, it's done and working nicely.

I can help occasionally but feature-wise the library looks pretty good for me, maybe some logic to download all the required files of the HTML chapter file, that I've already implemented on that project.

BTW this is the project

[1l0]

May I ask what language you moved on to? Sorry for that I'm not the one who will maintain this awesome library.

[gonejack]

Hi, author.

Glad to hear actively maintenance, I got some ideas for this project

1. EPUB readers are basically browsers across multi platforms now time, that might means EPUBCheck is kind of outdated.
2. There is something should be remove like https://github.com/bmaupin/go-epub/blob/master/epub.go#L456 which is kind of 'doing too much' as a library.

[pgundlach]

Not sure if I have anything to add to the discussion. First of all, thank you for providing this library, it is very helpful. I use it (my fork actually) regularly but haven't touched the code for quite some time. Not sure if I would be a good maintainer or if I could contribute something helpful. That said, let my try to make a few points.

• I think this library is very valuable.
• It is not a shame to mark a repository as "not maintained anymore" and close all bugs as "wont fix". This helps to identify if it is worth opening issues.
• I doubt that EPUBCheck is not useful anymore. I am not up to date with the spec but EPUBCheck finds subtle errors such as missing alt tags.
• You(?) could just mark this version as version 1.0 and be free to change the API for version 2. While nobody likes API changes, this would be the way to go.
• Someone should be the boss. If this is not the case, the danger might be that there could be endless discussions or nobody will implement anything.

I see that there are not that many open issues, these should be fixable.

[bmaupin]

@lucasew

First option seems better. You can add collaborators on the project and they can have write permission on master.

Agreed, I think that's a good place to start.

I can help occasionally but feature-wise the library looks pretty good for me, maybe some logic to download all the required files of the HTML chapter file, that I've already implemented on that project.

Kinda like #26 I guess?

BTW this is the project

Nice project! I'm sure you're already invested in the Kindle ecosystem by now, but Kobo e-readers have Pocket (and Overdrive) built in. I'm biased because I own one :)

[bmaupin]

@1l0

May I ask what language you moved on to?

For my own side projects, mostly TypeScript. That's not to say TypeScript is better, I just enjoy writing it more than Go and I like that I can use it in the browser as well (after transpiling, of course). But I use other languages as needed (Kotlin, Python, and yes, even Go :smiley:)

Sorry for that I'm not the one who will maintain this awesome library.

No worries!

[bmaupin]

@gonejack

EPUB readers are basically browsers across multi platforms now time, that might means EPUBCheck is kind of outdated.

I think I understand the point you're making, but at the moment I don't think I agree with the philosophy. I think a library that generates EPUBs shouldn't intentionally generate invalid ones. There are so many different devices, and an invalid EPUB that "works" on one device may completely crash another device.

However, at the moment I also think it's okay if the library allows the user to create an invalid EPUB if that's what they really want to do. I just don't think it should do it by default. But I could probably be convinced otherwise :)

In the context of #20, there could still be a way to meet this goal. We can discuss more there.

There is something should be remove like https://github.com/bmaupin/go-epub/blob/master/epub.go#L456 which is kind of 'doing too much' as a library.

That particular line looks like it's just making sure the image at the URL is retrievable, since AddImage will download it. If I remember correctly, I did the check right away so the error will be thrown whenever AddImage() is run; otherwise I think the error might happen during Write(), which could make it more difficult to track the cause.

Or did you mean that the library shouldn't download images from URLs at all? In general I wanted this library to be high-level enough to be easily usable (compared to a lower-level library like epubgo) but it can be tricky to know where to draw the line. One approach could be to try to meet the needs of as many people as possible, providing multiple ways to do things. Based on #26 it's apparent some would like this library to be able to do even more :)

[bmaupin]

@pgundlach

It is not a shame to mark a repository as "not maintained anymore" and close all bugs as "wont fix". This helps to identify if it is worth opening issues.

Agreed. Part of my motivation of creating this issue is I'm not quite ready to completely give up on this project, at least not until I feel like it has one or more people to take over. But if it comes to that point I can archive the project to make it clear that it's unmaintained.

You(?) could just mark this version as version 1.0 and be free to change the API for version 2. While nobody likes API changes, this would be the way to go.

Yes, at some point I probably should just tag v1 and worry about breaking changes later. I might look into doing that after this last push to clean up some of the issues/PRs.

Someone should be the boss. If this is not the case, the danger might be that there could be endless discussions or nobody will implement anything.

:100:

[roger-russel]

I would like to help colaborete into this project if possible.

[bmaupin]

Just a quick update: I merged all the outstanding PRs except for one that's unfortunately going to need to be almost entirely rewritten (#17). I do think functionality for adding subsections would be a great feature if anyone's interested in taking a look at that PR or submitting their own.

I've added some contribution guidelines (CONTRIBUTING.md) and so at this point I will try a best-effort approach at merging PRs that meet those guidelines.

I've also made some improvements to the tests such as integrating EPUBCheck and testing on Windows/Mac, to hopefully better catch any issues. And they also run using GitHub Actions so any forks of this project will get tests for free.

I would still love help maintaining this project since I don't feel I'm able to give it the attention it deserves as I'm not dogfooding it any more, so I'll leave this issue open.

@roger-russel Thanks for the offer, although I think in terms of maintainers, I'm primarily looking for people who have already contributed to the project. But you're more than welcome to submit pull requests for any contributions you'd like to make.

Thanks!

[fmartingr]

Hey @bmaupin ! @Monirzadeh and me are going to use go-epub in Shiori, so expect a few PRs on the following weeks.

Let me know if you need a hand maintaining the project (either with issues, reviewing, etc).

[bmaupin]

Hi everyone, it's been a couple years since I created this issue and I think it's finally time for me to retire from this project. While it hasn't been a ton of work to keep maintaining it since then, the amount of time I have to spend on it has only gone down over the years and so I don't think it makes much sense for me to continue to invest time in something that I don't use any more.

I created #68 to handle the transition. Thanks for all of your contributions!