Re: PostgreSQL 8.4 development plan - Mailing list pgsql-hackers

From Mark Mielke
Subject Re: PostgreSQL 8.4 development plan
Date
Msg-id 47AB5F70.5070303@mark.mielke.cc
Whole thread Raw
In response to Re: PostgreSQL 8.4 development plan  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote: <blockquote cite="mid:8101.1202410651@sss.pgh.pa.us" type="cite"><pre wrap="">Mark Mielke <a
class="moz-txt-link-rfc2396E"href="mailto:mark@mark.mielke.cc"><mark@mark.mielke.cc></a> writes:
</pre><blockquotetype="cite"><pre wrap="">In terms of picking an SCM candidate, I don't think "time to install 
 
from source" is a legitimate concern. Installing from source is great, 
but if the package needs to be installed from source, it is not well 
enough supported by the community to be worth using.   </pre></blockquote><pre wrap="">
That is 100.0% wrong.  Some people want to install from source, and
some don't have any choice because they are on platforms where there's
not a prebuilt binary available.  I am *not* willing to say that we
will blow off developers on any platform that some other project is
choosing not to provide binaries for.

As a fairly well related example, note how CVSup never became the de
facto standard, because it wasn't portable enough, or at least had made
the wrong decisions about what to depend on</pre></blockquote><br /> You are not correct. Different SCM systems have
differentcapabilities. Value and portability are important factors. Time to install from source is not. Comparing how
easythey are to install from source in terms of minutes is not a fair assessment of the value they provide nor the
portabilityof the systems. The numbers you quoted are obviously invalid as SVN is based very significantly on the APR
librariesthat Apache is based on in a well established and successful effort to provide portability. Would you say that
Apacheis not a good choice? None of this proves that SVN is a good choice - but I believe it does prove that using
numberssuch as you quoted to draw a conclusion about what is best for PostgreSQL is a backwards way of thinking about
theproblem.<br /><br /> GIT is currently poor at portability primarily because it is new, and if you tried to compile
iton Windows (a common platform these days) without CYGWIN you would have a lot of trouble. This does not make GIT a
worsechoice. That it lacks in portability is a current concern that should be weighed along with the rest of the issues
suchas ease of use, productivity, integration with other valuable tools, parallel development support (reliable merge
trackingbeing a major factor here), and offline capabilities.<br /><br /> I think what you missed was my statement that
ifpackage installs do not exist for the majority of the platforms you intend people to develop PostgreSQL on, then the
SCMsystem you are considering is not mature or enough, or supported well enough by the community, to be a good
candidateand there will be trouble down the road if the system that is chosen goes into disrepair. Being able to
compilefrom source is a virtue shared by open source developers - but a requirement that it must be compiled from
sourceis not a virtue. If it must be compiled from source, it means the product is not valuable enough to people to
createa demand for a binary install package. Nobody should be forced to compile an SCM system from source in order to
contributeto PostgreSQL. That would be just silly.<br /><br /> Cheers,<br /> mark<br /><br /><br /><pre
class="moz-signature"cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>

pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: {**Spam**} Re: PostgreSQL 8.4 development plan
Next
From: Zdenek Kotala
Date:
Subject: Re: PostgreSQL 8.3.0 'unrecognized node type: 1718580065'