On Wed, Nov 23, 2011 at 00:13, Adam Williamson wrote:
> How does that sound? Anyone want to propose modifications /
> alternatives? Thanks!
I liked the very much how we handled this in F16, having TCs earlier
is a plus to how I proceed in testing. So, I think the suggested
changes are very good.
On Wed, 2011-11-23 at 02:19 +0100, Henrik Nordström wrote:
> tis 2011-11-22 klockan 13:03 -0800 skrev Adam Williamson:
>
> > * Any custom choices the package maintainer opts to provide, via some
> > kind of interface to Bodhi
>
> * Checkboxes per bug assigned to the update for indicating that the
-2.fc14.1,glibmm24-2.24.2-2.fc14.1
The following builds have been pushed to Fedora 14 updates-testing
bitlbee-3.0.3-6.fc14
dovecot-2.0.16-1.fc14
kernel-2.6.35.14-105.fc14
mysql-5.1.60-1.fc14
pcre-8.10-3.fc14
rear-1.12.0-1.fc14
vlgothic-fonts-2022-1.fc14
Details
-0.3.2021svn.fc15
vlgothic-fonts-2022-1.fc15
Details about builds:
Saaghar-0.9.69-1.fc15 (FEDORA-2011-16294)
A Cross-Platform Persian Poetry Software
util-linux-2.20.1-2.1.fc16
vlgothic-fonts-2022-1.fc16
xen-4.1.2-2.fc16
zanata-python-client-1.3.2-1.fc16
Details about builds:
LuxRender-0.8.0-3.fc16 (FEDORA-2011-16279)
Lux Renderer, an unbiased
On 11/22/11 7:29 AM, Gianluca Cecchi wrote:
> I have an Asus U36SD laptop, with Optimus technology.
> I'm not sure if my current approach is the correct/more safe one.
> I think more and more devices are going to have this technology, so
> this could be a cue to address future F17 potential users
Hey, folks.
So, for Fedora 16 we experimented with replacing the 'RATS' test points
for Beta and Final with early drops of TC1, and I think that turned out
pretty well.
Given that, I think we should consider doing the same for Fedora 17.
Here are the current, relevant dates from the F17 schedule
On Tue, 2011-11-22 at 22:17 +0100, Sandro "red" Mathys wrote:
> On Tue, Nov 22, 2011 at 22:03, Adam Williamson wrote:
> > 2. Any update marked as 'critpath breaking' by a proven tester would be
> > blocked from being pushed stable at all - automatically or manually -
> > until the PT modified the
On Tue, 2011-11-22 at 21:31 +, "Jóhann B. Guðmundsson" wrote:
> On 11/22/2011 09:03 PM, Adam Williamson wrote:
> > 2. Any update marked as 'critpath breaking' by a proven tester would be
> > blocked from being pushed stable at all - automatically or manually -
> > until the PT modified the feed
On Tue, Nov 22, 2011 at 22:03, Adam Williamson wrote:
> 2. Any update marked as 'critpath breaking' by a proven tester would be
> blocked from being pushed stable at all - automatically or manually -
> until the PT modified the feedback or it was overridden by someone with
> appropriately godlike
Hey, folks.
So in the recent proven tester discussion, and in various other threads,
I've oft stated that the limits of the current Bodhi karma system are a
significant problem, and the planned Bodhi 2.0 karma system has to
potentially to significantly improve our update testing process. But it
oc
On Tue, 2011-11-22 at 11:18 -0500, Josh Boyer wrote:
> On Tue, Nov 22, 2011 at 10:54 AM, Adam Williamson wrote:
> > On Tue, 2011-11-22 at 13:29 +0100, Gianluca Cecchi wrote:
> >
> >> What about i915_enable_rc6 not being the default...? Does still put
> >> stability problems? Does it make sense to
On Tue, Nov 22, 2011 at 12:10 PM, Gianluca Cecchi
wrote:
> On Tue Nov 22 16:18:01 UTC 2011 Josh Boyer wrote:
>>>On Tue, Nov 22, 2011 at 10:54 AM, Adam Williamson wrote:
>>> modinfo asserts:
>>>
>>> parm: i915_enable_rc6:Enable power-saving render C-state 6
>>> (default: true) (int)
>>>
>
On Tue Nov 22 16:18:01 UTC 2011 Josh Boyer wrote:
>>On Tue, Nov 22, 2011 at 10:54 AM, Adam Williamson wrote:
>> modinfo asserts:
>>
>> parm: i915_enable_rc6:Enable power-saving render C-state 6
>> (default: true) (int)
>>
>> are you sure it's *not* the default?
>
> Yes. Modinfo is lying
On Tue, Nov 22, 2011 at 10:54 AM, Adam Williamson wrote:
> On Tue, 2011-11-22 at 13:29 +0100, Gianluca Cecchi wrote:
>
>> What about i915_enable_rc6 not being the default...? Does still put
>> stability problems? Does it make sense to enable it or not by default
>> based on different adapters/chip
On Tue, 2011-11-22 at 13:29 +0100, Gianluca Cecchi wrote:
> What about i915_enable_rc6 not being the default...? Does still put
> stability problems? Does it make sense to enable it or not by default
> based on different adapters/chipsets?
> In my case it gives me about 1hour and a half of battery
On Tue, Nov 22, 2011 at 12:00:23PM +0100, Gianluca Cecchi wrote:
> On Tue, Nov 22, 2011 at 11:22 AM, Alon Levy wrote:
> >
> > I think I have the same problem here, I've followed it once, gdbing the
> > server, it was in select, so maybe I'll try to do it again and do the
> > 'print AllClients' - fo
Hello,
I have an Asus U36SD laptop, with Optimus technology.
I'm not sure if my current approach is the correct/more safe one.
I think more and more devices are going to have this technology, so
this could be a cue to address future F17 potential users problems
At the moment I have F16 x86_64 on i
On Tue, Nov 22, 2011 at 11:22 AM, Alon Levy wrote:
>
> I think I have the same problem here, I've followed it once, gdbing the
> server, it was in select, so maybe I'll try to do it again and do the
> 'print AllClients' - for me reproducing is 100% by doing a chvt /
> suspend and resume. To get bac
On Mon, Nov 21, 2011 at 10:26:52AM -0500, Adam Jackson wrote:
> On Mon, 2011-11-21 at 12:11 +0100, Gianluca Cecchi wrote:
> > On Fri, Nov 18, 2011 at 7:00 PM, Adam Jackson wrote:
> >
> > > If you debuginfo-install gnome-shell, attach with gdb instead of sending
> > > SIGHUP, and run 'thread apply
20 matches
Mail list logo
