Islandora Install Sprint Intro Meeting

Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:

• Time: 2:00pm Eastern Daylight Time US (UTC-4)
• Dial-in Number: (641) 715-3570
  • Participant Code: 304589#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  • Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #islandora on irc.freenode.net

Attendees

1. Gavin Morris
2. Bryan Brown
3. Jared Whiklo ⭐️
4. Adam Soroka
5. Martin Teheri
6. Jon Green
7. Melissa Anez

Agenda

1. Stakeholder's Summary
2. Sprint Format
3. Sprint Logistics
4. Scope

Minutes

1. Summary This was meant to be informative, but due to the attendees we can do more. Want to arrange community based sprints around installation code. This has always been the hardest part of Islandora. Probably the easiest thing that helps the largest group.

   Stakeholders are individuals or organizations that have a vested interested in seeing the goals of the sprint fulfilled. So you have a large degree of influence on the outcomes, but you have to provide time during planning and development. Want to give people a chance to influence the work in a community fashion, the other is to stop getting de-railed with use cases that are not supported by someone spending time on it.

   No documentation around the stakeholder model, perhaps good to create some for future sprints.

2. Format

   Planning phase - which will be longer, stakeholder will meet, define the scope of the work to be done and decide on deliverables. The some small meetings to get this decided.

   Implementation phase - Not necessarily thinking 2 weeks, we've tried that but quite often can't dedicate that much time. Depending on what the commitments from the stakeholders ends up being will influence the end result.

   Adam - If we were able to commit 0.5 FTE for 1/2 week, is that enough?

   Danny - Yes, that is enough. Really it depends on what we can get.

   Gavin - What would be helpful, is a stakeholder document to be able to pass on to higher ups.

   Maybe we should resolve what the stakeholder document is at this call?

   Bit of a chicken and egg.

   • What is being delivered? Depends on how much developer time we have available?
   • How much developer time do we need to commit? Depends on deliverables.

3. Spring Logistics

   Github, no more no less

4. Logistics

   Limiting the scope as much as possible. But still make something that is generally usable for the majority of the people. Also useful for building on top of this work for greater reach.

   I would like to see:

   • scripts that are capable of installing something on bare metal using a dev ops script (probably Ansible)
   • One OS only and one version (perhaps the most recent), to reduce testing and development time.

   System calls don't vary too much inside a Linux flavours.

   Not against a container based solution if we have the people available to do the work.

   Can we use Ansible scripts that build on a bare metal or is building in a Docker setup a the starting point.

   What is the workload to take a bunch of Ansible roles to migrate to use with Docker. I can see how you would be building off of individual Docker containers. This seems to be achievable and a good rallying point.

   Ansible allows the creation of a set of idempotent commands and allows for deploying to various boxes, even various versions of Linux.

   Jon Green has already done some work on this - https://github.com/jonathangreen/claw-playbook

   Deliverables are build out the claw-playbook above on Ubuntu 16.04 for use on a single machine (ie. vagrant). Then work towards deploying the sandbox. Then work towards containerization and separation of large chunks of concerns.