After a few false starts it looks like we have per patch testing working
on VDSM, oVirt-engine, oVirt-engine-sdk and oVirt-engine-cli. There are
3 status a patch can get. 1) Success - Means the patch ran though the
tests without issue. 2) Failure - Means the tests failed. 3) Aborted -
Generally means the submitter is not in the whitelist and the tests were
never run. If you have any questions please feel free to ask.
I have a question:
I submitted a patch upstream and got '-1' from jenkins because of test failures.
I suspect that the failures aren't related to my patch, maybe the build wasn't stable
or it's simply a bug.
I'd like to have an option to tell jenkins to try again. I understand that this option is
called 're-trigger'. However I do not have this option in jenkins, perhaps due to lacking
How do you suggest I handle this?
Warning: This email is long, but important.
I've been working on a new website design for oVirt, and gave folks a
preview during yesterday's weekly status IRC meeting.
The website mockup is at:
(This is simply a static PNG exported from Inkscape, wrapped in a very
simple HTML page. Therefore, don't expect it to scale with your browser,
have selectable text, etc.)
The mockup has many different sections and updates, and I will explain
each change, as well as the thought process that went into each, below.
There are two main things to remember about this design:
1) It's a bunch of individual changes that work together.
2) It's a work in progress.
Also, the mockup was designed with our target audience in mind:
administrators (setting up and running the software), enthusiasts (who
may run instances at home), and programmers (tinkering with and
contributing back to the project), all with experience using Linux or
some form of UNIX. It is also important to note that our audience is
specifically _not_ casual desktop users (although they could benefit
from someone setting up and maintaining oVirt for them).
I'm eager to hear feedback on any and all changes, and work with you to
When you do provide feedback, and want to discuss more than one point,
please limit each email to one aspect of the site at a time. If you'd
like to talk about the logo and the site structure, for instance, please
send one email specifically talking about the logo, and then another
discussing the structure. This should make conversations easier for
everyone to follow and make it easier for me to track requested updates.
== Detailed changes ==
= Logo =
The oVirt logo is actually quite similar. I altered the "o" glyph, to
make it more aesthetically pleasing.
Comparison graphic between current and new (in simple greyscale, to make
it easy to see the difference):
= Color =
oVirt.org, right now, uses a green color throughout the site. The oVirt
administration UI also features green in its header. As a result, I've
pulled in that green and used it as the primary accent color for the new
(It also has the advantage that it is not blue, which is overused for
iconography, on the Internet, and for software in general.)
= Style =
Based on the typeface of our logo and our highlight color, our new style
reflects simplicity, openness, vibrancy, and elegance.
We can make this style work for both the WordPress and Wiki parts of the
= Site structure =
A revised site structure is hinted at in the front page mockup. You can
see this reflected in the top navigation. I did some overall
categorization, strongly influenced by Dave Neary's pre-existing work on
You can see a proposed sitemap here:
This is a general grouping of types of content, not necessarily a view
of the top-level page, or of sub-pages. In some cases, these items would
be sub-level pages, in others, they would be part of the navigation page.
The documentation page would highlight the best documentation available,
regardless of format - e.g. wiki, blog posts, etc. - and also have a
prominent link to the wiki. Other sub-pages may also link to the wiki,
if there is pertinent information (such as live docs for developers,
linked to from the develop section).
= Tagline =
This is a short, catchy phrase to indicate what the project is all
about. Since the target of oVirt is running on a server, most likely in
a datacenter, and it's open source, I figured we should make this prominent.
Usually taglines are simple and direct, and often have some sort of play
on words. "Open your virtual datacenter" can be interpreted in a few ways:
1) You can use oVirt to start (open up) a datacenter with virtualization
2) Take your existing datacenter and virtualize it
3) Use oVirt as an open source solution to manage your datacenter
= Supporting lead-in text =
It's important to start with some powerful explanatory text to state the
overall goal of the project. Usually, this ranges from a phrase to
around a sentence or two.
I wanted to express the purpose of the oVirt software in a very
high-level view, as a hook to get people interested to read more.
= Call to action =
"Start using oVirt now »" is a call-to-action button. After the simple
text explaining what oVirt is, it's important to provide an obvious next
After clicking the button, it would take the viewer to another page
where it provides a quick and simple way to start using oVirt.
Naturally, one would have to download oVirt to use it, so it should be
super-easy to do on this page. The page should also start a simple
step-by-step guide on getting oVirt working on one's own system(s).
I'm thinking that this may be, perhaps, simply a link to the "Download &
Use" section. Yes, it's in the navigation, but it does provide a very
important and clear next step, which helps with a natural-feeling
progression for an interested viewer of oVirt.org.
(BTW: If the simple guide is too complex, then we need to work at
further simplifying the process of setting up oVirt. It's important to
try to lower the barrier to entry. Part of this is making sure that
oVirt can run on one machine as well, and possibly booting from live USB
media for first-time evaluation purposes.)
= Front-page sections =
Most of text on the mockup is, in some way, based on content from the
current oVirt.org website — it's just edited a bit.
While most everyone appreciates a clean aesthetic, our primary target
group *also* likes to get to the point and see the information right up
front. The mockup of the front page that I'm presenting is based on this
In addition to being an overview of the project and the software it
produces, it also makes it really easy to explore from the content areas
to relevant other parts of the website. By bringing the top-level
navigation into the context of the overviews, we make it easier for
someone to jump to other sections, instead of having to scroll back up
to rely on the navigation.
The order of the front-page sections is important too. A goal with this
design was to:
1) Introduce people to oVirt, with a simple explanation
2) Let people know right upfront that it's an active project (release
3) Detail some of the most important features
4) Make it clear that it's a community project
5) Provide timely news & a way to easily get more info
6) Publish information on upcoming oVirt-related events (currently, in the
mockup, there's filler text for the time being)
Items #5 & #6 should both have a way to subscribe so that someone could
access this information without visiting oVirt.org. Twitter solves the
news component for us; we have to make sure the calendar is able to be
subscribed to as well.
Thanks for reading all of this! I'm looking forward to all
conversations, especially if it's constructive (regardless of a
positive, negative, or neutral slant).
I did not want to make the tree dirty so I am not sure what the cause.
Refer to .
You notice build failure for patchset 4, while patchset 4 is good. The error belongs to patchset 2.
It seems that after rebase from gerrit the jenkins fails to fetch the correct sources? Or it builds different patchset and report the error always at last?
This happens in several changes.