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

2022-03-11 Thread 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: [CentOS-devel] RHEL moving to issues.redhat.com only long term

2022-03-11 Thread 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 -- 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
___
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: Upstream tip wanted: CI service for Big Endian acrhes

2018-11-12 Thread Brian Stinson 
On Nov 12 13:32, Miro Hrončok wrote:
> Recently I've reported some Big Endian related test failures to an upstream
> project [0].
> 
> I was asked by an upstream project maintainer, whether I know some free
> Continuous Integration services where they can easily run their testsuite on
> Big Endian.
> 
> Any tips?
> 
>  * Upstream uses Travis CI to test on x86_64 Linux (Ubuntu)
>  * Upstream uses AppVeyor to test on Microsoft Windows
>  * It's a pure Python project, noarch, but some changes need to be done when
> loading/saving binary data (LE) with NumPy on BE system.
> 
> What I've considered:
> 
>  * COPR (but there is no big endian arch)
>  * (Ab)using Koji (I guess that would be considered a bad practice?)
>  * using QUEMU on Travis CI [1]
> 
> Any better tips? Thanks
> 
> [0] https://github.com/mikedh/trimesh/issues/249
> [1] 
> https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture-ci-workflow/
> 
> -- 
> 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

This may not be helpful if you need to target S390x specifically, but we
have PPC Big-endian CentOS VMs for projects in CentOS CI:

https://wiki.centos.org/QaWiki/CI/Multiarch

I'm happy to chat with you and your upstream about providing some
resources here.

--
Brian Stinson
CentOS CI Infrastructure Team 
___
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

Migrating jenkins.fedorainfracloud.org to jenkins-fedora-infra.apps.ci.centos.org

2018-04-12 Thread Brian Stinson 
Good Morning Everyone,

The Fedora Infrastructure has been running a jenkins instance in its
cloud for their own needs. That instance gained some tractions in our
community to the point that some projects are relying on it.
Unfortunately, our best-effort isn't sufficient to keep this instance in
a state that makes it useful for all of its users.

The CentOS infrastructure has offered to take over this instance and its
maintenance, they have much more expertise than us with jenkins and are
already maintaining multiple instances for other needs (including the
different CI pipelines now running for Fedora).

We want to do this migration in two steps:

1/ migrate all projects from fedorainfracloud.org to ci.centos.org in
such a way that there will be no work needed from any of the projects
currently using fedorainfracloud (except maybe changing the URLs we do
not have access to)

2/ work with the different projects on a case by case basis to
help them migrate to the setup that is used more commonly in
ci.centos.org with dynamic provisioning of the builder giving the
projects full access to them (ie: you will be able to install
directly all your dependencies on the builder without having to
request the infra team for it)

We are now ready for step (1): move over the fedorainfracloud instance
to ci.centos.org.

All projects set up in fedorainfracloud have been ported to
ci.centos.org which has been set up to mirror the instance Fedora was
running. So you will find there the same plugin, set up in the same way
as in Fedora.  Similarly, you will be able to log in the centos instance
using your Fedora credentials. Historical job logs were not migrated to
the new instance, please open a ticket if previous logs are needed.

We have setup redirects to the ci.centos.org instance.  We have adjusted
the URLs pointing to fedorainfracloud in pagure. You may want to update
the URLs we do not have access to and double-check that everything is
running as expected for your projects.

In case you have any problems, you can reach us on #fedora-admin on IRC
or by opening a ticket at https://pagure.io/fedora-infrastructure/

If you'd like to get started on step (2) on your own, the first step is
to request a project:
https://wiki.centos.org/SIGGuide/SIGProcess/AccountsCI 

The CentOS CI team will walk you through the rest of the process from
there.

Thanks for your attention and happy testing!

Brian & Pierre
- For the CentOS and Fedora Infrastructure Teams
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Migrating jenkins.fedorainfracloud.org to jenkins-fedora-infra.apps.ci.centos.org

2018-04-12 Thread Brian Stinson 
Good Morning Everyone,

The Fedora Infrastructure has been running a jenkins instance in its
cloud for their own needs. That instance gained some tractions in our
community to the point that some projects are relying on it.
Unfortunately, our best-effort isn't sufficient to keep this instance in
a state that makes it useful for all of its users.

The CentOS infrastructure has offered to take over this instance and its
maintenance, they have much more expertise than us with jenkins and are
already maintaining multiple instances for other needs (including the
different CI pipelines now running for Fedora).

We want to do this migration in two steps:

