FOSDEM/PGDay 2019 Developer Meeting

A meeting of the interested PostgreSQL developers is being planned for Thursday 31st January, 2019 at the Brussels Marriott Hotel, prior to FOSDEM/PGDay 2019. In order to keep the numbers manageable, this meeting is by invitation only. Unfortunately it is quite possible that we've overlooked important individuals during the planning of the event - if you feel you fall into this category and would like to attend, please contact Dave Page (dpage@pgadmin.org).

Please note that the attendee numbers have been kept low in order to keep the meeting more productive. Invitations have been sent only to developers that have been highly active on the database server over the 10 and 11 release cycles. We have not invited any contributors based on their contributions to related projects, or seniority in regional user groups or sponsoring companies.

This is a PostgreSQL Community event.

Meeting Goals

• Review the progress of the 12.0 schedule, and formulate plans to address any issues
• Address any proposed timing, policy, or procedure issues
• Address any proposed Wicked problems
• Commitfest Triage

Time & Location

The meeting will be:

• 9:00AM to 5:00PM
• Brussels Marriott Hotel

Coffee, tea and snacks will be served starting at 8:45am. Lunch will be provided.

RSVPs

The following people have RSVPed to the meeting (in alphabetical order, by surname) and will be attending:

• Christoph Berg
• Joe Conway
• Andres Freund
• Stephen Frost
• Daniel Gustafsson
• Devrim Gündüz
• Magnus Hagander
• Álvaro Herrera
• Amit Langote
• Thomas Munro
• Dave Page
• Masahiko Sawada
• Tomas Vondra
• Gregory Stark

The following people have sent their apologies:

• Peter Eisentraut
• Etsuro Fujita
• Peter Geoghegan
• Kyotaro Horiguchi
• Tatsuo Ishii
• Amit Kapila
• Jonathan Katz
• Tom Lane
• Noah Misch
• Bruce Momjian
• Craig Ringer
• Simon Riggs, on holiday that week
• Pavel Stehule

Photo

Top row, left to right: Andres Freund, Stephen Frost, Daniel Gustafsson, Dave Page, Devrim Gunduz, Magnus Hagander, Amit Langote

Bottom row, left to right: Álvaro Herrera, Thomas Munro, Greg Stark, Christoph Berg, Joe Conway, Masahiko Sawada, Tomas Vondra

Agenda Items

Please add agenda items here!

