Re: Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59

Log Message:
-----------

configure tag'd 8.3.0 and built witih autoconf 2.59

Modified Files:
--------------
pgsql:
configure (r1.577 -> r1.578)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.577&r2=1.578)
configure.in (r1.545 -> r1.546)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.545&r2=1.546)

I don't see the branch point for REL8_3_STABLE - has that been done? I
thought it would happen at the same time as we tagged the release.

cheers

andrew

Marc G. Fournier wrote:
> Log Message:
> -----------
>
> configure tag'd 8.3.0 and built witih autoconf 2.59
>
> Modified Files:
> --------------
> pgsql:
> configure (r1.577 -> r1.578)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.577&r2=1.578)
> configure.in (r1.545 -> r1.546)
> (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.545&r2=1.546)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
>
>

Andrew Dunstan wrote:
>
> I don't see the branch point for REL8_3_STABLE - has that been done? I
> thought it would happen at the same time as we tagged the release.

No, we will branch later.

---------------------------------------------------------------------------

>
> cheers
>
> andrew
>
> Marc G. Fournier wrote:
> > Log Message:
> > -----------
> >
> > configure tag'd 8.3.0 and built witih autoconf 2.59
> >
> > Modified Files:
> > --------------
> > pgsql:
> > configure (r1.577 -> r1.578)
> > (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.577&r2=1.578)
> > configure.in (r1.545 -> r1.546)
> > (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure.in?r1=1.545&r2=1.546)
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Andrew Dunstan wrote:
>
>> I don't see the branch point for REL8_3_STABLE - has that been done? I
>> thought it would happen at the same time as we tagged the release.
>>
>
> No, we will branch later.
>
>

Still not there.

We need this to be created before buildfarm members can start testing 8.3.

I still don't see why we wait to create the branch after tagging the
release. There doesn't seem to be any point.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > Andrew Dunstan wrote:
> >
> >> I don't see the branch point for REL8_3_STABLE - has that been done? I
> >> thought it would happen at the same time as we tagged the release.
> >>
> >
> > No, we will branch later.
> >
> >
>
> Still not there.
>
> We need this to be created before buildfarm members can start testing 8.3.
>
> I still don't see why we wait to create the branch after tagging the
> release. There doesn't seem to be any point.

We need an 8.3 tag, but not a branch. Is there no tag?

We don't branch because we want to apply 8.3 fixes to CVS HEAD for a
while, to avoid double-patching.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:
> Andrew Dunstan wrote:
>
>> Bruce Momjian wrote:
>>
>>> Andrew Dunstan wrote:
>>>
>>>
>>>> I don't see the branch point for REL8_3_STABLE - has that been done? I
>>>> thought it would happen at the same time as we tagged the release.
>>>>
>>>>
>>> No, we will branch later.
>>>
>>>
>>>
>> Still not there.
>>
>> We need this to be created before buildfarm members can start testing 8.3.
>>
>> I still don't see why we wait to create the branch after tagging the
>> release. There doesn't seem to be any point.
>>
>
> We need an 8.3 tag, but not a branch. Is there no tag?
>
> We don't branch because we want to apply 8.3 fixes to CVS HEAD for a
> while, to avoid double-patching.
>
>

I give up. We seem to look for ways to make things more difficult
sometimes. We are hampering the buildfarm, and keeping the tree frozen,
and thus preventing feature commits, on the off chance that there will
be some bug fix that we don't want to double patch. We backport fixes
all the time. Why is it such a big deal? Are we waiting for magic pixie
dust?

When we released 8.2, my archives show that HEAD was stamped as 8.3devel
the same day. That also doesn't seem to have been done yet, but anyway,
the branch for _STABLE must have been done before that time.

cheers

