Seeing enough positive feedback on this (and seeing that after all, it
works pretty well on my machine), I started an official Fedora 17
feature. You can find it at
Comments of course welcome, before I move this on to be ready for
So in the recent proven tester discussion, and in various other threads,
I've oft stated that the limits of the current Bodhi karma system are a
significant problem, and the planned Bodhi 2.0 karma system has to
potentially to significantly improve our update testing process. But it
occurred to me that I haven't really laid out why in much detail, and
those who aren't as involved with the process as we in QA are might not
have a really clear vision of why this is so important.
So, I thought I'd lay it out in the form of a glorious vision of the
future! Note: I have zero UI design skills. This UI as described would
suck. But the idea is that there would be a decent UI which *represents
all the described choices*.
In the Great Bodhi Of The Future, for any given update, a tester will
not simply have a comment box and a drop-down for -1, 0 or +1. They will
* The list of test cases associated with the package, with a PASS / FAIL
choice for each
* Checkboxes for 'This update does / does not break critical path
functionality' (with a link out to the critpath definition)
* A checkbox for 'I installed this update and continued to use my system
as normal and did not note any regressions'
* Any custom choices the package maintainer opts to provide, via some
kind of interface to Bodhi
This is the kind of flexibility that would make karma massively more
useful. The tighter definition of what feedback actually *means*
provides far more information to the maintainer, and enables us to
automate certain outcomes much more aggressively.
For me, one the principal benefits of such a system would be that we
could make the 'This update breaks critical path functionality' checkbox
an absolutely red flashing light, wailing siren emergency button. I
mean, you hit that thing and trucks roll from Fedora HQ, metaphorically
speaking. It would have a confirmation page which clearly described the
impact of asserting that an update broke critpath, so we could be
confident that it didn't get falsely triggered very often. I'd suggest
1. Any update that is marked as 'critpath breaking' by a FAS-registered
tester would be blocked from going any further in the update process
without manual intervention (no autopushes at all)
2. Any update marked as 'critpath breaking' by a proven tester would be
blocked from being pushed stable at all - automatically or manually -
until the PT modified the feedback or it was overridden by someone with
appropriately godlike powers (TBD, but probably not just the maintainer)
3. Any update marked as 'critpath breaking' should probably get
announced on at least test-announce and/or devel-announce
4. Any update marked as 'critpath breaking' *after it has already been
pushed* would similarly trigger a major response: notify maintainer very
hard, notify lists, generally do stuff to make sure it gets immediate
We would also obviously be able to offer maintainers more nuanced
options for autopushing updates - require a certain number of passes on
a certain set of test cases, for instance.
To go a bit into the theory, the really nasty limitation of the current
system is we simply have very little easily consumable indication of
what the karma provided on an update *means*. A +1 can mean anything
from 'I booted and nothing exploded' to 'I tested every line of this
code, then did it backwards standing on my head'. A -1 can mean 'I
booted this update and then my cat got sick, I think there's a
connection!', 'this update breaks $REALLY OBSCURE FEATURE Z', or 'this
update exploded my monitor'. We just _don't know_. You can get the
information from comments, usually, but that's obviously a complete
non-starter for any kind of programmatized or automated action based on
the feedback. In particular, we currently can't do anything dramatic
based on negative feedback because of the uncertainty around exactly
what it means. We do have a few policies about when to file negative
feedback, but even this only very slightly mitigates the problem - we
can't say 'only file negative feedback if the update breaks critpath',
that's just not feasible. So we can't identify the 'really really
negative' feedback and respond appropriate drastically to it without
causing lots of pain through false positives (or rather, false
With a more advanced feedback system we can identify the really big
problems and be much more aggressive about handling them, without
over-reacting to smaller problems. We could, correspondingly, be a bit
less strict about how much *positive* feedback you need to push an
update, if we can be a bit more confident that we'll definitely identify
the really bad problems through negative feedback.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
If you haven't yet taken the time to vote in the current Fedora
elections, I encourage you to take the time to vote before the voting
period ends at the end of the day (UTC time) on December 5th. This
election cycle has elections for open positions on the Ambassadors
steering committee (FAmSCo), the Engineering steering committee
(FESCo), and the Fedora Board.
Please visit https://admin.fedoraproject.org/voting/ to vote. For
more information on the elections, refer to
Fedora Project Leader
devel-announce mailing list
-----BEGIN PGP SIGNED MESSAGE-----
I'm not very experienced in crosscompiling applications but as far as
I understand lazarus wiki page for that topic, lazarus is able to
compile i.e. windows binaries on linux.
I'm currently in a situation where this feature would be very helpful
because it gets boring and costs some time for me to start my windows
vm just for a new build of my applications. I've allready filed a
bug for making feodra's lazarus package able to compile windows
binaries but there isn't any reaction so far.
So can anyone give me a hint how I can compile my lazarus applications
for windows on my linux box without using a windows vm and why the
lazarus package seems to miss the neccessary files for doing this out
of the box?
Mit freundlichen Grüßen/Regards
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Just installing Fedora 16 on a new system. We set up a RAID1 with mdadm for /.
On boot, we're finding that if there is a RAID inconsistency, dracut
is waiting for mdadm reconstruction to complete before booting the
system. This means that after a power outage or other condition that
would cause a reconstruction to become necessary, we have to wait
several hours for the system to come online again.
My understanding is that this reconstruction is a background task, is
there really a need for this to hold up boot?
This behaviour comes from
0064-90mdraid-wait-for-md-devices-to-become-clean.patch in the
I've been creating rpm packages for Fermi Linux for over 10 years, and
Scientific Linux 8 years, but I never had time to do anything for Fedora
and EPEL. Now that I'm not with Scientific Linux, I've got the time.
I'd like to help with the OpenShift client packages for Fedora and EPEL.
So I'm going to sign up to be a co-maintainer for rubygem-rhc, and
rubygem-json-pure (a new dependancy for rhc).