Re: Sync Rep for 2011CF1
От | Kevin Grittner |
---|---|
Тема | Re: Sync Rep for 2011CF1 |
Дата | |
Msg-id | 4D4FFD62020000250003A547@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: Sync Rep for 2011CF1 (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > Dave Page <dpage@pgadmin.org> wrote: >> Robert Haas <robertmhaas@gmail.com> wrote: >>> Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> Robert Haas <robertmhaas@gmail.com> writes: >>>>> ... Well, the current CommitFest ends in one week, ... >>>> >>>> Really? I thought the idea for the last CF of a development >>>> cycle was that it kept going till we'd dealt with everything. >>>> Arbitrarily rejecting stuff we haven't dealt with doesn't seem >>>> fair. >>> >>> Uh, we did that with 8.4 and it was a disaster. The CommitFest >>> lasted *five months*. We've been doing schedule-based >>> CommitFests ever since and it's worked much better. >> >> Rejecting stuff because we haven't gotten round to dealing with >> it in such a short period of time is a damn good way to limit the >> number of contributions we get. I don't believe we've agreed at >> any point that the last commitfest should be the same time length >> as the others > > News to me. > > http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan I believe that with tighter management of the process, it should be possible to reduce the average delay between someone writing a feature and that feature appearing in a production release by about two months without compromising quality. Getting hypothetical for a moment, delaying release of 50 features for two months to allow release of one feature ten months earlier is likely to frustrate a lot more people than having the train leave the station on time and putting that one feature into the next release. My impression was that Robert is trying to find a way to help get Simon's patch into this release without holding everything up for it. In my book, that's not a declaration of war; it's community spirit. -Kevin
В списке pgsql-hackers по дате отправления: