testtools-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

On 28 August 2013 03:46, Jonathan Lange <jml@xxxxxxxxx> wrote:

> Agreed. And Github's is not very good.
>
> Similarly, we've had occasional patches on Launchpad since the migration.
> Generally contributors have been more than happy to switch to Github, but
> it's a little bit of extra confusion.

Yup.

>>  - the github review/merge thing isn't all that good- it's not
>> terrible, but its neither LP nor gerrit/reviewboard
>
>
> I like it much more than Launchpad's code review system. I've not used
> gerrit or reviewboard.

You can play around on e.g. review.openstack.org quite easily, if you
want to get a feel for gerrit.

>>  - git itself is fine
>>  - we've had very slightly more driveby contributions than over a
>> similar timeframe on LP; but not enough to draw conclusions from.
>
>
> I'm not sure why we have data to draw conclusions on the other points.

I'm not sure we do :). I think we can draw conclusions on git by
virtue of using it enough. Driveby rates are hard because of many
confounding factors : and a low sample set.

>>  - the CI story is better than we had but still dissatisfying.
>
>
> Here are things I like about our current CI story, roughly in order:
>
>  1. I don't have to maintain it
>  2. It mostly works
>  3. It's not Jenkins (which I find ugly to look at, annoying to use and
> difficult to extend)
>
> We used to get lots of landings that passed with Python 2 but not with
> Python 3, or vice versa. My rough estimate is we've had those less since
> switching.

Yes, certainly something to not have turn up again.

>> I'm trying answer the questions 'should we move our other projects'
>> and 'should I move my related projects' to github.
>>
>> One thing I'd kind of like to do is spin up an openstack-infra setup
>> for testing-cabal:
>>  - gerrit as master
>>  - github as slave
>>  - zuul + jenkins doing testruns pre-and-for-landings
>>
>
> I don't know what zuul is, and nothing obvious turned up on page 1 of a
> Google search.

It's a scale-out cross-project test scheduler. E.g. we can cross-check
testtools vs subunit vs testrepository etc, so that we don't land
incompatible changes.

> Still track issues on Launchpad? If so, I don't see how this would prevent
> multiple issue trackers, as Github is still an issue tracker.

We might be able to turn off the github issue tracker entirely if we
don't use githubs code review thing (as they are coupled).

>> What do you guys think? Does that sound interesting? I have setup a
>> free rackspace account for the testing cabal...
>
>
> Mostly I've been trying to reduce my operational load, not increase it: I'm
> tired of logging into computers and being told I need to restart them. This
> proposal sounds like it would increase the load.

Thats true, it's not project-as-a-service stuff, at least not today anyhow.

> My priorities (not in order):
> - ease for new contributors

Ack.

> - low operational overhead for us

Ack, though I don't know if I can address the space of tests I need
for e.g. crcache in straight travis.

> - hard for us to break trunk
> - hard for us to break reverse dependencies (this has happened a fair bit)

Zuul will improve this.

> - easyish to spin off new projects

And this is straight forward too.

-Rob

-- 
Robert Collins <rbtcollins@xxxxxx>
Distinguished Technologist
HP Converged Cloud