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: