Burning an iso file with gnome is really confusing even for a technical user:
1. i insert a blank
2. i right click on an iso in nautilus and choose burn to cd/dvd
-> so far so good
3. i get a new window stating how much free space the blank has (but
in reality it already substracted the space beeing used by the iso you
want to burn)
-> this leaves the impression that the cd/dvd isnt really a blank
because it doesent tell you that it is the free space _after_ the burn
4. after burning if device polling is disabled (a typical setting for
laptops if you want to save power) it will tell you "burning failed"
while the burning itsself didnt fail at all, all that fails is
actually to poll the device...
there is lots to do on the usability front... like e.g. trying the stuff out ;)
p.s. this is not a problem for me but for other potential users with
less technical understanding
Is any one interested in the following packages:
glade3 -- User Interface Designer for GTK+ and GNOME
ldtp -- Desktop testing framework
pida -- A Python IDE written in Python and GTK
One reason that life is complex is that it has a real part and an
-- Andrew Koenig
Hi, everyone. Since the big PackageKit brouhaha surrounding Fedora 12,
there's been a discussion surrounding the need for a policy about
privilege escalation in Fedora. Representing the QA group, we would like
for there to be such a policy in order to allow a meaningful review of
privilege escalation issues as part of QA's testing of Fedora releases.
I took this concern to FESco, who basically said they would be willing
to consider any policy that's brought to them, but won't initiate the
creation of one. I have asked the security list (which seems mostly
dormant), some security folks individually, and it's been discussed on
this list, but none of those seem to have been interested in actually
creating a policy. So in the end, QA decided we would propose a draft.
We realize this is entirely out of our area of expertise, but there
appeared to be no alternative. So, here's a draft policy for review.
This has been through three rounds of drafts within the QA group, and
includes content based on very useful feedback from members of Red Hat's
security team, particularly Miloslav Trmac. Thanks to him and to all
others who contributed to the QA group discussion.
Please do provide any and all feedback on the proposed policy. if we can
get it into a shape which most people on the list would find acceptable,
my next step will be to take it back to FESco for them to review.
You can find the draft policy at
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
A friendly reminder that yesterday, January 26, 2010, we reached the
Feature and Spin submission deadline. Any new features or spins
submitted after yesterday will be targeted for Fedora 14.
A summary of the Fedora 13 milestones and exception process is here:
The next significant schedule milestone is Feature Freeze on February 9,
2010. At Feature Freeze it is expected that all features are
*significantly* "feature complete" and ready for testing.
Features which are not significantly feature complete at Feature Freeze
will be reviewed on an exception basis by FESCo or deferred to Fedora 14.
p.s. If you have questions about our release processes or milestones
please reply to this email or contact me directly and I will be glad to
devel-announce mailing list
I just committed and build gstreamer-plugins-bad-free to rawhide. This
package contains the -bad plugins shippable by Fedora.
If you maintain a version of gst-plugins-bad for a 3rd party repository,
or have a package that depends on either:
- gstreamer-plugins-good's farsight plugins
You should update your package to require gstreamer-plugins-bad-free