On Thu, Sep 6, 2012 at 9:16 AM, Robert Collins <robe...@robertcollins.net> wrote: > 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.
For clarity: I'm not playing 'guess what robert wants' here - I mean to say - I can see a way that I might take, and I imagine there are other ways that will also meet the constraints (+ also, challenging the constraints). I'm not throwing the way I might take up, because I don't know enough about what 'regular' upstreams do these days, I'd rather let folk that are fluent in the state of the art lead the discussion. -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
