Thread: 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.
--
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.
> 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, Pennsylvania19026
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, Pennsylvania19026
Postgres Developers Tip 10001: >> > Tom, I just discovered that the web mail archive facility >> handles the >> > attachments quite well. If you go to the archive, it >> gives you a download >> > link for each attachment, and you just need to give the >> file a decent name. >> >> So it does. Good tip --- you ought to mention it on the >> hackers list. >> I was thinking I'd have to subscribe to patches directly rather than >> via digest, but this'll save the day.