From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 3 Nov 2008 17:23:11 -0800 From: "Roman V. Shaposhnik" In-reply-to: <20081103001543.GC27416@nibiru.local> To: weigelt@metux.de, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1225761791.4781.211.camel@goose.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1223158526.466.10.camel@ginkgo> <1223351034.19902.17.camel@goose.sun.com> <1224739614.11627.124.camel@goose.sun.com> <20081030180755.GC14902@nibiru.local> <1225401310.32662.34.camel@goose.sun.com> <20081101190557.GB27416@nibiru.local> <2529BB27-520B-432E-9A70-3FB5EE5E938B@sun.com> <20081103001543.GC27416@nibiru.local> Subject: Re: [9fans] plan9port lacks exportfs server Topicbox-Message-UUID: 2ef046f4-ead4-11e9-9d60-3106f5b1d025 [I believe we should go off-line if you're interested in continuing this discussion, since it has very little to do with plan9port at this point. I'll reply to the portion that has relevance on the list here, and will reply to the rest of your email privately] On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote: > Of course I'm building > binary packages, too, but they're always specialized for some > particular target system, not general purpose, not comparable > to what common binary distros do. So you DO build binary packages. And you WANT to build plan9port as a binary package? Then, you should be expected to put a reasonable effort into making that happen. Doing virtual Tom Sawyering and trying to convince developers that they should be putting that effort instead of you is fine tactic, I don't deny. Tom Sawyer got lucky doing that, you seem to be out of luck so far :-) > > The kind of value that project members are simply not interested in. > > I know, and that tends to be the point where I fork. Yep. And that's the entire point here. See, I happen to also work on a project where we can *afford* to be arrogant and self-serving. The world needs us, not the other way around. Hence we don't even do formal dotted releases anymore. We try to be diligent about tracking the progress of the external APIs by bumping a version number in a couple of macros, but otherwise -- all packagers have is our history in an SCM. It is up to them to decide that a particular point in that history has certain properties (like stability, or even fitness for a given purpose). It is up to them to fork and work on those properties. We, as developers, are not interested in making these claims. In fact, if we were making these claims without proper investment in QA and design specs we would be grossly misleading the public. We don't want to be liars. Now, most of the stuff written by the likes of Ken and Russ and the rest of the usual Plan9 suspects always works (and now, I'm not being sarcastic one bit here -- I'm actually constantly amazed at how superior these human beings are at software engineering). Thus when Russ says it is 0.4.1 it really *is* 0.4.1. So may be the QA argument doesn't apply to plan9port all that much. But the fitness for a particular purpose probably does. Only you as a packager can answer the question: who are you building your stuff for. And once you do -- you will see a much clearer picture of how it is supposed to be packaged. More to the point, that picture is very unlikely to have anything to do with source code development practices. Thanks, Roman.