Skip to content

Meeting minutes 2019 04 04

Robert D Anderson edited this page Apr 4, 2019 · 5 revisions

Attendance: Robert Anderson, John Pashley, Roger Sheen, Shane Taylor, Radu Coravu, George Bina, Jarno Elovirta, Lief Erickson, Bill Gamboa, Frank Wegmann

Item 1: Any updates about prior releases?

3.3.1 about ready, two pull requests still open waiting for review: https://github.com/orgs/dita-ot/projects/13

HTTP / HTTPS Registry issues:

  • Registry is hosted at plugins.dita-ot.org -- it's just a site that hosts the JSON from our repository
  • DITA-OT installer looks there for plugin IDs. It fetches a JSON file from the website to look for the plugin you want.
  • Has been hosted at github pages so far, but we've been migrating the main website to Netlify, so intended to move this as well; Netlify has better support for a variety of things.
  • Realized Netlify only serves files over https, but github pages serve over both http and https. If you try to access Netlify with http, it will redirect to https.
  • Get a 302 response code, normally that's fine, means a client should continue to new URL.
  • Plugin install code doesn't handle the redirect. So latest code in 3.2 and 3.3, when looking for http://plugins.dita.org (listed explicitly in the shipped configuration file), will fail to get the expected JSON, and will fail.
  • Discovered this after moving, so quickly moved back to github pages; now deciding what to do.
  • Roger: what advantages would we have from Netlify?
  • Currently, there's a Magic Jekyll template _all.json that reads the static files in the repo, and combines into one file. Another file index has just a list of plugin IDs. This works, but is limiting: template language doesn't have many features. Netlify implementation does this as part of NPM install, uses JavaScript to combine files. Doesn't do anything extra yet. Goal: split metadata files into directories, individual files -- one directory for a plugin, inside you have an entry for each version. Easier / nicer / if these can be split. If we can use JS before deploying, would be easy to generate this automatically, or do other re-configuration without affecting client.
  • We want to switch to https for a bunch of reasons (users should feel more comfortable if the installer is adding code retrieved thru https). Also: at any point in the future, github could force https, resulting in the same issue we have today with Netlify.
  • So today, we have 3.2, 3.2.1, and 3.3 already released with HTTP that will fail if our provider forces HTTPS. We can release a 3.2.2 and 3.3.1 that update to https. Our unknowns though:
  • How many people have these, and are using registries?
  • How many people on 3.2 or 3.2.1 will not want or will not know to update?
  • A one character change in the configuration file will fix this, but how many users (who are using the registry) are not allowed to edit that file by their IT departments?
  • Jarno's preference: issue 3.2.2 with this one character change; fix in 3.3.1; and ship 3.4 with the correct HTTPS.
  • This is effectively a security enhancement: we will be switching the page to HTTPS for better security, and patching releases to accommodate it.
  • We can continue with the page at github, using http, for three or so months. This seems like a good enough window; our customer base is often slow to upgrade, and anyone on 3.2 or later is likely in the group of users who will quickly pick up a new patch.
  • One issue we have is that we really do not know how often this page is accessed - github pages does not provide us with a number of times the page is loaded.
  • Decision: will release 3.2.2 and 3.3.1 quickly with this fix. Will move the HTTP page over to Netlify + HTTPS within the next couple of weeks. One reason to move quickly - Robert will be presenting a session on the registry at CMS/DITA North America on April 17, if we move by then, then we have no risk of people 1) successfully trying the plugin at the conference, and then 2) having it fail after they head home. As Roger puts it, an example of "Conference driven development".

Item 2: DITA-OT Development status and updates

Next major release project board: https://github.com/orgs/dita-ot/projects/12

Major issue (project files) getting many updates from Jarno and feedback / code reviews from Radu. One pull request still open; once it is done, the project file is likely Feature Complete. Would like usability feedback from users of DITA-OT. Pull request open against docs with draft updates: https://github.com/dita-ot/docs/pull/252

Lots of discussion about project files, namespaces (yes or no? ... probably yes) ... really would like to get feedback, perhaps testing while this is still fresh and more easily updated.

Item 3: Doc updates and plans, update on documentation call

Web site is now on Netlify!

Web site now has a logo!!!! Many thanks to Sascha Nothofer for contributing the logo!

Roger needs help testing an update for a Windows change (build script update for calling builds) https://github.com/dita-ot/docs/pull/251

Item 4: DITA-OT Day 2019

By our next meeting, need to come up with a theme, or general idea for call-for-proposals. Do not have full info yet on location / hotel but hope to have that by next month.

Item 5: Other topics

...

Item 6: Backlog discussion

Clone this wiki locally