launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Thu, Sep 6, 2012 at 9:03 AM, Gavin Panella
<gavin.panella@xxxxxxxxxxxxx> wrote:
> On 4 September 2012 07:22, Robert Collins <robert@xxxxxxxxxxxxx> 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