Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On 14. 03. 19 12:50, Miro Hrončok wrote: On 14. 03. 19 12:33, Dominik 'Rathann' Mierzejewski wrote: On Thursday, 14 March 2019 at 10:06, Miro Hrončok wrote: On 14. 03. 19 7:51, Dridi Boukelmoune wrote: [...] Maybe what we need is to have koji for example refusing epoch bumps (and thus failing the build) if _not bumping_ epoch would _not break_ the upgrade path to ensure that epoch is only ever increased when we need to force a downgrade or when upstream changes versioning schemes in a way not considered an upgrade by RPM's NVR. Or use Pull Requests in the workflow and have somebody else review the commit before it gets to Fedora? While that's a good idea in general, how do you propose to implement this for packages that have only a single maintainer? Offer PR review swaps? TBH I was mostly responding to the ceph package, where: * there is more than 1 maintainer * most of the commits are "dump hundreds of upstream changes here" I'm concerned about this type of "maintenance". Giving the downstream spec some real love could have prevented this issue (it would not eliminate human error entirely). -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On 14. 03. 19 12:33, Dominik 'Rathann' Mierzejewski wrote: On Thursday, 14 March 2019 at 10:06, Miro Hrončok wrote: On 14. 03. 19 7:51, Dridi Boukelmoune wrote: [...] Maybe what we need is to have koji for example refusing epoch bumps (and thus failing the build) if _not bumping_ epoch would _not break_ the upgrade path to ensure that epoch is only ever increased when we need to force a downgrade or when upstream changes versioning schemes in a way not considered an upgrade by RPM's NVR. Or use Pull Requests in the workflow and have somebody else review the commit before it gets to Fedora? While that's a good idea in general, how do you propose to implement this for packages that have only a single maintainer? Offer PR review swaps? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Thursday, 14 March 2019 at 10:06, Miro Hrončok wrote: > On 14. 03. 19 7:51, Dridi Boukelmoune wrote: [...] > > Maybe what we need is to have koji for example refusing epoch bumps > > (and thus failing the build) if _not bumping_ epoch would _not break_ > > the upgrade path to ensure that epoch is only ever increased when we > > need to force a downgrade or when upstream changes versioning schemes > > in a way not considered an upgrade by RPM's NVR. > > Or use Pull Requests in the workflow and have somebody else review the > commit before it gets to Fedora? While that's a good idea in general, how do you propose to implement this for packages that have only a single maintainer? Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On 14. 03. 19 7:51, Dridi Boukelmoune wrote: On Fri, Mar 8, 2019 at 9:08 PM Kaleb Keithley wrote: The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x in f30/rawhide. It just occurred to me that this was a normal update when epoch was increased, right? Maybe what we need is to have koji for example refusing epoch bumps (and thus failing the build) if _not bumping_ epoch would _not break_ the upgrade path to ensure that epoch is only ever increased when we need to force a downgrade or when upstream changes versioning schemes in a way not considered an upgrade by RPM's NVR. Or use Pull Requests in the workflow and have somebody else review the commit before it gets to Fedora? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, Mar 8, 2019 at 9:08 PM Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x > in f30/rawhide. It just occurred to me that this was a normal update when epoch was increased, right? Maybe what we need is to have koji for example refusing epoch bumps (and thus failing the build) if _not bumping_ epoch would _not break_ the upgrade path to ensure that epoch is only ever increased when we need to force a downgrade or when upstream changes versioning schemes in a way not considered an upgrade by RPM's NVR. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
> All that's broken is a 3rd party's assumption that their Epoch setting > is greater than Fedora's. Assuming Ceph want to keep using Epoch in > this way, upstream can simply bump their Epoch again to be greater than > Fedora's new Epoch. Or bump their Epoch to something much less likely to conflict in the future, like 10 or 100. Dridi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 09:29:52AM -0400, Kaleb Keithley wrote: > On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé > wrote: > > > The ability to have multiple different builds of the same software which > > users can choose between, sounds alot like the use case for modularity. > > Abusing Epoch to try to address this kind of situation feels like a pretty > > undesirable approach, as this problem with suddenly clashing Epochs will > > illustrate. > > > > If only there had been modularity before f29 that might have been > reasonable a reasonable claim, IMO. Sure, in the past it wasn't possible, but I think it is a more viable long term approach to the general scenerio. > But it wasn't. My issue is that there's no way to fix things when a > mistake is made. > > Perhaps I misunderstand the purpose of rawhide. I appreciate that "we" try > to _not_ break things in rawhide, but when they do, there should be a way > to fix them. Well technically Fedora rawhide isn't actually broken by the epoch change. All that's broken is a 3rd party's assumption that their Epoch setting is greater than Fedora's. Assuming Ceph want to keep using Epoch in this way, upstream can simply bump their Epoch again to be greater than Fedora's new Epoch. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé wrote: > The ability to have multiple different builds of the same software which > users can choose between, sounds alot like the use case for modularity. > Abusing Epoch to try to address this kind of situation feels like a pretty > undesirable approach, as this problem with suddenly clashing Epochs will > illustrate. > If only there had been modularity before f29 that might have been reasonable a reasonable claim, IMO. But it wasn't. My issue is that there's no way to fix things when a mistake is made. Perhaps I misunderstand the purpose of rawhide. I appreciate that "we" try to _not_ break things in rawhide, but when they do, there should be a way to fix them. -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 9:12 AM Kaleb Keithley wrote: > > > > On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa wrote: >> >> Heck, the spec file >> that is in Fedora is basically an openSUSE spec with Fedora >> conditionals in it. > > > The ceph.spec file in Fedora is based on the upstream ceph.spec.in file; not > on anything in/from openSUSE. > > The upstream ceph.spec.in file is full of Fedora and SUSE conditionals. > > If openSUSE also used the upstream spec file then it shouldn't surprise > anyone that they are similar. > I'm keenly aware of where that spec file comes from, since I saw how it was developed. It did start out as something for Fedora, but SUSE folks started actively contributing in 2012 and merging their packaging into upstream, changing it from a Fedora-style package to a SUSE-style one. Today, Ceph packaging in OBS is fetched through a source service and used pretty much verbatim from upstream. I imagine you do something similar to bring it downstream, too. I'm not begrudging them of it, mind you. But it's a lie to say that it isn't an openSUSE-style spec file. It's nice to know that we're mostly compatible these days... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 8:22 AM Neal Gompa wrote: > Heck, the spec file > that is in Fedora is basically an openSUSE spec with Fedora > conditionals in it. > The ceph.spec file in Fedora is based on the upstream ceph.spec.in file; not on anything in/from openSUSE. The upstream ceph.spec.in file is full of Fedora and SUSE conditionals. If openSUSE also used the upstream spec file then it shouldn't surprise anyone that they are similar. -- Kaleb ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Mon, Mar 11, 2019 at 7:35 AM Daniel P. Berrangé wrote: > > On Fri, Mar 08, 2019 at 03:07:09PM -0500, Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to > > 14.x in f30/rawhide. > > > > I reset it to 1 in subsequent builds. Now adamwill is running builds with > > it bumped to 2 again. > > > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > > even I think) where they have epoch=2. I see this as a feature that lets > > someone install Ceph's epoch=2 packages on a system and not risk > > inadvertently updating with the Fedora Ceph packages. > > The ability to have multiple different builds of the same software which > users can choose between, sounds alot like the use case for modularity. > Abusing Epoch to try to address this kind of situation feels like a pretty > undesirable approach, as this problem with suddenly clashing Epochs will > illustrate. > > If ceph in Fedora were a module, is it possible for Ceph upstream to > provide an alternate module stream of ceph too ? If so, then users > could use the normal modules features in DNF for deciding which stream > to have active on their systems. > If there was a material difference between upstream and downstream, you might have a case for it. Today, there is not. Heck, the spec file that is in Fedora is basically an openSUSE spec with Fedora conditionals in it. It even has the (IMO dumb) license header thing that openSUSE forces for all of its package spec files. Not that it's necessarily a bad thing that the spec files are identical, but I'd rather just say we should not care, since there's no appreciable difference between the two. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, Mar 08, 2019 at 03:07:09PM -0500, Kaleb Keithley wrote: > The epoch was inadvertently bumped (not by me) when ceph was rebased to > 14.x in f30/rawhide. > > I reset it to 1 in subsequent builds. Now adamwill is running builds with > it bumped to 2 again. > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > even I think) where they have epoch=2. I see this as a feature that lets > someone install Ceph's epoch=2 packages on a system and not risk > inadvertently updating with the Fedora Ceph packages. The ability to have multiple different builds of the same software which users can choose between, sounds alot like the use case for modularity. Abusing Epoch to try to address this kind of situation feels like a pretty undesirable approach, as this problem with suddenly clashing Epochs will illustrate. If ceph in Fedora were a module, is it possible for Ceph upstream to provide an alternate module stream of ceph too ? If so, then users could use the normal modules features in DNF for deciding which stream to have active on their systems. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, 2019-03-08 at 15:07 -0500, Kaleb Keithley wrote: > The epoch was inadvertently bumped (not by me) when ceph was rebased to > 14.x in f30/rawhide. > > I reset it to 1 in subsequent builds. Now adamwill is running builds with > it bumped to 2 again. > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > even I think) where they have epoch=2. I see this as a feature that lets > someone install Ceph's epoch=2 packages on a system and not risk > inadvertently updating with the Fedora Ceph packages. > > Is there really no other way to get rid of the one or two "bad builds" > where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds > perhaps? I did send you an email about this to explain. The builds with epoch 2 made multiple Rawhide composes and the first Fedora 30 compose. This means anyone who installed 30 or Rawhide with ceph packages during those periods will never get ceph updated when they do 'dnf update', because they will have a package installed with epoch 2 and dnf will not see the package with epoch 1 as an update. Untagging the builds does not help anyone who got them installed while they were in Rawhide or Fedora 30 (in fact Fedora 30 still contains an epoch 2 build right now, so anyone installing it at present is getting epoch-2 ceph). We can talk about potentially allowing epoch down bumps at a distro upgrade boundary (though this rather hangs Rawhide users out to dry), but even if we were to start allowing that, since an epoch 2 build made it into a Fedora 30 compose, we can never bump the epoch down to 1 for Fedora 30's lifetime. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On 08. 03. 19 21:16, Neal Gompa wrote: On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote: The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x in f30/rawhide. I reset it to 1 in subsequent builds. Now adamwill is running builds with it bumped to 2 again. I would prefer that it not be bumped. Ceph has their own builds (for Fedora even I think) where they have epoch=2. I see this as a feature that lets someone install Ceph's epoch=2 packages on a system and not risk inadvertently updating with the Fedora Ceph packages. Is there really no other way to get rid of the one or two "bad builds" where epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? As of right now, no. Once it goes out in a compose, that's the way it goes... I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... Let's do a Fedora change? Coordinate with FPC? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: On not bumping the epoch in ceph-14, f30 and f31/rawhide
On Fri, Mar 8, 2019 at 3:08 PM Kaleb Keithley wrote: > > The epoch was inadvertently bumped (not by me) when ceph was rebased to 14.x > in f30/rawhide. > > I reset it to 1 in subsequent builds. Now adamwill is running builds with it > bumped to 2 again. > > I would prefer that it not be bumped. Ceph has their own builds (for Fedora > even I think) where they have epoch=2. I see this as a feature that lets > someone install Ceph's epoch=2 packages on a system and not risk > inadvertently updating with the Fedora Ceph packages. > > Is there really no other way to get rid of the one or two "bad builds" where > epoch=2 and keep shipping epoch=1 in Fedora? By untagging the builds perhaps? > As of right now, no. Once it goes out in a compose, that's the way it goes... I really wish we'd allow Epochs to be reset on distribution upgrades. With dnf distro-sync (which is used by system-upgrade) Epochs don't really matter and upgrades work as intended anyway... And EVR games like this are really annoying. :( -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
