Re: Fedora 33 System-Wide Change proposal: Introduce module Obsoletes and EOL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





Dne 30. 03. 20 v 17:10 Petr Pisar napsal(a):
On Mon, Mar 30, 2020 at 10:30:51AM -0400, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
[...]
*** When a module stream gets removed from a Fedora release, the
maintainer of the module stream must provide a modulemd document with
Obsoletes or EOL data.

I'd like to point out that Fedora Project has already possed EOL dates. They
are provided by packagers when requesting for new dist-git branch (i.e. when
creating a new stream) and they are stored in Fedora PDC.

Examples for perl:5.26
<https://pdc.fedoraproject.org/rest_api/v1/component-branch-slas/?branch_type=module&global_component=perl&branch=5.26>:

     {
         "id": 691015,
         "sla": "bug_fixes",
         "branch": {
             "id": 345929,
             "name": "5.26",
             "global_component": "perl",
             "type": "module",
             "critical_path": false,
             "active": false
         },
         "eol": "2019-12-01"
     }

I'll take a look.
This seems to be a reasonable input for checking which streams should be EOLed. Maybe we could automate creating the modulemd obsoletes metadata based on this.

So if you execute "dnf module list perl" in Fedora 30 you should not see
perl:5.26 accoding to this change.

Provided Fedora Project is going to keep requesting the EOL datum on creating
a branch, pungi could query PDC and automatically generate the
module-obsolete documents for streams and contexts that require those streams.
Sounds reasonable.


The only missing piece of information is the obsoleting stream. Either the
maintainer could edit the PDC data with this information when it is known (as
he already can edit the eol date by a rel-eng ticket
<https://pagure.io/releng/new_issue>; see module_eol template type), or the
maintainer could supply its own module-obsolete document (how?) that would
inhibit the generating the document for the same stream by pungi.
To be honest, I don't know how it works exactly and how to tweak the existing process, but I believe that people from Fedora infra will help me with that.


In both cases it would be great if an Fedora infrastrucure send a notification
to the maintainer the OEL is approaching and he should provide the data (e.g.
by filing a bug report into Bugzilla against that module).

-- Petr


_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux