Open Stack

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