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 for me:
#dev.SOFT.1: allow project maintainer to rebase pull requests. This
helps a lot both the PR author and the project maintainer, I love it, I
use it a lot and I would like to continue using it on my fedora related
contributions.
[1]: https://pagure.io/fedora-infrastructure/issue/7826
[2]: https://pagure.io/fedora-infrastructure/issue/7827
And that is for now.
Regards,
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
