Thread: remove 'noversion' from standalone backend
This patch removes the remaining code for processing the '-C' command-line option in the standalone backend. It no longer actually functions (i.e. specifying the option does nothing), and I didn't think it was interesting enough to be worth reviving, so I removed it. Unless anyone objects, I intend to apply this in 24 hours or so. -Neil
Attachment
Neil Conway <neilc@samurai.com> writes: > Unless anyone objects, I intend to apply this in 24 hours or so. Patch applied. -Neil P.S. BTW, how does everyone feel about the methodology I've been using for submitting and applying patches? The procedure I'm following is: - for trivial / obviously correct patches, just apply them immediately - for fairly simple patches, submit them to the list and apply them fairly soon afterward (say, within 24 hours or 48 hours). When I apply the patch, send another mail to wrap up the issue. - for more complex stuff, the usual submission & review process until the patch is ready to be applied. If people don't want the additional mail when a patch is applied, I can stop sending those to reduce the quantity of mail on -patches. I'm also open to any other suggestions for procedural changes...
Neil Conway <neilc@samurai.com> writes: > The procedure I'm following is: > - for trivial / obviously correct patches, just apply them immediately Check. > - for fairly simple patches, submit them to the list and apply them > fairly soon afterward (say, within 24 hours or 48 hours). When I > apply the patch, send another mail to wrap up the issue. I think the pgsql-committers log message is sufficient indication that you did it, and the followup message on -patches is unnecessary. We usually acknowledge applying patches from non-committers, on the theory that they might not be subscribed to pgsql-committers. But for your situation I don't see the value in the extra message. regards, tom lane
Neil Conway wrote: > P.S. BTW, how does everyone feel about the methodology I've been > using for submitting and applying patches? The procedure I'm > following is: > > - for trivial / obviously correct patches, just apply them > immediately > > - for fairly simple patches, submit them to the list and apply them > fairly soon afterward (say, within 24 hours or 48 hours). When I > apply the patch, send another mail to wrap up the issue. I feel that you don't really need to "wrap up" the issue, because anyone who cares enough will read the commit list. > > - for more complex stuff, the usual submission & review process until > the patch is ready to be applied. > > If people don't want the additional mail when a patch is applied, I > can stop sending those to reduce the quantity of mail on -patches. > I'm also open to any other suggestions for procedural changes... It's up to you. Normally it's OK to float a proposal and then install a corresponding patch right away, but if you feel better when other people look over the actual patch, feel free to post it.
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > The procedure I'm following is: > > > - for trivial / obviously correct patches, just apply them immediately > > Check. > > > - for fairly simple patches, submit them to the list and apply them > > fairly soon afterward (say, within 24 hours or 48 hours). When I > > apply the patch, send another mail to wrap up the issue. > > I think the pgsql-committers log message is sufficient indication that > you did it, and the followup message on -patches is unnecessary. > We usually acknowledge applying patches from non-committers, on the > theory that they might not be subscribed to pgsql-committers. But > for your situation I don't see the value in the extra message. Agreed. I just emailed Neil privately to say I think he is using good judgement on when to apply and when to wait 24 hours. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073