[Rdo-list] reconsidering midstream repos

Jay Dobies jason.dobies at redhat.com
Tue May 26 19:23:15 UTC 2015


On 05/25/2015 08:55 AM, 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.)

It's not just a single patch for THT (in fact, I think that's one of the 
lesser examples of what you're getting at, whereas I don't think we've 
maintained a single Tuskar cherry pick for longer than a few days at 
most over the course of the release). At very least, there's another 
commit that's carried midstream that hasn't landed upstream to enable 
post deploy hooks for RHEL registration:

https://review.openstack.org/#/c/172065/

That was first submitted on April 9th and hasn't yet landed. I'm not 
saying there isn't a problem in the length of that turn around time 
(that's an entirely separate discussion), but since we were under a 
time-based deadline to deliver the Satellite integration, it was cherry 
picked midstream. You could even argue that the presence of the 
midstream repos allowed that patch to sit around in limbo since we 
cherry picked and kinda forgot about it, which would be a +1 against them.

You also can't really look at the situation today and the number of 
non-upstream commits and necessarily draw the conclusion that they 
aren't needed. Over the course of the past few sprints, the THT repo has 
carried more than one upstream cherry pick at a time. Arguably, it 
should be carrying the pacemaker and network stuff if they weren't split 
across so many different commits which made waiting on a rebase simpler 
(those are, however, interesting experience stories when considering the 
midstream repos).

Slagle put it really well when he describes why we added them in the 
first place. Our scrum approach hasn't played well with the upstream 
community and trying to juggle both concurrently has led to, well, to 
the midstream repos, among other things :) Hindsight and lessons learned 
and what not, but something we need to think about and correct for OSP 8.

This might be airing too much of our dirty laundry on rdo-list, but I 
think discussing the midstream repos is secondary to figuring out a 
better approach to our scrum, strongly time-based deliverables v. 
upstream. Once we pick a direction there, I think the question of if 
they are needed will be more clear.

> 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
>
> --Hugh
>




More information about the dev mailing list