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