On 10/28/20 12:13 PM, Martin Curlej wrote:
First thank you Neil and Petr for your feedback on this. I really appreciate it.
Thanks to you Martin as well for trying to be open about future modularity
development.
On Tue, Oct 27, 2020 at 2:02 PM Neal Gompa <ngompa13@xxxxxxxxx
<mailto:ngompa13@xxxxxxxxx>> wrote:
At the end of the day for Fedora, packagers are maintaining the modules, so
they should be able to mark a module as EOL when they feel like they don't
want it in the distribution anymore. As for module obsoletes, this is
necessary for supporting transitions and upgrades, which broke /two/ Fedora
release upgrades because there was no way to handle this.
Additionally, with my third-party packager hat on, I need these to be
declarable in the module metadata so that it's easy to convey in a
machine-enforceable way when something is maintained/supported or not. I
don't know which third-parties you've been talking to, but as an actual
third-party packager who does work for an ISV that supports Fedora and
RHEL/CentOS for a product, I don't know where else I would put it.
Yes i agree, it seems i did not explain myself correctly. The initial proposal
is to include the EOL and obsoletes inside the existing metadata files
(modulemd) so i meant that. So if you wanted to handle the EOL and obsoletes
metadata differently, let say it would be supervised by an engineering team
(don't mean FESCO but in general), it could cause problems. But it seems the
proposal by dmach in
https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
<https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL> already
already solves that problem with a separated metadata file. So the point is
probably mute at this point as you can distribute/store the new metadata file as
you see fit.
This all seem to revolve around the (mysterious) engineering team. Who "owns"
the modular EOL information in Fedora, if not the packagers? IIRC There is no
modularity supervision team in Fedora. The Fedora modularity issue tracker is
dead since January/February, the meetings have been cancelled.
From your emails it seems that you are not interested in getting involved at
this level and would rather see some Fedora Modularity group/person to drive the
policies and content. Do I get that right?
On Tue, Oct 27, 2020 at 3:53 PM Petr Pisar <ppisar@xxxxxxxxxx
<mailto:ppisar@xxxxxxxxxx>> wrote:
On Tue, Oct 27, 2020 at 01:52:00PM +0100, Martin Curlej wrote:
> From my point of view right now it seems that this information should not
> be a part of the module (disgit, repository metadata). It is prone to human
> error when we leave this in the hands of a packager. So this would need a
> review of Engineering to be reliable.
>
Did you mean a Release Engineering, or a general engineering like FESCo?
Actually any team really. I try to look at Modularity as not environment
specific (i. e. company/organization/community in which it is used.). But it
seems this is Policy specific issue not a technology issue.
IIRC the current policy is: no modular EOLs mid-release (although I've failed to
locate it at the Polices page of the Modularity documentation).
While I get Petr's point about the usefulness of mid-release EOLs, I am a bit
worried about the UX if we allowed that.
Let's say Anna enables the postgresql:9.5 stream on her database server with
Fedora 33 and once the stream goes EOL (presumably around the upstream EOL date
in February 2021), postgresql suddenly updates to a newer version? Wouldn't Anna
be frustrated by this behavior? IMHO our users are familiar with this happening
on Fedora release boundary only.
OTOH If the EOL date is informational only (Anna keeps postgresql:9.5 but sees a
warning during dnf upgrades) and the obsoletes only actually happen on a
specific user action (and on release boundary), great. In March, Anna prepares
for the big update, backs up all her data and runs `dnf module switch
postgres:9.5 postgres:11` or `dnf module upgarde-to-supported postgres` or
whatever. Anna is not frustrated.
As a side note, having the latest postgresql automatically is useful as well,
especially on Anna's developer workstation. E.g. if Anna installs
postgresql:latest (or :stable or whatever) she would always get the latest
version. This can be done automagically or manually with an actual "latest"
stream defined as well (the stream would duplicate content from the latest
versioned stream).
However, designing such policies is Yet Another Extremely Hard Problem™ and if
we don't have involvement/ownership by the Red Hat's modularity team I am afraid
this is doomed to fail. I'd be very happy to see some emerging community around
this, but currently I don't, so please forgive my pessimism.
Why module obsoletes are dangerous for mere packagers, while package obsoletes
are safe? Can you elaborate?
It depends how you will handle the obsoletes and again how you set policies. For
example, you could obsolete a module stream which packages a major version of a
software with another major version. Or by human error, where you obsolete a
module stream with an older module stream.
Modular obsoletes should not be any more dangerous than RPM obsoletes. However
we have a strong history of modular content breaking the distro with no clear
way out. So I guess caution is reasonable.
What are the other means which the 3rd parties use?
Your imagination is the limit. ;) Just joking. Now seriously. For example,
Redhat and Fedora. The information about EOL and Obsoletes will be used and
distributed differently. Also it depends to whom you serve your content. If you
build modules just for your company and distribute it on your intranet it's
different from a community driven opensource linux distribution.
I am not against EOL or Obsoletes, I know they are necessary just to get some
other point of view, so we have all the requirements.
Actually when I read through my email and the points you made guys, it seems
most of my concerns are policy based. So it seems we need to set some rules and
policies in place so we don't repeat similar problems which occurred with the
introduction of default streams or modularization of Java. Basically Modularity
does not want to break Fedora again. :)
I believe the lack of policies when the technology was introduced to Fedora
allowed the breakage to happen. I'm glad you want to avoid that now. However if
you are not prepared to design (and enforce) the policies, the only way to
totally avoid the possible breakage is by not introducing the technology to
Fedora at all (or disallowing it, which is a low-effort policy by itself).
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
