Hey, folks. So, just wanted to kick off a discussion regarding this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=688305
The default update notification period has been changed for GNOME in F15 from 1 day to 1 week (security updates still get notifications immediately). This is a change that's come from upstream, the GNOME design team, who consider it a UI design issue. QA and FPL think this is at least partly a distro policy issue as well as / more than a UI design issue, and think we should consider whether we actually want to make this change for Fedora, and if so whether we should have a different update period for the pre-release cycle. QA certainly feels that 1 day is more appropriate than 1 week during pre-release time.
We chatted a bit about this during the blocker review meeting today, but all agreed this would be a more appropriate venue for discussion, so I wanted to kick off a thread. :) Thoughts?
On 03/18/2011 06:29 PM, Adam Williamson wrote:
Hey, folks. So, just wanted to kick off a discussion regarding this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=688305
The default update notification period has been changed for GNOME in F15 from 1 day to 1 week (security updates still get notifications immediately). This is a change that's come from upstream, the GNOME design team, who consider it a UI design issue. QA and FPL think this is at least partly a distro policy issue as well as / more than a UI design issue, and think we should consider whether we actually want to make this change for Fedora, and if so whether we should have a different update period for the pre-release cycle. QA certainly feels that 1 day is more appropriate than 1 week during pre-release time.
Should we tie this with the Bodhi package acceptance criteria? e.g. on stable releases, maintainers have to wait a week before packages can be moved to the next stage, while in F-15 it's 3 days.
Then again, important fixes often get karma-promoted, and maybe we don't want to make testers wait for the entire duration. But they can always manually check for updates.
Regards,
On Fri, Mar 18, 2011 at 07:50:29PM +0100, Michel Alexandre Salim wrote:
On 03/18/2011 06:29 PM, Adam Williamson wrote:
Hey, folks. So, just wanted to kick off a discussion regarding this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=688305
The default update notification period has been changed for GNOME in F15 from 1 day to 1 week (security updates still get notifications immediately). This is a change that's come from upstream, the GNOME design team, who consider it a UI design issue. QA and FPL think this is at least partly a distro policy issue as well as / more than a UI design issue, and think we should consider whether we actually want to make this change for Fedora, and if so whether we should have a different update period for the pre-release cycle. QA certainly feels that 1 day is more appropriate than 1 week during pre-release time.
Should we tie this with the Bodhi package acceptance criteria? e.g. on stable releases, maintainers have to wait a week before packages can be moved to the next stage, while in F-15 it's 3 days.
Then again, important fixes often get karma-promoted, and maybe we don't want to make testers wait for the entire duration. But they can always manually check for updates.
The Bodhi time limit seems orthogonal to me, since different testing packages are going to be available throughout any given 3-day cycle.
Altering this setting during the pre-release phase seems reasonable, similar to how we turn on debugging stuff in the kernel. I don't see why this is a big policy discussion, it's simply something to make testing easier during a pre-release. Could this setting be twiddled with a schema setting in the fedora-release package, so pre-releases would be a little chattier about updates up until the RC?
%if %{release} < 1 gsettings do-something-magical-to-the-system-installed-schema %endif
I don't think we should be reversing the GNOME upstream setting beyond the pre-release stage, i.e. for GA. This setting should have minimal impact beyond casual users, since people doing development, QA, packaging, and other contribution (1) will find it simple to change their personal setting (or may already have done so); and (2) run yum often enough on their own that the PackageKit refresh module will make the change irrelevant to them anyway (right?).
Casual users will be affected in that their box won't be as chatty about non-critical updates. A simple statement should be included in the Release Notes about the change.
On Fri, 2011-03-18 at 10:29 -0700, Adam Williamson wrote:
Hey, folks. So, just wanted to kick off a discussion regarding this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=688305
The default update notification period has been changed for GNOME in F15 from 1 day to 1 week (security updates still get notifications immediately). This is a change that's come from upstream, the GNOME design team, who consider it a UI design issue. QA and FPL think this is at least partly a distro policy issue as well as / more than a UI design issue, and think we should consider whether we actually want to make this change for Fedora, and if so whether we should have a different update period for the pre-release cycle. QA certainly feels that 1 day is more appropriate than 1 week during pre-release time.
We chatted a bit about this during the blocker review meeting today, but all agreed this would be a more appropriate venue for discussion, so I wanted to kick off a thread. :) Thoughts?
Have there been any decisions on this topic?
Thanks, James
On Sat, Mar 19, 2011 at 09:39:26AM -0400, Paul W. Frields wrote:
On Fri, Mar 18, 2011 at 07:50:29PM +0100, Michel Alexandre Salim wrote:
On 03/18/2011 06:29 PM, Adam Williamson wrote:
Hey, folks. So, just wanted to kick off a discussion regarding this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=688305
The default update notification period has been changed for GNOME in F15 from 1 day to 1 week (security updates still get notifications immediately). This is a change that's come from upstream, the GNOME design team, who consider it a UI design issue. QA and FPL think this is at least partly a distro policy issue as well as / more than a UI design issue, and think we should consider whether we actually want to make this change for Fedora, and if so whether we should have a different update period for the pre-release cycle. QA certainly feels that 1 day is more appropriate than 1 week during pre-release time.
I agree. How else can this be tested effectively in a timely manner so we know for sure that this works properly?
Should we tie this with the Bodhi package acceptance criteria? e.g. on stable releases, maintainers have to wait a week before packages can be moved to the next stage, while in F-15 it's 3 days.
Then again, important fixes often get karma-promoted, and maybe we don't want to make testers wait for the entire duration. But they can always manually check for updates.
The Bodhi time limit seems orthogonal to me, since different testing packages are going to be available throughout any given 3-day cycle.
Altering this setting during the pre-release phase seems reasonable, similar to how we turn on debugging stuff in the kernel. I don't see why this is a big policy discussion, it's simply something to make testing easier during a pre-release. Could this setting be twiddled with a schema setting in the fedora-release package, so pre-releases would be a little chattier about updates up until the RC?
%if %{release} < 1 gsettings do-something-magical-to-the-system-installed-schema %endif
I thought updates notification was broken and failed the QA Test Case because it took so long to happen:
https://bugzilla.redhat.com/show_bug.cgi?id=693251
I don't think we should be reversing the GNOME upstream setting beyond the pre-release stage, i.e. for GA. This setting should have minimal impact beyond casual users, since people doing development, QA, packaging, and other contribution (1) will find it simple to change their personal setting (or may already have done so); and (2) run yum often enough on their own that the PackageKit refresh module will make the change irrelevant to them anyway (right?).
I would argue that updates-testing should give more frequent notification, or bodhi acceptance criteria should be lengthened to accomodate the less frequent notification.
Casual users will be affected in that their box won't be as chatty about non-critical updates. A simple statement should be included in the Release Notes about the change.
On 04/05/2011 08:23 PM, James Laska wrote:
On Fri, 2011-03-18 at 10:29 -0700, Adam Williamson wrote:
Hey, folks. So, just wanted to kick off a discussion regarding this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=688305
The default update notification period has been changed for GNOME in F15 from 1 day to 1 week (security updates still get notifications immediately). This is a change that's come from upstream, the GNOME design team, who consider it a UI design issue. QA and FPL think this is at least partly a distro policy issue as well as / more than a UI design issue, and think we should consider whether we actually want to make this change for Fedora, and if so whether we should have a different update period for the pre-release cycle. QA certainly feels that 1 day is more appropriate than 1 week during pre-release time.
We chatted a bit about this during the blocker review meeting today, but all agreed this would be a more appropriate venue for discussion, so I wanted to kick off a thread. :) Thoughts?
Have there been any decisions on this topic
I agree with upstream on this a week notice with 1 day notice of security updates for GA.
With regards to us ( QA ) I dont see the reason for why we should differ from this rule since.
A) Reporters should use yum from cli to update during the development cycle of the release regardless of *DE and application settings preferably run it manually on daily bases.
B) Reporters are already affected by mirror latency with regards to updates.
If we are going to make exception to this or any other update rule an *De/application might have during our development cycle I think we should make sure that all reporters are using the same bits at the same time as in skip mirrors during development cycle as well but whether we have enough bandwith to support that that is something that infrastructure needs answer.
JBG
On Wed, 2011-04-06 at 10:51 +0000, "Jóhann B. Guðmundsson" wrote:
A) Reporters should use yum from cli to update during the development cycle of the release regardless of *DE and application settings preferably run it manually on daily bases.
Actually, we need at least some people to use PackageKit some of the time, or we don't notice when PackageKit is broken. And we can't expect _everyone_ running pre-releases to know this.
On 04/06/2011 03:47 PM, Adam Williamson wrote:
On Wed, 2011-04-06 at 10:51 +0000, "Jóhann B. Guðmundsson" wrote:
A) Reporters should use yum from cli to update during the development cycle of the release regardless of *DE and application settings preferably run it manually on daily bases.
Actually, we need at least some people to use PackageKit some of the time, or we don't notice when PackageKit is broken. And we can't expect _everyone_ running pre-releases to know this.
I would think we would test for that on the relevant testday for the application.
Having test cases that involves basically fooling packagekit to think that x supported configuration time period has passed and it should check for updates.
For example let's say packagekit wants to update it self every Friday we would set the system date to next Friday and see if packagekit would pick it up and check and notify for any updates available.
JBG
2011/4/6 "Jóhann B. Guðmundsson" johannbg@gmail.com:
Having test cases that involves basically fooling packagekit to think that x supported configuration time period has passed and it should check for updates.
You can just change the timestamp stored in gsettings.
Richard.
On Wed, Apr 06, 2011 at 09:08:57PM +0100, Richard Hughes wrote:
2011/4/6 "Jóhann B. Guðmundsson" johannbg@gmail.com:
Having test cases that involves basically fooling packagekit to think that x supported configuration time period has passed and it should check for updates.
You can just change the timestamp stored in gsettings.
I believe this is...
Schema: org.gnome.settings-daemon.plugins.updates Key: last-updates-notification Type: uint64
for those who didn't know where to find it already.
desktop@lists.stg.fedoraproject.org
-
Adam Williamson -
Chuck Anderson -
James Laska -
Jóhann B. Guðmundsson -
Michel Alexandre Salim -
Paul W. Frields -
Richard Hughes