There was a bug filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
At yesterday's F29 Go/No-Go meeting, we discussed the blocker status
of BZ #1628192 - Fedora 29 installation cannot see a firmware RAID
device. While the blocker criteria clearly states that this should be
a blocker for Beta, many of the people present at the meeting
disagreed, for a variety of reasons.
* Hardware supporting fwraid is considerably less pervasive than it
was when the criterion was written
* Testing this criterion can only be done with install media, which
limits our testing pool to the very dedicated members of Fedora QA.
Yes, anyone *can* download a nightly compose and try it, but in
practice this tends to be limited to the core testers. The majority of
testing that this feature will get will tend to happen as people try
out the Beta release.
To that end, I'd like to propose that we make the following change to
the criteria going forward:
"The blocking criterion for successful installation atop a firmware
RAID array is moved to the GA release criteria."
Phoronix recently release article about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
Best regards / S pozdravem,
DevConf.cz 2019 is the 11th annual, free, Red Hat sponsored community
conference for developers, admins, DevOps engineers, testers,
documentation writers and other contributors to Open Source Linux,
middleware, virtualization, storage, cloud and mobile technologies
where FLOSS communities sync, share, and hack on upstream projects
together in the beautiful city of Brno, Czech Republic.
The CfP is now open! Ready to submit your proposal? Submit at: devconf.info/cfp
Looking for ideas? Check out this year's primary themes at
- CfP closes: *October 26, 2018*
- Accepted speakers confirmation: *November 12, 2018*
- Event dates: Friday January 25 to Sunday January 27, 2019
Fedora Program Manager
Around the time DNF 3 landed in Rawhide (hence F29), we had quite a few
folks on these lists reporting issues, including crasher bugs. Many of
these seemed somehow related to the DNF history database. They also
were not easy to isolate and fix.
We're now close to the F29 Beta release, but we don't have a great
sense of how many people are still having these problems with DNF 3.2
Can anyone who is still struggling with DNF crashes on *basic*
operations on F29 or Rawhide please reply, and provide a few details on
what you're seeing and any workarounds or fixes you've found?
Thanks a lot!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
I'll orphan nitroshare. There are no dependencies except the subpackages.
Reasons for my decision: Upstream did no release since monthes and claims instable branch for master in the documentation.
There are some other good alternatives like KDE Connect or TotalCommander with WebDAV.