From Fedora Project Wiki
m
m (Nphilipp moved page Modularity Working Group/releases/Flock 2016 Release to Modularity Team/releases/Flock 2016 Release: We renamed the Modularity Working Group to "Modularity Team".)
 
(No difference)

Latest revision as of 11:06, 23 January 2019

Themes

  • Fedora contributors can build a module
  • Fedora contributors know what modules are

Notes

Priorities

  • p1- Flock (priority to work on)
  • p2- Flock (second in the line to work on)
  • p3 - optional for Flock

Linking stories

Requested authors are at the end of the outline item. Please write card numbers and hyperlink them with the user story.

Example:

  • Understand the general idea of “what is a module” (p1) — sct

    • #1000

-----------------

Outline of Deliverables

I would like any Fedora contributor to:

  • Understand the general idea of “what is a module” (p1) — sct

    • Put together a guideline documents to summarise this information

  • Define a module (p1)

    • Permissions? Fas membership? — ralph

    • Guidelines [finish writing this out] — contyk

      • review best practices guidelines format as well

    • Where to store the module files — ralph

      • Stg dist-git?

      • Copr?

      • Somewhere else?

      • All of the above?

    • Directory structure of files — contyk? jkaluza?

      • Metadata

      • Binaries

    • What to store? — contyk? jkaluza?

      • Module high-level definition (yaml/Json)

      • Rpm listing

      • Tar balls?

      • Rpms?

    • Versioning (doc + execution) — sct

    • EOL information — sct

    • Module dependency language — jkaluza

    • 5-6 example modules — cpacheco, jstanek

    • PDC integration (p1) — nils, karsten

      • Use pdc for module stack viewing (p1)

      • Use pdc for module viewing (p2)

      • Use pdc for module editing (p3)

      • Use pdc for module stack editing (p3)

    • External module api/abi definition and consumption — contyk, sct

  • Access to shared infrastructure (p1) — ralph

    • Permissions? (p1)

    • Upstream commit trigger? (p3)

    • Trigger defined module to be built by fedora infrastructure (this may mean copr) (p1)

    • Modules deployed to mirrors (p3) (this is really a model for how mirrors work)

    • Modules available on Fedora Stage for public consumption (p1)

  • Local development infrastructure (p3) — low priority, lets hold off

    • Replicated Fedora Infrastructure as metapackage in copr repo (p3)

    • Replicated Fedora Infrastructure as docker container(s) (p4)

  • Simple “base runtime” (p1) — mike mcgrath

    • Module defining current-state “base runtime” available for fedora contributors to build on

    • Document describing the current-state api of “base runtime”

  • Discover others’ modules (p1) — jkaluza

    • Provide a module-service that can surface any modules built in the shared infrastructure

    • Multi-module-repository support in client-tooling

Fedora deliverables:

  • Agreed phase 1 infra architecture (doc & diagrams) — ralph

  • Staging deployed infrastructure (diagram) — contyk

  • Proposal for production infrastructure (diagram) — ralph

  • Relationship to flatpak established — mike mcgrath, langdon

  • Relationship to docker established — mike mcgrath, langdon

  • Relationship with Fedora Server established — langdon

  • Relationship with Fedora Workstation established — langdon

  • Relationship with Fedora Cloud/Atomic established — langdon

  • Proposal for “what module quality means” — rwilliam

    • Proposed architecture for implementation

    • Proposed engagement model for eng and qe