RFC: rel-eng tooling development workflow

[Pierre-Yves Chibon]

On Thu, Apr 23, 2015 at 02:24:28PM -0400, Ryan S. Brown wrote:
> On 04/23/2015 01:54 PM, Adam Miller wrote:
> > I'm personally a fan of what I'll simply refer to as "the GitHub
> > workflow" by virtue of it's rise in popularity but it boils down to
> > effectively this:
> > 
> >   1) Upstream project has a 'master' or 'devel' branch were dev happens
> >   2) Developers fork the repository
> >   3) Developers create "topic branches" (a branch for a specific dev
> > feature/fix)
> >   4) Developer then send a pull request to 'master' or 'devel' for code review
> >   5) Once reviewed and signed off on it is approved and merged
> > 
> > Now a couple things to note:
> >     First and foremost is that this is by no means the only workflow
> > but just one that has become increasingly popular that I'm a fan of.
> > However, I'm certainly open to other suggestions and opinions but for
> > the sake of my initial proposal and the rest of this email I'll be
> > continuing on with this workflow in mind.
> 
> My biggest gripe with the github model is the enormous number of
> out-of-date forks that end up existing. I prefer the gerrit model, which is:
> 
> 1) Upstream has a single repo with a master branch (or devel, I guess)
> 2) Developers clone the repository and file reviews with tools like
>    git-review that are each a self-contained change (topic branch)
> 3) review happens between contributors with gerrit or similar
> 4) code is merged
> 5) on some basis (time, feature sets, dice rolls) releases are tagged
>    from "stable/release" branches, and backports/fixes can be added to
>    those branches over time.

Pagure tries to address this issue by making the main project be at the top
level URL wise.
So project are displayed at: pagure.org/<project>
while forks are under: pagure.org/fork/<user>/<project>

The idea being to clearly show what is the project and what is a fork and see if
we can encourage clear contribution back into the main project (as opposed to
people forking, adjusting for their needs and never pushing it back upstream).


> > With that second note in mind, there are a decent handful of open
> > source solutions for this and of those there are two "front runners"
> > in my mind for our use since they are written in python and the Fedora
> > team at large has plenty of experience developing and
> > hosting/deploying/administering software written in python. They are:
> > 
> > - pagure (http://pagure.dev.fedoraproject.org/)
> >     This has been written by Fedora's very own pingou and it satisfies
> > all immediate requirements that I know of (including FAS account
> > integration) and would offer the ability for us to fine-tune it for
> > our needs since it's effectively been developed "in house" but we
> > could also work to make it more popular in the broader community so
> > see if others would like to join and help add even more features to
> > it.
> > 
> > - kallithea (https://kallithea-scm.org/)
> >     This project has been growing interest and to the best of my
> > knowledge is that it's slated towards being used officially by
> > upstream CPython developers at python.org, however some have mentioned
> > in #fedora-releng that there are missing features that we'd need/want
> > so this might require a bit of initial heavy lifting to add upstream.
> > (also no current support for FAS integration)
> 
> I've read about kallithea and it does look quite nice, I'd be curious
> what features it's missing as is (other than FAS, of course).

As far as I understood when I talked with Kallithea's upstream at pycon,
Kallithea is really aiming to support a pull-request workflow. So they do a
little code hosting and offer a way to make pull-request to the project.

On the other side, I see pagure as being a small alternative to trac. It has
code hosting, pull-request mechanism but also documentation hosting and an issue
tracker.
AFAIU, these are necessary elements Kallithea is interesting in having.

Pagure comes with a number of git hooks as well and easy way to add more. I do
not really know how Kallithea stands on this.

> I've never used either of the above suggestions, but I'd also throw
> Gerrit into the running because it has quite good review workflows, is
> used by other FOSS projects, and has lots of existing tooling.
> 
> > Alright, with all that said. I'd like to kind of round this back to a
> > set of requirements for the group in terms of the new workflow and
> > tooling:
> > 
> > I think everyone agrees that we need:
> > 1) Code Review
> > 2) Easy viewing/reference of code review history
> > 3) Accountability for 1 & 2
> 
> Making sure the project exposes event hooks (for CI, fedmsg, commit
> hooks, etc) will probably be an important factor in any tool we choose,
> but that's certainly lower priority than code review & easy
> browsing/searching.

Pagure has fedmsg and web-hook enabled and comes with some commit hooks and we
can add more.

Note: Pagure does not have a code search facility, is that something we would
want to look into?


Pierre