On Thu, May 19, 2022 at 07:37:46AM +0200, Branislav Náter wrote:
> Hi,
>
> On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee <lee.iitb(a)gmail.com>
> wrote:
>
> > Hi,
> >
> > I am trying to request a package for RHEL 9, but I cannot find RHEL
> > under Projects at issues.redhat.com.
> > What is the correct project for RHEL 9 ?
> >
>
> You have to file a bug for "distribution" component in Bugzilla.
Please don't file it there. :)
Take a look at the handy doc:
https://docs.fedoraproject.org/en-US/epel/epel-package-request/
If anything is unclear there, please do let us know.
While RHEL may be moving to jira with RHEL10, EPEL is very likely to
stay with whatever Fedora is using (currently bugzilla).
kevin
Hi,
I filed on Bugzilla.
I wondered why there is no such option on issues.redhat.com (Jira ?).
Thanks
---
Lee
On Thu, May 19, 2022 at 11:08 AM Branislav Náter <bnater(a)redhat.com> wrote:
>
> Hi,
>
> On Thu, May 19, 2022 at 4:15 AM Thomas Stephen Lee <lee.iitb(a)gmail.com> wrote:
>>
>> Hi,
>>
>> I am trying to request a package for RHEL 9, but I cannot find RHEL
>> under Projects at issues.redhat.com.
>> What is the correct project for RHEL 9 ?
>
>
> You have to file a bug for "distribution" component in Bugzilla.
>
> Regards
> B.
>
>>
>>
>> Thanks
>>
>> ---
>> Lee
>>
>>
>> On Mon, Mar 7, 2022 at 11:14 PM Josh Boyer <jwboyer(a)redhat.com> wrote:
>> >
>> > Hi Fedora, CentOS, and EPEL Communities!
>> >
>> > As part of our continued 3 year major Red Hat Enterprise Linux release
>> > cadence, RHEL 9 development is starting to wrap up with the spring
>> > 2022 release coming soon. That means planning for the next release
>> > will start in earnest in the very near future. As some of you may
>> > know, Red Hat has been using both Bugzilla and Jira via
>> > issues.redhat.com for RHEL development for several years. Our
>> > intention is to move to using issues.redhat.com only for the major
>> > RHEL releases after RHEL 9.
>> >
>> > What does this mean for Fedora and CentOS? This discussion is in part
>> > to figure that out. Based on some very brief analysis, the following
>> > should hold:
>> >
>> > - RHEL customers should continue to file support cases through the Red
>> > Hat Customer portal, which will remain consistent regardless of the
>> > backend tooling used.
>> >
>> > - There is no imminent retirement of the Red Hat Bugzilla instance
>> > being planned at this time. RHEL 7, 8, and 9 will continue to use
>> > bugzilla in some form and RHEL 9 has a very long lifecycle.
>> >
>> > - Fedora Linux and EPEL have their own Bugzilla product families and
>> > are not directly impacted in their own workflows by the choice to use
>> > only issues.redhat.com for RHEL.
>> > - There will be impacts on existing documentation that provide
>> > guidance on requesting things from RHEL in various places like EPEL.
>> > We will be happy to help adjust these.
>> >
>> > - CentOS Stream contribution and bug reporting workflows will be
>> > adjusted to use issues.redhat.com instead of bugzilla in the relevant
>> > places. This should apply to all versions of CentOS Stream for a
>> > unified contributor workflow. This will happen gradually as we
>> > discover the best workflow to use.
>> >
>> > If there are other impacts that you can think of, please raise them on
>> > this thread. We’d like to ensure we’re covering as much as possible
>> > as this rolls out.
>> >
>> > josh
>> > _______________________________________________
>> > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>> > To unsubscribe send an email to epel-devel-leave(a)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.fedoraprojec…
>> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
>> _______________________________________________
>> CentOS-devel mailing list
>> CentOS-devel(a)centos.org
>> https://lists.centos.org/mailman/listinfo/centos-devel
>
>
>
> --
> Branislav Náter
> Principal Quality Engineer, Stacks QE
> IRC: bnater at #qa #urt #brno
> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel(a)centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
Hi Fedora, CentOS, and EPEL Communities!
As part of our continued 3 year major Red Hat Enterprise Linux release
cadence, RHEL 9 development is starting to wrap up with the spring
2022 release coming soon. That means planning for the next release
will start in earnest in the very near future. As some of you may
know, Red Hat has been using both Bugzilla and Jira via
issues.redhat.com for RHEL development for several years. Our
intention is to move to using issues.redhat.com only for the major
RHEL releases after RHEL 9.
What does this mean for Fedora and CentOS? This discussion is in part
to figure that out. Based on some very brief analysis, the following
should hold:
- RHEL customers should continue to file support cases through the Red
Hat Customer portal, which will remain consistent regardless of the
backend tooling used.
- There is no imminent retirement of the Red Hat Bugzilla instance
being planned at this time. RHEL 7, 8, and 9 will continue to use
bugzilla in some form and RHEL 9 has a very long lifecycle.
- Fedora Linux and EPEL have their own Bugzilla product families and
are not directly impacted in their own workflows by the choice to use
only issues.redhat.com for RHEL.
- There will be impacts on existing documentation that provide
guidance on requesting things from RHEL in various places like EPEL.
We will be happy to help adjust these.
- CentOS Stream contribution and bug reporting workflows will be
adjusted to use issues.redhat.com instead of bugzilla in the relevant
places. This should apply to all versions of CentOS Stream for a
unified contributor workflow. This will happen gradually as we
discover the best workflow to use.
If there are other impacts that you can think of, please raise them on
this thread. We’d like to ensure we’re covering as much as possible
as this rolls out.
josh
May 16, 2022 8:32:58 PM Maxwell G <gotmax(a)e.email>:
On Tuesday, April 19, 2022 3:14:56 PM CDT Kevin Fenzi wrote:
> In epel8 I will be converting the 'ansible' epel8 package into the
> upstream ansible-5 meta collections package (which also pulls in
> ansible-core).
>
Hi everyone,
I have rebased ansible to ansible 5 in epel8 and submitted a Bodhi update[1].
I would appreciate if you could help test the update and provide feedback. We
are also providing a newer version of ansible 5 in epel8-next that depends on
the newer version of ansible-core available in CentOS 8 Stream. Here[2] is the
Bodhi update for the epel8-next version.
[1]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-67f52f0700
[2]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-7083a5c511
I also branched ansible for epel9 and epel9-next. Here[3,4] are the Bodhi
updates for that.
[4]:https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-73e215eb5c
[5]: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-3090b856c2
Remember that ansible 5 is just a bundle of ansible collections that are
released together, and it depends on ansible-core (the engine) which provides
the core modules, engine, and command line tools. This provides the
"batteries-included" approach that users of ansible classic (ansible 2.9.x and
below) are used to. If you prefer a more minimalist approach, you can install
ansible-core alongside the specific collections you need. You can install
collections through EPEL's ansible-collection-* RPM packages or from Ansible
Galaxy. If you would like to do this, you can switch to ansible-core with `dnf
swap ansible ansible-core`.
--
Thanks,
Maxwell G (@gotmax23)
Pronouns: He/Him/His