Re: Feature freeze progress report

From: Marc Munro <marc(at)bloodnok(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Naz Gassiep <naz(at)mira(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, 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 15:22:50
Message-ID: 1178032970.10125.29.camel@bloodnok.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 2007-01-05 at 02:54 +0100, Gregory Stark wrote:
> "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.

The intention is to help keep patches, which may remain in the queue for
extended lengths of time, reasonably current. The mechanism aims to
help with these specific problems:

- patches accumulates bitrot and are consequently harder to apply and
understand
- the author, by the time review occurs, no longer has the details of
the patch uppermost in their mind

If the author can be automatically prodded when the patch no longer
cleanly applies, or when it suddenly breaks regression tests, they will
be able to keep the patch current, may discover bugs in it themselves
prior to review, and it will remain more fresh in their minds.

For sure, there will be classes of patch for which this mechanism
provides no benefit. For instance, where a patch contains code that is
for discussion only, or a patch that is dependant on another patch. In
these cases, the mechanism would simply note that they don't apply
cleanly, or don't pass tests, and would do nothing further. I can see
no harm here.

> 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.

I hope that it would not encourage reviewers to leave things in the
patch queue. I don't see why it would, so don't think this would
institutionalize a backlog.

I also disagree that detecting bitrot is not helpful. If I had eagerly
submitted a patch, I would definitely want to fix any bitrot that
occurred and would be thankful to be automatically informed.

And to clarify, I do not think the buildfarm should be involved in this
process.

__
Marc

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2007-05-01 15:26:03 Re: Feature freeze progress report
Previous Message Andrew Dunstan 2007-05-01 14:57:22 Re: Feature freeze progress report