On Wed, Jan 22, 2020 at 9:48 AM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote:
>>
>> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>> > And any discussion of GitHub isn't going to involve self-hosted, it's
>> > going to involve GitHub.com, which means we're talking about losing
>> > more of our independence as a project. This is one of those things
>> > that I'm not sure is a wise move.
>>
>> Well since we have a request for requirements: I propose requirements
>> #1 and #2 are to be self-hosted and open source. I'm suspect the Fedora
>> community would be outraged if we fail to meet either requirement.
>>
>> So if we can agree on that much, then we can avoid wasting time by
>> including GitHub in the list of options. That would bring us to a
>> choice between GitLab CE and Pagure. (Are there any other serious
>> options?)
>
>
> Thanks for actually proposing some requirements :-).
>
> In my opinion there are 2 different use cases :
>
> - pagure.io :
> For me the requirements here is to provide a place for community members to host there projects. And project here can mean anything it can be actual source code, documentation, or just a README with some info about a team or like many team have just a ticket tracker. Once of the strong requirement is that whatever the solution is it needs to integrate with Fedora Account System and user should be able to use Single Sign On. Regarding the use case where a team wants to have a issue tracker and maybe a README to give details about how to contribute to that team I think teams.fedoraproject.org should be the prefered solution, for the second where people want to host a git project (code, documentation, book, etc ...) I don't think this needs to be solved by the Fedora community, there are many options (free and non free, as in freedom) which have dedicated infrastructure and dedicated teams running this type of service.
>
>
> - dist-git (src.fedoraproject.org):
> This is a different use case, since here the solution needs to integrate with the rest of the infrastructure. the list of requirements here will be more specific for example it needs to be able to integrate with Fedora FAS but also to have the FAS group synced, branch ACLs, a way to integrate with release-monitoring, a way to integrate with bugzilla, a way to integrate with fedora-messaging (RabbitMQ), ....
> In general I think most of the integration with our infrastructure can be done with any solution either using the solution APIs or plugins system. After we need to compare the cost of developing and maintaining these pieces of glue to integrate everything against the current situation.
>
If we go for splitting up use cases, than I'd like to highlight one thing:
src.fedoraproject.org is not a GitForge, it is a centrally managed
code-review platform
Git Forges play a lot with the idea of users being able to create
their own forks of the repository, their own projects, with their own
rules. src.fp.org is the integrated platform where Fedora rules are in
action. This is different from the use case KDE and Gnome have, as
they manage development of projects, while we manage the integration.
And while GitHub and GitLab are well know leaders in the Git Forge
business, they are actually not that good when it comes to the topics
of 1) managing the large multi-component project in a unified way
under central authority; 2) managing actual code review process.
Code Review platforms, like Gerrit are way better at that.
To see an example, take a look at the management of projects and
groups in Gerrit. Or take a look on integration of CI systems. GitHub
still struggles to make it natural part of the interface.
We _can_ implement centralized code review platform on top of any Git
Forge service. But let's maybe consider using the right tool for the
right job?
The obvious counter-argument here is: most of the users are
uncomfortable with any interface other than GitHub. No matter if the
interface is superior, or lighter, or nicer, there is still going to
be that thing that it is _unusual_.
We, as a Linux distribution, know this argument pretty well. We, as
Fedora Linux distribution, know it even better: you can not bring
something new if you are scared of unusual things. Should it stop us?
We do need a better discoverability and visibility in the generic
development community. But it is a solvable task: we can create a
read-only mirror of our code on every common platform out there. We
can use it as an opportunity to show what we do, but also to teach how
we do it. For example OpenStack has a bot which replies on every
GitHub issue and pull-request to the read-only mirrored repository
with a manual on how one can send the same change through the
OpenStack development process. We would need to do it the same way
anyway, if we land on anything other than GitHub.
--
Aleksandra Fedorova
bookwar
_______________________________________________
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
