Re: Git Forge Requirements: Please see the Community Blog

[Julen Landa Alustiza]

Heya,

Currently we have two different pagure instances that hosts different 
use cases on them, and different use cases means different requirements, 
so first of all, about what use cases we are talking about?


we have src.fp.o for distgit, some pagure.io projects that hosts actual 
code development repos and some other repos that are used as trackers 
and documentation containers.


For all of them, I agree with mcatanzaro's requirements:
#1 self hosted
#2 open source

IMO, #1 could be a soft requirement, I would be fine with a service 
provided by an upstream first and open source friendly service provider 
if it allows us to dump out all our data on a easy way. Now git and 
github is the mainstream workflow, but previously was sourceforge and 
svn . We should be able to transfer our data from our current service to 
a N+1 or N+2 service without losing too much so we should be able to 
dump all our data on a supported way.


I have some more general requirements:

#3 privacy friendly. Nowadays js|cookie tracking is huge on the world 
wide web, I would prefer not being tracked on that way while using a 
fedora service. bodhi, koji or distgit does not inject any weird 
tracking javascript or cookies, I love that and since privacy concerns 
me I would like to continue on this way.


#4 Good integration with Fedora infra's core services. This include fas 
(and it's replacement) and fedora-messaging


#5 Easy to onboard and open to any community member, newcomers included. 
We should avoid the integration problems that we're having with 
teams.fp.o on this matter for example (see below)


This requirements are not just for our git forge, all the fedora 
services should satisfy with them.


Then, we should capture and analyze the different use cases 
individually. Different use cases, different requirements. They might 
fit all of them on the same solution or we could move some of them to a 
different one if the other solution fits better for that case.


So let start with distgit. Here we have a bunch of more requirements:

#packager.1: technical implementation of our packaking policies and the 
ability to evolve them as the policies evolve. This means at least 
support for system-wide commit users (provenpackagers), system-wide 
restricted branches, systemn-wide protected (non force pushable) refs, 
system-wide actors that can bypass all this limitations (releng).


This should cover orphaning and retaking process too.
We lack but we should have ACL branches and admins to support different 
EPEL|Fedora maintainers on the same repo.


#packager.2: Integration with other options|services that we have on our 
packaking workflows. This could be done on the git repo or we could have 
a different packager control panel service (I love miro's mockups for 
example). This includes BZ, bodhi, koji, anitya, BZ overrides...


That's for now on distgit.

On pagure.io I identify two big groups of repositories: code repos for 
development of different projects and tracking repos that are mostly 
used for the ticket system and some documentation.


The later ones could fit on teams.fp.o if we can solve the big issues on 
it: the fas integration is not perfect, and is not open for 
contributions. Fixing [1] and [2] is a requirement for teams to fulfill 
the initial general requirements, so it would be a requirement for an 
hypothetical transfer of this kind of projects from pagure.io to teams.fp.o


As general requirements, I have two at least:

#tickets.1: ticket|issue system support for usual workflows: tickets, 
assignees, tags, states, priorities...


#tickets.2: some kind of documentation integration. We have some repos 
on this use case that are just docs + tickets. We could support them on 
a non git repo solution if we can integrate both docs and tickets on a 
unique UI.


And then we have the code repos.

I like the idea of having a unique place to host all the fedora related 
code projects and I would add a couple of requirements around the 
homepage about this in case we go with a solution that groups all those 
code repos on a single place:


#dev.1: An attractive homepage that shows where is the activity right 
now, where we need help, and where newcomers can start to contribute.


#dev.2: Good searching capabilities.



For the repo itself... this is where we probably diverge more since 
every single developer has her own workflows so she'll have their own 
personal requirements. Some of us could just work with a system that 
allows you to make basic git operations and some others will require 
complex interactive conflict resolving UIs.


On my case, I don't need too much:

#dev.3: git support. I'm fine with just ssh support, but https one could 
benefit newcomers onboarding process.


#dev.4: PR workflow support.

#dev.5: ticketing system

#dev.6: web ui to the code, branches etc.

And then I have a soft requirement on a actual pagure feature that I did 
not use it previously but it means a lot nowadays 

Re: Git Forge Requirements: Please see the Community Blog

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 12:20 PM Neal Gompa  wrote:
>
> On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova  
> wrote:
> >
> > On Wed, Jan 22, 2020 at 9:48 AM Clement Verna  
> > wrote:
> > >
> > >
> > >
> > > On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro  
> > > wrote:
> > >>
> > >> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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 

Re: Git Forge Requirements: Please see the Community Blog

[Miro Hrončok]

On 22. 01. 20 12:19, Neal Gompa wrote:>> 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.


I'm sorry, no. I absolutely despise the Gerrit workflow that OpenStack
uses. To me, the only thing worse than Gerrit is the email/bz patch
submission workflow we used prior to Pagure. Gerrit would be a step up
from that legacy workflow, but it pushes too much crap onto the
contributor that it's a great way to demotivate people.

Having contributed to projects using Gerrit, and previously dealt with
Gerrit based workflows, I can honestly say that Gerrit is absolutely a
miserable experience and the OpenStack project should feel bad about
the fact that they think Gerrit provides a good user experience.
What's worse is that the stupid bot that they use on GitHub mirrors is
completely unfriendly to drive-by contributors. The OpenStack Project
is an example of how to make it fundamentally driven by corporate
developers who force asinine workflows because they can't be bothered
to make a proper community full of a mixture of hobbyists and
corporate contributors. And don't get me started on the fact that
there are no distributions of OpenStack on community Linux
distributions anymore, which I further indicate as evidence that the
OpenStack community is too insular for its own good. RDO does not
count since it doesn't work on *real* community distributions like
Fedora.


While I don't necessarily agree with the tone, I must agree the the Gerrit 
experience for drive by contributors is one of the most horrible ones I had.


I even think sending patches over e-mail is probably better.



The main reason I haven't pursued it is because CentOS CI is so
unreliable and awful. It's demoralizing getting failures and then
looking at Jenkins and seeing there are no logs of the failure. Or the
increasing number of "error" states where it just breaks...


This has been reported a year ago, without a fix so far:

During running tests, it's very hard to see what's happening
https://pagure.io/fedora-ci/general/issue/2

CI errors are undecipherable
https://pagure.io/fedora-ci/general/issue/43

CI errors happen far to often
https://pagure.io/fedora-ci/general/issue/44


I've been trying to make those issues a priority when we adapted gating, but I 
was outvoted at FESCo.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Wed, 22 Jan 2020 at 11:02, Neal Gompa  wrote:

> On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson 
> wrote:
> >
> > On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
> >  wrote:
> > >
> > > Felix Schwarz  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 

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 6:06 AM Aleksandra Fedorova  wrote:
>
> On Wed, Jan 22, 2020 at 9:48 AM Clement Verna  
> wrote:
> >
> >
> >
> > On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro  
> > wrote:
> >>
> >> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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 

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 6:04 AM Adam Williamson
 wrote:
>
> On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
> >
> > > > 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.
>
> https://github.com/python-gitlab/python-gitlab looks like a pretty
> actively maintained thing which claims to be compatible with current
> Gitlab API.

I'm using that one at work for some stuff, and most of the basic APIs
are in place, but the coverage of the GitLab API isn't very high. It's
mostly because GitLab keeps adding more stuff to the API and people
can't keep up, though. When I started using it around GitLab 10.5, it
was considered a lot more complete than it is now.

That said, basic interactions work pretty well, and as far as I know,
it's the most complete of the community API modules.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Aleksandra Fedorova]

On Wed, Jan 22, 2020 at 9:48 AM Clement Verna  wrote:
>
>
>
> On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro  wrote:
>>
>> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Wed, 2020-01-22 at 05:00 -0500, Neal Gompa wrote:
> 
> > > 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.

https://github.com/python-gitlab/python-gitlab looks like a pretty
actively maintained thing which claims to be compatible with current
Gitlab API.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Florian Weimer]

