-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to leverage the existing "issue base" in Readium-1 #44
Comments
whmccoy wrote: Just as an FYI, the EPUB-in-Edge team whom I talked with earlier this week here in Seattle area, mentioned how many tricky issues they had to deal with. And, they are ingesting eBook content at volume from publishers that they are now selling (at least in US) from the Microsoft Store. So I +1 this idea. But I would suggest we consider prioritizing by real-world applicability. Much as I am a fan of CFI in principle, I am not sure that it is something that lives in real content. Maybe you want "quartage" instead of "triage" where the fourth bucket is for issues that are significant, and perhaps fixable at reasonable cost, but are more theoretical than practical so low priority not because they are trivial but because they aren't (at least yet) used in the real world of content. Of course this could become a self-fulfilling prophecy as if we leave CFI buggy as heck then we can't expect it to get used... but I don't know that Readium will be the determinant of that in the first place. Another way to prioritize real-world applicability that wouldn't require exhaustive analysis of content is by feature support in other reading systems... if everyone else has good CFI support then probably that is important and we should to. If others omit it, not so much. Of course Readium has a goal to "raise the bar" of EPUB support but at some point adopter priorities should trump our pursuing noble goals, especially when resources are limited... |
@whmccoy Well, I think it is a little more complex than that. I think there are (at least) 4 buckets:
* I want to point out that the implementors of Readium-1 were forging new ground in terms of languages and open source and I think they did a great job. Readium-2 has an easier (bit not easy) path because of that path-breaking. My problem is (at least twofold)
|
I think there is some confusion with regards to CFI support. |
Moving this from email to an issue:
rkwright wrote
Laurent reminded me earlier today that we still have a large number of open issues in R1. This is no surprise because many of them really ARE still problems, but most are relatively minor. The problem all along has been that developers are always happy to develop features but less enthusiastic about fixing bugs. Especially in open source projects and when their REAL boss is breathing down their neck. We will run into this same problem with R2 as well, I am sure so we need to think about that.
However, I am making another pass through the open issues in R1 and reading through them got me thinking. There is a HUGE amount of time and effort invested in those issues: investigating, fixing, experimenting, etc. An not only the remaining open issues but also all the issues that have been closed. I’m trying to think of a way for us to troll through the issues and gather the info in a meaningful way. Even if R2 is better architected and designed, etc. many of the R1 issues arose not because of bad design or implementation (though that is true for some of them) but because the situation or problem was tricky.
The text was updated successfully, but these errors were encountered: