On Thu, Apr 23, 2015 at 1:24 PM, Ryan S. Brown <ryansb(a)redhat.com> wrote:
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.
That sounds like a reasonable workflow to me, I wouldn't object to
this if others prefer it as well.
One thing I did want to mention is that with the GitHub model one way
to thwart out of date forks, the trend should be that their fork's
master/devel branch never be directly developed on but instead always
track upstream's master/devel and then just simple pull from remote.
Effectively:
git fetch upstream
git fetch upstream --tags
git merge upstream/master
git push origin master
git push origin --tags
Then all topic branches are branched of of origin's master, rebasing
as necessary. This is how the OpenShift upstream work is done as a
reference.
> 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.
I'm definitely not anti-gerrit, I've not used it personally but I've
heard good things. It appears to be written in Java and GWT, I'm not
sure that's overly important other than packaging Java stuff can at
times be painful. Thought I'd mention it for the consumption of the
group.
> 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.
+1 - I completely agree, I think integration into fedmsg is a must and
something I probably should have mentioned originally. Could probably
be accomplished with post-commit hooks, but implementation details can
be handled later.
> 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.
Absolutely, happy to :)
-AdamM
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
_______________________________________________
rel-eng mailing list
rel-eng(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/rel-eng