* Felix Schwarz:

> 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.

I don't think Github allows disabling pull requests for projects.  This
means that a ptoential Fedora Github service would host content
submitted by people who have to agreed to the FPCA
.

Maybe that alone is sufficient to rule out Github?

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Wed, Jan 22, 2020 at 1:05 AM Peter Robinson  wrote:
>
> On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
>  wrote:
> >
> > Felix Schwarz  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.

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 

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Wed, 2020-01-22 at 10:01 +0100, Pierre-Yves Chibon wrote:
> 
> IIRC phabricator does not issue tracking which mean it would not fit the
> use-case of FESCo, FPC and other groups that are mostly using pagure as a
> ticketing system.

Sure it does, we used to use it for this. It calls them 'tasks', but
it's the same paradigm.

https://phacility.com/phabricator/maniphest/
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Wed, 2020-01-22 at 08:40 +, Peter Oliver wrote:
> On Tue, 21 Jan 2020, 21:32 Michael Catanzaro,  wrote:
> 
> 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?)
> 
> In the blog post they state that there aren't.  Certainly GitHub and GitLab
> have the most momentum.
> 
> I happen to like Phabricator, and appreciate the developer's opinionated
> design approach, but perhaps it's right to pick the most mainstream thing
> we can with the goal of not wanting to move again for, say, another decade
> or so.

We used Phabricator for Fedora QA work for a while, before migrating to
Pagure. It had some really nice features, but it was quite a lot of
work to maintain, and the fact that its workflow is not like Github's
and requires some specific tooling would likely be a barrier to
contribution since the Github workflow is such a de facto standard
these days.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Pierre-Yves Chibon]

On Wed, Jan 22, 2020 at 08:40:54AM +, Peter Oliver wrote:
>On Tue, 21 Jan 2020, 21:32 Michael Catanzaro, <[1]mcatanz...@gnome.org>
>wrote:
> 
>  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?)
> 
>In the blog post they state that there aren't.  Certainly GitHub and
>GitLab have the most momentum.
>I happen to like Phabricator, and appreciate the developer's opinionated
>design approach, but perhaps it's right to pick the most mainstream thing
>we can with the goal of not wanting to move again for, say, another decade
>or so.

IIRC phabricator does not issue tracking which mean it would not fit the
use-case of FESCo, FPC and other groups that are mostly using pagure as a
ticketing system.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Clement Verna]

On Tue, 21 Jan 2020 at 22:32, Michael Catanzaro 
wrote:

> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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.



> Michael
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Peter Oliver]

On Tue, 21 Jan 2020, 21:32 Michael Catanzaro,  wrote:

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?)


In the blog post they state that there aren't.  Certainly GitHub and GitLab
have the most momentum.

I happen to like Phabricator, and appreciate the developer's opinionated
design approach, but perhaps it's right to pick the most mainstream thing
we can with the goal of not wanting to move again for, say, another decade
or so.

-- 
Peter Oliver
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Adam Williamson]

On Tue, 2020-01-21 at 17:04 -0500, Michael Watters wrote:
> On 1/21/20 4:59 PM, Felix Schwarz wrote:
> > (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.)
> 
> Maybe I'm just a grumpy old system admin but it sounds like a lot of
> work for little, if any, gain.

The gain would be not having to maintain Pagure any more. It's
essentially one-time work for long-term gain, assuming the alternative
solution continues to exist and to be maintained and to meet our needs.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Michal Konecny]

On 21/01/2020 23:13, John M. Harris Jr wrote:

On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:

On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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?)

Michael

Both Gitea and Gogs are potential options, in my opinion, both are lightweight
and easy to extend.

If we go this way, in a few years we will end up in the same situation 
as with Pagure today. We will have many custom patches (which we need to 
take care of) and we will not have manpower to compete with the features 
of other major git forges.


--
Role: Fedora CPE Team - Software Engineer
IRC: mkonecny
FAS: zlopez
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Peter Robinson]

On Wed, Jan 22, 2020 at 4:59 AM Dan Čermák
 wrote:
>
> Felix Schwarz  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.

> 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.

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

Re: Git Forge Requirements: Please see the Community Blog

[John M. Harris Jr]

On Tuesday, January 21, 2020 9:57:59 PM MST Dan Čermák wrote:
> Felix Schwarz  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.
> 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.
> 
> 
> Cheers,
> 
> Dan

If these Python people really can't figure out Ruby, a language binding can be 
generated.. However, Ruby is much more clean than Python, and there's no 
requirement for downstream patches anyway. GitLab has a plugin interface these 
days.

-- 
John M. Harris, Jr.
Splentity

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

Re: Git Forge Requirements: Please see the Community Blog

[Dan Čermák]

Felix Schwarz  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.
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.


Cheers,

Dan


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Michael Catanzaro]

On Tue, Jan 21, 2020 at 3:13 pm, John M. Harris Jr 
 wrote:
Both Gitea and Gogs are potential options, in my opinion, both are 
lightweight

and easy to extend.


I have some experience with Gogs. I don't recommend it.

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

Re: Git Forge Requirements: Please see the Community Blog

[Alexander Bokovoy]

On ti, 21 tammi 2020, Alex Scheel wrote:

For a period of time, IDM tried using Pagure for FreeIPA development.
They filed a huge number of issues. Now we host issues on Pagure, and
have moved development to GitHub. [*] I think we've mostly quit filing
bugs; the Pagure team has done a good job with the resources they've
been given, but they definitely need more resources to pull this off
to a high level.


FreeIPA does not use Github for its primary code hosting. We do use
Pagure for that and would like to stay with open source forge. We do use
Github to mirror source code from Pagure and utilize pull requests flow,
though, purely because there are two things available there:
 - an easier new contributors' flow
 - ability to integrate with a larger number of CI systems

The first one sometimes is a deal breaker but not really too much. For
example, for Samba a move of existing Github mirror to Gitlab didn't
really reduced inflow of external contributors. Samba project does host
its git tree on own servers and maintains gitlab mirror for actually
doing reviews and accepting external and in-team contributions.


I still try and file issues from time to time...

...but Pagure really doesn't compare in quality to Gogs/Gitea, much
less GitLab or GitHub from strictly a development point of view.


My 2c.

- Alex


[*]: My team (Dogtag) is also considering moving our issues off of
Pagure onto GitHub, to host them along side our code. I don't claim
to speak for all of IDM here though, just noting what they've done.


>
> TL;DR:
> Can we please keep pagure? It already has the fedora-specific features
> we need, and I don't mind a "slow" pace of development.
> In my experience, it works really well, and I actually *like* to use
> it (which is not true for GitLab ... which is slow and horrible)
+1

> Fabio

I totally agree with Fabio, I can’t think of a single reason we should
dismiss pagure.

Ciao
Guido
FAS: tartina
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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


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


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Peter Robinson]

> >> 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.
>
> I second this.  FOSS is what's allowed RedHat to succeed and it would
> really suck to see Fedora switch to a closed source platform that's
> owned by Microsoft...
>
> Also, as somebody who runs a self hosted pagure server I would really
> hate to see pagure go away.  I understand Pingou may not have the time
> to work on the project as in the past but the torch should definitely be
> passed to somebody else or the community to continue work on the project.

It's open source now so what's stopping people/companies using it now
from contributing rather than relying on Pingou? Similarly if it
ceases to be a core piece of infrastructure for Fedora there's nothing
stopping the pagure community to continue it's development.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Tue, Jan 21, 2020 at 5:14 PM John M. Harris Jr  wrote:
>
> On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
> > On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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?)
> >
> > Michael
>
> Both Gitea and Gogs are potential options, in my opinion, both are lightweight
> and easy to extend.
>

Neither of those two are designed to be extended. There have been
other examples of attempts to do this, which has led to effectively
forking it. NotABug.org runs a fork of gogs for that reason. There are
some instances of Gitea that I'm aware of that had to be forked to be
extended. Forking to extend is not anything close to desirable.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[John M. Harris Jr]

On Tuesday, January 21, 2020 2:31:47 PM MST Michael Catanzaro wrote:
> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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?)
> 
> Michael

Both Gitea and Gogs are potential options, in my opinion, both are lightweight 
and easy to extend.

-- 
John M. Harris, Jr.
Splentity

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

Re: Git Forge Requirements: Please see the Community Blog

[Michael Watters]

On 1/21/20 4:59 PM, Felix Schwarz wrote:
> (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.)


Maybe I'm just a grumpy old system admin but it sounds like a lot of
work for little, if any, gain.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Felix Schwarz]

Am 21.01.20 um 22:31 schrieb Michael Catanzaro:
> Well since we have a request for requirements: I propose requirements #1 and
> #2 are to be self-hosted and open source.

+1

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Felix Schwarz]

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.)

Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[John M. Harris Jr]

On Tuesday, January 21, 2020 2:33:11 PM MST Neal Gompa wrote:
> Unfortunately, this is very difficult to manage with GitLab Omnibus
> based deployments

The new plugin interface makes it so that this is not the case. I make use of 
it on git.splentity.com, for example.

-- 
John M. Harris, Jr.
Splentity

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

Re: Git Forge Requirements: Please see the Community Blog

[Alex Scheel]

- Original Message -
> From: "Michael Catanzaro" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 21, 2020 4:31:47 PM
> Subject: Re: Git Forge Requirements: Please see the Community Blog
> 
> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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?)

I'd mention sr.ht (sourcehut) and gitea; the latter I run myself.

https://sourcehut.org/ (live: https://git.sr.ht/)
https://github.com/go-gitea/gitea demo: https://try.gitea.io/)

YMMV.

> 
> Michael
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Michael Watters]

On 1/21/20 4:31 PM, Michael Catanzaro wrote:
> On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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.

I second this.  FOSS is what's allowed RedHat to succeed and it would
really suck to see Fedora switch to a closed source platform that's
owned by Microsoft...

Also, as somebody who runs a self hosted pagure server I would really
hate to see pagure go away.  I understand Pingou may not have the time
to work on the project as in the past but the torch should definitely be
passed to somebody else or the community to continue work on the project.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Tue, Jan 21, 2020 at 4:18 PM John M. Harris Jr  wrote:
>
> On Tuesday, January 21, 2020 2:04:33 PM MST Neal Gompa wrote:
> > Aside from GitLab being very anti-integration
>
> This is no longer the case, by the way. GitLab has recently made it easier to
> add plugins, with the new method not requiring patching the source tree.
>
> Even before that change, webhook integrations + API calls were fairly powerful
> in GitLab.
>

