On Tue, Jun 27, 2017, 10:54 Josh Boyer <jwbo...@fedoraproject.org> wrote:

> On Tue, Jun 27, 2017 at 10:44 AM, langdon <lang...@redhat.com> wrote:
> > On 06/27/2017 08:30 AM, Josh Boyer wrote:
> >>
> >> On Sun, Jun 25, 2017 at 1:44 PM, langdon <lang...@fedoraproject.org>
> >> wrote:
> >>>
> >>> OVERVIEW
> >>> ========
> >>>
> >>> As the modularity work starts to enter Fedora with the Fedora 27
> >>> release, a typical Change Proposal did not seem to do justice on
> >>> capturing the moving parts and dependencies for the work to
> successfully
> >>> land. As a result, this document attempts to capture, at a high level,
> >>> the goals and deliverables for F27. We are also providing links to the
> >>> details to most aspects. Some of the details are still in progress and
> >>> will change over the F26 lifecycle (e.g. which modules will be included
> >>> for F27 Server).
> >>>
> >>> THE GOAL
> >>> ========
> >>>
> >>> The Modularity and Server Working Groups plan, with the help of many
> >>> other groups in Fedora, to deliver a fully modularized version of the
> >>> Fedora Server Edition. As an equal and complementary goal, the tooling
> >>> for module creation/development, deployment and automatic testing will
> >>> be as simple and automated as possible.
> >>> [*Change*](https://fedoraproject.org/wiki/Changes/Modular_Server)
> >>
> >> Given that Server is widely used across a number of architectures,
> >> with participation from various groups using those architectures, we
> >> still need Server to work on all the architectures it does today.  Is
> >> that your understanding as well?
> >
> >
> > We fully expect to build for all the supported architectures as Server
> > Edition does today.
>
> Yay!
>
> >>> CAVEATS
> >>> =======
> >>>
> >>> -   Although modularity allows for lifecycle changes, there is no plan
> >>> for
> >>> anything besides the normal 13 month lifecycle at this point.
> >>> -   Available content as modules will be less than a typical Server
> >>> release
> >>>      -   Only components that are a part of a module will be available
> >>>      -   Any RPM that is a part of module will be available to be
> >>> installed
> >>> directly or in addition to the “install profile” install of the module
> >>>
> >>> ASPECTS TRACKED
> >>> ===============
> >>>
> >>> -   Infrastructure Changes/Improvements:
> >>>      -   Bodhi: changes to support updating & tracking modules:
> >>> [*Change*](https://fedoraproject.org/wiki/Changes/ModularRelease)
> >>>      -   Arbitrary branching: enables modules to versions bound to
> >>> something
> >>> other than Fedora release number:
> >>> [*Change*](https://fedoraproject.org/wiki/Changes/ArbitraryBranching)
> >>>      -   Bugzilla & ABRT module-awareness are still in progress
> >>>      -   COPR: support for building modules has been added and will be
> >>> improved over the F26 cycle
> >>>      -   Automation (Freshmaker)
> >>>          -   On Demand Compose Service (for testing and container
> >>> rebuilds)
> >>
> >> What does "testing" mean here?
> >
> >
> > I think it just means "things are rebuilt and sent to automated testing".
> > Why it doesn't say "for release" I am not sure. I may have "cleaned up"
> the
> > text poorly.
> >
> > Ralph, JanK: can you weigh in here?
> >
> >>
> >>>          -   Greenwave: for policy/gating in Bodhi. User interactions
> >>> take
> >>> place in Bodhi.
> >>> -   Installation & System Management
> >>>      -   Anaconda: still in progress
> >>>      -   DNF: Work underway to support modules, additional features
> need
> >>> to
> >>> be added. Please report comments/features/bugs in the [*normal
> >>>
> >>> manner*](
> https://github.com/rpm-software-management/dnf/wiki/Bug-Reporting).
> >>>      -   Gnome Software: still in progress
> >>> -   Host & Platform module(s): Base components that provide the
> >>> “operating
> >>> system” aspects of Modular Fedora:
> >>> [*Change*](https://fedoraproject.org/wiki/Changes/Host_and_Platform),
> >>> [*Content tracker*](https://github.com/fedora-modularity/hp)
> >>> -   Application modules ([*Content
> >>> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)
> ):
> >>>      -   TBD language modules (1 or more versions each)
> >>>      -   TBD database modules (1 or more versions each)
> >>>      -   TBD web server modules (1 or more versions each)
> >>>      -   TBD utility server modules (1 or more versions each)
> >>> -   Applications as System Containers ([*Content
> >>> Tracking*](https://github.com/fedora-modularity/f27-content-tracking)
> ):
> >>>      -   TBD system integrated containers
> >>
> >> This requires a container build service capable of producing these
> >> containers.  I think the Fedora layered build service can do that for
> >> x86_64, but it is not capable of doing that for other architectures.
> >> Is support for that being worked on?
> >
> > I understand that to be the case as well. We plan to do, at least,
> x86_64. I
> > need Ralph, Adam Miller, and Eliska to comment any further on the plan.
>
> Here's my concern.  If system containers are a main component of a
> modular Server Edition, to the degree that it's the default way to do
> some things, then not having that experience present on all the
> architectures Server supports leads to a weird disparity and different
> user experience.  If system containers are *optional* for F27 and most
> of the modularity aspects are focused on RPM/repo module artifacts,
> then that is somewhat less of an impact.  It's unclear to me which is
> the plan here.
>
> josh
>

Sorry, meant to write that.. Yes, optional (but cool!)

/me needs to figure out how to capture all these clarifications somewhere
not-email

Langdon

>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to