Patches

I sent in a patch for createuser almost a week ago and I was wondering
what the procedure is. I haven't seen the patch applied but I also
haven't seen it rejected. I understand that not every one of my little
gems is going to make it in but I hope there is some sort of closure
method built into the process. In this case I think I have a useful
little addition to createuser but if I am alone, it isn't important
enough to diverge from the standard distribution. I just need to
know one way or the other.

In fact, this is the second time I sent in a similar patch for createuser
and I never heard anything about the first time either and that was before
6.4 was released.

I have it. When I am doing my own development, I don't apply patches
from the list. They stay in my mailbox, and get applied before beta
starts. If someone else applies it, I remove my copy.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thus spake Bruce Momjian

I sent in a patch for createuser almost a week ago and I was wondering

I have it. When I am doing my own development, I don't apply patches
from the list. They stay in my mailbox, and get applied before beta
starts. If someone else applies it, I remove my copy.

I see that Marc has gone ahead and committed it now. I guess the problem
is multiple queues. It would be better if there was one queue that the
committers could work on but I can't think of a good way to make that
work. Maybe some sort of PR system.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:

I see that Marc has gone ahead and committed it now. I guess the problem
is multiple queues. It would be better if there was one queue that the
committers could work on but I can't think of a good way to make that
work. Maybe some sort of PR system.

I don't think multiple queues per se are a problem; the deficiency I see
in our patching procedures is lack of visibility of the status of a
proposed patch. If it's not been applied, is it just because no one
has gotten to it yet, or was there an objection from someone? What's
worse is that one of the people with commit access might miss or forget
about such an objection, and commit a bogus patch anyway sometime later.
We have enough committers now that I think there's a definite risk here.

If we wanted to be really organized about this, it'd be cool to have
a central database with an item for each proposed patch and links to
followup discussions. But I'm not sure it's worth the work it would
take to set it up and then maintain the entries. Unless we get badly
bitten by a mistake that such a database would've prevented, it probably
won't happen ...

regards, tom lane

I don't think multiple queues per se are a problem; the deficiency I see
in our patching procedures is lack of visibility of the status of a
proposed patch. If it's not been applied, is it just because no one
has gotten to it yet, or was there an objection from someone? What's
worse is that one of the people with commit access might miss or forget
about such an objection, and commit a bogus patch anyway sometime later.
We have enough committers now that I think there's a definite risk here.

If we wanted to be really organized about this, it'd be cool to have
a central database with an item for each proposed patch and links to
followup discussions. But I'm not sure it's worth the work it would
take to set it up and then maintain the entries. Unless we get badly
bitten by a mistake that such a database would've prevented, it probably
won't happen ...

I keep them in my mailbox, delete them if there is objection or someone
else applies it. Eventually, I apply it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

So who's maintaining the website?
Drop me a line and let's have a chat about some improvements if you're
interested.
-DEJ

So who's maintaining the website?
Drop me a line and let's have a chat about some improvements if you're
interested.
-DEJ

We discuss the web site on the docs list, but if it's related to
patches, we can discuss in hackers. I am not the webmaster. You can
reach him at webmaster@postgresql.org.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026