I'm aware of those and the capabilities implied. Unfortunately, this
is very difficult to manage with GitLab Omnibus based deployments, and
there are other caveats and restrictions that make this not as usable
as it looks at first glace. And everyone I've talked to indicates that
the a from-source deployment is a recipe for insanity, so I'm not even
going to go there.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Michael Catanzaro]

On Tue, Jan 21, 2020 at 4:04 pm, Neal Gompa  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?)


Michael

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

Re: Git Forge Requirements: Please see the Community Blog

[Robert-André Mauchin]

On Tuesday, 21 January 2020 17:34:37 CET Leigh Griffin wrote:
> Hey Everyone,
> 
> On behalf of the CPE team I want to draw the communities attention to a
> recent blog post which you may be impacted by:
>  https://communityblog.fedoraproject.org/git-forge-requirements/
> 
> We will be seeking input and requirements in an open and transparent manner
> on the future of a git forge solution which will be run by the CPE team on
> behalf of the Fedora Community. This mail is being sent to the devel,
> mindshare and council-discuss lists for maximum visibility on a BCC to
> allow each list have their own views. Please forward it to any other list
> you may feel is relevant to maximise the exposure.
> 
> Thanks in advance,
> Leigh

Quote:
>At the same time, integrations that already exist in Pagure may need to be 
created for another git forge, which is a cost as well. This also needs to be 
fully considered by the team as part of the requirement gathering.

We just got Release-monitoring integration in Pagure, how would that be 
implemented in a new forge? What man-hours are you ready to commit to this new 
forge that can't equally be equally be committed to Pagure? At least with 
Pagure, we have people who know the codebase, would it be that easy to do 
custom integration with Git{hub,lab}?

GitHub is also, as far as I know, not free; wouldn't that be in contradiction 
with Fedora mission-statement to use it over a free alternative?

Best regards,

Robert-André

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

Re: Git Forge Requirements: Please see the Community Blog

[John M. Harris Jr]

On Tuesday, January 21, 2020 2:04:33 PM MST Neal Gompa wrote:
> Aside from GitLab being very anti-integration

This is no longer the case, by the way. GitLab has recently made it easier to 
add plugins, with the new method not requiring patching the source tree.

Even before that change, webhook integrations + API calls were fairly powerful 
in GitLab.

-- 
John M. Harris, Jr.
Splentity

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

Re: Git Forge Requirements: Please see the Community Blog

[Alex Scheel]

I had replied to Fabio on IRC but... :-)

- Original Message -
> From: "Guido Aulisi" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Tuesday, January 21, 2020 3:48:31 PM
> Subject: Re: Git Forge Requirements: Please see the Community Blog
> 
> 
> 
> > Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini
> >  ha scritto:
> > 
> > On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  > <mailto:lgrif...@redhat.com>> wrote:
> >> 
> >> Hey Everyone,
> >> 
> >> On behalf of the CPE team I want to draw the communities attention to a
> >> recent blog post which you may be impacted by:
> >> https://communityblog.fedoraproject.org/git-forge-requirements/
> >> <https://communityblog.fedoraproject.org/git-forge-requirements/>
> >> 
> >> We will be seeking input and requirements in an open and transparent
> >> manner on the future of a git forge solution which will be run by the CPE
> >> team on behalf of the Fedora Community. This mail is being sent to the
> >> devel, mindshare and council-discuss lists for maximum visibility on a
> >> BCC to allow each list have their own views. Please forward it to any
> >> other list you may feel is relevant to maximise the exposure.
> >> 
> >> Thanks in advance,
> >> Leigh
> > 
> > Alright, I have some questions that are not answered by the blog post.
> > 
> > - What is going to happen to the two pagure instances at pagure.io
> > <http://pagure.io/>,
> > and src.fedoraproject.org <http://src.fedoraproject.org/>?
> > 
> > I think pagure.io <http://pagure.io/> is a good home for fedora-related
> > projects (it was
> > the successor to fedorahosted.org <http://fedorahosted.org/>, after all,
> > IIRC). I know that many
> > group efforts are hosting their source code, ticketing system, etc.
> > there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> > shut down pagure.io <http://pagure.io/>, I assume those projects will have
> > to be moved
> > somewhere?
> +1
> 
> > Also, it's very nice to have a PR-based workflow for some
> > shared-maintenance packages on src.fedoraproject.org
> > <http://src.fedoraproject.org/>, and I don't
> > think losing that feature would be a good thing for fedora.
> +1
> 
> > - How is GitHub considered to be an alternative here?
> +1 …and to my knowledge GitHub is closed source.
> 
> > I don't think (public or hosted) GitHub can do what is currently done
> > on src.fedoraproject.org <http://src.fedoraproject.org/>, can it?
> > I'd also not want to see fedora use a closed-source product for such a
> > core service ...
> > 
> > - Which features are missing from pagure, compared to the other forges?
> +1 It’s not clear reading the original POST
> 
> > For my purposes, I don't miss any feature on pagure.io <http://pagure.io/>
> > compared to my
> > repositories on github.com <http://github.com/>, and OTTOMH, I can't come
> > up with any
> > missing features, at all …
> +1

From a _development_ POV, there's a number of things missing for it being
the primary git forge for pagure.io (not arguing about src.fedoraproject.org
or packaging use cases -- but some of those will benefit by these as well):

 - Real full-text search across issues and PRs. No need to RTFM.
(
 For those not having RTFM'd, you use "content:" to do a
 full-text search in current Pagure. I've argued that it should
 behave like other forge's searches:
 https://pagure.io/pagure/issue/2505#comment-582516
)
 - A UI with a UX that makes sense.
   https://pagure.io/pagure/issue/4543
   https://pagure.io/pagure/issue/2193
   https://pagure.io/pagure/issue/42(duped: 343)
   https://pagure.io/pagure/issue/2167
   (and you could keep cherry-picking issues. There's a section of
opened ones with UI tags).
 - The above is a huge category and I think its worth restating
   some items:
- Search, search, search.
- Split diff
- Real line numbers in the diff
- Expanding context around the diff
  (Diff, diff, diff?)
- Workflow on reviewing PRs is sub-optimal compared to most
  other forges.
 - Pagure is often slower than GitLab for me. YMMV.
 - ...

