From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?iso-8859-2?B?o3VrYXN6IE1pZXJ6d2E=?= Subject: Re: metadata plugins (was Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion) Date: Fri, 28 Jul 2006 22:58:09 +0200 Message-ID: References: <200607281402.k6SE245v004715@laptop13.inf.utfsm.cl> <44CA31D2.70203@slaphack.com> <44C9FB93.9040201@namesys.com> <44CA6905.4050002@slaphack.com> <44CA126C.7050403@namesys.com> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: list-help: list-unsubscribe: list-post: Errors-To: flx@namesys.com In-Reply-To: <44CA126C.7050403@namesys.com> List-Id: Content-Type: text/plain; format="flowed"; delsp="yes"; charset="iso-8859-1" To: "reiserfs-list@namesys.com" Dnia Fri, 28 Jul 2006 15:34:36 +0200, Hans Reiser =20 napisa=B3: > Let me put it from my perspective and stop pretending to be unbiased, so > others can see where I am coming from. No one was interested in our > plugins. We put the design on a website, spoke at conferences, no one > but users were interested. No one would have conceived of having > plugins if not for us. Our plugins affect no one else. Our > self-contained code should not be delayed because other people delayed > getting interested in our ideas and now they don't want us to have an > advantage from leading. If they want to some distant day implement > generic plugins, for which they have written not one line of code to > date, fine, we'll use it when it exists, but right now those who haven't > coded should get out of the way of people with working code. It is not > fair or just to do otherwise. It also prevents users from getting > advances they could be getting today, for no reason. Our code will not > be harder to change once it is in the kernel, it will be easier, because > there will be more staff funded to work on it. > > As for this "we are all too grand to be bothered with money to feed our > families" business, building a system in which those who contribute can > find a way to be rewarded is what managers do. Free software > programmers may be willing to live on less than others, but they cannot > live on nothing, and code that does not ever ship means living on =20 > nothing. > > If reiser4 is delayed enough, for reasons that have nothing to do with > its needs, and without it having encumbered anyone else, it won't be > ahead of the other filesystems when it ships. > It just hited me that 90% of mails (those I've read and remember) in which = =20 You guys are talking why r4 should or should not be merged did not contain = =20 a patch or not even a line of code as a reference, most of complains feels = =20 so abstract and ahead of time, there is nothing wrong with planing ahead =20 but does it still makes sense when nobody else actually said that he would = =20 want to use it in future? Can't it be pusshed up to vfs later if it proves = =20 itself and there is demand for it? My question is what does it break now? It's been in mm for some time now, = what troubles does it couse? Did anyone complained that it breaks mm and =20 should be dropped? I'm just a end user and have no idea of linux internals, but all the fuzz = about r4 seems so political and it's not just me who things so.