Re: [Rdo-list] reconsidering midstream repos

On 05/25/2015 08:55 AM, Hugh O. Brock wrote: 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.