Обсуждение: Commitfest status
The first commitfest has been on for about a week now, but I haven't seem much festivities going on. Do we plan to drain Bruce's patch queue completely during this commitfest? Or the items on the developer wiki TODO:PatchStatus list? When do we declare the commitfest to be over? Bruce's queue has many patches in there that haven't had any activity, and not all of the items are patches. The wiki is not quite up-to-date either. Looking at the items in the wiki, here's my quick triage of the items that have no reviewer assigned: Dead space map - We want something that doesn't require a shared mem block. It should also be crash-safe. I gave this, and the FSM a lot of thought last Autumn, and I plan to work on this for 8.4, but the patch as submitted is not acceptable. On disk Bitmap Index - Needs work, abandoned by Gavin. No amount of review will change that. POSIX shared memory support - Doesn't seem like it's worth it, frankly. I won't object if someone wants to put this in, but I'm not interested to spend time on it myself. stream bitmaps (API change for Group Index Tuples) - By me. I'm not planning to work on this currently, as there's not much need for this without bitmap indexes and grouped index tuples. bitmap scan changes - same here Grouped Index Tuples/Cluster Indexes - I'm not currently planning to work on this further. Group commit - just discussion, no patch Maintaining cluster order on insert - AFAICT, rejected by Tom, because the gain demonstrated by his test case was not worth adding so much code. I don't think that was a good test case, as clustering in general won't help much when the table fits in memory. There should be a bigger gain on other workloads, but I'm not planning to work on this for now. support for dumping only functions in pg_dump - An interesting patch, needs some cleanup though. Would be nice to have support for other objects than functions as well. current_query - I don't understand why this is needed. What's the use case? make --enable-integer-datetime the default - This needs more agreement than review. Not that anyone is objecting, AFAIK. TOAST thresholds - Not sure what this is. There is a patch by Tom here: http://archives.postgresql.org/pgsql-patches/2008-02/msg00053.php that looks ok to me. Avahi support - I don't know enough about this to comment DTrace enhancements - I don't know enough about this either to comment -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > The first commitfest has been on for about a week now, but I haven't > seem much festivities going on. > > Do we plan to drain Bruce's patch queue completely during this > commitfest? Or the items on the developer wiki TODO:PatchStatus list? > When do we declare the commitfest to be over? > > Bruce's queue has many patches in there that haven't had any activity, > and not all of the items are patches. The wiki is not quite up-to-date > either. Looking at the items in the wiki, here's my quick triage of the > items that have no reviewer assigned: I am basically 1-2 days away from having the patch queue full/complete, at which point I think we are going to need to make some decisions, as you mentioned. Lots of items are unclear and just need a decision if it is a TODO, patch work, or just discarded. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Heikki Linnakangas" <heikki@enterprisedb.com> writes: > The first commitfest has been on for about a week now, but I haven't > seem much festivities going on. Yeah, we are a bit behind on starting it :-(. Bruce was traveling until the end of February and is still not caught up on updating his list of open patches. And I had some Red Hat responsibilities to take care of, as well as personal matters, and was happy to let it slip a few days. But we need to get on with it. > Do we plan to drain Bruce's patch queue completely during this > commitfest? Or the items on the developer wiki TODO:PatchStatus list? Right at the moment the raw data is still in Bruce's patch queue. It's becoming increasingly obvious that that isn't going to work; we can't have one man being a complete bottleneck for the entire process. I concur with your other suggestion to try to move to a wiki-based patch list, though it's unclear to me just how we should manage that. I think I'd prefer a small number of people (but more than just Bruce) responsible for updating the queue. regards, tom lane
Tom Lane wrote: > "Heikki Linnakangas" <heikki@enterprisedb.com> writes: > > The first commitfest has been on for about a week now, but I haven't > > seem much festivities going on. > > Yeah, we are a bit behind on starting it :-(. Bruce was traveling > until the end of February and is still not caught up on updating > his list of open patches. And I had some Red Hat responsibilities > to take care of, as well as personal matters, and was happy to let > it slip a few days. But we need to get on with it. > > > Do we plan to drain Bruce's patch queue completely during this > > commitfest? Or the items on the developer wiki TODO:PatchStatus list? > > Right at the moment the raw data is still in Bruce's patch queue. > It's becoming increasingly obvious that that isn't going to work; > we can't have one man being a complete bottleneck for the entire > process. I concur with your other suggestion to try to move to > a wiki-based patch list, though it's unclear to me just how we > should manage that. I think I'd prefer a small number of people > (but more than just Bruce) responsible for updating the queue. Consider I am collecting all our open items from the past 10 months. Even when I am done the patch queue is going to be a load of work --- take a look at what is there now. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Tom Lane wrote: > > Right at the moment the raw data is still in Bruce's patch queue. > > It's becoming increasingly obvious that that isn't going to work; > > we can't have one man being a complete bottleneck for the entire > > process. I concur with your other suggestion to try to move to > > a wiki-based patch list, though it's unclear to me just how we > > should manage that. I think I'd prefer a small number of people > > (but more than just Bruce) responsible for updating the queue. > > Consider I am collecting all our open items from the past 10 months. > Even when I am done the patch queue is going to be a load of work --- > take a look at what is there now. We need storage of patches _outside_ our current patch queue. As a first problem with the statu quo, it's not possible for other people to add patches to the queue. Bruce suggests having a special email address that will allow people to bounce patches to. I see this as a kludge (a workable one perhaps, but still a kludge). Also it's not clear how it deals with authorization, though this is probably not a problem these days. The second problem is that there's no way to actually extract the patch from the queue. Cut'n pasting doesn't work, because whitespace is mangled. So one has to resort (retort?) to extracting the patch from one own's mbox, which sort of works -- unless it doesn't. And then you have to work out what's the email containing the latest patch is; if Bruce added a copy to the queue but the author updated it, how do you find that out? As a stopgap measure, a Wiki page could work. Patches should be attached to the page, or a link to external storage should be posted (but not to archives, obviously). -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Alvaro Herrera wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > > Right at the moment the raw data is still in Bruce's patch queue. > > > It's becoming increasingly obvious that that isn't going to work; > > > we can't have one man being a complete bottleneck for the entire > > > process. I concur with your other suggestion to try to move to > > > a wiki-based patch list, though it's unclear to me just how we > > > should manage that. I think I'd prefer a small number of people > > > (but more than just Bruce) responsible for updating the queue. > > > > Consider I am collecting all our open items from the past 10 months. > > Even when I am done the patch queue is going to be a load of work --- > > take a look at what is there now. > > We need storage of patches _outside_ our current patch queue. > > As a first problem with the statu quo, it's not possible for other > people to add patches to the queue. Bruce suggests having a special > email address that will allow people to bounce patches to. I see this > as a kludge (a workable one perhaps, but still a kludge). Also it's not > clear how it deals with authorization, though this is probably not a > problem these days. Right. > The second problem is that there's no way to actually extract the patch > from the queue. Cut'n pasting doesn't work, because whitespace is > mangled. So one has to resort (retort?) to extracting the patch from > one own's mbox, which sort of works -- unless it doesn't. And then you > have to work out what's the email containing the latest patch is; if > Bruce added a copy to the queue but the author updated it, how do you > find that out? Does the web site mhonarc archive have the same problem? Do you have URLs? (You can download an mbox of my patches list from the top link.) > As a stopgap measure, a Wiki page could work. Patches should be > attached to the page, or a link to external storage should be posted > (but not to archives, obviously). The bottom line is that this going to be painful no matter how we go at it: http://momjian.us/cgi-bin/pgpatches There are nine pages now. The patch queue will be twice that size once I am done. I am trying to trim but it is difficult. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > The bottom line is that this going to be painful no matter how we go at > it: > http://momjian.us/cgi-bin/pgpatches Yup. > There are nine pages now. The patch queue will be twice that size once > I am done. I am trying to trim but it is difficult. Bruce, you are putting too much of the work on your own shoulders and bottlenecking the whole process. Just dump stuff into the queue, don't trim and for heavens sake stop fixing "simple" things as you go. Once the queue is there we can spread around the work of processing the items. regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > The bottom line is that this going to be painful no matter how we go at > > it: > > http://momjian.us/cgi-bin/pgpatches > > Yup. > > > There are nine pages now. The patch queue will be twice that size once > > I am done. I am trying to trim but it is difficult. > > Bruce, you are putting too much of the work on your own shoulders and > bottlenecking the whole process. Just dump stuff into the queue, don't > trim and for heavens sake stop fixing "simple" things as you go. Once > the queue is there we can spread around the work of processing the > items. OK, you asked for it. All emails have been moved from pgpatches_hold to pgpatches. There are 19 pages. Let the pain begin! http://momjian.us/cgi-bin/pgpatches -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 7 Mar 2008 12:29:13 -0300 Alvaro Herrera <alvherre@commandprompt.com> wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > > > > Right at the moment the raw data is still in Bruce's patch queue. > > > It's becoming increasingly obvious that that isn't going to work; > > > we can't have one man being a complete bottleneck for the entire > > > process. I concur with your other suggestion to try to move to > > > a wiki-based patch list, though it's unclear to me just how we > > > should manage that. I think I'd prefer a small number of people > > > (but more than just Bruce) responsible for updating the queue. > > > > Consider I am collecting all our open items from the past 10 > > months. Even when I am done the patch queue is going to be a load > > of work --- take a look at what is there now. > > We need storage of patches _outside_ our current patch queue. O.k. this is ugly, probably shouldn't be done, and I may be flamed into oblivion for this but since we aren't using some kind of bug tracker that will detach the patches etc... Have we considered a read only imap server with a patches account that anyone can attach to with their email client to pull patches? Or, just a web-email interface that would allow someone to download the attachment? Sincerely, Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH0W/pATb/zqfZUUQRAsBmAJ9afIUgsuN+26zjbdk8MHcfX9755QCeISM6 zxcu/CxQYN2ujjovJXrm2H8= =E+FF -----END PGP SIGNATURE-----
Bruce Momjian <bruce@momjian.us> writes: > Tom Lane wrote: >> Bruce, you are putting too much of the work on your own shoulders and >> bottlenecking the whole process. Just dump stuff into the queue, don't >> trim and for heavens sake stop fixing "simple" things as you go. Once >> the queue is there we can spread around the work of processing the >> items. > OK, you asked for it. All emails have been moved from pgpatches_hold to > pgpatches. There are 19 pages. Let the pain begin! > http://momjian.us/cgi-bin/pgpatches OK, so now we need to actually divvy up the work somehow. Anyone want to take any particular pieces of this? I think the first step is triage --- which items actually need review now, which are dead or should become TODO entries, and which are trivial enough to just deal with without review. (Bruce, I guess you already did that on a portion of this list, but which portion?) Since there are 19 pages and probably less than 19 interested hackers, maybe we could just each take a page of the list as it stands and go through it at that level? Although many of the threads cross pages, so that's not ideal. Any other ideas? regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> Bruce, you are putting too much of the work on your own shoulders and > >> bottlenecking the whole process. Just dump stuff into the queue, don't > >> trim and for heavens sake stop fixing "simple" things as you go. Once > >> the queue is there we can spread around the work of processing the > >> items. > > > OK, you asked for it. All emails have been moved from pgpatches_hold to > > pgpatches. There are 19 pages. Let the pain begin! > > http://momjian.us/cgi-bin/pgpatches > > OK, so now we need to actually divvy up the work somehow. Anyone want > to take any particular pieces of this? I think the first step is triage > --- which items actually need review now, which are dead or should > become TODO entries, and which are trivial enough to just deal with > without review. (Bruce, I guess you already did that on a portion > of this list, but which portion?) Page 1-9 but lots I couldn't decide if they were TODO. I am now adding comments to lots of entries so people know what I need to know about it. > Since there are 19 pages and probably less than 19 interested hackers, > maybe we could just each take a page of the list as it stands and go > through it at that level? Although many of the threads cross pages, so > that's not ideal. Any other ideas? The problem is that as they are deleted, they will move. Perhaps I can just comment on them to close them and not delete anything. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes: > Tom Lane wrote: >> Since there are 19 pages and probably less than 19 interested hackers, >> maybe we could just each take a page of the list as it stands and go >> through it at that level? Although many of the threads cross pages, so >> that's not ideal. Any other ideas? > The problem is that as they are deleted, they will move. Perhaps I can > just comment on them to close them and not delete anything. Ah, right. And the other problem is additions of new messages to threads. So the page boundaries can't be expected to stay stable for long. The comment thing is kinda cool, but I don't feel very comfortable about using the comments for anything substantive. Actual reviews of patches, for example, need to still be sent on the mailing lists so that they'll go into the archives. I suggest we just use the comments for status annotations, like "done" or "no patch here, make a TODO" or "needs review, I will review". regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [080307 11:46]: > Since there are 19 pages and probably less than 19 interested hackers, > maybe we could just each take a page of the list as it stands and go > through it at that level? Although many of the threads cross pages, so > that's not ideal. Any other ideas? Only 150 "patches" in that queue, if you eliminate all the discussions and threads:http://people.ifax.com/~aidan/pg/patches.mbox a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Tom Lane wrote: > >> Since there are 19 pages and probably less than 19 interested hackers, > >> maybe we could just each take a page of the list as it stands and go > >> through it at that level? Although many of the threads cross pages, so > >> that's not ideal. Any other ideas? > > > The problem is that as they are deleted, they will move. Perhaps I can > > just comment on them to close them and not delete anything. > > Ah, right. And the other problem is additions of new messages to > threads. So the page boundaries can't be expected to stay stable for > long. Oh, yea, if I add things to the list they would bump things around. Perhaps we can just skip the idea that the URLs are constant and rely on the comments as staying with the emails. > The comment thing is kinda cool, but I don't feel very comfortable about > using the comments for anything substantive. Actual reviews of patches, > for example, need to still be sent on the mailing lists so that they'll > go into the archives. I suggest we just use the comments for status > annotations, like "done" or "no patch here, make a TODO" or "needs > review, I will review". Yea, the comments are to prompt people about what we need to do. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Aidan Van Dyk wrote: -- Start of PGP signed section. > * Tom Lane <tgl@sss.pgh.pa.us> [080307 11:46]: > > > Since there are 19 pages and probably less than 19 interested hackers, > > maybe we could just each take a page of the list as it stands and go > > through it at that level? Although many of the threads cross pages, so > > that's not ideal. Any other ideas? > > > Only 150 "patches" in that queue, if you eliminate all the discussions > and threads: > http://people.ifax.com/~aidan/pg/patches.mbox True, but we can't just discard all the ideas we had --- we need to decide if they are worth persuing or adding to TODO. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, Mar 7, 2008 at 11:48 AM, Bruce Momjian <bruce@momjian.us> wrote: > > Since there are 19 pages and probably less than 19 interested hackers, > > maybe we could just each take a page of the list as it stands and go > > through it at that level? Although many of the threads cross pages, so > > that's not ideal. Any other ideas? > > The problem is that as they are deleted, they will move. Perhaps I can > just comment on them to close them and not delete anything. I checked the patches listing for our own stuff, and confirmed missing some of the later exchanges. It wouldn't be helpful to a reviewer without some of the other context on the mailing list. ISTM if we move to a 'wiki style' patch management, or something more formal like a bug tracker the work becomes more decentralized and the patch developer becomes more involved in keeping the patch list up to date with the latest stuff. I think the wiki, being a more organic type of approach. is maybe a better fit for postgresql community style, and there is still a lot of 'plumbing' work to do. If you want to move some stuff to the wiki I will volunteer to help out with the initial transfer of patches from the hold list. I can do some review also, but am only up to snuff to review maybe 20% of the patches on there, so maybe page/person is not a good way to divide it up. I think better to just grab a patch and put yourself as a reviewer on the wiki. merlin
Bruce Momjian wrote: > Aidan Van Dyk wrote: > -- Start of PGP signed section. > > Only 150 "patches" in that queue, if you eliminate all the discussions > > and threads: > > http://people.ifax.com/~aidan/pg/patches.mbox > > True, but we can't just discard all the ideas we had --- we need to > decide if they are worth persuing or adding to TODO. Move the ideas to a different mbox. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
* Bruce Momjian <bruce@momjian.us> [080307 12:29]: > Aidan Van Dyk wrote: > -- Start of PGP signed section. > > * Tom Lane <tgl@sss.pgh.pa.us> [080307 11:46]: > > > > > Since there are 19 pages and probably less than 19 interested hackers, > > > maybe we could just each take a page of the list as it stands and go > > > through it at that level? Although many of the threads cross pages, so > > > that's not ideal. Any other ideas? > > > > > > Only 150 "patches" in that queue, if you eliminate all the discussions > > and threads: > > http://people.ifax.com/~aidan/pg/patches.mbox > > True, but we can't just discard all the ideas we had --- we need to > decide if they are worth persuing or adding to TODO. Sure, but ideas *are* discussed on the list as they come up. But it's not ideas that get committed during the commitfest. It's up to the "itchy" person to use the discussion on the lists around the ideas to come up with something concrete that *needs* to be more than hand-waving to be reviewed during a commit fest. That concrete something could be: *) A complete "patch" *) A partial patch (implementing step X of the discussed goals *) A defined implementation proposal (a patch minus C-language code) Ideas and discussion are important (actually vital). But the commit-fest is a period that reviewers and committers set apart time to process the *products* of ideas and proposals that have come about so far. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Merlin Moncure escribió: > ISTM if we move to a 'wiki style' patch management, or something more > formal like a bug tracker the work becomes more decentralized and the > patch developer becomes more involved in keeping the patch list up to > date with the latest stuff. I think the wiki, being a more organic > type of approach. is maybe a better fit for postgresql community > style, and there is still a lot of 'plumbing' work to do. Right. If the submitter thinks that the reviewer is going to need to have a look at the relevant email archives, he can post a link to the archives in the discussion web page for the patch. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Aidan Van Dyk wrote: > > > Only 150 "patches" in that queue, if you eliminate all the discussions > > > and threads: > > > http://people.ifax.com/~aidan/pg/patches.mbox > > > > True, but we can't just discard all the ideas we had --- we need to > > decide if they are worth persuing or adding to TODO. > > Sure, but ideas *are* discussed on the list as they come up. But it's > not ideas that get committed during the commitfest. > > It's up to the "itchy" person to use the discussion on the lists around > the ideas to come up with something concrete that *needs* to be more > than hand-waving to be reviewed during a commit fest. > > That concrete something could be: > *) A complete "patch" > *) A partial patch (implementing step X of the discussed goals > *) A defined implementation proposal (a patch minus C-language code) > > Ideas and discussion are important (actually vital). But the > commit-fest is a period that reviewers and committers set apart time to > process the *products* of ideas and proposals that have come about so > far. Well, when do we make decisions on these non-patch issue? Seems the commit fest is the right time to that too. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Alvaro Herrera wrote: > Merlin Moncure escribi?: > > > ISTM if we move to a 'wiki style' patch management, or something more > > formal like a bug tracker the work becomes more decentralized and the > > patch developer becomes more involved in keeping the patch list up to > > date with the latest stuff. I think the wiki, being a more organic > > type of approach. is maybe a better fit for postgresql community > > style, and there is still a lot of 'plumbing' work to do. > > Right. If the submitter thinks that the reviewer is going to need to > have a look at the relevant email archives, he can post a link to the > archives in the discussion web page for the patch. True, but what are the odds that is going to happen. We have trouble getting context diffs. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Alvaro Herrera wrote: >> Merlin Moncure escribi?: >> >>> ISTM if we move to a 'wiki style' patch management, or something more >>> formal like a bug tracker the work becomes more decentralized and the >>> patch developer becomes more involved in keeping the patch list up to >>> date with the latest stuff. I think the wiki, being a more organic >>> type of approach. is maybe a better fit for postgresql community >>> style, and there is still a lot of 'plumbing' work to do. >> Right. If the submitter thinks that the reviewer is going to need to >> have a look at the relevant email archives, he can post a link to the >> archives in the discussion web page for the patch. > > True, but what are the odds that is going to happen. We have trouble > getting context diffs. > I know merlin and I allocated a lot of resources towards our patch. If getting reviewed required us to jump through some hoops (like being repsonsible for updating a wiki), then so be it. If someone doesn't follow the patch submission rules, then the patch can't be reviewed as it is not within the proper state ... not a punishment just a patch not meeting review requirements. What are the requirements of a patch submission, don't know. One thing is for sure, the patch submitter is probably the most familiar with it so should be involved at some level of review preparation. This distributes the work and "attempts" to make patches more consistent when reviewed. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
* Bruce Momjian <bruce@momjian.us> [080307 13:11]: > > Ideas and discussion are important (actually vital). But the > > commit-fest is a period that reviewers and committers set apart time to > > process the *products* of ideas and proposals that have come about so > > far. > > Well, when do we make decisions on these non-patch issue? Seems the > commit fest is the right time to that too. There are 2 big decisions in the process: 1) Is this "feature/topic" worth *me* working on? 2) Is the result of that work worth going into "official" PostgreSQL CVS? #1 is made by the developer, hopefully based on some initial discussion on the lists. IF the discussion is overwhelmingly dismissive, or negative, or points in the some other direction, hopefully that decision will be an easy "no", so the developer doesn't waste his time. But the reviewers/committers *don't* decide if or what is worth a developer's effort. Even if it's *not* something that the community sees working out for PostgreSQL, it very well *may* be something "worth it" for the developer to pursue himself. It's simply his decision. And even if it *is* something that may be very good and desirable for PostgreSQL, the community can't make a developer work on it. It's an open source project. #2 is made by the reviewers/committers when the person presents the work he thought "worth it". And they can only make that decision when there is "something" to decide on. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Am Freitag, 7. März 2008 schrieb Bruce Momjian: > OK, you asked for it. All emails have been moved from pgpatches_hold to > pgpatches. There are 19 pages. Let the pain begin! > > http://momjian.us/cgi-bin/pgpatches OK, now how about moving this directory to developer.postgresql.org, do chgrp -R dev; chmod g+rw, and we can start working.
Peter Eisentraut wrote: > Am Freitag, 7. M?rz 2008 schrieb Bruce Momjian: > > OK, you asked for it. ?All emails have been moved from pgpatches_hold to > > pgpatches. ?There are 19 pages. ?Let the pain begin! > > > > ????????http://momjian.us/cgi-bin/pgpatches > > OK, now how about moving this directory to developer.postgresql.org, do > chgrp -R dev; chmod g+rw, and we can start working. Huh, it is a single mbox file, and is tied to my mhonarc and comments HTML code. What do you want to do? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +