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....@lists.launchpad.net >> [mailto:openstack- >> bounces+gabriel.hurley=nebula....@lists.launchpad.net] On Behalf Of >> Monty Taylor >> Sent: Tuesday, July 03, 2012 7:54 AM >> To: Eric Windisch >> Cc: openstack@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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp