v7.3 Branched ...

"Marc G. Fournier" wrote:

As was previously discussed (and now that I'm mostly back from the dead
... damn colds) I've just branched off REL7_3_STABLE ... all future beta's
will be made based off of that branch, so that development may resume on
the main branch ...

What is the attitude towards getting stuff from Gborg to the main
PostgreSQL distribution (contrib or otherwise)?

For example, the pg_autotune utility recently started on GBorg. It's an
ongoing project, useful to many installations, and the additional size
would be barely noticeable.

Not saying it's ready right now, but am hoping that maybe 7.4 would be
able to include it.

:-)

Regards and best wishes,

Justin Clift

So, for those doing commits or anoncvs, remember that the 'stable' branch
requires you to use:

-rREL7_3_STABLE

while the development branch is 'as per normal' ...

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Not going to happen ... there are oodles of "not big, but useful" pieces
of software out there that we could include ... but th epoint of Gborg is
you download the main repository, and then you go to gborg to look for the
add-ons you might like to have ...

On Sun, 29 Sep 2002, Justin Clift wrote:

"Marc G. Fournier" wrote:

Not going to happen ... there are oodles of "not big, but useful" pieces
of software out there that we could include ... but th epoint of Gborg is
you download the main repository, and then you go to gborg to look for the
add-ons you might like to have ...

Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools"
type of package, that includes in one download all of these nifty tools
(pg_autotune, oid2name, etc) that would be beneficial to have compiled
and already available. Kind of like "contrib" is (oid2name is already
there I know), but so people don't have to go hunting all over GBorg to
find the bits that they'd want.

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

[ I am starting to change subject headings to make things easier for
people.]

I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.

Marc, I know we said branch after beta2 but I think we need another week
or two before we can start using that branch effectively. Even if we
started using it, like adding PITR, the code would drift so much that
the double-patching would start to fail when applied.

Can the branch be undone, or can we not use it and just apply a
mega-patch later to make it match HEAD?

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

Marc G. Fournier wrote:

As was previously discussed (and now that I'm mostly back from the dead
... damn colds) I've just branched off REL7_3_STABLE ... all future beta's
will be made based off of that branch, so that development may resume on
the main branch ...

So, for those doing commits or anoncvs, remember that the 'stable' branch
requires you to use:

-rREL7_3_STABLE

while the development branch is 'as per normal' ...

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Marc, I know we said branch after beta2 but I think we need another week
or two before we can start using that branch effectively. Even if we
started using it, like adding PITR, the code would drift so much that
the double-patching would start to fail when applied.

Another problem is that with all the open issues, we still really need
to focus on 7.3, not on 7.4 development. I don't want to see massive
patches like PITR or the Windows-port stuff coming in just yet, because
we don't have the bandwidth to review them now.

Can the branch be undone, or can we not use it and just apply a
mega-patch later to make it match HEAD?

AFAIK there's no convenient way to undo the branch creation.

I concur with treating HEAD as the active 7.3 area for the next week or
so and then doing a bulk merge into the REL7_3 branch, so as to avoid
the labor of individual double-patches.

Marc previously proposed releasing beta3 in about a week --- will that
be a good time to open HEAD for 7.4 work, or will we need to delay still
longer? (I'm not sure yet, myself.)

regards, tom lane

Tom Lane wrote:
<snip>

Marc previously proposed releasing beta3 in about a week --- will that
be a good time to open HEAD for 7.4 work, or will we need to delay still
longer? (I'm not sure yet, myself.)

Perhaps it's too early to be able to effectively say when a
real+effective branch is likely to be really needed? Stuff still feels
a bit too chaotic.

Regards and best wishes,

Justin Clift

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Bruce Momjian writes:

I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.

Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Bruce Momjian writes:

I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.

Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.

Yes, there is something to be said for this idea. We can single-patch
into 7.3 and make one mega-patch to bring 7.4 up to 7.3. I think that
will work _if_ 7.4 doesn't drift too much, and even then, I just need to
spend some time manually doing it. However, there is the danger that
7.4 changes will not hit all the areas coming in from the 7.3 patch.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.

Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.

Why is that better than the other direction?

We can't afford to allow much divergence between the two branches so
long as we are engaged in wholesale double-patching, so I think it
really comes down to the same thing in the end: we are not ready for 7.4
development to start in earnest, whether there's a CVS branch for it or
not.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.

Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.

Why is that better than the other direction?

We can't afford to allow much divergence between the two branches so
long as we are engaged in wholesale double-patching, so I think it
really comes down to the same thing in the end: we are not ready for 7.4
development to start in earnest, whether there's a CVS branch for it or
not.

Yes. We need a decision now because I don't know which branch to touch.
Marc, I need your feedback on these ideas. There is discussion about
fixing earthdistance. Perhaps we fix that and remove the 7.3 tag and
just have everyone CVS checkout again.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Mon, 30 Sep 2002, Bruce Momjian wrote:

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

I don't think we want a branch for 7.4 yet. We still have lots of open
issues and the branch will require double-patching.

Merge the changes on the 7.3 branch into the 7.4 branch after 7.3 is
released.

Why is that better than the other direction?

We can't afford to allow much divergence between the two branches so
long as we are engaged in wholesale double-patching, so I think it
really comes down to the same thing in the end: we are not ready for 7.4
development to start in earnest, whether there's a CVS branch for it or
not.

Yes. We need a decision now because I don't know which branch to touch.
Marc, I need your feedback on these ideas. There is discussion about
fixing earthdistance. Perhaps we fix that and remove the 7.3 tag and
just have everyone CVS checkout again.

Go with Peter's suggestion about committing on one of the branches (v7.3
or v7.4, doesn't matter, unless Peter knows something I don't insofar as
merging from branch->trunk vs trunk->branch?) ... then when we are ready
to start letting it all diverge, we can just re-sync the opposite branch
and keep on with development ...

"Marc G. Fournier" <scrappy@hub.org> writes:

On Mon, 30 Sep 2002, Bruce Momjian wrote:

Yes. We need a decision now because I don't know which branch to touch.
Marc, I need your feedback on these ideas. There is discussion about
fixing earthdistance. Perhaps we fix that and remove the 7.3 tag and
just have everyone CVS checkout again.

Go with Peter's suggestion about committing on one of the branches (v7.3
or v7.4, doesn't matter,

Let's go with committing to HEAD then. It's just easier (don't need a
branch-tagged checkout tree to work in).

We'll sync up the REL7_3 branch when we're ready to put out beta3.

regards, tom lane

Tom Lane writes:

Why is that better than the other direction?

It isn't. Let's just keep committing to the head and merge it into 7.3
later.

--
Peter Eisentraut peter_e@gmx.net

Just a reminder, we are not using this tag. All 7.3 patches are going
to HEAD. Once we decide to split the tree for 7.4, we will update this
branch and announce it is ready to be used.

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

Marc G. Fournier wrote:

As was previously discussed (and now that I'm mostly back from the dead
... damn colds) I've just branched off REL7_3_STABLE ... all future beta's
will be made based off of that branch, so that development may resume on
the main branch ...

So, for those doing commits or anoncvs, remember that the 'stable' branch
requires you to use:

-rREL7_3_STABLE

while the development branch is 'as per normal' ...

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
Justin Clift wrote:<br>
<blockquote type="cite" cite="mid3D968786.66E5AC72@postgresql.org">
<pre wrap="">"Marc G. Fournier" wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Not going to happen ... there are oodles of "not big, but useful" pieces
of software out there that we could include ... but th epoint of Gborg is
you download the main repository, and then you go to gborg to look for the
add-ons you might like to have ...
</pre>
</blockquote>
<pre wrap=""><!---->
Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools"
type of package, that includes in one download all of these nifty tools
(pg_autotune, oid2name, etc) that would be beneficial to have compiled
and already available. Kind of like "contrib" is (oid2name is already
there I know), but so people don't have to go hunting all over GBorg to
find the bits that they'd want.</pre>
</blockquote>
That would be wonderful if it included some of the more stable tools / add-ons
that have been removed from the main distribution or have existed independent
of the main PostgreSQL development.<br>
<blockquote type="cite" cite="mid3D968786.66E5AC72@postgresql.org">
<pre wrap="">

:-)

Regards and best wishes,

Justin Clift

</pre>
</blockquote>
<br>
<br>
</body>
</html>

Thomas Swan wrote:

Justin Clift wrote:

<snip>

Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools"
type of package, that includes in one download all of these nifty
tools (pg_autotune, oid2name, etc) that would be beneficial to have
compiled and already available. Kind of like "contrib" is (oid2name is
already there I know), but so people don't have to go hunting all over GBorg
to find the bits that they'd want.

