RFC: rel-eng tooling development workflow

[Ryan S. Brown]

On 04/23/2015 01:54 PM, Adam Miller wrote:
> Hello all,
>     It's recently become somewhat of a recurring theme in the
> #fedora-releng channel to discuss the Fedora rel-eng tooling
> development workflow, changes that would like to be seen, and
> decisions on tools/infra to deliver them. I thought I'd shoot out an
> email to the list to kick off the conversation in a more formal manner
> with an initial proposal for feedback.

First, thank you!

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

>     Secondly, it has been brought up that the Fedora Rel-Eng team at
> large does not want to use GitHub because it is non-free software and
> I'm on board with that.

+1 for staying as free (or Libre) as possible.

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

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.

> If there are others, or things I have left out please let me know.
> 
> OK, that's it! If you made it this far, I owe you a cookie or something.
> 
> Please provide feedback, questions, and general snide remarks.
> 
> Thank you,
> -AdamM

Thanks for getting the ball rolling on this.

-- 
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.