-
Notifications
You must be signed in to change notification settings - Fork 423
Minutes
Participants: Avneesh, Matt, Romain, Tom.
This was discussed in the EPUB CG, and the issue is still under vote. It's likely that EPUBCheck will be asked to treat all 3.2 as the default version and just ignore 3.0.1. Votes are open until Thursday December 6th at 1700 UTC.
This may lead to a discussion about errors vs. warnings vs. info. This would be treated as a new issue, it’s independant to the 3.0.1 vs. 3.2 issue.
We can start integrating new 3.2 checks in the code base with no differentiation; and we'll follow whatever recommendation the CG makes on errors vs warnings.
We got a couple PR after v4.1.0. One is about a build step; the other is about completing missing translations. Once the translations are complete, we can release them as v4.1.1. This won't impact our release schedule for the 3.2 implementation; it's a patch release on v4.1.0.
Some more digging in the CSS handling: only certain attributes like font-family, size and a few specifics are being checked, the attributes like the ones mentioned #901 are ignored.
The CSS profile in EPUB 3.2 has a few slightly non-backward-compatible changes; we should follow the lead of the CG in what to validate.
- currently, we do validate some CSS, but only partially
- we do not cover all EPUB CSS rules
- should we handle anything specifically outlined in the spec? (at least at a warning level?)
For now we should maintain the status quo regarding what EPUBCheck does and doesn’t validate. We'll need to update the existing checks that are changed in 3.2; but general CSS validation is out of scope.
CSS validations could be triggered with an on/off switch, which people could either enable or disable. We’ll look at the implementation feasibility. One issue is deciding on the default behavior: validate or not? We can ask the CG to vote.
EPUB 3.2 support is due in Q1 2019. We will start releasing test versions earlier (first alpha in December?).
The most important/significant issues to tackle include:
- HTML and SVG upgrades (#892 and #893). Until we integrate with the Nu HTML Checker, we need to upgrade the schemas (see also #779).
- remote fonts
- core media types
- resources in the container without fallbacks
What about deprecation warnings? This could be added early on. Probably not the biggest prio, more a mid-tier change.
We'll setup 3 milestones: beta-1 (Dec?) / beta-2 (Jan?) / beta-3 (Feb?) and start sorting issues in these 3 buckets. Then we can review/reorganize these at will. RC testing can be done in March.
The version supporting EPUB 3.2 will be called v4.2.0, since the API and internal code won't change much.
Participants: Daniel, Matt, Romain, Tom.
EPUBCheck v4.1.0 was released today! See also the W3C announcement blog post. The changelog should be pretty thorough, it's based on the commit log.
One of the biggest refactoring is the one introducing localized reports:
previously EPUBCheck's locale was the JVM's default, now it can be configured
so some objects in EPUBCheck are now Locale-aware, including most of the reports, the CSSParser, etc.
The Locale is also available from the ValidationContext class but this all should be mostly transparent, it's not a breaking change
Sources compatibility has been upgraded to Java 7 at minimum; and various libraries have been updated.
Need to look more into #901 to make sure there is nothing to be done in EPUBCheck.
Housekeeping question: if we don't find anything that can be done, how should we tag/track that issue?
- explain the reasons in an issue comment
- assign a reviewer (Matt, Romain, or both)
- set the status label to
status: waiting for review - when the reviewer agrees, close the issue as
type: wontfix - OR if the issue is to be postponed to a later release, then set the status label back to
status:acceptedand update whatever milestone it's scheduled for
The Maven group ID is still org.idpf, maybe we should update that to org.w3c, let’s raise the issue to the steering committee
The latest translations were not pulled from the translation service (Transifex). Only one new string was impacted, and it only had one new translation (in German); but the release process should be made less error prone:
- document a release checklist in the wiki
- try to better integrate with Transifex and automatically pull new translations (tracked in #913). Maybe with web hooks (setup an address with Transifex and then Post a message to it to fire off their process).
A CHANGELOG.md file has been created.
Ideally the change log would be generated automatically from the issue tracker or commit log (à la "conventional changelog").
We will explore how this can be done from a Maven build, that would reduce the release work.
We'd like to configure an auto formatter, to reduce the whitespace-only diffs. If possible that would be integrated in the Maven build process.
Participants: Avneesh, Daniel, Matt, Romain, Tom.
Nothing really new to report, PRs will be closed soon.
Typically we should try to have all the PRs reviewed by a peer before merging. Merging PRs without peer review is acceptable if the change it quite straightforward; we do not always need systematic peer-review. The automated CI build is usually enough for QA on simple changes. "trusted" maintainers may auto-review when they're confident enough, given the lack of reviewers availability.
Tom started to look into #901 (-epub-text-orientation).
Should these new rules be setup in a new set of schematron files, and if so how much do we duplicate vs. referencing the existing files?
Sounds like a breaking change in EPUB 3.2.
It's currently not checked by EPUBCheck.
The bigger question is whether we want to keep a "3.0.1 forced mode" or if we just make 3.2 as the default and not allow checking 3.0.1 anymore. This question will be raised to the CG and BG.
We should also find out if proper CSS validation is even wanted. It could lead to a lot of errors/warnings if it gets implemented. It would take time to develop.
For the first 3.2-compatible release, we may not need to validate aspects that EPUBCheck didn't validate before. For example for #901, that means we may simply have nothing to act on.
Participants: Daniel, Matt, Romain, Tom.
Romain started to review issues and PRs. A deeper look at #859 indicates it's due to the schematron XSLT built in Jing. We have to take action since it's not only a development-time warning but will be rendered to users. Several solutions can be further explored; a mininmal repro project will be pushed to GitHub to file an issue with Jing.
Matt finalized the list of issues on the intermediary Google doc; all the required changes are now filed in the tracker with the spec: EPUB 3.2 label.
Old issues labelled as 3.1 have been moved to the spec: EPUB 3.2 label; Matt will clean up the issues that are no longer relevant.
Tom and Daniel will review these issues, and can start taking on some of them.
Romain started renaming the Github issue labels, following the suggestions in #862. Missing labels will now be added.
The branching guide hasn't been written yet, but we don't need a common 3.2 branch. New features and bug fixes can be developed in their own branch, that will later be merge to the master branch. We are suggesting to use a lightweight naming convention for branches: $type/### where ($type) indicates the type of work (e.g. feature, fix, chore, docs) and ### is either a short nickname or an issue number reference. The idead is to keep it simple, while making the branch name quickly understandable.
Participants: Avneesh, Daniel, Matt, Romain, Tom.
We discussed how we wanted to organize the communication within the core development team:
- weekly text chats using DAISY's
#epubcheckSlack channel - ad-hoc audio calls when needed
- Slack is used mostly for transient communication
- Resolutions and important information should be summarized in the meeting minutes on the wiki
We also discussed Slack best practices:
- we'll use a unique
#epucheckchannel as long as it works - we may add additional feature-specific Slack channels if discussions become difficult to manage in a single channel
- we won't use Slack's threading functionality, which is deemed more confusing than useful
- significant message editing is discouraged, or should be explicitly mentioned in the main discussion thread
- we'll use explicit '+1' messages rather than thumbs-up emoji reactions to upvoting important decisions (for accessibility reasons)
We discussed the issue labelling and potential use of a column-based issue management tool (Waffle, Zenhub, GitHub projects). Zenhub might be too complex for our use; GitHub projects isn't accessible. For accessibility, we want all the information to be available from the standard issue tracker and labels. Waffle could be a good option, as it is a pure visualization of GitHub's existing dataset.
Resolution:
- apply the labels proposed in #862 (pending comments from Daniel)
- stick to issues/labels/milestones as the primary source of information
- experiment with Waffle as an optional layer for visual issue management
Maintenance release, no big new features. The task is basically to wrap-up the work done by previous maintainers (and contributors). No plans to kill features like EDUPUB (yet). We should check that no "invalid" EPUB 3.1 validation is introduced.
Romain will handle 4.1.0, getting help from Daniel or Tom only if needed. The deadline is 3d week of November.
This task should not delay the work on EPUB 3.2.
A quick developers guide should be written on how to manage branches for working on multiple versions/features in parallel.
Status: exploring the source code, existing pull requests, EPUB 3.2 specs. Still quite low on the learning curve. Discussion will continue on Slack; Romain will answer questions and/or setup audio calls when requested.
Tom looked at issue #859 and the warnings appear to be raised at instantiation (and not for each test run). To be investigated.
The first step is to identify the list of stuff that changed (compared to EPUB 3.0.1) and need to be implemented. Matt will handle this task, with assistance from Daniel and Tom. Initial work will be done based on an Google Doc draft created by Matt during the 3.1 work.
The basic workflow will be:
- identify a change requiring to be implemented in epubcheck
- create a new issue
- someone else reviews and sets the label
accepted - someone voluntarily takes the issue, or we assign someone during our weekly chat
- this person thinks about the issue, possibly discusses it, and then sets the
waiting for revieworready for implemlabels
Participants: Avneesh, Daniel, Romain.
- set up infrastructure.
- Organize the issues + review the labelling strategy
- Move the repository to W3C.
- Do we need to rename the Java namespaces (legacy adobe and IDPF names). This can be handled in phase 2 during the code clean up.
- Infrastructure work can start Before TPAC
- Maintenance release for existing fixes (v4.10)
- Deadline is November.
- EPUBCheck updated to EPUB 3.2 - alpha release.
- In December or early January.
To help us triage GitHub issues, create "epics" meta-issues (group related issues, identify dependencies / development critical path, manage separate Pull Requests, etc.), and ultimately assign tasks / action items within a timeline, using:
- GitHub milestones
- GitHub labels
- possibly GitHub projects
...but there are also more powerful alternatives:
Romain knows Huboard; Daniel knows ZenHub; We all know Waffle, Trello, GitHub Projects.
Proposal (to be discussed further): exclude Trello (too disconnected from GitHub, more suitable for higher-level project management), exclude Waffle (there are slightly better alternatives than this simple GitHub "overlay"), exclude GitHub Projects (limited feature-set), consider Huboard and Zenhub (we need to verify accessibility).
ACTION ITEM: Avneesh to check screen reader accessibility of the current Github Projects (Avneesh already uses GitHub issue tracker label-based filtering, etc.)
ACTION ITEM: Romain to explore ZenHub and setup a test instance
We discussed the human resources needed to achieve the EPUB 3.2 milestone. ACTION ITEM: Romain should get in touch with the team and kick-off the development.
Communication channels for development team:
- the development team can use the #epubcheck Slack channel (in the daisy-dev orgnization)
-
- ad-hoc audio calls when necessary
- setup a weekly timeframe for developers chat
- the discussions will be summarized and published on a wiki page, under the heading of the date of call/interaction.
Communication call with steering committee:
- schedule a monthly audio call on Zoom.
- Create EPUBCheck twitter account? (requires approval of Luc/Tzviya). Its objective is to keep the public updated about the technical developments.
- We should formulate plan for providing some light weight updates that can be used by Luc/Tzviya for marketing. It may be posted on a blog or news, social media page etc.
ACTION ITEM: Avneesh to get in touch with Luc and Tzviya to invoke discussions on these topics.