Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Tom Lane ([EMAIL PROTECTED]) wrote: It's essential IMHO that we provide pg_shadow and pg_group as reasonably backward-compatible views on the new pg_roles catalog. It's not at all negotiable that CREATE USER and CREATE GROUP have to still work in a sane fashion --- to say otherwise is to say that we aren't going to load pg_dumpall scripts from older PG versions, and that is a Non Starter. Right, makes sense, I had just busted them while getting the initial code written. I've now gone back and cleaned up the main parser quite a bit with regard to create/alter/drop/etc user/role. My latest work is available here: http://kenobi.snowman.net/~sfrost/pg_role/latest-role_20050609.1.patch.gz Also the .h files in the same directory (pg_auth_members.h, pg_authid.h) which need to be put into src/include/catalog/. It patches and compiles cleanly against latest CVS (at least, latest as of a few hours ago). I've also updated and flushed out a bit the set of milestones/todo items. My latest version of that can be found here: http://kenobi.snowman.net/~sfrost/pg_role/role_milestones * Means completed in the patch, ? means I'm not sure if it's something that should be done or not. No marker means it needs to be done and hasn't been yet. In general I feel it's starting to get close to meeting all the expectations that I had for it. The more critical things, imv, are the ACL changes for multi-level role resolution (for owners and others) and the per-backend role-member cacheing and fixing the other parsers (ecpg, etc, shouldn't be too hard now that I've got it figured out for the main parser, or at least think I do). Unfortunately, it's starting to get close to July 1st and my availablity is rather sporadic in terms of when I can spend time on this. I'd certainly be willing to work with others (I'm generally pretty responsive to email) to get this finished off and polished up. I do hope to spend some more time on it over the next two weeks and may be able to finish it by July 1st myself but I can't really be 100% sure on that. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Andrew Dunstan wrote: Tom Lane said: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. -- 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On May 20, 2005, at 11:43 PM, Bruce Momjian wrote: Andrew Dunstan wrote: Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. This may be a bit off-the-wall, but I recall Joel Spolsky recently writing about using Bayesian filtering to classify mail into groups other than spam/ham. I wonder if there's any use for something like that in this case. http://www.joelonsoftware.com/articles/FogBugzII.html Michael Glaesemann grzm myrealbox com ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Fri, May 20, 2005 at 11:59:00PM +0900, Michael Glaesemann wrote: Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. This may be a bit off-the-wall, but I recall Joel Spolsky recently writing about using Bayesian filtering to classify mail into groups other than spam/ham. I wonder if there's any use for something like that in this case. http://www.joelonsoftware.com/articles/FogBugzII.html No, definitely not. Pseudo-bayesian classification as used by the more optimistic spam-filtering folks is pretty crappy at the best of times, and it's really unusuable for more than 3-4 categories. There are natural language analysis techniques that'll do this sort of thing, but they're in the realms of research projects, not canned tools. Cheers, Steve ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. However RT isn't really targeted at bug tracking specifically. It's more of a trouble ticket system. Targeted largely to things like NOCs or incident response ticketing systems. It's much more flexible than pure bug tracking systems like bugzilla and might be able to adapt to a more open email based working model better. But by the same token it would take more attention to set it up and adapt it to bug tracking. -- greg ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Joshua, does RT has full support of PostgreSQL ? Oleg On Tue, 17 May 2005, Joshua D. Drake wrote: discuss it, and contribute to resolving it. More often than not, a web-based interface like Bugzilla leads to a single bug master, who does most of this work by themselves. Besides the fact we don't have such a person, it would also mean that knowledge of bugs/patches and the discussion about resolving issues is distributed among a smaller pool of people. I can only speak for RT but with RT you can easily avoid this. For example you can set it up so that anything that would go to [EMAIL PROTECTED] would automatically create a ticket an alert all people within the patches group. Multiple people can be assigned to a ticket as a maintainer or just a watcher. You can even respond to specific messages within the thread instead of just a top down (one email after the other). There is definitely room for improvement; submitted patches do occasionally fall through the cracks, for example. I would personally be interested in a bug-tracking system that is closer to a shared email archive. That would be another nice part of RT. RT automatically deals with attachments and although I wouldn't use it for this you could even use it as a semi patch repository until the patch is actually approved for submission. issues, searching through issues, etc. But the point is that the current system works well; Well does it though? I am not saying it is bad, well yes I am ;). There is no central place for me to point one of my developers and say -- Hey, look at this patch... weren't we working on something like this? Let's help them out. I have to have the dig through the mail archives which is fairly counter productive. It would be much better to be able to say, hey... look at patch #42345. What do you think? I'm not sure which existing systems fit this model (suggestions are welcome) -- email needs to be the primary interface, not an afterthought (as is often the case). Perhaps RT would work, I'm not sure. RT supports complete email integration. Most of the interaction I do with it is actually through email not through the web interface. It also has the ability to have a knowledge base dropped right on top of it. Sincerely, Joshua D. Drake -Neil [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point effectively. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane wrote: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. What we do now is not to require the reporter or the developers to classify the email traffic, and the burden is on the people looking for specific information to find it. I am not suggesting we change that, but this the trade-off we have made. The only classification we do is the TODO list and the release notes --- everything else is email searches. -- 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On K, 2005-05-18 at 02:23 -0400, Bruce Momjian wrote: What we do now is not to require the reporter or the developers to classify the email traffic, and the burden is on the people looking for specific information to find it. I am not suggesting we change that, but this the trade-off we have made. The only classification we do is the TODO list and the release notes --- everything else is email searches. Maybe we should look for some mail-archive software which allows adding such tagging after the mail is stored in the list, so that once someone has found the information he was looking for, he could check some checkboxes or make some selections to make finding the info easier the next time. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane said: Greg Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. The basic point here is that these systems are designed on the assumption that there is a small, easily identified set of people who need-to-know about any given problem. We (Postgres) have done well by *not* using that assumption, and I'm not eager to adopt a tool that forces us to buy into that mindset. Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Apart from the question of who gets notifications, tracking systems provide some structure and manageability to the data. I find it mildly ironic to see database people eschew the methods of organisation which their own product could help to provide. But all this discussion seems to me pointless anyway - I don't see anybody with enough experience and respect being able to devote enough time to keep a tracking system healthy and useful. And without that we might as well just sit tight. Meanwhile, how about the earlier suggestions related to improving the TODO list a bit (e.g. a beginner's list)? cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane [EMAIL PROTECTED] writes: [ shrug... ] BZ sends me email too --- for the things *it* thinks I should know about. Right, what I'm saying is that in RT it's more flexible; you can set it up to send mail for the things *you* think people should know about. Also, BZ and most bug tracking systems make it hard to keep email as the communication mechanism of choice. Most of them (like BZ) just send you email with URLs to click to go to the web. There's also the Debian bug tracking system. It also works well with a mailing list set to be the maintainer. Then everyone on the mailing list gets every update on any bug. And you can update or close bugs by just sending email. Several of the larger Debian packages use this model including the X packages. -- greg ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Tom Lane ([EMAIL PROTECTED]) wrote: I think most of the real advantages of bug trackers that have been mentioned in this thread have to do with history and searchability. We have the raw info for that, in the pgsql-bugs and pgsql-commmitters mail archives, and so it seems to me that this reduces to the perennial gripe that we don't have good enough search tools for the archives. This also means, to some extent anyway, that someone who wants to show off the latest-greatest bug tracking system that will satisfy all our needs could 'seed' the system with at least some of the history that's available currently through the mailing list archives. If they (or the part of the community interested in it, whatever) then work to keep it up to date and show that it's a better system in whatever way, that'd go a great deal farther towards acceptance. Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
People: I think maybe we're putting on the frosting without the cake here. The primary purpose of bug trackers is to help get bugs fixed. Over the last couple of days, we've had a lot of comments from major bug-fixers that a BT isn't *needed* to get bugs fixed. Let's look at tools which address what we actually *do* need, rather than what we don't. Here's where I see a lack: 1) The TODO list is a bit impenetrable for new hackers wanting to get started with PostgreSQL tasks. 2) Users could use a place to look up their current bug and find out what version it was/will be fixed in. 3) Users could use a place to look up known issues/misunderstandings and find education and workarounds. None of those tasks necessarily requires a bug tracker. In fact, I'd advocate a project task list for (1) (which we conveninetly have in pgFoundry) and a knowledge base for (2) and (3). The issue in all cases is upkeep. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wednesday 18 May 2005 04:54, Andrew Dunstan wrote:
Meanwhile, how about the earlier suggestions related to improving the TODO
list a bit (e.g. a beginner's list)?
I think it would be simple enough to tag certain items on the list as low
hanging fruit that there is no reason not to do it.
On a side note, I think that also moving a few items in to a urgent section
like we had for 8.0 would be a really good idea for the start of each
development cycle. Tom mentioned that an item being included on the TODO list
doesn't mean all of core has bought in to it, so let's see a few items that
all of core has bought in to and agrees we might be close to. (Hierarchical
queries and updateable views, both of which are items with outstanding
patches/work and general core approval, come to mind.)
While we can't garauntee these things will be included in any release, a
section of 4-5 items that core/hackers agreed that should be in the next
release would probably help steer people to tackling those problems.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Oleg Bartunov wrote: Joshua, does RT has full support of PostgreSQL ? It support's Postgres, but it uses a dynamic query builder that is pretty brain dead. It only implements features that are cross DB compatible. It comes up with some pretty ugly queries. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tuesday 17 May 2005 01:41, Josh Berkus wrote: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince Yes, I have. Yes, it's steeper. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Lamar Owen ([EMAIL PROTECTED]) wrote: On Tuesday 17 May 2005 01:41, Josh Berkus wrote: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince Yes, I have. Yes, it's steeper. That seems rather odd to me. I havn't really looked at the OpenOffice.org code very much but generally I've found the PostgreSQL code to be pretty well commented and generally well thought-out. I've also found the acceptance, understanding and hand-holding of the PostgreSQL developers to be *better* than I've found in other communities (such as the Linux kernel...) that I've developed and have had code included in. I havn't actually gotten anything real into PostgreSQL *yet*, but I've been spending a fair bit of time on implementing support for SQL Roles and have had alot of help developing the approach for best implementing it (thanks Tom!) and help with stupid questions (what's a tuple?) from a couple developers on IRC (thanks Neil! thanks Andrew!). So, no, I don't think the barrier to entry is all that steep, and it's certainly not *too* steep by any means. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, May 18, 2005 at 05:19:55PM -0400, Stephen Frost wrote: * Lamar Owen ([EMAIL PROTECTED]) wrote: On Tuesday 17 May 2005 01:41, Josh Berkus wrote: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince Yes, I have. Yes, it's steeper. That seems rather odd to me. I havn't really looked at the OpenOffice.org code very much but generally I've found the PostgreSQL code to be pretty well commented and generally well thought-out. I've also found the acceptance, understanding and hand-holding of the PostgreSQL developers to be *better* than I've found in other communities (such as the Linux kernel...) that I've developed and have had code included in. Certainly the code is exceptionally beautiful. Anyone who has seen both Postgres' and MySQL sources can confirm that I think. Now *that* is an unreadable mess :-( I havn't actually gotten anything real into PostgreSQL *yet*, but I've been spending a fair bit of time on implementing support for SQL Roles and have had alot of help developing the approach for best implementing it (thanks Tom!) and help with stupid questions (what's a tuple?) from a couple developers on IRC (thanks Neil! thanks Andrew!). Say, how are you doing on that front? -- Alvaro Herrera (alvherre[a]surnet.cl) No es bueno caminar con un hombre muerto ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Josh Berkus wrote: 1) The TODO list is a bit impenetrable for new hackers wanting to get started with PostgreSQL tasks. [snip] In fact, I'd advocate a project task list for (1) (which we conveninetly have in pgFoundry) It belongs as part of the TODO list, I believe, or keeping it in sync will bedevil it. Just mark possible beginner tasks with something, like *, # or whatever. Or else maybe give them their own section. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Alvaro Herrera ([EMAIL PROTECTED]) wrote: I havn't actually gotten anything real into PostgreSQL *yet*, but I've been spending a fair bit of time on implementing support for SQL Roles and have had alot of help developing the approach for best implementing it (thanks Tom!) and help with stupid questions (what's a tuple?) from a couple developers on IRC (thanks Neil! thanks Andrew!). Say, how are you doing on that front? Current status is- it now compiles with a few pieces still missing: Better parser/backend setup needs to be done. I've hacked 'create role' into place where 'create group' was, but really I need to sit down and think about the *correct* statements, looking at the standard, etc, and write those and the associated back-end parts (most of the back-end parts are already done I think). Once those are done and implemented I'll see about backwards compatibility to the create user/create group parts. pg_group and associated views (information_schema, etc). We don't currently have an aggregate-into-array function that I saw so either we'll need to write one or we'll have to fake the information in pg_group (as, say, just the first group you're in, or something). This is only for backwards-compatibility to things which used pg_group so I'm not sure how important it is for it to be fully functional. I *think* I updated all the information_schema views to not use pg_group but to use the new system tables and that they're implemented correctly. I'm trying to think but there might be another view that was involved in this but I'm not sure. Write the base-case (no cache available) 'in_role' lookup code. I expect this code will also be used during role assignment to verify there are no loops. 'in_role' currently works for the one-level case, but doesn't handle the multi-level case. Shouldn't be too hard to do. Per-connection cacheing code for 'in_role' information. Discussed this with Tom, basically it'll be similar to the search_path cacheing code which is in namespace.c where the cache is marked out of date and regenerated whenever there's a change to the pg_auth_members table. Don't expect this to be very difficult. Once this is done the 'in_role' code in the ACL system will need to be updated for it. flat-file startup updating. This is what I'm currently working on. The difficulty is that I want the flat-files to have only names but the role/member information is in terms of Oids which need to be looked up to role names. Since this is during startup code now the syscache isn't available. What I'm doing is building a copy of the tables in memory (since they should be reasonably small), qsorting them and using bsearch for the lookups. Since they're in memory already and the write-new-role-information situation is much less common than startup I think I'm also going to qsort based on role name and define the format of the pg_auth table to be already-sorted so that the startup code doesn't need to sort it. Once I get all of the startup code working and can actually *connect* to the database I'll be doing a great deal more testing, bug fixing, and implementing the remaining items and testing them. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Stephen Frost [EMAIL PROTECTED] writes: Say, how are you doing on that front? Current status is- it now compiles with a few pieces still missing: [snip] It's essential IMHO that we provide pg_shadow and pg_group as reasonably backward-compatible views on the new pg_roles catalog. It's not at all negotiable that CREATE USER and CREATE GROUP have to still work in a sane fashion --- to say otherwise is to say that we aren't going to load pg_dumpall scripts from older PG versions, and that is a Non Starter. (Not too many releases ago, we couldn't even say that: once upon a time pg_dumpall tried to emit COPY TO pg_shadow commands :-(. But I hope that it's no longer necessary to handle that ...) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On T, 2005-05-17 at 01:32 -0400, Tom Lane wrote: As against that I notice some new arrivals proposing to add deductive reasoning to Postgres: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php or implement SQL99 hierarchical queries: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I guess you have missed most of the latest discussion around hierarchical queries ;) From what I understand, what is proposed is a code beautification project, (although likely not minor :) , because the pathes have been around (and allegedly in production use) for a few years already, originally supporting Oracle-style HQs and then, for about a year also subset of SQL99 (it misses SEARCH and CYCLE clauses, see the railroad diagram at http://gppl.moonbone.ru/with_clause.gif ) The patch is available at http://gppl.moonbone.ru/index.shtml I might be wrong, but I'll bet lunch that neither of those projects will come to anything. You can't run before you learn to crawl. Maybe you could take a look at the existing patch and comment what are the points that are most wrong with it. The last one was for 8.0.1. I'm sure someone more at home with pg internals would get the patch to acceptable level faster, but my feeling is that somehow these patches have been just not interesting to core developers. Maybe what we need is some documentation about how to get started as a Postgres hacker --- what to read, what sort of things to tackle for your first hack, etc. I think the people who have been successful around here are the ones who have managed to figure out the syllabus by themselves ... but surely we could try to teach those who come after. A code documentation or beautification project is usually a good way to get newcomers up to speed. And though the getting the the HQ patch into acceptable shape is probably quite big work, just starting with understanding and documenting what it does now and getting further help from pgsql-hackers on what it should do may be something that is possible without existing thorough understanding. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
I think it might also be valuable to have a list of things that are good 'starter projects'. Maybe some indication of TODO items that are simpler. Possibly a list of bugs, too. As someone who has looked at hacking the pg code, I agree it is difficult to know what to look at to get started. I love fixing bugs, but I'm used to the bug tracker type situation and being able to find something that looks relatively easy. That is how I've started on a number of other projects. With no formal bug tracker, I'm not sure what bugs I could look at. I have talked to some people on IRC about tackling the infinite date issue, but was warned off that, as the date/time code is a scary place. Then I looked into the possibility of working on the autovacuum stuff, and again got myself in a little too deep. Not low enough fruit for me. The curve to get the meaning of some things is sometimes hard PG_TRY and things like that just need reading code lots. Not meaning to attack Tom, but for new people proposing new patches he can seem intimidating. I have been around for a little while now and am adjusting to the reality. Maybe people shouldn't be hacking the code before being here a year. It would probably also be useful to point out ways people can help that don't involve hacking C code (or at least not much). Things like docs, the website, advocacy, performance testing, etc. It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). But at the same time, how do I not get into something that is being duplicated by somebody else? I'm just trying to give a bit of a perspective on the way I see things as some who has been around pg for about 12 months and attempted to hack the code a couple of times. Regards Russell Smith ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, May 17, 2005 at 09:23:42PM +1000, Russell Smith wrote: I think it might also be valuable to have a list of things that are good 'starter projects'. Maybe some indication of TODO items that are simpler. Possibly a list of bugs, too. As someone who has looked at hacking the pg code, I agree it is difficult to know what to look at to get started. I love fixing bugs, but I'm used to the bug tracker type situation and being able to find something that looks relatively easy. That is how I've started on a number of other projects. With no formal bug tracker, I'm not sure what bugs I could look at. I have talked to some people on IRC about tackling the infinite date issue, but was warned off that, as the date/time code is a scary place. I'd say the datetime code is a good place to start, the most important characteristic being that it's self contained. It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). Yes, performance testing may also show some implementation bugs that are important to find too. Stress-testing is important too. Or find corner cases, push implementation limits, etc. Or, find some area that people mentions as needing testing, the current example being SIGTERM handling in busy backends. But at the same time, how do I not get into something that is being duplicated by somebody else? Tell -hackers. But if you are going to do testing, it doesn't matter there is multiple people doing it. -- Alvaro Herrera (alvherre[a]surnet.cl) The first of April is the day we remember what we are the other 364 days of the year (Mark Twain) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). But at the same time, how do I not get into something that is being duplicated by somebody else? I reckon a good newbie task at the moment would be to add ALTER object SET SCHEMA blah; on all objects... Chris ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Russell Smith wrote: Maybe people shouldn't be hacking the code before being here a year. If you want to code, jump in. It is a practical craft that you only learn by doing. You might learn something of the people but you'll probably learn precious little of the code by just watching. But don't jump in at the deep end - massive reorganisation of the planner should not be your first project ;-). Ask lots of questions. Tell people what you're doing. I like the idea of a relatively simple low hanging fruit list that we could point newcomers at. Here are some nominations: . add some more tests for the PLs now we have a standard testing framework. . clean up and document some of the contrib modules so they can go into the core (e.g. pgcrypto, dbsize, cube, seg) . rewrite contrib/reindexdb in C so it can be used on Windows . this TODO item: Remove Money type, add money formatting for decimal type I'm sure other people will have additions to such a list. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane [EMAIL PROTECTED] Date: Tue, 17 May 2005 01:32:03 -0400 As against that I notice some new arrivals proposing to add deductive reasoning to Postgres: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php or implement SQL99 hierarchical queries: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I might be wrong, but I'll bet lunch that neither of those projects will come to anything. You can't run before you learn to crawl. The main advantage of deductive reasoning implementation I propose is in fundamental extension of database query language, I don't propose to extent SQL with some cumbersome constructions, for example, like WITH to express recursive queries (inefficiency of such constructions can be easily seen if you try to express a bit more complex recursive query then finding ancestors, e.g. query which finds minimal paths). Also it should be mentioned that original query language (SQL) de facto remains without great changes, the logic program which defines predicates (intensional relations) is located in the system table (there can be put the name and both the text and inner code of logic program). When we want to get intensional relation we simply write in SQL query the name of the logic program (deductive database) and the name of the predicate with the list of arguments. This syntax is identical to the syntax of table function calling with the schema name. Regards, Dmitriy ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Russell, What should be performance tested (I assume new code, like the bitmap scan). I've been meaning to put a task list for performance testing up on the TestPerf project. Yet another personal TODO ... -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
As someone who's been lurking on the postgres lists for quite some time, and submitted one (minor) patch, I think the notion of an entry-level task list for we beginners is fantastic. And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? BJ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, 18 May 2005, Brendan Jurd wrote: As someone who's been lurking on the postgres lists for quite some time, and submitted one (minor) patch, I think the notion of an entry-level task list for we beginners is fantastic. And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? Because none of the core developers will use it, so bugs would be added, but never removed ... Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? We have a long list of 'TODO' items, but could anyone generate a list of known bugs? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Marc G. Fournier wrote: And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? Because none of the core developers will use it, so bugs would be added, but never removed ... Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? We have a long list of 'TODO' items, but could anyone generate a list of known bugs? Bug tracking systems are used to track more than just bugs ... they are often used to track enhancements, support requests, and other tasks. GForge (and hence pgfoundry) provides each project by default with several trackers, one for each of these classes. But then, as a pgfoundry admin you know that, right? :-) cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, 17 May 2005, Andrew Dunstan wrote: Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. The key requirement that has always come up is that the core developers wouldn't use anything web based, so the tracker would have to somehow tie into the mailing lists themselves ... Bug tracking systems are used to track more than just bugs ... they are often used to track enhancements, support requests, and other tasks. GForge (and hence pgfoundry) provides each project by default with several trackers, one for each of these classes. But then, as a pgfoundry admin you know that, right? :-) Again, it comes down to who will maintain it? I believe that Bruce has already stated that he hasn't got the time/desire to do much more then his current TODO lists, Tom has stated a lack of desire to use a web-based tracking tool ... so we'd need to find someone with the time to act as intermediary to update things accordingly ... ... and I think *that* is probably one of hte major show stoppers ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Andrew, Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. Or whether to use one.Roughly 1/3 bugzilla, 1/3 something else, and 1/3 don't want a bugtracker. And, among the people who didn't want bugzilla, some were vehemently opposed to it. Bugtrackers discussed included GForge, bugzilla, RT, Roundup, Jura (they offered a free license) and a few I don't remember. Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. Request Tracker (RT) can do that. We use it for all of our support ticket stuff. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Marc G. Fournier [EMAIL PROTECTED] wrote: The key requirement that has always come up is that the core developers wouldn't use anything web based, so the tracker would have to somehow tie into the mailing lists themselves ... What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. I can't speak for the people who don't like web based but my guess is that the web is not their primary medium of communication. Email is. It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. This is true or at least, this is my experience but you are not going to convince many people of that. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I agree. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Joshua D. Drake [EMAIL PROTECTED] writes: It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. This is true or at least, this is my experience but you are not going to convince many people of that. The Postgres project has been exceedingly successful while using email lists as the primary means of communication/organization. I for one am disinclined to tinker with such a fundamental aspect of the way that the community operates. If we try to substitute a bug tracker for the mailing lists, I think we'll be making a very basic change in the community's communication structure, and not one for the better. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I agree. Since the development community is neither centralised nor organized, why would you expect such a repository to have anything to do with what actually happens? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Brendan Jurd wrote: What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. Brendan, please review the past versions of this thread. For example, see here: http://groups-beta.google.com/group/comp.databases.postgresql.hackers/browse_thread/thread/1cca714cc34865a5/f802a2a78c94faa3?q=bugzillarnum=1hl=en#f802a2a78c94faa3 cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Tom Lane [EMAIL PROTECTED] wrote: The Postgres project has been exceedingly successful while using email lists as the primary means of communication/organization. I for one am disinclined to tinker with such a fundamental aspect of the way that the community operates. If we try to substitute a bug tracker for the mailing lists, I think we'll be making a very basic change in the community's communication structure, and not one for the better. I agree that it's a major change, and the significance of changing the communication structure should not be underestimated. But a) I believe it would be a change for the better, and b) BZ uses a very flexible and verbose email notification system, so the departure from the existing email list structure would not be so drastic. I read through the discussion link that Andrew provided (thanks Andrew), and during that discussion you appeared to be in favour of bugzilla, for the same sorts of reasons I am promoting it now. What changed? Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I agree. Since the development community is neither centralised nor organized, why would you expect such a repository to have anything to do with what actually happens? I think the decentralised nature of the community is one of the things that is responsible for this steep learning curve, and could stand to be improved. And deploying a more centralised system for development management would be a crucial first step in said improvement. In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, 17 May 2005 14:45:00 -0300 (ADT), Marc G. Fournier [EMAIL PROTECTED] wrote: Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? Just imagine our marketing crew being able to say: According to our great bug tracking system NN serious bugs have been reported last year, 98% of which have been fixed within three days. Servus Manfred ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Manfred, Just imagine our marketing crew being able to say: According to our great bug tracking system NN serious bugs have been reported last year, 98% of which have been fixed within three days. grin You're not going to win over many people on *this* list with marketing arguments. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Brendan Jurd wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. It's a nice offer, but honestly, my experience in the commercial world as well as in FOSS tells me that a bug tracking system would need loving care from somebody with years of experience in the postgres development community. When I was managing this stuff in a commercial setting it took a large part of my day - I had a 30 to 60 minute meeting every morning and spent a further similar period updating, assigning, etc. The people who could do it are just too damned busy. Given the amount that Tom gets done now I'm amazed that he finds time to eat drink and sleep. The things I tried to suggest earlier in this thread would be much less burdensome. As for central management ... the phrase herding cats springs to mind. cheers andrew ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. Thanks, Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Joshua D. Drake ([EMAIL PROTECTED]) wrote: One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. Request Tracker (RT) can do that. We use it for all of our support ticket stuff. debbugs can do it too, though I don't know of anyone who's actually got it working outside of the Debian stuff. :) Personally, I like Debian's bug tracking system, but I suppose that's just me... I believe OTRS can do it too. Havn't played with the email interface of it really though. Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Stephen Frost [EMAIL PROTECTED] wrote: * Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. I'm detecting sarcasm here, but just in case you're being serious ... For such a tool to serve its intended purpose, the postgres community needs to be, to a certain extent, agreed on and aware of its use as the primary dev management system. There's no point creating, hosting, updating and maintaining anything if the community isn't using it. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, May 18, 2005 at 08:04:51AM +1000, Brendan Jurd wrote: On 5/18/05, Stephen Frost [EMAIL PROTECTED] wrote: * Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. I'm detecting sarcasm here, but just in case you're being serious ... I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) -- Alvaro Herrera (alvherre[a]surnet.cl) Oh, oh, las chicas galacianas, lo harán por las perlas, ¡Y las de Arrakis por el agua! Pero si buscas damas Que se consuman como llamas, ¡Prueba una hija de Caladan! (Gurney Halleck) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) Well sorry but that is ridiculous. Either the community (or more specifically core) chooses to use it upfront or not. I think it is a complete waste of time and energy to expect someone to put in all that effort just to have the community give them the finger. This isn't something that is going to serve the person who loose all the sleep to configure and maintain it. It is something that is going to help the PostgreSQL community has a whole, to grow in a reasonably organized and hopefully less painful way. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
* Brendan Jurd ([EMAIL PROTECTED]) wrote: I'm detecting sarcasm here, but just in case you're being serious ... Yeah, for the most part I *was* being quite serious. For such a tool to serve its intended purpose, the postgres community needs to be, to a certain extent, agreed on and aware of its use as the primary dev management system. There's no point creating, hosting, updating and maintaining anything if the community isn't using it. Nope, that's not the way the world works. If you build it, they will come. You'll want to make the *community* aware of it, sure, but that's just to encourage people to use it. You don't need anything to be agreed upon, either people will use it, or they won't. If enough people use it that it becomes apparent that it's clearly better *then* you'll likely get a more buy-in and acceptance from developers. Until the developers are on-board you'll need to act as an intermediary (unless you can automate it) between the people using your system and the developers. That's more of your time, but if you're willing to spend it on this to prove it's a better way to work, then go for it. You're never going to get everyone to whole-sale jump over to a new system. It's just not going to happen. You need to build the basics and then get people to start using it. Eventually if it manages to get to a critical mass of some sort you'll get enough people using it that some of them may be willing to help maintain it- perhaps not even developers but other people who are willing to help with the interaction with the developers. You could always start by just doing the 'todo' list that Bruce has and maintaining it as a set of 'enhancements' in the system you build. That shouldn't even be very hard to keep up to date w/ Bruce's todo list provided you watch for his commits to it on the CVS mailing list. Then, if people decide to use your system to open up new enhancement requests you can forward them on to the appropriate list/people and if it makes it onto Bruce's 'todo' list then some how mark it as 'approved' or something to distinguish it from stuff that's been suggested/asked for that *doesn't* make it on the list (and thus is unlikely to be done or worked on). Having the list of stuff that didn't make it would actually be useful and is something Bruce's list misses and thus would be a valuable addition (imv) you would be providing. Now, generally the way this kind of stuff works is that someone gets bitten by a bug and just decides this would be useful and just *does* it w/o asking permission or getting approval from anyone. When people just ask permission or nebulously volunteer their time towards it, generally it *doesn't* happen. Just my 2c. Stephen signature.asc Description: Digital signature
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, May 17, 2005 at 06:25:16PM -0400, Alvaro Herrera wrote: On Wed, May 18, 2005 at 08:04:51AM +1000, Brendan Jurd wrote: On 5/18/05, Stephen Frost [EMAIL PROTECTED] wrote: * Brendan Jurd ([EMAIL PROTECTED]) wrote: In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system. If you're willing to create it, host it, update it and keep it current, and feel it'd be so worthwhile to people that you'd be willing to continue to maintain it... Then go for it. You don't need anyone's approval or even agreement about it. *That* would be putting your money where your mouth is. I'm detecting sarcasm here, but just in case you're being serious ... I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) The useful bug tracking systems I've used have also included QA. Any bug submitted doesn't get accepted without a standalone test case. That test case is used both to confirm that the bug has been fixed once it's fixed, and is added into a set of regression tests. If someone were to create test cases for (some or all of the) submitted bugs (or handle the management of their creation) and track which test cases passed (via a tinderbox, or even the existing build-farm) that'd be a useful thing in itself. I suspect it'd be a useful thing for someone who has energy to expend on bug-tracking to do, and probably more immediately useful than anything that requires all the primary developers to change how they're currently handling bugs and to-do lists. Just a thought. Cheers, Steve ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, May 17, 2005 at 03:30:28PM -0700, Joshua D. Drake wrote: I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) Well sorry but that is ridiculous. Either the community (or more specifically core) chooses to use it upfront or not. I think it is a complete waste of time and energy to expect someone to put in all that effort just to have the community give them the finger. This isn't something that is going to serve the person who loose all the sleep to configure and maintain it. It is something that is going to help the PostgreSQL community has a whole, to grow in a reasonably organized and hopefully less painful way. Maybe I didn't express myself properly. I didn't mean that Brendan should do all the work by himself -- but expecting the whole community, or the usual developers, to do the initial effort, is not likely to make this plane fly. Because the current developers are already comfortable with the current state of affairs, why should they worry about changing the process? This is something the rest of the people can do, for their own sake. It can, of course, serve the community eventually. Would you expect Bruce to enter each and every TODO item in a bug tracking system? I wouldn't. Would I register my own pet peeves in such a system? Probably I would. -- Alvaro Herrera (alvherre[a]surnet.cl) Los románticos son seres que mueren de deseos de vida ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
This isn't something that is going to serve the person who loose all the sleep to configure and maintain it. It is something that is going to help the PostgreSQL community has a whole, to grow in a reasonably organized and hopefully less painful way. Maybe I didn't express myself properly. I didn't mean that Brendan should do all the work by himself -- but expecting the whole community, or the usual developers, to do the initial effort, is not likely to make this plane fly. Because the current developers are already comfortable with the current state of affairs, why should they worry about changing the process? This is something the rest of the people can do, for their own sake. It can, of course, serve the community eventually. O.k. then I misunderstood and apologize. I think the above is reasonable. I wouldn't think that the main developers would stop developing to create this system, nor would I want them to take time away from development to implement it. I would however think that the main developer buy off would be essential. If the primary memebers of the development community said o.k. we are going to implement foo... who wants to spear head it? That would be a good thing. Would you expect Bruce to enter each and every TODO item in a bug tracking system? Well that depends... if it replaced the current TODO list as the definitive source then yes I would. I wouldn't. Would I register my own pet peeves in such a system? Probably I would. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, 18 May 2005 04:31 am, Josh Berkus wrote: Andrew, Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. Or whether to use one.Roughly 1/3 bugzilla, 1/3 something else, and 1/3 don't want a bugtracker. And, among the people who didn't want bugzilla, some were vehemently opposed to it. Bugtrackers discussed included GForge, bugzilla, RT, Roundup, Jura (they offered a free license) and a few I don't remember. Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. Doesn't pgfoundry offer this? If not in 3.3, I'm sure it's in Gforge 4.0, or 4.1 which will be released soon. Regards Russell ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On 5/18/05, Joshua D. Drake [EMAIL PROTECTED] wrote: O.k. then I misunderstood and apologize. I think the above is reasonable. I wouldn't think that the main developers would stop developing to create this system, nor would I want them to take time away from development to implement it. I think we can all agree on that. I would however think that the main developer buy off would be essential. Yep ... I get the feeling that in this community we have a handful of people doing the overwhelming majority of the development. Getting at least an in principle nod of the head from these people is a prerequisite for any major effort IMO. BJ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Russell Smith wrote: One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. Doesn't pgfoundry offer this? If not in 3.3, I'm sure it's in Gforge 4.0, or 4.1 which will be released soon. 3.3 does not - have not looked at 4.x. Unless it's gone through a radical upgrade I don't think it's good enough. A mail interface is only part of the story. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Brendan Jurd wrote: What's the basis of this objection to a web-based dev management system? Beyond the core developers want to stick to email, I think there is a good reason that we should stick primarily to email for project management: Bugzilla and similar systems are point to point, whereas a mailing list is multicast[1]. When someone submits a patch or a bug report to a mailing list, any of the developers can see the report, discuss it, and contribute to resolving it. More often than not, a web-based interface like Bugzilla leads to a single bug master, who does most of this work by themselves. Besides the fact we don't have such a person, it would also mean that knowledge of bugs/patches and the discussion about resolving issues is distributed among a smaller pool of people. There is definitely room for improvement; submitted patches do occasionally fall through the cracks, for example. I would personally be interested in a bug-tracking system that is closer to a shared email archive. Individuals would send mail to a mailing list and other people would reply and eventually resolve the thread, as happens now. The process would be slightly more formalized: there would be a way to specify a few commands via email to close/open/resolve/etc. reports, and some kind of interface (perhaps web-based) for viewing unresolved issues, searching through issues, etc. But the point is that the current system works well; this would just be a slight formalization of existing procedures (we don't *want* a revolutionary change, nor do we need one). I think the administrative overhead wouldn't be too high, either. I'm not sure which existing systems fit this model (suggestions are welcome) -- email needs to be the primary interface, not an afterthought (as is often the case). Perhaps RT would work, I'm not sure. -Neil [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point effectively. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
discuss it, and contribute to resolving it. More often than not, a web-based interface like Bugzilla leads to a single bug master, who does most of this work by themselves. Besides the fact we don't have such a person, it would also mean that knowledge of bugs/patches and the discussion about resolving issues is distributed among a smaller pool of people. I can only speak for RT but with RT you can easily avoid this. For example you can set it up so that anything that would go to [EMAIL PROTECTED] would automatically create a ticket an alert all people within the patches group. Multiple people can be assigned to a ticket as a maintainer or just a watcher. You can even respond to specific messages within the thread instead of just a top down (one email after the other). There is definitely room for improvement; submitted patches do occasionally fall through the cracks, for example. I would personally be interested in a bug-tracking system that is closer to a shared email archive. That would be another nice part of RT. RT automatically deals with attachments and although I wouldn't use it for this you could even use it as a semi patch repository until the patch is actually approved for submission. issues, searching through issues, etc. But the point is that the current system works well; Well does it though? I am not saying it is bad, well yes I am ;). There is no central place for me to point one of my developers and say -- Hey, look at this patch... weren't we working on something like this? Let's help them out. I have to have the dig through the mail archives which is fairly counter productive. It would be much better to be able to say, hey... look at patch #42345. What do you think? I'm not sure which existing systems fit this model (suggestions are welcome) -- email needs to be the primary interface, not an afterthought (as is often the case). Perhaps RT would work, I'm not sure. RT supports complete email integration. Most of the interaction I do with it is actually through email not through the web interface. It also has the ability to have a knowledge base dropped right on top of it. Sincerely, Joshua D. Drake -Neil [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point effectively. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Joshua D. Drake wrote: You can even respond to specific messages within the thread instead of just a top down (one email after the other). Well, that seems pretty fundamental... But the point is that the current system works well; Well does it though? I am not saying it is bad, well yes I am ;). There is no central place for me to point one of my developers and say -- Hey, look at this patch... weren't we working on something like this? Let's help them out. I'm not saying there is not room for improvement -- my point is that the fundamental workflow (email submission of patches, discussion and resolution via mailing list discussion) works well, and I don't see any need to change it. If there are tools that help us improve this process (e.g. archiving the resolution of old issues, as you suggest), they are worth considering. In other words, I'd like a tool that fits the way we work now, not one that forces us to change our processes to adapt to its requirements. Anyway, RT sounds like perhaps it is worth investigating. -Neil ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data. I 100% agree... There's also this: http://www.issue-tracker.com/ Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Neil Conway wrote: Joshua D. Drake wrote: You can even respond to specific messages within the thread instead of just a top down (one email after the other). Well, that seems pretty fundamental... But the point is that the current system works well; Well does it though? I am not saying it is bad, well yes I am ;). There is no central place for me to point one of my developers and say -- Hey, look at this patch... weren't we working on something like this? Let's help them out. I'm not saying there is not room for improvement -- my point is that the fundamental workflow (email submission of patches, discussion and resolution via mailing list discussion) works well, and I don't see any need to change it. If there are tools that help us improve this process (e.g. archiving the resolution of old issues, as you suggest), they are worth considering. In other words, I'd like a tool that fits the way we work now, not one that forces us to change our processes to adapt to its requirements. Agreed. Basically, there is the ideal world, where everything is organized around bug numbers, and there is a tracking system of who has reported the bugs and who fixed them, with a roadmap, and there is the real world, where such organization takes time, and takes time away from doing actual productive work. Now, you can argue that the time to do the maintenance of such a system will pay off, but it is far from clear that is true. No one has shown me a project that has such a system that works better than what we have now, nor a roadmap that is better than ours. If this new setup is so great, please point me to a real project that uses it effectively. The only two projects I have worked with in this area are Mozilla (bugzilla, terribly complex bug tracking and roadmap that drove them off the road), and gaim, which seems to work (sourceforge, everything gets put into a box of feature/bug, etc, and someone comes along and manages that). I don't think either are more effective than what we have now. What we have now is _bad_ for new people trying to jump in and figure things out --- that is the real problem with our current setup. You can't just point someone at bug number XXX. How much is that worth to us in terms of time? I am unsure. I imagine the Mozilla guys spending all day closing bugs and putting things in little boxes (oh, that bug is a duplicate), but the whole time the project is not user-focused and they get superceeded by Firefox because the new project actually gives users what they want. Do we really want people to fill out a bug form, and have us get an email and get an email and reply to the request and close the bug, rather than just email the guy to give them the fix? What does the big bug database actually do for us except give us a big list of thousands of items. I just don't see the huge value in tracking stuff for little payback. Sure, it sounds great, but in practice it seems pretty useless, and there is maintenance cost. -- 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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Neil Conway [EMAIL PROTECTED] writes: Beyond the core developers want to stick to email, I think there is a good reason that we should stick primarily to email for project management: Bugzilla and similar systems are point to point, whereas a mailing list is multicast[1]. That seems to me to be a great summary of the issue. I've been dealing with Bugzilla for a few years now in my employment with Red Hat, and I think the bottom line for that kind of system is that it's designed to limit the visibility of issues, rather than expose them. Now that is just exactly what you want for a corporate-sized bug tracking system --- at Red Hat, I do not want to hear about bugs in the kernel, or X, or a thousand other components that I have no expertise in --- but I cannot see that restricting the flow of information is what we need for Postgres. I think most of the real advantages of bug trackers that have been mentioned in this thread have to do with history and searchability. We have the raw info for that, in the pgsql-bugs and pgsql-commmitters mail archives, and so it seems to me that this reduces to the perennial gripe that we don't have good enough search tools for the archives. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Steve Atkins [EMAIL PROTECTED] writes: The useful bug tracking systems I've used have also included QA. Any bug submitted doesn't get accepted without a standalone test case. Side note: while test cases are certainly Good Things that make life easier for developers, so we should encourage people to provide 'em, I can't say that I like the idea of a tracking system designed around the concept that a bug for which you don't have a test case isn't real. It's not all that easy to make a test case for bugs involving concurrent behavior. I'd go so far as to say that most of the seriously interesting bugs that I've dealt with in this project were ones that the original reporter didn't have a reproducible test case for. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] writes: Beyond the core developers want to stick to email, I think there is a good reason that we should stick primarily to email for project management: Bugzilla and similar systems are point to point, whereas a mailing list is multicast[1]. That seems to me to be a great summary of the issue. I've been dealing with Bugzilla for a few years now in my employment with Red Hat, and I think the bottom line for that kind of system is that it's designed to limit the visibility of issues, rather than expose them. Now that is just exactly what you want for a corporate-sized bug tracking system --- at Red Hat, I do not want to hear about bugs in the kernel, or X, or a thousand other components that I have no expertise in --- but I cannot see that restricting the flow of information is what we need for Postgres. I think most of the real advantages of bug trackers that have been mentioned in this thread have to do with history and searchability. We have the raw info for that, in the pgsql-bugs and pgsql-commmitters mail archives, and so it seems to me that this reduces to the perennial gripe that we don't have good enough search tools for the archives. Good point, and I think the big criticism of our current system is that it is hard for someone to come in and see only a limited view of our issues. For example, if you only want to see ecpg issues, we don't make it very easy. This is the same issue Joshua Drake was mentioning, that there is no easy way to point someone at bug number XXX and assume they will have a full summary of the issue. -- 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Wed, May 18, 2005 at 12:07:14AM -0400, Tom Lane wrote: Steve Atkins [EMAIL PROTECTED] writes: The useful bug tracking systems I've used have also included QA. Any bug submitted doesn't get accepted without a standalone test case. Side note: while test cases are certainly Good Things that make life easier for developers, so we should encourage people to provide 'em, I can't say that I like the idea of a tracking system designed around the concept that a bug for which you don't have a test case isn't real. It's not all that easy to make a test case for bugs involving concurrent behavior. I'd go so far as to say that most of the seriously interesting bugs that I've dealt with in this project were ones that the original reporter didn't have a reproducible test case for. Depends on the context. For a code base like PGs (with, as you say, many possibilities for weird concurrency issues or data driven bugs), or for a development style like PGs (i.e. mostly volunteer), _requiring_ a test case before a bug is worked on makes no sense. Some environments I've worked in, though, have had a stage between bug submitted and bug passed to developer where someone in QA makes an attempt to create a test case where one was not submitted with the bug. That was more the idea I was suggesting as a possibility - if someone has a QA itch to scratch then trolling postgresql-bugs for bugs without test cases and creating recreatable test cases to attach to those bugs might be a useful thing to do. Cheers, Steve ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Steve Atkins [EMAIL PROTECTED] writes: On Wed, May 18, 2005 at 12:07:14AM -0400, Tom Lane wrote: It's not all that easy to make a test case for bugs involving concurrent behavior. I'd go so far as to say that most of the seriously interesting bugs that I've dealt with in this project were ones that the original reporter didn't have a reproducible test case for. ... Some environments I've worked in, though, have had a stage between bug submitted and bug passed to developer where someone in QA makes an attempt to create a test case where one was not submitted with the bug. That was more the idea I was suggesting as a possibility - if someone has a QA itch to scratch then trolling postgresql-bugs for bugs without test cases and creating recreatable test cases to attach to those bugs might be a useful thing to do. It's absolutely useful --- in fact, creating a case that fails at least once-in-a-while is normally the first thing that a developer will try to do when faced with this sort of report. But that effort doesn't always require intimacy with the code, so farming it out is not a bad idea for spreading the work around. This certainly ties in with the recent discussions about how can you contribute when you haven't already learned all of the code base ... but to bring it back to the immediate topic, would a bugzilla or RT system really help compared to our existing mailing-list system? I've noticed Michael Fuhr and some other folk doing the confirm-bug- and-provide-test-cases spadework recently, so it seems like this is already something we can handle. What it comes down to is that a mailing list encourages many-eyes-on- one-bug synergy, whereas Bugzilla is designed to send a bug report to just one pair of eyes, or at most a small number of eyes. I haven't used RT but I doubt it's fundamentally different. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Learning curves and such (was Re: [HACKERS] pgFoundry)
Lamar Owen [EMAIL PROTECTED] writes: To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, The backend hacking curve is certainly steep, but I wonder whether the problem isn't largely one of people biting off more than they can chew. I got my start by hacking some things in libpq, which is way more self-contained than any aspect of the backend; and then started hacking relatively small backend stuff. I think the reason I know as much as I do today is that I've always been willing to investigate minor bugs. No one of them was all *that* exciting, but over time I've had the opportunity to study a lot of the backend code. Nearby you can watch Neil Conway bootstrapping himself by doing minor code beautification projects --- again not that exciting in itself, but useful, and in any case the *real* reason he's doing it is to learn the backend code in general. (Right, Neil?) As against that I notice some new arrivals proposing to add deductive reasoning to Postgres: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php or implement SQL99 hierarchical queries: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I might be wrong, but I'll bet lunch that neither of those projects will come to anything. You can't run before you learn to crawl. Maybe what we need is some documentation about how to get started as a Postgres hacker --- what to read, what sort of things to tackle for your first hack, etc. I think the people who have been successful around here are the ones who have managed to figure out the syllabus by themselves ... but surely we could try to teach those who come after. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
Lamar, To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. wince -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tue, May 17, 2005 at 01:32:03AM -0400, Tom Lane wrote: Maybe what we need is some documentation about how to get started as a Postgres hacker --- what to read, what sort of things to tackle for your first hack, etc. I think the people who have been successful around here are the ones who have managed to figure out the syllabus by themselves ... but surely we could try to teach those who come after. Didn't such a document exist at one point? I seem to remember reading about it on the old website... I think it might also be valuable to have a list of things that are good 'starter projects'. Maybe some indication of TODO items that are simpler. Possibly a list of bugs, too. It would probably also be useful to point out ways people can help that don't involve hacking C code (or at least not much). Things like docs, the website, advocacy, performance testing, etc. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
