Re: [pgsql-hackers] Patent issues and 8.1 - Mailing list pgsql-hackers

From Robert Treat
Subject Re: [pgsql-hackers] Patent issues and 8.1
Date
Msg-id 200501291437.22577.xzilla@users.sourceforge.net
Whole thread Raw
In response to Re: [pgsql-hackers] Patent issues and 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Saturday 29 January 2005 11:33, Tom Lane wrote:
> Robert Treat <xzilla@users.sourceforge.net> writes:
> > I'm not mischarecterizing, I just feel that putting out an lru based
> > 8.0.x release is such a bad idea that I'd rather do (1) than gamble on
> > (2).
>
> I don't understand why you think it's such a bad idea.  We do have the
> problem of getting adequate testing, but I think the answer to that
> is to put the same patch into HEAD as well.
>

The combination of inadequate testing, making support more difficult, and 
general all around confusion that beta/rc's for a revision level release are 
sure to cause. Not to mention that if the patent ever does materialize into a 
problem, the scope of that problem will be that much greater the longer we 
wait.

> > We can branch 8.1 and 8.2 now, with 2month dev planned for 8.1 and a
> > 12 month dev for 8.2 and go about things.
>
> I will resist that idea strongly.  We have no experience as a community
> with managing multiple active development branches, and I feel certain
> that we'd mess it up (eg, commit things into the wrong branch, or fail
> to commit things into both branches that need to be in both). Case in 
> point: Teodor has already, without discussion, committed 8.1 changes in
> tsearch2 that should force an initdb.   If we were taking the idea of a 
> backward-compatible 8.1 seriously we'd have to make him back that out of
> 8.1. 

I think this is a false case since right now we are hanging in limbo, with 
people unsure of what is proper to commit into what branch.  If there had 
been an official announcement that no initdb level changes were to go into 
8.1 I think we'd be ok.  

> I can't see trying to ride herd on all the committers to make sure 
> no one unintentionally breaks file-level compatibility over a whole dev
> cycle, even a short one.
>

I think the key is to put someone in charge of either 8.1 or 8.2 and let them 
be the primary gatekeeper for that release.  It can work either way... people 
develop against 8.1 and we have an 8.2 gatekeeper(s) responsible for patching 
forward any new commits into 8.2 and handling file-level incompatible feature 
commits.  Conversly we can have folks develop against 8.2 and have someone in 
charge of backpatching any non file-level incompatible changes backwards and 
the ARC changes.  

There are other upsides to this as well.  If we could do this now it would 
help move us to the ability to keep feature development going year round.  
Rather than having to stop 4-5 months every year to do beta we could create a 
new branch during beta and let people continue on with that... we already had 
some rumblings of that idea during the 8.0 beta cycle, this would give us a 
good test run. 

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL


pgsql-hackers by date:

Previous
From: Dawid Kuroczko
Date:
Subject: Re: Implementing Bitmap Indexes
Next
From: Dawid Kuroczko
Date:
Subject: Re: Implementing Bitmap Indexes