On Mon, Mar 30, 2020 at 7:17 PM clime <clime@fedoraproject.org> wrote:
I thought CPE ("Community Platform Engineering") is a part of the
community.

We are part of the CentOS and Fedora Communities, correct.
 
But no, because you want to hand over pagure.io to "the
Community", so what community is that...People that don't have
hardware?

As a team we owned over 130 services at last count, we cannot sustain that load, so wish to have the community come on board and take some of that ownership, be it code maintenance, feature development or hosting off of us. With that workload on us we cannot give due diligence to each app, Pagure fell into that category and led to this process. So yes, we would like to have the community more involved with running pagure.io, that may just be at an operational / development level, we haven't gotten that far in our planning yet.
 

It seems that the whole proposal is trying to make src.fp.o and
git.centos.org part of a corporate solution and therefore eat a huge
part of Fedora & CentOS ecosystems and of their independence.

Do you realize how valuable the Fedora upstream is for RHEL?

It's hugely valuable. 

The thing that I am saying is suggested by points like:

> 5
> As a RH Developer
> I need the ability to privately comment on a PR
> so that confidential information does not leak outside Red Hat

> 8
> As a RHEL engineer
> I want a modern git workflow
> So that I can use upstream practices in RHEL development for quicker delivery of features & fixes

Taking points like this into account for Fedora dist-git only makes
sense if RHEL development would take place directly on src.fp.o. 
But
that's not the case. We have community upstream and then there is RHEL
that further uses and processes the upstream work. While there is some
overlap in people, these are still two separate software development
domains.

The requirements given were taken for what they were, the two requirements you quoted were taken at face value.
 

Your suggestion is: "Let's break everything."

I never suggested that.
 
Do you know how many
existing integrations with pagure there are?

No. Our analysis will tell us that in due course
 
Do you know how much time
and also emotions was put into building it?

I have tracked the project development and am very familiar with the evolution of it. I can't quantify emotions but I do understand how much this means to the community and to the folks who worked on it and Pagure will live on beyond CPE operationally using it as a Git Forge. Just to note that emotions were not a factor in the requirements gathering process from the Fedora Community side, we got very simple requirements to process and base our decision upon.
 
Do you say all that work
was useless?
 
I never said that 

It's not only about technology but it's also about how
many people connected on it with a vision to build something good. And
by trying to overcome the feature gap, this can continue.

And I genuinely would love to see that feature gap overcome and for Pagure to flourish, I will be tracking the project and assisting where I can. 

Fedora is a community Linux distribution with people that want to work
together on something, it's not just some dumb package factory.

Do you want a community help on pagure?

Yes, I'd love a proper community to form around it.
 
Ask for it but not by handing
it a project that RH does not want to maintain anymore but instead try
first to describe the feature gap we are missing and see if it can be
overcome by a collective effort. It's better than rushing into a
decision which is breaking an extreme amount of stuff and which might
put into grave a good reusable technology that we have and that we
could also offer to other people and other communities for free so
that open-source can thrive.

We had several call to arms to bring more contributors in to apps that CPE had attained ownership of. Had we wanted to drop Pagure as a project we would have done so. We engaged on  a requirements gathering exercise and while you might not agree with the outcome, Gitlab meets the vast majority, if not all, the needs of the Fedora community. The effort we will undertake to fix tooling and make this work will still be a fraction of the effort for us both short and long term and allows us to concentrate on the actual value adds that the Fedora Community, via the Council, are requesting of our team. That's the trade off that I think is being missed here. 


Fedora dist-git is using pagure, CentOS dist-git is using pagure so
both these parties are, in my opinion, okay with it already. Let's
build on something we already have instead of destroying it over and
over again. Only this is a way for Fedora community to be a leading
party in the open-source and free software, which it should be.

clime
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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


--

Leigh Griffin

Engineering Manager

Red Hat Waterford

Communications House

Cork Road, Waterford City

lgriffin@redhat.com    
M: +353877545162     IM: lgriffin