For a period of time, IDM tried using Pagure for FreeIPA development.
They filed a huge number of issues. Now we host issues on Pagure, and
have moved development to GitHub. [*] I think we've mostly quit filing
bugs; the Pagure team has done a good job with the resources they've
been given, but they definitely need more resources to pull this off
to a high le

Re: Git Forge Requirements: Please see the Community Blog

[Fabio Valentini]

On Tue, Jan 21, 2020 at 10:02 PM Leigh Griffin  wrote:
>
>
>
> On Tue, Jan 21, 2020, 20:02 Fabio Valentini  wrote:
>>
>> On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin  wrote:
>> >
>> >
>> >
>> > On Tue, Jan 21, 2020, 17:17 Fabio Valentini  wrote:
>> >>
>> >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  wrote:
>> >> >
>> >> > Hey Everyone,
>> >> >
>> >> > On behalf of the CPE team I want to draw the communities attention to a 
>> >> > recent blog post which you may be impacted by:
>> >> >  https://communityblog.fedoraproject.org/git-forge-requirements/
>> >> >
>> >> > We will be seeking input and requirements in an open and transparent 
>> >> > manner on the future of a git forge solution which will be run by the 
>> >> > CPE team on behalf of the Fedora Community. This mail is being sent to 
>> >> > the devel, mindshare and council-discuss lists for maximum visibility 
>> >> > on a BCC to allow each list have their own views. Please forward it to 
>> >> > any other list you may feel is relevant to maximise the exposure.
>> >> >
>> >> > Thanks in advance,
>> >> > Leigh
>> >>
>> >> Alright, I have some questions that are not answered by the blog post.
>> >>
>> >> - What is going to happen to the two pagure instances at pagure.io,
>> >> and src.fedoraproject.org?
>> >>
>> >> I think pagure.io is a good home for fedora-related projects (it was
>> >> the successor to fedorahosted.org, after all, IIRC). I know that many
>> >> group efforts are hosting their source code, ticketing system, etc.
>> >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>> >> shut down pagure.io, I assume those projects will have to be moved
>> >> somewhere?
>>
>> (snip)
>>
>> > That scenario assumes a certain result and decision from the requirements 
>> > analysis so I genuinely have no answer here. Whatever choice we make, an 
>> > impact analysis would be needed in some shape or form. That (and our next 
>> > steps) will be done collaboratively in the open.
>>
>> I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
>> this is a language barrier issue ... but I'd hope that an impact
>> analysis of the different possibilities would be done *before* making
>> a decision, not after?
>>
>> I mean, whatever the "Git Forge Requirements" will be, we'd need to
>> know how any change will affect the projects and groups that are
>> currently using pagure ...

(...)

> Sorry I should have been more detailed on the steps, that's on me. So we have 
> a few steps in this process, first and foremost is this ODF document to 
> figure out what are the real requirements/ use cases / features of a git 
> forge. We gather and analyze that, combining the multiple stakeholder views 
> and have our requirements to base an analysis on. We then evaluate what 
> solution(s) meets the requirements and bring those solutions forward. We then 
> perform impact analysis on what each path might look like from multiple 
> perspectives which will include obvious costs from a time, money, resources 
> perspective of using a git forge. A decision can be made then in an informed 
> way as we know what we want to have, why we want it and what the cost may be. 
> We haven't fully defined the criteria for that analysis yet as the 
> requirements will no doubt throw up use cases and scenarios that we have to 
> factor in. So this is very much a call to arms to help inform us of how you 
> use a git forge and what your requirements are for one.
>
> Hope that clears it up and sorry for the lack of clarity.

Yes! Absolutely, thank you.
Is there a place where we can suggest such formal "requirements"? I
don't think either mailing list posts nor comments on the community
blog post are a good medium for that.

Fabio

>>
>> Fabio
>>
>> >>
>> >> Also, it's very nice to have a PR-based workflow for some
>> >> shared-maintenance packages on src.fedoraproject.org, and I don't
>> >> think losing that feature would be a good thing for fedora.
>> >>
>> >> - How is GitHub considered to be an alternative here?
>> >>
>> >> I don't think (public or hosted) GitHub can do what is currently done
>> >> on src.fedoraproject.org, can it?
>> >> I'd also not want to see fedora use a closed-source product for such a
>> >> core service ...
>> >>
>> >> - Which features are missing from pagure, compared to the other forges?
>> >>
>> >> For my purposes, I don't miss any feature on pagure.io compared to my
>> >> repositories on github.com, and OTTOMH, I can't come up with any
>> >> missing features, at all ...
>> >>
>> >>
>> >> TL;DR:
>> >> Can we please keep pagure? It already has the fedora-specific features
>> >> we need, and I don't mind a "slow" pace of development.
>> >> In my experience, it works really well, and I actually *like* to use
>> >> it (which is not true for GitLab ... which is slow and horrible)
>> >>
>> >> Fabio
>> >>
>> >> > --
>> >> >
>> >> > Leigh Griffin
>> >> >
>> >> > Engineering Manager
>> >> >
>> >> > Red Hat Waterford
>> >> >
>> >> > 

Re: Git Forge Requirements: Please see the Community Blog

[Neal Gompa]

On Tue, Jan 21, 2020 at 3:01 PM Fabio Valentini  wrote:
>
> On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin  wrote:
> >
> >
> >
> > On Tue, Jan 21, 2020, 17:17 Fabio Valentini  wrote:
> >>
> >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  wrote:
> >> >
> >> > Hey Everyone,
> >> >
> >> > On behalf of the CPE team I want to draw the communities attention to a 
> >> > recent blog post which you may be impacted by:
> >> >  https://communityblog.fedoraproject.org/git-forge-requirements/
> >> >
> >> > We will be seeking input and requirements in an open and transparent 
> >> > manner on the future of a git forge solution which will be run by the 
> >> > CPE team on behalf of the Fedora Community. This mail is being sent to 
> >> > the devel, mindshare and council-discuss lists for maximum visibility on 
> >> > a BCC to allow each list have their own views. Please forward it to any 
> >> > other list you may feel is relevant to maximise the exposure.
> >> >
> >> > Thanks in advance,
> >> > Leigh
> >>
> >> Alright, I have some questions that are not answered by the blog post.
> >>
> >> - What is going to happen to the two pagure instances at pagure.io,
> >> and src.fedoraproject.org?
> >>
> >> I think pagure.io is a good home for fedora-related projects (it was
> >> the successor to fedorahosted.org, after all, IIRC). I know that many
> >> group efforts are hosting their source code, ticketing system, etc.
> >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> >> shut down pagure.io, I assume those projects will have to be moved
> >> somewhere?
>
> (snip)
>
> > That scenario assumes a certain result and decision from the requirements 
> > analysis so I genuinely have no answer here. Whatever choice we make, an 
> > impact analysis would be needed in some shape or form. That (and our next 
> > steps) will be done collaboratively in the open.
>
> I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
> this is a language barrier issue ... but I'd hope that an impact
> analysis of the different possibilities would be done *before* making
> a decision, not after?
>
> I mean, whatever the "Git Forge Requirements" will be, we'd need to
> know how any change will affect the projects and groups that are
> currently using pagure ...
>

