W3C

- DRAFT -

SV_MEETING_TITLE

08 Jun 2017

Agenda

See also: IRC log

Attendees

Present
Avneesh, tzviya, dauwhe, Garth, Duga, rdeltour, Charles_LaPierre, BillM
Regrets
Chair
Tzviya
Scribe
dauwhe

Contents


<scribe> scribenick: dauwhe

<clapierre> present_ Charles_LaPierre

tzviya: lots of regrets
... mattg wins the service award yesterday, but he can't be here :(
... welcome to the epubcheck task force
... introductions

rdeltour: Romain Deltour, DAISY
... working on epubcheck for two years, primary maintainer
... I'm here to help, but I can't work a lot of hours on the code

Tobias: I'm Tobias Fischer, software dev from DE
... creator of Pagina
... volunteering with epubcheck for last 2 years

tzviya: I chair all the things
... and I do everything

garth: co-chair of DPUB
... Google uses epubcheck in our ingest pipeline

duga: Brady Duga, google

clapierre: Charles LaPierre, Benetech
... EPUB CG A11y task force co chair

dauwhe: Dave Cramer, Hachette

garth: Kevin Xu is with Google, working on epubcheck in google ingest pipeline

???: Thomas Ledoux: working on epubcheck

Marisa: Marisa DeMeglio, dev from DAISY
... work on validation

Naomi: I work for Random Penguin, doing epub process development

Wolfgang_: Wolfgang Schindler from Stuttgart, working on dictionaries
... not a java dev :)

tzviya: regrets from Readium folks
... we have quite a long agenda
... I don't know about the programming; I'm hear to help lead

Documents

UNKNOWN_SPEAKER: our goal is to make it possible for others to contribute to epubcheck
... break large tasks into smaller tasks
... so we can hand off small tasks
... lots of links in agenda
... we need volunteers
... we need a detailed list of changes from 3.0.1 to 3.1
... this is something a non-dev can do
... with guidance from a mattg doc
... and then create github issues
... this person should start by working with Matt, the world's nicest human

<Tobias> Matt's current 3.1 changelog: https://docs.google.com/document/d/1kgoxSEhF_iTyixj6XaZIc0cgruBNNQknaif4fyXqKto/edit

<tzviya> https://docs.google.com/document/d/1kgoxSEhF_iTyixj6XaZIc0cgruBNNQknaif4fyXqKto/edit

UNKNOWN_SPEAKER: do we have volunteers to work on this?

garth: what's the one linked in the agenda?

rdeltour: this is not from the work plan doc

tzviya: this is link one
... epub 3.1 validation

<garth> http://www.idpf.org/epub/31/spec/epub-changes-20170105.html

tzviya: we should just go from here
... matt took that doc, and wrote up the google doc

rdeltour: the google doc is more detailed

Naomi: should we split it up by chunks? I could do some, like do the package doc validation

tzviya: that's excellent
... how much time do you need?

Naomi: If it's just creating provisional github issues, I think I could do it by the 26th

tzviya: end of month? Excellent.
... you, matt, and I will follow up to get this started
... Matteus may offer to help with other sections
... the next few issues are all connected
... if you look at work plan doc, link 2

<tzviya> https://github.com/IDPF/epubcheck/wiki/WorkPlan

tzviya: you'll see there is a maintenance release scheduled for epubcheck, version 4.1.0
... we wanted to get a feel from the group if you think this is a good idea given there's no 3.1 support

Naomi: there are some retailers who are having ingestion issues with our files that are not wrong
... I think we should do this release

<Tobias> current 4.1.0 milestone: https://github.com/IDPF/epubcheck/milestone/3

rdeltour: I agree. There are many bug fixes and minor improvements
... we dn't have to wait for 3.1

tzviya: my concern was about publicity, if we release a new version that doesn't include 3.1 it looks bad and is confusing

rdeltour: the story of my life with epubcheck
... its a matter of marketing. if we make it clear it's a maintenance release
... and that we're working on 3.1, then we're OK

<clapierre> +1 to Romain's point

garth: I think it's good to make new version available
... having 4.1 would be good for us

