Re: [HACKERS] Development Plans - Mailing list pgsql-advocacy
From | Tom Lane |
---|---|
Subject | Re: [HACKERS] Development Plans |
Date | |
Msg-id | 6072.1109350967@sss.pgh.pa.us Whole thread Raw |
In response to | Development Plans (Simon Riggs <simon@2ndquadrant.com>) |
Responses |
Re: [HACKERS] Development Plans
Re: [HACKERS] Development Plans Re: [HACKERS] Development Plans Re: [HACKERS] Development Plans |
List | pgsql-advocacy |
Simon Riggs <simon@2ndquadrant.com> writes: > I'm happy with the Zen approach of "there is no answer, the code comes > when it is time" and "HACKERS list IS the process". > Many people take the lack of a planned release date as clear indication > that there is no strictly controlled release process, however-much I > state that there really is one. In the absence of release dates, could > we write down some indication of what the release process is, so > everybody understands there is one. What we do not have is a marketing-driven development process ;-). We let the decisions be dictated by the maturity of the code, not by an arbitrary predetermined release date. We do try to set a feature freeze date in advance, but this has always been a pretty sloppy cutoff --- the reason we set it in advance is just so that individual developers can make their own plans about how much they think they can get done in time for the next release. (Awhile back we didn't even do that, but we found that we were forever slipping a release because first one feature then another was "almost ready". We have learned that we must be willing to say "too late for this release".) Once we are past feature freeze, the beta schedule and release schedule are determined entirely by Core's judgment about the state of the code. I think most of the developers consider our process a strength, not a weakness. It's certainly conditioned by the realities of an open- source project in which most of the workers are part-time volunteers, but it works well for us. > Right now, I have zero idea which quarter, let alone which month feature > freeze for 8.1 is in. I think it will be in 2005, but I'm not sure. I'm sorry about the flux around the 8.1 schedule. It's been caused by what is hopefully a one-time problem, namely uncertainty about how we ought to deal with the ARC patent problem. Normally we would have set a fairly definite feature freeze date before now. > - what will be in release 8.1? Whatever people get done. In a project where the work is done by volunteers, it's just about pointless to imagine that we can predict it. I can say what I'm hoping to work on personally, but how much of it will get done I don't really know. Multiply that across a few dozen people and what you have is pretty squishy. I wouldn't mind seeing people be a little more vocal on the hackers list about what they plan to be doing, just so that there's not duplication of effort. But trying to assemble that into some sort of published Master Plan sounds to me like just a recipe for making ourselves look foolish when the Plan ends up having little relationship to reality. > - What are you working towards? Performance? Stability? X? Yes. Bruce used to try to describe our releases as being oriented towards some particular goal, but I always thought that these were after-the-fact descriptions that had nothing to do with the real development process. The truth is that individual developers work on what they feel like, or find interesting, or in some cases get paid to do. But just as there's not a master plan, there's not really some guiding vision that in a particular release we are going to focus on X or Y or Z. Note: the above is just my two cents and shouldn't be read as speaking for Core. I think if you asked the other members of core you'd get roughly similar answers, but each with his own spin. regards, tom lane
pgsql-advocacy by date: