Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 |
| Date | |
| Msg-id | CAKFQuwYJA0r3wy+rNgrGdJx8tJ-udsQLCERo+xY+HqpVs_MLRQ@mail.gmail.com Whole thread Raw |
| In response to | Re: Lets (not) break all the things. Was: [pgsql-advocacy] 9.6 -> 10.0 (Oleg Bartunov <obartunov@gmail.com>) |
| Responses |
Re: Lets (not) break all the things. Was: [pgsql-advocacy]
9.6 -> 10.0
(Robert Haas <robertmhaas@gmail.com>)
|
| List | pgsql-hackers |
* we don't *know* that any of the above items will require a backwards
compatibility break.
People keep talking about "we might want to break compatibility/file
format one day". But nobody is working on anything which will and
justifies it.
Our roadmap http://www.postgresql.org/developer/roadmap/ is the problem. We don't have clear roadmap and that's why we cannot plan future feature full release. There are several postgres-centric companies, which have most of developers, who do all major contributions. All these companies has their roadmaps, but not the community. I think 9.6 release is inflection point, where we should combine our roadmaps and release the one for the community. Than we could plan releases and our customers will see what to expect. I can't say for other companies, but we have big demand for many features from russian customers and we have to compete with other databases. Having community roadmap will helps us to work with customers and plan our resources.
I've already posited just having our release numbers operate on 5-year increments 10.0 - 10.4; 11.0 - 11.4, etc on advocacy but was met with silence. In any case this comment is just furtherance of the tail wagging the dog. I see no fundamental reason to have to plan something momentous enough, and actively schedule work to meet the plan, in order to justify a 10.0 release.
There is a bunch of hand-waving here, and its an environment I'm not immersed in, but it seems that creating a roadmap today is tantamount to waterfall design - useful in moderation but has largely shown to be undesirable at scale. Aside from the 1-year release cycle the project is reasonably agile and well receptive to outside observation, questions, and contributions. If you have spare resources you need to keep busy just ask how you can help. To be honest the community would likely rather have those people help review and test everything that is presently in-progress - future goals on a roadmap are not nearly as important. And if you have a demand you think needs to be fulfill put the information out there and get input.
If you are claiming the balance between community and profit is skewed undesirably you will need to put forth a more concrete argument in order to convince me. For me, having plans reside in the profit-motive parts of the community and having core simply operate openly seems to strike a solid balance.
I give a solid +10 to Robert's opinions on the matter and aside from figuring out if and how to fit first-number versioning dynamics into our release policies I think the community is doing a sufficient job on the communication and planning front. The biggest resource need is quality control. I dislike the fact that we are currently in a situation where the first 3 point releases each year are considered "live betas" based especially on both 9.3 and 9.5 post-release significant bug counts.
David J.
pgsql-hackers by date: