Thread: 8.2 features status
I'm not clear on why there's all this doom and gloom about how 8.2 will be "merely" a performance-oriented release, with few new features, eg http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php Certainly there's been a ton of effort spent on high-end performance issues. But a quick troll through the CVS logs shows a fair number of features that could be considered killer must-have things by their respective target audiences: multi-row VALUES, not only for INSERT but everywhere SELECT is allowed pg_dump multiple -n and -t options, regex patterns for object names multi-argument aggregates, including SQL2003-standard statistical aggregates fully configurable timezone abbreviations (no more 'australian_timezones' hack) allow full zic timezone names in datetime input values support comparisons like "if row(new.*) is distinct from row(old.*)" DROP ... IF EXISTS numerous tsearch2 improvements, eg thesaurus GIN index opclass GRANT CONNECT ON DATABASE support SSL Certificate Revocation List (CRL) files plpython supports named parameters, composite-type results, more result-set options plperl prepared queries domain constraint checks are now applied everywhere better psql multiline command handling error cursor position displayed for many parse-analysis errors standard_conforming_strings can be turned on (HUGE deal for some people) initdb and pg_ctl can safely start from an admin account on Windows display multiline values nicely in psql support SQL-compliant row comparisons; they can be indexscan quals DROP OWNED, REASSIGN OWNED for dealing with removal of a user null elements in arrays There are also some commits that are "mere" performance tweaks, and yet we should not understate their importance because they could make the difference between usability and non-usability in many applications: lazy vacuums are ignored by other processes; improves behavior of concurrent vacuums add index and table storage options (currently only FILLFACTOR) stats_command_string overhead reduced to near zero, now on by default reduce locking involved in DATABASE commands, eg CREATE DATABASE no longer blocks incoming connections constraint exclusion works for UPDATE and DELETE constraint exclusion works for UNION ALL views, not only inheritance trees planner can rearrange join order for many common OUTER JOIN scenarios And that's not counting some pretty significant submitted-but-not-yet- reviewed patches (sure, some of these may get rejected, but they're all open possibilities today): online index builds bitmap index AM updatable views PL plugin patch (plpgsql debugger infrastructure) restartable recovery (allow checkpoints for a hot-standby server) INSERT/UPDATE RETURNING Not that there's anything wrong with a performance-oriented release ... but if you think that 8.2 is short on features, you'd better get ready to be disappointed by every future release. There's not all that much stuff left to do in terms of raw language "features". (Of course the SQL committee keeps inventing a ton of new stuff every few years, but how much of that do you really care about?) regards, tom lane
My outlook is that it isn't a lot of _new_ things that you couldn't do before, but rather improvements of existing functionality. --------------------------------------------------------------------------- Tom Lane wrote: > I'm not clear on why there's all this doom and gloom about how 8.2 will > be "merely" a performance-oriented release, with few new features, eg > http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php > > Certainly there's been a ton of effort spent on high-end performance > issues. But a quick troll through the CVS logs shows a fair number of > features that could be considered killer must-have things by their > respective target audiences: > > multi-row VALUES, not only for INSERT but everywhere SELECT is allowed > pg_dump multiple -n and -t options, regex patterns for object names > multi-argument aggregates, including SQL2003-standard statistical aggregates > fully configurable timezone abbreviations (no more 'australian_timezones' hack) > allow full zic timezone names in datetime input values > support comparisons like "if row(new.*) is distinct from row(old.*)" > DROP ... IF EXISTS > numerous tsearch2 improvements, eg thesaurus > GIN index opclass > GRANT CONNECT ON DATABASE > support SSL Certificate Revocation List (CRL) files > plpython supports named parameters, composite-type results, more result-set options > plperl prepared queries > domain constraint checks are now applied everywhere > better psql multiline command handling > error cursor position displayed for many parse-analysis errors > standard_conforming_strings can be turned on (HUGE deal for some people) > initdb and pg_ctl can safely start from an admin account on Windows > display multiline values nicely in psql > support SQL-compliant row comparisons; they can be indexscan quals > DROP OWNED, REASSIGN OWNED for dealing with removal of a user > null elements in arrays > > There are also some commits that are "mere" performance tweaks, and yet > we should not understate their importance because they could make the > difference between usability and non-usability in many applications: > > lazy vacuums are ignored by other processes; improves behavior of concurrent vacuums > add index and table storage options (currently only FILLFACTOR) > stats_command_string overhead reduced to near zero, now on by default > reduce locking involved in DATABASE commands, eg CREATE DATABASE no longer blocks incoming connections > constraint exclusion works for UPDATE and DELETE > constraint exclusion works for UNION ALL views, not only inheritance trees > planner can rearrange join order for many common OUTER JOIN scenarios > > And that's not counting some pretty significant submitted-but-not-yet- > reviewed patches (sure, some of these may get rejected, but they're all > open possibilities today): > > online index builds > bitmap index AM > updatable views > PL plugin patch (plpgsql debugger infrastructure) > restartable recovery (allow checkpoints for a hot-standby server) > INSERT/UPDATE RETURNING > > Not that there's anything wrong with a performance-oriented release > ... but if you think that 8.2 is short on features, you'd better get > ready to be disappointed by every future release. There's not all > that much stuff left to do in terms of raw language "features". > (Of course the SQL committee keeps inventing a ton of new stuff every > few years, but how much of that do you really care about?) > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, 4 Aug 2006, Bruce Momjian wrote: > > My outlook is that it isn't a lot of _new_ things that you couldn't do > before, but rather improvements of existing functionality. It seems as though the majority of things on Tom's list are new things you couldn't do (at all easily) before. Gavin
Gavin Sherry wrote: > On Fri, 4 Aug 2006, Bruce Momjian wrote: > > > > > My outlook is that it isn't a lot of _new_ things that you couldn't do > > before, but rather improvements of existing functionality. > > It seems as though the majority of things on Tom's list are new things you > couldn't do (at all easily) before. To me new things are like PITR, Win32, savepoints, two-phase commit, partitioned tables, tablespaces. These are from 8.0 and 8.1. What is there in 8.2 like that? -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, 4 Aug 2006, Bruce Momjian wrote: > Gavin Sherry wrote: > > On Fri, 4 Aug 2006, Bruce Momjian wrote: > > > > > > > > My outlook is that it isn't a lot of _new_ things that you couldn't do > > > before, but rather improvements of existing functionality. > > > > It seems as though the majority of things on Tom's list are new things you > > couldn't do (at all easily) before. > > To me new things are like PITR, Win32, savepoints, two-phase commit, > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > there in 8.2 like that? Well, GIN and some of the unreviewed stuff (bitmaps, plpgsql debugger, updateable views) are in the same league as the stuff in 8.0 in terms of user demand and catching up with competitors, I think. A lot of the things on Tom's list are new bits of functionality to things added around 8.0 and 8.1 (major enhancements to the usability of constraint exclusion, for example). We knew then that these needed additional functionality to fill them out and make them useful to a wide range of people. Ideally we'd have both at each release but reality doesn't work like that. Thanks, Gavin
Gavin Sherry wrote: > On Fri, 4 Aug 2006, Bruce Momjian wrote: > > > Gavin Sherry wrote: > > > On Fri, 4 Aug 2006, Bruce Momjian wrote: > > > > > > > > > > > My outlook is that it isn't a lot of _new_ things that you couldn't do > > > > before, but rather improvements of existing functionality. > > > > > > It seems as though the majority of things on Tom's list are new things you > > > couldn't do (at all easily) before. > > > > To me new things are like PITR, Win32, savepoints, two-phase commit, > > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > > there in 8.2 like that? > > Well, GIN and some of the unreviewed stuff (bitmaps, plpgsql debugger, > updateable views) are in the same league as the stuff in 8.0 in terms of > user demand and catching up with competitors, I think. > > A lot of the things on Tom's list are new bits of functionality to things > added around 8.0 and 8.1 (major enhancements to the usability of > constraint exclusion, for example). We knew then that these needed > additional functionality to fill them out and make them useful to a wide > range of people. Ideally we'd have both at each release but reality > doesn't work like that. Yes, that is my point. It is a "usability" release. Nothing wrong with that. In fact, some people asked me if we were still doing things for ordinary users rather than just doing enterprise functionality. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian <bruce@momjian.us> writes:
> To me new things are like PITR, Win32, savepoints, two-phase commit,
> partitioned tables, tablespaces. These are from 8.0 and 8.1. What is
> there in 8.2 like that?
[ shrug... ] Five out of your six items have no basis in the SQL spec.
So it's not clear to me what your definition of "major feature" is,
unless maybe it's "anything except what we did for 8.2". Can you
enumerate ten things you would consider comparable to the above features
that aren't done yet?
regards, tom lane
Bruce Momjian wrote: > Gavin Sherry wrote: >> On Fri, 4 Aug 2006, Bruce Momjian wrote: >> >>> My outlook is that it isn't a lot of _new_ things that you couldn't do >>> before, but rather improvements of existing functionality. >> It seems as though the majority of things on Tom's list are new things you >> couldn't do (at all easily) before. > > To me new things are like PITR, Win32, savepoints, two-phase commit, > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > there in 8.2 like that? Well to be honest, the things that are coming in 8.2 more people will use then any of the things you just mentioned. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > To me new things are like PITR, Win32, savepoints, two-phase commit, > > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > > there in 8.2 like that? > > [ shrug... ] Five out of your six items have no basis in the SQL spec. > So it's not clear to me what your definition of "major feature" is, > unless maybe it's "anything except what we did for 8.2". Can you > enumerate ten things you would consider comparable to the above features > that aren't done yet? No, I cannot. I do think our missing list is shrinking. My point is that you really couldn't easily work around the 8.0/8.1 items I listed if they were missing, while the 8.2 items could be more easily worked-around. Again, nothing wrong with that. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > Bruce Momjian wrote: > > Gavin Sherry wrote: > >> On Fri, 4 Aug 2006, Bruce Momjian wrote: > >> > >>> My outlook is that it isn't a lot of _new_ things that you couldn't do > >>> before, but rather improvements of existing functionality. > >> It seems as though the majority of things on Tom's list are new things you > >> couldn't do (at all easily) before. > > > > To me new things are like PITR, Win32, savepoints, two-phase commit, > > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > > there in 8.2 like that? > > Well to be honest, the things that are coming in 8.2 more people will > use then any of the things you just mentioned. Right, hence "usability", not "new enterprise features". -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>>> It seems as though the majority of things on Tom's list are new things you >>>> couldn't do (at all easily) before. >>> To me new things are like PITR, Win32, savepoints, two-phase commit, >>> partitioned tables, tablespaces. These are from 8.0 and 8.1. What is >>> there in 8.2 like that? >> Well to be honest, the things that are coming in 8.2 more people will >> use then any of the things you just mentioned. > > Right, hence "usability", not "new enterprise features". O.k. I buy that. Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
+1 UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then we'd be able to claim "complete" support for partitioning, but this is a big deal improvement. - Luke On 8/3/06 9:30 PM, "Gavin Sherry" <swm@linuxworld.com.au> wrote: > A lot of the things on Tom's list are new bits of functionality to things > added around 8.0 and 8.1 (major enhancements to the usability of > constraint exclusion, for example).
On Fri, Aug 04, 2006 at 12:37:10AM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > To me new things are like PITR, Win32, savepoints, two-phase > > commit, partitioned tables, tablespaces. These are from 8.0 and > > 8.1. What is there in 8.2 like that? > > [ shrug... ] Five out of your six items have no basis in the SQL > spec. So it's not clear to me what your definition of "major > feature" is, unless maybe it's "anything except what we did for > 8.2". Can you enumerate ten things you would consider comparable to > the above features that aren't done yet? First, I'd like to say people are doing a fantastic job here. Kudos! One huge thing missing from the "done" list is that crucial bit of infrastructure and process that has shortened feedback loops--hence the beta period--by weeks if not months: the build farm. It's now smoothly integrated into the development process, and as a consequence, we can realistically have a release each year. :) As far as big missing features go, here's a short list: * Splitting queries among CPUs--possibly even among machines--for OLAP loads * In-place upgrades (pg_upgrade) * Several varieties of replication, which I believe we as a project will eventually endorse and ship * CALL * WITH RECURSIVE * MERGE * Windowing functions * On-the-fly in-line calls out to PL/your_choice without needing to issue DDL * Wild-eyed feral bits of the SQL standard like SQL/MED and SQL/XML But all that leaves out the oldest, most honored Postgres tradition: Breaking New Ground. We're definitely not done yet. :) Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Ühel kenal päeval, R, 2006-08-04 kell 00:46, kirjutas Bruce Momjian: > Tom Lane wrote: > > Bruce Momjian <bruce@momjian.us> writes: > > > To me new things are like PITR, Win32, savepoints, two-phase commit, > > > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > > > there in 8.2 like that? > > > > [ shrug... ] Five out of your six items have no basis in the SQL spec. > > So it's not clear to me what your definition of "major feature" is, > > unless maybe it's "anything except what we did for 8.2". Can you > > enumerate ten things you would consider comparable to the above features > > that aren't done yet? > > No, I cannot. I do think our missing list is shrinking. My point is > that you really couldn't easily work around the 8.0/8.1 items I listed > if they were missing, while the 8.2 items could be more easily > worked-around. The workaround for missing concurrent vacuum was to design your databases so the your small and large OLTP tables are on different servers or that you keep a replica and vacuum your large tables there and then switch over to it. It is debatable if that qualifies as "more easily worked-around" The workaround for pl/python not allowing returning records and sets was to write an actual pl/python function to generate the data and to store it in global ditionary GD, a set of pl/python data retrieval functions for each postgresql data type used and a wrapper function in pl/pgsql to call the real function and then return the the data records using the data retrieval functions. May be simple, but a real PITA to do for more than one function. I guess some other new features that were missing before were as easy to work around :) > Again, nothing wrong with that. Sure. Actually I think that people were able to work around missing features in 8.0/8.1 as well. The proof being, that people *did* actually use postgresql before 8.x , some even on win32 ;) -- ---------------- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com
David, On 8/3/06 11:02 PM, "David Fetter" <david@fetter.org> wrote: > * Splitting queries among CPUs--possibly even among machines--for OLAP > loads > > * In-place upgrades (pg_upgrade) > > * Several varieties of replication, which I believe we as a project > will eventually endorse and ship > > * CALL > > * WITH RECURSIVE > > * MERGE > > * Windowing functions > > * On-the-fly in-line calls out to PL/your_choice without needing to > issue DDL My ordering of this list in terms of priority is: 1) Windowing functions 2) MERGE 3) Index only access (new) 4) In-place upgrades We already have splitting queries among CPUs and machines. - Luke
All, <grin> Aren't I, the marketing geek, supposed to be the one whining about this? Seriously, PostgreSQL has the fastest release cycle of any RDBMS project in the world. The request I'm hearing from large production users is to release *less* often. So I don't find it a problem that this release has less "checklist" features than the last two did, and I don't think anyone else will. If all the pending features die then I might find it a stretch to write the press release, but otherwise, no problem. And since when were we a marketing-driven project anyway? > * In-place upgrades (pg_upgrade) BTW, I may get Sun to contribute an engineer for this; will get you posted. Oh, and if it makes it, Tzadhi's FULL DISJUNCTIONS patch is newsworthy. -- Josh Berkus PostgreSQL @ Sun San Francisco
David Fetter skrev: > As far as big missing features go, here's a short list: > > * Windowing functions If we are to wish for things the window functions and a proper collation/locale support is what I miss the most. /Dennis
On Fri, Aug 04, 2006 at 08:27:02AM +0200, Dennis Bjorklund wrote: > If we are to wish for things the window functions and a proper > collation/locale support is what I miss the most. Agreed. The complaints about collation/locale support have been continuous over the years, and it really is quite irritating in certain situations. I got the COLLATE support as far as grammer and executor support but got stuck on the planning and optimiser. Maybe one day I'll get the time to really finish it off properly... (if anyone else wants to have a shot, go for it). One downside of a fast release cycle: fast tree drift :) But I guess you can't really complain about that. Oh yeah, user-defined typmod would be cool. There's some movement on that though. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Bruce Momjian wrote: > > Right, hence "usability", not "new enterprise features". > I'm not too happy about the label "usability". "Ok, maybe postgres gets usable finally by supporting features that MySQL had for a long time...." a MySql guy would say. Regards, Andreas
On 04/08/06, Andreas Pflug <pgadmin@pse-consulting.de> wrote: > Bruce Momjian wrote: > > > > Right, hence "usability", not "new enterprise features". > > > I'm not too happy about the label "usability". > > "Ok, maybe postgres gets usable finally by supporting features that > MySQL had for a long time...." a MySql guy would say. I have the same feeling about the term "usability". It could be interpreted like : PostgreSQL was not usable until now. Best wishes, Adrian Maier
On 8/4/06, Luke Lonergan <llonergan@greenplum.com> wrote: > My ordering of this list in terms of priority is: > > 1) Windowing functions > 2) MERGE > 3) Index only access (new) > 4) In-place upgrades And what about compression of on-disk sorting? There has been a long thread about this idea. Is there any news about this feature? IIRC Jim Nasby and Martijn were working on testing that and on validating it was interesting for most of the cases. -- Guillaume
Tom Lane wrote: >Not that there's anything wrong with a performance-oriented release >... but if you think that 8.2 is short on features, you'd better get >ready to be disappointed by every future release. > It's a pity that some expectations have been raised about features that we haven't seen patches for, e.g. MERGE and/or some form of UPSERT, and recursive queries. I am not pointing fingers, but I do think we need some way in which the community can ensure that certain goals are met, or at least try to help if things fall in a ditch, rather than just relying on hackers scratching whatever itch they happen to get in splendid isolation and then trying to merge the results. cheers andrew
Josh Berkus wrote: >Oh, and if it makes it, Tzadhi's FULL DISJUNCTIONS patch is newsworthy. > > > Have we seen a patch for this? I don't recall seeing one. If not it had better get in damn fast, I guess. cheers andrew
On Friday 04 August 2006 02:20, Josh Berkus wrote:
> Seriously, PostgreSQL has the fastest release cycle of any RDBMS project in
> the world. The request I'm hearing from large production users is to
> release *less* often. So I don't find it a problem that this release has
> less "checklist" features than the last two did, and I don't think anyone
> else will.
>
Yes... one idea I have seen floated is that every other release should work
within the constraints of not requireing dump/reload, so that the really
nasty upgrade cycles could be spread out 2 years apart, but people could get
new features / imporvements each year if they wanted to. It sounds like a
good idea in theory, but would take some real world wrangling to achieve it.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote: > Have we seen a patch for this? I don't recall seeing one. If not it had > better get in damn fast, I guess. Yes, it was submitted the day before freeze. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Jonah H. Harris wrote: > On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote: > >> Have we seen a patch for this? I don't recall seeing one. If not it had >> better get in damn fast, I guess. > > > Yes, it was submitted the day before freeze. > Ah. good. Probably was when my mail was down for about 12 hours around then :-( cheers andrew
On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote: > It's a pity that some expectations have been raised about features that > we haven't seen patches for, MERGE/UPSERT & recursive queries Honestly, I've only had four people say it would be nice to have hierarchical queries (one of them wasn't even a PostgreSQL user). Almost everyone else seems to ask some variation of, "what's a hierarchical query and why do I need it?" It's hard to get excited about writing a patch no one sees a real need for. When I have a choice of working on things in my spare time, I choose what to work on based on basically two things (a) what is my interest in it and (b) who is going to use it. Based on that, I determine whether it's worth going through the hassle of design, development, testing, and final documentation (my prelim docs come from design). In short, I know a lot of people would probably use this feature after it was there, but *very* few have shown any interest in it and a patch for it (while in need of rewriting) has existed since 7.4. > I am not pointing fingers, but I do think we need > some way in which the community can ensure > that certain goals are met, or at least try to help > if things fall in a ditch, rather than just relying on > hackers scratching whatever itch they happen to > get in splendid isolation and then trying to merge > the results. I agree. The real problem is that we don't look at things in a business-like, "what are we going to have in the next release" perspective. Being as it's an OSS community, we just see what patches come in and we apply what we choose... then pick which ones we see as "major features" and announce them. I'd like to be mistaken here, but I don't think we've ever really had release planning in regards to features. We can always sit down after 8.2 is finalized and plan what are we doing for 8.3 and go from there. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Jonah H. Harris wrote: > On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote: > >> It's a pity that some expectations have been raised about features that >> we haven't seen patches for, MERGE/UPSERT & recursive queries > > > Honestly, I've only had four people say it would be nice to have > hierarchical queries (one of them wasn't even a PostgreSQL user). > Almost everyone else seems to ask some variation of, "what's a > hierarchical query and why do I need it?" It's hard to get excited > about writing a patch no one sees a real need for. > > When I have a choice of working on things in my spare time, I choose > what to work on based on basically two things (a) what is my interest > in it and (b) who is going to use it. Based on that, I determine > whether it's worth going through the hassle of design, development, > testing, and final documentation (my prelim docs come from design). > > In short, I know a lot of people would probably use this feature after > it was there, but *very* few have shown any interest in it and a patch > for it (while in need of rewriting) has existed since 7.4. > Chicken vs. egg. Look at the number of people using nested sets and other similar abominations to handle hierarchical data. There are whole books written about using these kludgy techniques. I think this really is a case of "build it and they will come". cheers andrew
On 8/3/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm not clear on why there's all this doom and gloom about how 8.2 will > be "merely" a performance-oriented release, with few new features, eg > http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php > > Certainly there's been a ton of effort spent on high-end performance > issues. But a quick troll through the CVS logs shows a fair number of > features that could be considered killer must-have things by their > respective target audiences: i can't resist this unproductive distraction from actual work. this is a huge release for me as it nails a lot of the features i've been waiting literally years for. it feels a lot like the 7.4 release where similar debates when on esp. regarding the windows port, etc. note that even if the release had no user level features at all, it would be better to release: the outside world likes to see the project is still active and moving forward. merlin
Luke Lonergan wrote: > +1 > > UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, then > we'd be able to claim "complete" support for partitioning, but this is a big > deal improvement. I haven't be following this but.. does the above mean that if CE is turned on and they are partitioned tables, I don't have to use a trigger for update/delete operations? Joshua D. Drake > > - Luke > > > On 8/3/06 9:30 PM, "Gavin Sherry" <swm@linuxworld.com.au> wrote: > >> A lot of the things on Tom's list are new bits of functionality to things >> added around 8.0 and 8.1 (major enhancements to the usability of >> constraint exclusion, for example). > > > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
> * Several varieties of replication, which I believe we as a project > will eventually endorse and ship This one will cause confusion regardless of how much advocacy, documentation and will power we put into it. > * On-the-fly in-line calls out to PL/your_choice without needing to > issue DDL You mean something like: EXEC plperl(print $foo)? Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
> 3) Index only access (new) Does this mean, I have hit the index and have the actual tuple data in the index row? So I don't have to go back to the relation to get the info? Joshua D. Drake > We already have splitting queries among CPUs and machines. Yes, YOU do. We don't. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Andreas Pflug wrote: > Bruce Momjian wrote: >> Right, hence "usability", not "new enterprise features". >> > I'm not too happy about the label "usability". > > "Ok, maybe postgres gets usable finally by supporting features that > MySQL had for a long time...." a MySql guy would say. Good point... What about "refinement" Joshua D. Drake > > Regards, > Andreas > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Fri, Aug 04, 2006 at 09:37:32AM -0400, Jonah H. Harris wrote: > I agree. The real problem is that we don't look at things in a > business-like, "what are we going to have in the next release" > perspective. Being as it's an OSS community, we just see what patches > come in and we apply what we choose... then pick which ones we see as > "major features" and announce them. There's a fairly standard way of getting people to do things for you: pay them money. Thing is, people can run around making lists of thing that would be cool, but no-one can really force anyone to do anything. Now, there are the priveledged few who are being paid to work on postgres. If you can convince their employers to fund things on the list, it might help. Also, some stuff might work well as Google SoC projects... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Jonah H. Harris wrote: > On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote: >> It's a pity that some expectations have been raised about features that >> we haven't seen patches for, MERGE/UPSERT & recursive queries > > Honestly, I've only had four people say it would be nice to have > hierarchical queries (one of them wasn't even a PostgreSQL user). You obviously aren't dealing with the number of people I am :) I get this question all the time. > I agree. The real problem is that we don't look at things in a > business-like, "what are we going to have in the next release" > perspective. Being as it's an OSS community, we just see what patches > come in and we apply what we choose... then pick which ones we see as > "major features" and announce them. > > I'd like to be mistaken here, but I don't think we've ever really had > release planning in regards to features. We can always sit down after > 8.2 is finalized and plan what are we doing for 8.3 and go from there. The only way we will get even a reasonable about of release planning is for the commercial entities involved around PostgreSQL to put a lot more resources into actually developing PostgreSQL. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Josh, On 8/4/06 7:47 AM, "Joshua D. Drake" <jd@commandprompt.com> wrote: >> 3) Index only access (new) > > Does this mean, I have hit the index and have the actual tuple data in > the index row? So I don't have to go back to the relation to get the info? Yep. Fix the visibility issue - there are a number of good ideas on how to do it, we are in a position to bang it out now IMO. >> We already have splitting queries among CPUs and machines. > > Yes, YOU do. We don't. Details, details - redefine "We" and it's the same thing. - Luke
On Friday 04 August 2006 09:37, Jonah H. Harris wrote: > On 8/4/06, Andrew Dunstan <andrew@dunslane.net> wrote: > > It's a pity that some expectations have been raised about features that > > we haven't seen patches for, MERGE/UPSERT & recursive queries > > Honestly, I've only had four people say it would be nice to have > hierarchical queries (one of them wasn't even a PostgreSQL user). > Almost everyone else seems to ask some variation of, "what's a > hierarchical query and why do I need it?" It's hard to get excited > about writing a patch no one sees a real need for. Make that five. I'll bless the day I can get rid of my recursive plsql functions. jan -- -------------------------------------------------------------- Jan de Visser jdevisser@digitalfairway.com Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
Adrian Maier wrote: > On 04/08/06, Andreas Pflug <pgadmin@pse-consulting.de> wrote: > > Bruce Momjian wrote: > > > > > > Right, hence "usability", not "new enterprise features". > > > > > I'm not too happy about the label "usability". > > > > "Ok, maybe postgres gets usable finally by supporting features that > > MySQL had for a long time...." a MySql guy would say. > > I have the same feeling about the term "usability". It could > be interpreted like : PostgreSQL was not usable until now. _improved_ usability -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>> "Ok, maybe postgres gets usable finally by supporting features that >>> MySQL had for a long time...." a MySql guy would say. >> I have the same feeling about the term "usability". It could >> be interpreted like : PostgreSQL was not usable until now. > > _improved_ usability I still don't like it. Usability is an opinion based thing. Personally I find MySQL confusing and illogical. However I know many people love it for that very same reason. I think we should drop the term usability as a selling part of the PR and push it into further description.. Instead we should use a slightly more expensive word (think 50 cents, not 5). :) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Andrew Dunstan wrote: > > > Tom Lane wrote: > > >Not that there's anything wrong with a performance-oriented release > >... but if you think that 8.2 is short on features, you'd better get > >ready to be disappointed by every future release. > > > > It's a pity that some expectations have been raised about features that > we haven't seen patches for, e.g. MERGE and/or some form of UPSERT, and > recursive queries. I am not pointing fingers, but I do think we need > some way in which the community can ensure that certain goals are met, > or at least try to help if things fall in a ditch, rather than just > relying on hackers scratching whatever itch they happen to get in > splendid isolation and then trying to merge the results. What we do is when people claim items, we monitor them to be sure they get them done for the current release, or at least give it their best try. There is not much more we can do. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > > >>> "Ok, maybe postgres gets usable finally by supporting features that > >>> MySQL had for a long time...." a MySql guy would say. > >> I have the same feeling about the term "usability". It could > >> be interpreted like : PostgreSQL was not usable until now. > > > > _improved_ usability > > I still don't like it. Usability is an opinion based thing. Personally I > find MySQL confusing and illogical. However I know many people love it > for that very same reason. > > I think we should drop the term usability as a selling part of the PR > and push it into further description.. Instead we should use a slightly > more expensive word (think 50 cents, not 5). :) Fine, I am all ears. Also, a lot of people are thinking usability improvements aren't a big item, but they are. I had a press person ask during the 8.0 release, "You have a lot of large features in 8.0, but what is there for the ordinary database user?". At that time all we had was COPY CSV. This release will have a lot of those usability improvements. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>> I think we should drop the term usability as a selling part of the PR >> and push it into further description.. Instead we should use a slightly >> more expensive word (think 50 cents, not 5). :) > > Fine, I am all ears. Also, a lot of people are thinking usability > improvements aren't a big item, but they are. I had a press person ask > during the 8.0 release, "You have a lot of large features in 8.0, but > what is there for the ordinary database user?". At that time all we had > was COPY CSV. This release will have a lot of those usability > improvements. I don't disagree with your thought process and I full agree :). I am just saying we should spice it up a bit :) Hmmmm.... PostgreSQL has showed an unprecedented commitment to all skill levels of database developers. With the release of 8.2 the group has focused on refinement and usability. Features such as ... add to the already impressive list of enterprise class features such as ... Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > > >> I think we should drop the term usability as a selling part of the PR > >> and push it into further description.. Instead we should use a slightly > >> more expensive word (think 50 cents, not 5). :) > > > > Fine, I am all ears. Also, a lot of people are thinking usability > > improvements aren't a big item, but they are. I had a press person ask > > during the 8.0 release, "You have a lot of large features in 8.0, but > > what is there for the ordinary database user?". At that time all we had > > was COPY CSV. This release will have a lot of those usability > > improvements. > > I don't disagree with your thought process and I full agree :). I am > just saying we should spice it up a bit :) > > Hmmmm.... > > PostgreSQL has showed an unprecedented commitment to all skill levels of > database developers. With the release of 8.2 the group has focused on > refinement and usability. Features such as ... add to the already > impressive list of enterprise class features such as ... Sounds very good, and that was my goal, that we get a "focus" idea for the release, I think that is it. As I remember, 8.0 was enterprise features, and 8.1 was performance. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Merlin Moncure wrote: > On 8/3/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I'm not clear on why there's all this doom and gloom about how 8.2 will >> be "merely" a performance-oriented release, with few new features, eg >> http://archives.postgresql.org/pgsql-hackers/2006-07/msg00111.php >> >> Certainly there's been a ton of effort spent on high-end performance >> issues. But a quick troll through the CVS logs shows a fair number of >> features that could be considered killer must-have things by their >> respective target audiences: > > i can't resist this unproductive distraction from actual work. this > is a huge release for me as it nails a lot of the features i've been > waiting literally years for. it feels a lot like the 7.4 release > where similar debates when on esp. regarding the windows port, etc. > > note that even if the release had no user level features at all, it > would be better to release: the outside world likes to see the project > is still active and moving forward. I fully agree here - 8.2 is a release that is of more interest to us than say 8.0 was. For some of our existing apps 8.2 is dramatically faster due to much better planed queries and things like 20-25% faster dump/restore cycles due to the dramatic improvements on sorting (and therefor CREATE INDEX) are really really cool things. Just switching to 8.2 makes one of our (interactive-web) app feel "blazingly fast" instead of just "ok" and that is a good thing - a very good one in fact ... And beside that the list tom posted is already damn impressive on it's own - i guess there are a number of large projects that can only dream of having a "new features" list like that. Stefan
Bruce Momjian wrote: > Joshua D. Drake wrote: >>>> I think we should drop the term usability as a selling part of the PR >>>> and push it into further description.. Instead we should use a slightly >>>> more expensive word (think 50 cents, not 5). :) >>> Fine, I am all ears. Also, a lot of people are thinking usability >>> improvements aren't a big item, but they are. I had a press person ask >>> during the 8.0 release, "You have a lot of large features in 8.0, but >>> what is there for the ordinary database user?". At that time all we had >>> was COPY CSV. This release will have a lot of those usability >>> improvements. >> I don't disagree with your thought process and I full agree :). I am >> just saying we should spice it up a bit :) >> >> Hmmmm.... >> >> PostgreSQL has showed an unprecedented commitment to all skill levels of >> database developers. With the release of 8.2 the group has focused on >> refinement and usability. Features such as ... add to the already >> impressive list of enterprise class features such as ... > > Sounds very good, and that was my goal, that we get a "focus" idea for > the release, I think that is it. As I remember, 8.0 was enterprise > features, and 8.1 was performance. > Quick reword: With the release of 8.2, PostgreSQL has shown an unprecedented commitment to all skill levels of database developers. The 8.2 version of PostgreSQL has focused on refinement and usability with features such as ... Adding to the already impressive list of enterprise class features such as ... Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Fri, Aug 04, 2006 at 09:37:32AM -0400, Jonah H. Harris wrote:
>> I agree. The real problem is that we don't look at things in a
>> business-like, "what are we going to have in the next release"
>> perspective. Being as it's an OSS community, we just see what patches
>> come in and we apply what we choose... then pick which ones we see as
>> "major features" and announce them.
> There's a fairly standard way of getting people to do things for you:
> pay them money. Thing is, people can run around making lists of thing
> that would be cool, but no-one can really force anyone to do anything.
> Now, there are the priveledged few who are being paid to work on
> postgres. If you can convince their employers to fund things on the
> list, it might help. Also, some stuff might work well as Google SoC
> projects...
Not to be unkind, but AFAIR all the unmet expectations in this release
cycle came from commercially-sponsored developers who said they'd do X
and then didn't finish it. I don't see that "taking a business-like
approach" would improve matters at all, even if there were a way for
the project to dictate to people what they should work on, which there
surely is not. Programmers are optimists by nature and will *always*
think they can accomplish more than really gets done (cf. The Mythical
Man-Month, still on target after all these years).
If you want an easy solution, here it is: *never* tell anyone that
feature X will be in the next release until it's actually committed
to CVS. (And maybe not then ... we've backed things out before.)
The only way there were any unmet expectations here were if people
failed to distinguish "someone is working on it" from "will be done
by 8.2 for sure".
regards, tom lane
"Luke Lonergan" <llonergan@greenplum.com> writes:
> UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too,
Huh? We had INSERT working before, that's why it's not mentioned.
regards, tom lane
"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> And what about compression of on-disk sorting?
That's purely a performance issue, which some people seem to want
to define as "not a new feature" ... which is not *my* view of
what's important ...
regards, tom lane
Luke, > Yep. Fix the visibility issue - there are a number of good ideas on how to > do it, we are in a position to bang it out now IMO. Actually, a group of us discussed this at the Code Sprint in Toronto, and came up with a plan which will also reduce row overhead on large tables. I can't remember who was working on that though. > >> We already have splitting queries among CPUs and machines. > > > > Yes, YOU do. We don't. > > Details, details - redefine "We" and it's the same thing. Well, if you'll give us the schedule for open-sourcing MPP 2.0 ... ;-) And actually, even incorporating very limited multi-threading of queries ... such as the proposal to dispatch an I/O thread for seq scans ... would help PostgreSQL a lot. -- Josh Berkus PostgreSQL @ Sun San Francisco
Joshua D. Drake wrote: > Bruce Momjian wrote: > >> Joshua D. Drake wrote: >> >>>>> I think we should drop the term usability as a selling part of the >>>>> PR and push it into further description.. Instead we should use a >>>>> slightly more expensive word (think 50 cents, not 5). :) >>>> >>>> Fine, I am all ears. Also, a lot of people are thinking usability >>>> improvements aren't a big item, but they are. I had a press person >>>> ask >>>> during the 8.0 release, "You have a lot of large features in 8.0, but >>>> what is there for the ordinary database user?". At that time all >>>> we had >>>> was COPY CSV. This release will have a lot of those usability >>>> improvements. >>> >>> I don't disagree with your thought process and I full agree :). I am >>> just saying we should spice it up a bit :) >>> >>> Hmmmm.... >>> >>> PostgreSQL has showed an unprecedented commitment to all skill >>> levels of database developers. With the release of 8.2 the group has >>> focused on refinement and usability. Features such as ... add to the >>> already impressive list of enterprise class features such as ... >> >> >> Sounds very good, and that was my goal, that we get a "focus" idea for >> the release, I think that is it. As I remember, 8.0 was enterprise >> features, and 8.1 was performance. >> > > Quick reword: > > > With the release of 8.2, PostgreSQL has shown an unprecedented > commitment to all skill levels of database developers. The 8.2 version > of PostgreSQL has focused on refinement and usability with features > such as ... Adding to the already impressive list of enterprise class > features such as ... > > > Sincerely, > > Joshua D. Drake I am interrested in finding out what you folks mean by usability and refinement. How do you measure it? These seem to me to be unmeasurable hackneyed terms with little intrinsic meaning! So could you say something like: the New Postgresql, version 8.2, building on its reputation of sheer power and ACID compliance, now implements feature 1, which provides benefit 1, plus feature 2, which leads to benefit 2, plus .... etc. thereby maximizing overall ease of use. ?? WE tend to speak of features, now is a good time to speak of benefits to the dba, benefits for upgrading to an existing project, etc. The New Postgresql 8,2 will increase speed of response by x %, ad hoc queries will be x % faster, etc. I know I am being simplistic, but the benefits need to blurt out, and be immediately recognizable as such to the majority of players. JMUETCW. Michael -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006
Cool! Then let's make a stronger claim about the feature: 'data management using partioning now with transparent
insert/update/deletesupport in addition to the already proven performance acceleration in previous releases.
- Luke
Sent from my GoodLink synchronized handheld (www.good.com)
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, August 04, 2006 12:39 PM Eastern Standard Time
To: Luke Lonergan
Cc: Gavin Sherry; Bruce Momjian; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 8.2 features status
"Luke Lonergan" <llonergan@greenplum.com> writes:
> UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too,
Huh? We had INSERT working before, that's why it's not mentioned.
regards, tom lane
Tom Lane wrote: > "Luke Lonergan" <llonergan@greenplum.com> writes: > >>UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, > > Huh? We had INSERT working before, that's why it's not mentioned. I think what Luke means, is that an INSERT into the base table of the inheritance hierarchy with CE enabled gets automagically inserted into the correct partition, and as far as I know that still doesn't happen -- but I've certainly been wrong before :-). Joe
On Fri, Aug 04, 2006 at 10:52:34AM +0200, Guillaume Smet wrote: > On 8/4/06, Luke Lonergan <llonergan@greenplum.com> wrote: > >My ordering of this list in terms of priority is: > > > >1) Windowing functions > >2) MERGE > >3) Index only access (new) > >4) In-place upgrades > > And what about compression of on-disk sorting? There has been a long > thread about this idea. Is there any news about this feature? IIRC Jim > Nasby and Martijn were working on testing that and on validating it > was interesting for most of the cases. Well, I posted a bunch of numbers, but people wanted more proof. Which I haven't had time to generate yet. If someone wants to pick up the ball and run with it, do some testing of SELECT random() AS r INTO test_table FROM generate_series(1,some_big_number); \t SELECT count(*) FROM (SELECT r FROM test_table ORDER BY r); This is about the worst-case test I can think of; if it still shows improvement here... BTW, I suspect it was too late for this to get into 8.2 over a month ago, as the patch that's floating around has some rather serious issue in it that would limit usability too much... something about specific sort modes or some such that I don't recall anymore. My intention was to try and finish testing after 8.2 when it was more likely that someone could look into whatever that issue was. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote: > > * In-place upgrades (pg_upgrade) > > BTW, I may get Sun to contribute an engineer for this; will get you posted. How would such a thing handle changes to page formats? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Our database has about 700 objects (tables,views, stored functions,
types etc), we want to make a change on a view or tables, it said that there
were a lot of depended obejcts. I know that depended object must be dropped
and then created to solve this. But, It has too many dependecies to drop.
It will be nice to all, if PostgreSQL database objects has an state
(valid/invalid) like Oracle has. Depended objects states are changed to
invalid if any changes would make to the objects that are referenced by
them.
For example ;
Assuming, we have a table named "T" and a view named "W". We wanna
change on a column table "T", it will said that view "W" depended on it. If
the database would has a lot of dependecies then the problem will never be
solved. In my opinion, we let the changes on table "T" then must change the
state the view "W" to invalid.
Of course, i dont know if this is possible..
I hope this is not a nice dream :-)
Best regards
Adnan DURSUN
ASRIN Bilisim Ltd.
> I am interrested in finding out what you folks mean by usability and > refinement. How do you measure it? These seem to me to be unmeasurable > hackneyed terms with little intrinsic meaning! Yep you are absolutely right. That is what press releases are all about. > So could you say > something like: the New Postgresql, version 8.2, building on its > reputation of sheer power and ACID compliance, now implements feature 1, > which provides benefit 1, plus feature 2, which leads to benefit 2, > plus .... etc. thereby maximizing overall ease of use. ?? > > WE tend to speak of features, now is a good time to speak of benefits to > the dba, benefits for upgrading to an existing project, etc. If they don't know by reading the terms, then they will want to buy reading the 50 cent, fancy words. > The New > Postgresql 8,2 will increase speed of response by x %, ad hoc queries > will be x % faster, etc. I know I am being simplistic, but the benefits > need to blurt out, and be immediately recognizable as such to the > majority of players. JMUETCW. Michael Percentages never work because it depends on a specific work load, specific design, specific hardware etc... Joshua D. Drake > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Fri, Aug 04, 2006 at 12:37:10AM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > To me new things are like PITR, Win32, savepoints, two-phase commit, > > partitioned tables, tablespaces. These are from 8.0 and 8.1. What is > > there in 8.2 like that? > > [ shrug... ] Five out of your six items have no basis in the SQL spec. > So it's not clear to me what your definition of "major feature" is, Stuff that's "sexy". Like 2PC, partitioning, etc. And to add to David Fetter's list without another post... * Better interface to partitioning * Stored procedures (ie: BEGIN; COMMIT;) -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Guys, > I still don't like it. Usability is an opinion based thing. Personally I > find MySQL confusing and illogical. However I know many people love it > for that very same reason. As the person who's leading the draft of the press release, let me say that any "theme" discussions which happen on -hackers from here on out I'm going to ignore. PR discussions belong on -advocacy, not this list. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
On Fri, Aug 04, 2006 at 12:03:59PM -0400, Bruce Momjian wrote: > Andrew Dunstan wrote: > > > > > > Tom Lane wrote: > > > > >Not that there's anything wrong with a performance-oriented release > > >... but if you think that 8.2 is short on features, you'd better get > > >ready to be disappointed by every future release. > > > > > > > It's a pity that some expectations have been raised about features that > > we haven't seen patches for, e.g. MERGE and/or some form of UPSERT, and > > recursive queries. I am not pointing fingers, but I do think we need > > some way in which the community can ensure that certain goals are met, > > or at least try to help if things fall in a ditch, rather than just > > relying on hackers scratching whatever itch they happen to get in > > splendid isolation and then trying to merge the results. > > What we do is when people claim items, we monitor them to be sure they > get them done for the current release, or at least give it their best > try. There is not much more we can do. Do we? There seems to be improvements to be had here. For example, someone at OSCon (Josh D maybe) was saying that we'll have MERGE/UPSERT in 8.2, but apparently we won't. At best, people will lay claim to TODO items, and the the nebulous group concious will vaguely remember that someone's working on it; sometimes remembering who, sometimes even pushing to get it in for the next release. But there's plenty of room there for things to get forgotten about (ie: MERGE/UPSERT, which would have been a nice big feature to add to the list in 8.2). BTW, while I'm thinking about it, I believe INSERT ... RETURNING is in, no? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Joshua D. Drake wrote: > >> I am interrested in finding out what you folks mean by usability and >> refinement. How do you measure it? These seem to me to be >> unmeasurable hackneyed terms with little intrinsic meaning! > > > Yep you are absolutely right. That is what press releases are all about. > >> So could you say something like: the New Postgresql, version 8.2, >> building on its reputation of sheer power and ACID compliance, now >> implements feature 1, which provides benefit 1, plus feature 2, which >> leads to benefit 2, plus .... etc. thereby maximizing overall ease >> of use. ?? >> >> WE tend to speak of features, now is a good time to speak of benefits >> to the dba, benefits for upgrading to an existing project, etc. > > > If they don't know by reading the terms, then they will want to buy > reading the 50 cent, fancy words. > >> The New Postgresql 8,2 will increase speed of response by x %, ad >> hoc queries will be x % faster, etc. I know I am being simplistic, >> but the benefits need to blurt out, and be immediately recognizable >> as such to the majority of players. JMUETCW. Michael > > > Percentages never work because it depends on a specific work load, > specific design, specific hardware etc... > > Joshua D. Drake > > > >> >> > > Josh, percentages, like almost anything, do work in the right context, in this case, that of the testimonial, something postgresql hasn't emphasized IMHO. If ten to 20 projects were treated as real and realistic case studies, with an in-depth description of the project, and how the NEW Postgresql effected these projects,and these were featured one after another, daily for an entire month, there would be major play in the news. By talking in depth about specific projects, we relate to the actual production users own daily experiences, especiually if % can be translated into dollars. For instance: "I Adapted the NEW Postgresql 8.2 in my online e-commerce website and save $1,343.45 per month in ...." or: "The Sheer Speed of such an ACID compliant ORDBMS as the NEW Postgresql 8.2, especially in danling xnxnxnxn enabled our company to ..." I am just brainstorming, I lack the db expertise, but real life stroies are powerful creatures with a life of their own. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.5/407 - Release Date: 8/3/2006
* Jim C. Nasby (jnasby@pervasive.com) wrote:
> On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote:
> > > * In-place upgrades (pg_upgrade)
> >
> > BTW, I may get Sun to contribute an engineer for this; will get you posted.
>
> How would such a thing handle changes to page formats?
Couldn't this be done by converting a table/partial-table at a time?
It wouldn't be something which could run while the system is live, but
it'd probably take less time than dump/restore and wouldn't require
double the disk space of the whole database... no?
Thanks,
Stephen
On 8/4/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Not to be unkind, but AFAIR all the unmet expectations in this release > cycle came from commercially-sponsored developers who said > they'd do X and then didn't finish it. FYI, I am not commercially sponsered. I am a full-time employee devoted to working on database internals, drivers, Oracle compatibility, architecture, prototyping, and some performance stuff for EnterpriseDB. While I work full-time for EnterpriseDB, they have ALWAYS given me time to work on other PostgreSQL-related things when I ask for it. However, with the exception of the INSERT/UPDATE RETURNING patch (which EnterpriseDB asked me to submit), the PostgreSQL community is, and always has been, primarily my own personal time. If I would've known a good number of people were asking for WITH RECURSIVE (as Josh mentioned), I would've had more incentive to work on it. Again, the original patch for this has been out since 7.3.4, and no one has seen fit to work on this feature in 3 years. If it's a feature the community seriously wanted, maybe someone should've said something. A couple of you said it would be nice to have, but I don't recall seeing any community-oriented, "we *really* want this feature in 8.2" (similar to other features). I would've gladly supported anyone else who wanted to do it. I do have a family and by the time I get to work on something at home it's approaching 23:00; the last thing I want to do is spend a few hours coding something no one seems to want. Similarly, it's even harder to get motivated when the people complaining about a missing feature are those who didn't seem to want it to begin with. I don't know what you want unless you tell me and I've got better things to do than play a psychic. -Jonah
The community cannot ask anyone to work harder. What we do ask is that if you start working on an item, let us know, and if you stop working on it, let us know soon so others can work on it. Also, if something is on the TODO list, the community doesn't need to shoot signal rockets to tell people it is important. The fact it is on the TODO list indicates it is significant, unless you are told otherwise. Shifting blame on an incomplete feature to the community doesn't help anyone. --------------------------------------------------------------------------- Jonah H. Harris wrote: > On 8/4/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Not to be unkind, but AFAIR all the unmet expectations in this release > > cycle came from commercially-sponsored developers who said > > they'd do X and then didn't finish it. > > FYI, I am not commercially sponsered. I am a full-time employee > devoted to working on database internals, drivers, Oracle > compatibility, architecture, prototyping, and some performance stuff > for EnterpriseDB. > > While I work full-time for EnterpriseDB, they have ALWAYS given me > time to work on other PostgreSQL-related things when I ask for it. > However, with the exception of the INSERT/UPDATE RETURNING patch > (which EnterpriseDB asked me to submit), the PostgreSQL community is, > and always has been, primarily my own personal time. > > If I would've known a good number of people were asking for WITH > RECURSIVE (as Josh mentioned), I would've had more incentive to work > on it. > > Again, the original patch for this has been out since 7.3.4, and no > one has seen fit to work on this feature in 3 years. If it's a > feature the community seriously wanted, maybe someone should've said > something. A couple of you said it would be nice to have, but I don't > recall seeing any community-oriented, "we *really* want this feature > in 8.2" (similar to other features). I would've gladly supported > anyone else who wanted to do it. > > I do have a family and by the time I get to work on something at home > it's approaching 23:00; the last thing I want to do is spend a few > hours coding something no one seems to want. Similarly, it's even > harder to get motivated when the people complaining about a missing > feature are those who didn't seem to want it to begin with. > > I don't know what you want unless you tell me and I've got better > things to do than play a psychic. > > -Jonah > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> BTW, while I'm thinking about it, I believe INSERT ... RETURNING is in,
> no?
There's a recently-submitted patch, but it's not been reviewed yet,
so it's premature to say "it's in". See upthread comments about
promising things in advance of them hitting CVS ...
regards, tom lane
On 8/4/06, Bruce Momjian <bruce@momjian.us> wrote: > Also, if something is on the TODO list, the community doesn't need to > shoot signal rockets to tell people it is important. The fact it is on > the TODO list indicates it is significant, unless you are told > otherwise. True, but stating that you want certain items in the TODO list done for a certain release is another thing. Being on the TODO list has nothing to do with if/when a TODO item will be worked-on or released. > Shifting blame on an incomplete feature to the community > doesn't help anyone. I don't believe any one is at fault. -Jonah
On Fri, Aug 04, 2006 at 10:27:49AM -0700, Joe Conway wrote: > Tom Lane wrote: > >"Luke Lonergan" <llonergan@greenplum.com> writes: > > > >>UPDATE/DELETE for CE are a big deal - I really wish we had INSERT too, > > > >Huh? We had INSERT working before, that's why it's not mentioned. > > I think what Luke means, is that an INSERT into the base table of the > inheritance hierarchy with CE enabled gets automagically inserted into > the correct partition, and as far as I know that still doesn't happen -- > but I've certainly been wrong before :-). Likewise, I suspect that the UPDATE/DELETE constraint elimination don't do anything 'magical' either; merely figure out what partitions can safely be ignored for a statement. While that's a good feature to have, it's far short of being able to automatically 'route' data to the correct partitions. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote: > * Jim C. Nasby (jnasby@pervasive.com) wrote: > > On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote: > > > > * In-place upgrades (pg_upgrade) > > > > > > BTW, I may get Sun to contribute an engineer for this; will get you posted. > > > > How would such a thing handle changes to page formats? > > Couldn't this be done by converting a table/partial-table at a time? > It wouldn't be something which could run while the system is live, but > it'd probably take less time than dump/restore and wouldn't require > double the disk space of the whole database... no? True, but if you're going to go about creating code that can deal with 2 different versions of on-disk data, why not go one better: put that code into the database itself, so that pages are converted on-the-fly as they're dirtied. That way you have *no* downtime (or almost no, anyway). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Aug 04, 2006 at 03:18:37PM -0400, Tom Lane wrote: > "Jim C. Nasby" <jnasby@pervasive.com> writes: > > BTW, while I'm thinking about it, I believe INSERT ... RETURNING is in, > > no? > > There's a recently-submitted patch, but it's not been reviewed yet, > so it's premature to say "it's in". See upthread comments about > promising things in advance of them hitting CVS ... True, but I didn't remember seeing it in your list of yet-to-be-committed patches, so I thought I'd mention it. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Aug 04, 2006 at 12:03:59PM -0400, Bruce Momjian wrote: > Andrew Dunstan wrote: > > Tom Lane wrote: > > > > >Not that there's anything wrong with a performance-oriented > > >release ... but if you think that 8.2 is short on features, you'd > > >better get ready to be disappointed by every future release. > > > > It's a pity that some expectations have been raised about features > > that we haven't seen patches for, e.g. MERGE and/or some form of > > UPSERT, and recursive queries. I am not pointing fingers, but I do > > think we need some way in which the community can ensure that > > certain goals are met, or at least try to help if things fall in a > > ditch, rather than just relying on hackers scratching whatever > > itch they happen to get in splendid isolation and then trying to > > merge the results. > > What we do is when people claim items, we monitor them to be sure > they get them done for the current release, or at least give it > their best try. There is not much more we can do. While I am not going to reopen the can of worms labeled 'bug tracker', I think it would be good to have a little more formality as far as claiming items goes. I'm picturing something like this: 1. Each person taking an item agrees to write at least one email each week to -hackers detailing progress or lack of same on the item. 2. Should someone wish to relinquish a claim on a feature, there needs to be some standard way to do a hand-off of whatever they've done/found and announce that the feature is now available to others to claim. 3. Should the person claiming the feature not communicate to -hackers for some period--I'm thinking 3 weeks is about right--the item goes back in the unclaimed pool with a message to -hackers saying that that's what's happened. What say? Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Jonah, > If I would've known a good number of people were asking for WITH > RECURSIVE (as Josh mentioned), I would've had more incentive to work > on it. You didn't ask. If you had asked, you would have got a response. People knew you were working on it, and assumed that it would be done, since you're a "full time" developer and a very fast programmer. The first time I became aware that you weren't expecting to finish was the PostgreSQL Anniversary. I expect that a lot of other people weren't aware of it until earlier in this thread. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Jonah H. Harris wrote: > On 8/4/06, Bruce Momjian <bruce@momjian.us> wrote: > > Also, if something is on the TODO list, the community doesn't need to > > shoot signal rockets to tell people it is important. The fact it is on > > the TODO list indicates it is significant, unless you are told > > otherwise. > > True, but stating that you want certain items in the TODO list done > for a certain release is another thing. Being on the TODO list has > nothing to do with if/when a TODO item will be worked-on or released. True. But with better communication, we might be able to have had someone else work on this. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> I'm picturing something like this: > > 1. Each person taking an item agrees to write at least one email each > week to -hackers detailing progress or lack of same on the item. > > 2. Should someone wish to relinquish a claim on a feature, there needs > to be some standard way to do a hand-off of whatever they've > done/found and announce that the feature is now available to others to > claim. > > 3. Should the person claiming the feature not communicate to -hackers > for some period--I'm thinking 3 weeks is about right--the item goes > back in the unclaimed pool with a message to -hackers saying that > that's what's happened. > > What say? I say that many people have been shouting on deaf ears about this topic for a long time and that I back an idea to change our incredibility inefficient policies on todo items. We are like the last bastion of anarchy, refusing to except that we are in fact a recognized and important open source project that has responsibilities to its community. Those responsibilities include better communication, feature tracking and milestones... but alas... again the walls of the canyon echo until there was nothing but the sound of water and crickets. Sincerely, Joshua D. rake > > Cheers, > D -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
* Jim C. Nasby (jnasby@pervasive.com) wrote:
> On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote:
> > * Jim C. Nasby (jnasby@pervasive.com) wrote:
> > > How would such a thing handle changes to page formats?
> >
> > Couldn't this be done by converting a table/partial-table at a time?
> > It wouldn't be something which could run while the system is live, but
> > it'd probably take less time than dump/restore and wouldn't require
> > double the disk space of the whole database... no?
>
> True, but if you're going to go about creating code that can deal with 2
> different versions of on-disk data, why not go one better: put that code
> into the database itself, so that pages are converted on-the-fly as
> they're dirtied. That way you have *no* downtime (or almost no, anyway).
Certainly a good idea but I'm really not sure that: a) we'd want the
core server to have essentially cruft code and b) that it'd be anywhere
near simple to make this actually work in the core system.
Supporting two versions of the page format when the only goal is
changing the formatting is quite a different thing than fully supporting
two on-disk formats throughout the backend. Additionally, if you have
something to convert the database wholesale then that really just needs
to support 2 versions at a time, if it's piecemeal then you could end up
in a situation where you have to support 3, 4, 5, however many prior
page formats existed. If not then you have to have a way to force all
the pages to be upgraded and you're unlikely to be able to do a whole
lot more with the system while that's happening, thus adding alot of
extra complication just to end up having everyone follow the
'pg_upgrade'-style path anyway...
In the end though, I think once it's been done in pg_upgrade this could
be revisited and considered and if enough people are interested in doing
it they could probably reuse some of hte pg_upgrade code to make it
happen.
Thanks,
Stephen
On Fri, Aug 04, 2006 at 07:45:56AM -0700, Joshua D. Drake wrote: > > >* Several varieties of replication, which I believe we as a project > > will eventually endorse and ship > > This one will cause confusion regardless of how much advocacy, > documentation and will power we put into it. It will, but I think we'll eventually have to get there if for no other reason than that every other DBMS on earth would have it. > >* On-the-fly in-line calls out to PL/your_choice without needing to > >issue DDL > > You mean something like: EXEC plperl(print $foo)? Something like this: SELECT a, b, c FROM ( EXECUTE IMMEDIATE LANGUAGE plperl $$...$$ ) AS (a int, b point, c text) JOIN ... Anyhow, the idea is to be able to call PL functionality in-line without having to create a function in advance. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
>>> issue DDL >> You mean something like: EXEC plperl(print $foo)? > > Something like this: > > SELECT a, b, c > FROM ( > EXECUTE IMMEDIATE > LANGUAGE plperl > $$...$$ > ) AS (a int, b point, c text) > JOIN ... > > Anyhow, the idea is to be able to call PL functionality in-line > without having to create a function in advance. Well that is certainly interesting. Opens up a whole lot of flexibility, especially to views and such. Seems a little unnatural though ;) Joshua D. Drake > > Cheers, > D -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Fri, Aug 04, 2006 at 01:41:42PM -0700, Joshua D. Drake wrote: > >>>issue DDL > >>You mean something like: EXEC plperl(print $foo)? > > > >Something like this: > > > >SELECT a, b, c > >FROM ( > > EXECUTE IMMEDIATE > > LANGUAGE plperl > > $$...$$ > >) AS (a int, b point, c text) > >JOIN ... > > > >Anyhow, the idea is to be able to call PL functionality in-line > >without having to create a function in advance. > > Well that is certainly interesting. Opens up a whole lot of flexibility, > especially to views and such. > > Seems a little unnatural though ;) That's the table constructor version. It would be nice to call other versions, too, like SELECT CALL IMMEDIATE LANGUAGE plpython $$...$$ (a, LOWER(b)) AS wacky_python_output FROM ... Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On Fri, Aug 04, 2006 at 12:40:01PM -0700, David Fetter wrote: > While I am not going to reopen the can of worms labeled 'bug tracker', > I think it would be good to have a little more formality as far as > claiming items goes. Agreed. > I'm picturing something like this: > > 1. Each person taking an item agrees to write at least one email each > week to -hackers detailing progress or lack of same on the item. > > 2. Should someone wish to relinquish a claim on a feature, there needs > to be some standard way to do a hand-off of whatever they've > done/found and announce that the feature is now available to others to > claim. > > 3. Should the person claiming the feature not communicate to -hackers > for some period--I'm thinking 3 weeks is about right--the item goes > back in the unclaimed pool with a message to -hackers saying that > that's what's happened. > > What say? It's a shame to have a person burn cycles on this, but anything would be an improvement over what we've got now. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > On Fri, Aug 04, 2006 at 12:40:01PM -0700, David Fetter wrote: > > While I am not going to reopen the can of worms labeled 'bug tracker', > > I think it would be good to have a little more formality as far as > > claiming items goes. > > Agreed. > > > I'm picturing something like this: > > > > 1. Each person taking an item agrees to write at least one email each > > week to -hackers detailing progress or lack of same on the item. > > > > 2. Should someone wish to relinquish a claim on a feature, there needs > > to be some standard way to do a hand-off of whatever they've > > done/found and announce that the feature is now available to others to > > claim. > > > > 3. Should the person claiming the feature not communicate to -hackers > > for some period--I'm thinking 3 weeks is about right--the item goes > > back in the unclaimed pool with a message to -hackers saying that > > that's what's happened. > > > > What say? > > It's a shame to have a person burn cycles on this, but anything would be > an improvement over what we've got now. -------- Really? -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: > While I am not going to reopen the can of worms labeled 'bug tracker', > I think it would be good to have a little more formality as far as > claiming items goes. > What say? I think this is a good plan for adding additional process overhead, and getting essentially nothing of value in return. I'm not convinced there's a problem in need of solving here... -Neil
>>> What say? >> It's a shame to have a person burn cycles on this, but anything would be >> an improvement over what we've got now. -------- > > Really? I lot of this could be automated with a web app. The web app takes the todo, a hacker signs up. Hacker takes todo. Web app reminds hacker every 6, 8 weeks to post an update or release the todo. Every 6/8 weeks we get an automated email to pgsql-hackers that states the current status of the todo list. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: > On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: > > While I am not going to reopen the can of worms labeled 'bug > > tracker', I think it would be good to have a little more formality > > as far as claiming items goes. > > > What say? > > I think this is a good plan for adding additional process overhead, > and getting essentially nothing of value in return. I'm not > convinced there's a problem in need of solving here... Perhaps you'd like to explain how big a burden on the developer it is to send an once a week, that being what I'm proposing here. As far as the "problem in need of solving," it's what Andrew Dunstan referred to as "splendid isolation," which is another way of saying, "letting the thing you've taken on gather dust while people think you're working on it." Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
David Fetter wrote: > On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: >> On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: >>> While I am not going to reopen the can of worms labeled 'bug >>> tracker', I think it would be good to have a little more formality >>> as far as claiming items goes. >>> What say? >> I think this is a good plan for adding additional process overhead, >> and getting essentially nothing of value in return. I'm not >> convinced there's a problem in need of solving here... > > Perhaps you'd like to explain how big a burden on the developer it is > to send an once a week, that being what I'm proposing here. > > As far as the "problem in need of solving," it's what Andrew Dunstan > referred to as "splendid isolation," which is another way of saying, > "letting the thing you've taken on gather dust while people think > you're working on it." Well I guess the key thing is that its transparent who is working on what feature and that someone (some projects have a new release manager for every release) keeps tabs on these people (maybe once every few weeks he asks how things are progressing, if the target can still be made etc). Maybe this can even be enumerated into a percentage value that can be published so that people who feel a given feature is very important to them can see if things are lagging behind. Actually the person keeping track of these feature developments does not need to be a pgsql hacker. As a matter of fact I have been trying to do something similar for the PHP project and I am more than willing to do the same for PostgreSQL. I do not however think it makes sense to ask developers to send in reports in a regular basis on their own. regards, Lukas
"Joshua D. Drake" <jd@commandprompt.com> writes: > Those responsibilities include better communication, feature tracking and > milestones... Wow, if we had all those we could have as efficient a release-engineering process as Mozilla!
> > "Joshua D. Drake" <jd@commandprompt.com> writes: > >> Those responsibilities include better communication, feature tracking >> and >> milestones... > > Wow, if we had all those we could have as efficient a release-engineering > process as Mozilla! > > This is not really a good argument. Might it not be possible that there is a sweeter spot somewhere in the middle? I don't think anyone wants something very heavy handed. cheers andrew
Folks, > This is not really a good argument. Might it not be possible that there > is a sweeter spot somewhere in the middle? I don't think anyone wants > something very heavy handed. Well, I think the answer is just to set something up and see if people can use it. If we keep kibitzing about it, the grousing will go on forever. Mind you, I'm not thinking a bug tracker, but just a task manager for the TODOs. BTW, I've road-tested GForge's task manager and it's not adequate for what we need. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
This has been a very interesting thread, if for no other reason then to just catalog all of the changes going into 8.2. I am going to be changing some hardware around so I need to decide if I want to a) change the hardware now and don't bother with 8.2, b) wait to upgrade hardware and do the upgrade to 8.2 at the same time, c) upgrade the hardware now and then upgrade to 8.2 when it is released. What I do basically depends on how much benefit I'm going to get from 8.2 and whether it's worth planning my hardware upgrades around or incurring additional downtime in order to do the postgres upgrade. Doing a dump/reload is not a problem at all, it doesn't take that long with the data I've got. It's just having to kick everyone off the system and shut everything down in order to do it. My applications are not that demanding on the DB so there isn't anything that I "NEED" that postgres doesn't already have. Because of this I stayed on 7.3 for way, way too long. It just didn't seem worth the effort to do the upgrade or the additional testing against each postgres version to make sure it didn't break my apps. But I finally bit the bullet and upgraded straight to 8.1. I couldn't believe what a huge performance difference it made even though I didn't use any of the big headlining features. (ie PITR, two-phase commit, etc). So I'm sure that even though I don't even understand what most of the items on toms huge list are, and I certainly don't understand where they will come into play for me, I'm sure that once I've upgraded and I use it for a while, I'll be very glad I did. That being said I think that Bruce has a point in that there is a certain class of features (which seems hard to define) which existed in 8.0 and 8.1 but not 8.2. I would define it like this: A) There are features that PHBs would look for. B) There are features that a casual database user would look for. C) There are features that an experienced database user would look for / understand D) and then there are features that a database guru/developer of database software would understand. Features of class A contribute to the bullet point lists, the buzz word checklists, etc and are easily used for marketing. For instance if someone were to package up postgres and put it in a box you would not have a list of "new features in 8.2!" that included "lazy vacuums are ignored by other processes". Only an existing postgres user who has had a setup complex enough to need a tricky vacuuming strategy would ever even know what that meant much less care about it. It might be life and death for many users, but it doesn't go on the back of the box. So if you define "major features" as class A features. In this case major doesn't mean important or useful or difficult to implement, just that they are the sort of features that one might be told to look for when shopping for a database. So in terms of marketing PITR, two phase commit, WIN32 support were very much "major" features. If people had expectations that are not being met it could be because 8.0 and 8.1 had so many of these headlining, market friendly, buzzword compliant "major" features. It doesn't make it any less impressive technically or less useful for the actual users of the database but it DOES make a difference as to how this release will be perceived by a lot of people. Not that it's a problem, but many people I think will see this release as less "Major" than the 8.0 or 8.1 releases. I think this is reflected in the fact that 8.0 was picked as the version to jump up to 8.0 instead of 7.5. I will upgrade at some point but mostly because experience has taught me that each release of postgres is significantly better than the last one, even if I won't see how until I actually use it in production. That being said I think that two of the not-yet-reviewed features are just as "major" as the "major" features from the past two releases. 1) updatable views - I won't really use this but it just seems like one of those features that people use when doing rdbms features comparison charts. I think that having updatable views will be considered by the masses to be a "major features" 2) restartable recovery (allow checkpoints for a hot-standby server) - Having the ability to have a hot standby database is a HUGE feature in my book. Maybe I'm just biased because it's a feature that I actually need but I think it's very big. Yes you can sort of do the same thing or something "better" with slony but this is what I really want (and I'm guessing that this will get used A LOT if it makes it in). And it's "bulit in" unlike slony. And it seems much easier to set up and maintain and less likely to have problems or complicate things than slony. In terms of having a setup with no "single point of failure" this goes a long way. And it builds on something that I will want set up anyway (PITR). Anyway this is just my $0.02 as a fairly average to low end, user of postgres as to how this issue may be perceived by the masses. Thanks in advance for what will certainly be another great release. On Aug 3, 2006, at 10:46 PM, Bruce Momjian wrote: > Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> To me new things are like PITR, Win32, savepoints, two-phase commit, >>> partitioned tables, tablespaces. These are from 8.0 and 8.1. >>> What is >>> there in 8.2 like that? >> >> [ shrug... ] Five out of your six items have no basis in the SQL >> spec. >> So it's not clear to me what your definition of "major feature" is, >> unless maybe it's "anything except what we did for 8.2". Can you >> enumerate ten things you would consider comparable to the above >> features >> that aren't done yet? > > No, I cannot. I do think our missing list is shrinking. My point is > that you really couldn't easily work around the 8.0/8.1 items I listed > if they were missing, while the 8.2 items could be more easily > worked-around. Again, nothing wrong with that. > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings >
Gregory Stark wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > >> Those responsibilities include better communication, feature tracking and >> milestones... > > Wow, if we had all those we could have as efficient a release-engineering > process as Mozilla! Thanks for the sarcasm. Anything productive to add? How about this... We can use Trac for the TODO list. It allows for assigning of todos, status, difficulty ratings, gives us a wiki for collaborative features etc... We even have one that is already pulling the pgsql repo for review. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Lukas Smith <smith@pooteeweet.org> writes: > David Fetter wrote: > > > On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: > >> On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: > >>> While I am not going to reopen the can of worms labeled 'bug > >>> tracker', I think it would be good to have a little more formality > >>> as far as claiming items goes. > >>> What say? > > >> I think this is a good plan for adding additional process overhead, > >> and getting essentially nothing of value in return. I'm not > >> convinced there's a problem in need of solving here... > > > Perhaps you'd like to explain how big a burden on the developer it is > > to send an once a week, that being what I'm proposing here. There seems to be a lack of recognition here of how free software development works. When people are contributing their time scratching an itch for their own edification the LAST thing they want is to have a manager to report to. > > As far as the "problem in need of solving," it's what Andrew Dunstan > > referred to as "splendid isolation," which is another way of saying, > > "letting the thing you've taken on gather dust while people think > > you're working on it." Really you guys are talking as if the developers that are working for the most part on an entirely volunteer basis have some sort of responsibility to you. They do not. If they don't feel like tell you where they're at then feel free to ask for your money back. Now if you think you have some tool that will make it easier for developers to do something they honestly want to do then feel free to suggest it and make it available. But if you want to dictate how programmers work for the gain of others you're going to have a hard time swimming against the current. Now not all the developers working on Postgres are unpaid volunteers. But the ones that aren't have their own managers to report to already and their own timelines and other responsibilities to deal with. They're not being paid to meet yours. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Fri, Aug 04, 2006 at 08:44:24PM -0400, Gregory Stark wrote: > > > Perhaps you'd like to explain how big a burden on the developer > > > it is to send an once a week, that being what I'm proposing > > > here. > > There seems to be a lack of recognition here of how free software > development works. When people are contributing their time > scratching an itch for their own edification the LAST thing they > want is to have a manager to report to. It it were--note the subjunctive--only for their own edification, that would be true. It's not. It's from a TODO list that a community put together, and claiming a TODO means taking an opportunity away from one or more other parties. > > > As far as the "problem in need of solving," it's what Andrew > > > Dunstan referred to as "splendid isolation," which is another > > > way of saying, "letting the thing you've taken on gather dust > > > while people think you're working on it." > > Really you guys are talking as if the developers that are working > for the most part on an entirely volunteer basis have some sort of > responsibility to you. They do not. When they've taken on a TODO, they most certainly have taken on a responsibility to the entire Postgres community. > If they don't feel like tell you where they're at then feel free to > ask for your money back. How do we get the time that somebody frittered away by grabbing a TODO when others could have worked on it? Time is a much more precious resource than money because no matter what you do, you can't get any more of it. > Now if you think you have some tool that will make it easier for > developers to do something they honestly want to do then feel free > to suggest it and make it available. Joshua Drake has made Trac available. Perhaps you weren't here for the extensive, drawn-out, rancorous discussions that surrounded a bug tracking system, but they're all over the archives. > But if you want to dictate how programmers work for the gain of > others you're going to have a hard time swimming against the > current. It's for their own gain, too. People who contribute good-sized features to PostgreSQL can generally choose their place of work and to a large degree, their salaries, so let's not get too excited about how this is only a matter of selfless generosity. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
> There seems to be a lack of recognition here of how free software > development > works. When people are contributing their time scratching an itch for > their > own edification the LAST thing they want is to have a manager to report > to. > I am sick of hearing lectures on this. It is simply NOT true that free software follows a single model of development. There are many projects and all have their own methods, some formal and some not very formal. But the idea that there is ONE method is simply nonsense. You really ought to know better. >> > As far as the "problem in need of solving," it's what Andrew Dunstan >> > referred to as "splendid isolation," which is another way of saying, >> > "letting the thing you've taken on gather dust while people think >> > you're working on it." > > Really you guys are talking as if the developers that are working for the > most > part on an entirely volunteer basis have some sort of responsibility to > you. > They do not. If they don't feel like tell you where they're at then feel > free > to ask for your money back. > > Now if you think you have some tool that will make it easier for > developers to > do something they honestly want to do then feel free to suggest it and > make it > available. But if you want to dictate how programmers work for the gain of > others you're going to have a hard time swimming against the current. > > Now not all the developers working on Postgres are unpaid volunteers. But > the > ones that aren't have their own managers to report to already and their > own > timelines and other responsibilities to deal with. They're not being paid > to > meet yours. > Really, you are suggesting that a volunteer coimmunity is incapable of actually organising itself in any coherent fashion, and that only money will motivate people to act with any sense of responsibility to others. FYI I have never got a penny for the work I have done on Postgres. I would not object to an occasional query about items I had undertaken to implement. Greg, you are on an utterly wrong track here. Try to look about a bit more broadly. cheers andrew
On Fri, 2006-08-04 at 15:44 -0700, David Fetter wrote: > As far as the "problem in need of solving," it's what Andrew Dunstan > referred to as "splendid isolation," which is another way of saying, > "letting the thing you've taken on gather dust while people think > you're working on it." I'm just not convinced this is a problem. We've seen *one* example of this happening in recent times (hierarchical queries) -- but even with better communication, it's not like there were hordes of folks volunteering to hack on hierarchical queries who just idled because they thought it was already being completed. If people are interested in the status of a patch, I think it's fine for them to email the person who's volunteered to work on it. If there hasn't been public activity from that person in recent times, it is probably a reasonable bet that the work has stalled. Formalizing the process strikes me as a waste of time, and IMHO would mostly serve to irritate the folks working on these features. -Neil
Rick Gigger <rick@alpinenetworking.com> writes:
> So if you define "major features" as class A features. In this case
> major doesn't mean important or useful or difficult to implement,
> just that they are the sort of features that one might be told to
> look for when shopping for a database. So in terms of marketing
> PITR, two phase commit, WIN32 support were very much "major" features.
You have a point: 8.0 and 8.1 had much more buzzword-compliant stuff
added. The truth of the matter is that a lot of that stuff was pretty
rough-edged in actual use, and now we're starting to smooth it out and
make it more readily usable. So in terms of *usable* PITR etc we're
only now getting there with 8.2. But that's not a bullet point that
impresses PHBs.
> That being said I think that two of the not-yet-reviewed features are
> just as "major" as the "major" features from the past two releases.
> 1) updatable views - I won't really use this but it just seems like
> one of those features that people use when doing rdbms features
> comparison charts.
Agreed, if this gets in it will be a Real Biggie. I de-emphasized it
in my list because I haven't looked at the patch yet and so have no
idea whether it's any good, but I fully agree it's a PHB-worthy
bullet point if it works.
> 2) restartable recovery (allow checkpoints for a hot-standby server)
> - Having the ability to have a hot standby database is a HUGE feature
> in my book.
Again, we claimed to have hot standby in 8.1, and we sort of did, it
just didn't work all that nicely. This will file down one seriously
rough edge, but is that a good marketing bullet point? Probably not.
regards, tom lane
> There seems to be a lack of recognition here of how free software development > works. When people are contributing their time scratching an itch for their > own edification the LAST thing they want is to have a manager to report to. I have heard you make this argument before, and it is just is not true. Even Debian is moving toward a more formal structure as has FreeBSD. You seem stuck in this world where everything is still 1994 and all FOSS software is developed in academia. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/ http://lwn.net/Articles/144281/ http://developer.kde.org/documentation/other/checklist.html > > Now not all the developers working on Postgres are unpaid volunteers. But the > ones that aren't have their own managers to report to already and their own > timelines and other responsibilities to deal with. They're not being paid to > meet yours. No one is expecting them to. However we are expecting some communication about it. When you start developing with a community you have a responsibility to that community. That means you let people know if you are not going to finish something, if you need help, if you can't help, or if you are going to bail on a project. You should also do so with (hopefully) the ability for someone to pick up where you left off. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
andrew@dunslane.net writes: > > There seems to be a lack of recognition here of how free software > > development works. When people are contributing their time scratching an > > itch for their own edification the LAST thing they want is to have a > > manager to report to. > > I am sick of hearing lectures on this. It is simply NOT true that free > software follows a single model of development. There are many projects > and all have their own methods, some formal and some not very formal. But > the idea that there is ONE method is simply nonsense. You really ought to > know better. Well strictly speaking I blurred a distinction in that not all free software projects are projects are volunteer projects at all. Projects like Mozilla and Emacs are driven by a single entity with paid developers. But excluding projects like that can you name a single project with a "formal" development process that it requires its developers to follow? And I'll note that my earlier sarcasm had a point. Projects that, while they may be free software, are driven by a single commercial entity frequently drive away any volunteer contributors with their onerous formal development methodologies. Mozilla in particular spent years angsting over why they were failing to attract any community contributors. I'm involved in a fairly large number of free software projects, and have been involved in a great deal more in the past. Certainly all projects use various tools to help. But where they do it's because those tools make their lives easier. Not because it makes it easier for other people watching them. If you phrase your argument in terms of milestones and progress updates and so on and how those things will help other people make use of the work then you're just going to find people continue to ignore it. The way to phrase the argument if you want to win people over is by figuring out how your tools will make the developers' lives easier. -- greg
Neil Conway <neilc@samurai.com> writes:
> If people are interested in the status of a patch, I think it's fine for
> them to email the person who's volunteered to work on it. If there
> hasn't been public activity from that person in recent times, it is
> probably a reasonable bet that the work has stalled. Formalizing the
> process strikes me as a waste of time, and IMHO would mostly serve to
> irritate the folks working on these features.
I tend to agree --- I don't see much value in trying to institute a
formalized process. We have not had that many cases where lack of
communication was a problem.
In the case at hand (hierarchical queries), I believe what happened was
that Jonah expected that he'd be able to complete the feature with a
relatively small amount of work by starting with the existing patch.
When he got into it he realized that a complete rewrite was needed, and
there was no time to get that done for 8.2. He told a few of us at the
anniversary conference, and perhaps should have been more proactive
about mentioning the problem on the mailing list, but *it would have
made no difference* as to whether hierarchical queries got into 8.2.
There was not anyone else in a position to invest the work needed in
the time available, either.
regards, tom lane
andrew@dunslane.net writes:
> Greg, you are on an utterly wrong track here. Try to look about a bit more
> broadly.
FWIW, I tend to agree with Greg. This project has gotten to where it is
with a very loose structure, and I think that trying to impose more
structure carries a significant risk of breaking the cooperative
dynamics that have worked so well for us so far. In short, I'm not sure
that we should try to fix something that isn't clearly broken.
I don't object to someone informally polling people who have claimed a
TODO item and not produced any visible progress for awhile. But I think
anything like "thou shalt report in once a week" will merely drive
people away from publicly claiming items, if not drive them away from
doing anything at all. We've already got far too much problem with
lack of visibility, in the sense that people pop up with patches after
not having told anyone they were working on a given problem (much less
posted a preliminary design for feedback, as I desperately wish people
would do before starting to code anything). We should encourage people
to say "I'm working on X", and I fear that putting requirements on them
as soon as they say that will mostly serve to keep them from saying
anything.
regards, tom lane
> I tend to agree --- I don't see much value in trying to institute a > formalized process. We have not had that many cases where lack of > communication was a problem. How do you know? Seriously... this comes up at least twice a year :). There is probably a basis for it. As I was saying on #postgresql, the current system works well for a small group of developers. I don't think there is any arguing that. However, there is a larger group out there, that would likely be willing to contribute but we are a bit of a black box, or perhaps we are too transparent?? I am not sure which. Frankly, I don't care if we ever get a bug tracker or use trac. However a more formalized communication process is sorely needed IMHO. I am actually hoping that jabber.postgresql.org would help that in the long run. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> As I was saying on #postgresql, the current system works well for a
> small group of developers. I don't think there is any arguing that.
> However, there is a larger group out there, that would likely be willing
> to contribute but we are a bit of a black box, or perhaps we are too
> transparent?? I am not sure which.
Maybe I'm too much "on the inside", but I see the problem the other way
'round: too little visibility of what's being done by people who are not
part of the inner circle of developers.
It's possible that creating a more formal structure would aid these folk
to let the rest of us know what they're doing ... but I think it's at
least as likely that a more formal structure would just drive them away.
> I am actually hoping that jabber.postgresql.org would help that in the
> long run.
Now here I think we might be on the same page. If people pop up on IRC
or jabber or any other communication method and talk about what they're
doing, that fixes the whole problem. I'm for adding anything that
provides an opportunity for people to talk to the community --- I'm not
for trying to force them to talk to the community, 'cause I don't think
that will work very well.
regards, tom lane
> I don't object to someone informally polling people who have claimed a > TODO item and not produced any visible progress for awhile. But I think > anything like "thou shalt report in once a week" will merely drive > people away from publicly claiming items, if not drive them away from > doing anything at all. Well a weekly report is probably ridiculous but as I said in an earlier post it would be fairly trivial to allow communication via web site and have that site keep tabs on people every 6-8 weeks. Heck we could even set it up to feed off of email as well.. for example: todo_173@postgresql.org Hey... just letting you guys know that I am still moving forward. My current list is: A B C Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Friday 04 August 2006 13:56, mdean wrote:
> Josh, percentages, like almost anything, do work in the right context,
> in this case, that of the testimonial, something postgresql hasn't
> emphasized IMHO. If ten to 20 projects were treated as real and
> realistic case studies, with an in-depth description of the project, and
> how the NEW Postgresql effected these projects,and these were featured
> one after another, daily for an entire month, there would be major play
> in the news. By talking in depth about specific projects, we relate to
> the actual production users own daily experiences, especiually if % can
> be translated into dollars.
>
The problem has never been the idea of doing more case studies, but has been
of finding someone to do it. Writing case studies isn't exactly exciting to
you're average programmer, and in most cases you'd rather have them hacking
code anyway.
> I am just brainstorming, I lack the db expertise, but real life stroies
> are powerful creatures with a life of their own.
Sure. Can you drum us up some advertising interns who are willing to work on
case studies for us? We surely have people who are interested in
participating.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On Friday 04 August 2006 21:19, Tom Lane wrote:
> Rick Gigger <rick@alpinenetworking.com> writes:
> > So if you define "major features" as class A features. In this case
> > major doesn't mean important or useful or difficult to implement,
> > just that they are the sort of features that one might be told to
> > look for when shopping for a database. So in terms of marketing
> > PITR, two phase commit, WIN32 support were very much "major" features.
>
> You have a point: 8.0 and 8.1 had much more buzzword-compliant stuff
> added. The truth of the matter is that a lot of that stuff was pretty
> rough-edged in actual use, and now we're starting to smooth it out and
> make it more readily usable. So in terms of *usable* PITR etc we're
> only now getting there with 8.2. But that's not a bullet point that
> impresses PHBs.
>
> > That being said I think that two of the not-yet-reviewed features are
> > just as "major" as the "major" features from the past two releases.
> >
> > 1) updatable views - I won't really use this but it just seems like
> > one of those features that people use when doing rdbms features
> > comparison charts.
>
> Agreed, if this gets in it will be a Real Biggie. I de-emphasized it
> in my list because I haven't looked at the patch yet and so have no
> idea whether it's any good, but I fully agree it's a PHB-worthy
> bullet point if it works.
>
Hmm.. I would de-emphasize it because it doesn't give us give us anything we
couldn't do before; and really what we can do now is way above most database
systems.
> > 2) restartable recovery (allow checkpoints for a hot-standby server)
> > - Having the ability to have a hot standby database is a HUGE feature
> > in my book.
>
> Again, we claimed to have hot standby in 8.1, and we sort of did, it
> just didn't work all that nicely. This will file down one seriously
> rough edge, but is that a good marketing bullet point? Probably not.
>
So, the things I hear most non-postgresql people complain about wrt postgresql
are:
no full text indexing built in
no replication built in
no stored procedures (with a mix of wanting in db cron facility)
the planner is not smart enough (with a mix of wanting hints)
vacuum leads to unpredictable performance
Of that list, they could probably all be turned into nice marketing points
(though #4 is pretty nebulous), though I don't see any of them getting
resolved anytime soon.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On 8/4/06, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In the case at hand (hierarchical queries), I believe what happened > was ... Tom is exactly correct, this is what happened. In the many months I've stated to be working on it, I've only had one other person (Mark Cave-Ayland) interested in assisting with the patch. Based on the need to completely rewrite it, neither he nor I would probably be able to get this done correctly for 8.2 without a fairly good amount of design. I would gladly assist anyone that wants to work on a new patch. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 2nd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
> I don't object to someone informally polling people who have claimed a > TODO item and not produced any visible progress for awhile. But I think > anything like "thou shalt report in once a week" will merely drive > people away from publicly claiming items, if not drive them away from > doing anything at all. The former is much more what I had in mind than the latter. Let's do that. cheers andrew
Robert Treat <xzilla@users.sourceforge.net> writes:
> On Friday 04 August 2006 21:19, Tom Lane wrote:
>> Rick Gigger <rick@alpinenetworking.com> writes:
>>> 1) updatable views - I won't really use this but it just seems like
>>> one of those features that people use when doing rdbms features
>>> comparison charts.
>>
>> Agreed, if this gets in it will be a Real Biggie.
> Hmm.. I would de-emphasize it because it doesn't give us give us anything we
> couldn't do before; and really what we can do now is way above most database
> systems.
Well, you know that and I know that, but no PHB knows that --- and
what's more important, the average journeyman database developer
probably doesn't know how to write those rules either. This feature
isn't about doing something that couldn't be done at all before; it is
about bringing a pretty useful behavior within the reach of mere mortals.
regards, tom lane
andrew@dunslane.net writes:
>> I don't object to someone informally polling people who have claimed a
>> TODO item and not produced any visible progress for awhile. But I think
>> anything like "thou shalt report in once a week" will merely drive
>> people away from publicly claiming items, if not drive them away from
>> doing anything at all.
> The former is much more what I had in mind than the latter. Let's do that.
Like I said, no objection here. But who exactly is "we" --- ie, who's
going to do the legwork? We surely don't want multiple people pestering
the same developer ...
regards, tom lane
> > It's possible that creating a more formal structure would aid these folk > to let the rest of us know what they're doing ... but I think it's at > least as likely that a more formal structure would just drive them away. > Well just some informal from the internal workings of CMD. Some of this won't work with the community because of QA but... I pretty much leave Alvaro, Alexey and Andrei (odd just realized the three As) alone. I watch the timeline on track to see what is going on. Once a week I will touch base just to get the team flow going. About once a month Alvaro will post a status to the lists that gives me a general idea of his direction and goals. Alvaro keeps tabs on Alexey and Andrei so that all development is done in the style of PostgreSQL. None of this is hard and fast, and it gives the developers the cat like feeling they like but allows me to be comfortable with the business requirement side. Obviously the business side doesn't apply here, but the "checkin" type does. One of the items I have been toying with for us (the community) is mentors. Basically you have a green programmer, or even a seasoned one... there are plenty lurking on the lists. Someone like Alvaro, Neil, or Andrew offers to mentor a particular feature such as Enums. Basically Alvaro or Neil could offer guidance and answer questions, maybe be a little more readily available for that particular email address. Alvaro does that with Alexey and Andrei... helping insure appropriate style, coding standards, giving feedback on particular implementations. Yes people can get that on the lists, but if they felt they were getting a little more direct attention, it might help retain them to the community. >> I am actually hoping that jabber.postgresql.org would help that in the >> long run. > > Now here I think we might be on the same page. If people pop up on IRC > or jabber or any other communication method and talk about what they're > doing, that fixes the whole problem. I'm for adding anything that > provides an opportunity for people to talk to the community --- I'm not > for trying to force them to talk to the community, 'cause I don't think > that will work very well. Cool well that is nice to know, I didn't get a whole lot of feedback on the idea. Sincerely, Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
Robert Treat wrote: > So, the things I hear most non-postgresql people complain about wrt postgresql > are: > > no full text indexing built in > no replication built in > no stored procedures (with a mix of wanting in db cron facility) > the planner is not smart enough (with a mix of wanting hints) > vacuum leads to unpredictable performance FTI is a biggie in my mind. I know it ain't happening for 8.2, but is the general plan to integrate TSearch2 directly into the backend?
I had a few thoughts on this issue: The objective is to smoothly upgrade to the new version with minimal downtime. The different proposals as far as I can see are as follows: Proposal A - the big one time reformatting 1) shutdown the db 2) run a command that upgrades the data directory to the new format 3) start up the new postgres version with the new data dir Pros: only pg_upgrade (or whatever it's called) needs to know about the old and new formats, each version of postgres knows about "it's" format and that's it. The postgres code stays clean cons: your database is down while the upgrade takes place. This sucks because the people who need this are the same people who are trying to avoid downtime. It's faster than a dump/reload but it doesn't completely solve the problem, it just mitigates it. Proposal B - the gradual upgrade 1) shutdown the db 2) start it back up with the new version of postgres 3) the new postgres version upgrades things in place as needed Pros: very short downtime. only the time to shutdown the postgres version and start up the new one cons: postgres code gets filled with cruft. each version has to know about the old versions on disk data format and how to upgrade it. Until it is finished you will be left with a database that is part old format, part new format. This could introduce bugs for people who never needed the feature in the first place. Here is another proposal that I haven't heard anyone else suggest. My apologies in advance if it's obviously not workable or has already be discussed. Proposal C - PITR with in on the fly disk upgrades 1) setup PITR 2) run pg_upgrade on your latest backed up data directories 3) start up the new pg on that data directory in restartable recovery / read-only / hot-standby mode 4) update the recovery log importer so that it can update the log files on the fly as it applies them 5) failover to the hot standby as you normally would Pros: essentially no downtime, just any incidental time needed for the failover to occur.cruft in postgres main codebase is mimimized. It's limited to the log importer. All other parts of postgres are unaffected Cons: requires another server or double the disk space on the original server. Is this a problem for people with databases so large that a dump reload is unacceptable?Perhaps there are technical issues with postgres that I don't understand that would make this too hard.Maybe it would take to long to update each log file as it's applied so it wouldn't be able to catch up. Oh yeah there's another way Proposal D - Use slony But I figured since that's been working for a long time, if slony solved their problem then they wouldn't be looking for something else. I have no need for this feature as a dump reload is not a problem for me. I've always wondered though if that was a feasible answer to this problem. Each time it crops up people propose solutions A and B but never C. On Aug 4, 2006, at 1:30 PM, Jim C. Nasby wrote: > On Fri, Aug 04, 2006 at 02:12:16PM -0400, Stephen Frost wrote: >> * Jim C. Nasby (jnasby@pervasive.com) wrote: >>> On Thu, Aug 03, 2006 at 11:20:48PM -0700, Josh Berkus wrote: >>>>> * In-place upgrades (pg_upgrade) >>>> >>>> BTW, I may get Sun to contribute an engineer for this; will get >>>> you posted. >>> >>> How would such a thing handle changes to page formats? >> >> Couldn't this be done by converting a table/partial-table at a time? >> It wouldn't be something which could run while the system is live, >> but >> it'd probably take less time than dump/restore and wouldn't require >> double the disk space of the whole database... no? > > True, but if you're going to go about creating code that can deal > with 2 > different versions of on-disk data, why not go one better: put that > code > into the database itself, so that pages are converted on-the-fly as > they're dirtied. That way you have *no* downtime (or almost no, > anyway). > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of > broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
If people are going to start listing features they want here's some things I think would be nice. I have no idea though if they would be useful to anyone else: 1) hierarchical / recursive queries. I realize it's just been discussed at length but since there was some question as to whether or not there's demand for it so I am just weighing in that I think there is. I have to deal with hierarchy tables all the time and I simply have several standard methods of dealing with them depending on the data set / format. But they all suck. I've just gotten use to using the workarounds since there is nothing else. If you are not hearing the screams it's just because I think it's just become a fact of life for most people (unless you're using oracle) that you've just got to work around it. And everyone already has some code to do this and they've already done it everywhere it needs to be done. And as long as you're a little bit clever you can always work around it without taking a big performance hit. But it would sure be nice to have next time I have to deal with a tree table. 2) PITR on a per database basis. I think this would be nice but I'm guessing that the work involved is big and that few people really care or need it, so it will probably never happen. 3) A further refinement of PITR where some sort of deamon ships small log segments as they are created so that the hot standby doesn't have to be updated in 16MB increments or have to wait for some timeout to occur. It could always be up to the minute data. 4) All the Greenplum Bizgress MPP goodness. In reality (and I don't know if bizgress mpp can actually do this) I'd like to have a cluster of cheap boxes. I'd like to install postgres on all of them and configure them in such a way that it automatically partitions and mirrors each table so that each piece of data is always on two boxes and large tables and indexes get divided up intelligently. Sort of like a raid10 on the database level. This way any one box could die and I would be fine. Enormous queries could be handled efficiently and I could scale up by just dropping in new hardware. Maybe greeenplum has done this. Maybe we will get their changes soon enough, maybe not. Maybe this sort of functionality will never happen. My guess is that all the little bit's a pieces of this will trickle in over the next several years and this sort of setup will be slowly converged on over time as lot's of little things come together. Table spaces and constraint exclusion come to mind here as things that could eventually evolve to contribute to a larger solution. 5) Somehow make it so I NEVER HAVE TO THINK ABOUT OR DEAL WITH VACUUM AGAIN. Once I get everything set up right everything works great but I'm sure if there's one thing I think everyone would love it would be getting postgres to the point where you don't even need to ship vacuumdb because there's no way the user could outsmart postgres's attempts to do garbage collection on it's own. 6) genuine updatable views. such that you just add an updatable keyword when you create the view and it's automagically updatable. I'm guessing that we'll get something like that, but its real magic will be throwing an error to tell you when you try to make a view updatable and it can't figure out how to make the rules properly. 7) allow some way to extract the data files from a single database and insert them into another database cluster. In many cases it would be a lot faster to copy the datafiles across the network than it is to dump, copy dump file, reload. 8) some sort of standard "hooks" to be used for replication. I guess when the replication people all get their heads together and tell the core developers what they all need something like this could evolve. Like I said, postgres more than satisfies my "needs". I am especially happy when you factor in the cost of the software (free), and the quality of the community support (excellent). And you can definitely say that the "missing" list is shrinking. But I think of it like this. There are tiers of database functionality that different people need: A) Correct me if I'm wrong but as great as postgres is there are still people out there that MUST HAVE Oracle or DB2 to get done what they need to get done. They just do things that the others can't. They may be expensive. They may suck to use and administer but the simple fact is that they have features that people need that are not offered in less expensive databases. B) Very, very powerful databases but lack the biggest, most complicated "enterprise" features. C) Light weight db for taking care of the basic need to store data and query it with sql. (some would call these "toy" databases) D) databases which are experimental, unreliable or have other limits that make them not practical compared with the other options I would say that with version 7.0 postgres moved from D to C (please don't get offended if this is way off base, I never used 6.x but I heard it was prone to crashes, data corruption and of course there was that pesky row size limit). It then proceeded to move up within tier C to become the best of it's class and pushing up into level B. With 8.0 it was firmly in level B. It was fast, efficient, powerful and began adding lots of really, really big features like PITR, savepoints, tablespaces, etc. Add ons like slony also allowed it to be used in places where it otherwise wouldn't have measured up. Now there are only a few features left in the B range and so there are tons of situations that can be taken care of by postgres now that were out of it's reach just a few years ago. Once those features are all gone there will still be some very big, very difficult features on the table that once completed will begin to remove any advantage that the really big guys have. I'm thinking especially of #4 above here. But they will definitely take a while. I may have tons of details wrong here but my point is that I think that postgres isn't just taking stuff off a big to do list, but rather is pushing itself upwards and is now in a position to start working on some very hard problems that once completed will put it into a very elite class of database systems. The "missing" list for tier B type problems is shrinking down to almost nothing and items from the tier A missing list are starting to come into view. Maybe I'm way off base here but that's how I see it. Postgres has come a long, long way, but the problems ahead are bigger and meaner than the ones behind. On Aug 4, 2006, at 12:02 AM, David Fetter wrote: > On Fri, Aug 04, 2006 at 12:37:10AM -0400, Tom Lane wrote: >> Bruce Momjian <bruce@momjian.us> writes: >>> To me new things are like PITR, Win32, savepoints, two-phase >>> commit, partitioned tables, tablespaces. These are from 8.0 and >>> 8.1. What is there in 8.2 like that? >> >> [ shrug... ] Five out of your six items have no basis in the SQL >> spec. So it's not clear to me what your definition of "major >> feature" is, unless maybe it's "anything except what we did for >> 8.2". Can you enumerate ten things you would consider comparable to >> the above features that aren't done yet? > > First, I'd like to say people are doing a fantastic job here. Kudos! > > One huge thing missing from the "done" list is that crucial bit of > infrastructure and process that has shortened feedback loops--hence > the beta period--by weeks if not months: the build farm. It's now > smoothly integrated into the development process, and as a > consequence, we can realistically have a release each year. :) > > As far as big missing features go, here's a short list: > > * Splitting queries among CPUs--possibly even among machines--for OLAP > loads > > * In-place upgrades (pg_upgrade) > > * Several varieties of replication, which I believe we as a project > will eventually endorse and ship > > * CALL > > * WITH RECURSIVE > > * MERGE > > * Windowing functions > > * On-the-fly in-line calls out to PL/your_choice without needing to > issue DDL > > * Wild-eyed feral bits of the SQL standard like SQL/MED and SQL/XML > > But all that leaves out the oldest, most honored Postgres tradition: > > Breaking New Ground. > > We're definitely not done yet. :) > > Cheers, > D > -- > David Fetter <david@fetter.org> http://fetter.org/ > phone: +1 415 235 3778 AIM: dfetter666 > Skype: davidfetter > > Remember to vote! > > ---------------------------(end of > broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match >
Joshua D. Drake wrote: > Frankly, I don't care if we ever get a bug tracker or use trac. > However a more formalized communication process is sorely needed > IMHO. There's also supposed to be a wiki set up. There, people can try to make up tracking lists, project management, task lists, release goals or whatever on their own. If patterns emerge, we can "formalize" them, but I feel this would be a good way to try things out. -- Peter Eisentraut http://developer.postgresql.org/~petere/
> andrew@dunslane.net writes: >>> I don't object to someone informally polling people who have claimed a >>> TODO item and not produced any visible progress for awhile. But I >>> think >>> anything like "thou shalt report in once a week" will merely drive >>> people away from publicly claiming items, if not drive them away from >>> doing anything at all. > >> The former is much more what I had in mind than the latter. Let's do >> that. > > Like I said, no objection here. But who exactly is "we" --- ie, who's > going to do the legwork? We surely don't want multiple people pestering > the same developer ... > Perl has its pumpking ... maybe we need a designated "holder of the trunk". I see that as a Core function. cheers andrew
On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote: > Robert Treat wrote: > >So, the things I hear most non-postgresql people complain about wrt > >postgresql are: > > > >no full text indexing built in > > FTI is a biggie in my mind. I know it ain't happening for 8.2, but is > the general plan to integrate TSearch2 directly into the backend? When the Tsearch developers say so I think. This will be the first major release with GIN which will form the basis of future releases of tsearch. IIRC they have a whole list of features they still want to add before it gets included... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Tom Lane wrote: > But a quick troll through the CVS logs shows ... > > multi-row VALUES, not only for INSERT but everywhere SELECT is allowed ... > multi-argument aggregates, including SQL2003-standard statistical aggregates ... > standard_conforming_strings can be turned on (HUGE deal for some people) ... > support SQL-compliant row comparisons; they can be indexscan quals ISTM this could be spun as a standards-focused release as well (at least partial implementations of a number of optional(?) SQL2003 features).
On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote: > I have heard you make this argument before, and it is just is not true. > Even Debian is moving toward a more formal structure as has FreeBSD. You > seem stuck in this world where everything is still 1994 and all FOSS > software is developed in academia. Debian moving towards a more formal structure? What I seeing is that they're trying to get away from the having one person responsible for things to working in groups. What it amounts to is simplifying the rules to doing someone elses work. People who don't like it leave and you hope you're left with a more efficient group. The links you provide are mostly about handling releases. To be honest, I think PostgreSQL's release handling is fine. But none of those projects tackles the issue of making sure certain things get done. If someone didn't do the work for getting GCC 4.1 working for Debian, then no matter how much of a release goal it was, it wouldn't happen... > That means you let people know if you > are not going to finish something, if you need help, if you can't help, > or if you are going to bail on a project. You should also do so with > (hopefully) the ability for someone to pick up where you left off. That I can agree with, but I don't think you can force it. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
andrew@dunslane.net wrote: > > andrew@dunslane.net writes: > >>> I don't object to someone informally polling people who have claimed a > >>> TODO item and not produced any visible progress for awhile. But I > >>> think > >>> anything like "thou shalt report in once a week" will merely drive > >>> people away from publicly claiming items, if not drive them away from > >>> doing anything at all. > > > >> The former is much more what I had in mind than the latter. Let's do > >> that. > > > > Like I said, no objection here. But who exactly is "we" --- ie, who's > > going to do the legwork? We surely don't want multiple people pestering > > the same developer ... > > > > Perl has its pumpking ... maybe we need a designated "holder of the > trunk". I see that as a Core function. I can assure you that individual developers were contacted about completing their items for 8.2, to the extent that some developers got upset at me because of my insistence. If they were hired by PostgreSQL companies and I had a relationship with their manager, their managers were informed as well. Jonah, who said the community wasn't clear it wanted his items completed, was part of that group. I see no need to mention the other people I contacted. Many of them completed their items, and Jonah finished some of his items. The fact is, the existing system worked as it should, though it is often invisible. We didn't get all the features we wanted, but that isn't because the system isn't working. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> There's also supposed to be a wiki set up. There, people can try to > make up tracking lists, project management, task lists, release goals > or whatever on their own. If patterns emerge, we can "formalize" them, > but I feel this would be a good way to try things out. Well I will re-extend my offer to put up a trac site for everyone which does contain a wiki. However, last time I offered I believe Marc was actually going to do it. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Bruce Momjian wrote: >I can assure you that individual developers were contacted about >completing their items for 8.2, to the extent that some developers got >upset at me because of my insistence. If they were hired by PostgreSQL >companies and I had a relationship with their manager, their managers >were informed as well. > >Jonah, who said the community wasn't clear it wanted his items >completed, was part of that group. I see no need to mention the other >people I contacted. Many of them completed their items, and Jonah >finished some of his items. > >The fact is, the existing system worked as it should, though it is often >invisible. We didn't get all the features we wanted, but that isn't >because the system isn't working. > > > Thank you Bruce. That is good to know. Maybe the invisibility has led me astray. I'll shut up now and see if I can actually get Enums and some other good stuff done by this time next year. With any luck I won't be quite as derailed as I was last cycle. Also, I hope it's now clear at least that there are many people who want to see recursive queries. cheers andrew
> The fact is, the existing system worked as it should, though it is often > invisible. We didn't get all the features we wanted, but that isn't > because the system isn't working. Well that kind of comes back to my point of better communication. Perhaps a lot of this discussion could have been avoided if the TODO had been more... proactive? For example: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 I *think* it was peter that did that one, but you see my point. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Martijn van Oosterhout <kleptog@svana.org> writes:
> On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote:
>> FTI is a biggie in my mind. I know it ain't happening for 8.2, but is
>> the general plan to integrate TSearch2 directly into the backend?
> When the Tsearch developers say so I think.
Yeah, that's my take too. Oleg and Teodor obviously feel it's not "done"
yet, and ISTM leaving it in contrib gives them more flexibility in a
couple of ways:
* they can make user-visible API changes without people getting as upset as if they were changing core features;
* because it is a removable contrib module, they can (and do) offer back-ports of newer versions to existing PG release
branches.
I think some descendant of tsearch2 will eventually be in core, but
we'll wait till we're pretty certain it's feature-stable.
regards, tom lane
Neil, all: > If people are interested in the status of a patch, I think it's fine for > them to email the person who's volunteered to work on it. The problem I would like to see resolved is that there is currently no accurate way to determine who is working on a patch except by comprehensive -hackers, -patches, and -performance archive reading. This is a little daunting for people who just joined the community, or who are users just wanting to know if someone is working on a feature they want. I doubt that any TODO system would have 100% participation, and I know that it would depend on having some non-hacker volunteers updating the information on behalf of developers who didn't want to use it. However, I think that getting those volunteers is entirely possible (for example, PWN is inculding a weekly patch list and it's not much more effort to check off those patches against a web-based TODO list). If the system reflected 70% of current development activity, then I think it would be a big improvement over the current "read 100% of the mail archives for three mailing lists back one year to find out what's going on." -- Josh Berkus PostgreSQL @ Sun San Francisco
Rick, > The objective is to smoothly upgrade to the new version with minimal > downtime. Thanks for jumping in. > The different proposals as far as I can see are as follows: > > Proposal A - the big one time reformatting > 1) shutdown the db > 2) run a command that upgrades the data directory to the new format > 3) start up the new postgres version with the new data dir > > Pros: only pg_upgrade (or whatever it's called) needs to know about > the old and new formats, each version of postgres knows about "it's" > format and that's it. The postgres code stays clean > cons: your database is down while the upgrade takes place. This > sucks because the people who need this are the same people who are > trying to avoid downtime. It's faster than a dump/reload but it > doesn't completely solve the problem, it just mitigates it. Yes, but it mitigates it *considerably.* The general idea is that doing an in-place binary upgrade should take 80% less time, and require only 10% (or so) extra disk space. This would be sufficient for most users with large databases; they can afford to be down from midnight to 3 am but not to be down for the whole weekend (as dump/reload requires for a 3tb database) nor do they have 100% + extra disk space and 20% extra CPU on the machine (as upgrade-by-replication requires). Plus, there are versions (like 8.2 looks to be) where there is *no* change in the file format. For these, pg_upgrade would need just to bootstrap the system, swap the system tables and header files, and restart. Seconds instead of hours. As PostgreSQL matures further, I predict that there will be more releases with no change in the file format, making this even more useful. > Proposal B - the gradual upgrade > 1) shutdown the db > 2) start it back up with the new version of postgres > 3) the new postgres version upgrades things in place as needed This is impractical, because the number of version-to-version compatibility libraries required will grow geometrically with time. We don't have to just accomodate the last version, but the last 4+ versions. > Proposal C - PITR with in on the fly disk upgrades > 1) setup PITR > 2) run pg_upgrade on your latest backed up data directories > 3) start up the new pg on that data directory in restartable > recovery / read-only / hot-standby mode > 4) update the recovery log importer so that it can update the log > files on the fly as it applies them > 5) failover to the hot standby as you normally would I don't think this is practical. Simon? -- Josh Berkus PostgreSQL @ Sun San Francisco
Josh Berkus wrote: > I doubt that any TODO system would have 100% participation, and I know that it > would depend on having some non-hacker volunteers updating the information on > behalf of developers who didn't want to use it. However, I think that > getting those volunteers is entirely possible (for example, PWN is inculding > a weekly patch list and it's not much more effort to check off those patches > against a web-based TODO list). If the system reflected 70% of current > development activity, then I think it would be a big improvement over the > current "read 100% of the mail archives for three mailing lists back one year > to find out what's going on." Yup, thats exactly what I experienced when I started a TODO list for the PHP project. A few developers wanted to get direct access, others use me as their proxy and then others do not care about the list at all. But it has been very helpful to the community to hear whats going on. It has let to some people joining the development or suggesting possible implementation options and more importantly it has reduced the work load of the release managers. This is not a task that requires a lot of technical know how and is therefore a great way for some non C hacker to contribute to the project. regards, Lukas
Tom Lane wrote: > I tend to agree --- I don't see much value in trying to institute a > formalized process. One more problem with the formalized process of claiming features in advance may stop what I suspect is a significant source of contributions -- people who add features/patches for internal work in their company and only after the fact find that they are something they'd contribute back. The small contribution I made (to help admins know when FSM settings were too low by monitoring log files instead of manual checks[1]) was done because we wanted it internally. Only after it proved useful to us, it was mentioned to the lists. Thanks in part to the BSD nature of postgresql, I suspect there are many internal-and-not-yet-released useful patches lurking around in industry. If I'm right, I'd wonder what the advocacy guys could do to get corporations to volunteer to contribute changes back that they've found useful internally. > We have not had that many cases where lack of > communication was a problem. One could say too much communication was the problem this time. I get the impression people implied they'd do something on a TODO and didn't. Arguably the project had been better off if noone had claimed the TODO, so if another company/team/whatever needed the feature badly, they could have worked on it themselves rather than waiting in hope of the feature. Of course they could have done this anyway - but if they see it on an implied roadmap document for the next release they're more likely to wait. Ron [1] http://archives.postgresql.org/pgsql-patches/2005-02/msg00171.php
Ron Mayer wrote: > >> We have not had that many cases where lack of >> communication was a problem. > > One could say too much communication was the problem this time. > > I get the impression people implied they'd do something on a TODO > and didn't. Arguably the project had been better off if noone > had claimed the TODO, so if another company/team/whatever needed > the feature badly, they could have worked on it themselves rather > than waiting in hope of the feature. Of course they could have > done this anyway - but if they see it on an implied roadmap document > for the next release they're more likely to wait. > This is just perverse. Surely you are not seriously suggesting that we should all develop in secret and then spring miracles fully grown on the community? We have bumped patches before because they have done things without discussing them, and were found not to be accepatble. The more complex features get, the more communication is needed. cheers andrew
andrew@dunslane.net wrote: > Ron Mayer wrote: >>> We have not had that many cases where lack of >>> communication was a problem. >> One could say too much communication was the problem this time. >> >> I get the impression people implied they'd do something on a TODO >> and didn't. Arguably the project had been better off if noone >> had claimed the TODO, so if another company/team/whatever needed >> the feature badly, they could have worked on it themselves rather >> than waiting in hope of the feature. > > This is just perverse. Surely you are not seriously suggesting that we > should all develop in secret and then spring miracles fully grown on the > community? Of course not. What I'm suggesting is two things. (1) That misleading information is worse than no information; and that speculative information next to TODOs can do as much harm discouraging others as it the good it does for communication. Perhaps a name/assignment/claim on a todo might be nice if someone wanted a private conversation with someone who knows about a feature; but even there wouldn't a public discussion on the lists likely be better? (2) That much corporate development on BSD projects is indeed developed in secret. Although may want to be contributed later either because the company no longer decides it's a trade-secret or gets tired of maintaining their own fork. Sure, such patches might need even more discussion and revision than if they were designed with core - but I think it's a reality that such work exists. > We have bumped patches before because they have done things > without discussing them, and were found not to be accepatble. The more > complex features get, the more communication is needed. Agreed, of course. This makes me think that ongoing discussion on hackers & patches is the only way to judge progress on a todo; and anything like assigned names & estimated dates & releases are less likely to be meaningful than what one could infer from discussions on the lists.
Tom Lane wrote: > Martijn van Oosterhout <kleptog@svana.org> writes: >> On Sat, Aug 05, 2006 at 12:19:54AM -0400, Matthew T. O'Connor wrote: >>> FTI is a biggie in my mind. I know it ain't happening for 8.2, but is >>> the general plan to integrate TSearch2 directly into the backend? > >> When the Tsearch developers say so I think. > > Yeah, that's my take too. Oleg and Teodor obviously feel it's not "done" > yet, and ISTM leaving it in contrib gives them more flexibility in a > couple of ways: > * they can make user-visible API changes without people getting as upset > as if they were changing core features; > * because it is a removable contrib module, they can (and do) offer > back-ports of newer versions to existing PG release branches. > > I think some descendant of tsearch2 will eventually be in core, but > we'll wait till we're pretty certain it's feature-stable. > My impression from this post http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php was that moving it into core should be doable for 8.3. I hope I didn't misunderstand. cheers andrew
Josh Berkus <josh@agliodbs.com> writes:
>> Proposal C - PITR with in on the fly disk upgrades
>> 1) setup PITR
>> 2) run pg_upgrade on your latest backed up data directories
>> 3) start up the new pg on that data directory in restartable
>> recovery / read-only / hot-standby mode
>> 4) update the recovery log importer so that it can update the log
>> files on the fly as it applies them
>> 5) failover to the hot standby as you normally would
> I don't think this is practical. Simon?
I don't think there is very much hope of an in-place upgrade for
scenarios involving changes in contents of user tables. In particular,
what of a change that requires more space than before, such as adding a
locale indicator to text fields? There's no guarantee that the data on
an old page will still fit, and there's certainly no hope of something
operating at the xlog level being able to move tuples across pages ---
if nothing else, because it's not in a position to compute new index
entries. I don't see this working for page-at-a-time updates even in a
full backend environment; again, indexes are the killer consideration.
I don't see how to get sane behavior from an index containing some
old-style entries and some new-style ones for a changed datatype.
As you mentioned, the scenarios that look practical for in-place upgrade
are the ones where only system catalog contents need to change. We've
already discussed this (many times) and agreed that we could live with
restricting user-table changes to happen only once every few releases.
regards, tom lane
In an attempt to throw the authorities off his trail, jnasby@pervasive.com ("Jim C. Nasby") transmitted:
>> What say?
>
> It's a shame to have a person burn cycles on this, but anything would be
> an improvement over what we've got now.
"Anything" includes some options that would probably *not* be
improvements.
I'm not sure that pestering everyone once a week would be a
particularly good move. That's too likely to get silly unrealistic
estimates as to how much is done. (Entirely typical in
run-by-the-calendar projects "project managed" by Big Five consulting
firms...)
On the flip side, I don't think it is unreasonable to expect to hear
*something* once a month or every two months on ToDo items that have
been assigned. With the proviso that if no news is heard in several
months, that surely suggests that the item isn't progressing, and
might deserve others' attention...
--
let name="cbbrowne" and tld="acm.org" in String.concat "@" [name;tld];;
http://linuxdatabases.info/info/linuxdistributions.html
Rules of the Evil Overlord #79. "If my doomsday device happens to come
with a reverse switch, as soon as it has been employed it will be
melted down and made into limited-edition commemorative coins."
<http://www.eviloverlord.com/>
Quoth david@fetter.org (David Fetter): > On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: >> On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: >> > While I am not going to reopen the can of worms labeled 'bug >> > tracker', I think it would be good to have a little more formality >> > as far as claiming items goes. >> >> > What say? >> >> I think this is a good plan for adding additional process overhead, >> and getting essentially nothing of value in return. I'm not >> convinced there's a problem in need of solving here... > > Perhaps you'd like to explain how big a burden on the developer it is > to send an once a week, that being what I'm proposing here. > > As far as the "problem in need of solving," it's what Andrew Dunstan > referred to as "splendid isolation," which is another way of saying, > "letting the thing you've taken on gather dust while people think > you're working on it." It seems to me once a week is a bit too often to demand, particularly when trying to "herd cats." A burden of once a month may seem more reasonable. -- let name="cbbrowne" and tld="gmail.com" in name ^ "@" ^ tld;; http://linuxdatabases.info/info/nonrdbms.html "If you pick up a starving dog and make him prosperous, he will not bite you; that is the principal difference between a dog and a man." -- Mark Twain
On Sat, 5 Aug 2006, Peter Eisentraut wrote: > Joshua D. Drake wrote: >> Frankly, I don't care if we ever get a bug tracker or use trac. >> However a more formalized communication process is sorely needed >> IMHO. > > There's also supposed to be a wiki set up. Working on that, hope to have it up Sunday ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote: > "Guillaume Smet" <guillaume.smet@gmail.com> writes: > > And what about compression of on-disk sorting? > > That's purely a performance issue, which some people seem to want > to define as "not a new feature" ... which is not *my* view of > what's important ... > > regards, tom lane > From my point of view, some of these new performance features are the most important changes in the 8.2 release. We are using other databases currently because of performance problems that are going to be addressed in this release. If we can use PostgreSQL instead, their are new possibilities for reliability and robustness that our current database choice will not allow. Ken
# kleptog@svana.org / 2006-08-05 15:49:33 +0200: > On Fri, Aug 04, 2006 at 06:25:35PM -0700, Joshua D. Drake wrote: > > I have heard you make this argument before, and it is just is not true. > > Even Debian is moving toward a more formal structure as has FreeBSD. You > > seem stuck in this world where everything is still 1994 and all FOSS > > software is developed in academia. > > Debian moving towards a more formal structure? What I seeing is that > they're trying to get away from the having one person responsible for > things to working in groups. What it amounts to is simplifying the > rules to doing someone elses work. People who don't like it leave and > you hope you're left with a more efficient group. > > The links you provide are mostly about handling releases. To be honest, > I think PostgreSQL's release handling is fine. But none of those > projects tackles the issue of making sure certain things get done. If > someone didn't do the work for getting GCC 4.1 working for Debian, then > no matter how much of a release goal it was, it wouldn't happen... Actually, the FreeBSD team does gather status reportsfrom people working on major tasks. Max Laier bugs current@ and hackers@ every two months, [1] then publisheswhatever came in. [2,3] They used to ask for emails IIRC, now I see there's a report submission form on theweb. [4] [1] http://marc.theaimsgroup.com/?l=freebsd-current&m=115126459006810 [2] http://marc.theaimsgroup.com/?l=freebsd-current&m=115265674914807 [3] http://www.freebsd.org/news/status/ [4] http://www.freebsd.org/cgi/monthly.cgi -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991
On Sat, Aug 05, 2006 at 01:00:24PM -0700, Josh Berkus wrote: > Neil, all: > > > If people are interested in the status of a patch, I think it's > > fine for them to email the person who's volunteered to work on it. > > The problem I would like to see resolved is that there is currently > no accurate way to determine who is working on a patch except by > comprehensive -hackers, -patches, and -performance archive reading. True. > This is a little daunting for people who just joined the community, > or who are users just wanting to know if someone is working on a > feature they want. > > I doubt that any TODO system would have 100% participation, and I > know that it would depend on having some non-hacker volunteers > updating the information on behalf of developers who didn't want to > use it. However, I think that getting those volunteers is entirely > possible (for example, PWN is inculding a weekly patch list and it's > not much more effort to check off those patches against a web-based > TODO list). If the system reflected 70% of current development > activity, then I think it would be a big improvement over the > current "read 100% of the mail archives for three mailing lists back > one year to find out what's going on." This thing is why I've been continuing the patches review on PostgreSQL Weekly News :) Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
On Aug 5, 2006, at 10:48 PM, Christopher Browne wrote: > Quoth david@fetter.org (David Fetter): >> On Fri, Aug 04, 2006 at 02:37:56PM -0700, Neil Conway wrote: >>> On Fri, 2006-08-04 at 12:40 -0700, David Fetter wrote: >>>> While I am not going to reopen the can of worms labeled 'bug >>>> tracker', I think it would be good to have a little more formality >>>> as far as claiming items goes. >>> >>>> What say? >>> >>> I think this is a good plan for adding additional process overhead, >>> and getting essentially nothing of value in return. I'm not >>> convinced there's a problem in need of solving here... >> >> Perhaps you'd like to explain how big a burden on the developer it is >> to send an once a week, that being what I'm proposing here. >> >> As far as the "problem in need of solving," it's what Andrew Dunstan >> referred to as "splendid isolation," which is another way of saying, >> "letting the thing you've taken on gather dust while people think >> you're working on it." > > It seems to me once a week is a bit too often to demand, particularly > when trying to "herd cats." > > A burden of once a month may seem more reasonable. One of the problems is that CVS branching is rather painful and some contributors can't commit. If there were some place where one could maintain a publicly-visible development branch just for feature X, that would make the work open source and trackable instead of "open-source-once-I'm-done". -M ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM agentm@themactionfaction.com ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > My impression from this post > http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php > was that moving it into core should be doable for 8.3. I hope I > didn't misunderstand. As I've stated before, it sure would be nice if there was any possible way this could be done for 8.2. This would be a *huge* feature for 8.2 to have, and it frankly needs all the big-item-yet-easy-to-grasp features it can get. Is there any way this could be done if we threw money and/or people at the problem? I'm sure we could come up with both if the end goal was having built-in text searching for the next release. - -- Greg Sabino Mullane greg@turnstep.com greg@endpoint.com End Point Corporation PGP Key: 0x14964AC8 200608062228 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iD8DBQFE1qjEvJuQZxSWSsgRApwuAJ9Dva+SNpnWi5a1C/xGDLeP0ZyI4QCeL5NW KSq5zQoVpD7U7oP2JdYgxu0= =bDQg -----END PGP SIGNATURE-----
Greg, > As I've stated before, it sure would be nice if there was any > possible way this could be done for 8.2. This would be a > *huge* feature for > 8.2 to have, and it frankly needs all the > big-item-yet-easy-to-grasp features it can get. Is there any > way this could be done if we threw money and/or people at the > problem? I'm sure we could come up with both if the end goal > was having built-in text searching for the next release. Maybe you've said this before, but why is the current regexp support not good enough? What kind of response time, etc, do you need? - Luke
Greg Sabino Mullane wrote: >>My impression from this post >>http://archives.postgresql.org/pgsql-hackers/2006-07/msg00556.php >>was that moving it into core should be doable for 8.3. I hope I >>didn't misunderstand. >> >> > >As I've stated before, it sure would be nice if there was any possible >way this could be done for 8.2. This would be a *huge* feature for >8.2 to have, and it frankly needs all the big-item-yet-easy-to-grasp >features it can get. Is there any way this could be done if we threw money >and/or people at the problem? I'm sure we could come up with both if >the end goal was having built-in text searching for the next release. > > > I suspect the train is too far out of the station. cheers andrew
"Greg Sabino Mullane" <greg@turnstep.com> writes:
> Is there any way this could be done if we threw money
> and/or people at the problem?
No.
I'm constantly amazed at the way people get worked up about
X-is-not-there *after* feature freeze. If you wanted it in 8.2,
the time to be throwing resources at the problem was six months ago.
It's not like Oleg and Teodor haven't let it be known that they
could use financing.
regards, tom lane
> I'm constantly amazed at the way people get worked up about > X-is-not-there *after* feature freeze. If you wanted it in 8.2, > the time to be throwing resources at the problem was six months ago. > It's not like Oleg and Teodor haven't let it be known that they > could use financing. I would say that Tsearch2 is not a deal breaker. I always express: Yes PostgreSQL has Full Text Indexing, it is just not enabled by default. Sincerely, Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
-----Original Message----- From: "Tom Lane" <tgl@sss.pgh.pa.us> To: "Greg Sabino Mullane" <greg@turnstep.com> Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> Sent: 07/08/06 04:42 Subject: Re: [HACKERS] 8.2 features status > I'm constantly amazed at the way people get worked up about > X-is-not-there *after* feature freeze. If you wanted it in 8.2, > the time to be throwing resources at the problem was six months ago. > It's not like Oleg and Teodor haven't let it be known that they > could use financing. The wxWidgets folks have a "bounty" page where potential sponsors can advertise features they want an how much they'll payfor them. Perhaps we should look at such a page, as well as the reverse where hackers can say "I'll do foo, but I need$500 to fund it". Regards, Dave
Tom Lane <tgl@sss.pgh.pa.us> writes: > I don't think there is very much hope of an in-place upgrade for > scenarios involving changes in contents of user tables. In particular, > what of a change that requires more space than before, such as adding a > locale indicator to text fields? There's no guarantee that the data on > an old page will still fit, and there's certainly no hope of something > operating at the xlog level being able to move tuples across pages --- > if nothing else, because it's not in a position to compute new index > entries. I don't see this working for page-at-a-time updates even in a > full backend environment; again, indexes are the killer consideration. > I don't see how to get sane behavior from an index containing some > old-style entries and some new-style ones for a changed datatype. > > As you mentioned, the scenarios that look practical for in-place upgrade > are the ones where only system catalog contents need to change. We've > already discussed this (many times) and agreed that we could live with > restricting user-table changes to happen only once every few releases. What of having support in the backend for two heap formats in each version. That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be a flag in pg_class indicating the heap format for that heap. Then you would be able to upgrade without rewriting all your tables and the only requirement is that sometime prior to the next upgrade you issue a per-table ALTER TABLE that involves rewriting the table such as CLUSTER or ALTER COLUMN TYPE USING. That still requires 2x space but only for a single table at a time which is much better than 2x space for the entire database. It also lets you schedule that job for some point in time when you can arrange to have the extra space. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote: > What of having support in the backend for two heap formats in each version. > That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be > a flag in pg_class indicating the heap format for that heap. Then you would be > able to upgrade without rewriting all your tables and the only requirement is > that sometime prior to the next upgrade you issue a per-table ALTER TABLE that > involves rewriting the table such as CLUSTER or ALTER COLUMN TYPE USING. I don't think you need even go that far. The only disk format change this time I'm aware of is the inet/cidr datatypes. Given most people don't use those, it would have been fairly easy to manage such a transistion. If the new types had been identified with a new OID (probably a good move anyway if the binary send/receive format changes), all that would've needed to happen would be that pg_upgrase would: 1. Under old system, munge the system catalog to add code for new inet type with new OID. Probably needs a shared lib (if you could create type input/output function with pl/pgsql it would help here). 2. Execute ALTER COLUMN TYPE USING to switch to the new type. 3. Shutdown old server 4. Complete catalog changes 5. Startup new version There were no wholesale page format changes, so there's not a lot that needs to be done on that scale. I presume you'd have to do the transistion at a "safe" point, considering there's no way a backup server it going to be able to follow this change... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout <kleptog@svana.org> writes:
> [ concerning handling a change in a single datatype's representation ]
> 1. Under old system, munge the system catalog to add code for new inet
> type with new OID. Probably needs a shared lib (if you could create
> type input/output function with pl/pgsql it would help here).
> 2. Execute ALTER COLUMN TYPE USING to switch to the new type.
> 3. Shutdown old server
> 4. Complete catalog changes
> 5. Startup new version
Probably easier and more flexible just to include both versions of the
datatype in the new release, and tell people they'd better ALTER COLUMN
TYPE sometime before updating to release N+2.
regards, tom lane
On Mon, Aug 07, 2006 at 08:37:14AM -0400, Tom Lane wrote: > Probably easier and more flexible just to include both versions of the > datatype in the new release, and tell people they'd better ALTER COLUMN > TYPE sometime before updating to release N+2. Right, but I wasn't sure if that'd be considered acceptable. So, in a nutshell, if all the other issues of pg_upgrade get ironed out and the only blocker was a change in the on-disk format of a type, including both the old and the new versions in the next major release would be an option seriously considered. Well, that's got to make it easiesr. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Fri, Aug 04, 2006 at 11:57:03AM -0500, Kenneth Marshall wrote: > On Fri, Aug 04, 2006 at 12:40:36PM -0400, Tom Lane wrote: > > "Guillaume Smet" <guillaume.smet@gmail.com> writes: > > > And what about compression of on-disk sorting? > > > > That's purely a performance issue, which some people seem to want > > to define as "not a new feature" ... which is not *my* view of > > what's important ... > > > > regards, tom lane > > > From my point of view, some of these new performance features are > the most important changes in the 8.2 release. We are using other > databases currently because of performance problems that are going > to be addressed in this release. If we can use PostgreSQL instead, > their are new possibilities for reliability and robustness that > our current database choice will not allow. The problem with 'performance improvements' from a PR standpoint is that they're not very sexy unless you've got some numbers to go with them. "8.2 has many performance improvements" - yawn. "On average, users have seen 40% performance improvements in 8.2, and in some cases performance increased over 1000%" - wow! Have you by chance done any performance testing with HEAD that can be compared to 8.1? -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Sat, Aug 05, 2006 at 11:31:24AM -0400, Andrew Dunstan wrote: > Bruce Momjian wrote: > >The fact is, the existing system worked as it should, though it is often > >invisible. We didn't get all the features we wanted, but that isn't > >because the system isn't working. > > Thank you Bruce. That is good to know. Maybe the invisibility has led me > astray. I'll shut up now and see if I can actually get Enums and some > other good stuff done by this time next year. With any luck I won't be > quite as derailed as I was last cycle. > > Also, I hope it's now clear at least that there are many people who want > to see recursive queries. Since some folks are waving the banner of 'open source software' around, why do we have some kind of invisible process for following up on what is and isn't being worked on? In this case, had it been mentioned publicly that recursive queries were getting pushed aside due to "perceived lack of user interest", people would have spoken out about it early on enough that it probably could have made it into 8.2. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Aug 04, 2006 at 09:58:08PM -0400, Tom Lane wrote: > andrew@dunslane.net writes: > > Greg, you are on an utterly wrong track here. Try to look about a bit more > > broadly. > > FWIW, I tend to agree with Greg. This project has gotten to where it is > with a very loose structure, and I think that trying to impose more > structure carries a significant risk of breaking the cooperative > dynamics that have worked so well for us so far. In short, I'm not sure > that we should try to fix something that isn't clearly broken. On the other hand, such an informal system only scales so far. It doesn't seem onerous to me that when someone claims something on the TODO that the TODO reflects that they've claimed it and when. To answer Greg's question about non-commercial projects with a 'formal development process', FreeBSD has someone publish quarterly status reports of where everything's at, and AFAIK there's no commercial sponsorship (except for a few limited cases, like PHK). > I don't object to someone informally polling people who have claimed a > TODO item and not produced any visible progress for awhile. But I think > anything like "thou shalt report in once a week" will merely drive > people away from publicly claiming items, if not drive them away from > doing anything at all. We've already got far too much problem with > lack of visibility, in the sense that people pop up with patches after > not having told anyone they were working on a given problem (much less > posted a preliminary design for feedback, as I desperately wish people > would do before starting to code anything). We should encourage people > to say "I'm working on X", and I fear that putting requirements on them > as soon as they say that will mostly serve to keep them from saying > anything. Perhaps having an easy interface on the TODO would be a way to foster that... an "I want to work on this item" button that would email whoever claimed an item hints like "please come up with a design and discuss it on -hackers before you start coding". And it shouldn't be hard to set that up so that it's not a burden for regular committers (ie: have a list of email addresses not to send those notices out to). BTW, such a system should make it much easier to come up with release notes/major features list for each release. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Fri, Aug 04, 2006 at 10:30:26PM -0400, Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > As I was saying on #postgresql, the current system works well for a > > small group of developers. I don't think there is any arguing that. > > > However, there is a larger group out there, that would likely be willing > > to contribute but we are a bit of a black box, or perhaps we are too > > transparent?? I am not sure which. > > Maybe I'm too much "on the inside", but I see the problem the other way > 'round: too little visibility of what's being done by people who are not > part of the inner circle of developers. > > It's possible that creating a more formal structure would aid these folk > to let the rest of us know what they're doing ... but I think it's at > least as likely that a more formal structure would just drive them away. On projects with bug trackers, it's not uncommon to see someone post a patch out-of-the-blue. It's also not uncommon to see folks who help out with trianging bugs and what-not, but don't necessarily do development. This happens because the tools are there to facilitate it. Perhaps more importantly, people now have the expectation that this is how things work, because it's what most OSS projects do. I'm not trying to bring up the bug tracker war, but it's a good example of how we've effectively thrown up barriers to people who want to contribute because of how different all our processes are. > > I am actually hoping that jabber.postgresql.org would help that in the > > long run. > > Now here I think we might be on the same page. If people pop up on IRC > or jabber or any other communication method and talk about what they're > doing, that fixes the whole problem. I'm for adding anything that > provides an opportunity for people to talk to the community --- I'm not > for trying to force them to talk to the community, 'cause I don't think > that will work very well. Don't put too many eggs in that basket. The problem with jabber and IRC is that once a conversation's over, it's only in the minds of whoever happened to witness it in real-time (sure, people log, but who actually reads IRC logs unless they're looking for something specific). There's a lot of opportunity for *less* communication, because you'll only get info from whoever happens to be watching the channel at that time. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Sat, Aug 05, 2006 at 03:55:17PM -0700, Ron Mayer wrote: > andrew@dunslane.net wrote: > >Ron Mayer wrote: > >>>We have not had that many cases where lack of > >>>communication was a problem. > >>One could say too much communication was the problem this time. > >> > >>I get the impression people implied they'd do something on a TODO > >>and didn't. Arguably the project had been better off if noone > >>had claimed the TODO, so if another company/team/whatever needed > >>the feature badly, they could have worked on it themselves rather > >>than waiting in hope of the feature. > > > >This is just perverse. Surely you are not seriously suggesting that we > >should all develop in secret and then spring miracles fully grown on the > >community? > > Of course not. What I'm suggesting is two things. > > (1) That misleading information is worse than no information; and > that speculative information next to TODOs can do as much harm > discouraging others as it the good it does for communication. Perhaps > a name/assignment/claim on a todo might be nice if someone wanted a > private conversation with someone who knows about a feature; but > even there wouldn't a public discussion on the lists likely be better? Yes, a name by itself is pretty useless. Having an idea of the status of that TODO item is a completely different story. If one month after claiming an item the status is "the old patch I thought would work is junk, this will need to be written from scratch, help wanted!" then clearly anyone who's interested in that item and had the ability to help would know that now was the time to step up. Going one step further, if that item was in a system that allowed people to get emails any time status changed then *everyone* who was interested in that feature would immediately know that help was needed. I fail to see how that's a bad thing. > (2) That much corporate development on BSD projects is indeed > developed in secret. Although may want to be contributed later > either because the company no longer decides it's a trade-secret > or gets tired of maintaining their own fork. Sure, such patches > might need even more discussion and revision than if they were > designed with core - but I think it's a reality that such work > exists. I think this goes way beyond patches... there's got to be dozens of home-grown scripts to handle PITR (for one example). Granted, most of those will be rather specific to an individual environment, but if people would at least share them then someone setting up PITR for the first time wouldn't have to start from scratch. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > Going one step further, if that item was in a system that allowed people > to get emails any time status changed then *everyone* who was interested > in that feature would immediately know that help was needed. I fail to > see how that's a bad thing. Or maybe even more importantly if the status did not change. regards, Lukas
On Mon, Aug 07, 2006 at 06:05:30AM -0400, Gregory Stark wrote: > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > I don't think there is very much hope of an in-place upgrade for > > scenarios involving changes in contents of user tables. In particular, > > what of a change that requires more space than before, such as adding a > > locale indicator to text fields? There's no guarantee that the data on > > an old page will still fit, and there's certainly no hope of something > > operating at the xlog level being able to move tuples across pages --- > > if nothing else, because it's not in a position to compute new index > > entries. I don't see this working for page-at-a-time updates even in a > > full backend environment; again, indexes are the killer consideration. > > I don't see how to get sane behavior from an index containing some > > old-style entries and some new-style ones for a changed datatype. > > > > As you mentioned, the scenarios that look practical for in-place upgrade > > are the ones where only system catalog contents need to change. We've > > already discussed this (many times) and agreed that we could live with > > restricting user-table changes to happen only once every few releases. > > What of having support in the backend for two heap formats in each version. > That is, 8.3 would be able to support 8.2 heaps as well as 8.3. There could be > a flag in pg_class indicating the heap format for that heap. Then you would be > able to upgrade without rewriting all your tables and the only requirement is > that sometime prior to the next upgrade you issue a per-table ALTER TABLE that > involves rewriting the table such as CLUSTER or ALTER COLUMN TYPE USING. > > That still requires 2x space but only for a single table at a time which is > much better than 2x space for the entire database. It also lets you schedule > that job for some point in time when you can arrange to have the extra space. Unless you make it so that the old-version pages get changed to the new version on-the-fly as they get dirtied. And please folks, yes, it's be insane to make the backend deal with more than one old version at a time. I think it's perfectly acceptable to tell folks that if they want to jump 4 major versions at once that they'll have to do it some other way. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Bruce, > The fact is, the existing system worked as it should, though it is often > invisible. We didn't get all the features we wanted, but that isn't > because the system isn't working. But it's exactly the invisibility of the process which people are complaining about. If the postgresql novice, it's darned near impossible to figure our who is working on feature X and what it's status or specification is. Your TODO just doesn't reflect current enough information. We've had this dicussion, or one similar to it, each release for the past 3 releases. Obviously other people feel that there's an issue, even if *you* don't. Also, the current nature of the system has a "bus-factor of 1"; that is, if you get hit by a bus NOBODY else has the information you have in your head (I seem to recall you harassing Marc about similar single-point-of-failure issues). We need a Bruce brain-dump to the web, even if someone else has to do the typing. --Josh
Hi, >> [ concerning handling a change in a single datatype's representation ] > >> 1. Under old system, munge the system catalog to add code for new inet >> type with new OID. Probably needs a shared lib (if you could create >> type input/output function with pl/pgsql it would help here). >> 2. Execute ALTER COLUMN TYPE USING to switch to the new type. >> 3. Shutdown old server >> 4. Complete catalog changes >> 5. Startup new version > > Probably easier and more flexible just to include both versions of the > datatype in the new release, and tell people they'd better ALTER COLUMN > TYPE sometime before updating to release N+2. Sounds very nice to have for me! Add an easy way to see which columns are still in the old format, and upgrading will be so much easier. - Sander
Josh Berkus wrote: > Bruce, > > > The fact is, the existing system worked as it should, though it is often > > invisible. We didn't get all the features we wanted, but that isn't > > because the system isn't working. > > But it's exactly the invisibility of the process which people are > complaining about. If the postgresql novice, it's darned near > impossible to figure our who is working on feature X and what it's > status or specification is. Your TODO just doesn't reflect current > enough information. Right. I think we want people to announce to the lists before they start on a patch. Often we can give advice and if someone else is working on it, they can mention that. I don't think our TODO list will ever allow people to start working effectively without asking the community. > We've had this discussion, or one similar to it, each release for the > past 3 releases. Obviously other people feel that there's an issue, > even if *you* don't. OK, they are free to use other methods. I am not stopping them. The TODO list marks items as done, but doesn't really track who is working on what. > Also, the current nature of the system has a "bus-factor of 1"; that is, > if you get hit by a bus NOBODY else has the information you have in your > head (I seem to recall you harassing Marc about similar > single-point-of-failure issues). We need a Bruce brain-dump to the > web, even if someone else has to do the typing. I know about the same as the community members who pay attention to postings. What I do is to act on that information by contacting developers and asking them to complete their work for feature freeze. Many of my conversations are not appropriate for the public, which is why it is done privately. In fact, the feedback I have gotten from some community members that have heard a little of the discussions I have had with developers is that I am too forceful. I know that doesn't match my often non-critical or even lax handling of things, but I take my community responsibility seriously, and if someone has stated they are working on an item, I expect them to take that pledge seriously as well. As far as people always asking for better tracking, they used to always ask for a roadmap, and when we stated we couldn't because we have no control over developers, they pointed to Mozilla, which had a roadmap at the time (but we know what happened to them.) In the case of recursive queries, I did more than might have even been polite to try to get the developer to complete it. I don't see how changing our system is going to improve it. If you want to change the system, find a system that would have actually done better than what we have in place. Or try a new system, and I will keep doing what I do, and we can see which system works best. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > > > The fact is, the existing system worked as it should, though it is often > > invisible. We didn't get all the features we wanted, but that isn't > > because the system isn't working. > > Well that kind of comes back to my point of better communication. > Perhaps a lot of this discussion could have been avoided if the TODO had > been more... proactive? > > For example: > > Make postmater and postgres options distinct so the postmaster -o > option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 We could do that, but once an item is done I don't see the point in having the date and person's name. You are right that is clearly a different purpose from the TODO list, and if someone wants to track that, it might help things. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > I know about the same as the community members who pay attention to > postings. What I do is to act on that information by contacting > developers and asking them to complete their work for feature freeze. > Many of my conversations are not appropriate for the public, which is > why it is done privately. > > In fact, the feedback I have gotten from some community members that > have heard a little of the discussions I have had with developers is > that I am too forceful. I know that doesn't match my often non-critical > or even lax handling of things, but I take my community responsibility > seriously, and if someone has stated they are working on an item, I > expect them to take that pledge seriously as well. > Is that a response from other developers, or from those you have pressed a bit? Perhaps the fact that the process is so very informal has led people to false expectations anyway. Maybe if we were quite up front about it people would not get upset. "If you say you will work on feature X, expect an occasional ping from someone asking about progress." > As far as people always asking for better tracking, they used to always > ask for a roadmap, and when we stated we couldn't because we have no > control over developers, they pointed to Mozilla, which had a roadmap at > the time (but we know what happened to them.) > This seems to me to be a case of the well known fallacy "post hoc ergo propter hoc". The fact that mozilla had some less than good results does not mean that everything they did was wrong. > In the case of recursive queries, I did more than might have even been > polite to try to get the developer to complete it. I don't see how > changing our system is going to improve it. If you want to change the > system, find a system that would have actually done better than what we > have in place. > > Or try a new system, and I will keep doing what I do, and we can see > which system works best. > > Excellent idea. We don't have to have a one size fits all set of procedures anyway - in fact I think it might be a mistake. Maybe we should select a few major features that people will work on for 8.3 and try a different model. We could then assess things around this time next cycle. cheers andrew
Andrew Dunstan wrote: > Bruce Momjian wrote: > > I know about the same as the community members who pay attention to > > postings. What I do is to act on that information by contacting > > developers and asking them to complete their work for feature freeze. > > Many of my conversations are not appropriate for the public, which is > > why it is done privately. > > > > In fact, the feedback I have gotten from some community members that > > have heard a little of the discussions I have had with developers is > > that I am too forceful. I know that doesn't match my often non-critical > > or even lax handling of things, but I take my community responsibility > > seriously, and if someone has stated they are working on an item, I > > expect them to take that pledge seriously as well. > > > > Is that a response from other developers, or from those you have pressed > a bit? Perhaps the fact that the process is so very informal has led From other developers, not those I have pressed. > people to false expectations anyway. Maybe if we were quite up front > about it people would not get upset. "If you say you will work on > feature X, expect an occasional ping from someone asking about progress." > > > As far as people always asking for better tracking, they used to always > > ask for a roadmap, and when we stated we couldn't because we have no > > control over developers, they pointed to Mozilla, which had a roadmap at > > the time (but we know what happened to them.) > > > > This seems to me to be a case of the well known fallacy "post hoc ergo > propter hoc". The fact that mozilla had some less than good results does > not mean that everything they did was wrong. My point is that we knew the idea was useless for us at the time, even though people asked for it over and over again. > > In the case of recursive queries, I did more than might have even been > > polite to try to get the developer to complete it. I don't see how > > changing our system is going to improve it. If you want to change the > > system, find a system that would have actually done better than what we > > have in place. > > > > Or try a new system, and I will keep doing what I do, and we can see > > which system works best. > > > > > > Excellent idea. We don't have to have a one size fits all set of > procedures anyway - in fact I think it might be a mistake. Maybe we > should select a few major features that people will work on for 8.3 and > try a different model. We could then assess things around this time next > cycle. My big point is that we should choose a system that would have had a better chance of completing features than what we have used in the past, and no one has suggested one. It is just like the bug tracker issue. Many think we need a bugtracker, but when I ask to see a project that has one that is better than what we have now, no one responds. Again, the same criteria should be applied to this issue. If people want to do something different with no objective hope it will be better, feel free to go ahead and do it, but I can't get excited about spending time on it. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: >>> >>> Or try a new system, and I will keep doing what I do, and we can see >>> which system works best. >>> >>> >>> >> Excellent idea. We don't have to have a one size fits all set of >> procedures anyway - in fact I think it might be a mistake. Maybe we >> should select a few major features that people will work on for 8.3 and >> try a different model. We could then assess things around this time next >> cycle. >> > > My big point is that we should choose a system that would have had a > better chance of completing features than what we have used in the past, > and no one has suggested one. > > It is just like the bug tracker issue. Many think we need a bugtracker, > but when I ask to see a project that has one that is better than what we > have now, no one responds. Again, the same criteria should be applied > to this issue. > > If people want to do something different with no objective hope it will > be better, feel free to go ahead and do it, but I can't get excited > about spending time on it. > I give up. You say "try something else and we'll see what works best." I respond "great idea.". Then you say "but it won't work anyway." Is it any wonder people get frustrated? Why give the illusion of an open mind when you have already made up your mind? cheers andrew
Andrew Dunstan wrote: > > My big point is that we should choose a system that would have had a > > better chance of completing features than what we have used in the past, > > and no one has suggested one. > > > > It is just like the bug tracker issue. Many think we need a bugtracker, > > but when I ask to see a project that has one that is better than what we > > have now, no one responds. Again, the same criteria should be applied > > to this issue. > > > > If people want to do something different with no objective hope it will > > be better, feel free to go ahead and do it, but I can't get excited > > about spending time on it. > > > > I give up. You say "try something else and we'll see what works best." > I respond "great idea.". Then you say "but it won't work anyway." Is it > any wonder people get frustrated? Why give the illusion of an open mind > when you have already made up your mind? I am saying other people can try a new system, but I don't have time to try something different when no evidence has been given that it is better (just different). > >>> Or try a new system, and I will keep doing what I do, and we can see > >>> which system works best. I realized when I said, "we can try" that I was being inconsistent, but I was just saying that if others want to try something, go ahead. I personally don't see how it will improve things, but if others want to spend time on it, they are welcome to do that. What I am not willing to do is to abandon a system that works for one that doesn't have evidence it is an improvement, and I don't want to spend time on a new system just for the sake of trying to do two systems at once. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > I am saying other people can try a new system, but I don't have time to > try something different when no evidence has been given that it is > better (just different). Ok, not sure if I am in a position to "call shots" like I am about to, but here it goes: Could everybody who is willing to invest time setting up an alternative contact me so that we can maybe get together in IRC to talk things through and come up with a solid game plan? Maybe with such a plan we can also get Bruce to atleast give us infrequent, even very "raw", brain dumps so that we do not face developers with all too much redundant information seeking. regards, Lukas
>> >> For example: >> >> Make postmater and postgres options distinct so the postmaster -o >> option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 > > > We could do that, but once an item is done I don't see the point in > having the date and person's name. You are right that is clearly a > different purpose from the TODO list, and if someone wants to track > that, it might help things. The idea of the above is not to track when it is done. THe "confirmed" is to track that development is taking place and that we have confirmed from the developer that they think it will be done for 8.2. It is something that in theory would update throughout the cycle 3 or 4 times. You could even have: Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Confirmed for 8.2 | 04/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Trouble encountered | 06/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | PeterE | Asks for help | 08/20/06 Make postmater and postgres options distinct so the postmaster -o option is no longer needed | Alvaro | Confirmed | 09/20/06 Notice the sequence of events. I am not saying the specific statuses are the way to go but it would give a simple way to keep tabs on things without having to create a whole new ball of yarn. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > >> > >> For example: > >> > >> Make postmater and postgres options distinct so the postmaster -o > >> option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 > > > > > > We could do that, but once an item is done I don't see the point in > > having the date and person's name. You are right that is clearly a > > different purpose from the TODO list, and if someone wants to track > > that, it might help things. > > The idea of the above is not to track when it is done. THe "confirmed" > is to track that development is taking place and that we have confirmed > from the developer that they think it will be done for 8.2. Oh, "confirmed" confused me. Maybe "anticipated" or "planned" for 8.2. > It is something that in theory would update throughout the cycle 3 or 4 > times. You could even have: > > Make postmater and postgres options distinct so the postmaster -o > option is no longer needed | PeterE | Confirmed for 8.2 | 04/20/06 > > > Make postmater and postgres options distinct so the postmaster -o > option is no longer needed | PeterE | Trouble encountered | 06/20/06 > > Make postmater and postgres options distinct so the postmaster -o > option is no longer needed | PeterE | Asks for help | 08/20/06 > > Make postmater and postgres options distinct so the postmaster -o > option is no longer needed | Alvaro | Confirmed | 09/20/06 > > Notice the sequence of events. I am not saying the specific statuses are > the way to go but it would give a simple way to keep tabs on things > without having to create a whole new ball of yarn. Interesting idea. If people willing to state they will complete items for the next release, I can add this to the TODO list, and just remove it once the item is in CVS. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
A long time ago, in a galaxy far, far away, bruce@momjian.us (Bruce Momjian) wrote: > Joshua D. Drake wrote: >> >> >> >> For example: >> >> >> >> Make postmater and postgres options distinct so the postmaster -o >> >> option is no longer needed | PeterE | Confirmed for 8.2 | 07/20/06 >> > >> > >> > We could do that, but once an item is done I don't see the point in >> > having the date and person's name. You are right that is clearly a >> > different purpose from the TODO list, and if someone wants to track >> > that, it might help things. >> >> The idea of the above is not to track when it is done. THe "confirmed" >> is to track that development is taking place and that we have confirmed >> from the developer that they think it will be done for 8.2. > > Oh, "confirmed" confused me. Maybe "anticipated" or "planned" for 8.2. > >> It is something that in theory would update throughout the cycle 3 or 4 >> times. You could even have: >> >> Make postmater and postgres options distinct so the postmaster -o >> option is no longer needed | PeterE | Confirmed for 8.2 | 04/20/06 >> >> >> Make postmater and postgres options distinct so the postmaster -o >> option is no longer needed | PeterE | Trouble encountered | 06/20/06 >> >> Make postmater and postgres options distinct so the postmaster -o >> option is no longer needed | PeterE | Asks for help | 08/20/06 >> >> Make postmater and postgres options distinct so the postmaster -o >> option is no longer needed | Alvaro | Confirmed | 09/20/06 >> >> Notice the sequence of events. I am not saying the specific statuses are >> the way to go but it would give a simple way to keep tabs on things >> without having to create a whole new ball of yarn. > > Interesting idea. If people willing to state they will complete items > for the next release, I can add this to the TODO list, and just remove > it once the item is in CVS. Is it forcibly necessary to have that commitment in order for this to be of some use? It seems to me that this would be a reasonably useful way of tracking the progress of TODO items irrespective of any particular commitment to completion in sync with a version. -- (reverse (concatenate 'string "moc.liamg" "@" "enworbbc")) http://linuxdatabases.info/info/languages.html When aiming for the common denominator, be prepared for the occasional division by zero.
Christopher Browne wrote: > >> Make postmater and postgres options distinct so the postmaster -o > >> option is no longer needed | Alvaro | Confirmed | 09/20/06 > >> > >> Notice the sequence of events. I am not saying the specific statuses are > >> the way to go but it would give a simple way to keep tabs on things > >> without having to create a whole new ball of yarn. > > > > Interesting idea. If people willing to state they will complete items > > for the next release, I can add this to the TODO list, and just remove > > it once the item is in CVS. > > Is it forcibly necessary to have that commitment in order for this to > be of some use? > > It seems to me that this would be a reasonably useful way of tracking > the progress of TODO items irrespective of any particular commitment > to completion in sync with a version. The problem comes with someone starting to work on something, then giving up, but if you record it, people think they are still working on it. What happens now is that someone says they want to work on X, and the community tells them that Y might be working on it, and Y gives us a status. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
bruce@momjian.us (Bruce Momjian) writes:
> Christopher Browne wrote:
>> >> Make postmater and postgres options distinct so the postmaster -o
>> >> option is no longer needed | Alvaro | Confirmed | 09/20/06
>> >>
>> >> Notice the sequence of events. I am not saying the specific statuses are
>> >> the way to go but it would give a simple way to keep tabs on things
>> >> without having to create a whole new ball of yarn.
>> >
>> > Interesting idea. If people willing to state they will complete items
>> > for the next release, I can add this to the TODO list, and just remove
>> > it once the item is in CVS.
>>
>> Is it forcibly necessary to have that commitment in order for this to
>> be of some use?
>>
>> It seems to me that this would be a reasonably useful way of tracking
>> the progress of TODO items irrespective of any particular commitment
>> to completion in sync with a version.
>
> The problem comes with someone starting to work on something, then
> giving up, but if you record it, people think they are still working on
> it.
If there is some form of "last updated on" date, that seems to me to
be quite sufficient for the purpose. If the person last working on it
hasn't reported any new news on the item in some substantial period of
time, that's a good implicit indication that something is stalled.
> What happens now is that someone says they want to work on X, and
> the community tells them that Y might be working on it, and Y gives
> us a status.
If what we see in the todo is...
Implement hierarchical queries using ANSI "WITH"/recursive query
system | Someone | Under way | [some date six months ago]
... then those that are interested in seeing this go in can probably
guess that the effort has stalled in that nothing has been worth
commenting on in six months.
This sort of thing is suggestive of having some sort of systematic way
to store structured information. Perhaps one could implement some
sort of database for it... :-)
--
output = ("cbbrowne" "@" "acm.org")
http://cbbrowne.com/info/sgml.html
Rules of the Evil Overlord #21. "I will hire a talented fashion
designer to create original uniforms for my Legions of Terror, as
opposed to some cheap knock-offs that make them look like Nazi
stormtroopers, Roman footsoldiers, or savage Mongol hordes. All were
eventually defeated and I want my troops to have a more positive
mind-set." <http://www.eviloverlord.com/>
> > If what we see in the todo is... > > Implement hierarchical queries using ANSI "WITH"/recursive query > system | Someone | Under way | [some date six months ago] > > ... then those that are interested in seeing this go in can probably > guess that the effort has stalled in that nothing has been worth > commenting on in six months. > > This sort of thing is suggestive of having some sort of systematic way > to store structured information. Perhaps one could implement some > sort of database for it... :-) Mysql should be able to handle something like that nicely. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Bruce, > What happens now is that someone says they want to work on X, and the > community tells them that Y might be working on it, and Y gives us a > status. > What happens now is: A starts working on X. 3 months pass B comes to hackers, spends hours reading the archives, doesn't find X (because they know it by a different name), comes to -hackers and asks "Is anyone working on X?" B waits for 2 weeks without an answer and repeats the question. Hackers E, F and G reply "yes, someone is but I don't remember who, search the archives for keyword X" B searches again, finds original post. B e-mails A and gets no response. B finally offers to take over X Hackers M, L, and N say "sure, but read the archives for spec info" B reads more archives for several hours. There's a LOT of unnecessary overhead in that process: having a simple web app that lists who claimed what todo and when, any status updates if they've voluntarily provided them, and links to archive discussions, we could reduce the above to a 3-step process making it vastly easier for new hackers to get started. To be clear: I'm not trying to solve a problem for existing hackers, for whom the existing system works fine. I'm trying to solve a problem for two groups: new hackers, and users who want to check the plans for new features without combing through the archives. I'll also point out that having an annotated TODO with regular updates would lessen the pressure we get from some parties for a roadmap. --Josh
On Aug 8, 2006, at 17:47 , Josh Berkus wrote: > > What happens now is: > > A starts working on X. > 3 months pass > B comes to hackers, spends hours reading the archives, doesn't find > X (because they know it by a different name), comes to -hackers and > asks "Is anyone working on X?" > B waits for 2 weeks without an answer and repeats the question. > Hackers E, F and G reply "yes, someone is but I don't remember who, > search the archives for keyword X" > B searches again, finds original post. > B e-mails A and gets no response. > B finally offers to take over X > Hackers M, L, and N say "sure, but read the archives for spec info" > B reads more archives for several hours. > > There's a LOT of unnecessary overhead in that process: having a > simple web app that lists who claimed what todo and when, any > status updates if they've voluntarily provided them, and links to > archive discussions, we could reduce the above to a 3-step process > making it vastly easier for new hackers to get started. A developers' wiki with links into the list archives would be great. -M
Josh Berkus wrote: > Bruce, > >> What happens now is that someone says they want to work on X, and the >> community tells them that Y might be working on it, and Y gives us a >> status. >> > > What happens now is: > > A starts working on X. > 3 months pass > B comes to hackers, spends hours reading the archives, doesn't find X > (because they know it by a different name), comes to -hackers and asks > "Is anyone working on X?" > B waits for 2 weeks without an answer and repeats the question. > Hackers E, F and G reply "yes, someone is but I don't remember who, > search the archives for keyword X" I would bet, right about here we loose a whole lot of would be contributors. Just the the questions I had about two todos this year was enough basically give up on doing any work on them. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
OK, seems this should be a separate application, not done in the TODO list, and I am not willing to take on that additional workload. --------------------------------------------------------------------------- Josh Berkus wrote: > Bruce, > > > What happens now is that someone says they want to work on X, and the > > community tells them that Y might be working on it, and Y gives us a > > status. > > > > What happens now is: > > A starts working on X. > 3 months pass > B comes to hackers, spends hours reading the archives, doesn't find X > (because they know it by a different name), comes to -hackers and asks > "Is anyone working on X?" > B waits for 2 weeks without an answer and repeats the question. > Hackers E, F and G reply "yes, someone is but I don't remember who, > search the archives for keyword X" > B searches again, finds original post. > B e-mails A and gets no response. > B finally offers to take over X > Hackers M, L, and N say "sure, but read the archives for spec info" > B reads more archives for several hours. > > There's a LOT of unnecessary overhead in that process: having a simple > web app that lists who claimed what todo and when, any status updates if > they've voluntarily provided them, and links to archive discussions, we > could reduce the above to a 3-step process making it vastly easier for > new hackers to get started. > > To be clear: I'm not trying to solve a problem for existing hackers, for > whom the existing system works fine. I'm trying to solve a problem for > two groups: new hackers, and users who want to check the plans for new > features without combing through the archives. > > I'll also point out that having an annotated TODO with regular updates > would lessen the pressure we get from some parties for a roadmap. > > --Josh -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce, > OK, seems this should be a separate application, not done in the TODO > list, and I am not willing to take on that additional workload. That's my feeling. But I think that we have enough people who are interested to maintain it. If we don't, there was no point anyway. --Josh
bruce wrote: > > OK, seems this should be a separate application, not done in the TODO > list, and I am not willing to take on that additional workload. Let me add that anyone who has CVS commit access or wants to submit TODO patches can keep the TODO updated in this way. --------------------------------------------------------------------------- > > --------------------------------------------------------------------------- > > Josh Berkus wrote: > > Bruce, > > > > > What happens now is that someone says they want to work on X, and the > > > community tells them that Y might be working on it, and Y gives us a > > > status. > > > > > > > What happens now is: > > > > A starts working on X. > > 3 months pass > > B comes to hackers, spends hours reading the archives, doesn't find X > > (because they know it by a different name), comes to -hackers and asks > > "Is anyone working on X?" > > B waits for 2 weeks without an answer and repeats the question. > > Hackers E, F and G reply "yes, someone is but I don't remember who, > > search the archives for keyword X" > > B searches again, finds original post. > > B e-mails A and gets no response. > > B finally offers to take over X > > Hackers M, L, and N say "sure, but read the archives for spec info" > > B reads more archives for several hours. > > > > There's a LOT of unnecessary overhead in that process: having a simple > > web app that lists who claimed what todo and when, any status updates if > > they've voluntarily provided them, and links to archive discussions, we > > could reduce the above to a 3-step process making it vastly easier for > > new hackers to get started. > > > > To be clear: I'm not trying to solve a problem for existing hackers, for > > whom the existing system works fine. I'm trying to solve a problem for > > two groups: new hackers, and users who want to check the plans for new > > features without combing through the archives. > > > > I'll also point out that having an annotated TODO with regular updates > > would lessen the pressure we get from some parties for a roadmap. > > > > --Josh > > -- > Bruce Momjian bruce@momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Josh Berkus wrote: > Bruce, > >> OK, seems this should be a separate application, not done in the TODO >> list, and I am not willing to take on that additional workload. > > That's my feeling. But I think that we have enough people who are > interested to maintain it. If we don't, there was no point anyway. /me raises his hand .. I already have a wiki I use to help maintain the php.net semi official release todo list: http://oss.backendmedia.com/PHPTODO/ But its running on MySQL .. However since it was easy for me to add a subwiki [1] I just did that and gave the world read/write access. I am sure someone else will soon step up and provide something nicer running on PostgreSQL :) regards, Lukas [1] http://oss.backendmedia.com/PGSQLTODO/
Lukas Smith wrote: > Josh Berkus wrote: > > >>OK, seems this should be a separate application, not done in the TODO > >>list, and I am not willing to take on that additional workload. > > > >That's my feeling. But I think that we have enough people who are > >interested to maintain it. If we don't, there was no point anyway. > > /me raises his hand .. I'd vote for a Trac site. I've found it to be a rather useful tool in general, though a bit too simple-minded; integrated Wiki, a simple bugtracker, and roadmap-style reports for people who cares about such stuff. I don't think we'd use the SCM module though. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
> > I'd vote for a Trac site. I've found it to be a rather useful tool in > general, though a bit too simple-minded; integrated Wiki, a simple > bugtracker, and roadmap-style reports for people who cares about such > stuff. > > I don't think we'd use the SCM module though. Oddly enough if anything we could use the SCM module for viewing/changest etc... I already have it regenerating itself over at http://projects.commandprompt.com/public/pgsql Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Can you guys conceive of the thousands of hours of chat you guys are racking upinstead of real hacking because you have an inadequate working structure? This is by far the chattiest and least worthwhile listserv in the bsd world. Bar none. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.394 / Virus Database: 268.10.7/411 - Release Date: 8/7/2006
Joshua D. Drake wrote: > >I don't think we'd use the SCM module though. > > Oddly enough if anything we could use the SCM module for > viewing/changest etc... I already have it regenerating itself over at > http://projects.commandprompt.com/public/pgsql I've found that repository view to be broken at certain spots. I'm not sure if the problem is in cvs2svn or Trac itself. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Joshua D. Drake wrote: > >>> I don't think we'd use the SCM module though. >> Oddly enough if anything we could use the SCM module for >> viewing/changest etc... I already have it regenerating itself over at >> http://projects.commandprompt.com/public/pgsql > > I've found that repository view to be broken at certain spots. I'm not > sure if the problem is in cvs2svn or Trac itself. Likely cvs2svn I would guess it is a large repository. I wouldn't expect it to be used instead of CVS but I could see it being useful for reference from a ticket or todo or something. Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
bruce wrote: > bruce wrote: > > > > OK, seems this should be a separate application, not done in the TODO > > list, and I am not willing to take on that additional workload. > > Let me add that anyone who has CVS commit access or wants to submit > TODO patches can keep the TODO updated in this way. I can also give someone ssh access to my server with the ability to modify only the TODO list. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Quoth jd@commandprompt.com ("Joshua D. Drake"):
> Josh Berkus wrote:
>> Bruce,
>>
>>> What happens now is that someone says they want to work on X, and the
>>> community tells them that Y might be working on it, and Y gives us a
>>> status.
>>>
>> What happens now is:
>> A starts working on X.
>> 3 months pass
>> B comes to hackers, spends hours reading the archives, doesn't find
>> X (because they know it by a different name), comes to -hackers and
>> asks "Is anyone working on X?"
>> B waits for 2 weeks without an answer and repeats the question.
>> Hackers E, F and G reply "yes, someone is but I don't remember who,
>> search the archives for keyword X"
>
> I would bet, right about here we loose a whole lot of would be
> contributors.
>
> Just the the questions I had about two todos this year was enough
> basically give up on doing any work on them.
So I'm to take it that if nobody had *ever* pestered you about those
items, you would have been certain (or "significantly more likely") to
get them done in time for 8.2?
I don't see this being a huge "force for evil"... If people are so
easily discouraged that any attempt to account for what has been
promised will lead to its loss, then it seems to me that they
shouldn't have promised anything in the first place.
It's not a matter of having to send in weekly status reports; I would
think that "pestering" about status more than once every other month
is more than could be done.
And in terms of the "community contract" for taking on TODO items, it
does not strike me as unreasonable to be expected to report back on
status once every couple months. That's not a heavy bureaucratic
burden.
--
output = ("cbbrowne" "@" "linuxfinances.info")
http://linuxfinances.info/info/wp.html
Rules of the Evil Overlord #223. "I will install a fire extinguisher
in every room -- three, if the room contains vital equipment or
volatile chemicals." <http://www.eviloverlord.com/>
Christopher Browne wrote:
> Quoth jd@commandprompt.com ("Joshua D. Drake"):
>> Josh Berkus wrote:
>>> Bruce,
>>>
>>>> What happens now is that someone says they want to work on X, and the
>>>> community tells them that Y might be working on it, and Y gives us a
>>>> status.
>>>>
>>> What happens now is:
>>> A starts working on X.
>>> 3 months pass
>>> B comes to hackers, spends hours reading the archives, doesn't find
>>> X (because they know it by a different name), comes to -hackers and
>>> asks "Is anyone working on X?"
>>> B waits for 2 weeks without an answer and repeats the question.
>>> Hackers E, F and G reply "yes, someone is but I don't remember who,
>>> search the archives for keyword X"
>> I would bet, right about here we loose a whole lot of would be
>> contributors.
>>
>> Just the the questions I had about two todos this year was enough
>> basically give up on doing any work on them.
>
> So I'm to take it that if nobody had *ever* pestered you about those
> items, you would have been certain (or "significantly more likely") to
> get them done in time for 8.2?
I think you are misreading my comment. I said:
>> I would bet, right about here we loose a whole lot of would be
>> contributors.
>>
>> Just the the questions I had about two todos this year was enough
>> basically give up on doing any work on them.
Which was a positive reinforcement to:
>>> A starts working on X.>>> 3 months pass>>> B comes to hackers, spends hours reading the archives, doesn't find>>> X
(becausethey know it by a different name), comes to -hackers and>>> asks "Is anyone working on X?">>> B waits for 2
weekswithout an answer and repeats the question.>>> Hackers E, F and G reply "yes, someone is but I don't remember
who,>>>search the archives for keyword X"
My point was, I was going to work on some todos before feature freeze. I
asked about two specific todos. One of them was badly worded and one of
them did not represent (except in the smallest of ways) what it actually
was.
The first one I bailed out of because it was entirely too much for me to
do in terms of expertise.
The second one turned into a huge debate about not only what the todo
was, but how it was to be implemented and it turned out the todo was all
about pg_dump. Here is that todo:
%Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()
I was under the impression that I would be writing some C or SQL
functions to create some useful tidbits.
It took a couple of days just to get enough information to find out I
was wrong. I was then going to think about possibly sponsoring the todo
instead as it was out of my realm.
I decided to forget about it after waiting for everyone to figure out
what they wanted.
Sincerely,
Joshua D. Drake
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL
solutionssince 1997 http://www.commandprompt.com/
<blockquote type="CITE"><pre> <font color="#000000">> There's a LOT of unnecessary overhead in that process: having a </font> <font color="#000000">> simple web app that lists who claimed what todo and when, any </font> <font color="#000000">> status updates if they've voluntarily provided them, and links to </font> <font color="#000000">> archive discussions, we could reduce the above to a 3-step process </font> <font color="#000000">> making it vastly easier for new hackers to get started.</font> <font color="#000000">A developers' wiki with links into the list archives would be great.</font> </pre></blockquote><br /> My thoughts exactly...<br /><table cellpadding="0" cellspacing="0" width="100%"><tr><td><br /><br/> --<br /> Korry Douglas <a href="mailto:korryd@enterprisedb.com">korryd@enterprisedb.com</a><br /> EnterpriseDB <a href="http://www.enterprisedb.com">http://www.enterprisedb.com</a></td></tr></table>
"Joshua D. Drake" <jd@commandprompt.com> writes:
> My point was, I was going to work on some todos before feature freeze. I
> asked about two specific todos. One of them was badly worded and one of
> them did not represent (except in the smallest of ways) what it actually
> was.
Well, it's certainly the case that some of the TODO items are vaguely
defined (because part of the TODO item is to figure out what to do)
and many of them are too complicated to explain well in one sentence.
But surely that's a different complaint from what's being discussed
in this thread?
What this story does do for me is reinforce the notion that it's
critical for newbie developers to work "in the open", getting feedback
from the lists at an early stage about what they are doing. If you go
off in a corner and develop a patch for a TODO item, you risk having it
rejected because you misunderstood what the TODO item was about.
Maybe the connection is that while thinking about processes, we need
to take into account the need to encourage people to get early
feedback about what they are considering doing.
regards, tom lane
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > My point was, I was going to work on some todos before feature freeze. I > > asked about two specific todos. One of them was badly worded and one of > > them did not represent (except in the smallest of ways) what it actually > > was. > > Well, it's certainly the case that some of the TODO items are vaguely > defined (because part of the TODO item is to figure out what to do) > and many of them are too complicated to explain well in one sentence. > But surely that's a different complaint from what's being discussed > in this thread? I have started adding URLs to the TODO items, which helps. > What this story does do for me is reinforce the notion that it's > critical for newbie developers to work "in the open", getting feedback > from the lists at an early stage about what they are doing. If you go > off in a corner and develop a patch for a TODO item, you risk having it > rejected because you misunderstood what the TODO item was about. Right, and the TODO items change over time as the system improves in other ways. > Maybe the connection is that while thinking about processes, we need > to take into account the need to encourage people to get early > feedback about what they are considering doing. We say that clearly in the developer's FAQ, but it seems it is not enough. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> What this story does do for me is reinforce the notion that it's > critical for newbie developers to work "in the open", getting feedback > from the lists at an early stage about what they are doing. If you go > off in a corner and develop a patch for a TODO item, you risk having it > rejected because you misunderstood what the TODO item was about. I 100% agree with this. Newbie developers should be in the open and it kind of lends itself to my Mentors idea that I mentioned previously. The problem I see is that even if they are in the open we make it fairly difficult to get the information they need to get started. > > Maybe the connection is that while thinking about processes, we need > to take into account the need to encourage people to get early > feedback about what they are considering doing. Agreed. Sincerely, Joshua D. Drake > > regards, tom lane > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
>> Maybe the connection is that while thinking about processes, we need >> to take into account the need to encourage people to get early >> feedback about what they are considering doing. > > We say that clearly in the developer's FAQ, but it seems it is not > enough. I just read the developer's FAQ, and just so were all honest I never had before. :). The developers FAQ is actually quite useful, and helpful except for this one part: Outstanding features are detailed in the TODO list. This is located in doc/TODO in the source distribution or at http://www.postgresql.org/docs/faqs.TODO.html. You can learn more about these features by consulting the archives, the SQL standards and the recommend texts (see 1.10). No one wants to consult the archives. Nor do I believe they should have to. I want a link, directly off the TODO line item that states specific references on one page of what is requested. This is where the wiki comes in. It would also be useful to have possible dependencies. I recently saw a patch come across from Sun, that Tom commented on, something about increase the size of some value to 64bit. I don't recall exactly. Tom's comments although valid (as usual :)) were that the person missed a bunch of stuff having to do with the planner. Some of us may think... well of course that is obvious... Well either the Sun guy was just lazy, or it isn't obvious. I prefer to think it is not obvious. From Bruce's perspective this actually doesn't add too much to the workload. Generate the link, possibly paste some archive urls into the wiki and then someone can come behind and clean up. Of course, who is the clean up guy is always a question. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > > >> Maybe the connection is that while thinking about processes, we need > >> to take into account the need to encourage people to get early > >> feedback about what they are considering doing. > > > > We say that clearly in the developer's FAQ, but it seems it is not > > enough. > > I just read the developer's FAQ, and just so were all honest I never had > before. :). The developers FAQ is actually quite useful, and helpful > except for this one part: > > > Outstanding features are detailed in the TODO list. This is located in > doc/TODO in the source distribution or at > http://www.postgresql.org/docs/faqs.TODO.html. > > You can learn more about these features by consulting the archives, the > SQL standards and the recommend texts (see 1.10). > > No one wants to consult the archives. Nor do I believe they should have > to. I want a link, directly off the TODO line item that states specific > references on one page of what is requested. This is where the wiki > comes in. We now have URLs on the TODO list to the archives, and the next FAQ item is: <H3 id="item1.4">1.4) What do I do after choosing an item to work on?</H3> <P>Send an email to pgsql-hackers with a proposal for what you want to do (assuming your contribution is not trivial).Working in so it is clear what we want people to do. > It would also be useful to have possible dependencies. I recently saw > a patch come across from Sun, that Tom commented on, something about > increase the size of some value to 64bit. I don't recall exactly. > > Tom's comments although valid (as usual :)) were that the person missed > a bunch of stuff having to do with the planner. > > Some of us may think... well of course that is obvious... > > Well either the Sun guy was just lazy, or it isn't obvious. I prefer to > think it is not obvious. > > From Bruce's perspective this actually doesn't add too much to the > workload. Generate the link, possibly paste some archive urls into the > wiki and then someone can come behind and clean up. I am keeping URLs in the TODO list. Why don't people submit improvements to the TODO list, rather than adding more complexity by making a separate wiki for every TODO item? If no one updates the TODO item, what makes you think they are going to do somethin in a wiki? I think the big conclusion we made long ago is that We are never going to have enough detail anywhere that someone is going to be able to work on an item without asking the community. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: > From Bruce's perspective this actually doesn't add too much to the > workload. Generate the link, possibly paste some archive urls into the > wiki and then someone can come behind and clean up. Or better yet, if editing the TODO is more accessible then we're not dependent on one person to maintain it. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
> We now have URLs on the TODO list to the archives, and the next FAQ item > is: > > <H3 id="item1.4">1.4) What do I do after choosing an item to > work on?</H3> > > <P>Send an email to pgsql-hackers with a proposal for what you want > to do (assuming your contribution is not trivial). Working in > > so it is clear what we want people to do. what we want my be part of the problem :) > >> It would also be useful to have possible dependencies. I recently saw >> a patch come across from Sun, that Tom commented on, something about >> increase the size of some value to 64bit. I don't recall exactly. > > I am keeping URLs in the TODO list. Why don't people submit > improvements to the TODO list, rather than adding more complexity by > making a separate wiki for every TODO item? If no one updates the TODO > item, what makes you think they are going to do somethin in a wiki? Do you want a todo list with 4 paragraphs (minimum) for each todo item? > > I think the big conclusion we made long ago is that We are never going > to have enough detail anywhere that someone is going to be able to work > on an item without asking the community. I don't think anyone is expecting that. I think that what we are expecting is that they can ask knowledgeable questions. Would you prefer: Hi, I am a C developer, PostgreSQL Rocks... I want to implement Enums.. Or: Hi, I am a C developer, PostgreSQL Rocks... I would like to take the Enums todo. Here are my specific questions regarding your feature requirements at URL --- Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Jim C. Nasby wrote: > On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: >> From Bruce's perspective this actually doesn't add too much to the >> workload. Generate the link, possibly paste some archive urls into the >> wiki and then someone can come behind and clean up. > > Or better yet, if editing the TODO is more accessible then we're not > dependent on one person to maintain it. To be fair, Bruce has offered to allow that to happen even on his home machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It may not be a web interface that people could log into but it is entirely possible to contribute back with it. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote: > bruce wrote: > > bruce wrote: > > > > > > OK, seems this should be a separate application, not done in the TODO > > > list, and I am not willing to take on that additional workload. > > > > Let me add that anyone who has CVS commit access or wants to submit > > TODO patches can keep the TODO updated in this way. > > I can also give someone ssh access to my server with the ability to > modify only the TODO list. I've never submitted patches for the TODO because it seems pretty silly to go through that much work just to add one line to a file, but being able to change it directly would be a good compromise. I'd be happy to help. Something else that bugs me about the current TODO process is there's a lot of ideas that get brought up but never make it on there. Certainly a lot of them aren't worth putting on there, but there's plenty of items that get left on the floor. It would be nice if there was a better way to deal with these ideas. One possibility: have a 'holding area' (perhaps on a Wiki) where users could add use-cases for these ideas. If there's 'enough demand' (however one defines that), they get promoted to the TODO. Note that this is something geared towards users... things that are obviously useful to -hackers tend to get on the list. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Bruce Momjian wrote: > > > I am keeping URLs in the TODO list. Why don't people submit > improvements to the TODO list, rather than adding more complexity by > making a separate wiki for every TODO item? If no one updates the TODO > item, what makes you think they are going to do somethin in a wiki? > You can update a wiki instantly. Unless you are a committer, updating the TODO list involves sending in a patch. It should be added that the idea that the TODO list has much authority has been decried in the past. > I think the big conclusion we made long ago is that We are never going > to have enough detail anywhere that someone is going to be able to work > on an item without asking the community. > Wikis take a tiny bit of getting used to. But they are extremely useful - they can be used like a kind of online notebook. I find it much easier to make progress notes, reminders, etc in a wiki than in a notebook that I forget to take with me half the time. And they are thus also a great place to record progress. Until you have used this, it seems strange. After you start it doesn't ;-) cheers andrew
Andrew Dunstan wrote: > Joshua D. Drake wrote: >>> >>> Or better yet, if editing the TODO is more accessible then we're not >>> dependent on one person to maintain it. >> >> To be fair, Bruce has offered to allow that to happen even on his home >> machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. >> It may not be a web interface that people could log into but it is >> entirely possible to contribute back with it. >> > > Er, that offer was not to all and sundry as I understood it, but for one > or two people. True :) Joshua D. Drake > > cheers > > andrew > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: >> >> Or better yet, if editing the TODO is more accessible then we're not >> dependent on one person to maintain it. > > To be fair, Bruce has offered to allow that to happen even on his home > machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. > It may not be a web interface that people could log into but it is > entirely possible to contribute back with it. > Er, that offer was not to all and sundry as I understood it, but for one or two people. cheers andrew
Jim C. Nasby wrote: > On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: > > From Bruce's perspective this actually doesn't add too much to the > > workload. Generate the link, possibly paste some archive urls into the > > wiki and then someone can come behind and clean up. > > Or better yet, if editing the TODO is more accessible then we're not > dependent on one person to maintain it. I have offered shell accounts to people, or perhaps we could push the entire TODO list up to a web site, though I am afraid it would be more complicated to update than it is now. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > > > We now have URLs on the TODO list to the archives, and the next FAQ item > > is: > > > > <H3 id="item1.4">1.4) What do I do after choosing an item to > > work on?</H3> > > > > <P>Send an email to pgsql-hackers with a proposal for what you want > > to do (assuming your contribution is not trivial). Working in > > > > so it is clear what we want people to do. > > what we want my be part of the problem :) > > > > >> It would also be useful to have possible dependencies. I recently saw > >> a patch come across from Sun, that Tom commented on, something about > >> increase the size of some value to 64bit. I don't recall exactly. > > > > I am keeping URLs in the TODO list. Why don't people submit > > improvements to the TODO list, rather than adding more complexity by > > making a separate wiki for every TODO item? If no one updates the TODO > > item, what makes you think they are going to do somethin in a wiki? > > Do you want a todo list with 4 paragraphs (minimum) for each todo item? The requirements of the item often change dramatically over time, so who is going to write paragraphs for a single item, especially if it will need updating. > > I think the big conclusion we made long ago is that We are never going > > to have enough detail anywhere that someone is going to be able to work > > on an item without asking the community. > > I don't think anyone is expecting that. I think that what we are > expecting is that they can ask knowledgeable questions. > > Would you prefer: > > Hi, I am a C developer, PostgreSQL Rocks... I want to implement Enums.. > > Or: > > Hi, I am a C developer, PostgreSQL Rocks... I would like to take the > Enums todo. Here are my specific questions regarding your feature > requirements at URL --- Well, few have shown any interest in improving the TODO list, so who is going to be motivated to do even more than we have now? -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > Jim C. Nasby wrote: > > On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote: > >> From Bruce's perspective this actually doesn't add too much to the > >> workload. Generate the link, possibly paste some archive urls into the > >> wiki and then someone can come behind and clean up. > > > > Or better yet, if editing the TODO is more accessible then we're not > > dependent on one person to maintain it. > > To be fair, Bruce has offered to allow that to happen even on his home > machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It Probably, but that's OK. > may not be a web interface that people could log into but it is entirely > possible to contribute back with it. It is very easy to update because it is a simple text file. The HTML is added automatically. Hard to see how it could be easier than that. I can even pull a TODO file from some server location and update from that if you don't want to ssh in but want to put your version at some URL. Or update update the CVS version and email it to me. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Jim C. Nasby wrote: > On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote: > > bruce wrote: > > > bruce wrote: > > > > > > > > OK, seems this should be a separate application, not done in the TODO > > > > list, and I am not willing to take on that additional workload. > > > > > > Let me add that anyone who has CVS commit access or wants to submit > > > TODO patches can keep the TODO updated in this way. > > > > I can also give someone ssh access to my server with the ability to > > modify only the TODO list. > > I've never submitted patches for the TODO because it seems pretty silly > to go through that much work just to add one line to a file, but being > able to change it directly would be a good compromise. I'd be happy to > help. > > Something else that bugs me about the current TODO process is there's a > lot of ideas that get brought up but never make it on there. Certainly > a lot of them aren't worth putting on there, but there's plenty of items > that get left on the floor. It would be nice if there was a better way > to deal with these ideas. I have to be selective because having items we aren't sure we want on there isn't helpful. > One possibility: have a 'holding area' (perhaps on a Wiki) where users > could add use-cases for these ideas. If there's 'enough demand' (however > one defines that), they get promoted to the TODO. Note that this is > something geared towards users... things that are obviously useful to > -hackers tend to get on the list. Yea, that would be interesting, like a pending TODO item list. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>>> It would also be useful to have possible dependencies. I recently saw >>>> a patch come across from Sun, that Tom commented on, something about >>>> increase the size of some value to 64bit. I don't recall exactly. >>> I am keeping URLs in the TODO list. Why don't people submit >>> improvements to the TODO list, rather than adding more complexity by >>> making a separate wiki for every TODO item? If no one updates the TODO >>> item, what makes you think they are going to do somethin in a wiki? >> Do you want a todo list with 4 paragraphs (minimum) for each todo item? > > The requirements of the item often change dramatically over time, so who > is going to write paragraphs for a single item, especially if it will > need updating. O.k. maybe the other people haven't written it loud enough :). That is the whole point of a WIKI. :) >> Or: >> >> Hi, I am a C developer, PostgreSQL Rocks... I would like to take the >> Enums todo. Here are my specific questions regarding your feature >> requirements at URL --- > > Well, few have shown any interest in improving the TODO list, so who is > going to be motivated to do even more than we have now? Bruce you have at least a dozen people right now that are willing to help. :) . I know for a fact that Andrew, Myself, Devrim and Darcy would all be willing to help. I would throw Alvaro in there too but he is probably the busiest of us all and would likely kill me ;) I bet Jim would also be willing to help. Between you, and Tom and Peter and Neil, and Alvaro we have all the engineer brains to help back us up. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Andrew Dunstan wrote: > Bruce Momjian wrote: > > > > > > I am keeping URLs in the TODO list. Why don't people submit > > improvements to the TODO list, rather than adding more complexity by > > making a separate wiki for every TODO item? If no one updates the TODO > > item, what makes you think they are going to do somethin in a wiki? > > > > You can update a wiki instantly. Unless you are a committer, updating > the TODO list involves sending in a patch. > > It should be added that the idea that the TODO list has much authority > has been decried in the past. True, it is my attempt at a TODO, and people do ask for adjustments. > > I think the big conclusion we made long ago is that We are never going > > to have enough detail anywhere that someone is going to be able to work > > on an item without asking the community. > > > > Wikis take a tiny bit of getting used to. But they are extremely useful > - they can be used like a kind of online notebook. I find it much easier > to make progress notes, reminders, etc in a wiki than in a notebook that > I forget to take with me half the time. And they are thus also a great > place to record progress. > > Until you have used this, it seems strange. After you start it doesn't ;-) Sure, but with openness comes cruft, which can be a problem too. Do we want everyone's idea of a useful feature listed? I don't. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Andrew Dunstan wrote: > Joshua D. Drake wrote: > >> > >> Or better yet, if editing the TODO is more accessible then we're not > >> dependent on one person to maintain it. > > > > To be fair, Bruce has offered to allow that to happen even on his home > > machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. > > It may not be a web interface that people could log into but it is > > entirely possible to contribute back with it. > > > > Er, that offer was not to all and sundry as I understood it, but for one > or two people. Well, either people post the changes publically or I trust a few people. I don't trust everyone or the TODO becomes a dumping ground, which I am afraid might happen with a wiki that anyone can update. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>> >> Until you have used this, it seems strange. After you start it doesn't ;-) > > Sure, but with openness comes cruft, which can be a problem too. Do we > want everyone's idea of a useful feature listed? I don't. Why not as long as we have someone who can actually make "approved" todos versus wishlist type stuff. Joshua D. Drake > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > >> Hi, I am a C developer, PostgreSQL Rocks... I would like to take the > >> Enums todo. Here are my specific questions regarding your feature > >> requirements at URL --- > > > > Well, few have shown any interest in improving the TODO list, so who is > > going to be motivated to do even more than we have now? > > Bruce you have at least a dozen people right now that are willing to > help. :) . I know for a fact that Andrew, Myself, Devrim and Darcy would > all be willing to help. I would throw Alvaro in there too but he is > probably the busiest of us all and would likely kill me ;) > > I bet Jim would also be willing to help. Between you, and Tom and Peter > and Neil, and Alvaro we have all the engineer brains to help back us up. OK, so how do you want to help is the question. Having received almost zero ideas for the current TODO list from any of those people, I am waiting for an answer. ;-) -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > >> > >> Until you have used this, it seems strange. After you start it doesn't ;-) > > > > Sure, but with openness comes cruft, which can be a problem too. Do we > > want everyone's idea of a useful feature listed? I don't. > > Why not as long as we have someone who can actually make "approved" > todos versus wishlist type stuff. So you want a wish-list wiki? Great idea, I can link to it from the TODO list. Is that all people want? -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > Joshua D. Drake wrote: >>>> Until you have used this, it seems strange. After you start it doesn't ;-) >>> Sure, but with openness comes cruft, which can be a problem too. Do we >>> want everyone's idea of a useful feature listed? I don't. >> Why not as long as we have someone who can actually make "approved" >> todos versus wishlist type stuff. > > So you want a wish-list wiki? Great idea, I can link to it from the > TODO list. Is that all people want? Do you miss my point (not being sarcastic) about having: 1. Better descriptions about the todo/feature? E.g; feature specification 2. The ability to categorize todo items 3. Heck *your portion* of the TODO would be easily satisfied by having a single line with a link that points to the specific wiki page. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > Bruce Momjian wrote: > > Joshua D. Drake wrote: > >>>> Until you have used this, it seems strange. After you start it doesn't ;-) > >>> Sure, but with openness comes cruft, which can be a problem too. Do we > >>> want everyone's idea of a useful feature listed? I don't. > >> Why not as long as we have someone who can actually make "approved" > >> todos versus wishlist type stuff. > > > > So you want a wish-list wiki? Great idea, I can link to it from the > > TODO list. Is that all people want? > > Do you miss my point (not being sarcastic) about having: > > 1. Better descriptions about the todo/feature? E.g; feature specification I am not sure there is enough churn of TODO items to make larger descriptions worth it. As it is, I have to link to new URLs as the TODO item is clarified. > 2. The ability to categorize todo items Categorize how? > 3. Heck *your portion* of the TODO would be easily satisfied by having a > single line with a link that points to the specific wiki page. But who is going to do that if no one has done anything in the past for the TODO list. I keep asking that. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>> 1. Better descriptions about the todo/feature? E.g; feature specification > > I am not sure there is enough churn of TODO items to make larger > descriptions worth it. As it is, I have to link to new URLs as the TODO > item is clarified. Are you kidding? Did you see the discussion just on the todo item that I tried to do? > >> 2. The ability to categorize todo items > > Categorize how? > >> 3. Heck *your portion* of the TODO would be easily satisfied by having a >> single line with a link that points to the specific wiki page. > > But who is going to do that if no one has done anything in the past for > the TODO list. I keep asking that. I believe that Andrew and I as well as a few others would be willing to do it. Of course I am speaking for Andrew here and I hope he agrees. I also know that Devrim would be more then happy to help out. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > >> 1. Better descriptions about the todo/feature? E.g; feature specification > > > > I am not sure there is enough churn of TODO items to make larger > > descriptions worth it. As it is, I have to link to new URLs as the TODO > > item is clarified. > > Are you kidding? Did you see the discussion just on the todo item that I > tried to do? Right, but the problem was a poor TODO item that needed improvement. I don't think I even remembered the reason for the item, but over time the requirement for the item had changed, I think, or it wasn't clear at the time it was proposed. > > > >> 2. The ability to categorize todo items > > > > Categorize how? > > > >> 3. Heck *your portion* of the TODO would be easily satisfied by having a > >> single line with a link that points to the specific wiki page. > > > > But who is going to do that if no one has done anything in the past for > > the TODO list. I keep asking that. > > I believe that Andrew and I as well as a few others would be willing to > do it. Of course I am speaking for Andrew here and I hope he agrees. I > also know that Devrim would be more then happy to help out. OK, so what do you want to do? -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Heikki Linnakangas wrote: > Bruce Momjian wrote: > > I am keeping URLs in the TODO list. Why don't people submit > > improvements to the TODO list, rather than adding more complexity by > > making a separate wiki for every TODO item? If no one updates the TODO > > item, what makes you think they are going to do somethin in a wiki? > > > > Well, since you asked, here's an patch to add an archive link for a todo > item that I'm working on. (I'll send a separate mail about that shortly). > > *** TODO 9 Aug 2006 02:48:10 -0000 1.1942 > --- TODO 9 Aug 2006 16:20:21 -0000 > *************** > *** 583,588 **** > --- 583,590 ---- > store heap rows in hashed groups, perhaps using a user-supplied > hash function. > > + > http://archives.postgresql.org/pgsql-performance/2004-08/msg00349.php > + > o %Add default clustering to system tables > > To do this, determine the ideal cluster index for each system Added. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
>>>> 3. Heck *your portion* of the TODO would be easily satisfied by having a >>>> single line with a link that points to the specific wiki page. >>> But who is going to do that if no one has done anything in the past for >>> the TODO list. I keep asking that. >> I believe that Andrew and I as well as a few others would be willing to >> do it. Of course I am speaking for Andrew here and I hope he agrees. I >> also know that Devrim would be more then happy to help out. > > OK, so what do you want to do? Oh, sure makes us deliver on our arguments. How very un open source of you :).. Let me get with andrew and I will post back and actual solidified idea. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Bruce Momjian wrote: > I am keeping URLs in the TODO list. Why don't people submit > improvements to the TODO list, rather than adding more complexity by > making a separate wiki for every TODO item? If no one updates the TODO > item, what makes you think they are going to do somethin in a wiki? > Well, since you asked, here's an patch to add an archive link for a todo item that I'm working on. (I'll send a separate mail about that shortly). *** TODO 9 Aug 2006 02:48:10 -0000 1.1942 --- TODO 9 Aug 2006 16:20:21 -0000 *************** *** 583,588 **** --- 583,590 ---- store heap rows in hashed groups, perhaps using a user-supplied hash function. + http://archives.postgresql.org/pgsql-performance/2004-08/msg00349.php + o %Add default clustering to system tables To do this, determine the ideal cluster index for each system Fortunately, when you pick up some thread from the mailing list and make a todo item, you post a reply to that thread with the wording. That makes it easy to find archive links for older todo items, just search the archive for the exact phrase that's on the todo item. For example, I found that thread by searching for "Automatically maintain clustering on a table". It would be useful to go through all the todo items that don't have a URL, search for the discussions in the archives that inspired them, and add links to them. > I think the big conclusion we made long ago is that We are never going > to have enough detail anywhere that someone is going to be able to work > on an item without asking the community. > Agreed. Note also that "the community" might not agree on the way TODO item should be implemented, or even on if a feature is necessary. It's more useful to have a reference to all opinions and ideas relevant to the item, than try prescribe a specific design in the TODO description. BTW: Just to let people know, I've just moved to UK and joined EnterpriseDB, so I'm going to be a lot more active with PostgreSQL in the future. - Heikki
>> >> OK, so what do you want to do? > > Oh, sure makes us deliver on our arguments. How very un open source of > you :).. Let me get with andrew and I will post back and actual > solidified idea. Andrew and I are tabling this until I get back from LinuxWorld. We will be discussing potential ideas to present via email during that week. Joshua D. Drake > > Sincerely, > > Joshua D. Drake > > > > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
> It would also be useful to have possible dependencies. I recently saw
> a patch come across from Sun, that Tom commented on, something about
> increase the size of some value to 64bit. I don't recall exactly.
> Tom's comments although valid (as usual :)) were that the person missed
> a bunch of stuff having to do with the planner.
> Some of us may think... well of course that is obvious...
> Well either the Sun guy was just lazy, or it isn't obvious. I prefer to
> think it is not obvious.
IIRC the problem with that patch was basically that the guy had failed
to search all of the source code for references to the struct he wanted
to modify. This isn't really the fault of the TODO list. It could be
(probably already is) a hint in the developer's FAQ ... but I can't see
putting that sort of generic how-to-develop-a-good-patch kind of info
into every TODO item.
regards, tom lane
-----Original Message----- From: "Jim C. Nasby" <jnasby@pervasive.com> To: "Bruce Momjian" <bruce@momjian.us> Cc: "Josh Berkus" <josh@agliodbs.com>; "Christopher Browne" <cbbrowne@acm.org>; "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> Sent: 09/08/06 17:00 Subject: Re: [HACKERS] 8.2 features status > One possibility: have a 'holding area' (perhaps on a Wiki) Marc was setting up developer.postgresql.org as a developers wiki btw... Dunno what happened to that. Marc? /D
> I am actually hoping that jabber.postgresql.org would help that in the > long run. Jabber's ok, but why not go with SILC instead?
Tom Lane wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: >> It would also be useful to have possible dependencies. I recently saw >> a patch come across from Sun, that Tom commented on, something about >> increase the size of some value to 64bit. I don't recall exactly. >> Tom's comments although valid (as usual :)) were that the person missed >> a bunch of stuff having to do with the planner. >> Some of us may think... well of course that is obvious... >> Well either the Sun guy was just lazy, or it isn't obvious. I prefer to >> think it is not obvious. > > IIRC the problem with that patch was basically that the guy had failed > to search all of the source code for references to the struct he wanted > to modify. This isn't really the fault of the TODO list. It could be > (probably already is) a hint in the developer's FAQ ... but I can't see > putting that sort of generic how-to-develop-a-good-patch kind of info > into every TODO item. I entirely assumed that your references were correct. It was just the only example that I could think up off the top of my head. I was more trying to display a good use of possible dependecies. SIncerely, Joshua D. Drake > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Andrew Hammond wrote: >> I am actually hoping that jabber.postgresql.org would help that in the >> long run. > > Jabber's ok, but why not go with SILC instead? Because everything supports jabber, I only know of SILC and gaim that support SILC :). Also Jabber is pretty much an accepted standard at this point and if we ever decide to open the server it would be nice to talk to gmail etc... Sincerely, Joshua D. Drake > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote: > Well, either people post the changes publically or I trust a few people. > I don't trust everyone or the TODO becomes a dumping ground, which I am > afraid might happen with a wiki that anyone can update. I think that's preventable, especially if we require logins to edit the wiki: while people are free to add content, others can clean up new content and remove dubious additions. Besides, I think the TODO list is speculative by nature: there are plenty of vague or half-baked ideas on the current TODO list, for example. For those who haven't seen it, I think the GCC Wiki is a good model: http://gcc.gnu.org/wiki Personally I'd like to see us move toward maintaining the TODO list and similar developer-oriented information primarily on a wiki. -Neil
On Wed, Aug 09, 2006 at 01:56:42PM -0700, Neil Conway wrote: > On Wed, 2006-08-09 at 12:15 -0400, Bruce Momjian wrote: > > Well, either people post the changes publically or I trust a few people. > > I don't trust everyone or the TODO becomes a dumping ground, which I am > > afraid might happen with a wiki that anyone can update. > > I think that's preventable, especially if we require logins to edit the > wiki: while people are free to add content, others can clean up new > content and remove dubious additions. Besides, I think the TODO list is > speculative by nature: there are plenty of vague or half-baked ideas on > the current TODO list, for example. > > For those who haven't seen it, I think the GCC Wiki is a good model: > > http://gcc.gnu.org/wiki > > Personally I'd like to see us move toward maintaining the TODO list and > similar developer-oriented information primarily on a wiki. Another possibility for "questionabl" TODO items is to allow users to vote on them. Bugzilla (just as an example) allows users to vote on bugs, but they're only given a limited number of votes, so they have to decide what's most important to them. There's also the idea of "TODO purgatory" that I mentioned earlier. The issue I'm thinking of here is that there are things that would be very beneficial for users to have but that much of -hackers won't care about. Right now, we don't do a very good job of identifying those things (IMHO). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Wednesday 09 August 2006 12:12, Bruce Momjian wrote:
> > One possibility: have a 'holding area' (perhaps on a Wiki) where users
> > could add use-cases for these ideas. If there's 'enough demand' (however
> > one defines that), they get promoted to the TODO. Note that this is
> > something geared towards users... things that are obviously useful to
> > -hackers tend to get on the list.
>
> Yea, that would be interesting, like a pending TODO item list.
Wouldn't a thread reply saying something like "Bruce, can we add this as a
TODO with the following wording: blah blah blah" likely suffice?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
Robert Treat wrote: > On Wednesday 09 August 2006 12:12, Bruce Momjian wrote: >>> One possibility: have a 'holding area' (perhaps on a Wiki) where users >>> could add use-cases for these ideas. If there's 'enough demand' (however >>> one defines that), they get promoted to the TODO. Note that this is >>> something geared towards users... things that are obviously useful to >>> -hackers tend to get on the list. >> Yea, that would be interesting, like a pending TODO item list. > > Wouldn't a thread reply saying something like "Bruce, can we add this as a > TODO with the following wording: blah blah blah" likely suffice? > Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see why that is hard or onerous). Plus it is seen by a wide audience, some of whom might not be tracking any wiki (very likely if there end up being several wiki's....) On that note, one nice feature of the current setup, is that the only place you need to look is the TODO, which then (hopefully) points you to a detail or url for more info. To have to check the TODO *and* the wiki is just one more thing to forget IMHO. Cheers Mark
On Wed, 9 Aug 2006, Dave Page wrote: > Marc was setting up developer.postgresql.org as a developers wiki btw... > Dunno what happened to that. > > Marc? Two words: House Hunting ... I have to download the stuff from pgFoundry tomorrow night, already have the database server running locally ... will post something to -www as soon as I have something up and running ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Mark Kirkwood <markir@paradise.net.nz> writes:
> Robert Treat wrote:
>> Wouldn't a thread reply saying something like "Bruce, can we add this as a
>> TODO with the following wording: blah blah blah" likely suffice?
That's pretty much how it's done now ...
> Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't see
> why that is hard or onerous). Plus it is seen by a wide audience, some
> of whom might not be tracking any wiki (very likely if there end up
> being several wiki's....)
Yeah, the main problem I have with TODO-on-a-wiki is the question of
quality control. I've been heard to complain that "the TODO list
consists of everything Bruce thinks is a good idea", but for the most
part things don't get onto TODO without some rough consensus on the
mailing lists --- at least about the nature of the problem, if not
the exact shape of the solution. I'm worried about a wiki having pages
that have not been peer-reviewed at all. In some respects that wouldn't
matter, but what of our hypothetical newbie developer coming along and
taking entries at face value? If you don't know the project well enough
to recognize bogus entries, you could still end up wasting your time
on silly ideas that will get rejected once seen by a wider audience.
regards, tom lane
Tom Lane wrote: > Yeah, the main problem I have with TODO-on-a-wiki is the question of > quality control. I've been heard to complain that "the TODO list > consists of everything Bruce thinks is a good idea", but for the most > part things don't get onto TODO without some rough consensus on the > mailing lists --- at least about the nature of the problem, if not > the exact shape of the solution. I'm worried about a wiki having pages > that have not been peer-reviewed at all. In some respects that wouldn't > matter, but what of our hypothetical newbie developer coming along and > taking entries at face value? If you don't know the project well enough > to recognize bogus entries, you could still end up wasting your time > on silly ideas that will get rejected once seen by a wider audience. To bring up PHP again: http://oss.backendmedia.com/PhP52 This is the todo list for the upcoming 5.2.0 release that is currently in RC1. Most of the todo items in PHP do not need much detail, so this list does not carry much more information than Bruce's list. The wiki has support for ACL's, so I have given various trusted people direct access. Some developers however rely on me for updating the items. As you can see there is a confirmed (as in the release manager has oked the todo) and an under discussion as well as a future 5.x release section. We already have a separate todo list for php 6. A todo list that illustrates the ability to attach more information for a given todo item is my PEAR::MDB2 list in the same wiki: http://oss.backendmedia.com/MDB2/ToDo regards, Lukas
-----Original Message----- From: "Marc G. Fournier" <scrappy@postgresql.org> To: "Dave Page" <dpage@vale-housing.co.uk> Cc: "Jim C. Nasby" <jnasby@pervasive.com>; "Bruce Momjian" <bruce@momjian.us>; "Josh Berkus" <josh@agliodbs.com>; "ChristopherBrowne" <cbbrowne@acm.org>; "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org> Sent: 10/08/06 05:30 Subject: RE: [HACKERS] 8.2 features status > Two words: House Hunting ... Yeuch. Toronto? > ... will post something to -www as soon as I have something up and running ... Ok, cool. /D
Marc, > > ... will post something to -www as > > soon as I have something up and running ... Given that JD is already pulling something into a Trac instance, why don't we just try using that? It has both an issue tracker and a wiki, and it's up and running now. When we have a firmer idea what we want, we may move to different software, but why spend extra effort now? -- Josh Berkus PostgreSQL @ Sun San Francisco
On 8/9/06, Bruce Momjian <bruce@momjian.us> wrote: > Joshua D. Drake wrote: > > >> > > >> Until you have used this, it seems strange. After you start it doesn't ;-) > > > > > > Sure, but with openness comes cruft, which can be a problem too. Do we > > > want everyone's idea of a useful feature listed? I don't. > > > > Why not as long as we have someone who can actually make "approved" > > todos versus wishlist type stuff. > > So you want a wish-list wiki? Great idea, I can link to it from the > TODO list. Is that all people want? just jumping in here but have you considered doing the todo list on a wiki? fwiw, i find the todo list links to be pretty neat and helpful. even for non-developers its a good way to get the feel about whats going on with certain features so they can plan strategies around them. merlin
First, +1 on Josh B.'s point about trying out Trac, since it's already up and running. Josh D., can you just turn that on? (BTW, is trac linked off http://commandprompt.com anywhere? I had to google to find it yesterday...) On Aug 9, 2006, at 11:34 PM, Tom Lane wrote: > Mark Kirkwood <markir@paradise.net.nz> writes: >> Robert Treat wrote: >>> Wouldn't a thread reply saying something like "Bruce, can we add >>> this as a >>> TODO with the following wording: blah blah blah" likely suffice? > > That's pretty much how it's done now ... Robert missed the point I was making... there is value in keeping track of ideas that may not have enough consensus to be a valid TODO yet, but could still be useful. >> Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't >> see >> why that is hard or onerous). Plus it is seen by a wide audience, >> some >> of whom might not be tracking any wiki (very likely if there end up >> being several wiki's....) > > Yeah, the main problem I have with TODO-on-a-wiki is the question of > quality control. I've been heard to complain that "the TODO list > consists of everything Bruce thinks is a good idea", but for the most > part things don't get onto TODO without some rough consensus on the > mailing lists --- at least about the nature of the problem, if not > the exact shape of the solution. I'm worried about a wiki having > pages > that have not been peer-reviewed at all. In some respects that > wouldn't > matter, but what of our hypothetical newbie developer coming along and > taking entries at face value? If you don't know the project well > enough > to recognize bogus entries, you could still end up wasting your time > on silly ideas that will get rejected once seen by a wider audience. Agreed... there needs to be enough consensus and 'critical mass' before something becomes an official TODO. Because of that, we shouldn't allow anyone to edit the TODO wiki (though I do think we shouldn't put the entire responsibility on Bruce). A nice thing about a wiki is it makes it easy for people to collectively work on a use-case and design for a TODO item. One thing that could come out of this is the expectation that TODO items that aren't "inherently obvious" (however you define that) must come with X amount of documentation (use cases, design, what-have-you). This isn't something that should replace discussion on the mailing lists, but I think that being able to point to a wiki page with the finalized info about a TODO item is a lot better than pointing at list archives that are spread all over. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim Nasby wrote: > First, +1 on Josh B.'s point about trying out Trac, since it's > already up and running. Josh D., can you just turn that on? (BTW, is > trac linked off http://commandprompt.com anywhere? I had to google to > find it yesterday...) I just noticed that the code repository on that Trac is broken in more ways than I had realized. For starters it doesn't seem to have the 8.1 branch or tags (apparently it's out of date). Doesn't Trac have a CVS plugin? It will just cause confusion to have a SVN repo that doesn't reflect reality -- which it wouldn't even if it weren't broken. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Jim Nasby wrote: >> First, +1 on Josh B.'s point about trying out Trac, since it's >> already up and running. Josh D., can you just turn that on? (BTW, is >> trac linked off http://commandprompt.com anywhere? I had to google to >> find it yesterday...) > > I just noticed that the code repository on that Trac is broken in more > ways than I had realized. For starters it doesn't seem to have the 8.1 > branch or tags (apparently it's out of date). It doesn't? http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql What are you looking at Alvaro? > > Doesn't Trac have a CVS plugin? No, like the rest of the world, Trac has moved on from CVS ;) > It will just cause confusion to have a > SVN repo that doesn't reflect reality Well sure... but again... what are you looking at, because it looks fine to me? And to be clear, I would only expect that this would be used as a reference, that is all. The ability to link from the wiki directly to a source file or changeset could be useful. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Alvaro Herrera wrote: > Jim Nasby wrote: >> First, +1 on Josh B.'s point about trying out Trac, since it's >> already up and running. Josh D., can you just turn that on? (BTW, is >> trac linked off http://commandprompt.com anywhere? I had to google to >> find it yesterday...) Oh and answer Jim's question. No isn't linked of www.cmd... why? I have no idea ;) It should be on our /community page. > > I just noticed that the code repository on that Trac is broken in more > ways than I had realized. For starters it doesn't seem to have the 8.1 > branch or tags (apparently it's out of date). > > Doesn't Trac have a CVS plugin? It will just cause confusion to have a > SVN repo that doesn't reflect reality -- which it wouldn't even if it > weren't broken. > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote: > No, like the rest of the world, Trac has moved on from CVS ;) There is CVSTrac (www.cvstrac.org), which actually predates Trac. However, is there a reason to use Trac beyond the fact that it is already setup? ISTM we only need a wiki, and don't need the other features of Trac, such as the bug tracker. -Neil
Neil Conway wrote: > On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote: >> No, like the rest of the world, Trac has moved on from CVS ;) > > There is CVSTrac (www.cvstrac.org), which actually predates Trac. > > However, is there a reason to use Trac beyond the fact that it is > already setup? ISTM we only need a wiki, and don't need the other > features of Trac, such as the bug tracker. Well that is certainly the question but the bug tracker could easily turn into a todo list as well. It is a very powerful tool that is relatively flexible. Joshua D. Drake > > -Neil > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Merlin Moncure wrote: > On 8/9/06, Bruce Momjian <bruce@momjian.us> wrote: > > Joshua D. Drake wrote: > > > >> > > > >> Until you have used this, it seems strange. After you start it doesn't ;-) > > > > > > > > Sure, but with openness comes cruft, which can be a problem too. Do we > > > > want everyone's idea of a useful feature listed? I don't. > > > > > > Why not as long as we have someone who can actually make "approved" > > > todos versus wishlist type stuff. > > > > So you want a wish-list wiki? Great idea, I can link to it from the > > TODO list. Is that all people want? > > just jumping in here but have you considered doing the todo list on a > wiki? fwiw, i find the todo list links to be pretty neat and helpful. > even for non-developers its a good way to get the feel about whats > going on with certain features so they can plan strategies around > them. I don't see what a wiki would do for the TODO list except make it take longer for me to update. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Jim Nasby wrote: > First, +1 on Josh B.'s point about trying out Trac, since it's > already up and running. Josh D., can you just turn that on? (BTW, is > trac linked off http://commandprompt.com anywhere? I had to google to > find it yesterday...) > > On Aug 9, 2006, at 11:34 PM, Tom Lane wrote: > > Mark Kirkwood <markir@paradise.net.nz> writes: > >> Robert Treat wrote: > >>> Wouldn't a thread reply saying something like "Bruce, can we add > >>> this as a > >>> TODO with the following wording: blah blah blah" likely suffice? > > > > That's pretty much how it's done now ... > > Robert missed the point I was making... there is value in keeping > track of ideas that may not have enough consensus to be a valid TODO > yet, but could still be useful. It seems some people like the authoritative TODO list, and others want a TODO wiki that they can add stuff to without having to get community buy-in. I have trouble seeing how the wiki doesn't just end up being a blog of ideas, but I see no harm in it as long as it is clear the items haven't passed community review. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> > It seems some people like the authoritative TODO list, and others want a > TODO wiki that they can add stuff to without having to get community > buy-in. I have trouble seeing how the wiki doesn't just end up being a > blog of ideas, but I see no harm in it as long as it is clear the items > haven't passed community review. I think it is a combination of the two. A wiki could be used to discuss ideas for todos, it could be used to describe TODOs in actual detail, it could used (in conjunction with Trac) to be able to document dependecies for todos... etc. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > > > > It seems some people like the authoritative TODO list, and others want a > > TODO wiki that they can add stuff to without having to get community > > buy-in. I have trouble seeing how the wiki doesn't just end up being a > > blog of ideas, but I see no harm in it as long as it is clear the items > > haven't passed community review. > > I think it is a combination of the two. A wiki could be used to discuss > ideas for todos, it could be used to describe TODOs in actual detail, it > could used (in conjunction with Trac) to be able to document dependecies > for todos... etc. But what is it likely to do? I don't think much, but if we can shut it down if we decide it isn't of value (unlike gborg which can't be shut down), I think it is fine to try. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: > I think it is a combination of the two. A wiki could be used to discuss > ideas for todos, it could be used to describe TODOs in actual detail, it > could used (in conjunction with Trac) to be able to document dependecies > for todos... etc. A wiki for *discussion*? I thought email was for that. A wiki is nice to work toghether on a document (in some circumstances). -- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://www.xs4all.nl/~reinoud __________________________________________________
Reinoud van Leeuwen wrote: > On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote: > >> I think it is a combination of the two. A wiki could be used to discuss >> ideas for todos, it could be used to describe TODOs in actual detail, it >> could used (in conjunction with Trac) to be able to document dependecies >> for todos... etc. > > A wiki for *discussion*? I thought email was for that. A wiki is nice to > work toghether on a document (in some circumstances). I dont he meant that. A wiki is a good place to summarize an email discussion, not to actually hold a discussion on the wiki (I have seen it done though .. and its not pretty). regards, Lukas
Neil Conway napsal(a): > However, is there a reason to use Trac beyond the fact that it is > already setup? ISTM we only need a wiki, and don't need the other > features of Trac, such as the bug tracker. I do not agree. How you determine what release fixes the bug now? We have web page and mailing list for bug reporting but there is not any relation between bug, patch and release(s). I think bug tracking is necessary if we want move forward. Zdenek
Joshua D. Drake wrote: > Alvaro Herrera wrote: > >Jim Nasby wrote: > >>First, +1 on Josh B.'s point about trying out Trac, since it's > >>already up and running. Josh D., can you just turn that on? (BTW, is > >>trac linked off http://commandprompt.com anywhere? I had to google to > >>find it yesterday...) > > > >I just noticed that the code repository on that Trac is broken in more > >ways than I had realized. For starters it doesn't seem to have the 8.1 > >branch or tags (apparently it's out of date). > > It doesn't? > > http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql > > What are you looking at Alvaro? Exactly that URL, but this wasn't there when I looked. Maybe it was being regenerated at that time? But I don't know why you are ignoring my comments that it's broken. For an example, go here: http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src Note that the DEVELOPERS file shows a revision 5684, message "Typo fix". Click on that 5684. It'll show you two items, revs 23689 and 5684. First problem, where did that 23689 come from? It wasn't there in the parent dir. Now open that changeset (click on the [23689]). Look at the list of files -- it only has errcodes.sgml in it. No DEVELOPERS, which is the file we want to track! Furthermore, it doesn't show any diff at all. I have looked at it before and I've found these kinds of problems all over the place. If you mark "follow copies" in the box at the right and then click Update, more broken revisions will appear. It's impossible to actually follow the history of a file, because all the entries are bogus. I don't know what on earth is going on but I surely won't waste my time checking that repo again since it seems pretty useless. > >Doesn't Trac have a CVS plugin? > > No, like the rest of the world, Trac has moved on from CVS ;) There are still a lot of projects using CVS. We happen to be one of them. It's pretty damn useful to be able to use the Trac facilities to mark tickets as "fixed in revision such-and-such", which allows us to track more carefully the bugs fixed and the features added. But if the repo is useless, then the rest of Trac loses a lot of its usefulness as well. > And to be clear, I would only expect that this would be used as a > reference, that is all. The ability to link from the wiki directly to a > source file or changeset could be useful. Precisely my point. But if the reference doesn't work, then it's just a plain Wiki like any other. I wouldn't want to waste my time on that. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
>> http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql >> >> What are you looking at Alvaro? > > Exactly that URL, but this wasn't there when I looked. Maybe it was > being regenerated at that time? > Yeah it gets regenerated every 4 hours or so. > But I don't know why you are ignoring my comments that it's broken. For > an example, go here: > > http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src No one is ignoring you. > > Note that the DEVELOPERS file shows a revision 5684, message "Typo fix". > Click on that 5684. It'll show you two items, revs 23689 and 5684. > First problem, where did that 23689 come from? It wasn't there in the > parent dir. Now open that changeset (click on the [23689]). Look at > the list of files -- it only has errcodes.sgml in it. No DEVELOPERS, > which is the file we want to track! Furthermore, it doesn't show any > diff at all. O.k. So it isn't perfect. It isn't like I expected to be. However many people find it useful, myself included. > I don't know what on earth is going on but I surely won't waste my time > checking that repo again since it seems pretty useless. O.k., I am not sure who put oil in your pudding, but nobody is asking you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually what *you* should be using. I would expect that if the SVN/Trac repo were determined to be used it would be used as an entry point and that explicit instructions would also be made that the authoritative source of the code is the CVSWeb repository. >>> Doesn't Trac have a CVS plugin? >> No, like the rest of the world, Trac has moved on from CVS ;) > > There are still a lot of projects using CVS. We happen to be one of > them. Unfortunately that is true. > It's pretty damn useful to be able to use the Trac facilities to mark > tickets as "fixed in revision such-and-such", which allows us to track > more carefully the bugs fixed and the features added. But if the repo > is useless, then the rest of Trac loses a lot of its usefulness as well. O.k. but no one is suggesting that we use Trac as a bug tracker, or at least I wasn't. All I was suggesting was the ability to help viewing of specific files as listed dependencies. > Precisely my point. But if the reference doesn't work, then it's just a > plain Wiki like any other. I wouldn't want to waste my time on that. > I just threw the trac out there because it was already setup. I don't care if anyone uses it or not. Nor am I suggesting that it *should* be used. Lastly if you review this thread you would see that Andrew and I had already decided to wait until after Linux World to actually propose something. It may be Trac it may be something else. For example, I am also looking at Launchpad. There is also something very similar to trac that is built on ruby on rails that also integrates with mailing lists. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
> > I do not agree. How you determine what release fixes the bug now? We > have web page and mailing list for bug reporting but there is not any > relation between bug, patch and release(s). I think bug tracking is > necessary if we want move forward. You can completely forget the idea of having an actual bug tracking system. It has been beaten to death over the years. The developers have very specific requirements that no bug tracker currently adheres to. If you are in the mood for a long, never ending soap opera on the topic I suggest you review the archives :) Sincerely, Joshua D. Drake > > Zdenek > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
Joshua D. Drake wrote: > > Lastly if you review this thread you would see that Andrew and I had > already decided to wait until after Linux World to actually propose > something. > > It is perhaps not surprising, but most of the discussion has been focused on technologies (mailing lists, wikis, bugtrackers, trac, SCM systems, etc.). My view is that these things are at best enablers of good process, but they should not define the processes used. I am trying to spend what little time I can devote to this topic to thinking about the issues I see in human rather than technological terms. cheers andrew
Joshua D. Drake wrote: > > >>http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql > >> > >>What are you looking at Alvaro? > > > >Exactly that URL, but this wasn't there when I looked. Maybe it was > >being regenerated at that time? > > Yeah it gets regenerated every 4 hours or so. Suggestion -- have it create the new copy in a separate directory and when it's complete, rename the new one to the original name. That way the update is "atomic" and users don't get to see an incomplete repo. > >I don't know what on earth is going on but I surely won't waste my time > >checking that repo again since it seems pretty useless. > > O.k., I am not sure who put oil in your pudding, but nobody is asking > you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually > what *you* should be using. Actually I'd *like* to use something better than CVSWeb, because you know what? It sucks and I'd love to have something better. I'd also like to have a decent bugtracker as well. If both repo and bugtracker are integrated it could be very useful. We almost have that with Trac but since it doesn't work, it's so close as to instill hope but because of the bugs it's useless so it brings frustration instead, which is much worse than if it didn't do either. > >It's pretty damn useful to be able to use the Trac facilities to mark > >tickets as "fixed in revision such-and-such", which allows us to track > >more carefully the bugs fixed and the features added. But if the repo > >is useless, then the rest of Trac loses a lot of its usefulness as well. > > O.k. but no one is suggesting that we use Trac as a bug tracker, or at > least I wasn't. All I was suggesting was the ability to help viewing of > specific files as listed dependencies. I am suggesting that. I have heard all the old discussions about not using a bugtracker, but in all fairness, I think some of us have to create critical mass and get something started. Those who don't want to use it can choose not to use it, or they can eventually find that yeah, maybe it's a good idea after all. If no one does anything, nothing will happen. I think the devel version of Trac contains some stuff to be able to handle multiple SCMs. I know there's a Monotone plugin for it at least. Maybe somebody has already written a CVS plugin as well -- I'll have a look. > It may be Trac it may be something else. For example, I am also looking > at Launchpad. There is also something very similar to trac that is built > on ruby on rails that also integrates with mailing lists. Launchpad is proprietary. I don't know about the RoR tool you mention, it may be worth having a look at. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > > O.k. but no one is suggesting that we use Trac as a bug tracker, or at > > least I wasn't. All I was suggesting was the ability to help viewing of > > specific files as listed dependencies. > > I am suggesting that. I have heard all the old discussions about not > using a bugtracker, but in all fairness, I think some of us have to > create critical mass and get something started. Those who don't want to > use it can choose not to use it, or they can eventually find that yeah, > maybe it's a good idea after all. If no one does anything, nothing will > happen. Agreed. Seems enough people are interested that even if I don't think it will work, it is worth a try. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> Actually I'd *like* to use something better than CVSWeb, because you > know what? It sucks and I'd love to have something better. I'd also I am not opposed to actually using taylor or something to do the conversion instead. I just couldn't get it to work. > I think the devel version of Trac contains some stuff to be able to > handle multiple SCMs. I know there's a Monotone plugin for it at least. > Maybe somebody has already written a CVS plugin as well -- I'll have a > look. Well that would make life ALOT easier. > Launchpad is proprietary. I don't know about the RoR tool you mention, > it may be worth having a look at. Launchpad is supposedly releasing their source 10/2006 I believe. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutionssince 1997 http://www.commandprompt.com/
On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote: > I just threw the trac out there because it was already setup. I don't > care if anyone uses it or not. Nor am I suggesting that it *should* be used. > > Lastly if you review this thread you would see that Andrew and I had > already decided to wait until after Linux World to actually propose > something. > > It may be Trac it may be something else. For example, I am also looking > at Launchpad. There is also something very similar to trac that is built > on ruby on rails that also integrates with mailing lists. Does that "rails thing" also have a bug tracker that integrates with mailing lists? IIRC the show-stopper on a bug tracker was finding one that allowed people to still use mailing lists. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: > On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote: > > I just threw the trac out there because it was already setup. I don't > > care if anyone uses it or not. Nor am I suggesting that it *should* be used. > > > > Lastly if you review this thread you would see that Andrew and I had > > already decided to wait until after Linux World to actually propose > > something. > > > > It may be Trac it may be something else. For example, I am also looking > > at Launchpad. There is also something very similar to trac that is built > > on ruby on rails that also integrates with mailing lists. > > Does that "rails thing" also have a bug tracker that integrates with > mailing lists? IIRC the show-stopper on a bug tracker was finding one > that allowed people to still use mailing lists. AFAIU the showstopper was that people wanted to be able to _control_ the bugtracker using email only, i.e. not forcing you to open a web browser to do stuff like adding comments or attachments to a bug, or closing, etc. I'm not sure what you have in mind about "integration" between the mailing lists and the bugtracker, because nothing else I can think of makes much sense. I'm always happy to be illuminated :-) -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Fri, Aug 11, 2006 at 05:27:46PM -0400, Alvaro Herrera wrote: > > Does that "rails thing" also have a bug tracker that integrates with > > mailing lists? IIRC the show-stopper on a bug tracker was finding one > > that allowed people to still use mailing lists. > > AFAIU the showstopper was that people wanted to be able to _control_ the > bugtracker using email only, i.e. not forcing you to open a web browser > to do stuff like adding comments or attachments to a bug, or closing, > etc. The only bugtracker I know that allows that is debbugs, which a nice system IMHO, but I'm sure people have differing opinions about that... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
On Friday 04 August 2006 02:20, Josh Berkus wrote: > <grin> Aren't I, the marketing geek, supposed to be the one whining about > this? [snip] > > * In-place upgrades (pg_upgrade) > BTW, I may get Sun to contribute an engineer for this; will get you posted. Long time no post. This statement really caught my attention; bravo if true upgrading can happen, and someone can be put on it and do it right. As Tom said, a little farther down the thread, we have talked over this many times. I specifically remember, oh, about a dozen times I personally have 'gadflied' this issue. As one who now has a, let's see: [root@pachyderm ~]# du /var/lib/pgsql/data -s 16668528 /var/lib/pgsql/data [root@pachyderm ~]# Yes, a 16GB inventory database, with in-database large object images. Anyway, as one who does not look forward to migrating this the old-fashioned way (I can just imagine how fas^H^H^Hslow a restore of all those large objects is going to be; backup is slow enough (about 50 minutes on this Xeon 2.4GHz box)), in place upgrade would cut this considerably; the database is not a complex one, just a largish one. It's, let's see, only holding a little less than 5,000 items with associated lo images (due to many factors, this is handled through ODBC from Microsoft Access; it is a kludge, and a big one, but it works very smoothly from the users' points of view, where item images are literally 'dragged and dropped' from the digital camera straight to the database). So, anyway, looking forward to seeing some progress in this department... :-) -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
On Fri, 11 Aug 2006, Alvaro Herrera wrote: > I am suggesting that. I have heard all the old discussions about not > using a bugtracker, but in all fairness, I think some of us have to > create critical mass and get something started. I will install anything, and everything, if you can get some sort of concensus on which one to try / go with ... so far, all discussions have ended with nobody coming close to agreeing to anything :) ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Marc G. Fournier wrote: > On Fri, 11 Aug 2006, Alvaro Herrera wrote: > >> I am suggesting that. I have heard all the old discussions about not >> using a bugtracker, but in all fairness, I think some of us have to >> create critical mass and get something started. > > > I will install anything, and everything, if you can get some sort of > concensus on which one to try / go with ... so far, all discussions > have ended with nobody coming close to agreeing to anything :) > > ---- > Marc G. Fournier Hub.Org Networking Services > (http://www.hub.org) > Email . scrappy@hub.org MSN . > scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > quite frankly, I think this group needs the same kind of consensus found in Torvalds kernel group. Is anyone denying their approach gets better results!? No flatline there. JMUASFANPWWMR! -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006
RT is easy to setup/configure/use and works well with PostgreSQL as the backend. CPAN uses it for their bug tracker. Was there a list of features and requirements? Ken On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: > On Fri, 11 Aug 2006, Alvaro Herrera wrote: > > >I am suggesting that. I have heard all the old discussions about not > >using a bugtracker, but in all fairness, I think some of us have to > >create critical mass and get something started. > > I will install anything, and everything, if you can get some sort of > concensus on which one to try / go with ... so far, all discussions have > ended with nobody coming close to agreeing to anything :) > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email . scrappy@hub.org MSN . scrappy@hub.org > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: > RT is easy to setup/configure/use and works well with PostgreSQL > as the backend. CPAN uses it for their bug tracker. Was there a > list of features and requirements? I don't know if we ever came up with one, but I know that the big "deal killer" for a bug tracker is that a lot of hackers don't want to be forced to use a web interface instead of email. So basically, to be accepted, a bug tracker would have to have an effective email interface; one that allowed for updates to an issue coming in via email. Sadly, I don't think such an animal exists. > Ken > > On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: > > On Fri, 11 Aug 2006, Alvaro Herrera wrote: > > > > >I am suggesting that. I have heard all the old discussions about not > > >using a bugtracker, but in all fairness, I think some of us have to > > >create critical mass and get something started. > > > > I will install anything, and everything, if you can get some sort of > > concensus on which one to try / go with ... so far, all discussions have > > ended with nobody coming close to agreeing to anything :) > > > > ---- > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > > Email . scrappy@hub.org MSN . scrappy@hub.org > > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Tue, 15 Aug 2006, Jim C. Nasby wrote: > On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: >> RT is easy to setup/configure/use and works well with PostgreSQL >> as the backend. CPAN uses it for their bug tracker. Was there a >> list of features and requirements? > > I don't know if we ever came up with one, but I know that the big "deal > killer" for a bug tracker is that a lot of hackers don't want to be > forced to use a web interface instead of email. So basically, to be > accepted, a bug tracker would have to have an effective email interface; > one that allowed for updates to an issue coming in via email. Sadly, I > don't think such an animal exists. GnATs :) > >> Ken >> >> On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: >>> On Fri, 11 Aug 2006, Alvaro Herrera wrote: >>> >>>> I am suggesting that. I have heard all the old discussions about not >>>> using a bugtracker, but in all fairness, I think some of us have to >>>> create critical mass and get something started. >>> >>> I will install anything, and everything, if you can get some sort of >>> concensus on which one to try / go with ... so far, all discussions have >>> ended with nobody coming close to agreeing to anything :) >>> >>> ---- >>> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >>> Email . scrappy@hub.org MSN . scrappy@hub.org >>> Yahoo . yscrappy Skype: hub.org ICQ . 7615664 >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 2: Don't 'kill -9' the postmaster >>> >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 6: explain analyze is your friend >> > > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Jim C. Nasby wrote: > On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: > > RT is easy to setup/configure/use and works well with PostgreSQL > > as the backend. CPAN uses it for their bug tracker. Was there a > > list of features and requirements? > > I don't know if we ever came up with one, but I know that the big "deal > killer" for a bug tracker is that a lot of hackers don't want to be > forced to use a web interface instead of email. So basically, to be > accepted, a bug tracker would have to have an effective email interface; > one that allowed for updates to an issue coming in via email. Sadly, I > don't think such an animal exists. We have three candidates already -- debbugs, RT and Gnats. The first has the advantage that was written by hackers, for hackers, so it doesn't have any of the insane "for end users" stuff which annoys so many people around here ;-) (On the other hand it does have some web stuff for generating reports, etc). I haven't used RT much, and I don't know Gnats at all, but I kinda like (the little I have played with) debbugs. Apparently it's rather easy to set up: http://www.benham.net/debbugs/ -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
I've used and use RT. It is web based for admin, but all the transactions are E-Mail based. http://www.bestpractical.com I can also make a test queue on my instance if someone wants to play. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US
In an attempt to throw the authorities off his trail, ler@lerctr.org ("Larry Rosenman") transmitted:
> I've used and use RT. It is web based for admin, but all the transactions
> are E-Mail based.
>
> http://www.bestpractical.com
>
> I can also make a test queue on my instance if someone wants to play.
We've got an RT system at work where some queues are set up to be
"sorta email manageable."
I see in their docs a "CommandByMail" extension that allows doing such
things via email request as:- changing queue- setting status, custom fields- assigning owners, watchers, links
It's not self-evident what the security implications are; I'm not sure
how requests are authenticated.
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxfinances.info/info/finances.html
As of next month, MACLISP "/" will be flushed in favor of "\".
Please update the WORLD.
> We have three candidates already -- debbugs, RT and Gnats. The first > has the advantage that was written by hackers, for hackers, so it > doesn't have any of the insane "for end users" stuff which annoys so > many people around here ;-) (On the other hand it does have some web > stuff for generating reports, etc). Kill me now if I have to use GNATS :) Have you ever tried submitting a bug to the FreeBSD project? *shudder* That said, I'll live :) I have recently totally falling in love with Trac and its complete subversion integration. I'm not sure it supports PostgreSQL, and converting to subversion is probably a little too hardcore at the moment :) Chris
Martha Stewart called it a Good Thing when chris.kingslynne@gmail.com ("Christopher Kings-Lynne") wrote:
>> We have three candidates already -- debbugs, RT and Gnats. The
>> first has the advantage that was written by hackers, for hackers,
>> so it doesn't have any of the insane "for end users" stuff which
>> annoys so many people around here ;-) (On the other hand it does
>> have some web stuff for generating reports, etc).
>
> Kill me now if I have to use GNATS :) Have you ever tried submitting
> a bug to the FreeBSD project? *shudder*
>
> That said, I'll live :)
>
> I have recently totally falling in love with Trac and its complete
> subversion integration. I'm not sure it supports PostgreSQL, and
> converting to subversion is probably a little too hardcore at the
> moment :)
Trac does support PostgreSQL...
The thing I don't understand at this point is what exactly is the
nature of the integration with the SCM.
I don't see it being likely that there will be a deep integration of
the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way
too much change to expect quickly...
--
(reverse (concatenate 'string "ofni.secnanifxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/spreadsheets.html
Any programmer who fails to comply with the standard naming,
formatting, or commenting conventions should be shot. If it so
happens that it is inconvenient to shoot him, then he is to be
politely requested to recode his program in adherence to the above
standard. -- Michael Spier, Digital Equipment Corporation
Christopher Kings-Lynne wrote: >> We have three candidates already -- debbugs, RT and Gnats. The first >> has the advantage that was written by hackers, for hackers, so it >> doesn't have any of the insane "for end users" stuff which annoys so >> many people around here ;-) (On the other hand it does have some web >> stuff for generating reports, etc). > > > Kill me now if I have to use GNATS :) Have you ever tried submitting a > bug to the FreeBSD project? *shudder* > > That said, I'll live :) > > I have recently totally falling in love with Trac and its complete > subversion integration. I'm not sure it supports PostgreSQL, and > converting to subversion is probably a little too hardcore at the > moment :) > > Chris > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > CVS users just rot away or are subverted. -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006
> Trac does support PostgreSQL... > > The thing I don't understand at this point is what exactly is the > nature of the integration with the SCM. > > I don't see it being likely that there will be a deep integration of > the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way > too much change to expect quickly... Basically I have it set up like this: * Trac has built-in browsing of the svn via the web * When I commit, the commit message must have a reference to an open ticket in Trac, eg: "Rearrange blah to fix bad bug. Fixes #745" * In trac's "development timeline", or whatever you can see all the commits against each ticket, and just click on them to see the complete diff for each change set in SVN. * Commit messages can contain full wiki markup, that fully integrates with the wiki that is all thoughout Trac. So, you can have wiki in your commit messages that refers to other bugs, wiki pages, source code files and lines, etc. Basically, Trac is cool. I don't see us adopting it too quickly for PostgreSQL though :P Chris
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> I don't know if we ever came up with one, but I know that the big "deal
> killer" for a bug tracker is that a lot of hackers don't want to be
> forced to use a web interface instead of email. So basically, to be
> accepted, a bug tracker would have to have an effective email interface;
> one that allowed for updates to an issue coming in via email. Sadly, I
> don't think such an animal exists.
That was the position that several of us took five-or-six years ago when
the issue first came up ;-)
These days I doubt there's anyone around the project who refuses to use
a web browser at all. However, I still personally find it much more
convenient to read and respond to mailing-list postings than to have to
go and visit random web pages to find out if there's something I need to
know about. So my current take on this would be that the bug tracker
would have to have a reasonable "output" email capability, but I'd not
necessarily insist on being able to "input" to it by mail. Red Hat's
present bugzilla system could be described that way --- and while I
can't say I'm in love with it, I can deal with it.
Now the other side of the coin is that people are used to being able to
email problem reports to pgsql-bugs, and that's not going to stop
anytime soon. If you don't mind having a bug tracker that is clueless
about some fair-size fraction of what is going on, then you can set up a
system that is impervious to email input. Just don't expect people to
trust it very far.
regards, tom lane
On Aug 16, 2006, at 12:29 , Tom Lane wrote: > So my current take on this would be that the bug tracker > would have to have a reasonable "output" email capability, but I'd not > necessarily insist on being able to "input" to it by mail. Setting aside the email in, how would people feel about Atom or RSS feeds as an alternative for alerts of activity in the system? Michael Glaesemann grzm seespotcode net
Tom Lane wrote: > that the bug tracker would have to have a reasonable "output" email > capability, but I'd not necessarily insist on being able to "input" > to it by mail. Red Hat's present bugzilla system could be described > that way --- and while I can't say I'm in love with it, I can deal > with it. Bugzilla is good in that you need to sign up to report anything (or at least it can be configured that way, not sure), which might reduce the amount of noise. The other systems that have been mentioned have by design little or no barrier of entry, which doesn't seem to be what we want. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Tom, > These days I doubt there's anyone around the project who refuses to use > a web browser at all. However, I still personally find it much more > convenient to read and respond to mailing-list postings than to have to > go and visit random web pages to find out if there's something I need to > know about. So my current take on this would be that the bug tracker > would have to have a reasonable "output" email capability, but I'd not > necessarily insist on being able to "input" to it by mail. Red Hat's > present bugzilla system could be described that way --- and while I > can't say I'm in love with it, I can deal with it. Actually, if that's the only objection it's solved. RT will now allow you to create, comment on, modify, and close bugs by e-mail. And the RT team would be thrilled to have us using it, in theory enough to provide some setup help. There's one thing that RT doesn't do by e-mail (can't remember offhand) but that's a TODO for them so it should be fixed soon. So, if the only real requirement for a bug tracker is that we can handle it 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible. -- Josh Berkus PostgreSQL @ Sun San Francisco
Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: > I'm not sure I follow this, since currently anyone can email the bugs list > or use the bugs -> email form from the website. Are you looking to > increase the barrier for bug reporting? Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most are confused or misdirected users. I don't want to raise that barrier. But I want a higher barrier before something is recorded in the bug tracking system. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On Wednesday 16 August 2006 00:52, Peter Eisentraut wrote:
> Tom Lane wrote:
> > that the bug tracker would have to have a reasonable "output" email
> > capability, but I'd not necessarily insist on being able to "input"
> > to it by mail. Red Hat's present bugzilla system could be described
> > that way --- and while I can't say I'm in love with it, I can deal
> > with it.
>
> Bugzilla is good in that you need to sign up to report anything (or at
> least it can be configured that way, not sure), which might reduce the
> amount of noise. The other systems that have been mentioned have by
> design little or no barrier of entry, which doesn't seem to be what we
> want.
I'm not sure I follow this, since currently anyone can email the bugs list or
use the bugs -> email form from the website. Are you looking to increase the
barrier for bug reporting?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote: > Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: > > I'm not sure I follow this, since currently anyone can email the bugs list > > or use the bugs -> email form from the website. Are you looking to > > increase the barrier for bug reporting? > > Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most > are confused or misdirected users. I don't want to raise that barrier. But > I want a higher barrier before something is recorded in the bug tracking > system. Well, you need to get some agreement on what the bug tracker is for. Is it: a) a front-end to deal with complaints and bugs people have. Is it something you expect end users to look at? This is how Debian uses its bug-tracker, to make sure issues people bring up don't get lost. You can always close the bug if it isn't a real bug. Or: b) a private bug database only used by -hackers to track known outstanding bugs and patches. If you want the latter, the approach would be to keep pgsql-bugs and when a real issue comes up, bounce it to the bug tracker. Any subsequent email discussion should then get logged in the bug report. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Martijn van Oosterhout wrote: > On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote: > >> Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: >> >>> I'm not sure I follow this, since currently anyone can email the bugs list >>> or use the bugs -> email form from the website. Are you looking to >>> increase the barrier for bug reporting? >>> >> Only a small fraction of the new posts on pgsql-bugs are actually bugs. Most >> are confused or misdirected users. I don't want to raise that barrier. But >> I want a higher barrier before something is recorded in the bug tracking >> system. >> > > Well, you need to get some agreement on what the bug tracker is for. Is > it: > > a) a front-end to deal with complaints and bugs people have. Is it > something you expect end users to look at? This is how Debian uses its > bug-tracker, to make sure issues people bring up don't get lost. You > can always close the bug if it isn't a real bug. > > Or: > > b) a private bug database only used by -hackers to track known > outstanding bugs and patches. > > If you want the latter, the approach would be to keep pgsql-bugs and > when a real issue comes up, bounce it to the bug tracker. Any > subsequent email discussion should then get logged in the bug report. > > Have a nice day, > What we are talking about here is bug triage. Weeding out misreports, duplicates etc. is a prime part of this function. It is essential to the health of any functioning bug tracking system. All it takes is resources. Is it worth it? Yes, IMNSHO, but it's a judgement call. One sensible way to do this would be to have a group of suitably qualified volunteers who could perform this function on a roster basis, for, say, a week or a two at a time. That way we could the load off key personnel like Tom (I am in favor of anything which would reduce the demands we place on Tom ;-) ) cheers andrew
On Wed, Aug 16, 2006 at 09:14:47AM -0400, Andrew Dunstan wrote: > What we are talking about here is bug triage. Weeding out misreports, > duplicates etc. is a prime part of this function. It is essential to the > health of any functioning bug tracking system. All it takes is > resources. Is it worth it? Yes, IMNSHO, but it's a judgement call. > > One sensible way to do this would be to have a group of suitably > qualified volunteers who could perform this function on a roster basis, > for, say, a week or a two at a time. That way we could the load off key > personnel like Tom (I am in favor of anything which would reduce the > demands we place on Tom ;-) ) Actually, I'd bet we don't need to put such a formal system in place. I suspect that we'll have users actually looking at the incomming bugs and commenting if they're not valid. As we notice folks who are doing a good job of that, we can give them the privleges to mark bugs as invalid. In the meantime, I'd be glad to help out with 'weeding' incomming bug reports. Depending on the bug tracking system, you can even just let people do this ad-hoc... bugzilla (for example) has an unconfirmed status for new bugs; it would just take people looking at all unconfirmed bugs and marking them appropriately. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote: > Tom, > > > These days I doubt there's anyone around the project who refuses to use > > a web browser at all. However, I still personally find it much more > > convenient to read and respond to mailing-list postings than to have to > > go and visit random web pages to find out if there's something I need to > > know about. So my current take on this would be that the bug tracker > > would have to have a reasonable "output" email capability, but I'd not > > necessarily insist on being able to "input" to it by mail. Red Hat's > > present bugzilla system could be described that way --- and while I > > can't say I'm in love with it, I can deal with it. > > Actually, if that's the only objection it's solved. RT will now allow you to > create, comment on, modify, and close bugs by e-mail. And the RT team would > be thrilled to have us using it, in theory enough to provide some setup help. > There's one thing that RT doesn't do by e-mail (can't remember offhand) but > that's a TODO for them so it should be fixed soon. > > So, if the only real requirement for a bug tracker is that we can handle it > 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible. Does Trac have similar capability? Reason I'm asking is that I think *eventually* it would be very useful to have trac's ability to link bugs, version control, wiki, etc. all together. I know it'll probably be quite some time before that happens, but I'm sure that if we go with RT it'll never happen. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Wed, Aug 16, 2006 at 11:12:11AM +0800, Christopher Kings-Lynne wrote: > >Trac does support PostgreSQL... > > > >The thing I don't understand at this point is what exactly is the > >nature of the integration with the SCM. > > > >I don't see it being likely that there will be a deep integration of > >the PostgreSQL SCM (whatever the SCM platform) with Trac; that's way > >too much change to expect quickly... > > Basically I have it set up like this: > > * Trac has built-in browsing of the svn via the web > > * When I commit, the commit message must have a reference to an open > ticket in Trac, eg: > > "Rearrange blah to fix bad bug. Fixes #745" > > * In trac's "development timeline", or whatever you can see all the > commits against each ticket, and just click on them to see the > complete diff for each change set in SVN. > > * Commit messages can contain full wiki markup, that fully integrates > with the wiki that is all thoughout Trac. So, you can have wiki in > your commit messages that refers to other bugs, wiki pages, source > code files and lines, etc. > > Basically, Trac is cool. I don't see us adopting it too quickly for > PostgreSQL though :P Well, CMD does have it up and running with our repository as sucked out of CVS. Granted, not full functionality, but better than nothing. If Josh turns on the rest of the stuff folks could go play with it and see what they think. BTW, if GNATS is what FreeBSD uses I'd have to agree that it's pretty ugly. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Jim C. Nasby wrote: >On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote: > > >>Tom, >> >> >> >>>These days I doubt there's anyone around the project who refuses to use >>>a web browser at all. However, I still personally find it much more >>>convenient to read and respond to mailing-list postings than to have to >>>go and visit random web pages to find out if there's something I need to >>>know about. So my current take on this would be that the bug tracker >>>would have to have a reasonable "output" email capability, but I'd not >>>necessarily insist on being able to "input" to it by mail. Red Hat's >>>present bugzilla system could be described that way --- and while I >>>can't say I'm in love with it, I can deal with it. >>> >>> >>Actually, if that's the only objection it's solved. RT will now allow you to >>create, comment on, modify, and close bugs by e-mail. And the RT team would >>be thrilled to have us using it, in theory enough to provide some setup help. >>There's one thing that RT doesn't do by e-mail (can't remember offhand) but >>that's a TODO for them so it should be fixed soon. >> >>So, if the only real requirement for a bug tracker is that we can handle it >>100% by e-mail, and integrate it with the pgsql-bugs list, that is possible. >> >> > >Does Trac have similar capability? Reason I'm asking is that I think >*eventually* it would be very useful to have trac's ability to link >bugs, version control, wiki, etc. all together. I know it'll probably be >quite some time before that happens, but I'm sure that if we go with RT >it'll never happen. > > guys, just a sobering refrain from the troll audience -- establishing trac/subversion, as a formal mechanism within postgesql circles, would go a long way toward showing the real world out there that postgresql is professionalizing (I know) and systematizing, etc.ad infinitum. Let everyone identify bugs (keeps novices busy), the more the merrier! New classes of semi-programmers will arise, lets call them buggers, and bugger watchers, unless they know English very well, pretty soon, the system will get used by real programmers, because in the long run, it saves time, and gets results. And folks, lets learn from the goofs of the Freebsd crowd, and maybe even from the Torvalds gang. Michael -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006
On Wed, 16 Aug 2006, Robert Treat wrote: > I'm not sure I follow this, since currently anyone can email the bugs > list or use the bugs -> email form from the website. Are you looking to > increase the barrier for bug reporting? Any garbage (ie. spam) is generally filtered before it hits the -bugs list itself ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664
Andrew Dunstan <andrew@dunslane.net> writes: > What we are talking about here is bug triage. Really? We have a problem with too many bug reports and need a tool to help triage them? That's the first I've heard of that. Think about what tasks you do now and what tool would make it easier. Don't try to invent problems to solve. The Debian system would be basically zero operational change. pgsql-bugs would continue to exist exactly as it does now except it would go through debbugs. Any message there would open a bug report. Anyone responding to say "that's not a bug" would just include the magic phrase to close the bug report too. Anyone responding with questions or data would just respond as normal. The net result would be exactly as it is now except that there would be a tool to view what bugs are still open and look at all the data accumulated on that bug. And you could look back at old bugs to see what version they were fixed in and what the bug looked like to see if it matched the problem a user is having. In short, it's just a tool to solve a problem we actually have (having a convenient archive of data about current and past bugs) without inventing problems to solve with extra process that we aren't already doing anyways. RT can be set up similarly but I'm not sure how much work it would take to make it as seamless. Debbugs has the advantage of working that way pretty much out of the box. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Gregory Stark wrote: > The Debian system would be basically zero operational change. > pgsql-bugs would continue to exist exactly as it does now except it > would go through debbugs. Debbugs is fine and all, but they don't seem to publish their code on a regular basis. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Andrew Dunstan wrote: > What we are talking about here is bug triage. I think we are actually talking about bug *tracking*. > One sensible way to do this would be to have a group of suitably > qualified volunteers who could perform this function on a roster > basis, for, say, a week or a two at a time. Organising a roster, a rotating roster at that, is probably the single most difficult thing you can do in this group. :-) -- Peter Eisentraut http://developer.postgresql.org/~petere/
Martijn van Oosterhout wrote: > If you want the latter, the approach would be to keep pgsql-bugs and > when a real issue comes up, bounce it to the bug tracker. Any > subsequent email discussion should then get logged in the bug report. That's what I want. I don't want the bug tracking system to be the primary frontend to users off the street. Because quite frankly most users are too confused to know what a real bug is. That doesn't mean that I want a closed BTS, but a system that requires sign up and user accounts (like Bugzilla) imposes the right barrier to random abuse in my mind. Note that RT stands for "Request Tracker", which on its face is a different thing, namely a system to do tracking of requests by users off the street. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Let me add that most entries that illict a quick patch or TODO item do not come in through the bugs list, but are rather problems people post to ther lists, or are the result of discussions. --------------------------------------------------------------------------- Gregory Stark wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > > What we are talking about here is bug triage. > > Really? We have a problem with too many bug reports and need a tool to help > triage them? That's the first I've heard of that. > > Think about what tasks you do now and what tool would make it easier. Don't > try to invent problems to solve. > > The Debian system would be basically zero operational change. pgsql-bugs would > continue to exist exactly as it does now except it would go through debbugs. > Any message there would open a bug report. Anyone responding to say "that's > not a bug" would just include the magic phrase to close the bug report too. > > Anyone responding with questions or data would just respond as normal. The net > result would be exactly as it is now except that there would be a tool to view > what bugs are still open and look at all the data accumulated on that bug. And > you could look back at old bugs to see what version they were fixed in and > what the bug looked like to see if it matched the problem a user is having. > > In short, it's just a tool to solve a problem we actually have (having a > convenient archive of data about current and past bugs) without inventing > problems to solve with extra process that we aren't already doing anyways. > > RT can be set up similarly but I'm not sure how much work it would take to > make it as seamless. Debbugs has the advantage of working that way pretty much > out of the box. > > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Greg, > In short, it's just a tool to solve a problem we actually have (having a > convenient archive of data about current and past bugs) without inventing > problems to solve with extra process that we aren't already doing anyways. > > RT can be set up similarly but I'm not sure how much work it would take to > make it as seamless. Debbugs has the advantage of working that way pretty much > out of the box. Debbugs would be good too. I'll quiz the Debian folks here at the conference about what issues there are with the system. FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to open source it for us. ;-) --Josh Berkus
Josh Berkus schrieb: > Greg, > >> In short, it's just a tool to solve a problem we actually have (having a >> convenient archive of data about current and past bugs) without inventing >> problems to solve with extra process that we aren't already doing >> anyways. >> >> RT can be set up similarly but I'm not sure how much work it would >> take to >> make it as seamless. Debbugs has the advantage of working that way >> pretty much >> out of the box. > > Debbugs would be good too. I'll quiz the Debian folks here at the > conference about what issues there are with the system. > > FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to > open source it for us. ;-) What is wrong with for example trac? (trac.edgewall.com) which actually runs on postgres just fine... Regards Tino
> Well, you need to get some agreement on what the bug tracker
> is for. Is
> it:
>
> a) a front-end to deal with complaints and bugs people have.
> Is it something you expect end users to look at? This is how
> Debian uses its bug-tracker, to make sure issues people bring
> up don't get lost. You can always close the bug if it isn't a
> real bug.
If we ask to take all complains, questions and bugs through a
"bugtracker", then it's not a bugtracker. It's more of an "anything goes
tracker", that usually ends up being a web based forum (with mail links)
without all the features that makes a web based forum at all usable.
(And I still think mailinglists are a lot more usable then a web based
forum that *does* have a lot of functionality) This is what IMHO you see
with a *lot* of OSS projects that use bugzilla or whatever. A bazillion
bugs that aren't bugs but discussions or questions etc. Can't speak
about the debian example, haven't checked theirs out.
We already have our mailinglist archives dealing with this. I really
can't see why we'd want to duplicate that and archive things in one more
place.
> Or:
>
> b) a private bug database only used by -hackers to track
> known outstanding bugs and patches.
This, however, I would find very useful - both as a -hacker and as a
user. The point is that only confirmed things should be in there, so
only confirmed things should be returned on searches and whatevr.
(private not as in not visible to the public, but private as in
write-controlled)
As a user/admin/whatever, just listing all bugs affecting an
installation ("8.0 branch after 8.0.4" for example) so I can evaluate if
I need to upgrade is a *very good* thing to be able to do. I realise
this adds a bit of overhead for the people doing commits, but it should
be possible to integrate that to a point where the overhead is
minimized. And it would be a big win.
As a -hacker, not needing to keep my own "mailbox format" or "textfile
format" bugtracker, and being able to easily find something that would
list all communications about a certain bug (*with* links to the
archives, where the actual information would still be) would definitly
be a win.
Tom seems to be able to remember everything in his head and whip out the
old commit messages in no time, but I certainly can't ;-)
> If you want the latter, the approach would be to keep
> pgsql-bugs and when a real issue comes up, bounce it to the
> bug tracker. Any subsequent email discussion should then get
> logged in the bug report.
IMHO, that's the best solution. Except the email discussion lives just
fine in the archives, and should be linked back into the tracker if
possible instead of copied there.
There's also the possibility of
c)
just using a "bugtracker style interface" as a presentation method over
whatever we have now. All our mails go into the archives. If we make
sure that all mails about a certain bug are flagged with that bug id
(easy enough if it's submitted through the bugs form, I'm sure there can
be some voodoo done in majordomo to have it send actual posts to the
lists through a script that would do a similar thing), then a tool could
fairly easy crawl the archives and pick up all emails related to that
bug, and present them separatly. Then if we can convince the committers
to always include the bug id when a commit is done for a bug, we'd have
the commit messages in the tracker as well... You'd still need someone
to fill out metadata like "versions affected" if we want that, but the
effort on the "main developers" would pretty much just be to remember to
keep the bug id around.
//Magnus
> > I'm not sure I follow this, since currently anyone can > email the bugs > > list or use the bugs -> email form from the website. Are > you looking > > to increase the barrier for bug reporting? > > Any garbage (ie. spam) is generally filtered before it hits > the -bugs list itself Spam: Yes. Non-bug-reports: Absolutely not. The majority of things on -bugs are *not* bug reports, from what I can tell... //Magnus
On Thu, Aug 17, 2006 at 06:48:54PM +0200, Magnus Hagander wrote: > This, however, I would find very useful - both as a -hacker and as a > user. The point is that only confirmed things should be in there, so > only confirmed things should be returned on searches and whatevr. > (private not as in not visible to the public, but private as in > write-controlled) I've yet to see a bug tracker that doesn't make it trivial to identify bugs that were marked as invalid (ie: not a real bug). The only difference is that you actually have to mark them as such. Given the fairly low volume of non-bugs that come in through the web form, I don't think marking them will be a big issue (and as I mentioned previously, it's something that doesn't have to be done by anyone who's a committer). In fact, having such a system would probably save committers time, because they could look only at bugs that had been confirmed as valid by someone else. Right now, every time a non-bug gets filed dozens of people end up reading the report before they hit delete. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
Magnus Hagander wrote: > > > I'm not sure I follow this, since currently anyone can > > email the bugs > > > list or use the bugs -> email form from the website. Are > > you looking > > > to increase the barrier for bug reporting? > > > > Any garbage (ie. spam) is generally filtered before it hits > > the -bugs list itself > > Spam: Yes. > Non-bug-reports: Absolutely not. > > The majority of things on -bugs are *not* bug reports, from what I can > tell... And many bugs appear on other lists, so again, it isn't just that the bugs list isn't just bugs, but that bugs appear elsewhere. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
> These days I doubt there's anyone around the project who > refuses to use a web browser at all. However, I still > personally find it much more convenient to read and respond > to mailing-list postings than to have to go and visit random > web pages to find out if there's something I need to know > about. So my current take on this would be that the bug > tracker would have to have a reasonable "output" email > capability, but I'd not necessarily insist on being able to > "input" to it by mail. Red Hat's present bugzilla system > could be described that way --- and while I can't say I'm in > love with it, I can deal with it. Doesn't bugzilla insist on sending you the complete bug every time? Or am I confusing it with the gforge/pgfoundry trackers? If so, then it's a really bad idea, IMHO, since it sends new copies out all the time... > Now the other side of the coin is that people are used to > being able to email problem reports to pgsql-bugs, and that's > not going to stop anytime soon. If you don't mind having a > bug tracker that is clueless about some fair-size fraction of > what is going on, then you can set up a system that is > impervious to email input. Just don't expect people to trust > it very far. Whatever system is used (if one is), there definitly needs to be some people looking over what comes in on the mailinglists (or on IRC, for that matter) and pipe it off to the tracker in case it's not already there. Unless we want to force everybody to use *just* a web interface (which would be a horrible idea, btw), we won't get 100% coverage. (btw, istm that people email at least as many bugs directly to -hackers, or to -general or whatever, because the end user *does not know* when it's a bug from when it's a misconfiguration, or misunderstanding of the issue or whatnot) //Magnus
> > This, however, I would find very useful - both as a -hacker > and as a > > user. The point is that only confirmed things should be in > there, so > > only confirmed things should be returned on searches and whatevr. > > (private not as in not visible to the public, but private as in > > write-controlled) > > I've yet to see a bug tracker that doesn't make it trivial to > identify bugs that were marked as invalid (ie: not a real > bug). The only difference is that you actually have to mark > them as such. Given the fairly low volume of non-bugs that > come in through the web form, I don't think marking them will > be a big issue (and as I mentioned previously, it's something > that doesn't have to be done by anyone who's a committer). In > fact, having such a system would probably save committers > time, because they could look only at bugs that had been > confirmed as valid by someone else. Right now, every time a > non-bug gets filed dozens of people end up reading the report > before they hit delete. Well, if it's invalid, it shouldn't be in there. But I guess you could just go ahead and delete it at that point - but it's work that someone has to do. But when I look at a lot of OSS projects out there, I see hundreds (if not thousands or tens of thousands for large projects) of bugs that are just dangling. That likely aren't bugs, but they are listed as such. Could definitly be that it's just that the system isn't maintained properly, but if so many others have failed, there's definitly a nontrivial risk that we would fail as well. //Magnus
On Wed, Aug 16, 2006 at 06:52:21AM +0200, Peter Eisentraut wrote: > Tom Lane wrote: > > that the bug tracker would have to have a reasonable "output" email > > capability, but I'd not necessarily insist on being able to "input" > > to it by mail. Red Hat's present bugzilla system could be described > > that way --- and while I can't say I'm in love with it, I can deal > > with it. > > Bugzilla is good in that you need to sign up to report anything (or at > least it can be configured that way, not sure), which might reduce the > amount of noise. The other systems that have been mentioned have by > design little or no barrier of entry, which doesn't seem to be what we > want. > We put an anti-spam solution w/quarantine in front of our RT E-mail instance (DSPAM) and it is very effective at keeping the cruft out of the tracking system. You can also do basic processing on incoming messages to weed out the "non-bugs". We put them in a General start queue and then move them to other working queues when they meet whatever threshold you set. The General queue could also automatically timeout/close tickets that stay in the queue for a certain period of time. Ken
On Wed, Aug 16, 2006 at 01:22:43PM +0900, Michael Glaesemann wrote: > > On Aug 16, 2006, at 12:29 , Tom Lane wrote: > > >So my current take on this would be that the bug tracker > >would have to have a reasonable "output" email capability, but I'd not > >necessarily insist on being able to "input" to it by mail. > > Setting aside the email in, how would people feel about Atom or RSS > feeds as an alternative for alerts of activity in the system? > > Michael Glaesemann > grzm seespotcode net > > RT has an RSS output. A particular set of criteria can be used to populate it on an individual basis. Ken
RT has an E-mail interface. That was one of our considerations when we used it to replace our aging trouble ticket system. What does the interface need to do? RT's is pretty flexible. Ken On Tue, Aug 15, 2006 at 04:59:46PM -0500, Jim C. Nasby wrote: > On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote: > > RT is easy to setup/configure/use and works well with PostgreSQL > > as the backend. CPAN uses it for their bug tracker. Was there a > > list of features and requirements? > > I don't know if we ever came up with one, but I know that the big "deal > killer" for a bug tracker is that a lot of hackers don't want to be > forced to use a web interface instead of email. So basically, to be > accepted, a bug tracker would have to have an effective email interface; > one that allowed for updates to an issue coming in via email. Sadly, I > don't think such an animal exists. > > > Ken > > > > On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote: > > > On Fri, 11 Aug 2006, Alvaro Herrera wrote: > > > > > > >I am suggesting that. I have heard all the old discussions about not > > > >using a bugtracker, but in all fairness, I think some of us have to > > > >create critical mass and get something started. > > > > > > I will install anything, and everything, if you can get some sort of > > > concensus on which one to try / go with ... so far, all discussions have > > > ended with nobody coming close to agreeing to anything :) > > > > > > ---- > > > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > > > Email . scrappy@hub.org MSN . scrappy@hub.org > > > Yahoo . yscrappy Skype: hub.org ICQ . 7615664 > > > > > > ---------------------------(end of broadcast)--------------------------- > > > TIP 2: Don't 'kill -9' the postmaster > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 6: explain analyze is your friend > > > > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 >
On Thu, Aug 17, 2006 at 07:00:21PM +0200, Magnus Hagander wrote: > > These days I doubt there's anyone around the project who > > refuses to use a web browser at all. However, I still > > personally find it much more convenient to read and respond > > to mailing-list postings than to have to go and visit random > > web pages to find out if there's something I need to know > > about. So my current take on this would be that the bug > > tracker would have to have a reasonable "output" email > > capability, but I'd not necessarily insist on being able to > > "input" to it by mail. Red Hat's present bugzilla system > > could be described that way --- and while I can't say I'm in > > love with it, I can deal with it. > > Doesn't bugzilla insist on sending you the complete bug every time? Or > am I confusing it with the gforge/pgfoundry trackers? If so, then it's a > really bad idea, IMHO, since it sends new copies out all the time... No. In fact, it's one of the few that doesn't do that. I agree that sending the whole bug is a really dumb idea. > > Now the other side of the coin is that people are used to > > being able to email problem reports to pgsql-bugs, and that's > > not going to stop anytime soon. If you don't mind having a > > bug tracker that is clueless about some fair-size fraction of > > what is going on, then you can set up a system that is > > impervious to email input. Just don't expect people to trust > > it very far. > > Whatever system is used (if one is), there definitly needs to be some > people looking over what comes in on the mailinglists (or on IRC, for > that matter) and pipe it off to the tracker in case it's not already > there. Unless we want to force everybody to use *just* a web interface > (which would be a horrible idea, btw), we won't get 100% coverage. > > (btw, istm that people email at least as many bugs directly to -hackers, > or to -general or whatever, because the end user *does not know* when > it's a bug from when it's a misconfiguration, or misunderstanding of the > issue or whatnot) Yes, there will have to be cross-checking. However, in practice, I've found that users will enter the bug themselves if you send them a reply asking them to, so I don't think it should pose too much additional burden. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote: > > I've yet to see a bug tracker that doesn't make it trivial to > > identify bugs that were marked as invalid (ie: not a real > > bug). The only difference is that you actually have to mark > Well, if it's invalid, it shouldn't be in there. But I guess you could > just go ahead and delete it at that point - but it's work that someone > has to do. > > But when I look at a lot of OSS projects out there, I see hundreds (if > not thousands or tens of thousands for large projects) of bugs that are > just dangling. That likely aren't bugs, but they are listed as such. > Could definitly be that it's just that the system isn't maintained > properly, but if so many others have failed, there's definitly a > nontrivial risk that we would fail as well. I always see people getting bent out-of-shape about bug trackers that contain a lot of invalid bug reports and I never understand why. Most of the ones I've seen hide those by default, so it's not like you really have to deal with them. And having them still exist is useful... for example, if you keep seeing the same thing come up over and over you know there's probably an issue of some kind (ie: documentation). Plus, if users are encouraged to search for the bug they found before reporting it and *that* search by default includes invalid bugs then it's more likely that the user will find the question (and answer) themselves. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Magnus Hagander" <mha@sollentuna.net> writes:
>> ... Red Hat's present bugzilla system
>> could be described that way --- and while I can't say I'm in
>> love with it, I can deal with it.
> Doesn't bugzilla insist on sending you the complete bug every time?
Nope, it just sends the changes/additions. Other than the lack of a
direct email input method, I find BZ quite usable. Josh was just
complaining that its source code is a mess (dunno, haven't looked)
but other than that I think it's a definite possibility, just because
so many people are already familiar with it.
> Whatever system is used (if one is), there definitly needs to be some
> people looking over what comes in on the mailinglists (or on IRC, for
> that matter) and pipe it off to the tracker in case it's not already
> there.
Sure; we'd need a few volunteers handling that, no matter what software
we pick.
regards, tom lane
Jim C. Nasby wrote: > On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote: > >>> I've yet to see a bug tracker that doesn't make it trivial to >>> identify bugs that were marked as invalid (ie: not a real >>> bug). The only difference is that you actually have to mark >>> >> Well, if it's invalid, it shouldn't be in there. But I guess you could >> just go ahead and delete it at that point - but it's work that someone >> has to do. >> >> But when I look at a lot of OSS projects out there, I see hundreds (if >> not thousands or tens of thousands for large projects) of bugs that are >> just dangling. That likely aren't bugs, but they are listed as such. >> Could definitly be that it's just that the system isn't maintained >> properly, but if so many others have failed, there's definitly a >> nontrivial risk that we would fail as well. >> > > I always see people getting bent out-of-shape about bug trackers that > contain a lot of invalid bug reports and I never understand why. Most of > the ones I've seen hide those by default, so it's not like you really > have to deal with them. And having them still exist is useful... for > example, if you keep seeing the same thing come up over and over you > know there's probably an issue of some kind (ie: documentation). Plus, > if users are encouraged to search for the bug they found before > reporting it and *that* search by default includes invalid bugs then > it's more likely that the user will find the question (and answer) > themselves. > If the crud isn't handled some way then the system isn't nearly as much use to you. That's why I believe some sort of process for keeping the bug tracking system reasonably clean is necessary. cheers andrew
Tom Lane wrote: >> Doesn't bugzilla insist on sending you the complete bug every time? >> > > Nope, it just sends the changes/additions. Other than the lack of a > direct email input method, I find BZ quite usable. Josh was just > complaining that its source code is a mess (dunno, haven't looked) > but other than that I think it's a definite possibility, just because > so many people are already familiar with it. > > One other point about BZ - several community members (including me) put in some effort to make the trunk version run on postgres, which it now does, and quite well. So our using it would be a nice return compliment. The source code might well be a mess, but for the most part it can just be treated as a black box. >> Whatever system is used (if one is), there definitly needs to be some >> people looking over what comes in on the mailinglists (or on IRC, for >> that matter) and pipe it off to the tracker in case it's not already >> there. >> > > Sure; we'd need a few volunteers handling that, no matter what software > we pick. > > > You betcha. I'm glad we agree about that. cheers andrew
Tom Lane wrote: > "Magnus Hagander" <mha@sollentuna.net> writes: > >> ... Red Hat's present bugzilla system > >> could be described that way --- and while I can't say I'm in > >> love with it, I can deal with it. > > > Doesn't bugzilla insist on sending you the complete bug every time? > > Nope, it just sends the changes/additions. Other than the lack of a > direct email input method, I find BZ quite usable. Josh was just > complaining that its source code is a mess (dunno, haven't looked) > but other than that I think it's a definite possibility, just because > so many people are already familiar with it. Have you tried to use debbugs? I agree with Greg Stark that it's a better fit for our current procedure, while enabling better traceability. For an example, see http://bugs.debian.org. There are three links there pointing to pages on how to use the system. Entering a bug number shows detail; for example try entering 330514 which is a PostgreSQL bug. You can add more detail to a bug by mailing <bug-number>@bugs.debian.org. You can close a bug by mailing <bug-number>-done@bugs.debian.org. You can of course clone bugs, retarget to a different package, merge bugs, etc. It's controllable by email -- in fact, I think email is the only controlling interface. You can get reports using the web frontend. You can get an mbox via HTTP for a particular bug, which you can later open with your email client if you like. (And respond to it, etc). We would have to determine what constitutes a "package" (probably one for each contrib module, one for each interface, one for the backend, etc; or we could have separate package for "optimizer", "rewriter", "transaction system", one for each access method, etc), what "tags" there are, what "versions", etc. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Have you tried to use debbugs? If you can find up-to-date source code for debbugs, we might continue that line of thought. The searching capabilities in debbugs are, well, non-existent, which is a real problem in my mind. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Peter Eisentraut wrote: > Alvaro Herrera wrote: > > Have you tried to use debbugs? > > If you can find up-to-date source code for debbugs, we might continue > that line of thought. Josh Berkus said he'd try to talk to the Debian people at LinuxWorld -- let's see if something materializes from there. > The searching capabilities in debbugs are, well, non-existent, which is > a real problem in my mind. Well, we can set up our own indexing, like Oleg and Teodor have done in http://www.pgsql.ru/ -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Have you tried to use debbugs? I agree with Greg Stark that it's a
> better fit for our current procedure, while enabling better
> traceability.
The principal strike against debbugs seems to be that the source code is
not readily available and/or isn't updated regularly. If we could get
current sources we'd probably end up maintaining our own fork ... OTOH,
given all the enthusiasm being expressed in this thread, somebody would
volunteer to do that no?
Other than that not-small problem, I agree that debbugs seems like an
excellent fit to our existing habits.
regards, tom lane
On Thu, Aug 17, 2006 at 08:20:22PM -0400, Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Have you tried to use debbugs? I agree with Greg Stark that it's a > > better fit for our current procedure, while enabling better > > traceability. > > The principal strike against debbugs seems to be that the source code is > not readily available and/or isn't updated regularly. If we could get > current sources we'd probably end up maintaining our own fork ... OTOH, > given all the enthusiasm being expressed in this thread, somebody would > volunteer to do that no? Well, actually, you can get the currently running source whenever you like: http://bugs.debian.org/debbugs-source/ I got that from one of the bugs listed against debbugs: http://bugs.debian.org/222077 The problem is that there is no recently packaged version that one can just quickly install somewhere. > Other than that not-small problem, I agree that debbugs seems like an > excellent fit to our existing habits. Yeah, debbugs is a really good fit here, like for Debian, because of the overwhelming prevalence of email correspondence compared to any other kind of communication. If we all used forums ofcourse, debbugs would suck :) Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate.
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> writes: > >> Have you tried to use debbugs? I agree with Greg Stark that it's a >> better fit for our current procedure, while enabling better >> traceability. >> > > The principal strike against debbugs seems to be that the source code is > not readily available and/or isn't updated regularly. If we could get > current sources we'd probably end up maintaining our own fork ... OTOH, > given all the enthusiasm being expressed in this thread, somebody would > volunteer to do that no? > > Other than that not-small problem, I agree that debbugs seems like an > excellent fit to our existing habits. > > > Well, the enthusiasm was for use, not for maintaining a fork :-) I had a brief look at the code (literally less than 5 minutes). The good news is that it is admirably small. A fork isn't a bad idea, though, especially as a pgfoundry project. I can think of several excellent candidates for such a project (no names, no pack drill) ;-) I should mention that it's a perl app. cheers andrew
All, I chatted some with some of the Debian folks who maintain Debbugs. They thought it would take a significant amount of work to adapt it to PostgreSQL, in addition to the obvious needs to improve the web interface. RT has some significant short comings for our project such as not having good support for tying bugs to versions etc. As people have pointed out, it's a "Request Tracker", not necessarily a Bug Tracker. On the other hand, a lot of my personal dislike of BugZilla seems to be based on being forced to use old versions. A lot of the stuff I hate about it has been fixed in the current version. So, the question is whether any of our biggest bug-fixers would dig in their heels and scream "No!" if we gave BugZilla a try. Comments? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
> > So, the question is whether any of our biggest bug-fixers would dig in > their heels and scream "No!" if we gave BugZilla a try. Comments? > > I could have this setup this weekend should we vote YES :) Joshua D. Drake
Josh Berkus <josh@agliodbs.com> writes: > On the other hand, a lot of my personal dislike of BugZilla seems to be > based on being forced to use old versions. A lot of the stuff I hate > about it has been fixed in the current version. Does that include it being basically a web-only interface? I'm listed on various mozilla bugs and occasionally get notifications of updates but I can't reply to those notifications and I'm not about to fire up a browser and log in and search for the bug just to add comments. I expect if you set up a web-based interface it won't be a matter of people digging in heels so much as just being indifferent to it. And like most projects the bugs will just accumulate and not get feedback. Incidentally, does it also fix the issue with the database schema where the entire set of comments is stored in a single field of a single record and so when two people comment on a bug at the same time one stomps on the others changes? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
> > I expect if you set up a web-based interface it won't be a matter of people > digging in heels so much as just being indifferent to it. And like most > projects the bugs will just accumulate and not get feedback. > > And which projects would these be? Oddly enough it might surprise you that the web has really matured. All kinds of people use it now. You should really check it out. ;) Sincerely, Joshua D. Drake > Incidentally, does it also fix the issue with the database schema where the > entire set of comments is stored in a single field of a single record and so > when two people comment on a bug at the same time one stomps on the others > changes? > >
Gregory Stark <gsstark@mit.edu> writes:
> I'm listed on various mozilla bugs and occasionally get notifications of
> updates but I can't reply to those notifications and I'm not about to fire up
> a browser and log in and search for the bug just to add comments.
It's really not that painful: every email bugzilla sends includes the
URL of the bug page. It's one click to visit the page, assuming your
mail and web tools are well enough integrated that you can readily visit
a URL given in text email. (If not, consider joining the 21st century
;-))
I think actually the weak spot of bugzilla for our purposes will be the
problem of transferring original email reports into BZ entries. The
volunteer(s) who do that work are probably going to want a tool better
adapted to that purpose than the standard BZ bug entry page ... but
we'll likely want to do some customization work on our BZ anyway, so
I don't see that as a fatal objection.
The bottom line here is that there will not be any tool that is perfect
for our purposes out-of-the-box. Well, it's all open source, we can
scratch our own itch. What we need more than any specific tool is a
commitment from someone to put effort into adapting the tool to our
needs.
(Given that reality, the quality of the tool's existing source code
needs to figure strongly in our decision. If BZ is still as ugly
as Josh remembers it being, that'd be a strike against it.)
regards, tom lane
Gregory Stark wrote: > Josh Berkus <josh@agliodbs.com> writes: > > > On the other hand, a lot of my personal dislike of BugZilla seems to be > > based on being forced to use old versions. A lot of the stuff I hate > > about it has been fixed in the current version. > > Does that include it being basically a web-only interface? > > I'm listed on various mozilla bugs and occasionally get notifications of > updates but I can't reply to those notifications and I'm not about to fire up > a browser and log in and search for the bug just to add comments. > > I expect if you set up a web-based interface it won't be a matter of people > digging in heels so much as just being indifferent to it. And like most > projects the bugs will just accumulate and not get feedback. Yea, I'm planning on ignoring the bug tracker until we decide I can stop doing what I do already. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Tom Lane wrote: > Gregory Stark <gsstark@mit.edu> writes: > >> I'm listed on various mozilla bugs and occasionally get notifications of >> updates but I can't reply to those notifications and I'm not about to fire up >> a browser and log in and search for the bug just to add comments. >> > > It's really not that painful: every email bugzilla sends includes the > URL of the bug page. It's one click to visit the page, assuming your > mail and web tools are well enough integrated that you can readily visit > a URL given in text email. (If not, consider joining the 21st century > ;-)) > > I think actually the weak spot of bugzilla for our purposes will be the > problem of transferring original email reports into BZ entries. The > volunteer(s) who do that work are probably going to want a tool better > adapted to that purpose than the standard BZ bug entry page ... but > we'll likely want to do some customization work on our BZ anyway, so > I don't see that as a fatal objection. > > The bottom line here is that there will not be any tool that is perfect > for our purposes out-of-the-box. Well, it's all open source, we can > scratch our own itch. What we need more than any specific tool is a > commitment from someone to put effort into adapting the tool to our > needs. > > (Given that reality, the quality of the tool's existing source code > needs to figure strongly in our decision. If BZ is still as ugly > as Josh remembers it being, that'd be a strike against it.) > > > It is a heck of a lot better then it was. For example, presentation logic is largely factored out and handed off to TT templates. Personally I'd like to see the SQL factored out too, but Bugzilla is hardly unique in having SQL littered across the code. Honestly, this is not your father's bugzilla. BTW, Josh's memory is of the 1.x series. The 2.x series is now at 2.22. The code has move a very long way. There are also tools for email interaction, although they might need to be beefed up for the likes of some 20th century dwellers :-) I will check about Greg's complaint about race conditions in updating comments. My initial impression is that this is no longer so, but I will get a definite answer. We certainly have enough perl-heads on our community that we can surely make it do what we want with little difficulty. Oh, it can also import some XML too. The DTD is in the source. cheers andrew
I wrote: > > > I will check about Greg's complaint about race conditions in updating > comments. My initial impression is that this is no longer so, but I > will get a definite answer. > > My impression was correct. Each comment on a bug gets its own row, marked by bug-id, commenter-id and timestamp. BTW, there are undoubtedly some infelicities in the schema, but it's not too bad, and the way the bugzilla code works there is no danger of one underlying DB platform getting out of synch, as they are all generated from a single abstract schema. cheers andrew
peter_e@gmx.net (Peter Eisentraut) writes: > Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat: >> I'm not sure I follow this, since currently anyone can email the bugs list >> or use the bugs -> email form from the website. Are you looking to >> increase the barrier for bug reporting? > > Only a small fraction of the new posts on pgsql-bugs are actually > bugs. Most are confused or misdirected users. I don't want to > raise that barrier. But I want a higher barrier before something is > recorded in the bug tracking system. Seems to me that for there to be a *bit* of a barrier might not be a bad thing... If "purported bugs" had to be acknowledged before going into the bug tracker system, that wouldn't seem a bad thing. That would mean that the frequent "I don't understand what I'm doing and didn't read the documentation" reports could be quickly triaged away, which strikes me as an important prerequisite for further automating things. -- select 'cbbrowne' || '@' || 'ntlug.org'; http://cbbrowne.com/info/sap.html FLORIDA: Relax, Retire, Re Vote.
Kenneth Marshall wrote: > RT is easy to setup/configure/use and works well with PostgreSQL > as the backend. RT works with Postgres, but I wouldn't say well. All queries in RT are generated by a query generator due to a naive obsession with database independance. They've achieved database independance at the cost of all the queries being brain-dead. Fixing the query generator would be a pretty big job. Drew
On Aug 17, 2006, at 3:40 PM, Alvaro Herrera wrote: >> The searching capabilities in debbugs are, well, non-existent, >> which is >> a real problem in my mind. > > Well, we can set up our own indexing, like Oleg and Teodor have > done in > http://www.pgsql.ru/ That seems like quite a hack for something that should be built-in... it also severely limits searchability. For example, it's very important to be able to do things like ignore closed bugs when you're searching. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
On 8/17/06, Peter Eisentraut <peter_e@gmx.net> wrote: > Alvaro Herrera wrote: > > Have you tried to use debbugs? > > If you can find up-to-date source code for debbugs, we might continue > that line of thought. http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html ( bzr get http://bugs.debian.org/debbugs-source/mainline/ ) > The searching capabilities in debbugs are, well, non-existent, which is > a real problem in my mind. As its mail based, it delegates searching to mail archive search tools. -- marko
Marko Kreen wrote: > On 8/17/06, Peter Eisentraut <peter_e@gmx.net> wrote: >> Alvaro Herrera wrote: >> > Have you tried to use debbugs? >> >> If you can find up-to-date source code for debbugs, we might continue >> that line of thought. > > http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html > > ( bzr get http://bugs.debian.org/debbugs-source/mainline/ ) > >> The searching capabilities in debbugs are, well, non-existent, which is >> a real problem in my mind. > > As its mail based, it delegates searching to mail archive search tools. > Why are we even dabating a system when it has been reported that the authors believe it is completely unsuitable for use by the PostgreSQL project? cheers andrew
> > Kenneth Marshall wrote: > > RT is easy to setup/configure/use and works well with PostgreSQL as > > the backend. > > RT works with Postgres, but I wouldn't say well. All queries > in RT are generated by a query generator due to a naive > obsession with database independance. They've achieved > database independance at the cost of all the queries being > brain-dead. Fixing the query generator would be a pretty big job. > We use RT with PostgreSQL for all internal IT requests and development/support/doc tasks on a couple products, and there's never been a problem. Are the queries optimal? no. The alternative might have been MySQL-only, and that would be worse. I can't really give a fair estimate on performance, because I'm running it on a PIII at 800MHz with several other things as well. But it's fast enough that I'm not screaming for a hardware upgrade. Regards, Paul Bort
Andrew, > Why are we even dabating a system when it has been reported that the > authors believe it is completely unsuitable for use by the PostgreSQL > project? Not *completely*. More that it would take a couple dozen hours of work to make it good for us, and the resulting version then couldn't be synched with the Debian version. Mind you, it would take an equal amount of time to add an e-mail-comment interface to Bugzilla, but BZ would then probably accept the patch. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco
Did you look at http://www.atlassian.com/software/jira/ - can use postgresql as database - free to open source projects, used by apache, hiberate, OpenSymphony - bugs may be submitted via email/web - built-in configurable workflow - runs as J2EE webapp on a number of OS's - lots of other features I am not associated with the company, just a user.
niederland@gmail.com wrote: > Did you look at http://www.atlassian.com/software/jira/ We had discussed that in an earlier round, but it's not free software, so it's out of the question. -- Peter Eisentraut http://developer.postgresql.org/~petere/