PgCon 2018 Developer Meeting
A meeting of the interested PostgreSQL developers is being planned for Tuesday 29 May, 2018 at the University of Ottawa, prior to pgCon 2018. 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 11/10 release cycles. We have not invited any contributors based on their contributions to related projects, or seniority in regional user groups or sponsoring companies.
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 12.0 release cycle
- Address any proposed timing, policy, or procedure issues
- Address any proposed Wicked problems
Time & Location
The meeting will be:
- 9:00AM to 12PM
- DMS 3105
- University of Ottawa.
Coffee, tea and snacks will be served starting at 8:45am. Lunch will be 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!
- Ashutosh Bapat
- Joe Conway
- Jeff Davis
- Andrew Dunstan
- Peter Eisentraut
- Andres Freund
- Stephen Frost
- Etsuro Fujita
- Robert Haas
- Magnus Hagander
- Kyotaro Horiguchi
- Tatsuo Ishii
- Amit Kapila
- Jonathan Katz
- Tom Lane
- Amit Langote
- Heikki Linnakangas
- Noah Misch
- Bruce Momjian
- Thomas Munro
- Dave Page
- Michael Paquier
- Masahiko Sawada
- Teodor Sigaev
- David Steele
- Tomas Vondra
- Gregory Stark
- Takayuki Tsunakawa
Apologies
- Simon Riggs
Agenda Items
- 12.0 release and commitfest schedule (Dave)
- Heavier filtering for patches in last CF (Andres Freund)
- How can CFs/development process put more focus on long pending patches (Andres Freund, Jonathan Katz)
- Please add suggestions for agenda items here. (with your name)
Agenda
| Time | Item | Presenter |
|---|---|---|
| 09:00 - 09:30 | Welcome and introductions | Dave Page |
| 09:30 - 09:45 | 12.0 release and commitfest schedule | Dave Page |
| 09:45 - 10:10 | Heavier filtering for patches in last CF | Andres Freund |
| 10:10- 10:30 | Keeping track of features / context of features | Jonathan Katz |
| 10:30 - 11:00 | Coffee break | All |
| 11:00 - 11:30 | How can CFs/development process put more focus on long pending patches | Andres Freund |
| 11:30 - 11:50 | GDPR and how it affects us | Magnus Hagander |
| 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.
Photo
Minutes
Dave P. kicks off the developer meeting. Team is trying to decide the "version number" for which # meeting this is.
Everyone present gives introductions. Occurs in a record four minutes.
- 12.0 Release Schedule
Dave P. starts discussing the schedule. Dave proposes that we release around September, 2019.
No one makes a motion to change (Except Stephen, who proposes September, 2018).
Dave P. asks about commitfest schedule.
Robert proposes that everyone tries to jam everything into the last commitfest. The reason they do that because they know when the last commitfest would be. Robert proposes that we generate a random number: if it is odd, we release. If it is even, we do not. [Laughter]. Would like to solve the problem of people not cramming into the last minute.
Tom: We have a full slot for this topic, maybe we should switch the order.
Dave: It's the next one.
[Laughter]
Andres: Was there anything really bad schedule wise?
Tom: A lot of "gross" stuff committed in the last few days of the final commitfest.
Robert: For a year or two, we used to freeze earlier (Jan/Feb). Was then moved to March, the later freeze has been offset by "fear" of the release management team coming to get you. It has worked well doing it in March.
Peter E: When we froze earlier, there was a distraction of people working on the release.
Jonathan: Is there a way to change the behavior to encourage people to propose patches / commit earlier?
Heikki: Fundamental problem of "discipline"
Noah: Robert's idea not unfounded.
Magnus: Would help developers with variable releases, users would not.
Greg S: In the last month, there is a variable of the commit.
Andres: The problem is much more we had a lot of patches in the commitfest that were updated in the middle of the commitfest. Just need to be more "cruel" about patches.
Robert: Who has time for cruelty? There are so many patches on the mailing list.
Andres: There were some patches that we did not thoroughly look at and some people were also unaware of the rules of the commitfest.
Noah: Even if we address the patches that weren't close to ready, would it address it?
Andres: I think it would help.
Dave: Who is actually going to do this? Who is going to be "cruel?"
Andres: Yes, if more people help with that it would be less "Andres is in a bad mood." Need to be more obvious around the rules.
Robert: Yes, need to write down the expectations so everyone can see what they are. Does not mean everyone will automatically meet the expectations. Gives an analogy to parenting.
Stephen: We're going to end up using vocabulary in there that is subjective, but better than nothing at all.
Andres: I posted a proposal that needs a bit of polish.
Amit: RMT should prioritize what could make it and what won't
Stephen: RMT has been post - could possibly move it up.
Greg S: Had a rule that patches in the final commitfest should be "close-to-ready." Only patches that the reviewers said that "this is close to ready" then it is approved for the final commitfest.
Andres: Not sure if that technically process is the problem. The author said "I don't care, I want it to be there anyway"
Peter E: If we are going to be more restrictive on these things and you can't submit stuff in the last commitfest, then we're really shrinking the window of when we should actually be doing stuff. It impacts the work we can do, then for new contributors "Oh you weren't here in November you can't contribute." I don't mind if someone submits a reasonably sized patch in March and it is good, we can work on it together.
Tom: Agreed, but size of the patch has a lot to do with it.
Peter E: Judgment calls: this patch is too big, too late, etc. It is human work, but we need to be inclusive.
Robert: We went back to this system; then there is not as much opportunity to do as much patch review. You commit stuff and you get to the end of the release cycle, and guess what there are bugs, and you have to fix it. Last year, I was working flat out for months committing partitioning bugs. Still had to review patches. I see the value of this, I see it's quite painful. The more you restrict the window, the more things will be at the window.
Andres: You want more time for development, but it creates too much work?
Heikki: In the period where we are working the release [Jonathan checked an email about PostgreSQL 8.2 windows installer...]; perhaps should squeeze the window.
Tom: Does not seem like we are very productive in the summer.
Andres: Should we move the release?
Tom: September is a great month of release. Can we do something more productive with the summer?
Andres: If we are waiting to release in Sept because we are unproductive in the summer, do we get any gain?
Stephen: Then do we move the last commitfest to the summer?
Robert: Last committfest is when Magnus is on his boat.
Noah: If we get little done in August, we should move the last commitfest to August.
Jeff: Should we do a semi-major release with some changes out?
Peter E: Cannot do a whole lot without catalog changes.
Andres: Depends on the area you work in.
Stephen: Don't want to go back to having 3 digits in release number.
Jonathan: Let's not muck up release process. User standpoint rant in terms of how people plan their upgrades.
Tom: Work harder documenting expectations. Changing topics: Start a new branch for the commitfest in July.
Stephen: What's the difference releasing the prior branch in September vs. whenever we branch?
Tom: Yeah once we branch is there any more testing getting done?
Robert: Well perhaps we try to release sooner; years ago we tried to release in June. But then people said you couldn't release in July & August. The RMT process is good at preventing what used to take a long time, i.e. open items that stay open forever. Someone can make you revert your patch. Perhaps we just decide "Hey, dot-O is coming out on June 15."
Peter E: The open item list quite short right now - we probably could release in a month. We need people to test their application and we need the period for it.
Tom: The reason it's so short because nobody has tested it yet.
Robert: Not going to get much testing between June - August.
Andres + Noah: Steady stream of bugs that come in until RC 1.
Stephen: Which group is it coming from? Us or users? If it's coming from outside, we could be spending more time on new development.
Noah: From the hip, 2/3s outside 1/3 inside.
Peter E: I did notice last year that more than half of the names in contributors list came after the beta tag.
Robert: At the same time, the # of bug reports by the time we get to beta 3 and RC 1, we don't get a lot of reports. Get a surge after dot-O. Can extend contract period between beta 1 + release and there are diminishing returns. That's why it's called a final release: all bugs are done [Jonathan laughed].
Andres: Propose that RMT has the best insight into state of release
Peter E: RMT already has the power to branch whenver they feel like and release whenever they feel like. That's possible in terms of branching - we tried that a couple of years ago and had an early review fest in June/July. Perhaps we try it again.
Stephen: I like the general idea of having a branch open earlier because from that newcomer perspective, it's nice to have a new time of year where people commit a patch.
Robert: It lets committers clear some smaller things off of your plate, you have more time to give bigger things adequate attention.
Tom: Stuff like that where we have a six-month window right now.
Peter E: We talk a lot about the last commitfest, but the first commitfest is huge.
Robert: I think we should stick to the same schedule as last year, but we will agree that we are going to document the expectations for the last commitfest better and we agree that the RMT can declare when they would like a new branch created even if we are not shipped yet.
Stephen: The RMT is caring about the release, as long as they are paying attention to open items, and it is already in the mandate to open the branch early, then the commiters can pick out smaller things from the later commitfest. We can go and pick stuff out of there and commit it into the branch once it's created, and that would give us the opportunity to have that first commitfest not be massive.
Tom: Would help a little bit on the easy stuff.
Andrew: Doesn't really matter if it's small or not?
Robert: Not really, but you may not have that time if you're working on stabilization.
[Andres phone goes off]
Peter E: Are we ready to branch 5 weeks from now?
Jonathan: Asks about the branch
Robert: Thing it depends how much we need to back patch. If branch too early, there is a lot of back-patching. Back-patching takes time and work, but if you're only going back one branch, it's not that bad. If Andres rewrites the executor for the 3rd time in 3 releases, it's a lot of work to fix bugs, but Andres will have to fix it anyway, so it load-balances out.
Stephen: Maybe while we should discourage people from committing stuff from the last commit fest that's big, we should also say "hey we are going to branch, but be gentle."
Tom: We could make an explicit suggestion that the point of opening the branch earlier is that by definition we are going to focus on little stuff.
Noah: I think more like Robert, it's rare that back-patching two month old code is a problem.
Peter E: If we are waiting for the RMT, could make it difficult to plan.
Andrew: Perhaps we say after X period, we will do feature freeze. So there is an assumption in most cases we will branch relatively early.
Tom: So more like RMT has veto over the feature freeze or postpone.
Stephen: So to Peter's point, if RMT has veto power, it makes it easier to plan.
Noah: If they can hold to a release date, they can hold to a branch date.
Peter E: We can still have a commitfest and get the process rolling.
Andres: We had a couple of patches where several seasoned community members said "Hey I don't want this to go in" but it went in anyway. We should be more accepting of each others’ veto - it turns out that most of the concern is reasonable. Maybe not all of it. But if two committers vetoed and it went in anyway, I found it concerning.
Stephen: I found it concerning also. One thing I will mention is that it depends on how you read into things; It wasn't clear to me that people were really asking for people to hold off and perhaps being more explicit about that. I wasn't involved in this particular discussion actively, but it seemed like concerns we raised, some people thought they were addressed and they weren't, and it was unclear.
Magnus: Add in commitfest app to have a person "hey i have interested in this patch"
Andres: I would use that, try it, but does not address the issue if you don't decide to care, then you don't care.
Bruce: I feel like if you do that, and bad things happen like in this case...
Tom: There were several things that went in despite Andres & I objections.
Bruce: I assumed a committer could block anything...
Tom: If you have commit bit, you can put it in.
Andres: Sometimes that is good.
Jonathan: Just need process for "breaking ties" with commits.
Stephen: +1/-1
Robert: Works well on design of features, not good for dumbness of code. Uses an example about an ASCII banner of "Stephen Frost" in core code. When you put something big into core, you are responsible for it, but you're also not responsible for it. Committers basically become collectively responsible for that things when it breaks. I know that is one of my biggest concerns about things going in and they are not fully baked. If I know that the person committing it will be 100% responsible for fixing everything that breaks, I'm ok with it. If I know the effort is going to fall onto other people, such as me, I for some reason get agitated about it.
Andres: If there are conflicts between committers, it is easier to override concerns in CF1 or CF2 vs. CF-LAST, it's easier to resolve earlier in the cycle than at the end.
Peter E: What is the resolution in terms of the schedule?
[Group is murmuring July].
Robert: I am moving to Europe so I can get the entire summer off.
Jonathan: Brings up the testing around Beta 1, only concerns around branching are based on user feedback from bugs. Also said willing to share notes from RMT meetings.
[Discussions around committing]
Andres: If we put in the document "In the last commitfest, we ask for committers to listen to objections more judiciously" then it's better than not.
Dave P: It sort of implies you don't have to listen to earlier commitfests.
Andrew: Don't know if writing a rule like that will have much effect.
Andres: Some of the expectations that some of the people who have been working with the project for awhile they are unaware of some of the rules. Not everyone has the history of the memory behind how some decisions were made.
Stephen: This discussion is a great example of not everyone is here, or not everyone is going to read through all the notes; having some kind of documentation is necessary. What that ends up being is a good question, but yes, things that going into the last CF that are large items have been seen before. Committers are expected to be looking for positive responses for other committers before pushing together a patch. If it's a big thing in the last commitfest, should try to get another committer involved.
[Discussion of how to commit and getting people to agree/disagree]
Bruce: If can't get everyone to agree, does the person still need to be a committer?
Andres: So if I disagree with something, I lose my commit bit?
Tom: Not going to get a 19-1 vote because not everyone is going to vote. More like 1-1 or 2-1.
Greg S: Not clear if that one person really reviewed it and noticed they should bring up, vs. the other two people did a thorough review.
Robert: Not sure if this is hard to resolve. If someone said "You forgot a semi-colon" that's a minor concern. If someone makes a thorough comment, that's pretty clear. If you're thinking about committing something, you better have read the thread on the patch you're committing. If you haven't, then we should reconsider commit bits.
Greg S: The usual dilemma is the patch that adds a feature that we want vs the compromises they might have made that limited future development. It's entirely possible for a committer to disagree with the priorities that the future development is more important than the current compromises for the feature. It doesn't mean that the committer who is willing to block the patch isn't willing to live with the feature. It's more priorities & dilemmas vs. binary decision.
Dave P: If the committer makes it clear, people are usually okay to live with that.
We are more-or-less back on schedule. We just need to commitfest schedule will be, and I think we need someone to take up the todo to take up guidelines.
Andres: I have a draft, Tom had some valid criticism, and I will re-read it at the backend of the discussion.
- ACTION ITEMS**:
- Andres will edit the document with commitfest guidelines - Extra commitfest in July unless RMT vetoes (2018-07) - Commitfests will be 2018-07, 2018-09, 2018-11, 2019-01, 2019-03
Jon- this came up from a note on the release thread. The idea is that we go through commit messages and building the list of features etc. With my advocacy hat on, it limits the messaging we can do along the way. Can we keep track of this as we go? Payoff is that at release time we just need to review.
Tom- We did an experiment about 10 years ago with building the release notes on the fly. It became obvious that multiple people had worked on it in different styles.
Jon- We don't necessarily need to write the actual release notes. This could be a wiki page or a feature on the commitfest app.
Peter- Are you talking about high level features or everything?
Andres- I could certainly use the notes as my brain isn't big enough to hold a full release at once.
Robert- If someone wrote the notes monthly, then nothing interesting would change until March 1st.
Bruce- If the way the features were added was discreet, it would work. As I recall previously we had to keep rewording things as things kept changing and we had to revise the way they were presented to the user. Sometimes a small feature at the beginning of the cycle would be subsumed into a much bigger feature.
Jon- You don't write the executive summary until you've written the rest. However, I think that last release we missed multi-column statistics which was a big feature which people didn't see and we should have shouted about.
Greg- Doing it incrementally can make things worse - people will think more of their own features.
Heikki- I've found blog posts people write very useful
[various folks agree]
Bruce- It's very helpful as they can include examples etc.
Andres- It helps people understand if they need to upgrade etc.
[much discussion about prioritization and importance of different features]
Peter- At the time we don't know. My favorite is in 9.4 where replication slots were buried at the end of the docs.
Greg- At both Heroku and Gitlab I found people got really excited about new features, but not from the release notes.
Michael- Blogs posts are very helpful - they get us much more feedback and reports than we get from people reading the release notes.
Jon- This is really about collating the list and getting the context around features so that we can keep track easily.
Stephen- Are we saying we want committers to blog about every feature they commit?
Robert- No blog post and you lose your commit bit!
Peter- It's a good idea anyway to promote yourself and your company and get feedback etc.
Noah- It doesn't sound like we have a process failure here.
Magnus- It was just a bad call.
Jon- So is there a way we can improve the context of what we're committing as we're going on?
Bruce- The reason these things get overlooked is that some things are of strategic importance to PostgreSQL, but sometimes people aren't looking at things from that perspective so they get missed. Maybe the issue is that you (Jon) and I are looking at this more strategically than others.
Robert- I got a major feature credit for a C API!!!1
Magnus- We always get the marketing one version before the feature gets really good.
Bruce- At least for 11 we have the top items, and we keep fleshing these things out over time.
Peter- For 11 the major items fit on a page which I think is a good balance.
Noah- Sounds like we're doing pretty well right now, but it doesn't seem like we have a proposal
Magnus- Except that Tom is going to start a blog!!!
Jon- Let's just keep this in mind, and help keep the context.
Tom- I was going to suggest it would be nice to have a cumulative list.
Jon- Maybe we should organize the wiki.
Peter- Part of the problem is that a lot of the wiki is out of date, whilst a lot isn't.
Thomas- The todo list should be called the don't do list.
Andres- We can use templates on the wiki to mark info out of date.
Stephen- For official info we should fold it into the main website.
Peter- I suggest people are just more aggressive when editing the wiki. It's all version controlled after all.
Stephen- We have an action item from that to fold official info into the website.
- Jon to work on that **
Peter- Advises caution to avoid making it harder to update things.
Jon- We'll move all the locked pages.
-- BREAK --
Dave P: How can commitfest and development process put more emphasis on long pending patches.
Andres: Comes up from patches that came up in the 2013 release cycle, there are a number of patches that have been in the release cycle for 3+ years and that is a) bad for PostgreSQL b) bad for contributors because for the authors it's really frustrating to go over the same thing for 4 years. c) Reviewers because it's frustrating to say "Hey this is not ready again."
One crazy-ish idea I had: we just say "Hey, the last commitfest closes two weeks earlier for anything younger than six months, and anything that are patches that needs review longer than 6 months without back and forth (Except for rebasing) can be committed in the last two weeks of the commitfest." Basically some procedural push for patches.
Peter E: Is your assertion that patches are mostly there, or is it that they are troublesome in general?
Andres: I think both, but mostly they just need some TLC. Change this architectural detail here, change this architectural detail there. Within a week or so of effort they can be committable.
So for example, incremental sort. Everyone says we want. It has been submitted since 2013 in one year increments.
Robert: The one year increments thing is part of the problem.
Andres: Other patches too: multivariate statistics was waiting for review for considerable amounts of time. Letting patches rot that long is not a good thing.
Robert: Unless the patch is really good can get through quickly. If a patch is a couple of 1000 lines, it takes a lot of time.
Amit: Some of the area the senior members or committers the areas of specialty can be divided and at the end of the day, people need to find time in the release cycle / commitfest, they will do that.
Peter E: Sure, but you can't tell people what to do.
Andres: People will say "Oh this looks ready I'll look at it at the end of the commitfest cycle." But it may take longer than that to properly review and feedfback.
Peter E: But then you will just have people commit things two weeks earlier. I feel that at the end, there is a fear of "loss of version" and people are "I wish I could work more on this" but that's not really a technical issue.
Noah: I do think it's reasonable to designate time to reviewing each patch - that's why CF process originated. I wonder is if the last commitfest is the right time for that?
Andres: The reason I bring that up is because there is the hammer that you can't commit after that.
Tom: I think a lot of these patches is part of the problem that Robert is alluding to which means they take a fair amount of work and probably not good material for getting them in. Would switch that around: do this earlier.
Andres: July ones
Robert: What would help is if someone could curate a list of these patches and just send them out. Here are the patches that have been going for more than X commitfests, in a softer way encourage people to work at those.
Tom: Can we fix the web app to do that?
Robert: The older the commit fest patch, the bigger the font size gets.
Jonathan: At what scale?
Robert: 4 pts (so linear).
Peter E: But still doesn't say if it's something that isn't ready or something that will never get in.
Andres: It's more the "Hasn't gotten any review, move to next."
Peter E: There probably are certain patches that only require a week of work, but don't know which ones are. It is ultimately the responsibility of the people submitting the work to get it reviewed.
Andres: But it can be hard due to corporate pressures. If we can get the world to contribute in this way to PostgreSQL i.e. on the reviewing side. People will get interest, but they will get interest 2 days before the freeze.
Stephen: Intent of the CFs was to get committers to look at other peoples’ patches. We were supposed to be hacking on our own stuff in the off months, and then committing stuff from other people during the CFs. This has now changed to committers push their patches through the commitfest, and we push our own patches during the CF them. Led to the situation where committers are worrying about our own patches vs. other peoples'.
David S: If we get more people shepherding patches throughout the year will help ameliorate the problem. Author participation is key.
Tom: Assuming Robert's idea of the font size bigger for lagging reviews...
Robert: There are only so many committers. If you are a non-committer who wants to get your patch committed, the number is not like 20, it's like 4-6. In 2016, there were 2 committers that committed the patches that were not self-commits of own work. In 2017, it was 4 committers (...). That means there is this ever increasing number of patches out there that are being funneled through a small number of people. Tom has gotten 12,000 LOC of code committed to PostgreSQL in 2017. That is a phenomenal achievement, that basically means people review code that does not have a lot of work to be done.
This means we will need to give more people commit bits. They will not be as good at it as people who have been doing it longer. Everyone continues to learn things. One of the problems is when we give new people commit bits, we don't necessarily solve the whole problem, but for some people, even if all they do is commit their own stuff, it does spare a lot of people work that is required for junior work.
We only lose if we give someone commit bit, and it generates more work for other people. The number of people who are able to review complex patches across the code base is very limited. When you have people who are consistently contributing 5,10,15K LOC each year, perhaps at some point we are being too picky. It's not like Tom's or my patches are bug free, but we know how to cover it up.
Peter E: I do want to add to it as this is a scaling problem: if you look at CF entries it's 275 entries. If you have to do the math, you have to dispose of 6-8 patches per day it is unrealistic to get through at current capacity.
Robert: +1 on math. Cannot have 200 patches in 30 days and 6 people and get through them all.
Tomas: Not sure if committing stuff is the main problem. I have been the author of the statistics patch - been falling through a year without review. Even if I got the commit bit today, I would not push it because it did not get a review. Review is what pushes it forward. It did get reviews in last two weeks of the CF, but still not enough to get it through. Even if the community gives commit bits to more people, it does not solve the problem of the patches not getting reviewed.
Andres: I think it does a bit, because when you become a committer, there is a feeling of "Hey, I need to commit stuff."
Greg S: Looking at Joe C's graph here, moving to next CF is becoming more and more.
[Joe C shows graph on small screen for "everyone" to see. Murmurs ensue around the room].
Heikki: Pattern is if gets pushed and it gets pushed again, it gets harder for it to get in.
Tomas: I think this is one of the problems with the statistics patch. Would be useful in the commitfest obligation to once-in-a-while send a summary email of the current status of the patch, here is what the patch is supposed to be in the current version.
Magnus: This sounds like the annotation feature that Peter G.
Thomas M: Should be able to read the commitfest message and understand what the patch does.
Robert: YES PLEASE!!!1
Stephen: While I agree it's good to have it in the commit message, when I go to the CF app, I'm going to read threads first. But maybe I should read commit message first?
Greg S: We have a lot of reviewers that are only technically capable enough to do cursory, basic review. Perhaps something we can ask people who want to contribute but they can't do a really in-depth technical review, but they could summarize what we can do.
Andres/Stephen: -1.
Tomas: I think summary emails should be written by the patch author.
Heikki: Depends if I can trust the author or not on it.
Andres: Still better than before. Give current state, past objections, future work, etc.
Heikki: Would be helpful in the threads to ask the author to do so. Still need to go through and check, but it's better.
Peter E: Could still easily assess the summary.
Noah: Heikki asking early in how to motivate people to spend time on this. Good to get a response.
Andres: There is also a lot of patches that are quite useful but are not as attractive to people to review/commit.
Noah: I think that does happen, but it's hard to detect what's happening. If every committer took the time to try to review, we can try our best to get it in.
[Discussion on how to review something like the statistics patch without a math background]
Tomas: Reviewing is important because it is a chance to learn, even if you are not familiar with the math. If a patch is written and it does not get a review, is it actually a patch?
Robert: It also plays into some patches everyone likes, but it is not everyone's priority.
Jonathan: Do need to get more people involved. Need new committers, but need to train them on how to do it well. Also need to trust the work of people when writing summaries.
Tom: Just having more committers doesn't solve the problem.
Robert: We don't have the ability to get people to spend time on the project, but we do have the opportunity to decide how much people contribute to the project. We may say "No, we are not going to open the funnel any wider" or we can say "We are comfortable cracking it open a little bit more, and we take the next 2, 3, 4 people who are almost ready and say 'Hey they're ready." If we don't change anything, it won't get any better.
Our development velocity is limited by how many hours people to commit.
Tom: Is there any way to motivate the existing committer time to spend more time on this?
Andres: This is why we brought up corporate pressures. If we don't have any community back pressure "Hey can't do that right now" good will, blah blah.
Heikki: Could ask committers individually to see what they would contribute more.
- ACTION ITEMS**:
- Raise font sizes based on push lag (or sortable column) - Patch authors send summaries regularly. CF managers send summaries to help rally the team - Look into getting more committers and getting them to review smaller patches until trained up to review large patches - Also help authors / committers facilitate reviewing other patches
Dave P: GDPR is an EU directive that has to be implemented by EU members by May 25. It is a new set of privacy regulations and rules with extremely stiff penalties if you break them. It includes things like the right to be forgotten, seriously strong protections against what is classified as personally identifiable information including IP addresses. Anyone who is in the EU or does business in the EU has to comply. This includes the project.
[Discussion on GDPR].