I think this is the CPE team's way of telling us that they want to
yank pingou from Pagure as part of $PINGOU_DAYJOB work. Otherwise,
this is grotesquely premature, given that the Pagure community is
slowly growing, and we have an increasing contributor base (slowly
growing, but it is growing).

As someone who has run GitHub Enterprise and is currently running
GitLab Enterprise for $MY_DAYJOB work, Pagure is loads easier to
manage and deal with. The "burden", as it were, is considerably lower.
The much saner rate of code churn also means that upgrading and
maintaining the system is much more manageable, which is why I
switched my personal Git server from GitLab CE to Pagure.

I suspect the features that they're thinking of are the trivial CI
setup stuff. Pagure has no equivalent to GitLab CI nor do we have a
service like Travis CI in place to support projects hosted there. We
do have CentOS CI, but because Jenkins is crap and requires the
Jenkins admins to approve projects, it's basically garbage for
self-service CI.

There's no reasonable chance we'd be able to migrate all our
integrations from Pagure to either GitHub or GitLab (self hosted or
otherwise). Aside from GitLab being very anti-integration and GitHub
increasingly going down the same path, the fundamental architecture of
our integrations is quite difficult to do with those two solutions
(message based on a broker). We have hacked around it for GitHub.com
with github2fedmsg, but it's not quite as expressive as the native
functionality Pagure provides is.

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.

Honestly, I think the only reason fixes and releases don't come more
frequently for Pagure is because there just aren't many people allowed
to merge and do things. And the CentOS CI frequently breaks. :(

If there's something I'd *love* to see replaced, it's the Jenkins
thing the CentOS Project runs. It's awful and provides a horrible user
and developer experience.


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Tue, Jan 21, 2020, 20:02 Fabio Valentini  wrote:

> On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin  wrote:
> >
> >
> >
> > On Tue, Jan 21, 2020, 17:17 Fabio Valentini 
> wrote:
> >>
> >> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin 
> wrote:
> >> >
> >> > Hey Everyone,
> >> >
> >> > On behalf of the CPE team I want to draw the communities attention to
> a recent blog post which you may be impacted by:
> >> >  https://communityblog.fedoraproject.org/git-forge-requirements/
> >> >
> >> > We will be seeking input and requirements in an open and transparent
> manner on the future of a git forge solution which will be run by the CPE
> team on behalf of the Fedora Community. This mail is being sent to the
> devel, mindshare and council-discuss lists for maximum visibility on a BCC
> to allow each list have their own views. Please forward it to any other
> list you may feel is relevant to maximise the exposure.
> >> >
> >> > Thanks in advance,
> >> > Leigh
> >>
> >> Alright, I have some questions that are not answered by the blog post.
> >>
> >> - What is going to happen to the two pagure instances at pagure.io,
> >> and src.fedoraproject.org?
> >>
> >> I think pagure.io is a good home for fedora-related projects (it was
> >> the successor to fedorahosted.org, after all, IIRC). I know that many
> >> group efforts are hosting their source code, ticketing system, etc.
> >> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> >> shut down pagure.io, I assume those projects will have to be moved
> >> somewhere?
>
> (snip)
>
> > That scenario assumes a certain result and decision from the
> requirements analysis so I genuinely have no answer here. Whatever choice
> we make, an impact analysis would be needed in some shape or form. That
> (and our next steps) will be done collaboratively in the open.
>
> I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
> this is a language barrier issue ... but I'd hope that an impact
> analysis of the different possibilities would be done *before* making
> a decision, not after?
>
> I mean, whatever the "Git Forge Requirements" will be, we'd need to
> know how any change will affect the projects and groups that are
> currently using pagure ...
>

Sorry I should have been more detailed on the steps, that's on me. So we
have a few steps in this process, first and foremost is this ODF document
to figure out what are the real requirements/ use cases / features of a git
forge. We gather and analyze that, combining the multiple stakeholder views
and have our requirements to base an analysis on. We then evaluate what
solution(s) meets the requirements and bring those solutions forward. We
then perform impact analysis on what each path might look like from
multiple perspectives which will include obvious costs from a time, money,
resources perspective of using a git forge. A decision can be made then in
an informed way as we know what we want to have, why we want it and what
the cost may be. We haven't fully defined the criteria for that analysis
yet as the requirements will no doubt throw up use cases and scenarios that
we have to factor in. So this is very much a call to arms to help inform us
of how you use a git forge and what your requirements are for one.

Hope that clears it up and sorry for the lack of clarity.

>
> Fabio
>
> >>
> >> Also, it's very nice to have a PR-based workflow for some
> >> shared-maintenance packages on src.fedoraproject.org, and I don't
> >> think losing that feature would be a good thing for fedora.
> >>
> >> - How is GitHub considered to be an alternative here?
> >>
> >> I don't think (public or hosted) GitHub can do what is currently done
> >> on src.fedoraproject.org, can it?
> >> I'd also not want to see fedora use a closed-source product for such a
> >> core service ...
> >>
> >> - Which features are missing from pagure, compared to the other forges?
> >>
> >> For my purposes, I don't miss any feature on pagure.io compared to my
> >> repositories on github.com, and OTTOMH, I can't come up with any
> >> missing features, at all ...
> >>
> >>
> >> TL;DR:
> >> Can we please keep pagure? It already has the fedora-specific features
> >> we need, and I don't mind a "slow" pace of development.
> >> In my experience, it works really well, and I actually *like* to use
> >> it (which is not true for GitLab ... which is slow and horrible)
> >>
> >> Fabio
> >>
> >> > --
> >> >
> >> > Leigh Griffin
> >> >
> >> > Engineering Manager
> >> >
> >> > Red Hat Waterford
> >> >
> >> > Communications House
> >> >
> >> > Cork Road, Waterford City
> >> >
> >> > lgrif...@redhat.com
> >> > M: +353877545162 IM: lgriffin
> >> >
> >> > @redhatjobs   redhatjobs @redhatjobs
> >> > ___
> >> > devel mailing list -- devel@lists.fedoraproject.org
> >> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> > Fedora Code of Conduct:
> 

Re: Git Forge Requirements: Please see the Community Blog

[Guido Aulisi]

> Il giorno 21 gen 2020, alle ore 18:15, Fabio Valentini  
> ha scritto:
> 
> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  > wrote:
>> 
>> Hey Everyone,
>> 
>> On behalf of the CPE team I want to draw the communities attention to a 
>> recent blog post which you may be impacted by:
>> https://communityblog.fedoraproject.org/git-forge-requirements/ 
>> 
>> 
>> We will be seeking input and requirements in an open and transparent manner 
>> on the future of a git forge solution which will be run by the CPE team on 
>> behalf of the Fedora Community. This mail is being sent to the devel, 
>> mindshare and council-discuss lists for maximum visibility on a BCC to allow 
>> each list have their own views. Please forward it to any other list you may 
>> feel is relevant to maximise the exposure.
>> 
>> Thanks in advance,
>> Leigh
> 
> Alright, I have some questions that are not answered by the blog post.
> 
> - What is going to happen to the two pagure instances at pagure.io 
> ,
> and src.fedoraproject.org ?
> 
> I think pagure.io  is a good home for fedora-related 
> projects (it was
> the successor to fedorahosted.org , after all, 
> IIRC). I know that many
> group efforts are hosting their source code, ticketing system, etc.
> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> shut down pagure.io , I assume those projects will have to 
> be moved
> somewhere?
+1

> Also, it's very nice to have a PR-based workflow for some
> shared-maintenance packages on src.fedoraproject.org 
> , and I don't
> think losing that feature would be a good thing for fedora.
+1

> - How is GitHub considered to be an alternative here?
+1 …and to my knowledge GitHub is closed source.

> I don't think (public or hosted) GitHub can do what is currently done
> on src.fedoraproject.org , can it?
> I'd also not want to see fedora use a closed-source product for such a
> core service ...
> 
> - Which features are missing from pagure, compared to the other forges?
+1 It’s not clear reading the original POST

> For my purposes, I don't miss any feature on pagure.io  
> compared to my
> repositories on github.com , and OTTOMH, I can't come up 
> with any
> missing features, at all …
+1

> 
> TL;DR:
> Can we please keep pagure? It already has the fedora-specific features
> we need, and I don't mind a "slow" pace of development.
> In my experience, it works really well, and I actually *like* to use
> it (which is not true for GitLab ... which is slow and horrible)
+1

> Fabio

I totally agree with Fabio, I can’t think of a single reason we should dismiss 
pagure.

Ciao
Guido
FAS: tartina___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Fabio Valentini]

On Tue, Jan 21, 2020 at 8:30 PM Leigh Griffin  wrote:
>
>
>
> On Tue, Jan 21, 2020, 17:17 Fabio Valentini  wrote:
>>
>> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  wrote:
>> >
>> > Hey Everyone,
>> >
>> > On behalf of the CPE team I want to draw the communities attention to a 
>> > recent blog post which you may be impacted by:
>> >  https://communityblog.fedoraproject.org/git-forge-requirements/
>> >
>> > We will be seeking input and requirements in an open and transparent 
>> > manner on the future of a git forge solution which will be run by the CPE 
>> > team on behalf of the Fedora Community. This mail is being sent to the 
>> > devel, mindshare and council-discuss lists for maximum visibility on a BCC 
>> > to allow each list have their own views. Please forward it to any other 
>> > list you may feel is relevant to maximise the exposure.
>> >
>> > Thanks in advance,
>> > Leigh
>>
>> Alright, I have some questions that are not answered by the blog post.
>>
>> - What is going to happen to the two pagure instances at pagure.io,
>> and src.fedoraproject.org?
>>
>> I think pagure.io is a good home for fedora-related projects (it was
>> the successor to fedorahosted.org, after all, IIRC). I know that many
>> group efforts are hosting their source code, ticketing system, etc.
>> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
>> shut down pagure.io, I assume those projects will have to be moved
>> somewhere?

(snip)

> That scenario assumes a certain result and decision from the requirements 
> analysis so I genuinely have no answer here. Whatever choice we make, an 
> impact analysis would be needed in some shape or form. That (and our next 
> steps) will be done collaboratively in the open.

I'm sorry, but I'm genuinely confused now. Maybe I'm tired, or maybe
this is a language barrier issue ... but I'd hope that an impact
analysis of the different possibilities would be done *before* making
a decision, not after?

I mean, whatever the "Git Forge Requirements" will be, we'd need to
know how any change will affect the projects and groups that are
currently using pagure ...

Fabio

>>
>> Also, it's very nice to have a PR-based workflow for some
>> shared-maintenance packages on src.fedoraproject.org, and I don't
>> think losing that feature would be a good thing for fedora.
>>
>> - How is GitHub considered to be an alternative here?
>>
>> I don't think (public or hosted) GitHub can do what is currently done
>> on src.fedoraproject.org, can it?
>> I'd also not want to see fedora use a closed-source product for such a
>> core service ...
>>
>> - Which features are missing from pagure, compared to the other forges?
>>
>> For my purposes, I don't miss any feature on pagure.io compared to my
>> repositories on github.com, and OTTOMH, I can't come up with any
>> missing features, at all ...
>>
>>
>> TL;DR:
>> Can we please keep pagure? It already has the fedora-specific features
>> we need, and I don't mind a "slow" pace of development.
>> In my experience, it works really well, and I actually *like* to use
>> it (which is not true for GitLab ... which is slow and horrible)
>>
>> Fabio
>>
>> > --
>> >
>> > Leigh Griffin
>> >
>> > Engineering Manager
>> >
>> > Red Hat Waterford
>> >
>> > Communications House
>> >
>> > Cork Road, Waterford City
>> >
>> > lgrif...@redhat.com
>> > M: +353877545162 IM: lgriffin
>> >
>> > @redhatjobs   redhatjobs @redhatjobs
>> > ___
>> > devel mailing list -- devel@lists.fedoraproject.org
>> > To unsubscribe send an email to devel-le...@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
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@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
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 

