Re: Thoughts on maintaining 7.3

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Thoughts on maintaining 7.3
Date: 2003-10-01 13:41:18
Message-ID: 20031001101848.R94686@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Wed, 1 Oct 2003, Robert Treat wrote:

> Maybe I've mis-read Joshua's intentions, but I got the impression that
> this 7.3 maintainer would follow the patches list and backport patches
> whenever possible. This way folks coding for 7.4/7.5 can stay focused on
> that, but folks who can't upgrade to 7.4 for whatever reason can still
> get some features / improvements.

The problem, I think (and please note that I'm not against it, just
playing major devil's advocate here) is that there have always been some
major fundamental coding changes between releases that there are very few
patches that are "back-patchable" without having to do some heavy
re-writes ...

> Several linux distros already do this for many packages, and personally
> I've always been surprised that, given postgresql's major release
> upgrade issues, that no commercial company has stepped in to offer this
> in the past. I think what Joshua is wondering is how much cooperation
> would he get from the community if he was willing to donate these
> efforts back into project.

Using Linux/FreeBS/Insert OS Here as an example is like comparing apples
to oranges ... take FreeBSD as an example, since I know it ... 5.x has had
some *major* re-writes to the kernel done to it, getting rid of 'the Giant
Lock' that SMP in 4.x uses ... those changes are not back-patchable, since
then you'd have 5.x ... there are alot of changes to the 5.x kernel that
rely on those changes, and are therefore not *easily* back-patchable ...

Now, userland software is a totally different case, since they are rarely
"tied" to the kernel itself ...

Think of PostgreSQL as the kernel, not as the distro ... how many changes
from one kernel release ae easily patched into an older one, without
having to take alot of other baggage back with it ... ?

> I personally think it's a good idea for *someone* to do this, but I'll
> leave it to core to decide if they want to put the projects stamp of
> approval on it for any official community release.

I don't believe anyone would work against this, nor could I imagine that
anyone would think it was "a bad idea", I'm just curious as to how
possible it is to do ...

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Adam H. Pendleton 2003-10-01 13:53:24 Re: GPL code issue?
Previous Message Gaetano Mendola 2003-10-01 13:30:32 Re: NOTICE: CREATE TABLE will create implicit triggers for foreign-key