| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Naz Gassiep" <naz(at)mira(dot)net> |
| Cc: | "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Marc Munro" <marc(at)bloodnok(dot)com>, <heikki(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <dpage(at)postgresql(dot)org>, <simon(at)2ndquadrant(dot)com>, <bruce(at)momjian(dot)us> |
| Subject: | Re: Feature freeze progress report |
| Date: | 2007-05-01 01:54:28 |
| Message-ID: | 87d51lqpez.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Naz Gassiep" <naz(at)mira(dot)net> writes:
> Even if the patch inventory wasn't kept right up to date, this system
> could potentially help many regression issues or bugs to surface sooner,
I just don't understand what this would accomplish. People run regressions
before submitting anyways. They can't run them on all architectures but bugs
that only affect some architectures are uncommon.
This seems to be merely institutionalizing having a large backlog of patches
which survive for long periods of time. But even in that situation I don't see
what it buys us. Detecting bitrot isn't terribly helpful and it doesn't help
us actually deal with the bitrot once it's happened.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2007-05-01 07:56:15 | Re: Feature freeze progress report |
| Previous Message | Naz Gassiep | 2007-05-01 01:33:40 | Re: Feature freeze progress report |