andrew

Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
>> Andrew Dunstan wrote:
>>
>>> Bruce Momjian wrote:
>>>
>>>> Andrew Dunstan wrote:
>>>>
>>>>> I don't see the branch point for REL8_3_STABLE - has that been
>>>>> done? I thought it would happen at the same time as we tagged the
>>>>> release.
>>>>>
>>>> No, we will branch later.
>>>>
>>>>
>>> Still not there.
>>>
>>> We need this to be created before buildfarm members can start testing
>>> 8.3.
>>>
>>> I still don't see why we wait to create the branch after tagging the
>>> release. There doesn't seem to be any point.
>>>
>>
>> We need an 8.3 tag, but not a branch. Is there no tag?
>>
>> We don't branch because we want to apply 8.3 fixes to CVS HEAD for a
>> while, to avoid double-patching.
>>
>>
>
> I give up. We seem to look for ways to make things more difficult
> sometimes. We are hampering the buildfarm, and keeping the tree frozen,
> and thus preventing feature commits, on the off chance that there will
> be some bug fix that we don't want to double patch. We backport fixes
> all the time. Why is it such a big deal? Are we waiting for magic pixie
> dust?
>
> When we released 8.2, my archives show that HEAD was stamped as 8.3devel
> the same day. That also doesn't seem to have been done yet, but anyway,
> the branch for _STABLE must have been done before that time.

+1 on getting the branch + stamping done ASAP.

//Magnus

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Bruce Momjian wrote:
>> Andrew Dunstan wrote:
>>> I don't see the branch point for REL8_3_STABLE - has that been done? I
>>> thought it would happen at the same time as we tagged the release.
>>
>> No, we will branch later.

> We need this to be created before buildfarm members can start testing 8.3.

Nonsense. At the moment, HEAD is 8.3.

> I still don't see why we wait to create the branch after tagging the
> release. There doesn't seem to be any point.

To avoid double-patching effort. I think we'll branch fairly shortly,
like in a week or so, but right now it'd mostly just create make-work
for committers.

regards, tom lane

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> Bruce Momjian wrote:
>>
>>> Andrew Dunstan wrote:
>>>
>>>> I don't see the branch point for REL8_3_STABLE - has that been done? I
>>>> thought it would happen at the same time as we tagged the release.
>>>>
>>> No, we will branch later.
>>>
>
>
>> We need this to be created before buildfarm members can start testing 8.3.
>>
>
> Nonsense. At the moment, HEAD is 8.3.
>

True, but it won't show up under that heading, and buildfarm members
won't be able to configure specific 8.3 testing until we branch.

>
>> I still don't see why we wait to create the branch after tagging the
>> release. There doesn't seem to be any point.
>>
>
> To avoid double-patching effort. I think we'll branch fairly shortly,
> like in a week or so, but right now it'd mostly just create make-work
> for committers.
>
>
>

Was that a big problem last release?

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> To avoid double-patching effort. I think we'll branch fairly shortly,
>> like in a week or so, but right now it'd mostly just create make-work
>> for committers.

> Was that a big problem last release?

Well, basically this happens at core's discretion, and we all feel that
waiting a bit more will minimize work. If there were a lot of people
chomping at the bit to start committing 8.4-only stuff, maybe we'd
decide differently. But right now what's on my radar screen is still
8.3 bugs, eg the open patch for bug #3921, and we're expecting a few
more new reports as soon as 8.3.0 spreads.

As best I recall, the immediate branch after 8.2 was the exception not
the rule --- we've usually waited longer than that.

regards, tom lane

Tom Lane wrote:
> As best I recall, the immediate branch after 8.2 was the exception not
> the rule --- we've usually waited longer than that.

8.2, 8.1, and 8.0 were branched off the x.y.0 release tag. 7.4 was branched
at rc1, 7.3 was branched at beta4, 7.2 was branched at final release, 7.1 was
branched at 7.1.1. So no. :-)

