On Sat, 29 May 2010, David wrote:

Now I'm able to update device-mapper on i386 machine, BTW please find this post..

"[CentOS] metadata cache corruption: cleared -> fixing in progress"

Thank you for pointing people at a solution that should largely (mod residual mirror skew and local 'dinking' on yum configurations) work at this point, David

The information relayed through the day in IRC and on the main mailing list reflected what was known as it was known, what was likely, and how it was being approached.

In back control channels, the CentOS team was studying the matter, testing retrievals, passing updates to public facing parts of the group, and updating findings and possible fixes (and thus eta to convergences). This was available and passed along to public facing team members as the earth rotated through the day. Let's consider it an unplanned trial shift in approach toward more openness on matters which have historically been less visible, and see how it worked out

There were at most handful of 'non-insider' posters today (Heller, Roth, Cox, Nichols, Charm) and I think three relevant bugs, which bugs should all be addressed by now. As one person noted: 'The world was not coming to an end' but I see: 16:58:06 UTC Heller "*ALL* of the public mirrors are broken"

later 01:39:51 UTC next UTC day: "*I* never claimed it was the end of the world. Just noticed a problem and posted a question to the list about it"

<dryly>and this knowledge of ALL mirrors with just a dial-up connection</> That is sure not how I read his Chicken Little assertion; I see a cry of 'Wolf' and alarmism as a reward

21:30:22 UTC Byrne (broken threading) "Does not work"

with a repository selection that looks VERY skewed to only one: centos.mirror.iweb.ca

That single mirror from our dispatch code is possible, but pretty unlilkely; if in a bug I might run down what is in play to have produced it. It MAY indicate that the 'staleness' was noted by the scripts that update the dispatcher, from the known skew, as the scripts noted the matter as well and dialled back repository archives handed out. But there should have been more than just one show up ... if that one is so overwhelming close that it 'always wins', there is a design problem because one loses the diversity needed to recover from one stale mirror [interrupting the pulls with a ^C to force a failover can help there, but no-one reads that part of the doco ;) ]

If in IRC, a couple seconds check would tell the tale about the 'pristine' or other nature of the yum configuration in play; if a bug were filed, a similar result because I'd drop the same questions back on the reporter to get a reproducer and visibility into their configuration changes, if any, from stock.

Instead, we get the drive by complaint and the load in an intentionally non-synchronous medium [email]. This is a venue where it just does not make sense to respond to 'noise'

No win there

My $0.02

-- Russ herrold

On 05/29/2010 12:53 AM, R P Herrold wrote:

The information relayed through the day in IRC and on the main mailing list reflected what was known as it was known, what was likely, and how it was being approached.

In back control channels, the CentOS team was studying the matter, testing retrievals, passing updates to public facing parts of the group, and updating findings and possible fixes (and thus eta to convergences). This was available and passed along to public facing team members as the earth rotated through the day. Let's consider it an unplanned trial shift in approach toward more openness on matters which have historically been less visible, and see how it worked out

OK, I'm curious. What is this "main mailing list"? And what are the "public facing parts of the group" and "public facing team members"? The way you describe it, it sounds as though you feel that passing information around within the clique counts as "openness". I hope that's not what you intended to imply.

I'll confess I didn't look on IRC. The problem I have with IRC is that I have to sit on there all day or risk missing what might be a significant part of the discussion. I read this mailing list as a newsgroup on gmane.org, and there I can look back at the entire discussion at any time. There's no equivalent I know of for that on IRC.

There were at most handful of 'non-insider' posters today (Heller, Roth, Cox, Nichols, Charm) and I think three relevant bugs, which bugs should all be addressed by now.

I guess I just don't get it. A handful of non-insiders post about an issue that's affecting all i386 users, and that's a problem?? The most significant "insider" post I saw here blamed the issue on mirror lag and basically told anyone who had a problem with that to go away. That leaves the impression that the problem is expected to correct itself in due time and that no other action is needed. I really hope you did not take offense at my pointing out evidence that this appeared to be something other than mirror lag.

At Sat, 29 May 2010 14:57:18 -0500 CentOS mailing list centos@centos.org wrote:

---Executing: recode

On May 29, 2010, at 10:01 AM, Robert Nichols wrote:

...

OK, I'm curious. What is this "main mailing list"? And what are the "public facing parts of the group" and "public facing team members"? The way you describe it, it sounds as though you feel that passing information around within the clique counts as "openness". I hope that's not what you intended to imply.

I'll confess I didn't look on IRC. The problem I have with IRC is that I have to sit on there all day or risk missing what might be a significant part of the discussion. I read this mailing list as a newsgroup on gmane.org, and there I can look back at the entire discussion at any time. There's no equivalent I know of for that on IRC.

FWIW, I *DID* go to IRC instead of the mailing list, and someone there with a really condescending attitude treated me like an idiot for not checking the mailing list first. I agree that there should be some clearer definition on the official support website as to the first point of contact for people trying to resolve these things in near-realtime.

I don't even bother with IRC -- it is close to useless over dial-up, since I cannot just sit there tieing up my (only) phone line. Sending an E-Mail to the mailing list is far easier -- I can send it out and then check back a few hours or a day later. It is not like not being able to update the two packages for a few hours or days was any sort of problem for me -- I just wanted to get the update done, eventually, presuming that the update represented some important bug or security fix.

The fact the the IRC people tell users to go check the mailing list, and mailing list people tell people to go check IRC sickens me. I don´t mind having to use one or the other, but it should be more clear.

--

Jeffrey A. Gipson (RHCE) T. (512) 827-8750

---

This message contains data in an unrecognized format, image/jpeg, which is being decoded and written to the file named "/home/heller/Mail/Attachments/red_hat_cert_eng_logo-clr-email.jpg". If you do not want this data, you probably should delete that file. Wrote file /home/heller/Mail/Attachments/red_hat_cert_eng_logo-clr-email.jpg

(via Mail.app)

This message contains data in an unrecognized format, application/pkcs7-signature, which is being decoded and written to the file named "/home/heller/Mail/Attachments/215-smime.p7s". If you do not want this data, you probably should delete that file. Wrote file /home/heller/Mail/Attachments/215-smime.p7s MIME-Version: 1.0

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos