openstack team mailing list archive

[Gabriel Hurley <Gabriel.Hurley@xxxxxxxxxx>]

Agreed on all points, and I know you're not evil, Monty. ;-) (mostly)

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.

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

All the best,

    - Gabriel

> -----Original Message-----
> From: Monty Taylor [mailto:mordred@xxxxxxxxxxxx]
> Sent: Tuesday, July 03, 2012 12:49 PM
> To: Gabriel Hurley
> Cc: Eric Windisch; openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> >> [mailto:openstack-
> >> bounces+gabriel.hurley=nebula.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> >> Monty Taylor
> >> Sent: Tuesday, July 03, 2012 7:54 AM
> >> To: Eric Windisch
> >> Cc: openstack@xxxxxxxxxxxxxxxxxxx
> >> 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@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~openstack
> >> More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
>