PgCon 2019 Developer Meeting
A meeting of the interested PostgreSQL developers is being planned for Tuesday 28 May, 2019 at the University of Ottawa, prior to pgCon 2019. In order to keep the numbers manageable, this meeting is by invitation only.
The invitation list for the meeting has changed this year to include representatives from various project sub-teams, for example, packagers, the release team, Code of Conduct committee and more.
As at last years event, an Unconference will be held on Wednesday for in-depth discussion of technical topics.
This is a PostgreSQL Community event.
Meeting Goals
- Define the schedule for the 13.0 release cycle
- Address any proposed timing, policy, or procedure issues
- Receive updates from project sub-teams on their activities and discuss any resulting issues or concerns.
- Address any proposed Wicked problems
Time & Location
The meeting will be:
- 9:00AM to 12PM
- DMS 3105 - Desmarais Hall, 55 Laurier Avenue East
- University of Ottawa.
Lunch will be served after the meeting.
RSVPs
The following people have RSVPed to the meeting (in alphabetical order, by surname). Note that we can accommodate a maximum of 30!
- Joe Conway
- Jeff Davis
- Andrew Dunstan
- Peter Eisentraut
- Andres Freund
- Stephen Frost
- Peter Geoghegan
- Robert Haas
- Magnus Hagander
- Stacey Haysler (present for CoC report and discussion only)
- Álvaro Herrera
- Amit Kapila
- Jonathan Katz
- Tom Lane
- Heikki Linnakangas
- Noah Misch
- Bruce Momjian
- Thomas Munro
- John Naylor
- Dave Page
- Michael Paquier
- David Rowley
- Masahiko Sawada
- David Steele
- Robert Treat
- Tomas Vondra
- Gregory Stark
The following people will not be in Ottawa, and do not plan to attend:
- Christoph Berg
- Vik Fearing
- Devrim Gunduz
- Andreas Scherbaum
- Sarah Conway Schnurr
- Alexander Korotkov
- Ilya Kosmodemiansky
- Amit Langote
- Haribabu Kommi
Agenda Items
- 13.0 release and commitfest schedule (Dave)
- Contributor Recognition (Andres, happy to share / pass, but should be discussed)
- contributors page update - how well is it working?
- should the developer meeting serve as recognition?
- The Evolving Developer Meeting: Goals & What We Want to Accomplish by the end of it? (Jonathan, happy to share)
- SQL standard update (Peter E.)
- Locale apocalypse (Peter E.)
- Criteria for major version release notes (Peter Geoghegan)
- Release notes depth level (Álvaro Herrera, happy to share)
- Please add suggestions for agenda items here. (with your name)
Agenda
| Time | Item | Presenter |
|---|---|---|
| 09:00 - 09:10 | Welcome and introductions | Dave Page |
| 09:10 - 09:20 | Code of Conduct report and discussion | Stacey Haysler |
| 09:20 - 09:25 | Core team/PGCAC update | Dave Page |
| 09:25 - 09:30 | Infrastructure update | Stephen Frost |
| 09:30 - 09:35 | Web & Advocacy update | Jonathan Katz |
| 09:35 - 09:40 | Funds & Sponsors update | Robert Treat/Joe Conway |
| 09:40 - 09:50 | 13.0 release and commitfest schedule | Dave Page |
| 09:50 - 10:10 | Contributor Recognition: Contributors page update; how well is it working? Should the Developer Meeting serve as recognition? | Andres Freund |
| 10:10 - 10:30 | The Evolving Developer Meeting: Goals & What We Want to Accomplish by the end of it? | Jonathan Katz, Dave Page |
| 10:30 - 11:00 | Coffee break | All |
| 11:00 - 11:10 | SQL standard update | Peter Eisentraut |
| 11:10 - 11:20 | Locale apocalypse | Peter Eisentraut |
| 11:20 - 11:35 | Commitfest Management | David Steele |
| 11:35 - 11:50 | Release notes: Criteria for major version release notes and depth level. | Peter Geoghegan, Álvaro Herrera |
| 11:50 - 12:00 | Any other business | Dave Page |
| 12:00 | Lunch |
Note: This timetable is a rough guide only. Items will start as soon as the previous discussion is complete (breaks will not move however). Any remaining time before lunch may be used for Commitfest item triage or other activities.
Minutes
Jonathan Katz recording.
09:00 - 09:10 Welcome and introductions
Dave Page: Welcome to the 10th(?) annual developer meeting in Ottawa. Lots of new faces, let's do introductions
People go around the room making introductions about what they do. Given how verbose the group is on the mailing lists, people are surprisingly brief.
Dave Page: We will be having a few reports from various projects that we do not normally hear from. The reason for this is that every year I partially struggle trying to find items for the agenda. We do usually end up having good discussion at the end of the day. It has also been mentioned a number of times, and this came up at the dev meeting in Brussels is that we have always been very focused on the core project, PostgreSQL itself. Some people at that meeting felt that it would be beneficial to hear the wider view of some other aspects of the project.
We will have some discussion time later on in the meeting to discuss whether or not this is working, if it's something that we want to continue, etc. We will hear from other aspects of the project. Hopefully we will find it interesting and there will be some useful discussion to be had.
Kicking it off, Stacey Haysler.
09:10 - 09:20 Code of Conduct report and discussion
Lead by Stacey Haysler
Stacey Haysler: Code of Conduct Committee kicked off last year. One was a threat of personal violence which resulted in a personal ban. There were two reports of sexual harassment. One resulted in a request for continuing education. One resulted in a temporary ban.
No current active investigations. We are encouraging conference organizers to reach out to us for educational resources for understanding how to handle a code of conduct complaint if it should come up. The CoC committee is here to help.
Q&A proceeds about general nature of incidents, how they occurred. How the CoC was modeled after other communities and what the PostgreSQL community does. Discussion of the overall effect of the CoC committee. Stacey covers the CoC process in terms of what happens when a complaint is made.
09:20 - 09:25 Core team/PGCAC update
Lead by Dave Page
Dave Page provides an update.
09:25 - 09:30 Infrastructure update
Lead by Stephen Frost
Stephen Frost: We bought a server last year -- have a project server being hosted by Magnus Hagander & co. We continue to have a lot of things donated to us. New boxes from Packet.net. We will be moving the buildfarm server because it's getting too big, will be giving it to Packet.net. Packet has given us 3 very large systems. Upgrading buildfarm will be a part of it: upgrading, partitioning, and getting it onto a version of PostgreSQL that's not EOL.
The other big project going on is upgrading the wiki. It has been ongoing for 3 years. It is not a trivial to do.
PGLister continues to be a good project and we continue to hack on it. Sometimes there are things that people don't like, but we go into it and improve it.
Andres Freund: Could we have some stats about traffic, downloads, etc. publicly?
Stephen Frost: We could possibly share some of the Grafana dashboards.
Peter Eisentraut: Who else are admins? Do we have enough people? Do we need to train new people? How many servers do we have? Who is paying for them?
Stephen Frost: At present, we are doing pretty well. Servers are being maintained. We have agreements with all of our providers for physical maintenance of them. Keeping up-to-date with patching. The biggest issue we have at the moment is that some of the larger projects are larger projects, and figuring out when we can spend time on that project spending on other stuff.
Not sure if we need more people at the moment.
Peter Geoghegan: Is there a coverage issue of people being awake?
Magnus Hagander: Joe has ruined that by moving.
Andres Freund: Is there a related problem that you have been in the project for ages and the project is not renewing? Do we need newer people on it?
Magnus Hagander: That is a fair point.
Stephen Frost: Newest person is Joe on the team is Joe and he's 5 years ago.
Robert Haas: How do people get involved in infrastructure side of things?
Magnus Hagander: Accidentally on purpose.
Robert Haas: The process could be better, e.g. on the development side, there is a way to do so. Less clear on the sysadmin side.
Magnus Hagander: We have sysadmin, and non-sysadmin. Once you are on the sysadmin team, you have access to everything. It is harder to step in and volunteer on that. We can work on better ways to get separation of concerns.
Stephen Frost: If you are volunteering to help us run everything as opposed to some things, that would be better.
Agreement to discuss more.
Actions Items
- Infrastructure team to discuss ways to recruit new members to the team
09:30 - 09:35 Web & Advocacy update
Lead by Jonathan Katz
Unfortunately the person recording could not record all responses as he was presenting. Notes read more of a summary of discussion
Jonathan Katz: Main project last year was the redesign of the website. Goals where to make it easier to get to key pages (e.g. downloads, documentation), mobile friendliness, and overall ease of use.
Learned lessons from poor rollout of changes to the archives viewer that made them less friendly than before, and created a "beta" period to test new documentation pages. This seemed to be a good strategy to collect feedback. Would like to work with pginfra to make said testing easier.
To measure success of these initiatives as well as a variety of advocacy initiatives, looked at overall web traffic to see if there have been changes. Did a year-over-year comparison (May 28, 2018 - May 27, 2019 vs. May 29, 2017 - May 27, 2018).
- Homepage ~4.8% increase. This was used as a baseline
- Downloads: ~32.5% increase. Windows / Mac downloads pages had a 24% / 27% increase in traffic respectively
- Documentation: 37% increase in traffic.
- As an interesting note, the about page had a 63% increase in traffic. The overall content on the about page had changed to provide a higher-level overview of features PostgreSQL offered, information about its adoption, ways to get started, and some statistics about the project.
Interestingly, the traffic to the press release on the PostgreSQL website between PG11 and PG10 was down ~50%, but we still see an uptick in overall numbers. On hypothesis is that we did a better job in overall awareness of the release so that our users knew what features were coming and as such were ready to download, but cannot draw any definitive conclusions.
Peter Geoghegan makes suggestions on how to make the archives mobile friendlier. Jonathan Katz asks him to report said suggestions to pgsql-www@lists.postgresql.org
Recently had the PostgreSQL 12 Beta 1 announcement. Year-over-year stats compared to PostgreSQL 11 Beta 1 announcement show a 16.6% increase in reading of press release, and a 20% increase to the downloads page.
Other major projects include:
- Moved platform to Python 3
- Documentation: remove `/static/` URL; support for SVGs to be scalable
- Release notes archive now on website
- Lots of cleanups
- Cleanup of professional services & platform pages, as it had been 5 years :(
- Reorganization of feature matrix...though probably needs more
- Removal of regional contacts page
- Contact page reorganization. Tried to get people to the correct points of contact more easily, but not sure if it's working
- Code linting
The Twitter account has grown from 0 to almost 12,000 followers over the course of 16 months. The one thing we suffer from is consistency of tweets; could be helped with by having more people.
With events, a lot of events have adopted the community guidelines that have been proposed.
Actions Items
- Ongoing web projects
- General navigation and navigation on specific pages
- Content rewriting & cleanups
- Incorporating training guidelines to list training companies on website
- APT viewing project
- Figuring out better ways of handling drive-by patches
- Recruiting more people to Twitter team
09:35 - 09:40 Funds & Sponsors update
Lead by Robert Treat & Joe Conway
Joe Conway: Years ago, there was an original effort to create a NPO for PostgreSQL like the Linux Foundation. This did not happen. When that was dissolved, there was a formation of a funds group that is connected to Software in the Public Interest, which was an org that Debian formed to manage funds that come in to sponsor the project.
The funds group was a team of people that were volunteered to provide governance to the project to govern the use of money. This group has been a various activities over the years. It was set up so that a Liaison would direct the funds with SPI. There was also a board adviser that would watch over the SPI board. This group had not changed over around 12 years.
Last year, a bunch of things has changed. Currently there are 17 people who are active members. According to the self-agreed governance rules of that group, if you wanted to be a part of the group you would send a message funds-group@lists.postgresql.org; if you are interested in sending money you would also send a message to that group.
Last year, we had to disable accepting donations via credit cards due to GDPR. We were able to recently re-enable it. We reconciled the membership as well.
The PostgreSQL website was directing all the traffic to an individual, now it is going to a more generic address. Back in February, we had elections. Robert Treat is the SPI Liaison. Dave Page determined that SPI does not actually use board advisors. We changed the second position to be a backup liaison. Dave Cramer is the backup liaison. We revamped the governance documents, and migrated them to postgresql.org. Need to set a forwarding address.
In terms of actual spending -- the current funds according to SPI are about $142,000 USD. Need a better system to figure out what we have spent on as we currently have to go through emails. In the past year:
- $500 for artwork for PostgreSQL 11
- ~$12,500 for servers
- $300 for press release for PostgreSQL 11
- $260 for expenses for GSoC travel
- $4400 for expenses for Slonik lapel pins
Currently under discussion:
- $500 for artwork for PostgreSQL 12
- Google Code-In has donated specific money earmarked for specific purpose. Pre-advance: $700 for person
- USB drives: looking to buy a bunch for $3000
- Hex stickers with Slonik - $1200
- Baseball caps - $1500
Greg Stark: I'm surprised how little we have spent on travel for conference for students and how much we have spent on merchandise.
Peter Eisentraut: The reason is that this group is not super well known. We need to better advertise that this exists.
Peter Geoghegan: Is there an issue with that someone does not feel empowered to write a real check?
Joe Conway: We have no gotten ourselves into the past 6 months advertising the availability of this.
Robert Treat: Important to understand is that this group has been around 15 years; there are also a lot of other groups (PgUS, PgEU, JPUG); the funds group is the only one that has an international charter to help, but we also try to encourage people to reach out to their local groups.
Andres Freund: Is there a chance that you can do a yearly report like the CoC does?
Robert Treat: Those records are more public, and we want to do a better job of showcasing it
Greg Stark: Is there a holistic view of where you want to be spending money when receiving donations? If you are only approving things by a case-by-case basis, you might in a situation where e.g. you are only spending on one thing.
Robert Treat: There is not a specific agenda as of yet, but that could be discussed.
Robert Treat: On the PostgreSQL website, there is a page where we list corporate sponsors of the PostgreSQL project. Over the past year, we have gotten our act together. There is a group of five people that should discuss which companies should be listed and not listed per guidelines. We take a group vote to say yes / no. There are only two categories: Major Sponsor, and Sponsor. We have committed to updating it at least every 6 months.
One of the big goals in general is to create more visibility, so we have added to the website how the group works and when we have last updated the sponsors list.
Action Items
- Funds group to work on making funds group as a resource more visible through community channels
- Funds group to work on creating a plan for how funds are spent as well as fundraising goals once that is set
09:40 - 09:50 13.0 release and commitfest schedule
Lead by Dave Page
General consensus is to branch just before the first PostgreSQL 13 commitfest.
Dave Steele: The extra commitfest saw about as many commits as any non-final commitfest.
Andrew D: The July one did not appear to have a much patches committed
Peter Eisentraut: There were about 50 patches that were otherwise handled.
David Steele: Patches that are backlogged are often backlogged for a reason. They are no less problematic in July than they are in March. I think the extra CF was useful. The question was was it too much burden on the committers? If committers ok with it?
Dave Page: Anyone object to doing the same as 12?
Consensus is same as last year.
Andres Freund: One mildly related issue: I suggest that we do not have RMTs that have non-overlapping timezones.
Action Items
- Branch for PostgreSQL 13 will occur just before July 2019 commitfest
- Commitfest schedule will be mirror that of PostgreSQL 12 cycle: July 2019, Sep 2019, Nov 2019, Jan 2020, Mar 2020.
09:50 - 10:10 Contributor Recognition: Contributors page update; how well is it working? Should the Developer Meeting serve as recognition?
Lead by Andres Freund
Andres Freund: This came up in a somewhat unrelated discussion was that the developer meeting serves as recognition for some developers who are otherwise not well recognized. Some people suggested it was a good idea, some bad. That made me also wonder how we deal with recognition. I noticed that the developers list was outdated.
Stephen Frost: One item is that we have a contributors team that is trying to figure this out. It has been unfortunately quiet. IIRC it's Robert Haas., Vik F., Dave Page., and myself.
Robert Haas: We've had a little bit of email discussion and it tailed off. We need to figure some things out. This process is hard as there is subjectivity about measuring levels of contribution. There is also subjectivity about every other aspect of the process.
Dave Page: Basically a similar problem with the sponsors, but five times harder.
Robert Haas: I would be glad to have a few more people contributors team -- would be helpful to have a few more discussions around that. We have enough consensus that we can get some changes done and enough effort that those changes can be made. Things are imperfect, but we will figure it out.
Peter Eisentraut: I know it's hard work and please keep it up, one sort of scheduling point is that traditionally that these sort of updates have been around this time of year, which probably confuses a lot of people that contributed to Release X, they then have to wait another year to somehow be listed. If you could aim for a 6 months schedule or try to get it updated at least twice a year.
Robert Haas: If we got a complete update of all of it done once, that would be a good first step. In terms of measuring of whether someone should be listed of a Contributor vs. Major Contributor. There have always been a lot of people that we do not list. We could easily list everyone who has made a contribution to PostgreSQL, and that list could be on the order of 1000 people. The more that we adjust the standard, the more people we could recognize. However, that is a bigger administrative burden.
Discussion ensues over process.
Robert Haas: There is an issue where people contribute over years and they do not get recognized at all. This is one reason why I started my blog post on code contributions to be able to shed some light on who contributes.
Peter Eisentraut: Can we have the team to establish a short term target? Set the process in place by X.
Stephen Frost: Let's set some cadence around the team.
Robert Haas: +1. We need to make it more clear what factors are taken into consideration.
Dave Page: One thing we have learned from the sponsors is to not try to codify too much. List general guidelines, but as soon as you try to codify an actual algorithm / scoring criteria, you will be bikeshedding for years etc.
Heikki Linnakangas: If you do it more often, like 6 months, or even 3 months, you come up with a list of new people and who has contributed in the last few months. It is easier to come up with names who are active or became active recently. You can keep track if they are continuing to do so, and later if they are still active and actively contributing, that's a way to make it work.
Robert Treat: I used to maintain the list when I maintained it myself. If I knew someone who should be on that list, I would add team. When new committers are being evaluated, and they are not a recognized contributor, they probably should be on that list.
Robert Haas: Let's at least have a chat for all those who are here.
Dave Page: Just to explain the original intent: the developer meeting from the very first one that was organized was never intended to be any form of recognition. It was intended that the developers who were the biggest contributors were the ones that were invited.
Andres Freund: Should we consider removing the list from the wiki?
Peter Geoghegan: There is an implicit recognition. People will feel recognition.
Discussion ensues over publication of RSVP list.
Andres Freund: Clear information about the different sections on the contributors website.
Jonathan Katz: +1; part of content rewrite.
Heikki Linnakangas: If we can change the theme of each meeting every year and vary the theme, would help with how people perceive the meeting.
Peter Geoghegan: +1
Dave Page provides history of the meeting.
Action Items
- Contributors team will work on setting up some guidance into what is taken into consideration on list. Will set up a more regular cadence for evaluation
- Will work on setting some short term goals on getting this done
Dave Page: Let's move evolving developer meeting agenda item to the end.
10:35 - 10:45 Coffee break
Peter Eisentraut: We have a new committer as of right now. David Rowley.
Congratulations and huzzahs all around
10:45 - 10:55 SQL standard update
Lead by Peter Eisentraut
Peter Eisentraut: As of earlier this, I am a member of the SQL Standard Working Group. I had a chance earlier this year to meet people who are active in the group and gave me some starting points on what is actually helpful. Volunteer effort: work is done by people who show up and do the work.
My goal is to make sure that we are not blindsided by new developments. I felt that SQL:2016 surprised a bunch of people on some of the work, e.g. JSON functionality. I want to keep an eye on what is going on for now. Next update is the plan for 2020 or 2021. If there is more interest, I can organize an unconference session tomorrow to talk about what's going on.
Andres Freund: Are there other meetings?
Peter Eisentraut: One in South Korea, not planning to go. Some meetings next year closer to where I live. There is a certain time investment in terms of participating actively. IF anyone has questions, please let me know.
Stephen Frost: From discussions you've had, any feeling / thought / impressions of PostgreSQL?
Peter Eisentraut: From people I've discussed they've heard of PostgreSQL and happy we are getting more involved.
John Naylor: Do other OSS projects have representation there?
Peter Eisentraut: I don't think so.
Action Items
- With Peter being on the committee, we will better know what changes are coming into SQL standard that could affect ongoing or planned work
- Exploring what will happen with new committee membership
11:00 - 11:10 Locale apocalypse
Lead by Peter Eisentraut
Peter Eisentraut: In glibc 2.28 which was published Aug 2018, they changed the locale significantly. The Linux distributions with LTS are now starting to come out. The first one was RHEL 8 which came out a few weeks ago. This change will affects such users
What do we do? It's too late to bake something into PostgreSQL. We can't put a bug fix into glibc. There is a wiki page Locale Data Changes is that at the very least we send people to it to understand the changes.
Thomas Munro: A bunch of operating systems have given up on dealing with it and are converging on UCA.
Greg Stark: Can we do something with point releases?
Peter Eisentraut: For users, they will be affected by operating system upgrades.
Heikki Linnakangas: How can users detect the issue?
Peter Eisentraut: We have put tests on the wiki page. We have also collected the behavior changes across a variety of operating systems where the behavior changes. We advise after upgrade, run amcheck or reindex or both.
Michael Paquier: Can we make REINDEXDB more smart about that?
Peter Eisentraut: Potentially, yes.
Thomas Munro: There is a massive thread about this. Probably an unconference discussion on this.
Peter Geoghegan: You can use ICU of cousre but only as a per-column location.
Peter Eisentraut: My goal for PG13 would make ICU global.
Peter Geoghegan: It would be nice to make it the de facto standard on certain platforms.
Stephen Frost: Like all of them.
Peter Eisentraut: Looking forward to discussing more tomorrow.
Action Items
- Ensure information about the locale issues that can crop up are effectively communicated to users. Have Locale Data Changes as starting point
- Unconference session about locales
11:10 - 11:25 Commitfest Management
Lead by David Steele
David Steele: First thing I would discuss is the extra commitfest in PG12; sounds like we will continue doing that. Increases overall capacity during the year. The focus on older patches that were at least doable.
We have an ongoing problem that we discussed last year: we have patches that go on from commitfest etc. and year-to-year. Sometimes it is because the patch itself is not ready; sometime it is because people who cannot get their stuff into e.g. a PG12, they will drop it. It is hard for people to take unmaintained patches seriously.
We added the feature where we tag CF entries to say for being PG13 even though it was in the CF for PG12. It was both good and confusing. You had to constantly filter to see what we were considering for 12. However, people were less upset when I marked it for PG13 and pushed it to the next commitfest.
Andres Freund: A lot of the items that got feedback; knowing it was for PG13 was "I can give it review, but may not be as thorough knowing that it wouldn't be for 12."
David Steele: I would like to say that Andres Freund' triage for the CF items has been invaluable. Been great to compare my notes to his notes; makes it easier to deliver bad news to people when a patch needs to be moved..
As far as the filtering goes, I would find I would have to munge the filters for the items that I am looking at. It would be nice to have a "not" filter, e.g. "NOT PG13" so I could look at the "current" stuff. Or a filter that is "current" so I can see what is currently what's going on for current / stable view.
Andres Freund: On the triage item, I'm glad to do it but I would like if other people would triage and as well. It would help be less arbitrary if it was just me. If more people chimed in, triage, and said "Hey it's not ready because XYZ"
David Steele: Having your triage helped me to move items that did not belong in PG12. I used a different method for tracking the stuff I was looking at this year. There is nothing in the CF app that lets me know if I recently viewed a patch.
Discussion ensues about some of the commitfest process and about marking a patch as a work-in-progress.
David Steele: Marking as the current version is a declaration of intent, i.e. we are planning to get something into 12.
Stephen Frost brings up topic about how we can ensure there is a steady stream of CFs
Andres Freund: Perhaps we need to do more to reject patches which could help ease some of the burden of managing commitfests.
Discussion ensues about various procedural issues.
Thomas Munro: Earlier you were talking about target version. Why are bugs subject to different versions of commitfest items and why should they be subject to certain rules?
Tom Lane: We basically have that list of bugs there so we don't forget about it.
Thomas Munro is volunteered to be CFM
Jonathan Katz: Suggest adding these guidelines + recommendations to the wiki: Running_a_CommitFest
Jonathan Katz is happy to help Thomas with CFM
David Steele: Noting that last one tends to be most challenging given there are some other challenges beyond just technical aspects.
Action Items
- Update Running_a_CommitFest on best practices that David Steele has mentioned.
- Thomas Munro & Jonathan Katz should sync up on commitfest management work
11:35 - 11:50 Release notes: Criteria for major version release notes and depth level.
Lead by Peter Geoghegan and Álvaro Herrera
Peter Geoghegan: There was a consensus against the current model that the current level for technical depth is appropriate, we are after all not as close to users. There are a number of people, including myself, that feel the level of depth of the release notes is insufficient as it does not support the goals of the release notes to provide insight into what they could benefit from, e.g. things that could have regressed workload, etc.
The inclination of the development community is increasingly towards performance stuff. Perhaps the current model made more sense on its own terms previously, and perhaps the current model could be revisited.
Noah Misch: Do you have a concrete proposal?
Peter Geoghegan: I would suggest that there could be more deference given to the views of the author in each case.
David Rowley: One of the things that gets left out commonly is query planner improvements, and I think it's a problem. Recently I had a customer upgrading from 9.2 => 9.6, and they had a query that was performing better. It had an EXISTS with a LIMIT 1 clause. I remember the patch in 9.5 that affected this. I remembered the commit that was broken, fixed it, changed it etc. I suggested to the customer to review the release notes as well for other changes, but said change was not in the release notes.
Peter Eisentraut: Other than the length of the release notes, what would be the counter argument for adding more detail?
Robert Haas: I agree in general. The challenge, as I understand it, is that it is difficult from the commit messages is that it's hard to judge how much detail the users care about and how do you explain that clearly.
Bruce Momjian: There are two issues I think about in making the release notes in trying to make the release notes digestible to users. I get why all of us would like to see that kind of detail that helps with more technical details. I write the release notes for people who are going to be reading all of the release notes.
One criteria I use is the length of the notes. The second thing I do is that if I hit three items that I cannot make sense of as a regular user, then I may tune out.
Robert Haas: The issue is that there is nothing else. The situation David R. is talking about is that it happens. If you cannot find the information in the release notes, you have to look in the commit log. I don't really agree with the idea that we should be afraid of things in the release notes because we are worried that people will not understand them. I worry we lose more that we are not documenting things that are important to people.
Peter Eisentraut: There are strategies to try to make adding the items more accessible.
Stephen Frost: We should at least list the things that are included; they may not have a lot of information in the note itself, but we can point to it.
Peter Geoghegan: I'm fine with it being a discrete item, but the point is that it needs to be discoverable.
Bruce Momjian: I would also love to see wiki pages on it, so I can discover it myself.
Robert Haas: These are workarounds for lacking documentation. Example is: planning around partitioning is faster in certain cases. Do we have documentation around which cases?
Can have drill downs for places to get more information.
Alvaro H: Another place we can do that is to add additional items to the feature matrix.
Andres Freund: Need to be careful about use feature matrix for features vs. behavioral changes.
Noah Misch: Need to ask ourselves are we happy about surprises users might see
Tom Lane: I'm afraid that a lot of these cases is that the thing the user is wishing to see is an unintended consequence of the release.
Jonathan Katz: In user days, would definitely re-read major release notes to find things. Can make it easier on pgweb to point out where to find where major incompatibilities changed.
Discussion on going back to ensure that old release notes document incompatibilities
Stephen Frost: Dedicated area for incompatibilities?
Greg Stark: Want to ensure we highlight incompatibilities that could surprise the user.
Heikki Linnakangas: It would be nice to drill down further on the features, wherever it may be. Could make it part of the documentation.
Peter Eisentraut: Do we want to try to do this for PG12?
Peter Geoghegan: It's only a matter of displaying information that is already there.
Bruce Momjian: Show the specific commits around it?
Action Items
- Research into ways to provide more details within the release notes with hidden description boxes, etc.
- Further discussion on ways to surface incompatibilities between versions
- Look into displaying URLs to commits in release notes, as information is available
11:50 - 12:20 The Evolving Developer Meeting: Goals & What We Want to Accomplish by the end of it?
Lead by Dave Page and Jonathan Katz
Dave Page: This meeting -- where should it go next? What do we want to accomplish?
Peter Eisentraut: The obvious problem is that we have expanded it, we are running out of time. Should we allocate more time?
Discussion ensues about requiring more time and capacity of the meeting.
Robert Haas: We could also have a couple of meetings. When we pushed the tech discussion out of this meeting, it pushed it back down to half a day. It allowed more people to be around in technical discussions. It could also help break out special purpose meetings. Could help have more open meetings, e.g. having a contributors meeting that people can openly attend.
Dave Page: Allows to have updates from other parts of the project so things do not get too compartmentalized.
Jonathan Katz: Great we have reports: good to see things beyond project. Want to ensure we have actionable follow-ups, the topics brought up seemed to affect across entire community.
Peter Eisentraut:
1. Do we want to make the meeting larger
- 1 General consensus is no.
2. Do we want to make it a full day?
- 2 General consensus is yes.
Noah Misch: Technical topics that work well are topics that are well known and have not been solved yet through community methods, e.g. locales or working with bug fixes languishing in commitfest.
Dave Page: People can always present items for the agenda and can have a discussion on whether it should be in the meeting or be in the unconference.
We will keep the meeting the same size. We will aim for a six hour meeting. Stephen & I will work on it again and call for volunteers (Andres Freund is voluntold). Include updates from various project areas. Keep them to 10 minutes each. We need to have a deadline to decide when people are invited by.
Action Items
- Having different parts of the project present and participating in the meeting is good and should continue
- Ensure invites can be sent out by the early New Year 2020.
- Dave Page, Stephen Frost, Andres Freund
Meeting adjourns at 12:20pm.
