testtools-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxx>]

On Thu, Aug 29, 2013 at 7:00 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx>wrote:

> On 28 August 2013 03:46, Jonathan Lange <jml@xxxxxxxxx> wrote:
>
> >>  - 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.
>
>
I'll take a look.


> >>  - 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.
>
>
Agreed.


> >>  - 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.
>
>
On IRC, you mentioned that the testtools release process has been broken
for you for some time.

Beyond that, you haven't exactly said what about CI you find dissatisfying.
I don't suppose it matters much, since Jenkins is an arbitrary thing-doer,
and can therefore satisfy all needs.



> >> 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.
>
>
Got a URL?


> > 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).
>
>
I guess that's something that can be easily checked.


> >> What do you guys think? Does that sound interesting? I have setup a
> >> free rackspace account for the testing cabal...
> >
> >
>
>
On IRC, you've said that you're going to go ahead and experiment with
setting up our own stack, to get a sense of what the operational overheads
are.

In general, I'm in favour of uniting more testing-cabal stuff
(infrastructure, mailing lists, IRC channels, website, etc.). Having
separate, separately-releasable code bases is great, but I believe the
other forms of fragmentation make the projects look less active than they
are (which isn't terribly active!), and mask some of the great thinking
that's gone into them.

jml