Re: EOL and Obsoletes in Modularity

On Tue, Nov 03, 2020 at 03:22:45PM +0100, Vít Ondruch wrote: > Have anybody considered to use AppData for that information? Or at least > similar approach? > I haven't. AppData looks very similar to our use case. Thanks for the pointer. -- Petr signature.asc Description: PGP signature _

Re: EOL and Obsoletes in Modularity

Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a): On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote: Daniel Mach writes: The API is clear: DNF expects additional 'modulemd-obsoletes' YAML documents in modules.yaml. The new document format is getting into libmodulemd and there's going to b

Re: EOL and Obsoletes in Modularity

On Tue, Nov 03, 2020 at 02:17:59PM +0100, Petr Šabata wrote: > On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar wrote: > > Another option would be adding the EOL data into modules dist-git > > repositories. To the same branches where modules are built from. But > > a different file. Pungi would enumarate

Re: EOL and Obsoletes in Modularity

On Tue, Nov 3, 2020 at 1:16 PM Petr Pisar wrote: > Another option would be adding the EOL data into modules dist-git > repositories. To the same branches where modules are built from. But > a different file. Pungi would enumarate all module builds directed to > a compose, locate their dist-git sou

Re: EOL and Obsoletes in Modularity

Dne 03. 11. 20 v 13:14 Petr Pisar napsal(a): On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote: Daniel Mach writes: The API is clear: DNF expects additional 'modulemd-obsoletes' YAML documents in modules.yaml. The new document format is getting into libmodulemd and there's going to

Re: EOL and Obsoletes in Modularity

On Mon, Nov 02, 2020 at 12:33:23PM +0100, Daniel Mach wrote: > From DNF team's perspective, a packaging system is not complete without > Obsoletes. That's why we believe module Obsoletes are a must have to ensure > smooth system upgrades and regular updates on systems consuming Rawhide (or > any ot

Re: EOL and Obsoletes in Modularity

On Tue, Nov 03, 2020 at 12:26:46AM +0100, Dan Čermák wrote: > Daniel Mach writes: > > The API is clear: DNF expects additional 'modulemd-obsoletes' YAML > > documents in modules.yaml. The new document format is getting into > > libmodulemd and there's going to be documentation on how to write it

Re: EOL and Obsoletes in Modularity

Hi all, Daniel Mach writes: > Hi, > > > Dne 27. 10. 20 v 13:52 Martin Curlej napsal(a): >> Hi, >> >> EOL and Obsoletes were planned as a feature of Modularity. The feature >> should enable to set shorter/longer life cycles on Modules than the OS >> release. The initial idea was to set this in

Re: EOL and Obsoletes in Modularity

I haven't got a need to use obsolete modules yet, so I'll write my opinion about the module EOL only. Q: Should the EOL be configurable to mid-release date? The others in this discussion showed it makes sense to EOL a module mid-release. Since the modules are built on and on (new build targets ar

Re: EOL and Obsoletes in Modularity

On Mon, Nov 02, 2020 at 08:37:30AM -0500, Stephen John Smoogen wrote: > On Mon, 2 Nov 2020 at 06:55, Miro Hrončok wrote: > > > On 11/2/20 12:33 PM, Daniel Mach wrote: > > > Then there's a question how to get the documents into modules.yaml. From > > my > > > perspective, it's up to Fedora infra/r

Re: EOL and Obsoletes in Modularity

On Mon, 2 Nov 2020 at 06:55, Miro Hrončok wrote: > On 11/2/20 12:33 PM, Daniel Mach wrote: > > Then there's a question how to get the documents into modules.yaml. From > my > > perspective, it's up to Fedora infra/releng/packaging people. Whether it > should > > be in dist-git, git repo (similar

Re: EOL and Obsoletes in Modularity

On 11/2/20 12:33 PM, Daniel Mach wrote: Then there's a question how to get the documents into modules.yaml. From my perspective, it's up to Fedora infra/releng/packaging people. Whether it should be in dist-git, git repo (similar to modulemd-defaults or comps), PDC, Bodhi (similar to updateinfo

Re: EOL and Obsoletes in Modularity

Hi, Dne 27. 10. 20 v 13:52 Martin Curlej napsal(a): Hi, EOL and Obsoletes were planned as a feature of Modularity. The feature should enable to set shorter/longer life cycles on Modules than the OS release. The initial idea was to set this information in the disgit metadata of a Module. As

Re: EOL and Obsoletes in Modularity

On Thu, Oct 29, 2020 at 8:17 AM Miro Hrončok wrote: > > On 10/29/20 12:43 PM, Petr Pisar wrote: > >> 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 rele

Re: EOL and Obsoletes in Modularity

On 10/29/20 12:43 PM, Petr Pisar wrote: 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. > That's how it is suspposed to work. Read "Pr

Re: EOL and Obsoletes in Modularity

On Thu, Oct 29, 2020 at 12:43:05PM +0100, Petr Pisar wrote: > Currently EOL is defined per stream in PDC. The initial value is provided by > packagers with "fedpkg request-branch --sl" command. Then the value can be > edited by relengs based on a ticket. In general, a big +1 to keeping this decent

Re: EOL and Obsoletes in Modularity

On Wed, Oct 28, 2020 at 12:13:27PM +0100, Martin Curlej wrote: > On Tue, Oct 27, 2020 at 3:53 PM Petr Pisar wrote: > > 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

Re: EOL and Obsoletes in Modularity

On Wed, Oct 28, 2020 at 01:02:56PM +0100, Miro Hrončok wrote: > 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 tracke

Re: EOL and Obsoletes in Modularity

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 > wrote:

Re: EOL and Obsoletes in Modularity

First thank you Neil and Petr for your feedback on this. I really appreciate it. On Tue, Oct 27, 2020 at 2:02 PM Neal Gompa 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 i

Re: EOL and Obsoletes in Modularity

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 > revi

Re: EOL and Obsoletes in Modularity

On Tue, Oct 27, 2020 at 8:52 AM Martin Curlej wrote: > Hi, > > EOL and Obsoletes were planned as a feature of Modularity. The feature > should enable to set shorter/longer life cycles on Modules than the OS > release. The initial idea was to set this information in the disgit > metadata of a Modu

EOL and Obsoletes in Modularity

Hi, EOL and Obsoletes were planned as a feature of Modularity. The feature should enable to set shorter/longer life cycles on Modules than the OS release. The initial idea was to set this information in the disgit metadata of a Module. As time went by the requirements have changed. >From my point