1/ migrate all projects from fedorainfracloud.org to ci.centos.org in
such a way that there will be no work needed from any of the projects
currently using fedorainfracloud (except maybe changing the URLs we do
not have access to)

2/ work with the different projects on a case by case basis to
help them migrate to the setup that is used more commonly in
ci.centos.org with dynamic provisioning of the builder giving the
projects full access to them (ie: you will be able to install
directly all your dependencies on the builder without having to
request the infra team for it)

We are now ready for step (1): move over the fedorainfracloud instance
to ci.centos.org.

All projects set up in fedorainfracloud have been ported to
ci.centos.org which has been set up to mirror the instance Fedora was
running. So you will find there the same plugin, set up in the same way
as in Fedora.  Similarly, you will be able to log in the centos instance
using your Fedora credentials. Historical job logs were not migrated to
the new instance, please open a ticket if previous logs are needed.

We have setup redirects to the ci.centos.org instance.  We have adjusted
the URLs pointing to fedorainfracloud in pagure. You may want to update
the URLs we do not have access to and double-check that everything is
running as expected for your projects.

In case you have any problems, you can reach us on #fedora-admin on IRC
or by opening a ticket at https://pagure.io/fedora-infrastructure/

If you'd like to get started on step (2) on your own, the first step is
to request a project:
https://wiki.centos.org/SIGGuide/SIGProcess/AccountsCI 

The CentOS CI team will walk you through the rest of the process from
there.

Thanks for your attention and happy testing!

Brian & Pierre
- For the CentOS and Fedora Infrastructure Teams
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: Intent to retire jenkins.fedorainfracloud.org

2018-01-09 Thread Brian Stinson 
On Jan 09 14:41, Pierre-Yves Chibon wrote:
> On Tue, Jan 09, 2018 at 02:29:38PM +0100, Dan Horák wrote:
> > On Tue, 9 Jan 2018 11:03:28 +0100
> > Pierre-Yves Chibon  wrote:
> > 
> > > Dear all,
> > > 
> > > The Fedora Infrastructure team has had a jenkins instance running at
> > > jenkins.fedorainfracloud.org for a little while now. This instance was
> > > maintained on a best-effort basis though and we often had outage and
> > > issues when upgrading it.
> > > Originally the jenkins master was running on RHEL using the RPMs
> > > provided by upstream jenkins. When jenkins became available in
> > > Fedora, we switched our master to be Fedora using the RPMs from
> > > Fedora. However, nowadays Jenkins is no longer packaged for Fedora,
> > > our jenkins master is therefore outdated.
> > > 
> > > On the other side of the fence, with our dear friends from CentOS, is
> > > a brand new, shiny and well supported Jenkins instance.
> > > So we thought it may be good to leverage the CentOS infrastructure to
> > > alleviate our infrastructure and maintenance.
> > > 
> > > We are currently working on setting up a Jenkins master in
> > > ci.centos.org that would be dedicated to projects ran in pagure.io.
> > > It needs a small change to pagure.io and some work on the CentOS side
> > > but nothing hard and we expect to be able to migrate the first
> > > volunteer projects by early next week.
> > 
> > do you plan to use the dynamically provisioned workers like the
> > current CentOS CI or will it use the static workers like the Fedora
> > Jenkins?
> 
> My understanding is to start with static workers as we have now in Fedora to
> ease the migration (no config change needed) and work from there to migrate to
> dynamically provisioned workers as the rest of CentOS CI does.
> 
> 
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

That's correct, we'll do static agents that match existing Jenkins
labels (EL6, EL7, F25, F25-ppc64le, and F26). 

Longer term, we'll work 1:1 with job owners to migrate to dynamic
provisioning.

--Brian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Intent to retire jenkins.fedorainfracloud.org

