Re: Releasing in September
От | Gavin Flower |
---|---|
Тема | Re: Releasing in September |
Дата | |
Msg-id | 569FE862.3000201@archidevsys.co.nz обсуждение исходный текст |
Ответ на | Re: Releasing in September (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 21/01/16 06:40, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: >> That's pretty much what I suggested :) >> Except that we need to do it for the last one as well. With the only >> exception that the last one might be a bit longer. But the fact is that the >> recent of CFs *and* releases, we've taken the approach of closing the CF >> when everything in it is done or explicitly reviewed-and-bumped, and tried >> really really hard not to bump things because nobody had time to look at >> them. That's what I'm suggesting we change, and actually just cut them. >> Yes, one of the reasons for the CFs was to allow people a fair chance to >> get reviewed.But given that there isn't actually a deadline in practice >> doesn't help with that. > Yeah. It's certainly unfair if someone's patch doesn't get reviewed, > but there are only 24 hours in a day, and we have a limited pool of > reviewer and committer manpower. I think we just have to say that > sometimes life is unfair. > > I think it might also be a good idea if we could somehow distinguish > "nobody had time for that yet" from "nobody is interested", with an eye > to flat-out rejecting patches that no one cares enough about to review. > Maybe we could reduce the workload by inventing some kind of up-front > filter whereby a patch isn't even a candidate to get reviewed unless, say, > at least two people besides the author say "this sounds like it's worth > pursuing". > > One of the other things I do not like about the current CF process is that > it's created a default assumption that most submitted patches should get > accepted eventually. It is *very* hard to reject a patch altogether in > the CF process: you more or less have to show cause why it should not get > accepted. That default is backwards. Maybe this isn't the process' fault > exactly, but it sure seems like that's how we approach patches now. > > regards, tom lane > > Possibly the emphasis should be on what patches should be ACCEPTED, rather than on what patches should be REJECTED? Then there is less stigma in a patch missing out, and people don't have justify rejecting patches. Cheers, Gavin
В списке pgsql-hackers по дате отправления: