launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On Thu, Sep 6, 2012 at 9:16 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> 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.

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