[EPEL-devel] Re: [CentOS-devel] RHEL moving to issues.redhat.com only long term

[Brian Stinson]

On Fri, Mar 11, 2022, at 04:55, Florian Weimer wrote:
> * Josh Boyer:
>
>> 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.
>
> Thanks for posting this publicly.
>
>> - 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.
>
> There is already an “FC” project on issues.redhat.com, into which Fedora
> bugs can be mirrored from bugzilla.redhat.com.  Should we expose the
> mirror+ Bugzilla flag publicly, and make the FC project public, so that
> people can experiment with that?
>
>> 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.
>
> What is going to happen to the CentOS Mantis instance
> ?  From the looks of it, it probably should
> just be switched off?

Since we've moved CentOS Stream to bugzilla/jira I think it will make more and 
more sense to look at deduplicating the number of bug trackers we have. CentOS 
Linux 7 bugs are still nominally tracked in Mantis, though. 

We do not have active plans to retire bugs.centos.org yet. 

--Brian 

>
> Thanks,
> Florian
> ___
> devel mailing list -- de...@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/de...@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [EPEL-devel] [CentOS-devel] [Proposal] Converge EPEL and CBS

[Brian Stinson]

On Sep 21 20:58, Haïkel wrote:
> 2015-09-21 19:46 GMT+02:00 Kevin Fenzi :
> > On Mon, 21 Sep 2015 16:12:07 +0200
> > Haïkel  wrote:
> >
> >> Hi,
> >>
> >> Since the CentOS acquihire, there was a lot of discussion about
> >> EPEL's future. Since the FOSDEM meetup between Fedora/CentOS folks,
> >> there was little progress on that topic
> >>
> >> After a discussion with a Smooge, I decided to come with a proposal,
> >> knowing that
> >> 1. Fedora wants to keep EPEL within it umbrella
> >> 2. That CentOS SIGs are in practice rebuilding a lot of EPEL packages
> >> (or retag them for other SIGs)
> >> leading to poor maintenance as they don't follow EPEL tickets for all
> >> their dependencies.

+1000 this is definitely one of the more bumpy experiences of the SIG
process. 

> >
> > Which tickets do you mean here? They are only rebuilding some packages,
> > but not others or?
> >
> 
> Any tickets filed against EPEL, for instance, if a bug or CVE is fixed
> against EPEL package,  CBS rebuilds won't be impacted as there's no
> way to automate that.
> Some examples from CentOS Cloud SIG:
> * RabbitMQ: it's a runtime requirement for OpenStack, we could just
> reuse EPEL packages but that would mean that Cloud SIG repository
> wouldn't be self-contained
> => Nick Coghlan's RepoFunnel would be a solution to mash repositories here.
> * A hell lot of python build requirements, that have to be rebuilt in
> CBS, as CBS don't have access to EPEL packages.
> 
> For instance, if the EPEL package gets fixed for a CVE, the CBS
> package may not get fixed (and vice-versa).
> Moreover, it makes mixing EPEL and CentOS SIGs repositories harder.

I'd rather see this happen through automation. If we're maintaining a
"cbs-common" repo (as Fabian and others are speaking of down-thread), it
would be simple to work out the inclusion/exclusion policy and set
things going (I suppose that means I've volunteered myself to help with
the tools :). Something like cbs-common has the added benefit of
treating EPEL like an "upstream" in that developers are allowed to
consume the bits from EPEL while adding in packages from other places,
and where they're encouraged to contribute back. 

> 
> 
> >> 3. EPEL is not part CentOS plans, and as soon as SIGs will progress,
> >> *may* turn the former irrelevant
> >
> > I suppose, but lots of people use/look to epel for packages, I don't
> > think that will change to using packages from CentOS sigs overnight.
> >
> 
> I agree.
> 
> >> 4. Some EPEL packages are poorly maintained especially on older EL
> >> releases and/or orphaned
> >
> > Sure, just like any large collection of packages.
> >
> 
> Yes, but all the more a reason to make it easier for CentOS community
> to participate to this efforts

Participate yes, but EPEL is a packaging effort that, I think, belongs
in a community with a broad base of packagers (Fedora). There are
definitely things we can do from both sides to make collaboration more
seamless. 

...SNIP some technical questions...

