On Mon, 8 Apr 2024 at 18:42, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 08/04/2024 16:43, Tom Lane wrote: > > Robert Haas <robertmh...@gmail.com> writes: > >> And maybe we need to think of a way to further mitigate this crush of > >> last minute commits. e.g. In the last week, you can't have more > >> feature commits, or more lines of insertions in your commits, than you > >> did in the prior 3 weeks combined. I don't know. I think this mad rush > >> of last-minute commits is bad for the project. > > > > I was just about to pen an angry screed along the same lines. > > The commit flux over the past couple days, and even the last > > twelve hours, was flat-out ridiculous. These patches weren't > > ready a week ago, and I doubt they were ready now. > > > > The RMT should feel free to exercise their right to require > > revert "early and often", or we are going to be shipping a > > very buggy release. > > > Can you elaborate, which patches you think were not ready? Let's make > sure to capture any concrete concerns in the Open Items list. > > I agree the last-minute crunch felt more intense than in previous years. > I'm guilty myself; I crunched the "direct SSL" patches in. My rationale > for that one: It's been in a pretty settled state for a long time. There > hasn't been any particular concerns about the design or the > implementation. I haven't commit tit sooner because I was not > comfortable with the lack of tests, especially the libpq parts. So I > made a last minute dash to write the tests so that I'm comfortable with > it, and I restructured the commits so that the tests and refactorings > come first. The resulting code changes look the same they have for a > long time, and I didn't uncover any significant new issues while doing > that. I would not have felt comfortable committing it otherwise. > > Yeah, I should have done that sooner, but realistically, there's nothing > like a looming deadline as a motivator. One idea to avoid the mad rush > in the future would be to make the feature freeze deadline more > progressive. For example: > > April 1: If you are still working on a feature that you still want to > commit, you must explicitly flag it in the commitfest as "I plan to > commit this very soon". > > April 4: You must give a short status update about anything that you > haven't committed yet, with an explanation of how you plan to proceed > with it. > > April 5-8: Mandatory daily status updates, explicit approval by the > commitfest manager needed each day to continue working on it. > > April 8: Hard feature freeze deadline > > This would also give everyone more visibility, so that we're not all > surprised by the last minute flood of commits. > IMO the fact that people struggle to work on patches, and make them better, etc. is an immense blessing for the Postgres community. Is the peak of commits really a big problem provided we have 6 months before actual release? I doubt March patches tend to be worse than the November ones. People are different, so are the ways they feel motivation and inspiration. This could be easily broken with bureaucratic decisions some of them, like proposed counting of lines of code vs period of time look even little bit repressive. Let's remain an open community, support inspiration in each other, and don't build an over-regulated corporation. I feel that Postgres will win if people feel less limited by formal rules. Personally, I believe RMT has enough experience and authority to stabilize and interact with authors if questions arise. Regards, Pavel Borisov
