[modularity] Modularizing the world fast and iteratively

[Adam Samalik]

Starting with a summary: ​Let's 1) use something like dependency-report
scripts [1] to get coordinated, and 2) make the initial builds against
bootstrap so we get a working thing fast and can iterate.


I've realized that developing the initial set of modules for F27 could be a
bit tricky in the beginning as some things might require many basic
dependencies on top of Platform to run and build. These dependencies, like
autotools or dynamic languages for example, need to get modularized first.

In F26 Boltron we had a 'shared-userspace' and
'shared-build-dependencies'
modules that kind of randomly included many of the shared dependencies of
other modules. I don't think that's necessarily terrible (although I'm sure
contyk would argue it is!), but it's not ideal. We should make modules that
represent a thing, like autotools, python2, python3, ruby, gtk2, gtk3, git,
etc. But making all of these modules on a greenfield without a solid base
could be tricky. How do we help people to know what they should include,
and what's going to be somewhere else?

For this, I have written a set of scripts, and already named them badly
'dependency-report' [1]. We have tested it with FreeIPA maintainers to
generate a dependency report [2] for them, and we have already identified
many modules that FreeIPA need as dependencies. I think we could use this
to help us with the initial design.

This brings me to my second thought... to build what we want, we need to
modularize a lot of other stuff. And when we are ready with the initial
design - that means we have identified all the modules we want to have and
all their dependencies, we need to build them. But, for example, a pretty
commonly needed thing like autotools [3] has pretty crazy build
dependencies [4] including Java, gtk2, gtk3, erlang, X11, python2, python3,
etc. And many of these need autotools, of course. We need to do
bootstraping.

So instead of trying to make everything perfect from the begining, we could
build everything we need against the Bootstrap module - a module that is
used as a buildroot for Host and Platform and contains mostly everything we
need. To compare, there is a report without using bootstrap [5] and with
using bootstrap [6]. This way we'll have a pretty decent set of module very
soon.

The next step would be lookin at the build dependencies of these initial
modules, building them against bootstrap, and rebuilding the initial
modules against these new ones. And then do it for the new ones as well,
until we have everything in place.

Also, with this top-down approach, we'll be flexible with the frequent
changes of the Platform module as it's getting stabilized which also makes
the design of the low-level modules nearly impossible right now.

With this approach, we:
1) get coordinated and make modules without conflicts
2) have a working thing very soon
3) can iterate on expanding the base set over time


If you'd like to participate, please feel free to propose your module on
the F27 content plan [7], I'll make you a repository under the
modularity-modules space [8] which serves as an input to the scripts, and
include your module in there.

Cheers!
Adam


[1] https://github.com/fedora-modularity/dependency-report
[2]
https://github.com/fedora-modularity/dependency-report/tree/master/module...
[3]
https://github.com/fedora-modularity/dependency-report/tree/original-plan...
[4]
https://github.com/fedora-modularity/dependency-report/blob/original-plan...
[5]
https://github.com/fedora-modularity/dependency-report/tree/original-plan...
[6]
https://github.com/fedora-modularity/dependency-report/tree/bootstrap/glo...
[7] https://github.com/fedora-modularity/f27-content-tracking
[8] https://github.com/modularity-modules

-- 

Adam Šamalík
---------------------------
Software Engineer
Red Hat