| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
| Subject: | Re: Releasing in September |
| Date: | 2016-01-20 17:03:49 |
| Message-ID: | 20160120170349.GB26711@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-01-20 11:53:32 -0500, Robert Haas wrote:
> But I'm not very sure that we're talking about the same set of people
> here. If we're going to go to a system where nobody's allowed to
> commit anything for the next release until the current release is
> finalized, then we'd better have some procedure for making sure that
> happens relatively quickly. And the procedure can't be that the
> people who are hot to get started on the next release have to bat
> cleanup for the people who don't have time to fix the bugs they
> introduced previously. Because *that* would be manifestly unfair.
Yes, that's a problem. But I don't see how we can avoid dealing with it
directly. Avoiding being stalled by unfixed bugs of others by having a
separate branch to continue working, inevitably leads to delayed
releases. If people don't fix the issues in time, there needs to be
direct pushback, leading to much less stuff getting in next time round.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-01-20 17:03:51 | Re: Releasing in September |
| Previous Message | Bruce Momjian | 2016-01-20 16:56:44 | Re: Releasing in September |