Personally, I don't agree with following this endless release cycle with an
additional indefinite waiting period.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Tom Lane wrote:
>
>> As best I recall, the immediate branch after 8.2 was the exception not
>> the rule --- we've usually waited longer than that.
>>
>
> 8.2, 8.1, and 8.0 were branched off the x.y.0 release tag. 7.4 was branched
> at rc1, 7.3 was branched at beta4, 7.2 was branched at final release, 7.1 was
> branched at 7.1.1. So no. :-)
>
> Personally, I don't agree with following this endless release cycle with an
> additional indefinite waiting period.
>

Yeah, that accords with my recollection. Also, it also would have been
nice if there had been some information about what was going on.

I don't really buy the double patching argument. Back patching becomes
more difficult when there has been significant code drit, but we surely
don't expect that much drift in the next week or two. Back patching when
there has been no code drift is pretty simple.

cheers

andrew

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> I don't really buy the double patching argument. Back patching becomes
> more difficult when there has been significant code drit, but we surely
> don't expect that much drift in the next week or two. Back patching when
> there has been no code drift is pretty simple.

Well, it's not hard, but it is tedious. Bruce and I, who are the people
most likely to bear the brunt of such tedium, both voted to wait a week
or so before branching. Peter did not bother to vote.

regards, tom lane

On Mon, Feb 04, 2008 at 08:36:47PM -0500, Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> > I don't really buy the double patching argument. Back patching becomes
> > more difficult when there has been significant code drit, but we surely
> > don't expect that much drift in the next week or two. Back patching when
> > there has been no code drift is pretty simple.
>
> Well, it's not hard, but it is tedious. Bruce and I, who are the people
> most likely to bear the brunt of such tedium, both voted to wait a week
> or so before branching. Peter did not bother to vote.

I assume this vote was taken out on -core? I don't mind -core deciding on
this, not at all, but I would appreciate it if you would post the result of
the vote on -hackers. It makes a lot of difference with an open-ended
"we'll branch sometmie later" and a "we talked about it, and we decided
we'll branch in one to two weeks unless something unusual comes up".

If you alraedy did this and I missed it in the mail-flood around fixing all
the presskits, I apologize in advance ;-)

//Magnus

On Feb 5, 2008 9:00 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> I assume this vote was taken out on -core? I don't mind -core deciding on
> this, not at all, but I would appreciate it if you would post the result of
> the vote on -hackers.

It wasn't a 'vote' in the formal sense. It was just a discussion with
people airing their opinion.

/D

On Tue, Feb 05, 2008 at 10:57:16AM +0000, Dave Page wrote:
> On Feb 5, 2008 9:00 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> > I assume this vote was taken out on -core? I don't mind -core deciding on
> > this, not at all, but I would appreciate it if you would post the result of
> > the vote on -hackers.
>
> It wasn't a 'vote' in the formal sense. It was just a discussion with
> people airing their opinion.

*how* you came to the decision isn't really what I care about in this
case..

//Magnus

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> I don't really buy the double patching argument. Back patching becomes
>> more difficult when there has been significant code drit, but we surely
>> don't expect that much drift in the next week or two. Back patching when
>> there has been no code drift is pretty simple.
>>
>
> Well, it's not hard, but it is tedious. Bruce and I, who are the people
> most likely to bear the brunt of such tedium, both voted to wait a week
> or so before branching. Peter did not bother to vote.
>
>

I suspect that you made this decision thinking that it didn't affect
anybody else much. But it does affect buildfarm members. The buildfarm
requires manual adjustment for each new branch to be built. Up to now
(as Peter showed) owners have been able to say "Oh, there's a new
release. I'll start building the new branch". With the branch delayed
they will have to say "Oh, there's a new release. I wonder when they
will branch so I can start building the new branch." I suspect there are
some buildfarm owners who don't read -hackers religiously, and who will
be somewhat in the dark.

This probably wasn't on the core team's horizon - IIRC Dave is the only
member of core who runs a buildfarm member.

cheers

andrew

On Feb 5, 2008 11:50 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
> This probably wasn't on the core team's horizon - IIRC Dave is the only
> member of core who runs a buildfarm member.

