From Fedora Project Wiki

< Modularity Team

Revision as of 14:20, 2 June 2016 by Langdon (talk | contribs) (Created page with "'''p1- Flock (priority to work on)''' '''p2- Flock (second in the line to work on)''' '''p3 - optional for Flock''' '''Please write card numbers and hyperlink them with the...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

p1- Flock (priority to work on)

p2- Flock (second in the line to work on)

p3 - optional for Flock

Please write card numbers and hyperlink them with the user story

Example:

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

    • #1000

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

I would like any Fedora contributor to:

  • Understand the general idea of “what is a module” (p1) — sct (write a card number and put behind a link to that card)

    • 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