> >> * Bridging Fedora/CentOS accounting system (CentOS is migrating to
> >> FAS)  <== we need to see the feasibility of this but that would be
> >> optimal, that would increase the permeability between our two
> >> contributors pools which is something, we all want to encourage.
> >
> > Bridging in which way? what information would be good to communicate
> > back and forth?
> >
> 
> I'm not familiar enough with the FAS/pkgdb architecture, so I will
> just list some requirements.
> * ensure that EPEL packagers could rebuild their packages in CBS

Automation through cbs-common would handle this case 

> * ensure that CentOS core SIG could administrate epel-provenpackager group

I think we should work up something in EPEL for this. We started an
"epel-wranglers" group in EPEL-land, I think the next step would be to
round up EPEL-provenpackagers some of whom would come from the CentOS
community.

> 
> Off course, it could be minimal and may not require syncing FAS
> instances, in the end.

Perhaps not syncing FAS instances, but we (CentOS) are hoping to make
progress on our auth systems in concert with Fedora and other
communities (See the freshly announced Community Auth Working Group). 

> 
> >> * Create a EPEL provenpackager group under CentOS core SIG
> >> supervision, allowing them to appoint people to maintain EPEL
> >> packages.
> >
> > Overriding the existing EPEL maintainers?
> >
> 
> Yes, as provenpackager could do with most Fedora packages but limited
> to EPEL branches.
> I know this may be difficult to give some control to another
> organization over part of our project. But we need to consider that
> Fedora/CentOS are part of a larger ecosystem.
> 
> 
> >> I suggest that we keep the EPEL name to acknowledge EPEL historical
> >> effort to provide quality additional packages for EL distros.
> >> Fedora contributors would still be able to contribute to EPEL, and
> >> CentOS contributors to make it up their 

[EPEL-devel] Call for Agenda Items: EPEL Meeting 01-May-2015 17:00 UTC

[Brian Stinson]

Hi All,

The EPEL Steering Committee will be meeting again at 17:00 UTC
01-May-2015 in #epel on freenode. Here is a draft agenda:

- Old Business:
  - Progress on Python3
  - New meeting day/time (I will be sending a poll out in a separate email to
EpSCO members today)
- New Business:
  - Ticket cleanup
  - Restart the EPIC Discussion?

If there are other discussion items we should consider, please reply here.

I hope to see you on Friday!
Brian


Brian Stinson
br...@bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Python3 vote

[Brian Stinson]

On Mar 19 16:57, Stephen John Smoogen wrote:
 At the last meeting I promised we would hold a vote on the Python 3 on the
 mailing lists. I got sidetracked after the meeting and never got to calling
 a vote on it. However in that time I haven't seen any complaints from the
 EPSCO members so would like to just have a +1/-1 vote by tomorrow on the
 proposed python3 item
 
 https://fedoraproject.org/w/index.php?title=User%3ABkabrda%2FEPEL7_Python3
 
 I am +1 on this.
 
 
 -- 
 Stephen J Smoogen.

+1 from me

Brian 

--
Brian Stinson
br...@bstinson.com | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

[EPEL-devel] EpSCO Meeting Agenda: 27-Feb-2015 17:00 UTC

[Brian Stinson]

Hi All,

We will be in #epel on Freenode for our weekly EPEL Steering
Committee meeting Friday 27-Feb-2015 at 17:00 UTC. 

Proposed Agenda items:

1.) Python 3.X Discussion 
- Dual stack support?
- Macros? 
- How can people help?

2.) Open Floor / Other Items

I hope to see you all there!

Brian

--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] How to formalize and finish the Py3 proposal?

[Brian Stinson]

On Feb 19 04:54, Bohuslav Kabrda wrote:
 Hi all,
 so I think everyone was able to express their opinions about my Python 3 
 proposal for EPEL [1] and I think it's time for me to formalize it, get it 
 approved and actually do it. I'm however unsure about how this works in EPEL 
 and I haven't been able to find a reference to a specific process.
 Can someone please advise (send a link/explain/...) on what is the best way 
 to formalize such proposal for EPEL and who to propose it to?
 
 Thanks a lot,
 Slavek
 
 [1] https://fedoraproject.org/wiki/User:Bkabrda/EPEL7_Python3

