holland-coredev team mailing list archive

[Andrew Garner <muzazzi@xxxxxxxxx>]

On Fri, Aug 3, 2012 at 1:20 PM, BJ Dierkes <wdierkes@xxxxxxxxxxxxxxxxxxx> wrote:
> I've created holland@xxxxxxxxxxxxx …  send an email to it to subscribe.  Note that, after you confirm your subscription, your first email will be sent to the list…
>
> Addiitonally, we have a 'holland-build' list for Jenkins builds, and what not.  Was thinking this should maybe be expanded to be used for a) bug/issue notifications, b) continuous integration (failed/recovered jenkins tests), etc.  Any thoughts on what we should name this list?  Basically, 'holland' list is for discussion…  end-user support, etc.  But for bug notifications, etc…  should this just be 'holland-coredev' or just 'holland-dev'?

I think holland-dev is fine.  I don't think we necessarily need
separate lists for the automated notifications and development
communication for now, given the low traffic and I agree we can split
this out later.   However, I do think having at least two mailing
lists so we can split out the automated notifications from normal list
discussions would be useful - even if we merge dev/user lists
together.

> Finally, I've been using Travis-CI for all my projects and think we should consider moving off of Jenkins and onto Travis?  Anyone have any issues with that?

Offhand, this looks like travis doesn't support non-ubuntu
distributions?  Ideally if we test our python code cleanly in ubuntu
we should run fine elsewhere, but in practice that has not always been
the case. I like being able to spin up specific slave servers with
Jenkins and run in a distribution specific environment.  It's easy for
python2.7isms (or even python > 2.4 isms) to sneak in and cause
problems for older environments that could otherwise be caught by
simple unit tests.  I am also wary of how well it would support our
more esoteric system test cases like LVM which creates some volumes
and makes sure the lvm api code works - this generally requires
special access.

Some of those test cases could be reenvisioned in other ways - they're
way beyond being unit tests at this point, which is unfortunate.  I am
also very tempted to standardize the next major holland release on
python2.6+ (rather than the current ~py2.3+backports) since 2.6 is
readily available on even RHEL5 these days and context managers (and
other 2.6 functionality) wildly simplifies much of the holland error
handling.  In that case, just using Travis/ubuntu/py2.6+ may not be
such a big issue.  It's probably easier to get non-trivial
contributions for python2.6 projects as well.