Re: Last gasp
От | Tom Lane |
---|---|
Тема | Re: Last gasp |
Дата | |
Msg-id | 10796.1334075758@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Last gasp ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Last gasp
|
Список | pgsql-hackers |
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > One other sort of mechanical test which I think can and should be > applied to patches submitted to the last CF is that if *at the start > of the CF* the patch doesn't apply, compile, pass regression tests, > and demonstrably provide the functionality claimed for the patch, it > should not be a candidate for inclusion in the release. I would not be in favor of inflexible application of such a rule. For instance, if a patch had gotten broken by a conflict with some other patch applied the day before the CF starts, it would be unfair to not give the patch author a reasonable amount of time to rebase. And such conflicts occurring after the CF starts are hardly unusual either. > A patch on > which the author is continuing to work even in the absence of review > should be considered a WIP "want feedback" submission; it should not > be allowed to constitute a "placeholder" for inclusion in the > release. It's one thing if review turns up corner case bugs missed > by the author; it's quite another if there is a month or two of > solid development left to be done. The CF period is not the time for > "now I'll get serious about wrapping this up." Agreed here, though. Chris Browne mentioned upthread that we really need a somewhat different process for WIP patches as opposed to those that are thought to be committable or nearly so. I don't know if we should institute his idea of a separate series of "HackFest" events, but at the very least we should try harder to draw a distinction between WIP and finished patches. They need different sorts of reviewing. regards, tom lane
В списке pgsql-hackers по дате отправления: