On 05/25/2015 02:55 PM, Hugh O. Brock wrote:
Seems like the midstream repos are causing us a lot of pain with
little
gain, at least in some cases. (For example it appears the t-h-t
midstream exists to carry a single patch that enables mongodb on
Centos.) Is it worth discussing whether we can eliminate some of these,
especially for upstreams like t-h-t that aren't tightly tied to the
OpenStack release schedule?
I have to bring one more thing here: the way we handle patches is
error-prone and opaque. `git push -f` is rarely a good way to solve
problems. It's easy to forget a patch on rebase, it requires explicit
coordination between people doing rebases, it does not (by default)
provide history of changes to patch series, it's hard to revert to
previous rebase if you forget to tag it. Delorean can also be confused
with multi-patch rebase.
Can we consider some specialized solution for handling patch stacks?
I've heard Rackspace is using Ply [1], looks nice at first glance. It's
idea is to store patch series in a separate repo - which looks like what
we want. So we can use our fork only for mgt-* branch and have all
patches tracked outside. Then we (maybe) could even use gerrit for
patches (which I don't like but some people dream of)!
[1]
https://github.com/rconradharris/ply
/me ducks flying bricks
--Hugh