[EPEL-devel] Re: Continuing playground discussion
On Wed, 2020-09-02 at 14:07 -0700, Kevin Fenzi wrote: > > I think playground might be fixable/made of use without too much > work... > * adjust fedpkg to stop requesting playground branches always/only > request them on explicit ask > * change the inheritence in koji so it inherits from epel8 > * untag all the things that are "older" in playground > * add more docs about what it is and how it works > * perhaps make it send a daily report for each compose > Whether we keep playground (but make playground inherit from epel) or drop it entirely -- that means package.cfg is not going to be needed either way, right? The only one scenario I can think of where package.cfg is useful is if someone wants their package automatically rebuilt for epel-next. But maybe that should be done automatically the same way ELN rebuilds Rawhide without the individual packager having to worry about it. So... masas-retire package.cfg, perhaps? -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Continuing playground discussion
On Mon, Aug 31, 2020 at 08:05:14AM -0700, Troy Dawson wrote: > On Mon, Aug 31, 2020 at 7:08 AM Stephen John Smoogen wrote: > > > > > > > > On Mon, 31 Aug 2020 at 09:43, Troy Dawson wrote: > >> > >> On Sun, Aug 30, 2020 at 11:44 AM kevin wrote: > >> > > >> > >> > > Thoughts? > >> > > >> > Well, I think it satisfies all the use cases, but... we barely have > >> > enough cycles to try and revamp playground. Do we think we have enough > >> > to do that and also make a new -next version? > >> > > >> > >> Very good question. > >> Without being a superhero, do you and/or Smooge think we have the > >> resources to do this? > >> It's sounding like the answer is no. > >> > > > > Honestly, I don't see us having the resources to keep the playground > > around. Kevin's doubts a long time ago about playground stretching > > resources too far were correct. The build system is highly complex and just > > doing plain EPEL is a strain on the Fedora volunteers. Adding the > > playground was an experiment and I would lean towards ending it. > > > > > > Sounds like you would like C) > > C) Drop playground. Say it was an interesting experiment and we > learned stuff, but shut it down. > (and clean up the package.cfg files as part of shutting it down) > > You, Kevin, and Mohan have been doing all the work. And anything we > decide, you all will end up doing all that work as well. So I think > totally fair that you get a huge say in what happens. > But if we do decide to drop playground, I don't want it to sound like > it's because of you. > > The facts are that EPEL has been given very limited resources, barely > enough to keep normal EPEL operations running. > Adding epel-playground on top, has over-taxed our limited resources. > If epel-playground didn't require any extra upkeep, it might be ok. > And if we find a solution that doesn't require any extra upkeep, maybe > we can keep playground. > But adding anything else, like -next, is over the top. At a minimum > it will require extra resources every couple years to setup and take > down stuff. Those are resources we don't have. I think playground might be fixable/made of use without too much work... * adjust fedpkg to stop requesting playground branches always/only request them on explicit ask * change the inheritence in koji so it inherits from epel8 * untag all the things that are "older" in playground * add more docs about what it is and how it works * perhaps make it send a daily report for each compose I suppose though that if we get those things in place, adding a epel8-stream shouldn't be much work over that (aside mirroring stream repos and adding them to koji). I wish we could get some idea of the usage of things to know where best to send our limited efforts. Are people using playground? Would they use it more if it was smaller/just big changes packages? Are there enough stream users to justify a epel repo built against it? Would it be popular if there were? I'm open on how to answer these questions, or I suppose we just guess as best we can. We could also decide to do something if we get the resources. ie, don't set a time when something is done, say it depends on free time of interested parties. I suppose all that didn't help too much did it? kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 749 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 489 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-bc0182548b bubblewrap-0.3.3-2.el7 198 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fa8a2e97c6 python-waitress-1.4.3-1.el7 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-89ad58d02c golang-1.15-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing python-apprise-0.8.8-1.el7 Details about builds: python-apprise-0.8.8-1.el7 (FEDORA-EPEL-2020-a2fff43b31) A simple wrapper to many popular notification services used today Update Information: Updated to v0.8.8 ChangeLog: * Wed Sep 2 2020 Chris Caron - 0.8.8-1 - Updated to v0.8.8 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 21 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-c2936180ed ansible-2.9.12-1.el8 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-96c4037065 ark-19.12.2-3.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing nextcloud-client-2.6.5-9.el8 perl-POE-Loop-Event-1.305-15.el8 python-apprise-0.8.8-1.el8 python-chirpstack-api-3.7.7-1.el8 python-cmarkgfm-0.4.2-2.el8 python-pynetbox-5.0.8-1.el8 Details about builds: nextcloud-client-2.6.5-9.el8 (FEDORA-EPEL-2020-12ac6b643e) The Nextcloud Client Update Information: First EPEL 8 release First EPEL 8 release ChangeLog: References: [ 1 ] Bug #1792987 - add nextcloud-client package to epel 8 https://bugzilla.redhat.com/show_bug.cgi?id=1792987 [ 2 ] Bug #1866060 - Improve new cmake macros in order to cover also EPEL 7 and 8 https://bugzilla.redhat.com/show_bug.cgi?id=1866060 perl-POE-Loop-Event-1.305-15.el8 (FEDORA-EPEL-2020-077c06b9b7) Bridge that allows POE to be driven by Event.pm Update Information: perl-POE-Loop-Event: rebuild for epel8 ChangeLog: python-apprise-0.8.8-1.el8 (FEDORA-EPEL-2020-52f7642d04) A simple wrapper to many popular notification services used today Update Information: Updated to v0.8.8 ChangeLog: * Wed Sep 2 2020 Chris Caron - 0.8.8-1 - Updated to v0.8.8 python-chirpstack-api-3.7.7-1.el8 (FEDORA-EPEL-2020-69d1a1166a) Chirpstack Python API Update Information: Initial package for Fedora ChangeLog: python-cmarkgfm-0.4.2-2.el8 (FEDORA-EPEL-2020-6bd49d3573) Minimal bindings to GitHub's fork of cmark Update Information: Run tests (rhbz#1827045) ChangeLog: References: [ 1 ] Bug #1827045 - Review Request: python-cmarkgfm - Minimal bindings to GitHub's fork of cmark https://bugzilla.redhat.com/show_bug.cgi?id=1827045 python-pynetbox-5.0.8-1.el8 (FEDORA-EPEL-2020-1d68e119fd) Python API client library for Netbox Update Information: Update to 5.0.8 ChangeLog: * Wed Sep 2 2020 Igor Raits - 5.0.8-1 - Update to 5.0.8 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
