Reindl Harald wrote:
oh even if people like i did some hundret dist-upgrades over the
years it was us told that linux has to go the windows way:
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
Yeah, this is a really insane feature!
Let me assure you that this feature is only
On Sat, Feb 9, 2013 at 9:10 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Reindl Harald wrote:
oh even if people like i did some hundret dist-upgrades over the
years it was us told that linux has to go the windows way:
http://fedoraproject.org/wiki/Features/OfflineSystemUpdates
Yeah, this
Am 09.02.2013 15:52, schrieb drago01:
On Sat, Feb 9, 2013 at 9:10 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Reindl Harald wrote:
oh even if people like i did some hundret dist-upgrades over the
years it was us told that linux has to go the windows way:
Am 04.02.2013 18:35, schrieb Miroslav Suchý:
On 01/25/2013 12:12 AM, Lennart Poettering wrote:
So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes
On Tue, 2013-02-05 at 08:54 +0100, Miroslav Suchý wrote:
On 02/04/2013 10:29 PM, Adam Williamson wrote:
https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/
... kinda. That's the best that I know of.
It lacks in details how I can put hook in upgrade.pre and
On 01/29/2013 12:59 AM, Adam Williamson wrote:
Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much any action to be
performed as part of the upgrade. To be sure
On 01/25/2013 12:12 AM, Lennart Poettering wrote:
So, you can ignore all of that, but then you have to think about what
you actually accomplished by your upgrade? You updated a couple of
libraries, and maybe managed to restart a few processes using them, but
for the rest of them the vulnerable
Hi
On Mon, Feb 4, 2013 at 12:35 PM, Miroslav Suchý wrote:
Lets pretend I'm still running Fedora 16 and every day I do yum-upgrade
and not rebooted from day zero.
I have exactly the same problem as during yum upgrade to next Fedora
release.
So we are ignoring this behaviour in middle of
On Mon, 2013-02-04 at 18:11 +0100, Miroslav Suchý wrote:
On 01/29/2013 12:59 AM, Adam Williamson wrote:
Well, the other thing fedup does - and the other reason it's necessary
compared to a simple online yum upgrade - is provide a mechanism for
pretty much any package to hook in pretty much
On 02/04/2013 10:29 PM, Adam Williamson wrote:
https://ohjeezlinux.wordpress.com/2012/11/13/fedup-a-little-background/ ...
kinda. That's the best that I know of.
It lacks in details how I can put hook in upgrade.pre and upgrade.post.
What is the best practise here?
It would be nice if you
Bruno Wolff III wrote:
Note that this doesn't fix problems caused by dropped packages, that block
other packages from being updated.
That's a problem for all upgrade methods, they might leave your system with
broken dependencies instead of erroring out, but in the end the problem is
always
Lennart Poettering wrote:
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
tried to update the Firefox RPM while it is running knows that
Lennart Poettering wrote:
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for rebooting...
That yum is tested every day and
Jaroslav Reznik wrote:
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade
Feature owner(s): Miroslav Suchý msu...@redhat.com
Upgrade Fedora to next version using yum upgrade.
I agree this should be officially supported, but:
I propose to have FedUp and
drago01 wrote:
And the major issue with yum upgrades is that online upgrades can fail
not only based on what you have installed but also what is currently
running and it cannot handle stuff like usermove without user
intervention.
1. That's a problem with UsrMove, not with yum!
2. UsrMove CAN
drago01 wrote:
I doubt that you can install all packages without hitting conflicts.
That just shows again how Conflicts are evil and how we're way too tolerant
about them. There should be NO conflicting packages in the official
repositories.
Kevin Kofler
--
devel mailing list
Jóhann B. Guðmundsson wrote:
Users are better of keeping /home on a separated partition and re-use it
with an fresh install then those poor attempts to support upgrades one
way or another which at this point in time we cant do since the bits for
that aren't properly aligned to make that
Hi,
If a fedup upgrade can go offline for a lengthy, but uncertain, amount
of time, then the lack of feedback is worrying. You can't hold your
breath for 25 minutes, you don't know when to conclude that you have a
serious problem that will require help from the data center staff, and
you
On Mon, 2013-01-28 at 14:01 +0100, Gerd Hoffmann wrote:
Hi,
If a fedup upgrade can go offline for a lengthy, but uncertain, amount
of time, then the lack of feedback is worrying. You can't hold your
breath for 25 minutes, you don't know when to conclude that you have a
serious
On 26 Jan 2013, at 15:28, Michael Scherer wrote:
Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit :
On 26 Jan 2013, at 13:09, Chris Murphy wrote:
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
pseli...@mindspring.com wrote:
If you could SSH into fedup during its offline
Le samedi 26 janvier 2013 à 06:21 +, Matthew Garrett a écrit :
On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote:
Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
already did version upgrade taking 6 to 8h due to slow internet or slow
hard drives,
On Jan 24, 2013, at 10:42 PM, Matthew Garrett mj...@srcf.ucam.org wrote:
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a fully informed choice
about whether an online upgrade will ensure that they're no longer
running
On Jan 25, 2013, at 9:20 PM, Sam Varshavchik mr...@courier-mta.com wrote:
William Brown writes:
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new
On 26 Jan 2013, at 12:11, Chris Murphy wrote:
After 1/2 dozen fedup upgrades during testing, on average the
downtime portion of the upgrade was between 25 and 40 minutes. On a
five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust
drive (the new computer with SSD did the fedup
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote:
If a fedup upgrade can go offline for a lengthy, but uncertain, amount of
time, then the lack of feedback is worrying. You can't hold your breath for
25 minutes, you don't know when to conclude that you have a
On Jan 26, 2013, at 11:16 AM, Reindl Harald h.rei...@thelounge.net wrote:
Am 26.01.2013 19:09, schrieb Chris Murphy:
I just don't see how it's best practices to be doing updates on live
processes. This seems sorta like a game to find out just how much one can
cheat the upgrade process
Am 25.01.2013 18:00, schrieb Nicolas Mailhot:
Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit :
Applications have deps on all kinds of
data in /usr/lib, not just shared libraries. Such as locale data, icons,
fonts, artwork, documentation.
BTW Firefox seems to be the only
Am 25.01.2013 19:20, schrieb Lennart Poettering:
Nonsense, for a distribution upgrade you just recommend the admin to
reboot the system when done.
Everybody expects to reboot after a big distro-sync anyway as there is a
new kernel and basically new-everything.
Ah, so you have to reboot
Am 25.01.2013 21:17, schrieb Jóhann B. Guðmundsson:
On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
I use Fedora as a server system for my daily developer work. I use
many services with different configurations. Actually updating it with
preupgrade/fedup is sometimes hard. Reinstalling
On 26 Jan 2013, at 13:09, Chris Murphy wrote:
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
pseli...@mindspring.com wrote:
If a fedup upgrade can go offline for a lengthy, but uncertain,
amount of time, then the lack of feedback is worrying. You can't
hold your breath for 25 minutes,
Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit :
On 26 Jan 2013, at 13:09, Chris Murphy wrote:
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton
pseli...@mindspring.com wrote:
If you could SSH into fedup during its offline period and get
real time feedback about what
25.01.2013 22:27, Lennart Poettering пишет:
On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
On 01/24/2013 06:12 PM, Lennart Poettering wrote:
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want
On Fri, 2013-01-25 at 05:42 +, Matthew Garrett wrote:
On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including
Chris Adams wrote:
The way some other Unix OSes I've used worked for version upgrades was
to require the admin drop to single-user mode first, optionally with
network access. RHL/RHEL/Fedora have never had a single-user with
network mode, but that would be nice to have. Then maybe yum
Am 25.01.2013 05:46, schrieb Simo Sorce:
That said I think trying a distro-sync from a graphical session is just
a funny and instructive experience, I wouldn't recommend it as you'll
keep the pieces when your session blows up and brings with it your yum
upgrade, but it is certainly
Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit :
Applications have deps on all kinds of
data in /usr/lib, not just shared libraries. Such as locale data, icons,
fonts, artwork, documentation.
BTW Firefox seems to be the only application that goes bonkers when fonts
are updated
On 01/24/2013 06:12 PM, Lennart Poettering wrote:
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Then all code that runs that is not a system service is difficult to
restart from a
On 01/24/2013 06:12 PM, Lennart Poettering wrote:
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Then all code that runs that is not a system service is difficult to
restart
On Fri, 25.01.13 08:58, Simo Sorce (s...@redhat.com) wrote:
On Fri, 2013-01-25 at 05:42 +, Matthew Garrett wrote:
On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
We are all grown up enough to decide for our own, just give the
information and let the admin take care of
On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
On 01/24/2013 06:12 PM, Lennart Poettering wrote:
If you restart any of those you bring down the entire machine basically,
or bring down at least the bits you really want to avoid, i.e. the
user's sessions...
Lennart Poettering (mzerq...@0pointer.de) said:
I'll wait your patches for the kernel to allow seamless upgrades of the
kernel without reboots.
Sure, just have a ksplice server that generates splices for each new kernel
build relative to the previous one, and your upgrade process downloads all
My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the disruption
they always bring, at someone else's schedule. As you say, there are
good reasons why it's what it is now, and maybe you're right that it
can't be significantly
On Fri, 2013-01-25 at 19:20 +0100, Lennart Poettering wrote:
On Fri, 25.01.13 08:58, Simo Sorce (s...@redhat.com) wrote:
On Fri, 2013-01-25 at 05:42 +, Matthew Garrett wrote:
On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
We are all grown up enough to decide for
On Fri, Jan 25, 2013 at 14:22:44 -0500,
Przemek Klosowski przemek.klosow...@nist.gov wrote:
My point is that it'd be nice to improve the upgrades. I love
upgrades---I love the shiny new toys and I hate them for the
disruption they always bring, at someone else's schedule. As you say,
there
Hi,
2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com:
On 01/23/2013 10:55 PM, drago01 wrote:
Supporting none is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
Users are
On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
Hi,
2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com:
On 01/23/2013 10:55 PM, drago01 wrote:
Supporting none is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
On Fri, 2013-01-25 at 20:17 +, Jóhann B. Guðmundsson wrote:
On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
Hi,
2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com:
On 01/23/2013 10:55 PM, drago01 wrote:
Supporting none is not an option.
Really suddenly not an option.
We did
On 01/25/2013 08:32 PM, Simo Sorce wrote:
On Fri, 2013-01-25 at 20:17 +, Jóhann B. Guðmundsson wrote:
On 01/25/2013 07:39 PM, Michał Piotrowski wrote:
Hi,
2013/1/23 Jóhann B. Guðmundsson johan...@gmail.com:
On 01/23/2013 10:55 PM, drago01 wrote:
Supporting none is not an option.
Really
Simo Sorce s...@redhat.com writes:
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If yum
freaks out for *whatever* reason I want to be there with an
emergency shell open [...] I've been saved more than once by a
On Fri, Jan 25, 2013 at 03:51:14PM -0500, Frank Ch. Eigler wrote:
Simo Sorce s...@redhat.com writes:
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If yum
freaks out for *whatever* reason I want to be there with
On 25 Jan 2013, at 14:23, Simo Sorce wrote:
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight
bit
longer for rebooting...
A) One
On Fri, 2013-01-25 at 21:57 +, Matthew Garrett wrote:
On Fri, Jan 25, 2013 at 03:51:14PM -0500, Frank Ch. Eigler wrote:
Simo Sorce s...@redhat.com writes:
[...] B) I will *not* trust an update system that cuts me out of my
remote server and make me *hope* it will come up later. If
Le vendredi 25 janvier 2013 à 19:20 +0100, Lennart Poettering a écrit :
Ah, so you have to reboot anyway, so where is the difference between
your approach and proper offline updates then? Either way you have to
interrupt your work to reboot the machine. One just takes a slight bit
longer for
Ah, so you have to reboot anyway, so where is the difference
between
your approach and proper offline updates then? Either way you
have to
interrupt your work to reboot the machine. One just takes a
slight bit
longer for
William Brown writes:
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new subvolume. When you
reboot, the new subvolume can become the new root.
a) Currently
Once upon a time, William Brown will...@firstyear.id.au said:
In the future, hopefully once btrfs is a bit more mature, perhaps it
could be considered to make a new writable snapshot subvolume of the
system, and the use yum prefix to update the new subvolume. When you
reboot, the new subvolume
On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote:
Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I
already did version upgrade taking 6 to 8h due to slow internet or slow
hard drives, that's IMHO a pretty significant downtime.
fedup does all network activity
On Wed, Jan 23, 2013 at 11:57 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
On 01/23/2013 10:55 PM, drago01 wrote:
Supporting none is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an
On Wed, Jan 23, 2013 at 10:14:28PM -0800, Adam Williamson wrote:
(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic difference, I think.)
Because we don't officially support
Once upon a time, Adam Williamson awill...@redhat.com said:
Several knowledgeable developers have asserted that - while it often
happens to work out okay - online upgrading is an inherently dangerous
operation, I don't see that the limited amount of validation QA is able
to offer can possibly
On 01/23/2013 07:50 PM, Lennart Poettering wrote:
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
What could not be restarted? And what we
Miroslav Suchý (msu...@redhat.com) said:
On 01/23/2013 07:50 PM, Lennart Poettering wrote:
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code isn't like that. Anybody who
On Wed, 23.01.13 22:17, Adam Williamson (awill...@redhat.com) wrote:
On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
On Wed, Jan 23, 2013 at 22:47:18 +,
\Jóhann B. Guðmundsson\ johan...@gmail.com wrote:
b)
We QA have alot of QA community members testing this so this
On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Wed, 23.01.13 22:17, Adam Williamson (awill...@redhat.com) wrote:
On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
On Wed, Jan 23, 2013 at 22:47:18 +,
\Jóhann B. Guðmundsson\
On 24 January 2013 10:25, drago01 drag...@gmail.com wrote:
On Thu, Jan 24, 2013 at 6:11 PM, Lennart Poettering
Wouldn't it make sense to test the full install?
I doubt that you can install all packages without hitting conflicts.
You can not. Lots of things conflict so if you try to do a 'yum
On Thu, 24.01.13 15:28, Miroslav Suchý (msu...@redhat.com) wrote:
On 01/23/2013 07:50 PM, Lennart Poettering wrote:
The thing is that doing on-line updates only works for stuff you can
restart, and that doesn't mind that things are not atomically
updated. However, much (most?) of our code
On Thu, 2013-01-24 at 08:56 -0500, Matthew Miller wrote:
On Wed, Jan 23, 2013 at 10:14:28PM -0800, Adam Williamson wrote:
(As a side note, I would like to avoid describing fedup as 'officially
supported' and describe it instead as 'officially recommended' - it's an
important semantic
On Thu, 2013-01-24 at 18:11 +0100, Lennart Poettering wrote:
On Wed, 23.01.13 22:17, Adam Williamson (awill...@redhat.com) wrote:
On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
On Wed, Jan 23, 2013 at 22:47:18 +,
\Jóhann B. Guðmundsson\ johan...@gmail.com wrote:
b)
On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
I mean, here's an example: let's say openssl is updated, which is
pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at least half of all processes running on your
system,
and they all
On Thu, 24.01.13 21:15, Simo Sorce (s...@redhat.com) wrote:
On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
I mean, here's an example: let's say openssl is updated, which is
pulled
in by a ton of other things, for example the libc NSS LDAP module. The
libc NSS is used by at
On Fri, 2013-01-25 at 04:46 +0100, Lennart Poettering wrote:
On Thu, 24.01.13 21:15, Simo Sorce (s...@redhat.com) wrote:
On Fri, 2013-01-25 at 00:12 +0100, Lennart Poettering wrote:
I mean, here's an example: let's say openssl is updated, which is
pulled
in by a ton of other things,
On Thu, Jan 24, 2013 at 11:46:24PM -0500, Simo Sorce wrote:
We are all grown up enough to decide for our own, just give the
information and let the admin take care of that.
Well, that's the problem. Most of our users (including many of the
professional sysadmins) are *not* able to make a
On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote:
FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
upgrade). Some devels say that offline upgrade is only way. But on-line
upgrade
is possible. E.g in Debian world it is even prefered method. In
On Wed, Jan 23, 2013 at 7:50 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote:
FedUp is in fact yum-upgrade as well, but in dracut environment (aka off-line
upgrade). Some devels say that offline upgrade is only way. But
On Wed, Jan 23, 2013 at 1:04 PM, Jaroslav Reznik jrez...@redhat.com wrote:
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade
Feature owner(s): Miroslav Suchý msu...@redhat.com
Upgrade Fedora to next version using yum upgrade.
I see no reason to make this an
If this method will be tested by FedoraQA, then I believe this upgrade method
can be safely recommended to user.
The feature owners of this need to do the testing and prodding, not QA. The
way this feature is written, it seems to imply that QA is supposed to
implement this feature.
Note
Le mercredi 23 janvier 2013 à 19:50 +0100, Lennart Poettering a écrit :
On Wed, 23.01.13 18:04, Jaroslav Reznik (jrez...@redhat.com) wrote:
FedUp is in fact yum-upgrade as well, but in dracut environment (aka
off-line
upgrade). Some devels say that offline upgrade is only way. But
On 01/23/2013 07:29 PM, Josh Boyer wrote:
On Wed, Jan 23, 2013 at 1:04 PM, Jaroslav Reznikjrez...@redhat.com wrote:
= Features/FedoraUpgrade =
https://fedoraproject.org/wiki/Features/FedoraUpgrade
Feature owner(s): Miroslav Suchýmsu...@redhat.com
Upgrade Fedora to next version using yum
On Wed, Jan 23, 2013 at 11:47 PM, Jóhann B. Guðmundsson
johan...@gmail.com wrote:
So I say let's support both or non et all..
Supporting none is not an option.
And the major issue with yum upgrades is that online upgrades can fail
not only based on what you have installed but also what is
On 01/23/2013 10:55 PM, drago01 wrote:
Supporting none is not an option.
Really suddenly not an option.
We did that for a long time why is that suddenly not an option so please
enlighten me why that's not an option.
Users are better of keeping /home on a separated partition and re-use it
On Wed, Jan 23, 2013 at 22:47:18 +,
\Jóhann B. Guðmundsson\ johan...@gmail.com wrote:
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA
community.
Aren't they just testing an upgrade of the default
On Wed, Jan 23, 2013 at 10:57:59PM +, Jóhann B. Guðmundsson wrote:
Users are better of keeping /home on a separated partition and
re-use it with an fresh install then those poor attempts to
support upgrades one way or another which at this point in time we
cant do since the bits for that
On Wed, 2013-01-23 at 18:04 +, Jaroslav Reznik wrote:
If this method will be tested by FedoraQA, then I believe this upgrade method
can be safely recommended to user.
On a practical level, this is not a good thing to rely on. It is
impossible for QA to cover the entire set of possible
On Wed, 2013-01-23 at 19:47 -0600, Bruno Wolff III wrote:
On Wed, Jan 23, 2013 at 22:47:18 +,
\Jóhann B. Guðmundsson\ johan...@gmail.com wrote:
b)
We QA have alot of QA community members testing this so this does NOT
require any additional effort or cause additional LOAD on the QA
84 matches
Mail list logo