Avneesh: in DAISY we have experience with maintence releases while major features are in progress
... we try to communicate that clearly
... I'm COO for DAISY
... DAISY has been quite involved with epubcheck, and I want to help with a smooth transition

tzviya: so consensus seems to be to go for maintence release

<Wolfgang_> +1 for maintenance release

tzviya: let's talk about resource requirement
... and how much time is required, and what skills

<tzviya> https://github.com/IDPF/epubcheck/wiki/TestSuiteCleanup

tzviya: there's link 1.5 with romain's doc
... romain, can you walk us through this?
... let's break this up into tasks

rdeltour: epubcheck comes with extensive integration tests
... we have a bunch of epubs we run epubcheck against
... and we check against expected passes/failures
... several hundreds of tests
... test suite has grown organically, and is how hard to maintain
... after a contribution from ??? devs, dozens of tests were added, and it was more obv. that tests were hard to maintain
... in parallel with 3.1 impl, we should clean up and reorganize test suite
... make it more maintainable

<Wolfgang_> s /nook/Nook/

rdeltour: this is painful for devs
... I spent more time fixing test suite than making code changes
... in this cleanup doc, I tried to define some steps
... for us to work on
... 1. define naming convention, for directories and unit test methods
... there's no convention now
... it's messy
... we have to reorg test directories
... there are two main branches where data is stored
... there's a 20 directory for epub2, and a 30 directory...
... and there's some packaged epubs, and some expanded files, and some single docs
... and more stuff added by BN folks
... need to merge input data branches
... and cleanup things like having both expanded and packages
... easier for devs to use expanded
... we have to clean up individual tests
... some are real-world tests
... some are not minimal test cases
... and make a minimal base epub
... and rework test data to work in minimal base
... sometimes a single test case raises several issues
... so we need to split, so each test tests a single feature
... there's also a companion metadata doc
... epubcheck reads this data
... hard to maintain; we should get rid of these

<Wolfgang_> * has everybody problems to hear Romain?

rdeltour: that's about it
... this is not rocket science, but it's annoying, and needs to be done
... it will take a long time due to the number of tests, but it can be done progressively
... after cleanup, we can check for test coverage
... but the cleanup is needed first

tzviya: thanks
... the 4.1 release is our first priorty, you said it's all but complete
... what do you need from this group to get 4.1 out the door?

rdeltour: I don't think we need much from the group from 4.1

Tobias: most of the open issues are things which need to be reviewed, like 15 PRs with code changes
... so there are only 9 open issues
... for which romain signed up :)
... we could reassign, but I'm on holiday for next 2.5 weeks
... to get 4.1 finished we don't need big help from group

tzviya: if you look in the repo, it's broken into projects

<tzviya> https://github.com/IDPF/epubcheck/projects

tzviya: the 4.1 project, and 3.1 refactoring/cleanup
... those things could be done simultaneously
... I want to figure out how to break out these tasks into things we can assign to people who are not romain/tobias
... so we need skills required and time needed
... might be too early to figure this out
... might need training
... right now I can't ask my colleagues to get involved
... Romain, as you work can you add to wiki?

rdeltour: during this call?

tzviya: like naming convention

rdeltour: I don't think we need call time for naming; one person should volunteer
... for instance, in first example, it's a convention that test methods start with 'test'
... but the rest we can make shorter
... a volunteer should do a naming pattern

tzviya: I can do that
... reworking test directory org is more complex
... as well as understanding how validation works
... this person would work with Romain/Tobias

rdeltour: clarification:
... it doesn't require knowledge of current tests
... but it does require knowledge about the epub specs and history
... whether we want to organize by version and domain
... one person can propose something first, and then we can match that against current test suite to make sure it's workable

tzviya: brady and garth, no one knows history better than you

<rdeltour> https://github.com/IDPF/epubcheck/wiki/TestSuiteCleanup

<tzviya> https://github.com/IDPF/epubcheck/wiki/TestSuiteCleanup

garth: the doc I thought we were using was the work plan

tzviya: there are multiple docs

garth: I see it
... rework test organization