To be honest the zoo beside me didn't even cross my mind when that
thread happened. I didn't pay much attention as it's doesn't affect me
much - plus I've spent the last 2 months double patching pgAdmin since
the EDB QA team started finding all sorts of obscure buglets, so I can
see where Tom's coming from.

/D

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:

> Tom Lane wrote:
>
> With the branch delayed they will have to say "Oh, there's a new
> release. I wonder when they will branch so I can start building the new
> branch."

Doesn't that just mean they should be sure to announce the branch loudly when
it happens? I can't really see them failing to do that anyways.

Whether the branch or not is just an procedural detail that only committers
need to be concerned with. I think this is all projected anguish over
something related. Tom says "if there were people chomping at the bit to
commit" but that just raises the question: why aren't there people chomping at
said bit? There are certainly tons of patches queued up in Bruce's "held for
8.4" queue.

Is it that just that we have queued up 8.3.x patches occupying committers
attention? Or is it that reviewers and committers are exhausted from 8.3 and
not quite ready yet to tackle new patches?

Either way we need to find a solution that doesn't overload reviewers and
committers and makes continual progress against pending patches. If we don't
keep the patch queue short now we're only going to have a repeat of the
last-minute rush at feature-freeze time again.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

Gregory Stark wrote:
> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>
>
>> Tom Lane wrote:
>>
>> With the branch delayed they will have to say "Oh, there's a new
>> release. I wonder when they will branch so I can start building the new
>> branch."
>>
>
>
>

No, I wrote that, not Tom. Your snipping went slightly astray.

cheers

andrew

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:

> Gregory Stark wrote:
>> "Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:
>>
>>> Tom Lane wrote:
>>>
>>> With the branch delayed they will have to say "Oh, there's a new
>>> release. I wonder when they will branch so I can start building the new
>>> branch."
>
> No, I wrote that, not Tom. Your snipping went slightly astray.

Er, yeah. Whatever Tom wrote would have had another level of >s.
Obviously I should have snipped one more line.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- --On Tuesday, February 05, 2008 10:00:29 +0100 Magnus Hagander
<magnus(at)hagander(dot)net> wrote:

> On Mon, Feb 04, 2008 at 08:36:47PM -0500, Tom Lane wrote:
>> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>> > I don't really buy the double patching argument. Back patching becomes
>> > more difficult when there has been significant code drit, but we surely
>> > don't expect that much drift in the next week or two. Back patching when
>> > there has been no code drift is pretty simple.
>>
>> Well, it's not hard, but it is tedious. Bruce and I, who are the people
>> most likely to bear the brunt of such tedium, both voted to wait a week
>> or so before branching. Peter did not bother to vote.
>
> I assume this vote was taken out on -core? I don't mind -core deciding on
> this, not at all, but I would appreciate it if you would post the result of
> the vote on -hackers. It makes a lot of difference with an open-ended
> "we'll branch sometmie later" and a "we talked about it, and we decided
> we'll branch in one to two weeks unless something unusual comes up".

Actually, "branch in one to two weeks" has been the status quo almost since day
one ... not that I'm against "branch on release", I'm only saying that we've
followed this same procedure on branching since ... forever.

- ----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . scrappy(at)hub(dot)org MSN . scrappy(at)hub(dot)org
Yahoo . yscrappy Skype: hub.org ICQ . 7615664
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)

iD8DBQFHqTeE4QvfyHIvDvMRAlisAKCxactS3Xp6V9/PbOOn11vhPioQaACgm+Ck
psuY9S9odAYdj91T5/QlYDc=
=CdzR
-----END PGP SIGNATURE-----

Marc G. Fournier wrote:
> Actually, "branch in one to two weeks" has been the status quo almost since
> day one ... not that I'm against "branch on release", I'm only saying that
> we've followed this same procedure on branching since ... forever.

That is incorrect. See earlier in this thread.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/