-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 10:59 PM, Matt McCutchen wrote:
> That's why I'm so frustrated that Fedora seems to be committed
> to keeping the Mozilla trademarks, which moot any discussion of whether
> to deviate for those packages. But this is only my opinion. Fe
On Fri, 2010-08-13 at 07:56 +0200, Ralf Corsepius wrote:
> On 08/13/2010 07:11 AM, Matt McCutchen wrote:
> > Let's try that again. Fedora has no obligation to you; nothing entitles
> > you (or anyone for that matter) to push updates or even to post to this
> > list.
> ... and people are free to ha
On Thu, 2010-08-12 at 22:26 -0700, Jesse Keating wrote:
> Do you have any sort of proof that it's a "political" reason? It would
> seem to me that our kernel maintainers do not wish to include code that
> hasn't been blessed by Linus in our packages. Doing so has burned us in
> the past, and perh
On 08/13/2010 01:23 AM, Luke Macken wrote:
> On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
>> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
>>> - Minimum time-in-testing requirements
>>> - Every day bodhi will look for updates that have been
>>> in testing for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 10:16 PM, Kevin Kofler wrote:
> Chris Ball wrote:
>> This should be unsurprising, because the stated objectives of the
>> Fedora project as a whole don't agree with you either:
>>
>> http://fedoraproject.org/wiki/Objectives
>> http://fedo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 12:33 PM, Lennart Poettering wrote:
> On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
>
>> Since 2006 I counted 18 slips (I think one or two of those may just be a
>> single slip listed twice). Lets not yell, lets not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/12/2010 12:05 PM, Bruno Wolff III wrote:
> On Thu, Aug 12, 2010 at 12:00:29 -0700,
> Adam Williamson wrote:
>>
>> We usually catch most initial blockers for any given release at the
>> first TC stage. Bugs we slip for are usually ones identifi
Chris Ball wrote:
> This should be unsurprising, because the stated objectives of the
> Fedora project as a whole don't agree with you either:
>
> http://fedoraproject.org/wiki/Objectives
> http://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Those same objectives say that Fedora shou
On Fri, 2010-08-13 at 03:33 +0200, Kevin Kofler wrote:
> Chris Adams wrote:
> > Why are you here? All you do is shout about how everything that is done
> > is done wrong, and how you wanted to do it different but were out-voted.
> > Why don't you go start your own distribution? If you are right,
Fedora 14 Alpha RC4 is now available [1]. Please refer to the following
pages for download links and testing instructions.
Installation:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Desktop:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Ideally, all
Hi,
> Bruno Wolff III wrote:
>> We'll until Lougher writes something that Linus will accept, we
>> need to wait.
> But WHY? IMHO, an upstream tarball is just a base to apply our
> patches onto.
Because the kernel team doesn't agree with you, of course.
This should be unsurprising
Chris Adams wrote:
> Why are you here? All you do is shout about how everything that is done
> is done wrong, and how you wanted to do it different but were out-voted.
> Why don't you go start your own distribution? If you are right, then
> you should have no trouble getting a large group of deve
Once upon a time, Kevin Kofler said:
> IMHO, FESCo should be abolished, Fedora needs to be ruled by the SIGs!
Why are you here? All you do is shout about how everything that is done
is done wrong, and how you wanted to do it different but were out-voted.
Why don't you go start your own distribut
Bruno Wolff III wrote:
> We'll until Lougher writes something that Linus will accept, we need to
> wait.
But WHY? IMHO, an upstream tarball is just a base to apply our patches onto.
We shouldn't be prisoners of upstream, especially when upstream processes
are just too slow to fit our needs. Back
There will be an outage starting at 2010-08-15 01:00 UTC, which will last
approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2010-08-15 01:00 UTC'
Reason for outage:
Network work is being done in our pr
I wrote:
> But FWIW, when it comes to KDE in particular, the whole thing is moot or
> soon to be moot anyway because parts of KDE are now being redefined as
> "critical path", resulting in even more annoying update policies, even
> though there was clear consensus in KDE SIG that such policies are
On Fri, Aug 13, 2010 at 01:18:29 +0200,
Kevin Kofler wrote:
> Bruno Wolff III wrote:
> > I hope to occasionally push back a little against this. When LZMA squashfs
> > makes it upstream (it looks like it won't happen in time for F14) we will
> > probably gain about 10% on what we can fit in a gi
On 8/12/2010 9:16, Peter Lemenkov wrote:
> I'm currently in process of automatic enlisting of all ~10K Fedora Git
> repos at Ohloh.
Do you have some way of automatically adding new packages as they are
added to Fedora in the future?
--
devel mailing list
devel@lists.fedoraproject.org
https://adm
I wrote:
> This argument has been brought up all the time. The thing is, it takes
> time to find people to +1 updates. It takes even longer if the people
> actually test the updates before +1ing them (as they're expected to). This
> excessive and useless QA adds delays over delays.
But FWIW, when
List Troll wrote:
> If you have been *testing* it for 2-3 weeks surely you have no problem
> to find two testers to confirm the small fix?
This argument has been brought up all the time. The thing is, it takes time
to find people to +1 updates. It takes even longer if the people actually
test th
On Fri, Aug 13, 2010 at 3:02 AM, Kevin Kofler wrote:
> Luke Macken wrote:
>> Ok, so the problem here is that bodhi unpushes updates when you edit
>> *anything* in it. If it only unpushed an updated when you add/remove
>> builds from it, then this scenario would be sane.
>
> There's still the "We'
Nicolas Mailhot wrote:
> So perhaps the delay between "invasive features autorized" and "alpha"
> is too short.
It's true that sometimes very invasive features have been rushed in right
before the feature freeze, often irrespective of the (lack of) benefits (at
least at their state of developmen
Luke Macken wrote:
> Ok, so the problem here is that bodhi unpushes updates when you edit
> *anything* in it. If it only unpushed an updated when you add/remove
> builds from it, then this scenario would be sane.
There's still the "We've been testing a new KDE release for 2-3 weeks, now
we need
Linuxguy123 wrote:
>
> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
>
>
I'm interested in this. I have noticed that for the past (several months?)
my system would freeze at apparently random times, while disk goes busy, for
periods of 20-30 seconds. This did not used to happen
Orcan Ogetbil wrote:
> The F-(x) package will have higher EVR than the F-(x+1) one. This
> will break the upgrade path. Is there any measures to prevent this?
No. In fact FESCo specifically refused to consider this as an issue, they
say separate releases need separate testing and so they refuse
drago01 wrote:
> It isn't broken so there is nothing to fix; slipping to fix issues
> found is a feature not a bug.
> We don't have any reason to "rush".
+1
Slips DO and WILL happen. It's just a matter of fact. It also happens in
other projects. We just need to accept this.
If we really want to
Will Woods wrote:
> This is a good point, and it's one of the reasons the 'critpath' stuff
> exists. It's the same concept, applied somewhat differently: rather than
> freeze the 'CoreOS' stuff earlier, we freeze it harder - we require more
> testing for those pieces.
The problem is, "freezing har
Nathaniel McCallum wrote:
> I disagree, the feature is shipping on time. Shipping on time enables
> others in the Fedora community (people who build on, deploy, etc) know
> with some assurance what their schedules will look like. If I were a
> project manager looking at using a Linux OS in my pro
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
> - Minimum time-in-testing requirements
> - When someone tries to push an update to stable, bodhi will
> look to see if it has the appropriate karma, or if it has
> been in testing for more than N days.
I
Jason L Tibbitts III wrote:
> To me this implies that we should begin testing earlier (or, perhaps,
> never stop testing) and treat any new failure as an event of
> significance. It's tough to meet a six month cycle if we spend half of
> it telling people to expect everything to be broken.
We HAV
Bruno Wolff III wrote:
> We've tried that in the past and it didn't work. Slipping the whole
> schedule right away is better than slipping piecewise when it comes to
> planning.
Huh? What's the worst that can happen? That we slip again, being at the same
release date as with the cascading slip sy
Luke Macken wrote:
> Fixed in
> https://fedorahosted.org/bodhi/changeset/97b1a9d1f9ceecaaa2128837cc5bbd7f8e495f36
That "fix" is really unhelpful and makes it a PITA to edit updates! In the
past, KDE SIG has often edited in some trivial fixes into the final stable
push of a KDE grouped update which
On 08/12/2010 07:15 PM, Kevin Kofler wrote:
> Orcan Ogetbil wrote:
>> Now without any further testing the package can be pushed to stable,
>> which contradicts the purpose of this whole change in bodhi.
>
> Sssh, why can't you keep quiet about this?!
>
>> I think, for packages that are modified dur
On 08/12/2010 07:12 PM, Orcan Ogetbil wrote:
> On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
>>- Minimum time-in-testing requirements
>>- Every day bodhi will look for updates that have been
>> in testing for N days (fedora: N=7, epel: N=14), and will
>>
Orcan Ogetbil wrote:
> Now without any further testing the package can be pushed to stable,
> which contradicts the purpose of this whole change in bodhi.
Sssh, why can't you keep quiet about this?!
> I think, for packages that are modified during the testing period,
> this N should be calculated
Bruno Wolff III wrote:
> I hope to occasionally push back a little against this. When LZMA squashfs
> makes it upstream (it looks like it won't happen in time for F14) we will
> probably gain about 10% on what we can fit in a given size image.
It's quite sad that we're waiting for upstream there.
On Thu, Aug 12, 2010 at 5:57 PM, Luke Macken wrote:
> - Minimum time-in-testing requirements
> - Every day bodhi will look for updates that have been
> in testing for N days (fedora: N=7, epel: N=14), and will
> add a comment notifying the maintainer that the
Kevin Fenzi wrote:
> Well, this has nothing to do with that. We are currently only pushing
> to stable those updates that are needed to fix Alpha release blockers
> in F14. So, it wouldn't matter here.
It will matter after the Alpha release when urgent dependency fixes will be
withheld for 1 week
On Fri, 13 Aug 2010 00:31:58 +0200
Kevin Kofler wrote:
> I think that this is really going to break our workflow!
I think it's going to help our workflow and provide our users with more
stable updates. Time will tell.
> For example, for the Fedora 14 under development, we now have to wait
> a
Subject: Fedora 14 Blocker Bug Review Meeting 2010-08-13 @ 16:00 UTC (12
PM EST)
When: Friday, 2010-08-13 @ 16:00 UTC (12 PM EST)
Where: #fedora-bugzappers on irc.freenode.net
Here are the current bugs listed as blocking the Alpha release. We'll be
discussing all of these to determine if they m
Luke Macken wrote:
> - Package update acceptance criteria compliance
>https://fedoraproject.org/wiki/Package_update_acceptance_criteria
>- Disable direct-to-stable pushes
> (https://fedorahosted.org/bodhi/ticket/434)
>- Minimum time-in-testing requirements
>
On Thu, Aug 12, 2010 at 13:13, Felix Miata wrote:
> On 2010/08/12 11:55 (GMT-0700) Adam Williamson composed:
>
>> if you want to maintain s-c-d, I'm sure ajax would be more than
>> happy to hand over ownership.
>
> Being a non-programmer I'm confident there's little likelihood I'd be
> competent t
On Thu, 2010-08-12 at 13:19 -0500, Mike McGrath wrote:
> How can we fix this?
Step 1 is to realize/admit there is a problem. You've tactfully done
that.
Step 2 is to gather data and knowledge. That doesn't appear to be
happening in these posts.
On the data side, it would be very interesting to
A new version of bodhi has just hit production. This release contains
a number of bugfixes and improvements, along with some important process
changes.
https://admin.fedoraproject.org/updates
ChangeLog
=
- Package update acceptance criteria compliance
https://fedoraproject
On Thu, 2010-08-12 at 17:08 -0400, Felix Miata wrote:
> On 2010/08/12 16:53 (GMT-0400) Adam Jackson composed:
>
> > On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote:
>
> >> For the benefit of those few, and there will likely always be some, for
> >> whom
> >> automatic isn't, some tool is ne
On 2010/08/12 16:52 (GMT-0400) Adam Jackson composed:
> On Thu, 2010-08-12 at 15:00 -0400, Felix Miata wrote:
>> EDID & DDC are mere conveniences unnecessary to the function of the device. I
>> really couldn't care less whether EDID/DDC exists, much less works. What
>> matters (works just fine) f
On 2010/08/12 16:53 (GMT-0400) Adam Jackson composed:
> On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote:
>> For the benefit of those few, and there will likely always be some, for whom
>> automatic isn't, some tool is needed upstream in Xorg, possibly SaX2 or SCD
>> at least as a starting po
I'll reply here but I'm also bringing together some things in the rest of
the thread... sorry about that.
On Thu, Aug 12, 2010 at 01:19:29PM -0500, Mike McGrath wrote:
>
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets no
On Thu, 2010-08-12 at 15:02 -0400, Nathaniel McCallum wrote:
> If our schedules aren't reasonably fixed, than others have a hard time
> working with us. Loosing users (especially companies with resources to
They are reasonably fixed. Please don't blow this out of proportion. I
don't believe we'v
On 08/12/2010 02:22 PM, Bill Nottingham wrote:
> Jon Ciesla (l...@jcomserv.net) said:
>> I disagree that a clockwork release schedule is required for quality, or
>> even perceived quality. If that's the sort of metric being looked at,
>> the user is probably best suited to RHEL, CentOS, etc.
> I
On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets not flame war, lets not
> point fingers. How can we fix this? It's clearly not one group or one
> individ
Le jeudi 12 août 2010 à 13:51 -0500, Jason L Tibbitts III a écrit :
> I guess I'm just saying that, if we had the developer time to do it, it
> would be super nice if we could get the "pre-F15 rawhide is useless" bit over
> and done with by the time F15 branches. But back in reality, I know
> tha
http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
http://www.phoronix.com/scan.php?page=news_item&px=ODQ3Mw
I believe I am affected by this issue from time to time.
Any chance that a near future Fedora kernel would contain the "fix" ?
Thanks
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/d
On Thu, 2010-08-12 at 15:13 -0400, Felix Miata wrote:
> For the benefit of those few, and there will likely always be some, for whom
> automatic isn't, some tool is needed upstream in Xorg, possibly SaX2 or SCD
> at least as a starting point. A wider call for a maintainer of SaX2 or SCD or
> some
On Thu, 2010-08-12 at 15:00 -0400, Felix Miata wrote:
> EDID & DDC are mere conveniences unnecessary to the function of the device. I
> really couldn't care less whether EDID/DDC exists, much less works. What
> matters (works just fine) from a display, which may have been manufactured
> before the
On Thu, 2010-08-12 at 13:39 -0500, Mike McGrath wrote:
> Would an 8[1] month cycle cause fewer slips per release? Fewer bugs?
For me, one of the guiding principles for Fedora QA's work on tools and
policies has been this: time, by itself, doesn't fix anything.
Making the schedules longer isn't
On Thu, 2010-08-12 at 21:33 +0200, Lennart Poettering wrote:
> I want to mention one thing: on opensuse the "base"
> system has a different schedule then the rest of the OS. i.e. the
> kernel, gcc, glibc and the low-level tools freeze first, while
> everything else may be hacked on a couple of wee
On Thu, Aug 12, 2010 at 2:19 PM, Mike McGrath wrote:
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets not flame war, lets not
> point fingers. How can we fix this?
[snip]
> This is a collective failure.
While I agree t
On Thu, 2010-08-12 at 21:33 +0200, Lennart Poettering wrote:
> On Thu, 12.08.10 13:19, Mike McGrath (mmcgr...@redhat.com) wrote:
>
> > Since 2006 I counted 18 slips (I think one or two of those may just be a
> > single slip listed twice). Lets not yell, lets not flame war, lets not
> > point fing
On Thu, Aug 12, 2010 at 14:32:21 -0400,
Felix Miata wrote:
>
> So users of absent or dysfunctional DDC and/or EDID should be committed to
> 800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
> working just fine) displays or learn the cryptic and complicated methodology
Jon Ciesla (l...@jcomserv.net) said:
> I disagree that a clockwork release schedule is required for quality, or
> even perceived quality. If that's the sort of metric being looked at,
> the user is probably best suited to RHEL, CentOS, etc.
It would be interesting to look at RHEL/CentOS to see
On 08/12/2010 02:14 PM, Nathaniel McCallum wrote:
> On 08/12/2010 03:08 PM, Jon Ciesla wrote:
>>On 08/12/2010 01:39 PM, Mike McGrath wrote:
>>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>>>
> "BN" == Bill Nottingham writes:
BN> I can't help but note that the slips have
On 08/12/2010 03:08 PM, Jon Ciesla wrote:
> On 08/12/2010 01:39 PM, Mike McGrath wrote:
>> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>>
"BN" == Bill Nottingham writes:
>>> BN> I can't help but note that the slips have become more frequent as we
>>> BN> started to actually *have
On 2010/08/12 11:55 (GMT-0700) Adam Williamson composed:
> if you want to maintain s-c-d, I'm sure ajax would be more than
> happy to hand over ownership.
Being a non-programmer I'm confident there's little likelihood I'd be
competent to attempt such an endeavor. Nevertheless, my complaints are n
On 08/12/2010 03:03 PM, Bruno Wolff III wrote:
> On Thu, Aug 12, 2010 at 13:19:29 -0500,
> Mike McGrath wrote:
>> Since 2006 we've slipped at least 16-18 weeks by my count. That's more
>> than half of a full release cycle.
>>
>> Thoughts?
>
> One thing I have noticed is people landing big chang
On 08/12/2010 01:51 PM, Jason L Tibbitts III wrote:
>> "MM" == Mike McGrath writes:
> MM> Possibly also stop changing earlier?
>
> Not necessarily. We should certainly try to get the earth shattering
> changes done as early as possible (i.e. soon after branch) but I
> recognize that there
On 08/12/2010 01:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham writes:
>> BN> I can't help but note that the slips have become more frequent as we
>> BN> started to actually *have* release criteria to test against. We
>> BN> di
On Thu, Aug 12, 2010 at 12:00:29 -0700,
Adam Williamson wrote:
>
> We usually catch most initial blockers for any given release at the
> first TC stage. Bugs we slip for are usually ones identified at that
> stage that we couldn't fix in time, bugs introduced between TC and RC by
This is anoth
On Thu, Aug 12, 2010 at 13:19:29 -0500,
Mike McGrath wrote:
> Since 2006 we've slipped at least 16-18 weeks by my count. That's more
> than half of a full release cycle.
>
> Thoughts?
One thing I have noticed is people landing big changes (such as python and
systemd) that break things for a wh
On 08/12/2010 02:39 PM, drago01 wrote:
> On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath wrote:
>
>> Since 2006 I counted 18 slips (I think one or two of those may just be a
>> single slip listed twice). Lets not yell, lets not flame war, lets not
>> point fingers. How can we fix this?
>
> It is
On 2010/08/12 14:38 (GMT-0400) Bill Nottingham composed:
> Felix Miata said:
>> So users of absent or dysfunctional DDC and/or EDID should be committed to
>> 800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
>> working just fine) displays
> Just as a point, if the EDI
On Thu, 2010-08-12 at 13:50 -0500, Mike McGrath wrote:
> Any of the QA guys have any way to measure the the most common cause of
> our slips? Is it usually stuff we're our own upstream for? Is it
> integration? Is it bugs that were introduced months ago but only recently
> found or bugs that we
On Thu, Aug 12, 2010 at 14:50:38 -0400,
Nathaniel McCallum wrote:
>
> One thing I am curious about is why, when slipping for an Alpha target,
> the whole schedule slips. Can't we just take a week out of the Beta
> cycle? The amount of testing time is roughly the same.
We've tried that in the
On Thu, 2010-08-12 at 14:32 -0400, Felix Miata wrote:
> On 2010/08/12 10:46 (GMT-0700) Adam Williamson composed:
>
> > It's more or less dead. ajax technically maintains it, but it's right at
> > the bottom of his priority list and we've been wanting to drop it for
> > ages. It's useful for almost
> "MM" == Mike McGrath writes:
MM> Possibly also stop changing earlier?
Not necessarily. We should certainly try to get the earth shattering
changes done as early as possible (i.e. soon after branch) but I
recognize that there isn't sufficient developer time available to both
stabilize one
On 08/12/2010 02:39 PM, Mike McGrath wrote:
> On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
>
>>> "BN" == Bill Nottingham writes:
>>
>> BN> I can't help but note that the slips have become more frequent as we
>> BN> started to actually *have* release criteria to test against. We
>> BN> did
On Thu, 12 Aug 2010, Bill Nottingham wrote:
> Matthias Clasen (mcla...@redhat.com) said:
> > > This is a collective failure.
> >
> > I'd like to question that premise. Why is it a failure if we adjust our
> > release schedule to meet our release criteria ?
>
> Well, ideally we'd be able to sched
On Thu, Aug 12, 2010 at 13:27:05 +0200,
Jaroslav Reznik wrote:
> Problem is not an image (we will provide it in the future, forever), the
> issue
> is size constraint - software grows faster and faster, we have more
> dependencies
> etc. -> means less software on LiveCD...
I hope to occasi
On Thu, 2010-08-12 at 14:32 -0400, Felix Miata wrote:
> The reason I started this thread is precisely because I have little tolerance
> for being stuck in last century's 1024x...@96dpi lowfi on a display I've been
> running 2048x1536 on for roughly a decade. Before xrandr, X could itself
> perform
On 12/08/10 19:19, Mike McGrath wrote:
How can we fix this? It's clearly not one group or one
> individual or we'd just go talk to them. This is a collective failure.
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both hard\virtual-ware.
On 12/08/10 19:19, Mike McGrath wrote:
How can we fix this? It's clearly not one group or one
> individual or we'd just go talk to them. This is a collective failure.
I don't think it's any failure, just that more ppl are finding problems
across a greater variety of both hard\virtual-ware.
On Thu, 2010-08-12 at 13:29 -0500, Jason L Tibbitts III wrote:
> > "BN" == Bill Nottingham writes:
>
> BN> I can't help but note that the slips have become more frequent as we
> BN> started to actually *have* release criteria to test against. We
> BN> didn't slip nearly as much when we weren'
commit 7dfb64501728fe5f414283fc4225f9846abb4431
Author: Paul Howarth
Date: Thu Aug 12 19:39:41 2010 +0100
Resurrect for EPEL-6
Package has disappeared from RHEL-6 as of the Beta 2 Refresh, so this
package,
a clone of what was in Beta 2, is being introduced in EPEL-6 to satisfy
Felix Miata (mrma...@earthlink.net) said:
> So users of absent or dysfunctional DDC and/or EDID should be committed to
> 800x600 or 1024x768 @96DPI until they replace their (quality, antique, still
> working just fine) displays
Just as a point, if the EDID/DDC is dysfunctional, then I don't think
On Thu, 12 Aug 2010, Jason L Tibbitts III wrote:
> > "BN" == Bill Nottingham writes:
>
> BN> I can't help but note that the slips have become more frequent as we
> BN> started to actually *have* release criteria to test against. We
> BN> didn't slip nearly as much when we weren't testing it.
On Thu, Aug 12, 2010 at 8:19 PM, Mike McGrath wrote:
> Since 2006 I counted 18 slips (I think one or two of those may just be a
> single slip listed twice). Lets not yell, lets not flame war, lets not
> point fingers. How can we fix this?
It isn't broken so there is nothing to fix; slipping to
On Thu, Aug 12, 2010 at 2:19 PM, Mike McGrath wrote:
... snip ...
> Since 2006 we've slipped at least 16-18 weeks by my count. That's more
> than half of a full release cycle.
>
Actually, I don't think that the slips in the releases have _accumulated_ to
be
'half' of a full release cycle' beca
On 2010/08/12 10:46 (GMT-0700) Adam Williamson composed:
> It's more or less dead. ajax technically maintains it, but it's right at
> the bottom of his priority list and we've been wanting to drop it for
> ages. It's useful for almost nothing these days, especially now GNOME
> has a mechanism for
On Thu, 12.08.10 12:06, Bill Nottingham (nott...@redhat.com) wrote:
>
> Lennart Poettering (mzerq...@0pointer.de) said:
> > > Yes, that is correct. An already built version on f15 will always be
> > > "newer" than anything coming up from f14.
> >
> > Can I "undo" such a build? I did that mostl
> "BN" == Bill Nottingham writes:
BN> I can't help but note that the slips have become more frequent as we
BN> started to actually *have* release criteria to test against. We
BN> didn't slip nearly as much when we weren't testing it.
To me this implies that we should begin testing earlier (o
On Thu, 12.08.10 22:10, Chen Lei (supercyp...@gmail.com) wrote:
> Hi Lennart,
Heya,
>
> I found that systemd-units depends on pkgconfig, is this dependency
> really needed for minimum systemd?
Yes, this is intended this way. udev does the same these days. We
consider .pc files simply a nice wa
Matthias Clasen (mcla...@redhat.com) said:
> > This is a collective failure.
>
> I'd like to question that premise. Why is it a failure if we adjust our
> release schedule to meet our release criteria ?
Well, ideally we'd be able to schedule such that we can accomplish
our release criteria wit
On Thu, 2010-08-12 at 13:19 -0500, Mike McGrath wrote:
> This is a collective failure.
I'd like to question that premise. Why is it a failure if we adjust our
release schedule to meet our release criteria ?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/m
Oct 6 2006: "Fedora Core 6 release date slip" -
http://lists.fedoraproject.org/pipermail/announce/2006-October/002243.html
Oct 16 2006: "Another slip in the FC6 schedule" -
http://lists.fedoraproject.org/pipermail/announce/2006-October/002248.html
Jul 11 2006: "FC6 test2 freeze slipping by a week
On Thu, 2010-08-12 at 17:07 +0100, Richard W.M. Jones wrote:
> On Thu, Aug 12, 2010 at 06:16:52PM +0400, Peter Lemenkov wrote:
> > Hello All!
> >
> > I'm currently in process of automatic enlisting of all ~10K Fedora Git
> > repos at Ohloh. Right now roughly 7% of repositories were added and
> > o
Hi, everyone. So, we have one bug remaining for Fedora 14 whose blocker
status is unclear:
https://bugzilla.redhat.com/show_bug.cgi?id=596985
Two reporters in the bug - John Reiser and Mike Chambers - and one
reporter from the list - Rui He,
http://lists.fedoraproject.org/pipermail/test/2010-Augu
On Thu, 2010-08-12 at 10:11 -0400, Felix Miata wrote:
> I updated system yesterday, installed scd just now:
>
> [init 3]# system-config-display
> File "/usr/share/system-config-display/xconf.py", line 27, in
> import xf86config
> File "/usr/lib/python2.7/site-packages/xf86config.py", line 1
On 2010/08/12 10:52 (GMT-0400) David Malcolm composed:
> On Thu, 2010-08-12 at 10:11 -0400, Felix Miata wrote:
>> I updated system yesterday, installed scd just now:
>> [init 3]# system-config-display
>> File "/usr/share/system-config-display/xconf.py", line 27, in
>> import xf86config
>>
On Thu, Aug 12, 2010 at 10:10:25PM +0800, Chen Lei wrote:
> I found that systemd-units depends on pkgconfig, is this dependency
> really needed for minimum systemd?
Please file things like this in bugzilla so they don't get lost in the chaos
of this discussion list.
--
Matthew Miller
Senior Sy
1 - 100 of 139 matches
Mail list logo
