Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)
FYI https://fedoraproject.org/wiki/Changes/libmemcached-awesome libmemcached 1.0.18 have been retired from Rawhide libmemcached-awesome 1.1.0 is now available Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)
Le 06/07/2021 à 20:28, David Cantrell a écrit : On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote: On Tue, Jul 6, 2021 at 12:29 PM David Cantrell wrote: On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote: >https://fedoraproject.org/wiki/Changes/libmemcached-awesome > >== Summary == >Switch from libmemcached to libmemcached-awesome > >== Owner == >* Name: [[User:Remi| Remi Collet]] >* Email: remi at fedoraproject dot org > >== Detailed Description == > >libmemcache 1.0.18 was released in February 2014, so hasn't received >an update for 7 years. > >libmemcache-awesome is a fork providing same libraries, tools with >API/ABI compatibility. > >== Benefit to Fedora == > >Rely on a maintained project. > > > >== Scope == >* Proposal owners: Check Koschei status. Test with latest version to >ensure compatibility. Work with upstream on bug fixing. Needed mass >rebuild (C extensions) done by change owner. > >* Other developers: N/A (not a System Wide Change) >* Release engineering: >* Policies and guidelines: N/A (not a System Wide Change) >* Trademark approval: N/A (not needed for this Change) > > >== Upgrade/compatibility impact == >N/A (not a System Wide Change) > >== How To Test == > >* install and play with your application > >== User Experience == > >Developers and system administrators will have the great benefit or >running a maintained library. > > >== Dependencies == > >All php-* packages (and some *-php) > >== Contingency Plan == >* Contingency mechanism: Drop not compatible packages. >* Contingency deadline: N/A (not a System Wide Change) >* Blocks release? N/A (not a System Wide Change) > >== Documentation == > >* [https://awesomized.github.io/libmemcached/ Upstream documentation] > The change proposal indicates this is a drop-in API replacement project, but will this introduce a new package named 'libmemcached-awesome' and we let libmemcached go out to pasture? Or is this changing the Source0 of the libmemcached package to just use this new upstream? If the former, will the new package provide proper Provides/Conflicts against the existing libmemcached package or are there plans to allow both to be installed at the same time? From what I can tell, you can't have both installed in parallel, so I think I'd prefer to see the Source0 in libmemcached change to the fork rather than introducing a new source package and complicating things. That's more or less the direction I was going with this thought. If we are fairly confident libmemcached is dead upstream, then I see no reason to just replace Source0 with the active project. On the other hand, we have seen projects come back from what appears to be a dead upstream and then you have a name conflict and/or confusion. Also we do have naming policy for Fedora packages that at least encourages the package name to match the upstream project name in cases where that will work. I don't know the state of libmemcached and whether or not it will come back to life (or if it's even dead upstream). With that in mind, I would prefer to see: * Addition of libmemcached-awesome as a new package * libmemcached-awesome Provides libmemcached * libmemcached-awesome Obsoletes libmemcached * Orphan libmemcached That the plan (new package named, as the project, libmemcached-awesome) FYI, the rename was an explicit requirement of the old project author. Additionally, if any packages carry a Requires or dynamic dependency on libmemcached, those should be updated to libmemcached-awesome. The lazy way would be to add Epoch: 1 to libmemcached-awesome and let libmemcached fade away. libmemcached will be retired, everything provided by "libmemcached" is now provided byt the new one Remi ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)
On Tue, Jul 06, 2021 at 12:51:59PM -0400, Neal Gompa wrote: On Tue, Jul 6, 2021 at 12:29 PM David Cantrell wrote: On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote: >https://fedoraproject.org/wiki/Changes/libmemcached-awesome > >== Summary == >Switch from libmemcached to libmemcached-awesome > >== Owner == >* Name: [[User:Remi| Remi Collet]] >* Email: remi at fedoraproject dot org > >== Detailed Description == > >libmemcache 1.0.18 was released in February 2014, so hasn't received >an update for 7 years. > >libmemcache-awesome is a fork providing same libraries, tools with >API/ABI compatibility. > >== Benefit to Fedora == > >Rely on a maintained project. > > > >== Scope == >* Proposal owners: Check Koschei status. Test with latest version to >ensure compatibility. Work with upstream on bug fixing. Needed mass >rebuild (C extensions) done by change owner. > >* Other developers: N/A (not a System Wide Change) >* Release engineering: >* Policies and guidelines: N/A (not a System Wide Change) >* Trademark approval: N/A (not needed for this Change) > > >== Upgrade/compatibility impact == >N/A (not a System Wide Change) > >== How To Test == > >* install and play with your application > >== User Experience == > >Developers and system administrators will have the great benefit or >running a maintained library. > > >== Dependencies == > >All php-* packages (and some *-php) > >== Contingency Plan == >* Contingency mechanism: Drop not compatible packages. >* Contingency deadline: N/A (not a System Wide Change) >* Blocks release? N/A (not a System Wide Change) > >== Documentation == > >* [https://awesomized.github.io/libmemcached/ Upstream documentation] > The change proposal indicates this is a drop-in API replacement project, but will this introduce a new package named 'libmemcached-awesome' and we let libmemcached go out to pasture? Or is this changing the Source0 of the libmemcached package to just use this new upstream? If the former, will the new package provide proper Provides/Conflicts against the existing libmemcached package or are there plans to allow both to be installed at the same time? From what I can tell, you can't have both installed in parallel, so I think I'd prefer to see the Source0 in libmemcached change to the fork rather than introducing a new source package and complicating things. That's more or less the direction I was going with this thought. If we are fairly confident libmemcached is dead upstream, then I see no reason to just replace Source0 with the active project. On the other hand, we have seen projects come back from what appears to be a dead upstream and then you have a name conflict and/or confusion. Also we do have naming policy for Fedora packages that at least encourages the package name to match the upstream project name in cases where that will work. I don't know the state of libmemcached and whether or not it will come back to life (or if it's even dead upstream). With that in mind, I would prefer to see: * Addition of libmemcached-awesome as a new package * libmemcached-awesome Provides libmemcached * libmemcached-awesome Obsoletes libmemcached * Orphan libmemcached Additionally, if any packages carry a Requires or dynamic dependency on libmemcached, those should be updated to libmemcached-awesome. The lazy way would be to add Epoch: 1 to libmemcached-awesome and let libmemcached fade away. None of the above is mentioned in the change proposal and since the change is about the mechanics of how to do this, I'd like to see it explained out. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)
On Tue, Jul 6, 2021 at 12:29 PM David Cantrell wrote: > > On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote: > >https://fedoraproject.org/wiki/Changes/libmemcached-awesome > > > >== Summary == > >Switch from libmemcached to libmemcached-awesome > > > >== Owner == > >* Name: [[User:Remi| Remi Collet]] > >* Email: remi at fedoraproject dot org > > > >== Detailed Description == > > > >libmemcache 1.0.18 was released in February 2014, so hasn't received > >an update for 7 years. > > > >libmemcache-awesome is a fork providing same libraries, tools with > >API/ABI compatibility. > > > >== Benefit to Fedora == > > > >Rely on a maintained project. > > > > > > > >== Scope == > >* Proposal owners: Check Koschei status. Test with latest version to > >ensure compatibility. Work with upstream on bug fixing. Needed mass > >rebuild (C extensions) done by change owner. > > > >* Other developers: N/A (not a System Wide Change) > >* Release engineering: > >* Policies and guidelines: N/A (not a System Wide Change) > >* Trademark approval: N/A (not needed for this Change) > > > > > >== Upgrade/compatibility impact == > >N/A (not a System Wide Change) > > > >== How To Test == > > > >* install and play with your application > > > >== User Experience == > > > >Developers and system administrators will have the great benefit or > >running a maintained library. > > > > > >== Dependencies == > > > >All php-* packages (and some *-php) > > > >== Contingency Plan == > >* Contingency mechanism: Drop not compatible packages. > >* Contingency deadline: N/A (not a System Wide Change) > >* Blocks release? N/A (not a System Wide Change) > > > >== Documentation == > > > >* [https://awesomized.github.io/libmemcached/ Upstream documentation] > > > > The change proposal indicates this is a drop-in API replacement > project, but will this introduce a new package named > 'libmemcached-awesome' and we let libmemcached go out to pasture? Or > is this changing the Source0 of the libmemcached package to just use > this new upstream? > > If the former, will the new package provide proper Provides/Conflicts > against the existing libmemcached package or are there plans to allow > both to be installed at the same time? From what I can tell, you can't have both installed in parallel, so I think I'd prefer to see the Source0 in libmemcached change to the fork rather than introducing a new source package and complicating things. -- 真実はいつも一つ！/ 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://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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: libmemcached-awesome (Self-Contained Change proposal)
On Thu, Jun 24, 2021 at 11:50:18AM -0400, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/libmemcached-awesome == Summary == Switch from libmemcached to libmemcached-awesome == Owner == * Name: [[User:Remi| Remi Collet]] * Email: remi at fedoraproject dot org == Detailed Description == libmemcache 1.0.18 was released in February 2014, so hasn't received an update for 7 years. libmemcache-awesome is a fork providing same libraries, tools with API/ABI compatibility. == Benefit to Fedora == Rely on a maintained project. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * install and play with your application == User Experience == Developers and system administrators will have the great benefit or running a maintained library. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * [https://awesomized.github.io/libmemcached/ Upstream documentation] The change proposal indicates this is a drop-in API replacement project, but will this introduce a new package named 'libmemcached-awesome' and we let libmemcached go out to pasture? Or is this changing the Source0 of the libmemcached package to just use this new upstream? If the former, will the new package provide proper Provides/Conflicts against the existing libmemcached package or are there plans to allow both to be installed at the same time? Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: libmemcached-awesome (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/libmemcached-awesome == Summary == Switch from libmemcached to libmemcached-awesome == Owner == * Name: [[User:Remi| Remi Collet]] * Email: remi at fedoraproject dot org == Detailed Description == libmemcache 1.0.18 was released in February 2014, so hasn't received an update for 7 years. libmemcache-awesome is a fork providing same libraries, tools with API/ABI compatibility. == Benefit to Fedora == Rely on a maintained project. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * install and play with your application == User Experience == Developers and system administrators will have the great benefit or running a maintained library. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * [https://awesomized.github.io/libmemcached/ Upstream documentation] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org 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-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: libmemcached-awesome (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/libmemcached-awesome == Summary == Switch from libmemcached to libmemcached-awesome == Owner == * Name: [[User:Remi| Remi Collet]] * Email: remi at fedoraproject dot org == Detailed Description == libmemcache 1.0.18 was released in February 2014, so hasn't received an update for 7 years. libmemcache-awesome is a fork providing same libraries, tools with API/ABI compatibility. == Benefit to Fedora == Rely on a maintained project. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: N/A (not a System Wide Change) * Release engineering: * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == * install and play with your application == User Experience == Developers and system administrators will have the great benefit or running a maintained library. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * [https://awesomized.github.io/libmemcached/ Upstream documentation] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