2018-01-09 Thread Brian Stinson 
On Jan 09 09:25, Adam Williamson wrote:
> On Tue, 2018-01-09 at 11:03 +0100, Pierre-Yves Chibon wrote:
> > Dear all,
> > 
> > The Fedora Infrastructure team has had a jenkins instance running at
> > jenkins.fedorainfracloud.org for a little while now. This instance was
> > maintained on a best-effort basis though and we often had outage and issues 
> > when
> > upgrading it.
> > Originally the jenkins master was running on RHEL using the RPMs provided by
> > upstream jenkins. When jenkins became available in Fedora, we switched our
> > master to be Fedora using the RPMs from Fedora. However, nowadays Jenkins 
> > is no
> > longer packaged for Fedora, our jenkins master is therefore outdated.
> > 
> > On the other side of the fence, with our dear friends from CentOS, is a 
> > brand
> > new, shiny and well supported Jenkins instance.
> > So we thought it may be good to leverage the CentOS infrastructure to 
> > alleviate
> > our infrastructure and maintenance.
> > 
> > We are currently working on setting up a Jenkins master in ci.centos.org 
> > that
> > would be dedicated to projects ran in pagure.io.
> > It needs a small change to pagure.io and some work on the CentOS side but
> > nothing hard and we expect to be able to migrate the first volunteer 
> > projects by
> > early next week.
> > 
> > Once the first migrations have happened and the first rough edges have been
> > smoothed we will be announcing an official retirement date for
> > jenkins.fedorainfracloud.org and migrate all the projects hosted there to
> > ci.centos.org, and of course help with the potential questions raising from
> > this.
> 
> Will there be a standard / automated migration path for projects that
> have followed documented steps to implement a CI workflow through this
> Jenkins instance, like these:
> 
> https://docs.pagure.org/pagure/usage/pagure_ci_jenkins.html
> 
> ? Thanks!
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

The plan is to automatically import the existing job configs from
jenkins.fedorainfracloud to the new tenant in ci.centos.org 

Changing the Build trigger in the repo settings to point at the new
instance -may, or may not- be a manual step, but there will be, at the
very least, a documented procedure for that.

The goal here is to, first get a supported jenkins instance available,
try a migration of a 'friendly' project (thanks Pingou for
volunteering!) and then work out the procedures for retirement. 

-- Brian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reminder: Distributions Devroom CFP - Deadline 10-December

2015-12-07 Thread Brian Stinson 
On Nov 02 15:46, Brian Stinson wrote:
> FOSDEM 2016 - Distributions Devroom Call for Participation
> 
> The Distributions devroom will take place 30 & 31 January, 2016 at FOSDEM, in
> room K.4.201 at Université Libre de Bruxelles, in Brussels, Belgium. 
> 
> As Linux distributions converge on similar tools, the problem space 
> overlapping
> different distributions is growing. This standardization across the
> distributions presents an opportunity to develop generic solutions to the
> problems of aggregating, building, and maintaining the pieces that go into a
> distribution.
> 
> We welcome submissions targeted at developers interested in issues unique to
> distributions, especially in the following topics:
> 
> - Cross-distribution collaboration on common issues, eg: content distribution 
> and documentation
> - Working with vendor relationships (eg. cloud providers, non-commodity 
> hardware vendors etc )
> - The future of distributions, emerging trends and evolving user demands from 
> the idea of a platform
> - User experience management ( onboarding new users, facilitating technical 
> growth, user to contribution transitions etc )
> - Building trust and code relationships with the upstream components of a 
> distribution
> - Solving traditional problems like package management, and content 
> management (eg. rpm/dpkg/ostree/coreos )
> - Contributor resource management, centralised trust management, key trust etc
> - Integration technologies like installers, deployment facilitation ( eg. 
> cloud contextualisation )
> 
> Submissions may be in the form of 30-55 minute talks, panel sessions,
> round-table discussions, Birds of a Feather (BoF) sessions or lightning talks.
> 
> Dates
> --
> 
> Submission Deadline: 10th Dec 2015
> Acceptance Notification: 15th Dec 2015
> Final Schedule Posted: 17th Dec 2015
> 
> 
> How to submit
> --
> 
> Visit https://penta.fosdem.org/submission/FOSDEM16
> 
> 1.) If you do not have an account, create one here
> 2.) Click 'Create Event' 
> 3.) Enter your presentation details
> 4.) Be sure to select the Distributions Devroom track!
> 5.) Submit
> 
> 
> What to include
> ---
> - The title of your submission
> - A 1-paragraph Abstract
> - A longer description including the benefit of your talk to your target 
> audience
> - Approximate length / type of submission (talk, BoF, ...)
> - Links to related websites/blogs/talk material (if any)
> 
> If you have any questions, feel free to contact the devroom organizers:
> distributions-devr...@lists.fosdem.org 
> (https://lists.fosdem.org/listinfo/distributions-devroom)
> 
> Cheers!
> Karanbir Singh (twitter: @kbsingh) and Brian Stinson (twitter: @bstinsonmhk)
> 
> for and on behalf of The Distributions Devroom Program Committee

Hi Folks,

Just a reminder that the CFP for the Distributions Devroom will close on
Thursday 10-December.

Cheers!

--
Brian Stinson
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Distributions Devroom CFP

2015-11-02 Thread Brian Stinson 
FOSDEM 2016 - Distributions Devroom Call for Participation

The Distributions devroom will take place 30 & 31 January, 2016 at FOSDEM, in
room K.4.201 at Université Libre de Bruxelles, in Brussels, Belgium. 

As Linux distributions converge on similar tools, the problem space overlapping
different distributions is growing. This standardization across the
distributions presents an opportunity to develop generic solutions to the
problems of aggregating, building, and maintaining the pieces that go into a
distribution.

We welcome submissions targeted at developers interested in issues unique to
distributions, especially in the following topics:

- Cross-distribution collaboration on common issues, eg: content distribution 
and documentation
- Working with vendor relationships (eg. cloud providers, non-commodity 
hardware vendors etc )
- The future of distributions, emerging trends and evolving user demands from 
the idea of a platform
- User experience management ( onboarding new users, facilitating technical 
growth, user to contribution transitions etc )
- Building trust and code relationships with the upstream components of a 
distribution
- Solving traditional problems like package management, and content management 
(eg. rpm/dpkg/ostree/coreos )
- Contributor resource management, centralised trust management, key trust etc
- Integration technologies like installers, deployment facilitation ( eg. cloud 
contextualisation )

Submissions may be in the form of 30-55 minute talks, panel sessions,
round-table discussions, Birds of a Feather (BoF) sessions or lightning talks.

Dates
--

Submission Deadline: 10th Dec 2015
Acceptance Notification: 15th Dec 2015
Final Schedule Posted: 17th Dec 2015


How to submit
--

Visit https://penta.fosdem.org/submission/FOSDEM16

1.) If you do not have an account, create one here
2.) Click 'Create Event' 
3.) Enter your presentation details
4.) Be sure to select the Distributions Devroom track!
5.) Submit


