Re: commitfest.postgresql.org is no longer fit for purpose
От | Robert Haas |
---|---|
Тема | Re: commitfest.postgresql.org is no longer fit for purpose |
Дата | |
Msg-id | CA+TgmoZKgd27w9soHAy1TBfnWy2iAwk5uCz_4hV=NLe1+O31Wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: commitfest.postgresql.org is no longer fit for purpose (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: commitfest.postgresql.org is no longer fit for purpose
Re: commitfest.postgresql.org is no longer fit for purpose Re: commitfest.postgresql.org is no longer fit for purpose |
Список | pgsql-hackers |
On Fri, May 17, 2024 at 11:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > We already have gone back to that model. We just haven't admitted it > > yet. And we're never going to get out of it until we find a way to get > > the contents of the CommitFest application down to a more reasonable > > size and level of complexity. There's just no way everyone's up for > > that level of pain. I'm not sure not up for that level of pain. > > Yeah, we clearly need to get the patch list to a point of > manageability, but I don't agree that abandoning time-boxed CFs > will improve anything. I'm not sure. Suppose we plotted commits generally, or commits of non-committer patches, or reviews on-list, vs. time. Would we see any uptick in activity during CommitFests? Would it vary by committer? I don't know. I bet the difference wouldn't be as much as Tom Lane would like to see. Realistically, we can't manage how contributors spend their time all that much, and trying to do so is largely tilting at windmills. To me, the value of time-based CommitFests is as a vehicle to ensure freshness, or cleanup, or whatever word you want to do. If you just make a list of things that need attention and keep incrementally updating it, eventually for various reasons that list no longer reflects your current list of priorities. At some point, you have to throw it out and make a new list, or at least that's what always happens to me. We've fallen into a system where the default treatment of a patch is to be carried over to the next CommitFest and CfMs are expected to exert effort to keep patches from getting that default treatment when they shouldn't. But that does not scale. We need a system where things drop off the list unless somebody makes an effort to keep them on the list, and the easiest way to do that is to periodically make a *fresh* list that *doesn't* just clone some previous list. I realize that many people here are (rightly!) concerned with burdening patch authors with more steps that they have to follow. But the current system is serving new patch authors very poorly. If they get attention, it's much more likely to be because somebody saw their email and wrote back than it is to be because somebody went through the CommitFest and found their entry and was like "oh, I should review this". Honestly, if we get to a situation where a patch author is sad because they have to click a link every 2 months to say "yeah, I'm still here, please review my patch," we've already lost the game. That person isn't sad because we asked them to click a link. They're sad it's already been N * 2 months and nothing has happened. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления:
Следующее
От: Robert HaasДата:
Сообщение: Re: commitfest.postgresql.org is no longer fit for purpose