On Thu, Apr 2, 2020 at 8:05 AM Adam Williamson <adamwill(a)fedoraproject.org
On Wed, 2020-04-01 at 22:33 -0400, Randy Barlow wrote:
> On 4/1/20 1:16 PM, Adam Williamson wrote:
> > Has it been demonstrated that either Pagure or Gitlab CE are
> > "not viable" for the purposes Fedora needs?
> Hey Adam!
> I agree with you that Pagure and Gitlab CE are both
viable for Fedora's
> needs in terms of feature matrices and requirements. We have shipped a
> handful or so of Fedora releases over the last 3ish years since src.fpo
> came online as proof!
> However, the CPE team does not have the resources to do a
good job on
> maintaining that system, and Bodhi, and Koji, and the 187 other apps (I
> think we did count the apps we maintained at one point and ended up with
> a list that was about 190 long!). The responsibility to engineer ratio
> is not healthy or sustainable.
Okay, look, at a certain point I start to feel like we're trapped in
some sort of Kafka novel here.
At the outset of this whole mess, quite a lot of people said "well this
is obviously just all a pretext for dropping Pagure and going to hosted
Gitlab". Much offence seemed to be taken at this, and much was made of
this absolutely not being the case at all, and Pagure being definitely
a contender, and - as was pointed out upthread - how there would be
public meetings and feedback sessions and a whole three-ring circus
before a final decision was made. Which very definitely hadn't already
been made, or anything.
We held the public consultation with each community. Fedora held public
dissemination of it's own requirements that were rolled up after a lengthy
discussion (almost 10 days beyond the deadline to roll up). Once that
closed we went into analysis mode and we didn't rightly or wrongly, share
the full user story list for every single stakeholder to debate and argue
about. I personally think it was the right call not to share it as already,
in several replies from people, the merit of some requirements making the
list was called out. That's not conducive to a debate when the requestor
might not be part of the community and when we as CPE genuinely take each
requirement at face value and it's not for us to debate or side on whether
it's a 'good or bad' requirement. Given the passionate responses here I
know that others feel that decision was wrong. I respect that viewpoint, I
don't have to agree with it, but I respect it.
And now three days into this thread, you're saying "well, CPE doesn't
have the resources to maintain Pagure". So, what, people were right in
the first place, and this was really just the Dump Pagure Project all
To be crystal clear, the exercise was to do check if we needed to invest in
Pagure (heavily or otherwise) and use those requirements to help set the
priority of our Git Forge solution, a solution we had ignored priority wise
as both a team and stakeholders (Fedora Council and CentOS Board) and which
was not harming us. Had Pagure been the choice, we would have invested in
it to bring it to the point we needed it and would have maintained it
longer term. We would have made it clear to stakeholders that the trade off
here was other features that we could not call on. That's why we ran this,
to arrive at that logical decision and not make an ill informed decision.
If so what was the point of all this half-baked kabuki nonsense? Why
not just say so up-front?
Because it genuinely was not the case.
If CPE never thought it had the resources to
maintain Pagure and Pagure was never really a contender, and Github
as clearly a non-starter as Leigh says it was, why didn't we just say
"yeah no we're going to Gitlab" four months (or whatever it was) ago
and save all of this silliness?
I'm going to be clear here. CPE does not have the resources to maintain
Pagure to the standard it needs to be. CPE does not have the resources to
maintain Bodhi to the standard it needs to be. CPE does not have the
resources to.......I can keep going but you get the picture. Randy is
correctly pointing out that from an Engineering capacity perspective, we
simply do not have the people power to maintain, build, drive, own and be
responsible for the lifecycle of a project that in truth needs a full time
team far beyond the current capacity of our team. Last year we invested all
our available developers to bring Bodhi to a point it could gate Rawhide.
We were prepared to make a similar investment in Pagure to bring it to a
point it met the requirements we had gathered. The difference here is that
finish line does not exist for Pagure as requirements we received have a
much larger long term onus on us as a team. That's why we ran it, to figure
out if we could do another long stint in a singular project to solve a real
problem we have. The requirements said this was not viable.
> We agree that this process wasn't
> actually very open at all, but *even if it had been*, if the result was
> preordained, what would have been the point?
it was not preordained.
> Also, why does CPE not *at least* have its ducks very
definitely in a
> row about exactly how much work is actually going to be involved in all
> the options here?
This analysis was ran side by side with a datacenter colo move across
country in the USA. The AAA project requirements and spin up for replacing
FAS. CentOS Stream requirements and phased deliverables. We took a decision
to not get as deep technically when the initial set of requirements was
trending towards Gitlab. This was a time investment trade off and now we
can schedule the deeper tech phase and are making moves in that direction
How has this decision taken several months and yet
when people ask "okay, so exactly what is the plan for re-doing all the
Pagure<->dist-git integration with Gitlab, and how much work and how
long is that going to take?", the answer is "uh, we don't know, we're
going to figure it out now"?
I hope the above explains it.
> Why does the blog post that announced this
> decision - talk quite a lot about what the plan is with regard to
> pagure.io (that's clearly what it usually means when it says "Pagure",
> in context) but nothing at all about what the plan is wrt dist-git?
This was to ensure that the option for project hosting on pagure.io was
still there for community members who wish to store their source code in
Pagure. It was requested to be explicitly called out by Pingou to make it
crystal clear that this decision is not designed to kill Pagure. We are
happy to facilitate pagure.io as long as the community find it useful and
hopefully we will get interest in helping to maintain that.
> Not to mention that this subthread is about the
circumstances in which
> Fedora has decided it will accept non-free infra, and that "not viable
> and not available" quote. If we count absolutely anything that involves
> CPE actually doing any work beyond paying someone else to run it as
> "not viable", well, yeah, that's going to render an awful lot of stuff
> "not viable", isn't it? But I don't think that's how many
> necessarily have expected that text to be interpreted.
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
Red Hat Waterford <https://www.redhat.com/
Cork Road, Waterford City
M: +353877545162 IM: lgriffin