On Thu, Sep 6, 2012 at 9:03 AM, Gavin Panella <gavin.pane...@canonical.com> wrote: > On 4 September 2012 07:22, Robert Collins <rob...@canonical.com> wrote: > ... >> I don't have a particular view on the specifics for achieving this, >> but I will note that we currently have achieved it. So, if we change, >> please: >> - change it across the board >> - don't break the sysadmin installation use cases. > > I expect that python-pgbouncer will only ever be installed as a > test-time dependency of something larger, e.g. Launchpad. Its buildout > environment is only used for development of python-pgbouncer, not in > its role as a dependency of Launchpad.
Sure. > Put another way, Launchpad has a buildout cache, for CI and > deployment, but python-pgbouncer on its own does not need one, unless > we want to build it in a net-limited environment, e.g. a landing bot > in the Canonical DC. Right, we want such a bot. > Many projects that we maintain that do not solely serve Launchpad's > purpose would be served better by *not* forcing a cache, keeping > things unsurprising for potential contributors, keeping them as > upstream projects. Individually, yes, but we also have the friction around landing (tarmac) and development patterns for the contributors. Which, btw, are vastly biased towards Cloud Engineering folk at the moment; you can argue that the setup overhead is an inhibitor of outside contribution. We have no real data on the number of outside contributors vs inside contributors. However, today, *only* outside contributors are surprised at the setup (because all our projects use the cache etc), so numerically, we maximise lack of surprise with a consistent approach. > It may be interesting to run these project's test suites with the > dependency versions that Launchpad imposes, which may differ from > those typically used when developing those projects independently. For > example, we might develop python-pgbouncer with a recent version of > testtools from PyPI, but as part of Launchpad it might run with an > older version. However, I don't think we should do this by forcing > python-pgbouncer to be in lock-step with Launchpad. I would like real data on the costs of difference here. But let me be clear - I am *keen* to see things change, I think we need to solve for the constraints I outlined though: you don't seem to think they are unreasonable, *except* for the 'not be different' bit, and for that - the data we do have supports being consistent over being different. I'm likely missing something though! So lets phrase it differently: how can we make /all/ our projects more like J Random Upstream Python Package without compromising the constraints I listed above? Note that I was very careful when I wrote them: I /want/ to enable change in this area, and AFAICT there are several avenues available, if someone steps up and does the work. -Rob _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
