[core-workflow] Pagure and Fedora

[Maciej Szulik]

On Fri, May 20, 2016 at 11:08 AM, Victor Stinner
<victor.stinner at gmail.com> wrote:
> Hi,
>
> I just read a very interesting article about a new forge, Pagure:
> "Pagure and Fedora"
>
>    https://lwn.net/SubscriberLink/687821/ddb9fc2c985a606a/
>
> Pagure looks like a clone of GitHub implemented in Python (!) (Python
> 2 only yet, oooooh, but a Python 3 port is ongoing) and storing all
> data in Git! Excellent. Data: code, documentation, tickets, pull
> requests, etc. Just everything.
>
>    https://pagure.io/pagure
>
> The main difference with GitHub is that you can more easily extract
> data to move to a new forge later. I also understand that it's free to
> host your own server, since Pagure is a libre (free) software (GitHub
> requires a license, no?).
>
> As written in the article, the GitHub still has a major advantage: its
> "network" (its community).
>
> I also shared the article because I read another very interesting
> article about Gerrit. Mike Bayer writes that Gerrit reviews are as
> much importants as changes themself. IMHO he's right, the information
> of reviews are very important and we should take to keep... especially
> if tomorrow we move to another forge ;-)
> http://techspot.zzzeek.org/2016/04/21/gerrit-is-awesome/
>
> It looks like we are going to loose all Rietveld reviews when moving
> to GitHub. What if we move to Pagure tomorrow? :-p
>
> The CPython move to GitHub seems to have started. It looks like Pagure
> is still young, and GitHub has many advantages, but well, I wanted to
> share this project with you ;-)
>
> Note: GitHub was down a few minutes this morning ;-)
>
>    https://status.github.com/
>

Victor I'm positive Brett will "hug" you a lot during language summit
when talking about
GitHub migration. Anyway, as you've mentioned one of the biggest
advantages gh has
over its competitors is its popularity which greatly opens the gates
to new contributors.
Personally I'd prefer we focus on improving the workflow on top of gh
to be as much
automated as possible. Here I'm talking about something similar we
already have for
OpenShift or Kubernetes where one of the core contributors can either
ask the bot to
test the PR (part of the tests or full suite) and then mark it for
merge. Additionally,
since we will still keep b.p.o around for issues we need to make the
connection between
it and gh as automatic as possible (including turning patches from
b.p.o into PRs).
The last one will be actually worked on by our GSoC student Anish Shah.

Having said that, once we have all of those pieces in place I don't
see any problem
with yet another migration to eg. pagure, although I'm pretty sure
you'll need to find
a volunteer, who will be able to spent ton of time to do the
migration. Like currently
Brett is doing, for which he deserves eternal gratefulness :)

Maciej

PS. Every service, even the best one has its down time ;)