Richard W.M. Jones wrote:
> I'm not convinced yet this is a glibc issue. It could be a problem in
> the threaded work-queue code in git-grep which is just exposed by the
> change in glibc. No one will know until we finally diagnose the bug.
The analysis in the bug is now that this is indeed a bu
On Tue, 2011-10-25 at 08:32 +0100, Richard W.M. Jones wrote:
> You snipped the part where Kevin wrote "[...] if the maintainer
> demonstrates incompetence at taking these decisions, the offending
> maintainer needs to be replaced." The problem here appears to be a
> human one, not something that
On Mon, Oct 24, 2011 at 11:34:46PM +0200, Jim Meyering wrote:
> Jim Meyering wrote:
> > Adam Williamson wrote:
> >> ... The only breakage
> >> in one which was approved was to do with compiling things - which, sure,
> >> is a pain in the ass, but it's not the kind of problem critpath was
> >> intro
On Mon, Oct 24, 2011 at 10:46:31AM -0700, Adam Williamson wrote:
> On Mon, 2011-10-24 at 18:50 +0200, Kevin Kofler wrote:
> > Adam Williamson wrote:
> > > We have lots of suggestions. As I've said at least fifty times, it's
> > > pointless going too far with the slapping of band-aids on the current
Jim Meyering wrote:
> Adam Williamson wrote:
>> ... The only breakage
>> in one which was approved was to do with compiling things - which, sure,
>> is a pain in the ass, but it's not the kind of problem critpath was
>> introduced to deal with in the first place.
>
> The problem is bigger than it f
Adam Williamson wrote:
> ... The only breakage
> in one which was approved was to do with compiling things - which, sure,
> is a pain in the ass, but it's not the kind of problem critpath was
> introduced to deal with in the first place.
The problem is bigger than it first seemed, and still not fi
On Mon, 2011-10-24 at 18:50 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > We have lots of suggestions. As I've said at least fifty times, it's
> > pointless going too far with the slapping of band-aids on the current
> > karma system, because it's fundamentally too simplistic: it's never
Adam Williamson wrote:
> We have lots of suggestions. As I've said at least fifty times, it's
> pointless going too far with the slapping of band-aids on the current
> karma system, because it's fundamentally too simplistic: it's never
> going to be perfect and there is a definite point of diminish
On Mon, 2011-10-24 at 09:51 -0500, Chris Adams wrote:
> Once upon a time, Adam Williamson said:
> > Oh - and remember, the goal of the critpath process is to ensure we
> > don't send out updates that break people's systems. It worked fine in
> > this case: no glibc update which breaks systems was
On Mon, 2011-10-24 at 11:06 +0200, Henrik Nordström wrote:
> sön 2011-10-23 klockan 23:45 -0700 skrev Adam Williamson:
>
> > This would cause significant problems around crunch times. We would wind
> > up having to have releng super-push far more updates because we simply
> > don't always *have* t
Once upon a time, Adam Williamson said:
> Oh - and remember, the goal of the critpath process is to ensure we
> don't send out updates that break people's systems. It worked fine in
> this case: no glibc update which breaks systems was approved. All the
> ones which caused major runtime breakage g
sön 2011-10-23 klockan 23:45 -0700 skrev Adam Williamson:
> This would cause significant problems around crunch times. We would wind
> up having to have releng super-push far more updates because we simply
> don't always *have* three days to wait to hit deadlines.
note that I only proposed automa
On 10/24/2011 02:47 AM, Henrik Nordström wrote:
> sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
>
>> The fail(*), imo, was with 12.999 going stable containing known-regressions.
>> So, any suggestions, if any, to prevent any similar series of events?
>
> My suggestions:
>
> Disable automatic
On Sun, Oct 23, 2011 at 05:04:48PM -0500, Rex Dieter wrote:
> So, any suggestions, if any, to prevent any similar series of events?
Do the development in Rawhide and cherry pick only well-tested bug fix
commits to the stable branch (F16 in this case).
Rich.
--
Richard Jones, Virtualization Grou
On Sun, Oct 23, 2011 at 4:14 AM, Kevin Kofler wrote:
> Jim Meyering wrote:
>> glibc-2.14.90-12.999, which has just made it to stable provokes a
>> hard-to-diagnose (for me at least) problem.
>>
>> While most things work, and it fixed two problems that affected me,
>> it caused me some frustration:
On Sun, 2011-10-23 at 23:43 -0700, Adam Williamson wrote:
> On Sun, 2011-10-23 at 04:14 +0200, Kevin Kofler wrote:
>
> > The fact that a glibc with showstoppers of this kind got pushed to stable
> > shows that the karma system does not work at all. It just hinders getting
> > legitimate fixes ou
On Sun, 2011-10-23 at 17:04 -0500, Rex Dieter wrote:
> The fail(*), imo, was with 12.999 going stable containing known-regressions.
> So, any suggestions, if any, to prevent any similar series of events?
We have lots of suggestions. As I've said at least fifty times, it's
pointless going too fa
On Mon, 2011-10-24 at 02:47 +0200, Henrik Nordström wrote:
> Don't automatically push to stable until at least X days (3?) have
> passed, enabling sufficient time for regressions to be detected. Package
> maintainer can initiate push earlier by "Push to stable" if needed and
> confident there is n
On Sun, 2011-10-23 at 04:14 +0200, Kevin Kofler wrote:
> The fact that a glibc with showstoppers of this kind got pushed to stable
> shows that the karma system does not work at all. It just hinders getting
> legitimate fixes out and does nothing to stop regressions. glibc is even
> critpath, y
On 10/23/2011 07:47 PM, Henrik Nordström wrote:
> Disable automatic push to stable when there is any negative karma,
> requiring the package maintainer to initiate the push even if karma
> kriteria have been met.
This idea has been suggested:
https://fedorahosted.org/bodhi/ticket/618
--
devel mai
sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
> The fail(*), imo, was with 12.999 going stable containing known-regressions.
> So, any suggestions, if any, to prevent any similar series of events?
My suggestions:
Disable automatic push to stable when there is any negative karma,
requiri
Kevin Kofler wrote:
> Jim Meyering wrote:
>> glibc-2.14.90-12.999, which has just made it to stable provokes a
>> hard-to-diagnose (for me at least) problem.
>>
>> While most things work, and it fixed two problems that affected me,
>> it caused me some frustration:
>>
>> https//bugzilla.redhat.c
Am 23.10.2011 04:14, schrieb Kevin Kofler:
> Jim Meyering wrote:
>> glibc-2.14.90-12.999, which has just made it to stable provokes
>> a hard-to-diagnose (for me at least) problem.
>>
>> While most things work, and it fixed two problems that affected
>> me, it caused me some frustration:
>>
>> ht
Jim Meyering wrote:
> glibc-2.14.90-12.999, which has just made it to stable provokes a
> hard-to-diagnose (for me at least) problem.
>
> While most things work, and it fixed two problems that affected me,
> it caused me some frustration:
>
> https//bugzilla.redhat.com/747377
glibc-2.14.90-12.99
On Fri, Oct 21, 2011 at 1:55 PM, David Airlie wrote:
>> > The Glibc package maintainer. I'm pretty sure he understands
>> > upstream, and FESCo should probably start the discussion with him
>> > first anyway.
I've started a dialog with the glibc packager and explained the
concerns I'm seeing.
-
>
> > The Glibc package maintainer. I'm pretty sure he understands
> > upstream, and FESCo should probably start the discussion with him
> > first anyway.
>
> I'm not exactly sure what glibc "upstream" (defined as people without
> commit rights to Fedora git) have to do with this at all. The i
Josh Boyer writes:
> On Fri, Oct 21, 2011 at 1:21 AM, Rahul Sundaram wrote:
>> FESCo is the entity which can have that conversation with Glibc upstream
>> on behalf of Fedora. Who else can?
> The Glibc package maintainer. I'm pretty sure he understands
> upstream, and FESCo should probably sta
On Fri, Oct 21, 2011 at 1:21 AM, Rahul Sundaram wrote:
>> I'd vote for #1, but that's a much longer conversation that should be
>> had upstream and before we even get close to bringing it to FESCo.
>
> FESCo is the entity which can have that conversation with Glibc upstream
> on behalf of Fedora.
On 10/20/2011 06:05 AM, Josh Boyer wrote:
>
> Except that Fedora _has_ been glibc's development platform for as long
> as I can remember. The Fedora project might not think so, but it's
> exactly what upstream glibc does.
I am aware of this but our policies have changed and either they need to
On Wed, 2011-10-19 at 20:35 -0400, Josh Boyer wrote:
> Except that Fedora _has_ been glibc's development platform for as long
> as I can remember. The Fedora project might not think so, but it's
> exactly what upstream glibc does.
Indeed, this has been the case since it was still called Red Hat
On Wed, Oct 19, 2011 at 8:35 PM, Josh Boyer wrote:
> On Wed, Oct 19, 2011 at 5:51 PM, Rahul Sundaram wrote:
>> On 10/20/2011 01:06 AM, Adam Williamson wrote:
>>> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
>>>
What did you downgrade to ?
AFAIK Several people had to downgrade fr
On Wed, Oct 19, 2011 at 5:51 PM, Rahul Sundaram wrote:
> On 10/20/2011 01:06 AM, Adam Williamson wrote:
>> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
>>
>>> What did you downgrade to ?
>>> AFAIK Several people had to downgrade from -11 because of nsswitch
>>> issues ... seem glibc is not
On Thu, 2011-10-20 at 00:30 +0200, Michael Schwendt wrote:
> On Wed, 19 Oct 2011 23:36:43 +0200, HA (Heiko) wrote:
>
> > IMHO Rawhide should be the only place where version-control-snapshots
> > of such an important component like glibc should be allowed.
> >
> > Maybe it would be better to let t
On Wed, 19 Oct 2011 23:36:43 +0200, HA (Heiko) wrote:
> IMHO Rawhide should be the only place where version-control-snapshots
> of such an important component like glibc should be allowed.
>
> Maybe it would be better to let the value of positive karma depend on
> the severity of the package. Tha
On 10/20/2011 01:06 AM, Adam Williamson wrote:
> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
>
>> What did you downgrade to ?
>> AFAIK Several people had to downgrade from -11 because of nsswitch
>> issues ... seem glibc is not in good shape :-(
>
> You get to pick your breakage. If glib
On Wed, 2011-10-19 at 23:36 +0200, Heiko Adams wrote:
> Am 19.10.2011 23:09, schrieb Richard W.M. Jones:
> > On Wed, Oct 19, 2011 at 12:36:36PM -0700, Adam Williamson wrote:
> >> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
> >>
> >>> What did you downgrade to ? AFAIK Several people had to
Am 19.10.2011 23:09, schrieb Richard W.M. Jones:
> On Wed, Oct 19, 2011 at 12:36:36PM -0700, Adam Williamson wrote:
>> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
>>
>>> What did you downgrade to ? AFAIK Several people had to
>>> downgrade from -11 because of nsswitch issues ... seem glib
On Wed, Oct 19, 2011 at 12:36:36PM -0700, Adam Williamson wrote:
> On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
>
> > What did you downgrade to ?
> > AFAIK Several people had to downgrade from -11 because of nsswitch
> > issues ... seem glibc is not in good shape :-(
>
> You get to pick y
On Wed, 2011-10-19 at 15:25 -0500, Bruno Wolff III wrote:
> On Wed, Oct 19, 2011 at 12:36:36 -0700,
> Adam Williamson wrote:
> >
> > You get to pick your breakage. If glibc maintainers would kindly stop
> > pulling random git snapshots into a pending stable release that would be
> > nice, but t
On Wed, Oct 19, 2011 at 12:36:36 -0700,
Adam Williamson wrote:
>
> You get to pick your breakage. If glibc maintainers would kindly stop
> pulling random git snapshots into a pending stable release that would be
> nice, but then, I'd also like a solid gold toilet and that doesn't
> appear to be
Simo Sorce wrote:
> On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
...
>> To recover an F16 system that works better, I ran this:
>>
>> yum downgrade glibc glibc-static glibc-devel glibc-common glibc-headers \
>> glibc-utils nscd
>
> What did you downgrade to ?
> AFAIK Several people
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
> What did you downgrade to ?
> AFAIK Several people had to downgrade from -11 because of nsswitch
> issues ... seem glibc is not in good shape :-(
You get to pick your breakage. If glibc maintainers would kindly stop
pulling random git snapsho
On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
> I spent too many hours debugging this today, so feel obliged to warn
> about this. Plus, I feel a little guilty for giving it positive
> karma initially. Today's -1 was too late.
>
> glibc-2.14.90-12.999, which has just made it to stable p
I spent too many hours debugging this today, so feel obliged to warn
about this. Plus, I feel a little guilty for giving it positive
karma initially. Today's -1 was too late.
glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.
While most
44 matches
Mail list logo
