Re: [Rdo-list] reconsidering midstream repos

On Mon, May 25, 2015 at 02:55:57PM +0200, 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? > > /me ducks flying bricks No flying bricks from me anyway :) I agree with what you're saying, but would like to agree on what we're actually meaning. I think it's great that pretty much exactly what we said would happen has happened: as Kilo nears completion, the patches that we're having to carry for RDO-Manager is approaching 0.

But before we say, let's kill the midstream repos...let's consider why we even have them to begin with. We didn't come up with the idea to fork a bunch of projects because it would make our *development* lives for RDO-Manager easier. In fact, it's exactly the opposite, they cause pain. So why do we have them? Quite simply it's because of the demand that we show, commit to, and support features in RDO-Manager prior to them necessarily merging in upstream OpenStack projects. If we can lift that requirement, we could likely do away with the midstream repos entirely. I know this is rdo-list, but in the spirit of being open, if we don't have midstream repos for RDO-Manager, then we shouldn't have them for OSP either, and we should only be committing to features as they land in upstream OpenStack. It doesn't make sense to me to drop the midstream repos for RDO-Manager, but then turn around and set them up privately for OSP. At least with them setup for RDO, we're doing the development of the management product in the open. In fact if we were to split like this, I think the pain would only intensify. It's pragmatic to say that anyone looking to productize OpenStack is going to have their own bug fixes/etc that they need, and maybe even some features. But setting up private forks as a general development principal to drive OpenStack based product development should be avoided at all costs. So yes, I'm +1 on dropping the midstream repos if they're no longer needed. But I'm -1 on then turning around and setting them up privately so that we can commit code to private forks because that code hasn't landed in upstream OpenStack yet. If we can agree that this isn't needed, then I think we can do without the midstream. Otherwise, if we're going to insist on forks to "land" features prior to them merging upstream, let's at least keep them public. There's a couple other facets to the discussion as well: The midstream repos is a place where we can preview where the management product is headed. For example, the Heat breakpoint work was available from the midstream repos much earlier than it ended up merging into Heat/heatclient. Some devs/users might find this sort of thing really useful, and could provide some early feedback for RDO-Manager. The midstream repos are also a place where we can quickly land reverts to unblock work. The Neutron regression that broke provisioning via Ironic this past cycle immediately comes to mind...it took a couple of weeks before the upstream revert even landed in Neutron. While that was broken, we carried the proposed revert in the midstream repos so that people could install a Neutron that actually worked for RDO-Manager. > > --Hugh > > -- > == Hugh Brock, hbrock(a)redhat.com == > == Senior Engineering Manager, Cloud Engineering == > == RDO Manager: Install, configure, and scale OpenStack == > == http://rdoproject.org == > > "I know that you believe you understand what you think I said, but I’m > not sure you realize that what you heard is not what I meant." > --Robert McCloskey > > _______________________________________________ > Rdo-list mailing list > Rdo-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/rdo-list > > To unsubscribe: rdo-list-unsubscribe(a)redhat.com -- -- James Slagle -- _______________________________________________ Rdo-list mailing list Rdo-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rdo-list To unsubscribe: rdo-list-unsubscribe(a)redhat.com