That would be wonderful if it included some of the more stable tools /
add-ons that have been removed from the main distribution or have
existed independent of the main PostgreSQL development.

Hi Thomas,

Want to get it together?

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Perhaps one could just create a "PostgreSQL Powertools" section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...

Robert Treat

On Wed, 2002-10-16 at 16:56, Robert Treat wrote:

Perhaps one could just create a "PostgreSQL Powertools" section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...

Let ye-old package managers make a shell package which simply points to
the others as dependencies.

I'd be willing to do this for FreeBSD (think Sean? would help as well)
if someone comes up with the list.

On Wed, 2002-10-16 at 16:00, Justin Clift wrote:

Thomas Swan wrote:

Justin Clift wrote:

<snip>

Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools"
type of package, that includes in one download all of these nifty
tools (pg_autotune, oid2name, etc) that would be beneficial to have
compiled and already available. Kind of like "contrib" is (oid2name is
already there I know), but so people don't have to go hunting all over GBorg
to find the bits that they'd want.

That would be wonderful if it included some of the more stable tools /
add-ons that have been removed from the main distribution or have
existed independent of the main PostgreSQL development.

Hi Thomas,

Want to get it together?

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
Rod Taylor

On Wednesday 16 October 2002 05:05 pm, Rod Taylor wrote:

On Wed, 2002-10-16 at 16:56, Robert Treat wrote:

Perhaps one could just create a "PostgreSQL Powertools" section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...

Let ye-old package managers make a shell package which simply points to
the others as dependencies.

I'm going to attempt to do up RPMs of all those.... :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Wed, 2002-10-16 at 16:05, Rod Taylor wrote:

On Wed, 2002-10-16 at 16:56, Robert Treat wrote:

Perhaps one could just create a "PostgreSQL Powertools" section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...

Let ye-old package managers make a shell package which simply points to
the others as dependencies.

Sort of like a meta-port?

I'd be willing to do this for FreeBSD (think Sean? would help as well)
if someone comes up with the list.

That would be useful, and port(s) for the rest of contrib as well (like
contrib/tsearch).

:-)

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

On Thu, 17 Oct 2002, Justin Clift wrote:

Thomas Swan wrote:

Justin Clift wrote:

<snip>

Ok. Wonder if it's worth someone creating a "PostgreSQL Powertools"
type of package, that includes in one download all of these nifty
tools (pg_autotune, oid2name, etc) that would be beneficial to have
compiled and already available. Kind of like "contrib" is (oid2name is
already there I know), but so people don't have to go hunting all over GBorg
to find the bits that they'd want.

That would be wonderful if it included some of the more stable tools /
add-ons that have been removed from the main distribution or have
existed independent of the main PostgreSQL development.

Hi Thomas,

Want to get it together?

Just a thought, and I've included chris in this ... is there some way of
setting up maybe a 'meta package' on Gborg that would auto-pull in and
package stuff like this?

For instance, in FreeBSD ports, you can make such that when you type in
'make', it just goes to other ports and builds/installs those ...

Baring that, how about the ability to create a new category that is
maintained by someone that various project maintains could 'cross-link'
their projects into?

On a different note ... if anyone out there would like to maintain/package
up binaries for various OS similar to what Lamar does with RPMs, I'd love
to see us extend our binaries section on the ftp server ...

On 16 Oct 2002, Larry Rosenman wrote:

Perhaps one could just create a "PostgreSQL Powertools" section on
techdocs, naming the packages and where to get them. This would
eliminate the need to maintain a package that just duplicates other
packages...

Let ye-old package managers make a shell package which simply points to
the others as dependencies.

I'd be willing to do this for FreeBSD (think Sean? would help as well)
if someone comes up with the list.

There is a postgresql-devel port in FreeBSD now that I am maintaining
that is where DBAs and anxious developers can cut their teeth on the
new features/bugs/interactions in PostgreSQL. As soon as we get out
of beta here, I'm going to likely get in the habbit of updating the
port once a month or so with snapshots from the tree.

FWIW, at some point I'm going to SPAM the CVS tree with a
POSTGRESQL_PORT tunable that will let users decide which PostgreSQL
instance they want (stable version vs -devel). I've been really busy
recently and haven't gotten around to double checking things since I
made the changes a month ago during the freeze. Maybe this weekend
I'll get around to touching down on all of the various files.... no
promises, I'm getting ready to move. -sc

--
Sean Chittenden