We agreed to move forward with the proposal at our last meeting[1]. I'm
thinking we should put this on the agenda again to talk about details
and see how we can help.

Cheers!
Brian

[1] http://meetbot.fedoraproject.org/epel/2015-02-13/epel.2015-02-13-17.00.html
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] [CentOS-devel] Meeting face to face CentOS Project and EPEL

[Brian Stinson]

On Jan 02 01:27, Karanbir Singh wrote:
 hi,
 
 crossposting this to centos-devel and epel-devel
 
 we are working to arrange a meeting with the EPEL folks at Fosdem 2015,
 on 31st Jan at 7pm ( venue to be confirmed ), to try and workout some
 options on how the two efforts might best co-ordinate.
 
 A key part of the conversation would also focus on how SIGs and other
 contributors to downstream repos in centos.org can interface with and
 set expectations on the epel repos.
 
 Everyone able to make it please let me know your names so I can track
 attendance and make reservations accordingly.
 
 Regards,
 
 -- 
 Karanbir Singh, Project Lead, The CentOS Project
 +44-207-0999389 | http://www.centos.org/ | twitter.com/CentOS
 GnuPG Key : http://www.karan.org/publickey.asc
 ___
 CentOS-devel mailing list
 centos-de...@centos.org
 http://lists.centos.org/mailman/listinfo/centos-devel

Count me in.

Brian

--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: [EPEL-devel] Looking to move Friday EPEL meeting.

[Brian Stinson]

On Oct 28 09:58, Stephen John Smoogen wrote:
 I have had a conflict come up for the Friday meeting at 1600 UTC.  Would it
 be possible to move the meeting to 1700 or 1800 UTC?
 
 -- 
 Stephen J Smoogen.

Either time works fine for me.

Brian

--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: EPEL Notes from .next discussion.

[Brian Stinson]

On Aug 13 01:25, Stephen John Smoogen wrote:
 I think that would be something with softwarecollections.org as that seems
 in line with their way of packaging items.  I think that for some sorts of
 packages and libraries it makes sense for that, but I don't know if EPEL
 would mix and match like that. What I would like to do is the following:
 
 We move from our moving distribution to a point release cycle with a disk
 layout like the following:
 
 epel
 epel/development/
 epel/development/5
 epel/development/6
 epel/development/7
 epel/beta/5.12
 epel/beta/6.7
 epel/beta/7.1
 epel/releases
 epel/releases/6.6
 epel/releases/5.11
 epel/releases/7.0
 epel/updates
 epel/updates/6.6
 epel/updates/5.11
 epel/updates/7.0
 epel/updates/testing/
 epel/updates/testing/6.6
 epel/updates/testing/5.11
 epel/updates/testing/7.0
 
 epel/development would be like the current EPEL directories but without the
 stringent requirements that packages are locked to a specific version for
 the lifetime of the overall RHEL release. Instead whenever RHEL releases a
 new dot release (7.0, 6.6, 5.11), EPEL would branch off the releases from
 development to beta/7.0 or beta/6.6 etc. Packages would be built against
 the point release and would need to be tested to get sufficient karma for
 'release'. Once 6 weeks have passed from the RHEL point release, all
 packages which had gotten enough karma and that had completed repository
 trees would be put into epel/releases/6.6. Updates to that package would be
 put into updates/testing/6.6 and then promoted to updates/6.6 when enough
 karma had been given for an update. New packages which were added after the
 point release would show up in updates following the process Fedora does
 for new packages between point releases.
 
 Later when 7.1, 6.7, 5.12 (or whatever they are called) comes out then the
 process is repeated which will make sure that packages that aren't needed
 enough to have sponsors will not be in EPEL and potentially broken and
 large updates are possible so if python34 is in 7.0 but python35 is ready
 for 7.2 it can replace it without problems (or similarly with ruby23 etc
 etc). Once the next point release is made ready, the old point release will
 be archived off to keep storage levels within reason.
 
 I know that this proposal needs a lot more fleshing out, but I think it
 covers the use cases many users of EPEL need for long term usage of
 packages.
 
 
 -- 
 Stephen J Smoogen.

Were there plans made (at flock or elsewhere) for regular EPEL-related 
meetings? I would like
to chip in and help where I can. I think this proposal strikes a happy medium
between stability (within a point-release) and updated features. 

--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel