NVIDIA Question
by David St.Clair
This may be a dumb question, but why can't Redhat distribute NVIDIA binary
drivers?
In NVIDIA's licence (http://www.nvidia.com/object/nv_swlicense.html) it
says:
"2.1.2 Linux Exception. Notwithstanding the foregoing terms of Section
2.1.1, SOFTWARE designed exclusively for use on the Linux operating system
may be
copied and redistributed, provided that the binary files thereof are not
modified in any
way (except for unzipping of compressed files)."
So, what's keeping RedHat from putting the drivers in the distribution? If
it's a GPL
thing, would it be easy to just download it during installation or at
least give the option to the user?
Thanks,
--
David St.Clair
dstclair(a)cs.wcu.edu
1 year, 10 months
Mouse goes crazy
by Jonathan Villa
Ok, I have had Yarrow working well for a while now, but yesterday I
started experiencing some odd issues with my mouse. All of a sudden it
stops working correctly. The only thing that seems to fix is to kill X
and run mouse-test, then restart.
Any ideas?
Also, I have FC 1 running on a desktop which is hooked up to a KVM
switch. Whenever I go to another PC, and return, the same thing
happens, the mouse goes crazy.
???
1 year, 10 months
[Fedora QA] #472: create testcase for resizing in custom partitioning
by fedora-badges
#472: create testcase for resizing in custom partitioning
------------------------+------------------------
Reporter: kparal | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 22
Component: Test cases | Version:
Keywords: | Blocked By:
Blocking: |
------------------------+------------------------
After discovering https://bugzilla.redhat.com/show_bug.cgi?id=1221247 it
seems reasonable we should test this more properly in the future.
Currently we seem to have no test case about resizing partitions in manual
part dialog. We probably should, and test it against at least a standard
partition and a logical volume. Optionally, we can split standard
partitions into ext4 and ntfs, to cover similar use cases as in our
QA:Testcase_partitioning_guided_shrink .
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/472>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 3 months
Non-image blocker process change proposal
by Adam Williamson
Hi, folks! It's been a recurring issue in the blocker review / release
validation process in recent times that we run across bugs that qualify
as blockers, but for which the fix does not need to be in the final
frozen media or install trees.
Common cases are bugs related to upgrading, especially since the
introduction of fedup and even more so of dnf-system-upgrade; most
upgrade-related issues can now be sufficiently fixed by package updates
to either the source or target release. Bugs to do with writing USB
media from the previous release, for instance, also often fall in this
category.
Up until now we've been sort of handwaving these as 'special blockers',
following the regular blocker process but noting in comments that they
don't block the compose. We haven't been tracking very hard if they
actually *are* being fixed with updates promptly, we've just been sort
of waving a magic wand and assuming it will happen. I just found one
which was supposed to be fixed with a 0-day update for Beta, but hadn't
been fixed yet: https://bugzilla.redhat.com/show_bug.cgi?id=1263230
So, we kinda need to do this better.
Up top I'd like to note there are really kind of two buckets of
'special blockers' for any given release. If the release being
validated is N, they are:
1) Bugs for which the fix must be in the 0-day update set for N
2) Bugs for which the fix must be stable in N-1 and N-2 by N release day
There will be a lot of process nerd detail involved in any fix, but
before any detailed drafts I'd like to suggest two broad possible
approaches and see what people think:
#1 Separate trackers
--------------------
As a sort of on-the-spot PoC for F23 Beta, I created a new tracker bug
for bucket 1: https://bugzilla.redhat.com/show_bug.cgi?id=1264167
We could formalize that approach, and have a '0-day' blocker tracker
for each milestone. We could either just have one '0-day' tracker and
throw bugs for both the pending release and previous stable releases on
the same tracker and keep track of what needs updating where in each
bug, or we could have two 0-day trackers for each milestone, one for
the pending release, and one for previous stable releases.
So we'd have something like:
F24AlphaBlocker
F24AlphaFreezeException
F24Alpha0Day
(F24AlphaStable) (? - better alias suggestions welcome)
and so on. This is a lot of bugs, but there is a script to create them,
so we're not adding a bunch of onerous work.
So far as proposing bugs goes, I think we'd probably want to extend the
current somewhat flexible approach; formally you would nominate a bug
as a particular type of blocker/FE (by marking it as blocking the
appropriate tracker), but we would move things around in blocker review
meetings sensibly, as we currently do (when something is nominated as
FE but should really be a blocker, or vice versa). In blocker review
we'd go through all bugs nominated for any of the trackers, probably
starting with 'Blocker', then '0Day' and 'Stable', then
'FreezeException'.
#2 MOAR METADATA
----------------
The alternative is to make the existing Blocker trackers do more work.
In this model we wouldn't add any new tracker bugs; we'd just add new
'magic words' in the Whiteboard field. Right now, an accepted blocker
is identified by the string 'AcceptedBlocker' appearing in the
whiteboard field. We could simply add some more magical strings like
that: 'Accepted0Day' and 'AcceptedStable', say (better suggestions
welcome).
I kind of like this idea as it's less change and involves creating
fewer new bugs. We'd have to make some changes to blockerbugs either
way - tflink can say if either approach would be more work in
blockerbugs, but I'm gonna guess they'd be fairly similar.
With either approach, the basic goal is to make it more feasible to
keep an eye on each of the different categories of 'release blocker'
bugs; right now we have solid processes in place for ensuring the
'normal' blockers are all addressed in the release media, but we don't
have any processes in place for ensuring 0Day and Stable bugs actually
get updates shipped when we say they must.
My suggestion would be that we make sure 'blockerbugs' includes lists
of each type of blocker. Ahead of and at Go/No-Go meetings, we would
want to have a formal assurance from the person responsible for fixing
the bug that the fix would be provided by a certain time - say, one day
or two days ahead of the release date - and it would be QA's
responsibility to ensure the updates are tested promptly, and releng's
responsibility to ensure they are pushed on time after being tested. I
would suggest the Program Manager ought to have overall responsibility
for keeping an eye on the 0Day and Stable blocker lists and making sure
the maintainer, QA, and releng all did their jobs on time.
It'd be great if folks could post their general thoughts on this, and
any preference for option 1 or option 2. Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7 years, 9 months
criterion proposal: upgrading across 2 releases
by Kamil Paral
Our current upgrade criterion says:
"For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed."
https://fedoraproject.org/wiki/Fedora_24_Beta_Release_Criteria#Upgrade_re...
Currently we have no criterion that would cover upgrading across 2 releases, e.g. from F21 to F23 (directly, not one by one). But in the real world this very often happens. It's even one of the reasons we support our releases until N+2 release is available + 1 month (i.e. F21 is supported until F23 is out + 1 month). The often cited reason is for people to be upgrading just once per year (and have one month to do that). And of course many (probably most) of them don't upgrade one by one, but skip a release.
I feel that for something as important as system upgrade, we should provide a better level of quality and assurance for upgrading across 2 releases. Currently we have no criterion and testing it is just an afterthought, not even tracked anywhere. I'd like to amend the existing criterion to include N-2 release as well, i.e.:
"For each one of the release-blocking package sets, it must be possible to successfully complete an upgrade from a fully updated installation of any of the two previous stable Fedora releases with that package set installed."
(language corrections very welcome)
We can discuss whether N+2 upgrading should be a separate Final criterion, not joined with the Beta one. I don't feel strongly either way.
I'd also set up a new test case in our installation matrix in the upgrade section:
https://fedoraproject.org/wiki/Template:Installation_test_matrix#Upgrade
Something like QA:Testcase_upgrade_dnf_skip_release. The question is whether to have just a single test case and let people choose which package set they test, or whether to pick some particular package set. We probably don't want to test all combinations, at least not manually. Just a single "please test something" test case would be satisfactory here, I think. Something will get tested, and we will block on important bugs we discover, that's the important change.
If we decide to not go this route for some reason, I think we should adjust our tools (system-upgrade) and documentation (wiki, fedora docs) and provide very clear and visible warning that the only officially supported means of upgrading is to go up releases one by one. And that skipping releases might be dangerous (considerably more than doing it the recommended way). Because I feel we would be doing our users a disservice if we neither tested skipping releases nor warned them against doing that.
Thoughts?
Kamil
7 years, 10 months
[Fedora QA] #474: Proposed Test Day - i18n
by fedora-badges
#474: Proposed Test Day - i18n
----------------------+------------------------
Reporter: tagoh | Owner:
Type: task | Status: new
Priority: major | Milestone: Fedora 23
Component: Test Day | Version:
Keywords: | Blocked By:
Blocking: |
----------------------+------------------------
After discussing the schedule of i18n test day in the fedora i18n meeting
yesterday, we have agreed to have it 1st of September.
--
Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/474>
Fedora QA <http://fedorahosted.org/fedora-qa>
Fedora Quality Assurance
7 years, 10 months