tzviya: romain said it requires knowledge of history of epub, and how tests might be organized
... could you or brady do this?

garth: we'll look at it and make comments, and take an initial stab

tzviya: you can put suggestions in the wiki

<rdeltour> +1

tzviya: define a minimal base epub test case

rdeltour: it's not complicated

dauwhe: I can work on minimal test case

clapierre: how can this work?

rdeltour: it's just a base for all unit tests
... one valid epub file, which can be copied when creating a new test, and then you tweak something in it to make it invalid.

clapierre: that makes sense

Cleaning up each test

tzviya: anyone with epub knowledge could be trained?
... what do you want to see happen here?

rdeltour: we will need to document what needs to happen
... take one test case in epubcheck
... run it

<Wolfgang_> * Where would I find the test cases?

rdeltour: 2 cases: one, is a test that's expected to pass
... in that case you just need to minimize the test case, prune any useless feature from input
... the other case is for expected failures
... we need to look at error messages
... if the messages are about several independent issues, then we need to split the test case, make one for each error
... and clean up / minimize the input data

Naomi: all of this is in java, right?

rdeltour: the most difficult part doesn't have to do with java, but is about changing the epub content

Wolfgang_: my Q is where I would find the test cases, to get a feeling for them?

<Tobias> testcases: https://github.com/IDPF/epubcheck/tree/master/src/test/resources

Wolfgang_: can you post a link?

clapierre: is there any IDE support for the java files?

rdeltour: it's possible to run all the tests at once with Maven
... you might be able to use that for single test

Tobias: you can run single tests with JUnit in Eclipse (?)

tzviya: if that's not possible, that's something we should add

rdeltour: even running epubcheck against the input data gets you a long way

tzviya: true

<BillMcCoy> (staled) Eclipse plugin for running epubcheck (and editing): https://github.com/rkwright/epubcrude

tzviya: as far as resources, and checking and modularizing
... it's a very manual task. Correct?

rdeltour: correct.

tzviya: most people in call should be able to understand
... could we divvy up the files among the ten of us

rdeltour: that's a good idea
... the prerequisite is to have a naming convention, directory structure, and base epub

tzviya: I'll try to have naming convention tomorrow
... garth should have directory structure by end of next week

dauwhe: I can have base epub next week

tzviya: I'll assign everyone on the call, and some other folks... I'll create a list of files, run tests, and work on documentation

<rdeltour> SGTM!

tzviya: everyone will have 2-3 weeks to do that, with ten files to work on

SGML!

tzviya: in a week and a half, we'll have the prereqs
... four minutes left, for the rest of the agenda
... if we're doing a 4.1 release, when might the 3.1 release be done?

rdeltour: depends who's gonna do it
... we don't have dev resources

tzviya: we need to talk to Laurent
... and do we need to migrate the repo?
... how often should we meet?
... is this a good time to meet?
... it's late in Euroland

Wolfgang_: I would like to have it earlier

<BillMcCoy> apologies for my schedule conflict today (that was a one-off conflict though)

Wolfgang_: one hour earlier?

<rdeltour> late is good for me, kids are quieter :)

Wolfgang_: once per month works

<garth> Agree

<clapierre> +1 on 1/month

Avneesh: time is late for me, but i may not need to be in all calls
... because Romain is here

tzviya: for next call... I scheduled this one around Romain and Tobias
... right now we're scheduled for this time next month
... I'll follow up with Romain and Tobias
... right now webex is for the same time on 6 July
... I'll create minutes and send summary

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/08 19:00:19 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Marissa/Marisa/
Succeeded: s/C??/COO/
Succeeded: s/???/nook/
Succeeded: s/that/naming convention/
Present: Avneesh tzviya dauwhe Garth Duga rdeltour Charles_LaPierre BillM
Found ScribeNick: dauwhe
Inferring Scribes: dauwhe

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Agenda: https://lists.w3.org/Archives/Public/public-epub3/2017Jun/0005.html
Got date from IRC log name: 08 Jun 2017
Guessing minutes URL: http://www.w3.org/2017/06/08-epubcheck-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]