On 2020-08-25 18:44, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-07-24 15:23, Tom Lane wrote:
Sounds good. Do we want to try Noah's idea of temporarily committing
the remaining changes, to see if the buildfarm is happy?
I think to get value out of this you'd have to compare the config
Peter Eisentraut writes:
> On 2020-07-24 15:23, Tom Lane wrote:
>> Sounds good. Do we want to try Noah's idea of temporarily committing
>> the remaining changes, to see if the buildfarm is happy?
> I think to get value out of this you'd have to compare the config.status
> output files (mainly p
On 2020-07-24 15:23, Tom Lane wrote:
Peter Eisentraut writes:
On 2020-07-17 10:46, Peter Eisentraut wrote:
v1-0001-Rename-configure.in-to-configure.ac.patch
I have committed that, and I have sent feedback to the Autoconf
developers about our concerns about the slowness of some of the new te
Peter Eisentraut writes:
> On 2020-07-17 10:46, Peter Eisentraut wrote:
>> v1-0001-Rename-configure.in-to-configure.ac.patch
> I have committed that, and I have sent feedback to the Autoconf
> developers about our concerns about the slowness of some of the new tests.
Sounds good. Do we want to
On 2020-07-17 10:46, Peter Eisentraut wrote:
v1-0001-Rename-configure.in-to-configure.ac.patch
I have committed that, and I have sent feedback to the Autoconf
developers about our concerns about the slowness of some of the new tests.
--
Peter Eisentraut http://www.2ndQuadrant.co
Hi,
On 2020-07-18 20:15:52 -0400, Tom Lane wrote:
> As best I can tell, the reason it's so slow is that somebody decided they
> ought to have a completionist approach to discovering whether the compiler
> has "C++11 features". The test program embedded in configure for this
> is a good 220 lines
Peter Eisentraut writes:
> On 2020-07-16 18:17, Tom Lane wrote:
>> Yeah. Because we'd want to rip out those hacks, it's not quite as simple
>> as "regenerate configure with this other autoconf version"; somebody will
>> have to do some preliminary investigation and produce a patch for the
>> auto
On Sat, Jul 18, 2020 at 2:12 AM Tom Lane wrote:
> Another issue is that we're not going to open up the main repo for
> access by non-committers, so this approach doesn't help for most
> developers. We've had some success, I think, with Munro's cfbot
> solution --- I'd rather see that approach exp
Hi,
On 2020-07-17 10:46:30 +0200, Peter Eisentraut wrote:
> Okay, let's take a look. Attached is a patch series.
Cool.
> One thing that's annoying is that the release notes claim that configure
> should now be faster, and some of the changes they have made should support
> that, but my (limite
Magnus Hagander writes:
> That one does more or less what Dagfinn suggests except in a separate repo.
> We could also just have a separate repo for it where people could push if
> we wanted to. Which could be committers, or others. But in comparison with
> what Perl does, I would assume actually h
On Fri, Jul 17, 2020 at 4:12 PM Tom Lane wrote:
> ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> > Noah Misch writes:
> >> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker
> wrote:
> >>> Instead of doing this on the master branch, would it be worth defi
ilm...@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Noah Misch writes:
>> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
>>> Instead of doing this on the master branch, would it be worth defining a
>>> namespace for branches that the buildfarm tests i
Noah Misch writes:
> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
>
>> Instead of doing this on the master branch, would it be worth defining a
>> namespace for branches that the buildfarm tests in addition to master
>> and REL_*_STABLE?
>>
>> In the Perl world we ha
On 2020-07-16 18:17, Tom Lane wrote:
Andres Freund writes:
I think it'd be a good plan to adopt the beta on master.
We already have parts of it backpacked, there have been things we couldn't
easily do because of bugs in 2.69. There aren't that many changes to configure
it total, and partic
On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Noah Misch writes:
> > On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
> >> Along the same line, I read at [1]
> >>
> >> Because it has been such a long time, and because some of the changes
> >> potenti
Andres Freund writes:
> I think it'd be a good plan to adopt the beta on master.
> We already have parts of it backpacked, there have been things we couldn't
> easily do because of bugs in 2.69. There aren't that many changes to
> configure it total, and particularly not in the back branches. S
Hi,
On July 16, 2020 8:24:15 AM PDT, Tom Lane wrote:
>Noah Misch writes:
>> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>More ambitiously, we could just adopt 2.69b in HEAD and see what
>happens,
>planning to revert only if things break. The cost to that is that
>committers who wa
Andrew Dunstan writes:
> On 7/16/20 11:24 AM, Tom Lane wrote:
>> More ambitiously, we could just adopt 2.69b in HEAD and see what happens,
>> planning to revert only if things break. The cost to that is that
>> committers who want to commit configure.ac changes would have to install
>> 2.69b. Bu
On 7/16/20 11:24 AM, Tom Lane wrote:
> Noah Misch writes:
>> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>>> Maybe we should do some pro-active testing, rather than just waiting for
>>> 2.70 to get dropped on us? God knows how long it will be until 2.71.
>> Sounds good. A cheap o
Noah Misch writes:
> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>> Maybe we should do some pro-active testing, rather than just waiting for
>> 2.70 to get dropped on us? God knows how long it will be until 2.71.
> Sounds good. A cheap option would be to regenerate with 2.70, push
Noah Misch writes:
> On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > It was mentioned elsewhere in passing that a new Autoconf release might
>> > be coming. That one will warn about the old naming "configure.in" and
>> > request "configure.ac". So w
On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > It was mentioned elsewhere in passing that a new Autoconf release might
> > be coming. That one will warn about the old naming "configure.in" and
> > request "configure.ac". So we might want to rename that
Peter Eisentraut writes:
> It was mentioned elsewhere in passing that a new Autoconf release might
> be coming. That one will warn about the old naming "configure.in" and
> request "configure.ac". So we might want to rename that sometime.
> Before we get into the specifics, I suggest that all
On 7/15/20 9:14 AM, Peter Eisentraut wrote:
> It was mentioned elsewhere in passing that a new Autoconf release
> might be coming. That one will warn about the old naming
> "configure.in" and request "configure.ac". So we might want to rename
> that sometime. Before we get into the specifics, I
24 matches
Mail list logo
