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.