I'd suggest that the Modularity team could preapre a list of example
use cases that will present the strenghts of the modularity.
I believe, there are currently many examples of packages that took a
path to become only modular and it always created more issues than it
solved.
Let's focus on a simple use cases first, which only modularity can
solve the best and leave the more complicated ones for later - after a
careful consideration if turning some regular packages into only
modules would really help both packager and user experience.
Keep in mind, there are still wide gaps in the modularity packager
experience, new bugs spawning every now and then.
In light of this persistent situation, I honor the new goal currently
set of focusing at those issues.
--
I'll start with my use case, which IMHO can be used as a great case
advocating for modularity.
I'm a maintainer of MariaDB, MySQL and some software around.
While the new major version of the database is being developed, I'd
love to pack it in Fedora, test it, offer it to the users and provide
feedback to the upstream, solving the uprising issues with them way
before the GA.
Because I want to keep a stable version in the base Fedora, I'm using
modules to provide both of them.
E.g. when MySQL 8 was being developed ( pre-GA releases ), I normally
maintained the MySQL 5.7 (latest stable major version) in the base
Fedora, while having MySQL 8 as a module.
When the MySQL 8 went GA, I had MySQL 5.7 in Fedora N and MySQL 8 in Fedora N+1.
However at the same time I also provided MySQL 5.7 as a module in both
Fedora N and N+1. Same for MySQL 8 module (in both Fedora N & N+1).
That way, the users weren't forced to upgrade right away (once the
Fedora N went EOL), but they got time to prepare and / or test it
first.
In a case, when user is hungry for the very latest version, he has the
MySQL 8 available before it went ot the base Fedora, and even before
the MySQL 8 went GA, so he can provide feedback to the upstream either
directly or through me (via BZ).
Since the upgrades between Fedora releases with modules when the
version in Fedora base changes are still not really thought through,
you (as a user) need the same module in the both Fedora N & N+1,
beacuse you can't upgrade Fedora version from MySQL 5.7 that was in
base to MySQL 5.7 module, since newly there is MySQL 8 is in the base
Fedora.
I believe no other applicable solution is as elegant for my use case,
as modularity has.
COPR repositories are hidden from the users (you first need to know
which repo you want to use before getting it's content), and the
builds from there are not pushed through the updtae system (BODHI) to
discover bugs early.
New package (named e.g. 'mysql-8' ) is also far from "elegant"
solution. Even further when I (the pkg mainatiner) plan to soon (once
GA is released) update to that version in the original package.
The same for MariaDB 10.3 -> 10.4; future 10.4 -> 10.5 ...
--
I strogly believe a list of use cases like this would make the
modularity much more clear to both mainatiners and users.
Stick to Unix philosophy ("Do One Thing and Do It Well") and don't
rush or even try to make modules from everything.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Wed, Sep 18, 2019 at 9:32 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
>
> Now that Modularity is available for all Fedora variants, it's time to
> address issues discovered and improve the experience for packagers and
> users. The Modularity team identified a number of projects that will
> improve the usefulness of Modularity and the experience of creating
> modules for packagers. Thoe team is proposing a renewed objective to
> the Fedora Council.
>
> You can read the proposal at:
> https://pagure.io/Fedora-Council/council-docs/pull-request/61#request_diff
>
> The Council will vote on this in two weeks.
>
> This is also posted to the Community Blog:
> https://communityblog.fedoraproject.org/renewing-the-modularity-objective/
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