What to include
---
- The title of your submission
- A 1-paragraph Abstract
- A longer description including the benefit of your talk to your target 
audience
- Approximate length / type of submission (talk, BoF, ...)
- Links to related websites/blogs/talk material (if any)

If you have any questions, feel free to contact the devroom organizers:
distributions-devr...@lists.fosdem.org 
(https://lists.fosdem.org/listinfo/distributions-devroom)

Cheers!
Karanbir Singh (twitter: @kbsingh) and Brian Stinson (twitter: @bstinsonmhk)

for and on behalf of The Distributions Devroom Program Committee
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-09-22 Thread 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

2015-04-30 Thread 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

2015-03-20 Thread 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

2015-02-26 Thread 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?

2015-02-19 Thread 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

2015-01-01 Thread 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.

2014-10-28 Thread 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.

2014-08-12 Thread 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

Re: [ACTION NEEDED] Orphaning packages

2014-07-22 Thread Brian Stinson 
On Jul 22 10:53, Susi Lehtola wrote:
 Hi,
 
 
 due to relocation to another continent and starting a new job, I have
 to refocus my reduced time for Fedora on packages that I actively use.
 So, I'm orphaning the following packages:
 
 
 dopewars
 efte   
 firehol
 gdpc
 gromacs
 jaxodraw
 json-c
 latex2rtf
 lis
 noip
 pdfchain
 perl-Net-UPnP
 pidgin-latex
 pygrace
 pypar
 python-paida
 qd
 towhee
 unetbootin
 vecmath
 vim-latex
 votca-csg
 votca-tools
 xdrfile
 -- 
 Susi Lehtola
 Fedora Project Contributor
 jussileht...@fedoraproject.org

I think I can grab python-paida and pypar. 

Brian

--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Brian Stinson

2014-07-13 Thread Brian Stinson 
Hi Everyone, 

My name is Brian Stinson. I've followed the Fedora project since my first Linux
box (FC2) and I've done EL (RHEL and CentOS) administration for a living for a
few years now, most recently for the Mathematics department at Kansas State
University. 

My goal is to contribute to mathematical and scientific software in EPEL for 
work,
and get involved in the community at large (including anything python
related) for fun. 

My first package contribution is python-djvulibre (Python bindings to an
open-source implementation of the DjVu document format):
https://bugzilla.redhat.com/show_bug.cgi?id=1119095

I'm seeking a sponsor who is familiar with packaging python applications who can
also help me with EPEL best practices. 

Side note: I've also done a little work on centpkg for the CentOS project:
https://git.centos.org/summary/centpkg.git and I'm greatly appreciative of all
the work Fedora has put into the dist-git workflow.

Cheers!
Brian

--
Brian Stinson
bstin...@ksu.edu | IRC: bstinson | Bitbucket/Twitter: bstinsonmhk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct