= Attendees =
Ian Jackson (Citrix)
Lars Kurth (chair)
Aravind Gopalakrishnan (AMD)
= Status & Process of selecting vendor =
== Credative ==
Ian J and Konrad interviewed the technical staff of Credative : both seem to be confident that Credative can do the job
Ian J states that he knows some of the individuals working from Credative as he has worked with them in a similar capacity they perform for Debian. This means two things: Ian saw them operate and solve similar problems to ours for Debian, but also has
a conflict of interest which he wanted to declare
What we do not yet have is a commercial proposal
Lars pinged Oscar Herrera their business guy on next steps, as we do not yet have a detailed commercial proposal. But then we were both on vacation and things stalled until yestetday
ACTION: Lars to arrange a follow-up call for Friday or early next week
== TBNG Consulting ==
Lars sent work spec to TBNG. Waiting to get confirmation that they have capacity and arrange follow-up call/interviews
ACTION: Lars to ping again (done)
== Process ==
Ian and Aravind made clear that without proper maintenance we are running an increasing risk if we get a
Lars would prefer if we had two proposals. However would be happy to go with Credative, if
A) The price is correct
B) We can de-risk, e.g. start with a 2-3 months short term trial contract to scope out the work and deal with loose ends ands then re-evaluate and go for a longer term contract. This is what Credative have suggested also and would mean we are not stuck
with a supplier we can't work with them
C) If TBNG Consulting
It is crucial to keep the Mpmentum going, given that we lost it due to vacation days
ACTION: work with AB, Credative & Possibly TBNG towards closure before the next AB meeting
= Setting up a 3rd party OSSTEST infrastructure (Aravind) =
Aravind and his team are looking to set up OSSTEST for non-production HW
Ian: setting OSSTEST in stand-alone mode is a good start. Setting a production system is somewhat harder and may not be fully documented. Ian offered help and we discussed some conventions on how to best communicate. It is certainly possible to do this,
but there may be docs gaps.
1) Aravind to ask questions either via this list or xen-devel, but make sure to CC Ian
2) Consider joining #xendevel IRC channel for fast turn-around low latency questions
Aravind raised the issue that test failures show up as AMD64, but that these are sometimes Intel failures. Ian explains that this is due to Debian architecture names (see https://wiki.debian.org/DebianAMD64Faq).
We had a brief discussion whether there is an easy way to add architecture info to reports that would allow AMD mapping failures to their HW. Ian J states that this is possible, and offers to implement a solution, but would need to understand Aravind's needs
more. Agreed to discuss via e-mail
ACTION: Aravind to explain his use-case by email such that we can find a solution that works
|