On Wed, 22 Jan 2020 at 11:02, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote:
>
> On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
> <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Felix Schwarz <fschwarz@xxxxxxxxxxxxxxxxx> writes:
> >
> > > Am 21.01.20 um 21:48 schrieb Guido Aulisi:
> > >> I totally agree with Fabio, I can’t think of a single reason we should dismiss
> > >> pagure.
> > >
> > > Gitlab is used by many free software communities like Freedesktop, Gnome,
> > > Debian. Using the same tools could help to facilitate
> > > inter-process/inter-distro collaboration.
> > >
> > > Personally I guess github would attract most contributions for Fedora from new
> > > contributors but it is closed source so I'd prefer gitlab for Fedora. (Though
> > > I somehow got used to pagure and getting the gitlab integration to the same
> > > level as pagure currently will be a lot of work for sure.)
> >
> > On top of that Gitlab is a huge Ruby on Rails application and (at least
> > I have the feeling that) the Fedora community doesn't have so many Ruby
> > developers in comparison to Python developers, so implementing something
> > comparable could be challenging let alone from the manpower point of
> > view.
>
> That's the whole point of APIs, and I'm sure they provide bindings for
> those APIs to assist in the process.
>
Sorry, no they don't. There are some community projects that provide
some overlays to some of the APIs, but they are in various states of
disrepair. Some are doing somewhat okay, but it's difficult since
their churn rate also includes API breakages.
> > And then there's the issue that we are not upstream and might have to
> > maintain the integration as a downstream patch forever as upstream might
> > not want it.
>
> They've provided pretty good support to various other open source
> communities such as GNOME and Freedesktop/Xorg.
>
Yes, but neither of those communities actually have terribly special
requirements. In fact, those communities either had *nothing* in terms
of infrastructure (FreeDesktop/Xorg) or were willing to throw
everything away for GitLab (GNOME). We would not fit in either bucket,
which makes GitLab a very awkward fit for us.
And GitLab CI is a poor fit for Fedora because it doesn't offer a good
model for distribution-scale integration and delivery. At $DAYJOB, I
have been maintaining a heavily used GitLab system for three years,
and I have some fairly good experience understanding where it fits
well since $DAYJOB folks try to exploit as many features that are
reasonably useful as possible. And frankly, it works well for GNOME
and FDO because multi-project integration is not a fundamental
requirement for the projects hosted there. For Fedora, this *is* a
fundamental requirement, and the Fedora CI people are working
gloriously towards the goal of having that be fully in place.
> I think we should be looking at this from a different PoV.... like the
> given the resources that we currently have attempting to develop a git
> forge what could they do if someone else was doing that what other
> awesome things could they achieve if they were able to deal with
> integration as opposed to just playing catch up.
That's not the motivation here. And honestly, I've *never* seen that happen.
It just happened last year, a lot of the development effort of the CPE team was focused on rawhide gating. It meant that projects that were not related to that effort suffered from this, for example pagure, anitya (release-minotoring), speeding up the compose, moving away from PDC, moving from the current FAS, etc ...
That's also a somewhat negative view of this, because it implies we're
not doing something awesome now. Pagure fills a niche that currently
isn't filled by anything else today and works rather well in doing so.
Pagure is actually a pretty awesome forge that provides some unique
capabilities:
* Remote pull requests, allowing people working on their own servers
to contribute to projects on Pagure
* Support for fully offline workflows (this is actually possible due
to Pagure's fundamental design)
* Full state project mirroring in a reasonably portable manner
* Full themeability without pain (that's fairly recent, but it's nice!)
* First-class support for integrating with other solutions (best of
breed combinations rather than difficult monoliths)
Downstream distributions can actually fully mirror src.fp.o without
too much pain, including PRs, and do further work based on it. That's
not really a thing in other forges. I know that I've been using that
property for some of $DAYJOB work and personal work too, and it really
makes life quite nice.
Since Pagure 5.0, I've been a very happy user of the Pagure forge, as
the usability of the system has gone way up and it is very close to my
vision of what a Free Software forge should be like. Pagure makes our
island have bridges to other islands, as opposed to all these GitLab
servers that are closed islands.
And there's this worry that GitLab will go the same path Transifex
did. They have a ton of incentives to do so, and they already are
starting to with the consideration of injecting nonfree _javascript_ in
all variants. And if you think community forks are going to survive on
the GitLab codebase, oh boy, nope. That codebase is *huge* and
complex. It's a combination of Ruby and Go that has one of the most
baffling architectures I've observed. The RhodeCode fork Kallithea is
many times smaller and is equally struggling.
Pagure is also slowly growing as a community in its own right and
there are various groups aligned with Pagure's vision that are
interested in adopting it as their solution and contributing to the
project. Part of this has been somewhat due to my campaigning for it
in aligned communities, of course, but it's also because Pagure is
genuinely good and unique among Git forge solutions.
Pagure is also proof that Fedora can be innovative in a very positive
way. It was a rough start, but we've got a groove going, let's not
kill it!
I agree with you that Pagure is a cool project and is particularly unique in the world of git forges. I have also made my first FOSS contribution to Pagure and if I am part of the Fedora Community today it is because of Pagure and Pingou. But I also have to pragmatic and realistic and I think that to be successful Pagure needs more development effort and I don't think that in the current state of the Fedora Infrastructure we can afford that development. My opinion from working day to day in this infrastructure is that we are now reaching a point where we have to pay for the technical debt we have accumulated. Like any sort of debt, you have to pay its interests and for many year we did not, now with have the debt collector knocking at the door, looking at the televisor in the living room. The more we wait to pay back this technical debt the worst it becomes, you also have to add to that, that a lot of the technical and domain knowledge about the tools and the infra in general was lost when most of the creator of these applications moved to new adventures.
The Fedora community is also not growing much, more and more community member ends up having more and more things to do, because of that they are even more dependent on the infrastructure being reliable and stable. For example many people might have planned to contribute during the end of the year holidays but could not because of the problem we have experience with Koji, Bodhi and RabbitMQ. It means that users of the infra are getting frustrated because Koji is slow again, a Bodhi update was not pushed again, there is a problem pushing a commit to fork again, or there is no progress on my 2 year old ticket that ask to rename my group in FAS. It also means that people working on the infra are getting more and more frustrated because there are just too many fires to fight at once and whatever they do it will suck or someone will complain.
All this technical debt, also make it harder to attract new contributor who would be interested to contribute development time to these applications. Being innovative and creative is fun, creating new cool application for the Fedora Community is really great and rewarding, the other side of the medal is a little bit less shiny, maintaining a large code base, making sure that it runs well in production is not that interesting and rewarding.
In my opinion, as a community we have to make a choice either we continue as we are now, knowing very well that the things will only get worst, or do we try to refocus on the essential and make some sacrifice and compromise ? Alternative to Pagure will not be perfect and will not cover 100% of the use cases, but can we live with it ? are we ready to make some trade off ?
Another solution is to find 20 developers that are willing to invest a few hours a week fixing bugs on all the applications we have.
The Pagure.io forge really is only missing some kind of self-service
CI to make it generically useful. CentOS CI is a trash heap and needs
to be replaced by a better solution that allows self-service
enablement. I'm sorry, but whoever thought that CentOS CI would scale
or work reasonably well needs to rethink their priorities. It's the
only part of the Pagure.io forge system that isn't self-service, and
it shows with the poor levels of CI adoption.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
_______________________________________________ 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
