Open Stack

On 07/03/2012 04:23 PM, Gabriel Hurley wrote:
> Agreed on all points, and I know you're not evil, Monty. ;-)
> (mostly)

Dammit. I'm going to HAVE to try harder... see my other post about
Bulgarian bars with freezers...

> You're totally right that this particular case won't stymie new
> contributors, but as we've seen for changes to common--and sometimes
> even to the client libraries or devstack--reviewers are in short
> supply and getting the change you need in one of the "gate" projects
> merged can often add days of impedance to otherwise fruitful work.
> It's bitten me plenty of times.

Yes. It's super hard and frustrating- especially as someone who rarely
makes patches to the projects themselves UNLESS it's something happening
through openstack-common ... or something that just broke between
devstack and our infrastructure.

> So the need for balance is critical. Being able to vet the impact of
> a change on every project consuming it is difficult for either
> automated systems or human reviewers, so we do our best.
> 
> Perhaps the simplest answer for now is devising a reasonable set of
> automated gate tests for this "os-requires " module that humans can
> trust, and working to expand the circle of reviewers on these
> centralized projects that have the power to block everyone yet are so
> easy to ignore...

TOTALLY agree - especially on expanding the circle of reviewers.

> All the best,
> 
> - Gabriel
> 
>> -----Original Message----- From: Monty Taylor
>> [mailto:mordred at inaugust.com] Sent: Tuesday, July 03, 2012 12:49
>> PM To: Gabriel Hurley Cc: Eric Windisch;
>> openstack at lists.launchpad.net Subject: Re: [Openstack] Single
>> global dependency list
>> 
>> It's a good and valid question and I don't really know. In this
>> case, I'm merely the pack-horse who was told "global synchronized
>> dependencies lists!" (not that I'm not the evil person cooking up
>> schemes)
>> 
>> That said - most patches from new contributors don't actually come
>> with new library dependencies. If they are adding a new depend, I
>> think it's reasonable to expect it to be slightly harder to get
>> that landed.
>> 
>> I do think that we need an answer to "who approves changes to this
>> list". Getting stuff merged to openstack-common is often hard
>> because it's a smaller list of people who work on it. I'd hate to
>> see this be only PTLs. However, things like "let's upgrade webob"
>> seem to _actually_ need more eyes than it seems like at the time.
>> 
>> meh.
>> 
>> On 07/03/2012 03:12 PM, Gabriel Hurley wrote:
>>> So, I understand the rationales, and I think of those three
>>> options the one
>> chosen is the most reasonable. I'm gonna just come out and say I
>> hate this whole idea, but let's set this aside for a minute 'cuz I
>> have a genuine question:
>>> 
>>> What will the process be for merging changes to this requirements
>>> list?
>> Having yet another roadblock to getting your contribution merged is
>> a huge developer disincentive. We're really making it exceptionally
>> hard for new contributors, and frustrating even for the old hands.
>>> 
>>> So, with the goal of making the coordinated management of the
>>> projects
>> possible, what can we do to respect developers?
>>> 
>>> - Gabriel
>>> 
>>>> -----Original Message----- From: openstack-
>> bounces+gabriel.hurley=nebula.com at lists.launchpad.net
>>>> [mailto:openstack- 
>>>> bounces+gabriel.hurley=nebula.com at lists.launchpad.net] On
>>>> Behalf Of Monty Taylor Sent: Tuesday, July 03, 2012 7:54 AM To:
>>>> Eric Windisch Cc: openstack at lists.launchpad.net Subject: Re:
>>>> [Openstack] Single global dependency list
>>>> 
>>>> 
>>>> 
>>>> On 07/03/2012 10:09 AM, Eric Windisch wrote:
>>>>> I have to agree with others that copying files around is not
>>>>> ideal, and I can see the maintenance of this getting more
>>>>> involved as Nova becomes more coupled with common.
>>>>> 
>>>>>>> Additionally, we'd make the copy only copy in the
>>>>>>> versions from openstack-common for package that were
>>>>>>> already listed in the target project, so that we wouldn't
>>>>>>> add django to python-swiftclient, for instance.
>>>>> 
>>>>> This seems to be a reasonable argument against using git
>>>>> submodules, but I'm afraid we might be losing more than we're
>>>>> gaining here.
>>>>> 
>>>>> Just because python-swiftclient depends on openstack-common,
>>>>> and django-using code exists there, doesn't mean that django
>>>>> needs to be installed for python-swiftclient. We might do
>>>>> better to use git submodules and solve the dependency
>>>>> problem, than continuing down
>>>> this
>>>>> copy-everything path.
>>>> 
>>>> We're explicitly NOT doing a copy-everything path. That's the
>>>> whole
>> point..
>>>> We're only copying the needed depends from the master list.
>>>> 
>>>> git submodules actually make the problem worse, not better.
>>>> 
>>>>> Alternatively, speed up the movement from incubation to
>>>>> library.
>>>> 
>>>> Yeah - that's kind of the reason that bcwaldon was saying this 
>>>> shouldn't be in openstack-common. openstack-common wants to be
>>>> a library, and then we're back at not having an appropriate
>>>> place for the
>> master list.
>>>> 
>>>> Monty
>>>> 
>>>> _______________________________________________ Mailing list:
>>>> https://launchpad.net/~openstack Post to     :
>>>> openstack at lists.launchpad.net Unsubscribe :
>>>> https://launchpad.net/~openstack More help   :
>>>> https://help.launchpad.net/ListHelp
>>> 
>>> 
>>> 
>> 
> 
> 
>