On Thu, Apr 2, 2020 at 8:05 AM Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote:
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
along?
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 was
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 already.
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 people would
necessarily have expected that text to be interpreted.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Leigh Griffin
Engineering Manager
Communications House
Cork Road, Waterford City
lgriffin@xxxxxxxxxx
M: +353877545162 IM: lgriffin
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
