[chef] Re: Re: Migrating mailing list


Chronological Thread 
  • From: "aL." < >
  • To:
  • Subject: [chef] Re: Re: Migrating mailing list
  • Date: Wed, 4 Sep 2013 13:35:29 +0100

My vote to the archive the old stuff! The confirmation mail went to my spam folder on gmail.

--
Si necesitas una máquina para hacer algo y no la compras al final te darás cuenta de que has pagado lo mismo y no tienes la máquina.--Henry Ford
Alberto


On Wed, Sep 4, 2013 at 11:17 AM, Mathieu Martin < " target="_blank"> > wrote:
Agreed about the pack-rat thing.

For the record, my "confirm subscribe" link didn't get shoved into spam by Gmail.

Mat


On Wednesday, September 4, 2013, Adam Jacob wrote:
Agreed. We can always publish the archive statically.

Adam

-----Original Message-----
From: Lamont Granquist < >
Reply-To: " " < >
Date: Tuesday, September 3, 2013 5:53 PM
To: " " < >
Subject: [chef] Re: Migrating mailing list

>I sent this to Nathen and he requested I forward this on to the mailing
>list:
>
>On 9/3/13 1:18 PM, Nathen Harvey wrote:
>> We've looked at using Google Groups to host our fancy new mailing lists
>> but that doesn't seam feasible primarily because it's going to be nearly
>> impossible to cleanly migrate all of our existing messages to Google
>> Groups.
>>
>Does that have to be a requirement?
>
>If the old mailing list archives are kept around and searchable via
>google search on the web the information can still be found.  As time
>goes on the utility of that old information decays and will eventually
>become more of a hindrance than its worth anyway.  I don't see why we
>need a pack-rat mentality towards information here.
>
>...
>
>To expand a little bit by analogy: I solved my problem with having 20
>years worth of accumulated cables in buckets in my apartment by keeping
>the ones that were being used and recycling all the rest, and I was
>pretty brutal about it and only kept some spare ethernet and USB cables
>and tossed most everything else. Of course a week later I needed an
>adapter that I had just gotten rid of so I had to re-buy it on Amazon,
>but I haven't missed a cable since then and I've got significantly less
>clutter and all my 9-pin serial cables, old SCSI ribbon connectors and
>RGB composite video connectors are no longer cluttering my apartment (if
>I really need a 9-pin serial cable I can go down to re-PC and buy one of
>my old ones back...  and my ego doesn't need to center around being the
>guy who can come up with one at a moments nice...)
>
>Recently, I noticed that if you typed "install chef" into google the top
>hit on search was for the old instructions on installing chef 10.x open
>source server. I also found that people were still blogging about how
>chef was difficult to install and citing that page as evidence of it.
>That came about a year after doing all the work to create omnibus and
>make the chef installation process much easier, and hanging onto that
>old information might have been keeping a few people who still use 10.x
>server happy, but was doing so at the expense of every single new user
>of chef out there.  That is information that is net doing substantial
>harm rather than being helpful.
>
>You can see this on google when you find people googling "<subject>
>2013" to try to find recent information, because blog posts on ruby, or
>whatever, from 2007 often aren't at all relevant anymore.  I want to
>know about this years segfaulting bug, not one from a decade ago.
>
>So, if we just froze the mailing list it'll be a bit harder for awhile
>to find useful information from the few months prior to the cutover --
>but two years later all those old messages are going to mostly be
>useless clutter and misinformation anyway.  There may be a few gems left
>at that point, but the bulk of the information is not going to be that
>useful.  I don't necessarily suggest deleting the old mailing list
>archives, but I don't think its wise to make decisions about its
>replacement based on the requirement to preserve all the data
>indefinitely.
>
>There seems to be an implicit assumption that the value of information
>is always positive, even though it may approach zero and that all
>information should be kept and preserved if at all possible.  I actually
>see information that isn't curated as crossing the zero point and
>becoming of negative value over time and that negative number constantly
>getting larger and larger over time as it clutters up search results and
>makes old wikis useless until they are ultimately abandonded because
>nobody can take a weed-whacker to them and delete old information (


--
Rock Solid Ops: development & operations consulting for Ruby on Rails




Archive powered by MHonArc 2.6.16.

§