Re: Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

On Tue, Jan 21, 2020, 17:17 Fabio Valentini  wrote:

> On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  wrote:
> >
> > Hey Everyone,
> >
> > On behalf of the CPE team I want to draw the communities attention to a
> recent blog post which you may be impacted by:
> >  https://communityblog.fedoraproject.org/git-forge-requirements/
> >
> > We will be seeking input and requirements in an open and transparent
> manner on the future of a git forge solution which will be run by the CPE
> team on behalf of the Fedora Community. This mail is being sent to the
> devel, mindshare and council-discuss lists for maximum visibility on a BCC
> to allow each list have their own views. Please forward it to any other
> list you may feel is relevant to maximise the exposure.
> >
> > Thanks in advance,
> > Leigh
>
> Alright, I have some questions that are not answered by the blog post.
>
> - What is going to happen to the two pagure instances at pagure.io,
> and src.fedoraproject.org?
>
> I think pagure.io is a good home for fedora-related projects (it was
> the successor to fedorahosted.org, after all, IIRC). I know that many
> group efforts are hosting their source code, ticketing system, etc.
> there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
> shut down pagure.io, I assume those projects will have to be moved
> somewhere?
>

That scenario assumes a certain result and decision from the requirements
analysis so I genuinely have no answer here. Whatever choice we make, an
impact analysis would be needed in some shape or form. That (and our next
steps) will be done collaboratively in the open.

>
> Also, it's very nice to have a PR-based workflow for some
> shared-maintenance packages on src.fedoraproject.org, and I don't
> think losing that feature would be a good thing for fedora.
>
> - How is GitHub considered to be an alternative here?
>
> I don't think (public or hosted) GitHub can do what is currently done
> on src.fedoraproject.org, can it?
> I'd also not want to see fedora use a closed-source product for such a
> core service ...
>
> - Which features are missing from pagure, compared to the other forges?
>
> For my purposes, I don't miss any feature on pagure.io compared to my
> repositories on github.com, and OTTOMH, I can't come up with any
> missing features, at all ...
>
>
> TL;DR:
> Can we please keep pagure? It already has the fedora-specific features
> we need, and I don't mind a "slow" pace of development.
> In my experience, it works really well, and I actually *like* to use
> it (which is not true for GitLab ... which is slow and horrible)
>
> Fabio
>
> > --
> >
> > Leigh Griffin
> >
> > Engineering Manager
> >
> > Red Hat Waterford
> >
> > Communications House
> >
> > Cork Road, Waterford City
> >
> > lgrif...@redhat.com
> > M: +353877545162 IM: lgriffin
> >
> > @redhatjobs   redhatjobs @redhatjobs
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@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
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: Git Forge Requirements: Please see the Community Blog

[Fabio Valentini]

On Tue, Jan 21, 2020 at 5:40 PM Leigh Griffin  wrote:
>
> Hey Everyone,
>
> On behalf of the CPE team I want to draw the communities attention to a 
> recent blog post which you may be impacted by:
>  https://communityblog.fedoraproject.org/git-forge-requirements/
>
> We will be seeking input and requirements in an open and transparent manner 
> on the future of a git forge solution which will be run by the CPE team on 
> behalf of the Fedora Community. This mail is being sent to the devel, 
> mindshare and council-discuss lists for maximum visibility on a BCC to allow 
> each list have their own views. Please forward it to any other list you may 
> feel is relevant to maximise the exposure.
>
> Thanks in advance,
> Leigh

Alright, I have some questions that are not answered by the blog post.

- What is going to happen to the two pagure instances at pagure.io,
and src.fedoraproject.org?

I think pagure.io is a good home for fedora-related projects (it was
the successor to fedorahosted.org, after all, IIRC). I know that many
group efforts are hosting their source code, ticketing system, etc.
there (Go SIG, Stewardship SIG, FPC, FESCo, etc.). If it is decided to
shut down pagure.io, I assume those projects will have to be moved
somewhere?

Also, it's very nice to have a PR-based workflow for some
shared-maintenance packages on src.fedoraproject.org, and I don't
think losing that feature would be a good thing for fedora.

- How is GitHub considered to be an alternative here?

I don't think (public or hosted) GitHub can do what is currently done
on src.fedoraproject.org, can it?
I'd also not want to see fedora use a closed-source product for such a
core service ...

- Which features are missing from pagure, compared to the other forges?

For my purposes, I don't miss any feature on pagure.io compared to my
repositories on github.com, and OTTOMH, I can't come up with any
missing features, at all ...


TL;DR:
Can we please keep pagure? It already has the fedora-specific features
we need, and I don't mind a "slow" pace of development.
In my experience, it works really well, and I actually *like* to use
it (which is not true for GitLab ... which is slow and horrible)

Fabio

> --
>
> Leigh Griffin
>
> Engineering Manager
>
> Red Hat Waterford
>
> Communications House
>
> Cork Road, Waterford City
>
> lgrif...@redhat.com
> M: +353877545162 IM: lgriffin
>
> @redhatjobs   redhatjobs @redhatjobs
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Git Forge Requirements: Please see the Community Blog

[Leigh Griffin]

Hey Everyone,

On behalf of the CPE team I want to draw the communities attention to a
recent blog post which you may be impacted by:
 https://communityblog.fedoraproject.org/git-forge-requirements/

We will be seeking input and requirements in an open and transparent manner
on the future of a git forge solution which will be run by the CPE team on
behalf of the Fedora Community. This mail is being sent to the devel,
mindshare and council-discuss lists for maximum visibility on a BCC to
allow each list have their own views. Please forward it to any other list
you may feel is relevant to maximise the exposure.

Thanks in advance,
Leigh

-- 

Leigh Griffin

Engineering Manager

Red Hat Waterford 

Communications House

Cork Road, Waterford City

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


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