• Communication between hackers and packagers (Devrim)
• Bug tracking / Bug ID / Links to bug threads (Stephen, and Magnus, though he doesn't know it yet)
• Contribution recognition (Stephen)
• PGCon plans, and such (Stephen)
• RMT for v12 (Stephen, plus whomever...)

Agenda

Time	Item	Presenter
09:00 - 09:10	Welcome and introductions	Dave
09:10 - 09:20	12.0 Release Review	All
09:20 - 09:40	Communication between hackers and packagers	Devrim
09:40 - 10:00	Bug tracking / Bug ID / Links to bug threads	Stephen/.Magnus
10:00 - 10:20	Contribution recognition	Stephen
10:20 - 10:30	RMT for v12	Stephen
10:30 - 11:00	Coffee break	All
11:00 - 11:15	PGCon plans and such	Stephen
11:15 - 12:30	???	All
12:30 - 13:30	Lunch	All
13:30 - 15:00	Commitfest Triage	All
15:00 - 15:30	Tea break	All
15:30 - 16:45	Commitfest Triage	All
16:45 - 17:00	Any other business	Dave
17:00	Finish

Minutes

9.20:  12.0 Release Review
==========================

Dave: Are we on track, is there anything we want to change about the way we do the release?
Andres: We should decide on a target date
Stephen: We should do that the same as last year
Andres: We had a lot of last minute questions about whether patches go in...
Stephen: We should do some thinking about how to avoid that
Magnus: Knowing the freeze window head of time would be good
Greg: Then people will plan to put something in on the last day of the freeze
Stephen: We would like it if people wouldn't put large patches in the last CF
Dave: A problem since ... how many years?
Andres: It's OK, we just kick them into the next CF (unready, new)
Stephen: Triage this afternoon may help with that.  What else could we do?
Magnus: For a while we had placeholder patches that people put in so they wouldn't miss the cut-off.  We should kill those.
Stephen: The important thing is that we really do that.  We had some cases where people felt very strongly that a patch wasn't ready but it went in.
Andres: We need to escalate to other committers faster.  We have other committers that only take a look at major patches after commit and then they find a lot of problems.
Stephen: Problem is that when someone signs up no one else will look.
Magnus: We need a way to detect the cases where something needs more committers to review.
Stephen: How about: if a committer says that they have a concern then maybe the item goes on the "open items" list.
Magnus: How about: if one committer objects, a new process that requires another committer to ...
Joe: Perhaps there should be a wording you can use to say you want to block the patch until another couple of committers get involve to resolve the problem.
Stephen: Commitfest status?
Andres:
Stephen: If someone commits after that status is set without a resolution process, then it becomes clear to everyone that it needs to be reverted, without complicated pain.
Magnus: The problem is social, not technical.  Let's start with the question of who triggers the process and how it gets resolved.
Andres: Perhaps CCing core, as a documented process.  Who can I contact?
Greg: There is a risk of doing things in private.
Stephen: It might go over better if something things are not discussed in public (ie reverting).
Magnus: Technical problems should be addressed on hackers.
Stephen: If we do it on on private lists we give people a chance to go back onto -hackers to discuss the technical question.  Giving someone an opportunity to publicly reconsider and decide on their own that they want to revert it.  private-committers is better than personal emails.  We need a policy, and perhaps we could discuss it at pgcon.  Who wants to take that action item?
Everybody:
Stephen: If nobody objects I will draft a policy and then we'll see if there are objections.  There will be objections.
Magnus: It makes sense to float something on the private committers list, before we get to pgcon.  Let's not arrive there without a proposal.
Andres: Discussing it before the next BF to raise awareness would be good.
Stephen: I don't want to rush it, and come across as overbearing.
Andres: Right but we don't have to agree on the policy, just discuss the ideas.
Magnus: So people know that the issue exists.
Stephen: It's on my list of things to do before pgcon.  So basically by end of February.  Good discussion, I will work up a draft policy and float it.

Dave: We have a wiki section with procedures.
Andres: The wiki is incredibly out of date.
Magnus: It was also wrong when it wasn't out of date.
Stephen: Some of the policies are on the website and some are on the wiki.
Magnus: We should probably make the documentation scream at you when you're looking at an old version.
Stephen: Policies about development should be in the docs in the source tree.
Magnus: We should have a total index of policies that points to the docs, the wiki, ...
Dave: We could have them in the docs so that they're in the source tree but publish them on the website with other policies.
Andres: It does seem reasonable to have developer policies all in once place.
Andres: The commitfest processs should be in there.
Stephen: Action item for Andres.
Dave: I'm going to remove stuff from the wiki into the website.  It'll take that action point.  Archives policy, ... and other ones that are more or less up to date.  Those that are not up to date, I'll contact those people.  Most of them are probably alright.

Action points: Andres to document commitfest process.  Dave to move stuff from wiki to website.  Stephen to propose revert policy.

9:59:  Communication between hackers and packagers
==================================================
Devrim: There was a discussion about renaming a binary.  We have to dig.  I would ask the hackers to drop an email to the -packagers mailing list.
Dave: I have annoyed people in the past by forgetting to tell people about changes to pgadmin.
Stephen: What things need to go to packagers?
Devrim: Andres did a great job of communicating with me about how to package the JIT stuff.
Stephen: We can put that into a policy document.  Tell us what things there are... changing binary names, removing things, new dependencies, ...
Christoph: No body told me about the changes to the documentation build tools...
Thomas: Could RMT add a sign-off step, "have we communicated all packaging changes?"
Everybody: No!
Christoph: Should we enable new features by default?
Stephen: That is a whole other question...
Stephen: Floating point dates were a case where the packagers made a choice that we didn't directly control.
Greg: In cases where there is more than one option, like different SSL library implementations, we should leave that to packagers to do whatever is the preferred approach on that platform.  Packagers have real policy decisions to make, they're not robots.
Christoph: I had to rewrite pg_config in perl, to support cross compiling.
Alvaro: As a committer, do I need to tell you if I change a binary name?
Dave: Generally it's about knowing when changes are going to happen.  Right now we have no coordination with Debian packages etc.  I'd like to see us to things with more consistently.  But we need to know when things are changing upstream.  Adding a binary, etc.
Devrim: Example: a while ago I had to add support for pg_basebackup.
Thomas: Does this include header files that we export, and files like the errorcodes.txt?
Magnus: Devrim needs to write a policy on this.
Alvaro: Should we cross-post to -packagers?
Magnus, Stephen: No!  Devrim will give us a specific list of things that need to be send to -packagers.
Christoph: For distributions other than RHEL and Debian, people may not even be following -hackers.
Dave: packagers is not open because it has security information before the general public.
Stephen: Do we need another mailing list for these announcements?  More open?
Stephen: Consolidate various other end-user lists?
Dave: Devrim to propose policy to -hackers.  Someone needs to start -packagers/-hackers discussion about communication.
Christoph: I will.
Devrim: I would like the PDFs to be built.  Sometimes they break, but nobody notices upstream.
Thomas: When the HTML build was OK?
Devrim: Yes.
Dave: Do we need to have the PDFs built on a build farm animal?  Shall we ask Andrew to make that an option?

Action points: Magnus to talk to Andrew.  Devrim to propose communication policy document.

10:30: Coffee.

11:10:  Bug tracking / Bug ID / Links to bug threads 
====================================================

Thomas: Can we add clearer links to the pgadmin bug tracker from the bug reporting page?
Greg: Could we have a drop list and forward bug reports to those projects?
Thomas: Well at least a clearer link...
Stephen: I like the combo box.  Magnus?
Greg: I wouldn't have a problem with the list having Advanced Server or RDS etc.
Dave: Progressive reveal from a combo box, starting with a few options and adding more as we need them.
Magnus: I don't think we should generate messages for other projects.
Thomas: You could leave the mailing list at the centre but track the status.
Christoph: You could extend the commitfest app to do that.
Magnus: I have previously proposed that.
Thomas: The problem is that threads started by email (not the form) don't have an ID.
Dave: We own the mailing list software, so we could assign IDs to those.
Stephen: I have previously proposed that.
Christoph: The Wikipedia article for PostgreSQL notes that we have no bug tracker.
Greg: There are a lot of -hackers threads by Tom that describe "known problems".
Greg: I would like to compile a list of those emails.
Thomas: User bugs are not the same as "known problems" like "if you do this and you do that the planner gets confused".
Stephen: A link on the bug reporting problem to some known problems?
Dave: If you have a real bug tracker you have to do triage.
Stephen: We'd have to make sure that people can keep doing exactly what they're doing it today.
Alvaro: Nathan Wagner runs a system that classifies bugs by reading the -bugs mailing list.  I will write to the -hackers mailing list[1].
Christoph: That could become part of the CF app.
Stephen: Great, let's discuss this further on -hackers.

Action points: Greg to report on "known problems" from the mail list.

12:10:  Contribution recognition 
================================

Stephen: Robert and I have been doing reports on contributions.  How do you think that's going?
Andres: It's terrible.  People don't get added to Major Contributors and are driven away from the project.
Christoph: Right, I've been trying to get [redacted] put on the contributors list for years but have been told to take it up at pgcon.
Dave: The problem is that no one wants to take responsiblity for it.
Stephen: In the past Robert and I have done it at pgcon because core is there and they tell us to do it.
Dave: I can't promise but there is no reason you can't email core during the year.
Andres: You should write 'I am going to add this person in three days unless you object'.
Joe: I think you should have more than Stephen and Robert proposing.
Stephen: You don't think Robert and I disagree enough?
Dave: We need a policy on who can be proposed (including non-backend code contributors?)
Stephen: We need more people.
Magnus: I would suggest someone with more of an outside perspective.  I would suggest [redact].
Daniel: We also have the difference between the release note contributors and the website contributors.
Dave: Action item: add description 

Action points: Dave to write better descriptions of contributor classes.  Dave to follow up on adding more people the team that deals with recognition.

13:40:  RMT
===========

Alvaro: We should have one again.
Stephen: Should we define one before freeze.
Alvaro: The first RMT had a set of rules, but it was so annoying that it was decided not to have rules; each release's RMT decides how it is going to operate.
Andres: Last year there was a feature freeze + RMT announced in March.
Stephen: The last RMT should share information with the next one.
Andres: Should be more aggressive?

13:50:  PGCon
=============

Stephen: Feedback on who should be at the developer meeting in Ottawa?
Stephen: What is the basis for limiting the list?  Can we invite more?
Dave: Room size is a problem.
Dave: It's very good to have packagers in the meeting as we do today.
Stephen: Perhaps we should decide what we're going to talk about and then decide who should be invited.
Dave: Chicken and egg.
Stephen: Dave and I will take an action point to look at past agendas and make sure we're getting the right people.

Action points: Dave and Stephen to review past topics.

14:10:  Patch triage
====================

<discussion not recorded in minutes>

[1] https://www.postgresql.org/message-id/flat/201901311104.gwxzhzxu6ns6%40alvherre.pgsql