On Tue, 2020-05-19 at 15:58 -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 18:55 -0400, Doug Ledford wrote:
> > > I guess we get to poke through everything built around the 17th
> > > and
> > > try
> > > to find a relevant change? :)
> >
>
On Tue, 2020-05-19 at 15:45 -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 18:16 -0400, Doug Ledford wrote:
> > But this is different, and it's the cause of your problem (well,
> > it's
> > the immediate cause anyway). The kernel-install script is failin
udev rpm packages should have an
explicit requires on libibverbs I think.
Anyway, at this point, I don't know if the rdma-core-owner people can
help. I think this is first in the hands of the systemd folks.
> DEBUG util.py:602: /var/tmp/rpm-tmp.6RiAo6: line 34: 2006782
> Segmentation fault
The arm32 platform literally does not support the memory primitives needed to
safely to RDMA. If we enable the support, and someone uses it, there is
nothing we can do to prevent them running the risk of memory corruption. So we
probably need to exclude arm32 from all these packages, or condit
On Sun, 2018-02-04 at 14:30 -0800, Kevin Fenzi wrote:
> On 02/04/2018 01:38 PM, Jan Kratochvil wrote:
> > On Sun, 04 Feb 2018 22:14:47 +0100, Doug Ledford wrote:
> > > cc1: fatal error: inaccessible plugin file plugin/annobin.so expanded
> > > from short plugin na
: that I
need to add with gcc-8.0.1 that I didn't know about? And if there is,
why isn't it part of the Build package group since the RPM macros the
build system defines are the ones telling gcc to use annobin?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B
x27;s where we stand on openmpi. Someone will have to fill me
in on mpich. I haven't done anything with mpich yet (it was added by
another employee, then transferred to me when that employee left the
company), so I will have to come up to speed.
Oh, and please leave me on the Cc: list.
On Sat, 2014-07-26 at 11:17 -0600, Kevin Fenzi wrote:
> libibverbs
> libmlx4
> libmthca
Taken.
--
Doug Ledford
GPG KeyID: 0E572FDD
signature.asc
Description: This is a digitally signed message part
--
devel mailing list
devel@lists.fedoraproject.
When a shutdown task isn't proceeding as planned on Fedora 19/rawhide,
am I the only one that feels like I'm staring down the monocle of a
Cylon and should be preparing to die? That or it's the hood from Kit
off of Knight Rider...
Either way, it's creepy ;-)
--
devel mailing list
devel@lists.fed
On 06/10/2013 04:43 AM, Lennart Poettering wrote:
> On Sun, 09.06.13 11:05, Doug Ledford (dledf...@redhat.com) wrote:
>
>> The audit system is just a more modern version of that same thing. And
>> the second you put any sort of exception into the audit rules, then you
>>
On 06/09/2013 11:42 AM, Matthew Garrett wrote:
> On Sun, Jun 09, 2013 at 11:05:44AM -0400, Doug Ledford wrote:
>
>> And really, we've spent more time on this thread than it would take
>> Lennart to fix PA. Just a quick stat and check of uid before trying to
>> re
On 06/09/2013 01:05 PM, Adam Williamson wrote:
> On Sun, 2013-06-09 at 16:44 +0200, Reindl Harald wrote:
>
>> where did you read this?
>
> Where Doug et al keep not responding to Lennart and Matthew's queries as
> to whether the correct fix is to the app or to the audit system, but
> keep repeati
On 06/09/2013 10:34 AM, Adam Williamson wrote:
> On Sun, 2013-06-09 at 10:03 -0400, Steve Grubb wrote:
>
>>> I don't think anyone wants these accesses to generate audit records. The
>>> question is whether the right way to fix that is to avoid those accesses
>>> in the first place or to provide a
On 06/09/2013 09:53 AM, Roberto Ragusa wrote:
> On 06/08/2013 04:13 PM, Doug Ledford wrote:
>>
>> Yes, but none of these results show the .12s time that your first
>> noatime test run showed in your original post. If you are now saying
>> that atime is faster than noa
On 06/08/2013 02:35 PM, Adam Williamson wrote:
> On Sat, 2013-06-08 at 09:25 -0400, Steve Grubb wrote:
>
>> Its not quite like this. What I need is the OS to be well behaved under
>> normal
>> conditions so that when problems come along they are easily spotted. Fedora
>> has been a fairly well
On 06/08/2013 10:29 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 10:13:45 AM Doug Ledford wrote:
>> Yes, but none of these results show the .12s time that your first
>> noatime test run showed in your original post. If you are now saying
>> that atime is faster than
On 06/08/2013 10:10 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 09:57:03 AM Doug Ledford wrote:
>> Bad test. The first run took the hit for getting the file info into
>> page cache, after that, everything was run from cache and you got the
>> second result above
On 06/08/2013 09:53 AM, Steve Grubb wrote:
> On Saturday, June 08, 2013 09:34:22 AM Steve Grubb wrote:
>> Does opening with noatime really make a measurable difference (assuming it
>> worked)? I suspect not since what we have now is 2 syscalls. It would
>> probably be faster to load icons without
On 05/21/2013 04:25 PM, Chris Murphy wrote:
>
> On May 21, 2013, at 2:07 PM, Reindl Harald wrote:
>
>>
>>
>> Am 21.05.2013 22:02, schrieb Chris Murphy:
>>> Maybe someone can explain to me the use case for ONBOOT= where its value
>>> isn't tied
>>> to the current network state. I wasted an inor
r it, it's a royal pain in
the ass. And have him read the openmpi spec file too, it really
exemplifies how ugly this stuff gets.
--
Doug Ledford
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 2/23/2012 8:52 AM, Michal Schmidt wrote:
> On 02/21/2012 06:31 PM, Doug Ledford wrote:
>> it honors all the LSB dependency tags in the SysV init scripts, and
>> my experience is that this is specifically where a number of the
>> emulation startup bugs exists.
>
> Wha
feature to me...it means that if an admin starts a
service manually for whatever reason (debugging, want to see output,
the systemd unit file won't allow the necessary interactive username
and password prompt, etc.), then it won't get stopped properly on
shutdown. That is not a feature, th
485
ibsim - https://bugzilla.redhat.com/show_bug.cgi?id=773492
--
Doug Ledford
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
- Original Message -
> Oh I figured if it was going to be dropped it would no longer be
> CRITPATH, but if it would remain that I would prefer not to have Mrs
> Ledford hunting me down .
You're probably safer that way... ;-)
--
Doug Ledford
GPG K
ght require the running kernel be what
it is building for and then you would *have* to wait until the first time that
particular kernel is booted to build the module.
So, long story short, there are difficulties, not the least of which is the
poorly understood usage of the %trigger ca
ould give me another CRITPATH package, and I'd sooner slit
my wrists.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
rfectly workable solution. You just don't like it on the basis of
your own ingrained FUD against the idea that isn't even based on realistic
future development of this dead end package.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
> https://fedorahosted.org/mailman/listinfo/autoqa-devel
>
> Here is the main webpage on autoqa
> http://fedoraproject.org/wiki/AutoQA
I've already volunteered for one project that's at least tangentially related
to AutoQA and I'm having a hard time fi
ed in the muck and going
nowhere at the moment?
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
the second because that's a huge gaping
security cluster fuck).
> not because it's necessary.
It's just as necessary as any of the other rescue tools we put on rescue CDs.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redha
lt because you won't care about the host OSes boot
loader installation (or lack thereof).
If anyone complains about a grub/grub2 binary in libguestfs, tell them it's a
necessary tool the base OS didn't want to provide reliably so you did what was
necessary.
--
Doug Ledfor
x27;t normally
install all of them. A user who bought the hardware in question could probably
suss out which package they need to satisfy the dependency if they were asked.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mail
t in support of Fedora's own
virtualization stack. Therefore, I would take your argument as basically "We
don't want it in the base OS any more, and we don't care about our
virtualization stack, so go away." I don't think he missed the point at all
her or not
there *is* a right automatic dependency.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
d D all provide foo, that the proper answer (whether
using zif or yum) would be to ask the user which they would prefer. Any
automated system is going to be prone to being tricked one way or another.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/
scale.
You may be right. Which, unfortunately, just makes me feel like an
outcast that doesn't belong.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
- Original Message -
> On Tue, 20 Sep 2011 15:19:29 -0400 (EDT)
> Doug Ledford wrote:
>
> ...snip...
>
>
> Which rpmdiff are we talking about here?
> The free/included in fedora one is not that great... it gives you
> files
> and deps that changed, but
ept* unit testing, there is
no ability for them to easily do an actual analysis of the changes and ma
ke an engineering decision versus a QA decision.
> thus we have bodhi
> and updates-testing as a gateway to get into the release.
It's a gateway, I just don't think it serves as usef
rball update when it was just a roll up bug fix release. A source
update that implements new features is another issue. The maintainer is in the
best position to know this and can note the distinction in the bodhi ticket.
> Looks like it would get things done.
That's what I thought ;
ot;test, report breakage, fix, retest" process to
be as fast as possible, and our current process moves at the speed of a salt
coated slug.
That's my proposed process for our early branched release. Thoughts?
--
Doug Ledford
GPG KeyID: CFBFF194
http://peop
fix, push, test" cycle goes much faster.
Note: I'm not putting my $.02 in towards either side, just playing devil's
advocate.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
- Original Message -
> On Mon, Sep 19, 2011 at 02:53:11PM -0400, Doug Ledford wrote:
>
> > This is incorrect. The whole reason the stage1.5 portion is an fs
> > compatible reader is so that you can update the stage2 file and it
> > will pick the changes
- Original Message -
> Matthew Garrett wrote:
> > The output of rpm -qf grub may be instructive.
>
> I suppose you mean rpm -ql grub…
That worked better. And I see your point. I was mistaken in thinking that the
grub files resided directly in /boot/grub.
--
devel mailing list
devel@li
- Original Message -
>
>
>
>
> On Mon, Sep 19, 2011 at 10:53 AM, Doug Ledford < dledf...@redhat.com
> > wrote:
>
>
>
>
> Like I said, not true. The grub package is designed to be updateable
> without requiring an mbr reinstall. What's
- Original Message -
> On Mon, Sep 19, 2011 at 12:44:58PM -0400, Doug Ledford wrote:
> > OK, technically it install the 1.5 or the 2.0 if you don't use a
> > 1.5
> > (if you install both the 1.5 and 2.0, then it patches the name of
> > the
> > 2.0 int
- Original Message -
> On Mon, Sep 19, 2011 at 10:51:26AM -0500, Matyas Selmeci wrote:
> > Kevin Kofler wrote on Mon, Sep 19, 2011 at 01:02:26PM +0200:
> > > Michael Schroeder wrote:
> > > > Sounds like you want weak dependencies (i.e. "Suggests" et al).
> > >
> > > In this case, I think d
- Original Message -
> On Fri, Sep 16, 2011 at 03:01:06PM -0400, Doug Ledford wrote:
> > On 9/15/2011 12:01 PM, Matthew Garrett wrote:
> > > On Thu, Sep 15, 2011 at 04:56:43PM +0100, Richard W.M. Jones
> > > wrote:
> > > The most obvious case w
uming grub is
installed, after all, it isn't guaranteed to be able to boot in the
future if you uninstall the grub rpm package after guest installation).
Of course, the virtual block devices in the guest would not be the same
as they would under the host with the guest block device
install and live on the host. As for
security, if you assume that the host is locked down tight with no
running services besides sshd and libvirtd, then it is arguably the
better place to have a tool like grub installed than in the guest which
might be running apache and considerably more
I've grown entirely too fed up with the CRITPATH approval process.
Here's my Fedora FESCo TRAC ticket requesting that the issue be solved
and providing a suggested solution. If you agree, you might want to put
your +1 in the ticket. If you disagree because you think you have a
better solution, pl
This could use some testing love. If it misses Fedora 16 final, it
won't be a huge setback. The only change between what's already in f16
and this updated package is the two bug fixes mentioned. I've tested
those fixes myself (my workstation didn't work properly until the fixes
went in, not that
On 8/12/2011 3:28 AM, Adam Williamson wrote:
> On Thu, 2011-08-11 at 19:40 -0400, Doug Ledford wrote:
>
>>> I've never got around to working up a coherent proposed modification and
>>> submitting it, though - if anyone else can, that'd be great.
>>
>&
ons. It's a pity that symbol versions are so
> painful to use that really only glibc makes any effort to do it.
libibverbs uses symbol versions quite nicely.
> Hilariously gcc _does_ let you specify symbol version in a __attribute__
> tag, but only on HP/UX on ia64. Thanks for
On 08/11/2011 05:42 PM, Tom Lane wrote:
>> On Wed, 2011-08-10 at 09:02 -0400, Doug Ledford wrote:
>>> Can we please either disable these nag messages or give developers the
>>> ability to push a package regardless of testing when it reaches nag age?
>
>> You h
On 08/11/2011 12:32 PM, Adam Williamson wrote:
> On Wed, 2011-08-10 at 09:02 -0400, Doug Ledford wrote:
>> Can we please either disable these nag messages or give developers the
>> ability to push a package regardless of testing when it reaches nag age?
>
> You have that abi
Can we please either disable these nag messages or give developers the
ability to push a package regardless of testing when it reaches nag age?
Original Message
Subject: [Fedora Update] [CRITPATH] [old_testing_critpath]
mdadm-3.1.3-0.git20100804.3.fc14
Date: Wed, 10 Aug 2011 00
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/20/2011 6:05 PM, Reindl Harald wrote:
>
>
> Am 20.07.2011 22:06, schrieb Doug Ledford:
>> On 07/15/2011 05:20 PM, Reindl Harald wrote:
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=253031
>>>
&
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/20/2011 4:13 PM, Jeff Spaleta wrote:
> On Wed, Jul 20, 2011 at 12:06 PM, Doug Ledford
> wrote:
>> Unfortunately, I was told I should remove the systemd support in
>> particular, so I did. Glad to hear it worked for you thou
On 07/15/2011 05:20 PM, Reindl Harald wrote:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=253031
>
> * Fri Jul 15 2011 Doug Ledford - 3.2.2-5
> - Merge rawhide mdadm to f15. Rawhide changelog preserved even though
> - the referenced versions do not exist in f15, rawhide
On 05/27/2011 10:43 AM, Albert Strasheim wrote:
> Hello
>
> On Fri, May 27, 2011 at 3:52 PM, Doug Ledford wrote:
>> I just need some time to get updates in. However, that being said, I
>> totally ignore OFED. I pull packages from upstream and I do *not* get
>> anythi
ore their custom hacks were reviewed and
then modified and then accepted upstream. That ended my relationship
with their offerings.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://
On 04/10/2011 01:23 PM, Sven Lankes wrote:
> On Sun, Apr 10, 2011 at 12:45:56PM -0400, Doug Ledford wrote:
>
>> And here we are, about to go down the same road again. I have an update
>> in updates-testing, it's getting no love, and the package that's in the
>>
Comment inline below:
Sent from my iPhone
On Apr 10, 2011, at 4:34 PM, Adam Williamson wrote:
> On Sun, 2011-04-10 at 12:45 -0400, Doug Ledford wrote:
>
>> And here we are, about to go down the same road again. I have an update
>> in updates-testing, it's getting n
Apr 10, 2011, at 4:37 PM, Adam Williamson wrote:
> On Sun, 2011-04-10 at 15:01 -0400, Doug Ledford wrote:
>> The bug I'm looking at right now is specifically against the live
>> image, so no I can't test that with something in updates testing. It
>> needs to make i
um wrote:
>> On 10 April 2011 20:01, Doug Ledford wrote:
>>> The bug I'm looking at right now is specifically against the live image, so
>>> no I can't test that with something in updates testing. It needs to make it
>>> to the base before it gets
PM, Björn Persson wrote:
> Doug Ledford wrote:
>> Now I'm seeing new bugs trickle in about mdadm in the live image, and I
>> have no clue if there is something I need to fix because I haven't
>> gotten my update pushed to stable yet so these people are running
>>
ckage fixes all
the known issues should you freeze it and require anything like this
critpath process. But as long as the package in the alpha/beta is known
to still be broken, then get the hell out of the maintainer's way and
let us do our job.
--
Doug Ledford
GPG KeyID:
mdadm work properly with the new
: systemd and with the tmpfs based /var/run and
: /var/lock. Please push to stable prior to F15 final.
Submitter: dledford
Submitted: 2011-03-28 15:44:22
https://admin.fedoraproject.org/updates/mdadm-3.1.5-1.fc15
--
Doug Ledford
a production machine which isn't already set up that way.
>
> Kevin Kofler
>
For non-boot devices, loopback works. You only need the hardware if you
are testing boot time capabilities (which, admittedly, is the far more
important aspect of testing for this package).
--
On 12/01/2010 05:17 PM, Adam Williamson wrote:
> On Wed, 2010-12-01 at 16:55 -0500, Doug Ledford wrote:
>
>> The comparison is 100% fair because it points out the fundamental
>> problem with the current policy: if you don't have a paid staff of
>> testers to make sur
On 12/01/2010 04:35 PM, Adam Williamson wrote:
> On Wed, 2010-12-01 at 16:22 -0500, Doug Ledford wrote:
>
>> If the ticket can be allowed to languish that long, then I don't feel in
>> the least bit guilty that I didn't drop my other Red Hat
>> responsibilitie
On 12/01/2010 04:40 PM, Luke Macken wrote:
> On Wed, Dec 01, 2010 at 10:41:20AM -0800, Adam Williamson wrote:
>> On Wed, 2010-12-01 at 13:23 -0500, Doug Ledford wrote:
>>
>>> That being said, F14 went out with a broken mdadm *purely* because of
>>> this polic
On 12/01/2010 01:41 PM, Adam Williamson wrote:
> On Wed, 2010-12-01 at 13:23 -0500, Doug Ledford wrote:
>
>> That being said, F14 went out with a broken mdadm *purely* because of
>> this policy.
>
>> Evidently my update was approved somewhere along the way, but becaus
ntly my update was approved somewhere along the way, but because of
the volume of bodhi spam I get, I missed it. So I'm not sure if it
could have made F14 final or not, but I know it didn't because I was
working on other things at the time.
Bodhi critpath restrictions == -1000 in their
On 11/23/2010 04:32 PM, Lennart Poettering wrote:
> On Tue, 23.11.10 16:12, Doug Ledford (dledf...@redhat.com) wrote:
>
>> On 11/23/2010 03:48 PM, Lennart Poettering wrote:
>>> Heya!
>>>
>>> I hereby want to let everybody know that in the next days I wil
ect.org/wiki/Features/var-run-tmpfs
Will the tmpfs mounts be available in the initramfs, or only on the
running system?
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.co
- "Richard W.M. Jones" wrote:
> On Wed, Nov 17, 2010 at 10:29:56PM -0500, Gregory Maxwell wrote:
> > Most code is not performance critical.
>
> Much more code than you think is performance critical, particularly
> when I can throw up 1000 instances of it in the cloud.
>
> /me considers makin
exceed) the packager's needs for at least another 13
> releases or so... :-)
>
> Oh, yeah, and Jesse - thank you, for now people can finally stop
> mumbling blames my way. ;)
No!!! That doesn't stop. The crazy Romanian is to blame for everything!
--
Doug Ledford
esting repo, the package
link in the bodhi ticket will allow you to directly download the packages.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infinib
On 03/09/2010 07:46 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> Things like the libata kernel change and KDE 3 to 4 migration are
>> intentional events
>
> That's the whole problem. Under our current model, we have places and times
> where to perform those i
o, I can see where some changes simply don't warrant a bunch
of strict rules. We can have these changes even in critpath packages,
but the whole point of critpath is that we've isolated a set of packages
that are so important that it's worth it to take a little extra time
just to make
r across the board and give up.
I'm sorry Kevin, but you and I will simply have to agree to disagree. I
will *not* capitulate to your stance on this issue.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific
On 03/08/2010 03:31 PM, Adam Williamson wrote:
> On Mon, 2010-03-08 at 12:14 -0500, Doug Ledford wrote:
>> On 03/08/2010 11:05 AM, Adam Williamson wrote:
>>> If you think the poll is wrong - provide some data to disprove it.
>>
>> I'm sorry, but that's a sc
s "gratuitous" and "reasonable", and I have no
doubt that this wording change would effect the results of the poll (and
probably drastically so). To be a valid poll, we have to be precise
enough that people know what they are voting on without the wording
leading their thoughts.
--
'stable/less updates' Fedora don't
> frequent things like the forums or users list. Sure, they might search
> it or post a question when they run into an issue, but they are more
> likely to spend their time... well, using their machine.
Indeed. I can't vot
On 03/05/2010 03:58 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> It comes with less extra work than doing two update streams. Face it,
>> there is *no* solution to this problem that both solves the issue for
>> both parties involved and does not include at least *some*
e that even if
we made a policy that Fedora was primarily stable once released, that
there would always be exceptions to that rule and things that should be
updated more aggressively. So I would not advocate for any policy that
was absolute and inflexible. There should be room for human judgment to
On 03/05/2010 04:49 AM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> So, I'm going to reiterate my policy suggestion:
>>
>> Make Fedora releases (all of them) stable in nature, not semi-rolling.
>> Make rawhide consumable as a semi-rolling release itself.
>
&
On 03/04/2010 06:27 PM, Kevin Kofler wrote:
> Doug Ledford wrote:
>> But let's be clear. That's a *policy* decision. One of the things that
>> got very confusing in the previous thread(s) was the intermixing of
>> policy decisions and technical issues. For inst
by other people. Mike
McGrath's snapshot proposal and Matt Domsch's Slowing rate of change in
older releases proposal are the two I would pair with my proposal in
order to satisfy both groups. I don't see any reason to rehash them here.
--
Doug Ledford
GPG KeyID
ate styles) and your own.
I will probably both send my proposal here and post it there. But it
won't be until later tonight, I have to leave for about 5 hours now :-/
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband s
On 03/03/2010 04:40 PM, Tom "spot" Callaway wrote:
> On 03/03/2010 04:30 PM, Doug Ledford wrote:
>> So while I agree that some of the posts where people are simply
>> attacking other people need to stop, I can't agree that this thread has
>> reached a
e trying to
satisfy two groups and actually satisfying none.
That's why things can't just stay the way they are.
--
Doug Ledford
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat
hread has
reached a stage where it is advisable to stop constructive discussions.
I would argue that it's necessary to continue constructive discussions
in order to reach the stage where a wiki page and proposals makes sense.
--
Doug Ledford
GPG KeyID: CFBFF194
http://peopl
gs are actually bad enough
to push people to opt for a different option.
Well, if either group doesn't hold at least a reasonable number of
members though, it might not be worth it to do any sort of technical
solution to the issue as the benefit might not cover the implementation
On 03/02/2010 04:25 AM, Panu Matilainen wrote:
> On Tue, 2 Mar 2010, Kevin Kofler wrote:
>
>> Doug Ledford wrote:
>>> Fixes my problem
>>> Works for me (someone testing that didn't necessarily have any of the
>>> problem supposedly fixed by this up
On 03/01/2010 05:01 PM, Jesse Keating wrote:
> On Mon, 2010-03-01 at 16:51 -0500, Doug Ledford wrote:
>> To be pedantic, Fedora is what it is. What the leadership has to say
>> doesn't really matter in terms of what Fedora *is*, only in terms of
>> what Fedora is *sup
ing about test coverage or
anything like that. Also FMP/DFMP karma against a bug could be noted
both in the bodhi ticket as well as in the bug itself with a resultant
VERIFIED/FAILS_QA toggle to the bug status.
--
Doug Ledford
GPG KeyID: CFBFF194
http://peo
down into the stable releases.
At that point you would know for sure what Fedora is, not what it's
supposed to be. I say this because, obviously, different people read
the part about First differently and do different things.
--
Doug Ledford
GPG KeyID: CFBFF194
http://peo
nt adds complexity to the early boot process which is
something you always want to be as simple and failproof as possible, so
creating a new namespace for the sake of anal retentiveness about naming
is in fact counter productive and the wrong thing to do. As such, I say
suck it up and deal with /
1 - 100 of 102 matches
Mail list logo
