On 4/8/24 8:29 AM, Andres Freund wrote:
Hi,On 2024-04-08 09:26:09 -0400, Robert Haas wrote:On Sun, Apr 7, 2024 at 6:50 PM Michael Paquier <mich...@paquier.xyz> wrote: 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 don't think it's very useful to paint a very broad brush here, unfortunately. Some will just polish commits until the last minute, until the the dot's on the i's really shine, others will continue picking up more CF entries until the freeze is reached, others will push half baked stuff. Of course there will be an increased commit rate, but it does looks like there was some stuff that looked somewhat rickety.
I agree with Andres here (though decline to comment on the rickety-ness of the patches). I think overcoming human nature to be more proactive at a deadline is at least a NP-hard problem. This won't change if we adjust deadlines. I think it's better to ensure we're enforcing best practices for commits, and maybe that's a separate review to have.
As mentioned in different contexts, we do have several safeguards for a release:
* We have a (fairly long) beta period; this allows us to remove patches prior to GA and get in further testing. * We have a RMT that (as Tom mentioned) can use its powers early and often to remove patches that are not up to our quality levels. * We can evaluate the quality of the commits coming in and coach folks on what to do better.
I understand that a revert is costly, particularly the longer a commit stays in, and I do 100% agree we should maintain the high commit bar we have and not rush things in just so "they're in for feature freeze and we'll clean them up for beta." That's where best practices come in.
I tend to judge the release by the outcome: once we go GA, how buggy is the release? Did something during the release cycle (e.g. a sloppy commit during feature freeze, lack of testing) lead to a bug that warranted an out-of-cycle release? And yes, how we commit things at feature freeze / through the beta impact that - we should ensure we're still committing things that we would have committed at a least hectic time, but understand that the deadline is still a strong motivator co complete the work.
Thanks, Jonathan
OpenPGP_signature.asc
Description: OpenPGP digital signature
