On Tuesday 16 December 2008 16:53:26 Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Dave Page wrote:
> >> Any eta on a fix for this? My internal builds are failing as well as
> >> red_bat. (and yes, the other 2 MSVC buildfarm members are currently
> >> waiting for Dell to get hold of a new motherboard for their box).
> >
> > I think the maintenance of the MSVC build system is the job of the,
> > well, maintainer of the MSVC build system, whoever that may be. In
> > other words, I have no ETA for you from me. I'd be glad, however, to
> > provide information to the maintainers.
>
> I do not think this is an appropriate attitude for a committer to take.
> You are responsible for what you commit. If you don't have the
> knowledge to fix something, or the resources to test it, okay ... but
> you then need to be proactive about getting someone else to fix/test it.
> Or else revert the broken patch.
I would like to have this clarified, as I keep running afoul of it.
We originally did the Windows port using the MinGW build system because we did
not want to maintain another build system. When people starting on the MSVC
build system, I was given assurances that they would maintain it and we would
not have to worry about it. I specifically recall discussions about that in
Toronto in 2006.
Now who are those maintainers and what are they doing about it?
I am not hostile against the MSVC system, even though I have no interest in it
(and I am unfamiliar with the payoff). I have done a lot of portability work
for crazy platforms that I have no stake in. But those platforms and build
systems used standard tools, had publically available documentation, and in
the extreme cases had a box that one could log into to verify the work. None
of this is available here. I don't think the progress of this project can
depend on proprietary tools and systems in a few hands.
Help?!?