Re: commitfest.postgresql.org is no longer fit for purpose
От | Tomas Vondra |
---|---|
Тема | Re: commitfest.postgresql.org is no longer fit for purpose |
Дата | |
Msg-id | 17f80bc0-81da-4e2b-8704-8a9aca4562d1@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: commitfest.postgresql.org is no longer fit for purpose (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: commitfest.postgresql.org is no longer fit for purpose
|
Список | pgsql-hackers |
On 5/20/24 16:16, Robert Haas wrote: > On Sun, May 19, 2024 at 3:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >... > >> * Another reason for things sitting a long time is that they're too >> big to review without an unreasonable amount of effort. We should >> encourage authors to break large patches into smaller stepwise >> refinements. It may seem like that will result in taking forever >> to reach the end goal, but dropping a huge patchset on the community >> isn't going to give speedy results either. > > Especially if it has a high rate of subtle defects, which is common. > I think breaking large patches into reasonably small parts is a very important thing. Not only is it really difficult (or perhaps even practically impossible) to review patches over a certain size, because you have to grok and review everything at once. But it's also not great from the cost/benefit POV - the improvement may be very beneficial, but if it's one huge lump of code that never gets committable as a whole, there's no benefit in practice. Which makes it less likely I'll even start looking at the patch very closely, because there's a risk it'd be just a waste of time in the end. So I think this is another important reason to advise people to split patches into smaller parts - not only it makes it easier to review, it makes it possible to review and commit the parts incrementally, getting at least some benefits early. >> * Before starting this thread, Robert did a lot of very valuable >> review of some individual patches. I think what prompted him to >> start the thread was the realization that he'd only made a small >> dent in the problem. Maybe we could divide and conquer: get a >> dozen-or-so senior contributors to split up the list of pending >> patches and then look at each one with an eye to what needs to >> happen to move it along (*not* to commit it right away, although >> in some cases maybe that's the thing to do). It'd be great if >> that could happen just before each commitfest, but that's probably >> not practical with the current patch volume. What I'm thinking >> for the moment is to try to make that happen once a year or so. > > I like this idea. > Me too. Do you think it'd happen throughout the whole year, or at some particular moment? We used to do a "triage" at the FOSDEM PGDay meeting, but that used to be more of an ad hoc thing to use the remaining time, with only a small subset of people. But that seems pretty late in the dev cycle, I guess we'd want it to happen early, perhaps during the first CF? FWIW this reminds me the "CAN reports" tracking the current "conditions, actions and needs" of a ticket. I do that for internal stuff, and I find that quite helpful (as long as it's kept up to date). >> Yeah, all this stuff ultimately gets done "for the good of the >> project", which isn't the most reliable motivation perhaps. >> I don't see a better one... > > This is the really hard part. > I think we have plenty of motivated people with good intentions. Some are motivated by personal interest, some by trying to achieve stuff related to their work/research/... I don't think the exact reasons matter too much, and it's often a combination. IMHO we should look at this from the other end - people are motivated to get a patch reviewed & committed, and if we introduce a process that's more likely to lead to that result, people will mostly adopt that. And if we could make that process more convenient by improving the CF app to support it, that'd be even better ... I'm mostly used to the mailing list idea, but with the volume it's a constant struggle to keep track of new patch versions that I wanted/promised to review, etc. The CF app helps with that a little bit, because I can "become a reviewer" but I still don't get notifications or anything like that :-( regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Greg Sabino MullaneДата:
Сообщение: Re: Logging which local address was connected to in log_line_prefix
Следующее
От: Jacob ChampionДата:
Сообщение: Re: pg_parse_json() should not leak token copies on failure