[modularity] Modularity Team Meeting Minutes (Sept 17, 2019)
by Langdon White
Minutes:
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-09-17/modularity....
Minutes (text):
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-09-17/modularity....
Log:
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-09-17/modularity....
============================================================
#fedora-meeting-3: Weekly'ish Meeting of the Modularity Team
============================================================
Meeting started by langdon at 15:02:03 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-3/2019-09-17/modularity....
.
Meeting summary
---------------
* roll call (langdon, 15:02:29)
* agenda (langdon, 15:03:42)
* starting with https://pagure.io/modularity/issue/148 (langdon,
15:04:46)
* all other tickets (langdon, 15:04:52)
* open floor (langdon, 15:04:57)
* "Encourage following branch naming guidelines in default streams":
https://pagure.io/modularity/issue/148 (langdon, 15:05:39)
* AGREED: modularity team recommends packages get a branch per
upstream "version" (langdon, 15:58:45)
* ACTION: contyk to run the idea by the FPC (langdon, 15:59:06)
* langdon to chair next week (sept 24) (langdon, 16:01:49)
Meeting ended at 16:02:07 UTC.
Action Items
------------
* contyk to run the idea by the FPC
Action Items, by person
-----------------------
* contyk
* contyk to run the idea by the FPC
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* langdon (69)
* asamalik (50)
* contyk (48)
* cipherboy (21)
* zodbot (9)
* mbooth (3)
* sillebille (2)
* sgallagh (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
4 years, 7 months
Re: Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
by Kevin Kofler
> Enable module default streams in the buildroot repository for modular
> and non-modular RPMs.
>
> == Summary ==
> This Change (colloquially referred to as "Ursa Prime") enables the
> Koji build-system to include the RPM artifacts provided by module
> default streams in the buildroot when building non-modular (or
> "traditional") RPMs.
>
> == Owner ==
> * Name: [[User:Sgallagh| Stephen Gallagher]]
> * Email: sgallagh(a)redhat.com
> * Responsible WG: Modularity WG
I have already stated this multiple times in other threads, but just so that
nobody claims that I have not given feedback to this change (which has been
claimed for some other changes in a similar situation), I am going to state
this again:
I oppose this change because I believe Miro's proposal to require all
packages to have a non-modular version (i.e., to ship the default stream as
non-modular packages) is the much better approach to the issue and makes
this change proposal entirely moot.
To be clear, I propose the following:
* All packages MUST have a default version in any given Fedora release.
* The default version MUST be shipped as non-modular (not as a modular
default stream).
* It follows that packages cannot be module-only.
* This applies to ALL packages including build tools. In particular,
packages must not be hidden from users through constructs such as
buildroot-only modules or non-API packages in modules. If a package is in
a module, no matter in what function, there MUST be a default version in
the non-modular repository.
* The fedora-modular repository SHOULD be disabled by default on user
machines, matching the current build system behavior. This also helps
enforcing the above policies.
I believe that the above proposal is essentially identical to Miro's
proposal from the other thread, which I support. The exact wording can be
discussed, but it is important that the essence of the proposal (module-only
= no go) is retained.
Kevin Kofler
4 years, 6 months
Re: Agenda for Tuesday's Modularity Working Group Meeting
(2019-01-22)
by Nils Philippsen
...and it was cancelled because the usually attending people are on
travels.
On Tue, 2019-01-22 at 15:33 +0100, Nils Philippsen wrote:
> Sorry that this one's a little late, scheduling snafu...
>
> Find below a list of topics which are planned to be discussed in the
> Fedora Modularity Working Group meeting on Tuesday at 15:00 UTC in
> #fedora-meeting-3 on irc.freenode.net.
>
> To find out when this is in your local time zone, check the Fedora
> Calendar (if you've set it and are logged in):
> https://apps.fedoraproject.org/calendar/modularity/#m5249
>
> Alternatively, to convert UTC to your local time zone, take a look at
> http://fedoraproject.org/wiki/UTCHowto
>
> or run:
> date -d 'Tuesday 15:00 UTC'
>
> Links to all issues below can be found at:
> https://pagure.io/modularity/report/meeting_agenda
>
> = Discussed and Voted =
> Modularity WG Charter (contd.)
> https://pagure.io/modularity/issue/119
> DECISION (+4, 0, -0)
>
> = Followups =
>
> #topic #112 Discussion: Module lifecycles
> #link https://pagure.io/modularity/issue/112
> .modularity 112
> #link https://pagure.io/fesco/issue/2027
>
> #topic #115 Discussion: Stream branch ownership for packages &
> modules
> #link https://pagure.io/modularity/issue/115
> .modularity 115
> #link https://pagure.io/fesco/issue/2028
>
> = New business =
>
> N/A
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue. The report of the agenda items can be found at
> https://pagure.io/modularity/report/meeting_agenda
>
> If you would like to add something to this agenda, you can file a new
> issue at https://pagure.io/modularity/issues, or bring it up at the
> end
> of the meeting during the open floor topic. Note that the meeting is
> one hour long and issues we don't get around to discussing may be
> deferred until the following meeting.
>
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
5 years, 3 months
Re: How to obsolede module?
by Neal Gompa
On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppisar(a)redhat.com> wrote:
>
> On Tue, Jan 14, 2020 at 05:21:40AM -0500, Josef Ridky wrote:
> > Hi folks,
> >
> > Does anyone know, how can I obsolete modular version of package?
> >
> > TL;DR
> >
> > I have one package (gimp) that is now available as RPM and Module at the
> > same time in Fedora. Due of modular version makes issues to users during
> > system upgrade, I've decided to remove (obsolete) modular version of gimp
> > and keep the RPM version only.
> >
> > Question is, How can I set new RPM build to be the replacement for the
> > modular one? Especially, is it possible, when someone with modular gimp
> > installed types `dnf upgrade gimp`, that command will remove modular gimp
> > and installs new RPM instead?
> >
> RPM Obsolets triggers a package removal and can be placed into any package.
> However, you cannot obsolete a module (i.e. disable or reset it)
> programatically. This is by design an action that needs an explicit user's
> consent. If you need modularity to support marking modules end-of-life,
> I recommend you contacting Modularity team (psabata) that has been requested
> to implement this feature for a long time.
>
I still can't believe that anyone thought this was okay... :(
> Since any active module content masks same-named non-modular packages, you
> cannot uninstall the modular gimp package by putting an Obsoletes into the
> non-modular gimp package. Until the user explicitly disables the module, your
> non-modular gimp will be invisible and thus the Obsoletes should not take any
> effect.
>
> But there is an solution in Fedora if your module exists in updates repository
> only. Because Fedora mirrors keep only the latest module version, it should
> be possible to place another package into the module, make it Obsolete and
> Provide the modular gimp package. This causes DNF to replace the modular
> gimp package with the another package. After that DNF should make the
> non-modular gimp visible. Then you can release a non-modular gimp with higher
> release than the Provided "gimp" symbol and that will obsolete the another
> package. This should DNF make to replace the modular another package with your
> non-modular gimp package.
>
> But this only a theory. Maybe it won't work because of a caching of the
> modular metadata somewhere.
>
This theory doesn't work if your module had defaults because all the
YAML documents are downloaded and applied to DNF locally. If it
didn't, then it'd work.
--
真実はいつも一つ！/ Always, there's only one truth!
4 years, 3 months
[Modularity] Working Group IRC meeting minutes (2018-08-21)
by Nils Philippsen
=================================================================
#fedora-meeting-3: Weekly Meeting of the Modularity Working Group
=================================================================
Meeting started by nils at 14:01:02 UTC.
Minutes: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-08-21/modularity_...
Minutes (text): https://meetbot.fedoraproject.org/fedora-meeting-3/2018-08-21/modularity_...
Log: https://meetbot.fedoraproject.org/fedora-meeting-3/2018-08-21/modularity_...
Meeting summary
---------------
* Roll Call (nils, 14:01:14)
* Agenda (nils, 14:02:36)
* [asamalik] Replacing docs.pagure.org/modularity with a redirect to
the Fedora Docs / Modularity (nils, 14:03:07)
* [contyk] open issues (nils, 14:03:24)
* AOB (nils, 14:03:28)
* Replacing docs.pagure.org/modularity with a redirect to the Fedora
Docs / Modularity (nils, 14:03:42)
* AGREED: let old Pagure instance redirect to Fedora Docs/Modularity
(nils, 14:17:05)
* Wanna talk about lifecycles? (nils, 14:18:30)
* ACTION: asamalik starts a thread on the devel list about managing
module lifecycles. The result (or a first iteration) will be
reviewed in the next meeting. asamalik will also create a ticket
for
that so we don't forget. (asamalik, 14:42:19)
* open issues (nils, 14:42:46)
* LINK: https://pagure.io/modularity/issuess (nils, 14:43:36)
* LINK: https://pagure.io/modularity/issue/1033 (nils, 14:46:20)
* LINK: https://pagure.io/modularity/issue/977 (nils, 14:50:43)
* LINK: https://pagure.io/modularity/issue/722 (nils, 14:52:45)
* ACTION: asamalik looks into what if anything runs in infrastructure
testing, if it needs replacing
(https://pagure.io/modularity/issue/31)) (nils, 15:01:55)
Meeting ended at 15:03:59 UTC.
Action Items
------------
* asamalik starts a thread on the devel list about managing module
lifecycles. The result (or a first iteration) will be reviewed in the
next meeting. asamalik will also create a ticket for that so we don't
forget.
* asamalik looks into what if anything runs in infrastructure testing,
if it needs replacing (https://pagure.io/modularity/issue/31)
Action Items, by person
-----------------------
* asamalik
* asamalik starts a thread on the devel list about managing module
lifecycles. The result (or a first iteration) will be reviewed in
the next meeting. asamalik will also create a ticket for that so we
don't forget.
* asamalik looks into what if anything runs in infrastructure
testing,
if it needs replacing (https://pagure.io/modularity/issue/31)
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* asamalik (86)
* nils (77)
* contyk (52)
* langdon (30)
* zodbot (12)
* sgallagh (4)
* x3mboy (2)
* bcotton (1)
* dgilmore (1)
* mikedep333 (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
5 years, 8 months
Re: What are the benefits of default modular streams over non-modular
packages?
by Miro Hrončok
On 15. 11. 19 12:14, Joe Orton wrote:
> On Thu, Nov 14, 2019 at 04:56:28PM +0100, Miro Hroncok wrote:
>> I'll admit that I personally don't see any benefits, but of course that
>> doesn't mean that they don't exist or that it's not worth having this
>> discussion.
>>
>> Considering we have 6 default modular streams, let me acknowledge that for
>> the maintainers who decided to deliver default modular streams instead of
>> non-modular packages, there clearly are some benefits.
>> While some of us might not understand them, let's not say there are none.
>> But even if there are clear benefits for the maintainers of those modules,
>> I'm asking about the benefits for everybody else.
>
> Seems like a bit of an odd question. There is an end-user benefit from
> making multiple module streams available both in the short run (more
> features/choices today) and long run (better tested software via making
> development/unstable releases available more widely).
I don't understand how are default modular streams valuable to that benefit.
(let's have a lamafarm software in the examples)
Suppose I have this situation:
- lamafarm version 1.x is in default modular stream only
- there are no other streams with other versions of lamafarm
Vs. this situation:
- lamafarm version 1.x is in non-modular Fedora
- there are no modular streams with other versions of lamafarm
Where is the end-user benefit with the modular default stream? I don't see it,
sorry.
Or suppose I have this situation:
- lamafarm version 1.x is in default modular stream only
- there are N other streams with other versions of lamafarm (such as 2.x, ...)
Vs. this situation:
- lamafarm version 1.x is in non-modular Fedora
- there are N moulear streams with other versions of lamafarm (such as 2.x, ...)
Where is the end-user benefit with the modular default stream? I don't see it
either, sorry.
> This comes at a high cost to package owners if we have to keep
> non-modular packages - we have to maintain, build, and test X streams
> plus Y non-modular release branch builds for each component, rather than
> just X streams.
Yes. This is the benefit of the default modular stream for the modular
maintainers. I have never questioned it.
I have even proposed that we take the default modular stream RPMs and we add
them to our non-modular repository when we compose it, in order to keep that
benefit for the modular maintainers. It was turned down almost immediately.
> In some cases the costs will be prohibitive to
> supporting modular streams - the aim of switching to default streams +
> dropping non-modular packages is precisely to eliminate that cost
> difference.
In my opinion (and that is my very subjective opinion, but based on experience)
the cost of that difference is otherwise paid by everybody else.
The group of everybody else is very much bigger than the group of modular
maintainers. Hence, I'd approve such trade off.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 5 months
Re: Removal of Modular repos broke upgrades to Fedora 39: What now?
by Adam Williamson
On Fri, 2023-08-04 at 12:16 +0200, Miro Hrončok wrote:
> Hello folks,
>
> With the retirement of modularity, the modular dnf repositories for Fedora 39
> no longer exist. However, this will introduce a problem during upgrades. When
> users try to upgrade from previous Fedora releases with fedora-repos-modular
> installed, they will hit fatal errors that will probably look like this:
>
> Errors during downloading metadata for repository 'fedora-modular':
> - Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x8...
> (IP: ...)
> - Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x8...
> (IP: ...)
> - Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x8...
> (IP: ...)
> Error: Failed to download metadata for repo 'fedora-modular': Cannot prepare
> internal mirrorlist: Status code: 404 for
> https://mirrors.fedoraproject.org/metalink?repo=fedora-modular-39&arch=x8...
> (IP: ...)
>
> Or:
>
> Error: Failed to download metadata for repository 'fedora-modular': Cannot
> download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
>
> (The actual error might differ depending on the exact state of the removal of
> the modular repos and their mirrorlist etc.)
>
>
> This is caused by the combination of the following facts:
>
> - the modular repo configuration in Fedora 37/38 has skip_if_unavailable=False
> - when the releasever is set to 39, the URLs of the repos give error 404
>
> This is a big deal, because even users who don't use modularity at all (but
> have not uninstalled fedora-repos-modular) will not be able to upgrade to
> Fedora 39+ without reaching for help.
>
> Adam outlined 3 options to solve this problem in the bugzilla where he reported
> this: https://bugzilla.redhat.com/2228827
So an update to this, thanks to Miro for double-checking me: I had
forgotten that the openQA tests edit the dnf config to point to the
compose tree (in order to make sure we're testing the right thing -
there's an ordering problem if we just test the actual 'rawhide'
location on the mirror system, it might not have been synced by the
time the tests run).
It looks like the public 'rawhide' location *does* still have a Modular
tree:
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Modular/
but there's still a problem there, because...it's now just stale data.
That is the Modular tree from the 20230802.n.0 compose, and unless
someone does something about it, it always *will* be. Keeping the last
set of modular repos frozen in amber forever doesn't seem like the best
permanent situation :)
So this is still an issue, but at least it doesn't actually immediately
break upgrades to Rawhide using the default dnf config. I'll downgrade
the bug severity appropriately.
--
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @adamw(a)fosstodon.org
https://www.happyassassin.net
8 months, 3 weeks
Re: Agenda for Tuesday's Modularity Working Group Meeting
(2018-12-18)
by Nils Philippsen
Obviously, this should be for today, 2018-12-18.
On Tue, 2018-12-18 at 15:54 +0100, Nils Philippsen wrote:
> (Sorry for sending this so late.)
>
> Find below a list of topics which are planned to be discussed in the
> Fedora Modularity Working Group meeting on Tuesday at 15:00 UTC in
> #fedora-meeting-3 on irc.freenode.net.
>
> To find out when this is in your local time zone, check the Fedora
> Calendar (if you've set it and are logged in):
> https://apps.fedoraproject.org/calendar/modularity/#m5249
>
> Alternatively, to convert UTC to your local time zone, take a look at
> http://fedoraproject.org/wiki/UTCHowto
>
> or run:
> date -d 'Tuesday 15:00 UTC'
>
> Links to all issues below can be found at:
> https://pagure.io/modularity/report/meeting_agenda
>
> = Discussed and Voted =
> Modularity WG Charter Review
> https://pagure.io/modularity/issue/118
> https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2018-...
> (+3, 0, -0)
>
> We'll skip the WG meetings scheduled for 2018-12-25 and 2019-01-01
> because many people are absent.
> https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2018-...
> (+3, 0, -0)
>
> = Followups =
> #topic #112 Discussion: Module lifecycles
> https://pagure.io/modularity/issue/112
>
> #topic #115 Discussion: Stream branch ownership for packages &
> modules
> https://pagure.io/modularity/issue/115
>
> = New business =
> #topic #119 Modularity WG Charter (contd.)
> https://pagure.io/modularity/issue/119
>
> = Open Floor =
>
> For more complete details, please visit each individual
> issue. The report of the agenda items can be found at
> https://pagure.io/modularity/report/meeting_agenda
>
> If you would like to add something to this agenda, you can file a new
> issue at https://pagure.io/modularity/issues, or bring it up at the
> end
> of the meeting during the open floor topic. Note that the meeting is
> one hour long and issues we don't get around to discussing may be
> deferred until the following meeting.
>
--
Nils Philippsen "Those who would give up Essential Liberty to
Software Engineer purchase a little Temporary Safety, deserve neither
Red Hat Liberty nor Safety." -- Benjamin Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
5 years, 4 months
Re: Modularity and the system-upgrade path
by Lukas Ruzicka
> So despite providing zero feedback here, this was voted at the modularity
> meeting:
>
> * Tagging Module Defaults into non-modular repo (sgallagh, 15:41:37)
> * AGREED: We disagree with merging default streams into the main repo
> as non-modular packages. Our approach is to implement a mechanism of
> following default streams to give people the experience they want.
> (+4 0 -0) (asamalik, 16:07:40)
>
Well,
based on this discussion, pushing content in modular defaults is not the
experience that people want. I have been a bit ill
for some time and before I could add my point to the discussion, everything
has been more or less said.
Just for illustration, this is what I wanted to say about it:
1. Modularity should stay away from my system until I call for it -> now
it is not the case, because modularity sneaks into users' computer through
modular defaults that overcome the non-modular packages. Gimp is the first
such "horse" that jumps into almost everybody's desktop and they are
modular without even knowing it.
2. Modularity should provide alternative content, if I need it and when
I need it. Modules should be installable only through "dnf module" command
and not through the regular dnf command, so that I explicitely need to
allow modularity on my system.
3. The naming conventions of the streams should be *obligatory* for
every module packager. So, if we decide that we want a "latest" stream,
then all modules should have a "latest" stream for rolling updates.
Currently, they all have various names of streams, from which I cannot tell
anything. If there should be a "slow" path, then again, all modules should
have a "slow" path.
4. Non-modular Fedora must be a valid use case and remain an option.
5. If I decide to go modular, there must be a way to go non-modular
again, without breaking the system. Or, if modular is the only option, so
if I go into specific streams, there must be a way to go to defaults
without breaking the system. With non-modular defaults, this seems easy.
With modules? I am not sure.
6. We need to expect that once there are hundreds of modules, people
will install all possible combinations and they all will need to work. I am
not sure, we will be able to test something like that.
Seeing the reaction of the Modularity WG ... I do not understand how it is
possible that such important decisions are taken by 4 people without any
Fedora wide discussions like this. And yet, it seems a little bit that even
opinions on this list will not fall on fertile grounds.
I wish the communication improved in the first place. Community means
togetherness.
> should aim for solution 1. if solution 2. is not negotiable by the
> modularity WG.
>
+1
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
4 years, 6 months