James Antill wrote:
> Wow ... it's almost as if we need a place where developers could put
> _updates_ for a significant amount of time so that users could do some
> _testing_ on them, under each of their particular conditions. We could
> maybe use this instead of developers hitting the go button
On Fri, 2009-10-16 at 20:47 +0200, Kevin Kofler wrote:
> What
> happened is that some IMAP-related feature broke, affecting some users (and
> I'm sorry you were hit by it), whereas most had their IMAP working just
> fine. So those bugs weren't trivial to catch.
Wow ... it's almost as if we nee
Nicolas Mailhot wrote:
> Dejavu has matured a lot so new releases are incremental improvements with
> no big feature changes.
... i.e. exactly the kind of things which should be pushed as updates!
> Not worth it pushing updated packages for previous releases (that will be
> installed by pretty mu
On Fri, Oct 16, 2009 at 06:48:38 +1000,
Dave Airlie wrote:
>
> 2 months is too long for user apps maybe, for X.org or Mesa from what I
> can see for ever probably isn't long enough, its not a matter of how
> much time something spends in updates-testing its a matter of how many
> people run wha
Le Ven 16 octobre 2009 20:39, Kevin Kofler a écrit :
> For example, I find it sad you switched to fire-and-forget "maintenance" for
> dejavu-fonts. The monthly updates were a good thing, they rarely if ever
> caused any problems and they improved font coverage.
Dejavu has matured a lot so new r
Rahul Sundaram wrote:
> Well, I do remember spending hours switching from kmail to thunderbird
> in the past because a KDE update in Fedora broke IMAP support and it
> stayed broken for quite sometime.
There have indeed been a few KMail regressions (especially with IMAP) which
slipped through, bo
Nicolas Mailhot wrote:
> They won't sit in forever, at worst they'll be pushed to users with the
> next Fedora release (that will have been tested properly during beta)
That's what I mean by "forever". It's "forever" as far as that one release
is concerned.
> No. It's *our* loss if we needlessly
On Fri, 2009-10-16 at 14:03 +0530, Rahul Sundaram wrote:
> On 10/16/2009 12:34 AM, Adam Williamson wrote:
>
> > I should've clarified that as far as new packages go, I don't see a
> > problem with just pushing them to stable after a few days in -testing as
> > long as no-one complains. It's quite
On 10/16/2009 05:24 AM, Kevin Kofler wrote:
> Matěj Cepl wrote:
>> Yes, I know, that's opinion of people around KDE that they don't
>> distinguish between Rawhide and updates-testing
>
> That's not true. In KDE SIG:
> * we do not push KDE prereleases to updates-testing (nor to the stable
> update
On 10/16/2009 12:34 AM, Adam Williamson wrote:
> I should've clarified that as far as new packages go, I don't see a
> problem with just pushing them to stable after a few days in -testing as
> long as no-one complains. It's quite hard for a new package to *break*
> something on a currently-workin
Le Ven 16 octobre 2009 01:49, Kevin Kofler a écrit :
>
> Nicolas Mailhot wrote:
>> Please do not ever push untested work to stable just because no one
>> complained. If you want testing on older releases you can push it to
>> testing but please don't ever promote it.
>
> Sorry, letting updates si
Adam Williamson wrote:
> I should've clarified that as far as new packages go, I don't see a
> problem with just pushing them to stable after a few days in -testing as
> long as no-one complains. It's quite hard for a new package to *break*
> something on a currently-working system without explicit
Matěj Cepl wrote:
> Yes, I know, that's opinion of people around KDE that they don't
> distinguish between Rawhide and updates-testing
That's not true. In KDE SIG:
* we do not push KDE prereleases to updates-testing (nor to the stable
updates, of course),
* we rarely push application prereleases
Nicolas Mailhot wrote:
> Please do not ever push untested work to stable just because no one
> complained. If you want testing on older releases you can push it to
> testing but please don't ever promote it.
Sorry, letting updates sit in testing forever is just not an option.
> People who bother
On Thu, Oct 15, 2009 at 4:48 PM, Dave Airlie wrote:
>
> 2 months is too long for user apps maybe, for X.org or Mesa from what I
> can see for ever probably isn't long enough
My guess is that it's relatively easy for a semi-technical person to
be able to map back from a visible problem in a deskto
On Thu, 2009-10-15 at 17:27 +0200, Kevin Kofler wrote:
> Michael Schwendt wrote:
> > If you know that you would _never_ be happy with a test-update becoming
> > a stable update, then either don't push such a test-update or unpush
> > it (manually or by relying on karma automatism).
>
> That was my
On Thu, 2009-10-15 at 20:26 +0200, Matěj Cepl wrote:
> Dne 14.10.2009 22:26, Adam Williamson napsal(a):
> > I agree with this, but by the same token, the use suggested by Matej
> > seems against the purpose of updates-testing, as does the original idea
> > in this thread (push some Xorg changes we'
Dne 14.10.2009 22:26, Adam Williamson napsal(a):
> I agree with this, but by the same token, the use suggested by Matej
> seems against the purpose of updates-testing, as does the original idea
> in this thread (push some Xorg changes we'd never be happy about putting
> in stable into it). I also a
Dne 15.10.2009 17:21, Kevin Kofler napsal(a):
> Matěj Cepl wrote:
>> This is actually your personal opinion AFAIK, right?
>
> No, it's what updates-testing is for.
Yes, that's your personal opinion about what updates-testing is for.
> Who gives a darn? If nobody complains about any issues, just
Le Jeu 15 octobre 2009 17:21, Kevin Kofler a écrit :
> Who gives a darn? If nobody complains about any issues, just push it! In 99%
> of cases, what works fine on Fedora n will work fine on Fedora n-1, too.
It is not 99% and it takes just a few bad apples to ruin the experience
provided by the
Michael Schwendt wrote:
> If you know that you would _never_ be happy with a test-update becoming
> a stable update, then either don't push such a test-update or unpush
> it (manually or by relying on karma automatism).
That was my point!
> However, it could be that you would need to offer a test
Matěj Cepl wrote:
> This is actually your personal opinion AFAIK, right?
No, it's what updates-testing is for.
> I tend to disagree with this -- one example which seems to me legitimate
> is when I create a new package (I remember I came to this conclusion with
> both PSPP and nimbus-theme) then
On Wed, 14 Oct 2009 13:26:53 -0700, Adam wrote:
> (push some Xorg changes we'd never be happy about putting
> in stable into it).
If you know that you would _never_ be happy with a test-update becoming
a stable update, then either don't push such a test-update or unpush
it (manually or by relyin
On Wed, 2009-10-14 at 11:21 +0200, Michael Schwendt wrote:
> On Wed, 14 Oct 2009 08:58:45 +0200, Kevin wrote:
>
> > We really need some stricter enforcement against stuff sitting in testing
> > forever.
>
> Rather we need some rules against such mindset.
>
> We don't guarantee anything about up
Dne 14.10.2009 08:58, Kevin Kofler napsal(a):
> "Never" is definitely the wrong answer: updates-testing is not for stuff
> which is too unstable to go stable, ever. Any update sitting in testing for
> more than (at most) 2 or 3 weeks (usually 1 week is enough, but risky stuff
> should get approx
On Wed, 14 Oct 2009 08:58:45 +0200, Kevin wrote:
> We really need some stricter enforcement against stuff sitting in testing
> forever.
Rather we need some rules against such mindset.
We don't guarantee anything about updates-testing. It's a place where
to test potential updates/upgrades. And i
Adam Jackson wrote:
> If we were more aggressive about backporting the kernel drm bits, and
> there was some slightly easier (preferably Makefile.common-driven) way
> of getting a package into the buildroot before being in -updates proper,
> we could probably do without lookaside repos.
Well, if y
James Antill wrote:
> Personally I'd suggest pushing to updates-testing but wait a _long_
> time (maybe even never) before pushing to stable.
"Never" is definitely the wrong answer: updates-testing is not for stuff
which is too unstable to go stable, ever. Any update sitting in testing for
more
On Thu, 2009-10-08 at 23:56 -0400, James Antill wrote:
> On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote:
> > The thing with doing updates for F11 is the regression rate due to
> > lack of QA, I put Mesa packages into updates-testing that fixed a
> > lot of r300/r500 bugs back at the start of
On Sat, 2009-10-10 at 15:02 +, Scott Tsai wrote:
> On Fri, 09 Oct 2009 07:57:51 -0700, Adam Williamson wrote:
>
> > It would be nice to have more comprehensive 3D tests.
>
> I think it's worth packaging the "piglit" OopenGL test suite:
> http://cgit.freedesktop.org/piglit
> and using it in gr
On Fri, 09 Oct 2009 07:57:51 -0700, Adam Williamson wrote:
> It would be nice to have more comprehensive 3D tests.
I think it's worth packaging the "piglit" OopenGL test suite:
http://cgit.freedesktop.org/piglit
and using it in graphics test days.
According tho this blog post by Eric Anholt and
It's Friday, so I'll allow myself to digress -
Ilyes Gouta wrote:
think that the has_gem thing is exported for X11 and Xv user-space
through a GEM ioctl property and it doesn't interfere with the rest of
Whenever I see " GEM " I get weird DOS GUI flashbacks, and they hurt.
Couldn't they have
On Fri, Oct 09, 2009 at 09:35:23 +0100,
Terry Barnaby wrote:
> I totally agree with you on the QA issue. Maybe I am wrong, but I haven't
> seen any real set of tests to be performed on Fedora 3D graphics.
> I tried the ATI test day for graphics. On the 3D graphics side it said to
> run "glxgears
On Fri, 2009-10-09 at 14:08 +0200, Andreas Tunek wrote:
> Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
> tests and removes stuff like abiword and gnumeric?
We're not huge fans of the Phoronix tests for a variety of reasons
(including that you don't really have a clue what
On Fri, Oct 09, 2009 at 02:08:41PM +0200, Andreas Tunek wrote:
>Maybe we could do a "Phoronix live cd" that includes the phoronix 3d
>tests and removes stuff like abiword and gnumeric?
If the tests are in Fedora and you find someone willing to create the
kickstart file for the spin, sure.
josh
-
2009/10/9 Terry Barnaby :
> On 10/09/2009 12:19 AM, Dave Airlie wrote:
>>
>> On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
>>>
>>> On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
No, I don't what to force testing on anyone (although F11 has done
that
already
Obviously i915.modeset == 0 all the time (including when I reported the issue).
-Ilyes
On Fri, Oct 9, 2009 at 9:21 AM, Ilyes Gouta wrote:
> Hi,
>
> I actually (think?) that I fixed the issue. It's all related to a
> check in the intel i915 drm code in the kernel, which is still present
> in the
On 10/09/2009 12:19 AM, Dave Airlie wrote:
On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
No, I don't what to force testing on anyone (although F11 has done
that
already :) )
I was just suggesting that a separate yum archive wit
Hi,
I actually (think?) that I fixed the issue. It's all related to a
check in the intel i915 drm code in the kernel, which is still present
in the latest Fedora 2.6.30.8-64 kernel. It's in the form of
data->has_gem = !IS_8XX(dev) ? 1 : 0, which gets the whole gem stuff
disabled for my i855GM. I c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James Antill wrote:
> The problem is that PPAs/KoPeRs are going to get much less
testing than
> stuff in updates-testing, so if you don't think you are
getting enough
> testing in updates-testing I really don't see how KoPeRs will
solve that
> pr
On Fri, 2009-10-09 at 09:19 +1000, Dave Airlie wrote:
> On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
> > Then please feel free to make one. :) I don't mean that in a snide
> > fashion, but it really is the answer. As noted, having our X.org
> > developers spend time on such a repositor
On Thu, 2009-10-08 at 09:37 -0700, Adam Williamson wrote:
> On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
> > No, I don't what to force testing on anyone (although F11 has done
> > that
> > already :) )
> > I was just suggesting that a separate yum archive with the packages
> > necessary
On Thu, 2009-10-08 at 19:33 +0100, Terry Barnaby wrote:
> > Backporting packages is not intrinsically very difficult, though it is
> > somewhat time-consuming, so it's something for which a far greater
> > candidate pool exists than X driver development. Thus, the suggestion
> > that someone else
On 10/08/2009 05:37 PM, Adam Williamson wrote:
On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
No, I don't what to force testing on anyone (although F11 has done
that
already :) )
I was just suggesting that a separate yum archive with the packages
necessary
to test the later graphics dev
On Wed, Oct 07, 2009 at 15:15:06 +0100,
Terry Barnaby wrote:
> The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
> ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
> on any of my computers (5 different graphics hardware versions).
I was able to
On Thu, Oct 08, 2009 at 14:05:22 +0100,
> I was just suggesting that a separate yum archive with the packages necessary
> to test the later graphics development code that will be in F12 could be
> made available for people to try out easily with their F11 systems.
> They can optionally try these. I
On Thu, 2009-10-08 at 14:05 +0100, Terry Barnaby wrote:
> No, I don't what to force testing on anyone (although F11 has done
> that
> already :) )
> I was just suggesting that a separate yum archive with the packages
> necessary
> to test the later graphics development code that will be in F12 coul
On Thu, 2009-10-08 at 10:54 +0100, Terry Barnaby wrote:
> I would have thought that more people would be likely to try out the graphics
> updates if it is easy for them to install on their running systems and use in
> their normal usage patterns rather than have to maintain a separate test
> syst
Matej Cepl wrote:
> I guess because F11 is considered stable release? I don't know really,
> but I would just add a banal observation that every hour spend on
> backporting stuff to F11 (and from Adam's answer it seems to require many
> many hours) cannot be spent on making Rawhide-soon-to-be-F12 m
On 10/08/2009 01:51 PM, Bruno Wolff III wrote:
On Thu, Oct 08, 2009 at 10:54:54 +0100,
Terry Barnaby wrote:
Are you confident that F12 will make 3D usable under Linux on the majority of
mainstream graphics cards ?
It's not going to provide 3d for nvidia, though it is hoped that nouveau wil
On Thu, Oct 08, 2009 at 10:54:54 +0100,
Terry Barnaby wrote:
> Are you confident that F12 will make 3D usable under Linux on the majority of
> mainstream graphics cards ?
It's not going to provide 3d for nvidia, though it is hoped that nouveau will
be somewhat improved. Intel and all much of AT
On Thu, Oct 08, 2009 at 10:54:54AM +0100, Terry Barnaby wrote:
>>> It would be good to have a Linux system that could actually to 3D with the
>>> major applications by the end of 2009 !
>>
>> Fortunately, F-12 is scheduled for release by then!
>>
>> josh
>>
> Are you confident that F12 will make 3D
On 10/07/2009 03:44 PM, Josh Boyer wrote:
On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote:
A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
new 1.7 XServer and 7.6 mesa would be very useful.
No, not really.
I understand that changing the Graphics syste
Mail Lists, Wed, 07 Oct 2009 22:26:08 -0400:
> I dont have this hardware - but just a question - why not just upgrade
> to upstream (2.6.32 would be nice in a couple of days ... ) ?
I guess because F11 is considered stable release? I don't know really,
but I would just add a banal observation t
On 10/07/2009 02:26 PM, Adam Jackson wrote:
> In fact, the major reason for not backporting the intel driver to F11 is
> that it requires a bunch of kernel changes that no one really has time
> for. Among other things, 830 through 865 require GEM in the intel 2.9,
> which we have disabled for the
On Wed, 2009-10-07 at 10:44 -0400, Josh Boyer wrote:
> On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote:
> > A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
> > new 1.7 XServer and 7.6 mesa would be very useful.
>
> No, not really.
>
> > I understand that c
On Wed, Oct 07, 2009 at 03:15:06PM +0100, Terry Barnaby wrote:
> A new release of drm/mesa/xf86-video-ati/Xserver code for F11 based on the
> new 1.7 XServer and 7.6 mesa would be very useful.
No, not really.
> I understand that changing the Graphics system could break many
> users systems, so ma
On Wed, Oct 07, 2009 at 15:15:06 +0100,
Terry Barnaby wrote:
> The graphics system in F11 is horribly broken for 3D, at least on Intel 845,
> ATI 200 and ATI 300 chipsets. Certainly the Blender program will not run
> on any of my computers (5 different graphics hardware versions).
3d seems to b
On 10/04/2009 04:05 PM, John Reiser wrote:
The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.
Enumerate the reasons, please. Which _specific_ bugs or features have been
improved elsewhere but not in F11? Why are they important to you and
othe
- "Michal Nowak" wrote:
> But there's patch http://bugs.freedesktop.org/show_bug.cgi?id=20901
> you might wanna test it -- looked good.
As of now it's "RESOLVED FIXED". Should be part of 2.6.32 kernel (when
is out).
Michal
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
ht
- "Ilyes Gouta" wrote:
> Hi John,
>
> I updated my Fedora 11 laptop (an old Thinkpad R50e, Pentium-M, w/
> intel 855G integrated graphics), latest Fedora kernel 2.6.30.8-64 and
Well, having i855 here too, and frankly, xorg-x11-drv-intel+libdrm+kernel
combination at F-11 was really horrible
Hi John,
I updated my Fedora 11 laptop (an old Thinkpad R50e, Pentium-M, w/
intel 855G integrated graphics), latest Fedora kernel 2.6.30.8-64 and
I still have the Xv video acceleration locking up the entire machine
as soon as I start a video playback. I dug a bit actually and I'm not
sure anymore
The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.
Enumerate the reasons, please. Which _specific_ bugs or features have been
improved elsewhere but not in F11? Why are they important to you and others?
--
--
fedora-devel-list mailing list
Hi,
The title says it all. How about that? We really need it for old intel
h/w such as an i855 for example.
Regards,
Ilyes Gouta.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
64 matches
Mail list logo
