Thread: pgFoundry
Hello, PgFoundry has been brought up quite a bit lately. How we want it to succeed, how we want it to be the hub of PostgreSQL development. So my question is... Why isn't it? Why is PostgreSQL not hosted at pgFoundry? It seems that it has everything we would need? To keep this on track, consider my question as if it were 2 months from now and pgFoundry was all up on the new servers etc... Sincerely, Joshua D. Drake
> PgFoundry has been brought up quite a bit lately. How we want > it to succeed, how we want it to be the hub of PostgreSQL development. > So my question is... Why isn't it? Speaking only for myself, I volunteered to have my project moved over first as a test case. This was agreed, the original plan being to start moving the project "within two weeks." It stretched into months, many of them, and at some point I figured I'd asking and just wait to be notified.That must have been over a year ago by now. A lot of stuff happened to me personally over that waiting period (like living in three noncontiguous countries) so I may easily have missed, or even forgotten, an announcement on one of the mailing lists. I'm not unique, however. The same may be true of others. So if you want to encourage people to migrate to the new site, tell them about it and repeat, repeat, repeat! Post an announcement for each project that makes the jump. Bring it to the fore. Convey the fact--assuming it is one, of course--that this is where the Postgres-related projects are headed. Keep people updated. Did I mention "repeat" as well? Jeroen
On Fri, 6 May 2005 01:32 pm, Joshua D. Drake wrote: > Hello, > > PgFoundry has been brought up quite a bit lately. How we want > it to succeed, how we want it to be the hub of PostgreSQL development. > So my question is... Why isn't it? Because it's not the hub of PostgreSQL development. I think it will be difficult to build a culture of "This" is the place to be unless we actually kill gborg totally. Currently there are still projects there, I'm personally never sure where to look for a particular project. Even some of the more high profile projects like Slony-I aren't even on PgFoundy. How can we expect people to take it seriously. Issue two, which I know is being resolved, is that people find it painfully slow to navigate. Who wants to search a sight that is painfully slow. But until the site is running at a good speed, and can support a reasonably large number of projects at that speed, are people going to be encouraged to move over? I don't think so. I know there are issues with the CVS statistics. If I'm looking for a project to forfill a function, looking at the statistics is a good way to determine if the project is going anywhere or not. As well as releases. Currently every project say "This project has no CVS history." and lists 0 commits and 0 adds. I don't think this generally looks good for us. If there was no information, it would be better than the false information. Also a little more prominence on the PostgreSQL main page would be helpful. I know there is a link, but to the unknowning user, what is pgFoundry about? Maybe some advertisting about the fact that is you want something that runs with your PostgreSQL server, head on over to pgFoundry to find it. We should encourage any OSS projects that are for PostgreSQL to use pgFoundry instead of any other hosting source. One very basic example is the nss library I have been working on. I recently found that in February, another fork of the nss library had popped up on debian's Gforge site. I had no idea it existed, and they had no idea I existed, and they use PostgreSQL fairly exclusively. Where were they looking for an nss library when then needed one? Well, it obviously wasn't at pgFoundry. > Why is PostgreSQL not hosted at pgFoundry? > It seems that it has everything we would need? This is possibly true, it gives the advantage of trackers and many functions that the lists are used for. Maybe it's less likely we would lose patches and/or bugs. I don't really have a lot of knowledge about the benefits disadvantages, so I'll leave the people who actually use CVS and things like that to make a comment. > > To keep this on track, consider my question as if it were 2 months from > now and pgFoundry was all up on the new servers etc... Personally, this is a problem. It's another 2 months away. In that time, I think we also need to focus on getting rid of gborg and redirecting people to pgFoundry. But can the current setup handle the load, and can we get the move from gborg done? Also is the upgrade path for moving servers easy, if it is it's probably more reason to push for the full closure of gborg. Now, despite the apparent large number of complaints. I think pgFoundry is a very good idea, and will work well in the long run. I just think we need to get some things going well to get people on the site more. Once that happens, people will instinctively look there. Sincerely, Russell Smith
> > Personally, this is a problem. It's another 2 months away. In that time, I think we > also need to focus on getting rid of gborg and redirecting people to pgFoundry. > But can the current setup handle the load, and can we get the move from gborg done? > Also is the upgrade path for moving servers easy, if it is it's probably more reason to > push for the full closure of gborg. Gborg is considered deprecated. The projects that are there may or may not move. Although the goal it to get them to. Also at this point Gborg has nothing to do with the initial question. I am not asking about Gborg. I am asking why we are not placed PostgreSQL at the core of what is supposed to be the PostgreSQL Projects website, pgFoundry. Sincerely, Joshua D. Drake Command Prompt, Inc. > > > Now, despite the apparent large number of complaints. I think pgFoundry is a very good > idea, and will work well in the long run. I just think we need to get some things going > well to get people on the site more. Once that happens, people will instinctively look there. > > Sincerely, > > Russell Smith -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, 6 May 2005, Joshua D. Drake wrote: >> >> Personally, this is a problem. It's another 2 months away. In that time, >> I think we >> also need to focus on getting rid of gborg and redirecting people to >> pgFoundry. >> But can the current setup handle the load, and can we get the move from >> gborg done? >> Also is the upgrade path for moving servers easy, if it is it's probably >> more reason to >> push for the full closure of gborg. > > Gborg is considered deprecated. The projects that are there may or may not > move. Although the goal it to get them to. > > Also at this point Gborg has nothing to do with the initial question. I am > not asking about Gborg. I am asking why we are not placed PostgreSQL at the > core of what is supposed to be the PostgreSQL Projects website, pgFoundry. This has been discussed several times before ... pgFoundry offers us nothing that we don't already have, and takes away several things ... also, with pgFoundry moving 'State side', it has one more check against moving the core project over to it ... With PostgreSQL *not* US based, we are not subject to the whim's of the US government, nor its export restrictions, nor its lawyers ... This is one of those "check the archives, its been discussed before" kinda threads ;( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
> > > This has been discussed several times before ... pgFoundry offers us > nothing that we don't already have, Actually it does: 1. Public presentation of the project development 2. Public presentation of the project bugs 3. Public presentation of the project tracker and docs Perception is everything :) The new people, the people who are coming to PostgreSQL they are looking for the Web, they want an interface that they can peruse, easily search, see priority etc... That is not mailing lists :) and takes away several things ... Curious to know what those are? > With PostgreSQL *not* US based, we are not subject to the whim's of the > US government, nor its export restrictions, nor its lawyers ... I am not even going to touch this one. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, 6 May 2005, Joshua D. Drake wrote: > >> >> >> This has been discussed several times before ... pgFoundry offers us >> nothing that we don't already have, > > Actually it does: > > 1. Public presentation of the project development Sounds like what http://www.postgresql.org is either doing, or should be extended to do ... > 2. Public presentation of the project bugs Same as 1, but maybe a bit more forcefully by ppl like Tom ... god, Josh Berkus even spent the time going through all the various 'bug tracking tools' out there to find something that would satisfy the requirement by ppl like Tom to *not* have a web interface, while providing one, and none of them (and, if I recall correctly, *especially* not pgFoundry) came close ... and Josh put alot of work/effort into the research, if I recall correctly, including looking at some potential "commercial" offerings that were willing to work with us ... Again, this was heavily discussed at least a couple of times ... > 3. Public presentation of the project tracker and docs Isn't that what http://www.postgresql.org is for? > The new people, the people who are coming to PostgreSQL they are looking > for the Web, they want an interface that they can peruse, easily search, > see priority etc... Sounds like what http://www.postgresql.org is either doing, or should be extended to do ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: > On Fri, 6 May 2005, Joshua D. Drake wrote: > >> >>> >>> >>> This has been discussed several times before ... pgFoundry offers us >>> nothing that we don't already have, >> >> >> Actually it does: >> >> 1. Public presentation of the project development > > > Sounds like what http://www.postgresql.org is either doing, or should be > extended to do ... No that is public presentation of the project not project development. > >> 2. Public presentation of the project bugs > > > Same as 1, but maybe a bit more forcefully by ppl like Tom ... god, Josh > Berkus even spent the time going through all the various 'bug tracking > tools' out there to find something that would satisfy the requirement by > ppl like Tom to *not* have a web interface, while providing one, and > none of them (and, if I recall correctly, *especially* not pgFoundry) The new version of PgFoundry provides a SOAP interface so there is no reason why we could not create a simple interface for command line access (which I would use as well) > >> 3. Public presentation of the project tracker and docs > > > Isn't that what http://www.postgresql.org is for? Well not in my mind although it could be extended to. Case in point where do I go on the website to see what the current todo and progress based on the todos? I click on Developers->RoadMap->TODO That is great (seriously) but from a developer (at least in my mind) it doesn't tell me what I want to know. Now look at: http://gforge.org/tracker/?atid=105&group_id=1&func=browse http://gforge.org/forum/?group_id=1 http://gforge.org/pm/task.php?group_project_id=54&group_id=1&func=browse The color scheme is bad but I think it makes my point. We don't have anything like this, and I think it would be beneficial. > >> The new people, the people who are coming to PostgreSQL they are >> looking for the Web, they want an interface that they can peruse, >> easily search, see priority etc... > > > Sounds like what http://www.postgresql.org is either doing, or should be > extended to do ... I am talking about new developers. Developers want good, solid information that is easy to find. That is not always the case as we have recently been speaking about at length in several different threads. Sincerely, Joshua D. Drake > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, May 06, 2005 at 10:01:45AM -0700, Joshua D. Drake wrote: > >With PostgreSQL *not* US based, we are not subject to the whim's of the > >US government, nor its export restrictions, nor its lawyers ... > > I am not even going to touch this one. Why? While I wouldn't put the terms exactly the way Marc did, I _would_ say that the US approach to "intellectual property" in software is sufficiently reaching as to qualify in the "over" category. Canada's rules are bad enough, but having worked under both regimes, I'm moderately convinced that having a non-US "home base" for CVS is a good idea. A -- Andrew Sullivan | ajs@crankycanuck.ca When my information changes, I alter my conclusions. What do you do sir? --attr. John Maynard Keynes
Andrew Sullivan wrote: > On Fri, May 06, 2005 at 10:01:45AM -0700, Joshua D. Drake wrote: > >>>With PostgreSQL *not* US based, we are not subject to the whim's of the >>>US government, nor its export restrictions, nor its lawyers ... >> >>I am not even going to touch this one. > > > Why? Because I think if you think that having the CVS anywhere will matter to the US, I think your dead wrong. If the US wants to come after the project they are going to one way or the other. They will either: A. Prosecute US developers working on the project B. Prosecute Non-US developers with countries they have extradition treaties with. C. Send in the army to overthrow your dictator and hunt you. It doesn't matter either way. FYI, a US business can rather successfully sue a Canadian one. I am not saying I agree or disagree with the above 3. Frankly it is none of anybody's business what I think about it. However I am no fool in thinking that another country provides any veil if the US actually wants something you have. Sincerely, Joshua D. Drake Command Prompt, Inc. While I wouldn't put the terms exactly the way Marc did, I > _would_ say that the US approach to "intellectual property" in > software is sufficiently reaching as to qualify in the "over" > category. Canada's rules are bad enough, but having worked under > both regimes, I'm moderately convinced that having a non-US "home > base" for CVS is a good idea. > > A > -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, May 06, 2005 at 11:35:19AM -0700, Joshua D. Drake wrote: > > FYI, a US business can rather successfully sue a Canadian one. Yes, but in Canada, only for actual violations of Canadian law. Most of the time, the practical effect of this is nothing, because the Canadian businesses have US assets that the USian business can go after in USian courts. (This tactic is the one that's been attempted, for instance, to perform the enforcement of the extraterritorial claims of the US Cuba embargo.) But since the project isn't a legal entity and has no assets, we don't have that problem. Individual contributors might, of course, but we can't do anything about that anyway. > I am not saying I agree or disagree with the above 3. Frankly it is none > of anybody's business what I think about it. However I am no fool in > thinking that another country provides any veil if the US actually wants > something you have. Well, sure. But the code isn't really something they can "have" any more than they can "have" the idea of public key cryptography. The more relevant question is a cost-benefit one: the US government spent (IMHO) too much time harassing US security researchers over PGP, for instance, but didn't do very much attempting to make life difficult for non-US researchers. I submit that was mostly because the diplomatic pain that it was likely to cost wasn't worth the pointless benefit of trying to put the cat back in the bag. I think that there is a potential nonzero advantage in having the project hosted outside of the strict legal reach of the US Congress. The Parliament of Canada isn't a whole lot better, but its tendency to feature debates about who will be best at bribing some part of the country to keep quiet about the divorce means that it is less likely to spend as much time attempting to tell people what to think. It's a very modest benefit, to be sure, but not one to give up without thinking. (In the Canada case, of course, it comes at the potential cost that in any year, the project could find itself in a new, and previously non-existent, country.) A -- Andrew Sullivan | ajs@crankycanuck.ca A certain description of men are for getting out of debt, yet are against all taxes for raising money to pay it off. --Alexander Hamilton
mr-russ@pws.com.au (Russell Smith) writes: > Because it's not the hub of PostgreSQL development. I think it will > be difficult to build a culture of "This" is the place to be unless > we actually kill gborg totally. Currently there are still projects > there, I'm personally never sure where to look for a particular > project. Even some of the more high profile projects like Slony-I > aren't even on PgFoundy. How can we expect people to take it > seriously. Various people are keen on moving Slony-I over to PGFoundry, but not until the perpetual "two months" expires, and it gets to the necessary "more stabler" point. -- (format nil "~S@~S" "cbbrowne" "acm.org") http://www.ntlug.org/~cbbrowne/sap.html Rules of the Evil Overlord #78. "I will not tell my Legions of Terror "And he must be taken alive!" The command will be: ``And try to take him alive if it is reasonably practical.''" <http://www.eviloverlord.com/>
On Fri, May 06, 2005 at 11:09:36 -0700, "Joshua D. Drake" <jd@commandprompt.com> wrote: > Marc G. Fournier wrote: > >On Fri, 6 May 2005, Joshua D. Drake wrote: > >> > >>1. Public presentation of the project development > > > > > >Sounds like what http://www.postgresql.org is either doing, or should be > >extended to do ... > > > No that is public presentation of the project not project development. I don't see that people are going to be able to participate in development if they don't use the mailing lists. If they want an overview of what is happening, they should read the weekly news summaries. The TODO list will let them know what new features have been completed for the next release.
>> >>No that is public presentation of the project not project development. > > > I don't see that people are going to be able to participate in development > if they don't use the mailing lists. I am not arguing that but public mailing lists are no place to track status of sub projects or tasks. They are for discussion. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Fri, 6 May 2005, Joshua D. Drake wrote: >>> >>> No that is public presentation of the project not project development. >> >> >> I don't see that people are going to be able to participate in development >> if they don't use the mailing lists. > > I am not arguing that but public mailing lists are no place to track status > of sub projects or tasks. They are for discussion. first off, there is really no reason why a 'PostgreSQL Server' project can't be created on pgFoundry for the express purpose of this sort of thing, with pointers to where the real work is happening ... but ... who is going to maintain it? if developers aren't willing to deal with a formal bug tracking system, I can't see how a 'web based project tracking system' is ever going to get updated, unless somehow maintaining of that ties in with the Weekly News that David/Elein/etc have been producing ... ? But, if that is the case, then why not just archive the Weekly News on the main web site and provide a link/sub-page expressly for that? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Joshua D. Drake wrote: >>> >>> No that is public presentation of the project not project development. >> >> >> >> I don't see that people are going to be able to participate in >> development >> if they don't use the mailing lists. > > > I am not arguing that but public mailing lists are no place to track > status of sub projects or tasks. They are for discussion. > > Joshua, I think you formulated the question wrong. It shouldn't be "why aren't we using pgFoundry?" but "what can we do to improve our processes?" Only after that question is answered should toolsets be considered. For example, the TODO list is not really a task list at all - its status is very nebulous. Some things will probably never be done, and many many things will be done which aren't on it. So before we ask about task tracking, we need to ask where the list of tracked tasks comes from. In the past I have been told "there isn't and can't be such a list". In that case, use of task tracking software is just a waste of bandwidth. I'd like to see a bit more in the way of formal process, but to be done right that also needs some resources (i.e. someone's time) which is not something we are rich in. cheers andrew
"Joshua D. Drake" <jd@commandprompt.com> writes: > >>No that is public presentation of the project not project development. > > I don't see that people are going to be able to participate in development > > if they don't use the mailing lists. > > I am not arguing that but public mailing lists are no place to track status of > sub projects or tasks. They are for discussion. What does it mean to "track" the status of something? How would the status change except by discussion? What would be the point of announcing the status of something without allowing people to comment? I think you have a severely flawed idea of how free software development proceeds. What you're describing sounds like something a manager of a commercial project would want. Perhaps it's something the managers of the people working on Postgres on behalf of some corporate sponsors might want but in those cases I doubt they would want the information to be public anyways. In the free software world there's no top-down management of the project with managers issuing direction and expecting feedback reports. People only want tools that make their lives easier. Not tools that make other people's lives easier at the expense of their own convenience. The programmers are not beholden to any corporate interests (other than their own sponsors, who presumably are getting all the feedback they're looking for privately). I'm rather surprised Postgres doesn't have a good bug tracking system. That's something most projects find pretty essential. Strangely enough the reason seems to be that Postgres really doesn't have many bugs... Unlike web browsers or GUIs or most of the other free software projects out there, databases don't tolerate bugs well. Any serious bug is cause for an immediate point release. The only use for a bug tracking system would really be for tracking all those pesky "IWBNI" bugs that never rise to urgent status. But "tracking the status" of sub-projects is just not the kind of thing free software people do. They send emails when they have something to say. -- greg
On Sat, 7 May 2005, Greg Stark wrote: > But "tracking the status" of sub-projects is just not the kind of thing > free software people do. They send emails when they have something to > say. in defence of Joshua's idea, there are some "large projects" within our development that would be nice to see some sort of 'time lines' for, but mainly those are the sorts of things that have set milestones to look for ... I believe that Simon's work on the PITR stuff might fall under that, where he had various 'stages' he was working towards ... But, I think that the # of "sub projects" that this would apply to is so few that setting anything up more formally then Simon sending out an updated patch would be more work then the derived benefit ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Greg, > I'm rather surprised Postgres doesn't have a good bug tracking system. > That's something most projects find pretty essential. Strangely enough the > reason seems to be that Postgres really doesn't have many bugs... Unlike > web browsers or GUIs or most of the other free software projects out there, > databases don't tolerate bugs well. Any serious bug is cause for an > immediate point release. The only use for a bug tracking system would > really be for tracking all those pesky "IWBNI" bugs that never rise to > urgent status. Actually, a bug tracker would be useful for two purposes: 1) Tracking bugs that are actually feature requests, in an effort (possibly futile) to cut down on the number of "when will PostgreSQL be able to use an index on MAX()?" requests that we get. A certain amount of this is in our FAQ, but the FAQ has the flaws of both not being easily searchable, and having a very manual update process so that it frequently gets out of date. 2) Tracking bugs that were fixed (and features that were added) in particular releases so that users know when they need to upgrade. For example, if a user had an index corruption problem with 7.4.1, it would be useful for them to know that an upgrade to 7.4.5 (as I recall) would fix it. Currently, they'd have to read all of the release notes from 7.4.2 through 7.4.5 and decipher insider terminonolgy to figure it out -- not always easy to do, and even harder to convince your boss. The problem is that a bug tracker would not be useful to the Postgresql *developers*; our current system works pretty well for us now. Except for one possibility: IF we had a formal bugtracker, are there people who are not currently contributing to PostgreSQL who would be willing/able to read, test, and analyse bug reports? With the addition of several companies to our community, it's a possibility, and would make the trouble of using a bug tracker worthwhile, I think. Comments? -- Josh Berkus Aglio Database Solutions San Francisco
> What does it mean to "track" the status of something? How would the status > change except by discussion? What would be the point of announcing the status > of something without allowing people to comment? No one said anything about not letting people comment or discuss. What I am suggesting is a better public presentation of what the heck is going on with PostgreSQL development. > > I think you have a severely flawed idea of how free software development > proceeds. Then you obviously aren't paying attention. Look at other major OSS projects. They have these things in place. Even the Linux kernel has a bugzilla (although I am not advocating bugzilla). Not to mention KDE, Gnome, Debian.. These projects also have reasonably defined milestones for particular releases and show status of those milestones during the release. What you're describing sounds like something a manager of a > commercial project would want. Perhaps it's something the managers of the > people working on Postgres on behalf of some corporate sponsors might want but > in those cases I doubt they would want the information to be public anyways. What I am describing is what other large OSS projects already do. > In the free software world there's no top-down management of the project with > managers issuing direction and expecting feedback reports. No but there are people in charge of particular tasks. There are people only working on certain things. Like the work that the people did on PITR. People only want > tools that make their lives easier. Not tools that make other people's lives > easier at the expense of their own convenience. The programmers are not > beholden to any corporate interests (other than their own sponsors, who > presumably are getting all the feedback they're looking for privately). I am not suggesting that anybody be beholden to anybody accept maybe the community itself. Sincerely, Joshua D. Drake
On Saturday 07 May 2005 15:31, Josh Berkus wrote:
> 2) Tracking bugs that were fixed (and features that were added) in
> particular releases so that users know when they need to upgrade.
one idea that has been quasi floated before would be something equivalent to
Simon Riggs developer summaries and/or Bruce's release history, that could be
updated as appropriate for each development cycle. If someone were willing to
maintain it, we could put it on the website along with the TODO list.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Saturday 07 May 2005 16:23, Joshua D. Drake wrote: > > What does it mean to "track" the status of something? How would the > > status change except by discussion? What would be the point of announcing > > the status of something without allowing people to comment? > No one said anything about not letting people comment or discuss. What I > am suggesting is a better public presentation of what the heck is going > on with PostgreSQL development. This has been a perennial problem and has existed at least since version 6.1.0, as that's when I first noticed it. Looking at the website alone doesn't show the dynamic development that is actually happening, and has never shown it. I very nearly passed PostgreSQL by because it looked unmaintained at the time from looking at the website. That cannot be said at this juncture, but at the same time that is not real indication of how dynamic things really are. From a sidelines point of view, a developer status summary page would allow one to follow development without having to read every message in HACKERS. At this point in my work, I am unable to follow development like I once did (one reason I stepped down as RPM maintainer) and have no real idea of the direction for 8.1 as a result. To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, steeper even than Plone, which is acknowledged by many to have an incredibly steep learning curve. The only way in my mind to get this dynamism on the website is to make the website part of the process at some level. If someone has to go through and digest for the website (hacker-bits, a la general bits) then that takes away developer resources (because someone has to be fairly close to the development process to do that sort of digestion). Rather, if developers are using a system that automatically pushes to a web interface (or even uses a web interface with a cli component) then the status is automatically generated and the work of updating status is distributed. > > I think you have a severely flawed idea of how free software development > > proceeds. > Then you obviously aren't paying attention. Look at other major OSS > projects. They have these things in place. Even the Linux kernel has a > bugzilla (although I am not advocating bugzilla). Not to mention KDE, > Gnome, Debian.. > These projects also have reasonably defined milestones for particular > releases and show status of those milestones during the release. Virtually all OSS projects I am involved with publish a generalized road map online. Some are more organized than others. PostgreSQL has a different culture, this is true. But it is somewhat of an intimidating culture for an outsider; once 'inside' (which takes 6 months or more unless you're another Tom Lane (I love going back and reading the way he just 'jumped in' to the project)) this is one of the friendliest development communities around. One might say the high bar of entry and the steep learning curve is partly the reason for that; culture changes take careful thought to implement, and a web-published development might easily change the whole culture of the project. The biggest flamewars I have seen here involve one of the following topics: 1.) GPL vs BSD 2.) MySQL 3.) Multithreaded versus multiprocess. Most other communities (with the notable exception of the GNUradio community, which is even more polite than this one, something I thought was not possible) have many more hot button topics than three. Like any other management process (sorry, those of you who think OSS means 'no management' - there is management here) the PostgreSQL process is unique due to the unique collection of members, and what works for one community won't necessarily work for another. Having said that, I'd love an 'at-a-glance' development status showing, possibly in graphical terms, where each subproject of the PostgreSQL core is at right now, updated frequently, as I've changed into more of a user role than a developer role; I can see the forest now, instead of all the RPM bushes and prairie grass. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Lamar Owen wrote: >>Look at other major OSS >>projects. They have these things in place. Even the Linux kernel has a >>bugzilla (although I am not advocating bugzilla). Not to mention KDE, >>Gnome, Debian.. >> >> > > > >>These projects also have reasonably defined milestones for particular >>releases and show status of those milestones during the release. >> >> > >Virtually all OSS projects I am involved with publish a generalized road map >online. Some are more organized than others. > >PostgreSQL has a different culture, this is true. > > I don't think anybody is arguing for a radical change in culture - certainly I would not be so presumptuous after only a couple of years :-) But a roadmap could be useful in many ways. It need not tie anybody down, if positioned right, but can help people to see where things are going, and where the gaps are. This could in a sense be as simple as prioritising the TODO list. Right now anybody who wants to contribute and looks at the list has no idea if the item is considered important or even if it is still thought to be desirable. There are many changes that can be rung on this theme - you would probably want to keep the "roadmap process" as light as possible for the cultural reasons you mention. cheers andrew
Andrew, > down, if positioned right, but can help people to see where things are > going, and where the gaps are. This could in a sense be as simple as > prioritising the TODO list. Right now anybody who wants to contribute > and looks at the list has no idea if the item is considered important or > even if it is still thought to be desirable. There are many changes that > can be rung on this theme - you would probably want to keep the "roadmap > process" as light as possible for the cultural reasons you mention. The substantial problem here is that nobody *wants* to create a roadmap type document. If you can find a volunteer, it'd be worth discussing -- I can see a way we can make a "roadmap" without being deceptive about how we get features. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Andrew Dunstan <andrew@dunslane.net> writes:
> I don't think anybody is arguing for a radical change in culture -
> certainly I would not be so presumptuous after only a couple of years
> :-) But a roadmap could be useful in many ways. It need not tie anybody
> down, if positioned right, but can help people to see where things are
> going, and where the gaps are. This could in a sense be as simple as
> prioritising the TODO list.
I think that even getting that done would turn into a flamew^H^H^H^Hhuge
distraction. The way things really work around here is that individual
developers have their own priorities and they work on what seems most
important to them at the time. (In some cases those priorities may be
set by their companies more than by the individuals, but that's
irrelevant from the community's perspective.) ISTM any sort of
project-wide prioritization would be either (1) meaningless or (2) a
guaranteed-to-fail attempt to assert control over other contributors.
But the TODO list could certainly be made more informative without
getting into that swamp. I don't think it does very well at conveying
the relative sizes of the work items, nor the extent to which there is
consensus about how particular problems ought to be solved (the fact
that something is on TODO does not necessarily mean that all the major
contributors have bought into it...). And of course you're right that
it tells nothing at all about whether progress is currently being made
on a given item. The markers indicating that someone has expressed
interest in an item don't mean they are actively doing anything with it.
The real difficulty here is exactly what Lamar noted: who's going to do
the work? Bruce seems to be swamped already, so we'd need a new
volunteer to maintain a more useful TODO list, and there doesn't seem
to be anyone who wants to do it and has the depth of familiarity with
the project to do a good job of it.
regards, tom lane
On Mon, 2005-05-16 at 12:50, Lamar Owen wrote:
> >From a sidelines point of view, a developer status summary page would allow
> one to follow development without having to read every message in HACKERS.
> At this point in my work, I am unable to follow development like I once did
> (one reason I stepped down as RPM maintainer) and have no real idea of the
> direction for 8.1 as a result.
I don't think anyone is against this idea, but as of yet no one has
stepped forward with the time to keep such a thing updated.
> The only way in my mind to get this dynamism on the website is to make the
> website part of the process at some level. If someone has to go through and
> digest for the website (hacker-bits, a la general bits) then that takes away
> developer resources (because someone has to be fairly close to the
> development process to do that sort of digestion). Rather, if developers are
> using a system that automatically pushes to a web interface (or even uses a
> web interface with a cli component) then the status is automatically
> generated and the work of updating status is distributed.
One idea I've tossed around is requiring patches to include release
notes, and then display the release notes on the web site as a "done so
far" type of list. It doesn't get you what is under active development,
but would get you a more up-to-date picture of changes as a release
evolves.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
On Monday 16 May 2005 14:12, Robert Treat wrote: > On Mon, 2005-05-16 at 12:50, Lamar Owen wrote: > > The only way in my mind to get this dynamism on the website is to make > > the website part of the process at some level. If someone has to go > One idea I've tossed around is requiring patches to include release > notes, and then display the release notes on the web site as a "done so > far" type of list. It doesn't get you what is under active development, > but would get you a more up-to-date picture of changes as a release > evolves. Well, there is always the '-committers' list; if all CVS commits had/have meaningful commit changelog notices, then that could drive something. There are two things being talked about here: 1.) A forward-looking rad map; 2.) A status indication of where development is happening, and a history of past development. In my mind 2 is more important than 1, for all the reasons Tom already mentioned. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Robert Treat <xzilla@users.sourceforge.net> writes:
> One idea I've tossed around is requiring patches to include release
> notes, and then display the release notes on the web site as a "done so
> far" type of list. It doesn't get you what is under active development,
> but would get you a more up-to-date picture of changes as a release
> evolves.
We did do that (not very rigorously) during the 7.4 release cycle.
I'm not sure why we fell out of the habit again for 8.0. It seems
like a reasonable idea to me. I don't think I'd necessarily do it
exactly the way it was done before though --- rather than keep the
info in release.sgml, which is big and hard to edit already, maybe
a separate plain-text file would be easier to work with.
regards, tom lane
On Monday 16 May 2005 14:07, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > This could in a sense be as simple as > > prioritising the TODO list. > But the TODO list could certainly be made more informative without > getting into that swamp. We need to prune the TODO list to make it more useful. This will be hard, this is true, but if a pruning discussion for each item on the list is held then the real interest in the item would stick out like a sore thumb. It's just too big and not really hierarchical. Are we too close to freeze and beta on 8.1 to have this sort of discussion? It doesn't need to be discussed close to a beta cycle, IMO, or it could easily turn into the huge distraction Tom speaks of. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
What projects have big roadmaps? The only one I can think of is Mozilla, and we all know how well that worked (aka Firefox). In fact, you could argue that the Mozilla focus on the roadmap blinded them to focusing on user needs, and made the obsolete. I have modifed the TODO HTML so the completed items are in italics. --------------------------------------------------------------------------- Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > > I don't think anybody is arguing for a radical change in culture - > > certainly I would not be so presumptuous after only a couple of years > > :-) But a roadmap could be useful in many ways. It need not tie anybody > > down, if positioned right, but can help people to see where things are > > going, and where the gaps are. This could in a sense be as simple as > > prioritising the TODO list. > > I think that even getting that done would turn into a flamew^H^H^H^Hhuge > distraction. The way things really work around here is that individual > developers have their own priorities and they work on what seems most > important to them at the time. (In some cases those priorities may be > set by their companies more than by the individuals, but that's > irrelevant from the community's perspective.) ISTM any sort of > project-wide prioritization would be either (1) meaningless or (2) a > guaranteed-to-fail attempt to assert control over other contributors. > > But the TODO list could certainly be made more informative without > getting into that swamp. I don't think it does very well at conveying > the relative sizes of the work items, nor the extent to which there is > consensus about how particular problems ought to be solved (the fact > that something is on TODO does not necessarily mean that all the major > contributors have bought into it...). And of course you're right that > it tells nothing at all about whether progress is currently being made > on a given item. The markers indicating that someone has expressed > interest in an item don't mean they are actively doing anything with it. > > The real difficulty here is exactly what Lamar noted: who's going to do > the work? Bruce seems to be swamped already, so we'd need a new > volunteer to maintain a more useful TODO list, and there doesn't seem > to be anyone who wants to do it and has the depth of familiarity with > the project to do a good job of it. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Lamar Owen <lowen@pari.edu> writes: > To put it much more bluntly: PostgreSQL development (both the process > and the codebase) has one of the steepest learning curves around, The backend hacking curve is certainly steep, but I wonder whether the problem isn't largely one of people biting off more than they can chew. I got my start by hacking some things in libpq, which is way more self-contained than any aspect of the backend; and then started hacking relatively small backend stuff. I think the reason I know as much as I do today is that I've always been willing to investigate minor bugs. No one of them was all *that* exciting, but over time I've had the opportunity to study a lot of the backend code. Nearby you can watch Neil Conway bootstrapping himself by doing minor code beautification projects --- again not that exciting in itself, but useful, and in any case the *real* reason he's doing it is to learn the backend code in general. (Right, Neil?) As against that I notice some new arrivals proposing to add deductive reasoning to Postgres: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php or implement SQL99 hierarchical queries: http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I might be wrong, but I'll bet lunch that neither of those projects will come to anything. You can't run before you learn to crawl. Maybe what we need is some documentation about how to get started as a Postgres hacker --- what to read, what sort of things to tackle for your first hack, etc. I think the people who have been successful around here are the ones who have managed to figure out the syllabus by themselves ... but surely we could try to teach those who come after. regards, tom lane
Lamar, > > To put it much more bluntly: PostgreSQL development (both the process > > and the codebase) has one of the steepest learning curves around, You haven't looked at the OpenOffice.org code. <wince> -- Josh Berkus Aglio Database Solutions San Francisco
On Tue, May 17, 2005 at 01:32:03AM -0400, Tom Lane wrote: > Maybe what we need is some documentation about how to get started > as a Postgres hacker --- what to read, what sort of things to tackle > for your first hack, etc. I think the people who have been successful > around here are the ones who have managed to figure out the syllabus > by themselves ... but surely we could try to teach those who come > after. Didn't such a document exist at one point? I seem to remember reading about it on the old website... I think it might also be valuable to have a list of things that are good 'starter projects'. Maybe some indication of TODO items that are simpler. Possibly a list of bugs, too. It would probably also be useful to point out ways people can help that don't involve hacking C code (or at least not much). Things like docs, the website, advocacy, performance testing, etc. -- Jim C. Nasby, Database Consultant decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828 Windows: "Where do you want to go today?" Linux: "Where do you want to go tomorrow?" FreeBSD: "Are you guys coming, or what?"
Tom Lane wrote: > We did do that (not very rigorously) during the 7.4 release cycle. > I'm not sure why we fell out of the habit again for 8.0. It seems > like a reasonable idea to me. In the past I have suggested incrementally maintaining release.sgml (or some plaintext version of it), rather than having Bruce generate the release notes from a single sweep through the CVS logs prior to a release. The current process can easily lose information: Bruce needs to make a snap decision about which changes are relevant, and it's not always easy to make that decision correctly. It also means the person who implemented a feature (and therefore knows the problem well) is not writing the release notes for it. And it means the release notes are always at least a little bit behind the times. IIRC, the previous discussion petered out when Bruce said he prefers the current process. -Neil
On T, 2005-05-17 at 01:32 -0400, Tom Lane wrote: > > As against that I notice some new arrivals proposing to add deductive > reasoning to Postgres: > http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php > or implement SQL99 hierarchical queries: > http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php I guess you have missed most of the latest discussion around hierarchical queries ;) >From what I understand, what is proposed is a "code beautification project", (although likely not minor :) , because the pathes have been around (and allegedly in production use) for a few years already, originally supporting Oracle-style HQs and then, for about a year also subset of SQL99 (it misses SEARCH and CYCLE clauses, see the railroad diagram at http://gppl.moonbone.ru/with_clause.gif ) The patch is available at http://gppl.moonbone.ru/index.shtml > I might be wrong, but I'll bet lunch that neither of those projects will > come to anything. You can't run before you learn to crawl. Maybe you could take a look at the existing patch and comment what are the points that are most "wrong" with it. The last one was for 8.0.1. I'm sure someone more at home with pg internals would get the patch to acceptable level faster, but my feeling is that somehow these patches have been just not interesting to core developers. > Maybe what we need is some documentation about how to get started > as a Postgres hacker --- what to read, what sort of things to tackle > for your first hack, etc. I think the people who have been successful > around here are the ones who have managed to figure out the syllabus > by themselves ... but surely we could try to teach those who come > after. A code documentation or beautification project is usually a good way to get newcomers up to speed. And though the getting the the HQ patch into acceptable shape is probably quite big work, just starting with understanding and documenting what it does now and getting further help from pgsql-hackers on what it should do may be something that is possible without existing thorough understanding. -- Hannu Krosing <hannu@skype.net>
> > I think it might also be valuable to have a list of things that are good > 'starter projects'. Maybe some indication of TODO items that are > simpler. Possibly a list of bugs, too. > As someone who has looked at hacking the pg code, I agree it is difficult to know what to look at to get started. I love fixing bugs, but I'm used to the bug tracker type situation and being able to find something that looks relatively easy. That is how I've started on a number of other projects. With no formal bug tracker, I'm not sure what bugs I could look at. I have talked to some people on IRC about tackling the infinite date issue, but was warned off that, as the date/time code is a scary place. Then I looked into the possibility of working on the autovacuum stuff, and again got myself in a little too deep. Not low enough fruit for me. The curve to get the meaning of some things is sometimes hard PG_TRY and things like that just need reading code lots. Not meaning to attack Tom, but for new people proposing new patches he can seem intimidating. I have been around for a little while now and am adjusting to the reality. Maybe people shouldn't be hacking the code before being here a year. > It would probably also be useful to point out ways people can help that > don't involve hacking C code (or at least not much). Things like docs, > the website, advocacy, performance testing, etc. It would be useful to outline positions that are actually available for people to take. It's easy to give a general list. I've asked and seen may like it. For me, what does helping with advocacy mean? What should be performance tested (I assume new code, like the bitmap scan). But at the same time, how do I not get into something that is being duplicated by somebody else? I'm just trying to give a bit of a perspective on the way I see things as some who has been around pg for about 12 months and attempted to hack the code a couple of times. Regards Russell Smith
On Tue, May 17, 2005 at 09:23:42PM +1000, Russell Smith wrote: > > > I think it might also be valuable to have a list of things that are good > > 'starter projects'. Maybe some indication of TODO items that are > > simpler. Possibly a list of bugs, too. > > As someone who has looked at hacking the pg code, I agree it is > difficult to know what to look at to get started. I love fixing bugs, > but I'm used to the bug tracker type situation and being able to find > something that looks relatively easy. That is how I've started on a > number of other projects. With no formal bug tracker, I'm not sure > what bugs I could look at. I have talked to some people on IRC about > tackling the infinite date issue, but was warned off that, as the > date/time code is a scary place. I'd say the datetime code is a good place to start, the most important characteristic being that it's self contained. > It would be useful to outline positions that are actually available > for people to take. It's easy to give a general list. I've asked and > seen may like it. For me, what does helping with advocacy mean? What > should be performance tested (I assume new code, like the bitmap > scan). Yes, performance testing may also show some implementation bugs that are important to find too. Stress-testing is important too. Or find corner cases, push implementation limits, etc. Or, find some area that people mentions as needing testing, the current example being SIGTERM handling in busy backends. > But at the same time, how do I not get into something that is > being duplicated by somebody else? Tell -hackers. But if you are going to do testing, it doesn't matter there is multiple people doing it. -- Alvaro Herrera (<alvherre[a]surnet.cl>) "The first of April is the day we remember what we are the other 364 days of the year" (Mark Twain)
> It would be useful to outline positions that are actually available for people to take. > It's easy to give a general list. I've asked and seen may like it. For me, what does > helping with advocacy mean? What should be performance tested (I assume new code, > like the bitmap scan). But at the same time, how do I not get into something that is > being duplicated by somebody else? I reckon a good newbie task at the moment would be to add ALTER object SET SCHEMA blah; on all objects... Chris
Russell Smith wrote: >Maybe people shouldn't be hacking the code before being here a year. > > > If you want to code, jump in. It is a practical craft that you only learn by doing. You might learn something of the people but you'll probably learn precious little of the code by just watching. But don't jump in at the deep end - massive reorganisation of the planner should not be your first project ;-). Ask lots of questions. Tell people what you're doing. I like the idea of a "relatively simple low hanging fruit" list that we could point newcomers at. Here are some nominations: . add some more tests for the PLs now we have a standard testing framework. . clean up and document some of the contrib modules so they can go into the core (e.g. pgcrypto, dbsize, cube, seg) . rewrite contrib/reindexdb in C so it can be used on Windows . this TODO item: Remove Money type, add money formatting for decimal type I'm sure other people will have additions to such a list. cheers andrew
Tom Lane <tgl@sss.pgh.pa.us> Date: Tue, 17 May 2005 01:32:03 -0400 > As against that I notice some new arrivals proposing to add deductive > reasoning to Postgres: > http://archives.postgresql.org/pgsql-hackers/2005-05/msg01045.php > or implement SQL99 hierarchical queries: > http://archives.postgresql.org/pgsql-hackers/2005-05/msg01089.php > > I might be wrong, but I'll bet lunch that neither of those projects will > come to anything. You can't run before you learn to crawl. The main advantage of deductive reasoning implementation I propose is in fundamental extension of database query language, I don't propose to extent SQL with some cumbersome constructions, for example, like WITH to express recursive queries (inefficiency of such constructions can be easily seen if you try to express a bit more complex recursive query then finding ancestors, e.g. query which finds minimal paths). Also it should be mentioned that original query language (SQL) de facto remains without great changes, the logic program which defines predicates (intensional relations) is located in the system table (there can be put the name and both the text and inner code of logic program). When we want to get intensional relation we simply write in SQL query the name of the logic program (deductive database) and the name of the predicate with the list of arguments. This syntax is identical to the syntax of table function calling with the schema name. Regards, Dmitriy
Russell, > What should be performance tested (I assume new code, > like the bitmap scan). I've been meaning to put a task list for performance testing up on the TestPerf project. Yet another personal TODO ... -- Josh Berkus Aglio Database Solutions San Francisco
As someone who's been lurking on the postgres lists for quite some time, and submitted one (minor) patch, I think the notion of an "entry-level" task list for we beginners is fantastic. And, I'm sure this has been asked and answered a billion times already, but why *don't* we have a real bug tracking system? BJ
On Wed, 18 May 2005, Brendan Jurd wrote: > As someone who's been lurking on the postgres lists for quite some > time, and submitted one (minor) patch, I think the notion of an > "entry-level" task list for we beginners is fantastic. > > And, I'm sure this has been asked and answered a billion times > already, but why *don't* we have a real bug tracking system? Because none of the core developers will use it, so bugs would be added, but never removed ... Also, how many 'bugs' have we seen go through the lists that someone hasn't jump'd on and fixed in a couple of days? We have a long list of 'TODO' items, but could anyone generate a list of "known bugs"? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Marc G. Fournier wrote: >> >> And, I'm sure this has been asked and answered a billion times >> already, but why *don't* we have a real bug tracking system? > > > Because none of the core developers will use it, so bugs would be > added, but never removed ... Last time it came up I thought the problem was that there was not a consensus on *which* bugtracker to use. Incidentally, I'm not advocating we use bugzilla (if anything I think I'd lean towards using RT), but this seems like a good opportunity to note that as of a week or two ago bugzilla's HEAD branch supports using PostgreSQL as its backing store, and this will be maintained. > > Also, how many 'bugs' have we seen go through the lists that someone > hasn't jump'd on and fixed in a couple of days? We have a long list > of 'TODO' items, but could anyone generate a list of "known bugs"? > Bug tracking systems are used to track more than just bugs ... they are often used to track enhancements, support requests, and other tasks. GForge (and hence pgfoundry) provides each project by default with several trackers, one for each of these classes. But then, as a pgfoundry admin you know that, right? :-) cheers andrew
On Tue, 17 May 2005, Andrew Dunstan wrote: > Last time it came up I thought the problem was that there was not a > consensus on *which* bugtracker to use. The key requirement that has always come up is that the core developers wouldn't use anything web based, so the tracker would have to somehow tie into the mailing lists themselves ... > Bug tracking systems are used to track more than just bugs ... they are > often used to track enhancements, support requests, and other tasks. > GForge (and hence pgfoundry) provides each project by default with > several trackers, one for each of these classes. But then, as a > pgfoundry admin you know that, right? :-) Again, it comes down to who will maintain it? I believe that Bruce has already stated that he hasn't got the time/desire to do much more then his current TODO lists, Tom has stated a lack of desire to use a web-based tracking tool ... so we'd need to find someone with the time to act as intermediary to update things accordingly ... ... and I think *that* is probably one of hte major show stoppers ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664
Andrew, > Last time it came up I thought the problem was that there was not a > consensus on *which* bugtracker to use. Or whether to use one. Roughly 1/3 bugzilla, 1/3 something else, and 1/3 don't want a bugtracker. And, among the people who didn't want bugzilla, some were vehemently opposed to it. Bugtrackers discussed included GForge, bugzilla, RT, Roundup, Jura (they offered a free license) and a few I don't remember. > Incidentally, I'm not advocating we use bugzilla (if anything I think > I'd lean towards using RT), but this seems like a good opportunity to > note that as of a week or two ago bugzilla's HEAD branch supports using > PostgreSQL as its backing store, and this will be maintained. One of the things which came out of the bugtracker discussion is that anything we use must have the ability for developers to interact 100% by e-mail, as some critical developers will not use a web interface. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
> >>Incidentally, I'm not advocating we use bugzilla (if anything I think >>I'd lean towards using RT), but this seems like a good opportunity to >>note that as of a week or two ago bugzilla's HEAD branch supports using >>PostgreSQL as its backing store, and this will be maintained. > > > One of the things which came out of the bugtracker discussion is that anything > we use must have the ability for developers to interact 100% by e-mail, as > some critical developers will not use a web interface. Request Tracker (RT) can do that. We use it for all of our support ticket stuff. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On 5/18/05, Marc G. Fournier <scrappy@postgresql.org> wrote: > > The key requirement that has always come up is that the core developers > wouldn't use anything web based, so the tracker would have to somehow tie > into the mailing lists themselves ... > What's the basis of this objection to a web-based dev management system? Seems like web-based makes plenty of sense for a physically disparate development community like this one. It also seems that, once you get it up and running, any worthwhile dev management system is going to actually take less time / effort to maintain than, say, maintaining manually concocted todo lists and coordinating development via a mailing list. Call me a normaliser, but even if the maintenance cost is higher, I think it's worth it to have a centralised, authoratitive, organised repository for dev task data.
> > What's the basis of this objection to a web-based dev management > system? Seems like web-based makes plenty of sense for a physically > disparate development community like this one. I can't speak for the people who don't like web based but my guess is that the web is not their primary medium of communication. Email is. > > It also seems that, once you get it up and running, any worthwhile dev > management system is going to actually take less time / effort to > maintain than, say, maintaining manually concocted todo lists and > coordinating development via a mailing list. This is true or at least, this is my experience but you are not going to convince many people of that. > Call me a normaliser, but even if the maintenance cost is higher, I > think it's worth it to have a centralised, authoratitive, organised > repository for dev task data. I agree. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
"Joshua D. Drake" <jd@commandprompt.com> writes:
>> It also seems that, once you get it up and running, any worthwhile dev
>> management system is going to actually take less time / effort to
>> maintain than, say, maintaining manually concocted todo lists and
>> coordinating development via a mailing list.
> This is true or at least, this is my experience but you are not going to
> convince many people of that.
The Postgres project has been exceedingly successful while using email
lists as the primary means of communication/organization. I for one
am disinclined to tinker with such a fundamental aspect of the way that
the community operates. If we try to substitute a bug tracker for the
mailing lists, I think we'll be making a very basic change in the
community's communication structure, and not one for the better.
>> Call me a normaliser, but even if the maintenance cost is higher, I
>> think it's worth it to have a centralised, authoratitive, organised
>> repository for dev task data.
> I agree.
Since the development community is neither centralised nor organized,
why would you expect such a repository to have anything to do with
what actually happens?
regards, tom lane
Brendan Jurd wrote: >What's the basis of this objection to a web-based dev management >system? Seems like web-based makes plenty of sense for a physically >disparate development community like this one. > > > > Brendan, please review the past versions of this thread. For example, see here: http://groups-beta.google.com/group/comp.databases.postgresql.hackers/browse_thread/thread/1cca714cc34865a5/f802a2a78c94faa3?q=bugzilla&rnum=1&hl=en#f802a2a78c94faa3 cheers andrew
On Mon, 16 May 2005 20:54:15 -0400 (EDT), Bruce Momjian <pgman@candle.pha.pa.us> wrote: >I have modifed the TODO HTML so the completed items are in italics. Isn't it a bit misleading to have those items on the TODO list at all? Shouldn't there be a separate list: DONE for the next release? ServusManfred
On 5/18/05, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The Postgres project has been exceedingly successful while using email > lists as the primary means of communication/organization. I for one > am disinclined to tinker with such a fundamental aspect of the way that > the community operates. If we try to substitute a bug tracker for the > mailing lists, I think we'll be making a very basic change in the > community's communication structure, and not one for the better. > I agree that it's a major change, and the significance of changing the communication structure should not be underestimated. But a) I believe it would be a change for the better, and b) BZ uses a very flexible and verbose email notification system, so the departure from the existing email list structure would not be so drastic. I read through the discussion link that Andrew provided (thanks Andrew), and during that discussion you appeared to be in favour of bugzilla, for the same sorts of reasons I am promoting it now. What changed? > >> Call me a normaliser, but even if the maintenance cost is higher, I > >> think it's worth it to have a centralised, authoratitive, organised > >> repository for dev task data. > > > I agree. > > Since the development community is neither centralised nor organized, > why would you expect such a repository to have anything to do with > what actually happens? > I think the decentralised nature of the community is one of the things that is responsible for this "steep learning curve", and could stand to be improved. And deploying a more centralised system for development management would be a crucial first step in said improvement. In the interests of putting my money where my mouth is, I would be willing to enlist in the housekeeping effort for this hypothetical new system.
On Tue, 17 May 2005 14:45:00 -0300 (ADT), "Marc G. Fournier" <scrappy@postgresql.org> wrote: >Also, how many 'bugs' have we seen go through the lists that someone >hasn't jump'd on and fixed in a couple of days? Just imagine our marketing crew being able to say: "According to our great bug tracking system NN serious bugs have been reported last year, 98% of which have been fixed within three days." ServusManfred
Manfred, > Just imagine our marketing crew being able to say: "According to our > great bug tracking system NN serious bugs have been reported last year, > 98% of which have been fixed within three days." <grin> You're not going to win over many people on *this* list with marketing arguments. -- --Josh Josh Berkus Aglio Database Solutions San Francisco
Brendan Jurd wrote: > >In the interests of putting my money where my mouth is, I would be >willing to enlist in the housekeeping effort for this hypothetical new >system. > > > > It's a nice offer, but honestly, my experience in the commercial world as well as in FOSS tells me that a bug tracking system would need loving care from somebody with years of experience in the postgres development community. When I was managing this stuff in a commercial setting it took a large part of my day - I had a 30 to 60 minute meeting every morning and spent a further similar period updating, assigning, etc. The people who could do it are just too damned busy. Given the amount that Tom gets done now I'm amazed that he finds time to eat drink and sleep. The things I tried to suggest earlier in this thread would be much less burdensome. As for central management ... the phrase "herding cats" springs to mind. cheers andrew
On Tue, 17 May 2005 14:29:49 -0700, Josh Berkus <josh@agliodbs.com> wrote: ><grin> You're not going to win over many people on *this* list with marketing >arguments. Yeah, that's the problem with *my* learning curve ... ServusManfred
* Brendan Jurd (direvus@gmail.com) wrote:
> In the interests of putting my money where my mouth is, I would be
> willing to enlist in the housekeeping effort for this hypothetical new
> system.
If you're willing to create it, host it, update it and keep it current,
and feel it'd be so worthwhile to people that you'd be willing to
continue to maintain it... Then go for it. You don't need anyone's
approval or even agreement about it. *That* would be putting your money
where your mouth is.
Thanks,
Stephen
* Joshua D. Drake (jd@commandprompt.com) wrote: > >One of the things which came out of the bugtracker discussion is that > >anything we use must have the ability for developers to interact 100% by > >e-mail, as some critical developers will not use a web interface. > > Request Tracker (RT) can do that. We use it for all of our support > ticket stuff. debbugs can do it too, though I don't know of anyone who's actually got it working outside of the Debian stuff. :) Personally, I like Debian's bug tracking system, but I suppose that's just me... I believe OTRS can do it too. Havn't played with the email interface of it really though. Stephen
On 5/18/05, Stephen Frost <sfrost@snowman.net> wrote: > * Brendan Jurd (direvus@gmail.com) wrote: > > In the interests of putting my money where my mouth is, I would be > > willing to enlist in the housekeeping effort for this hypothetical new > > system. > > If you're willing to create it, host it, update it and keep it current, > and feel it'd be so worthwhile to people that you'd be willing to > continue to maintain it... Then go for it. You don't need anyone's > approval or even agreement about it. *That* would be putting your money > where your mouth is. > I'm detecting sarcasm here, but just in case you're being serious ... For such a tool to serve its intended purpose, the postgres community needs to be, to a certain extent, agreed on and aware of its use as the primary dev management system. There's no point creating, hosting, updating and maintaining anything if the community isn't using it.
On Wed, May 18, 2005 at 08:04:51AM +1000, Brendan Jurd wrote: > On 5/18/05, Stephen Frost <sfrost@snowman.net> wrote: > > * Brendan Jurd (direvus@gmail.com) wrote: > > > In the interests of putting my money where my mouth is, I would be > > > willing to enlist in the housekeeping effort for this hypothetical new > > > system. > > > > If you're willing to create it, host it, update it and keep it current, > > and feel it'd be so worthwhile to people that you'd be willing to > > continue to maintain it... Then go for it. You don't need anyone's > > approval or even agreement about it. *That* would be putting your money > > where your mouth is. > > I'm detecting sarcasm here, but just in case you're being serious ... I don't think Stephen was being sarcastic. Such a system would need an enormous bootstrap effort. Once it's in place, and having shown its usefulness, maybe the community would start using it. (Of course no one can make promises on that other than for himself.) -- Alvaro Herrera (<alvherre[a]surnet.cl>) Oh, oh, las chicas galacianas, lo harán por las perlas, ¡Y las de Arrakis por el agua! Pero si buscas damas Que se consuman como llamas, ¡Prueba una hija de Caladan! (Gurney Halleck)
* Brendan Jurd (direvus@gmail.com) wrote: > I'm detecting sarcasm here, but just in case you're being serious ... Yeah, for the most part I *was* being quite serious. > For such a tool to serve its intended purpose, the postgres community > needs to be, to a certain extent, agreed on and aware of its use as > the primary dev management system. > > There's no point creating, hosting, updating and maintaining anything > if the community isn't using it. Nope, that's not the way the world works. "If you build it, they will come." You'll want to make the *community* aware of it, sure, but that's just to encourage people to use it. You don't need anything to be agreed upon, either people will use it, or they won't. If enough people use it that it becomes apparent that it's clearly better *then* you'll likely get a more buy-in and acceptance from developers. Until the developers are on-board you'll need to act as an intermediary (unless you can automate it) between the people using your system and the developers. That's more of your time, but if you're willing to spend it on this to prove it's a better way to work, then go for it. You're never going to get everyone to whole-sale jump over to a new system. It's just not going to happen. You need to build the basics and then get people to start using it. Eventually if it manages to get to a critical mass of some sort you'll get enough people using it that some of them may be willing to help maintain it- perhaps not even developers but other people who are willing to help with the interaction with the developers. You could always start by just doing the 'todo' list that Bruce has and maintaining it as a set of 'enhancements' in the system you build. That shouldn't even be very hard to keep up to date w/ Bruce's todo list provided you watch for his commits to it on the CVS mailing list. Then, if people decide to use your system to open up new enhancement requests you can forward them on to the appropriate list/people and if it makes it onto Bruce's 'todo' list then some how mark it as 'approved' or something to distinguish it from stuff that's been suggested/asked for that *doesn't* make it on the list (and thus is unlikely to be done or worked on). Having the list of "stuff that didn't make it" would actually be useful and is something Bruce's list misses and thus would be a valuable addition (imv) you would be providing. Now, generally the way this kind of stuff works is that someone gets bitten by a bug and just decides this would be useful and just *does* it w/o asking permission or getting approval from anyone. When people just ask permission or nebulously volunteer their time towards it, generally it *doesn't* happen. Just my 2c. Stephen
> > > I don't think Stephen was being sarcastic. Such a system would need an > enormous bootstrap effort. Once it's in place, and having shown its > usefulness, maybe the community would start using it. > (Of course no one can make promises on that other than for himself.) Well sorry but that is ridiculous. Either the community (or more specifically core) chooses to use it upfront or not. I think it is a complete waste of time and energy to expect someone to put in all that effort just to have the community give them the finger. This isn't something that is going to serve the person who loose all the sleep to configure and maintain it. It is something that is going to help the PostgreSQL community has a whole, to grow in a reasonably organized and hopefully less painful way. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
On Tue, May 17, 2005 at 06:25:16PM -0400, Alvaro Herrera wrote: > On Wed, May 18, 2005 at 08:04:51AM +1000, Brendan Jurd wrote: > > On 5/18/05, Stephen Frost <sfrost@snowman.net> wrote: > > > * Brendan Jurd (direvus@gmail.com) wrote: > > > > In the interests of putting my money where my mouth is, I would be > > > > willing to enlist in the housekeeping effort for this hypothetical new > > > > system. > > > > > > If you're willing to create it, host it, update it and keep it current, > > > and feel it'd be so worthwhile to people that you'd be willing to > > > continue to maintain it... Then go for it. You don't need anyone's > > > approval or even agreement about it. *That* would be putting your money > > > where your mouth is. > > > > I'm detecting sarcasm here, but just in case you're being serious ... > > I don't think Stephen was being sarcastic. Such a system would need an > enormous bootstrap effort. Once it's in place, and having shown its > usefulness, maybe the community would start using it. > (Of course no one can make promises on that other than for himself.) The useful bug tracking systems I've used have also included QA. Any bug submitted doesn't get accepted without a standalone test case. That test case is used both to confirm that the bug has been fixed once it's fixed, and is added into a set of regression tests. If someone were to create test cases for (some or all of the) submitted bugs (or handle the management of their creation) and track which test cases passed (via a tinderbox, or even the existing build-farm) that'd be a useful thing in itself. I suspect it'd be a useful thing for someone who has energy to expend on bug-tracking to do, and probably more immediately useful than anything that requires all the primary developers to change how they're currently handling bugs and to-do lists. Just a thought. Cheers, Steve
On Tue, May 17, 2005 at 03:30:28PM -0700, Joshua D. Drake wrote: > >I don't think Stephen was being sarcastic. Such a system would need an > >enormous bootstrap effort. Once it's in place, and having shown its > >usefulness, maybe the community would start using it. > >(Of course no one can make promises on that other than for himself.) > > Well sorry but that is ridiculous. Either the community (or more > specifically core) chooses to use it upfront or not. I think it is a > complete waste of time and energy to expect someone to put in all that > effort just to have the community give them the finger. > > This isn't something that is going to serve the person who loose all the > sleep to configure and maintain it. It is something that is going to > help the PostgreSQL community has a whole, to grow in a reasonably > organized and hopefully less painful way. Maybe I didn't express myself properly. I didn't mean that Brendan should do all the work by himself -- but expecting the whole community, or the usual developers, to do the initial effort, is not likely to make this plane fly. Because the current developers are already comfortable with the current state of affairs, why should they worry about changing the process? This is something the rest of the people can do, for their own sake. It can, of course, serve the community eventually. Would you expect Bruce to enter each and every TODO item in a bug tracking system? I wouldn't. Would I register my own "pet peeves" in such a system? Probably I would. -- Alvaro Herrera (<alvherre[a]surnet.cl>) "Los románticos son seres que mueren de deseos de vida"
>>This isn't something that is going to serve the person who loose all the >>sleep to configure and maintain it. It is something that is going to >>help the PostgreSQL community has a whole, to grow in a reasonably >>organized and hopefully less painful way. > > > Maybe I didn't express myself properly. I didn't mean that Brendan > should do all the work by himself -- but expecting the whole community, > or the usual developers, to do the initial effort, is not likely to make > this plane fly. Because the current developers are already comfortable > with the current state of affairs, why should they worry about changing > the process? This is something the rest of the people can do, for their > own sake. It can, of course, serve the community eventually. O.k. then I misunderstood and apologize. I think the above is reasonable. I wouldn't think that the main developers would stop developing to create this system, nor would I want them to take time away from development to implement it. I would however think that the main developer buy off would be essential. If the primary memebers of the development community said o.k. we are going to implement foo... who wants to spear head it? That would be a good thing. > Would you expect Bruce to enter each and every TODO item in a bug > tracking system? Well that depends... if it replaced the current TODO list as the definitive source then yes I would. I wouldn't. Would I register my own "pet peeves" in > such a system? Probably I would. Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedication Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Manfred Koizar wrote: > On Mon, 16 May 2005 20:54:15 -0400 (EDT), Bruce Momjian > <pgman@candle.pha.pa.us> wrote: > >I have modifed the TODO HTML so the completed items are in italics. > > Isn't it a bit misleading to have those items on the TODO list at all? > Shouldn't there be a separate list: DONE for the next release? The idea is that people who are running 8.0 need to see those items because they aren't _done_ in their release. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On Wed, 18 May 2005 04:31 am, Josh Berkus wrote: > Andrew, > > > Last time it came up I thought the problem was that there was not a > > consensus on *which* bugtracker to use. > > Or whether to use one. Roughly 1/3 bugzilla, 1/3 something else, and 1/3 > don't want a bugtracker. And, among the people who didn't want bugzilla, > some were vehemently opposed to it. Bugtrackers discussed included GForge, > bugzilla, RT, Roundup, Jura (they offered a free license) and a few I don't > remember. > > > Incidentally, I'm not advocating we use bugzilla (if anything I think > > I'd lean towards using RT), but this seems like a good opportunity to > > note that as of a week or two ago bugzilla's HEAD branch supports using > > PostgreSQL as its backing store, and this will be maintained. > > One of the things which came out of the bugtracker discussion is that anything > we use must have the ability for developers to interact 100% by e-mail, as > some critical developers will not use a web interface. > Doesn't pgfoundry offer this? If not in 3.3, I'm sure it's in Gforge 4.0, or 4.1 which will be released soon. Regards Russell
On 5/18/05, Joshua D. Drake <jd@commandprompt.com> wrote: > O.k. then I misunderstood and apologize. I think the above is > reasonable. I wouldn't think that the main developers would stop > developing to create this system, nor would I want them to take time > away from development to implement it. > I think we can all agree on that. > I would however think that the main developer buy off would be > essential. Yep ... I get the feeling that in this community we have a handful of people doing the overwhelming majority of the development. Getting at least an "in principle" nod of the head from these people is a prerequisite for any major effort IMO. BJ
Russell Smith wrote: >> >>One of the things which came out of the bugtracker discussion is that anything >>we use must have the ability for developers to interact 100% by e-mail, as >>some critical developers will not use a web interface. >> >> >> >Doesn't pgfoundry offer this? If not in 3.3, I'm sure it's in Gforge 4.0, or 4.1 which will be >released soon. > > > > 3.3 does not - have not looked at 4.x. Unless it's gone through a radical upgrade I don't think it's good enough. A mail interface is only part of the story. cheers andrew
Brendan Jurd wrote: > What's the basis of this objection to a web-based dev management > system? Beyond "the core developers want to stick to email", I think there is a good reason that we should stick primarily to email for project management: Bugzilla and similar systems are "point to point", whereas a mailing list is multicast[1]. When someone submits a patch or a bug report to a mailing list, any of the developers can see the report, discuss it, and contribute to resolving it. More often than not, a web-based interface like Bugzilla leads to a single "bug master", who does most of this work by themselves. Besides the fact we don't have such a person, it would also mean that knowledge of bugs/patches and the discussion about resolving issues is distributed among a smaller pool of people. There is definitely room for improvement; submitted patches do occasionally fall through the cracks, for example. I would personally be interested in a "bug-tracking system" that is closer to a shared email archive. Individuals would send mail to a mailing list and other people would reply and eventually resolve the thread, as happens now. The process would be slightly more formalized: there would be a way to specify a few commands via email to close/open/resolve/etc. reports, and some kind of interface (perhaps web-based) for viewing unresolved issues, searching through issues, etc. But the point is that the current system works well; this would just be a slight formalization of existing procedures (we don't *want* a revolutionary change, nor do we need one). I think the administrative overhead wouldn't be too high, either. I'm not sure which existing systems fit this model (suggestions are welcome) -- email needs to be the primary interface, not an afterthought (as is often the case). Perhaps RT would work, I'm not sure. -Neil [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point effectively.
> discuss it, and contribute to resolving it. More often than not, a > web-based interface like Bugzilla leads to a single "bug master", who > does most of this work by themselves. Besides the fact we don't have > such a person, it would also mean that knowledge of bugs/patches and the > discussion about resolving issues is distributed among a smaller pool of > people. I can only speak for RT but with RT you can easily avoid this. For example you can set it up so that anything that would go to patches@postgresql.org would automatically create a ticket an alert all people within the patches group. Multiple people can be assigned to a ticket as a maintainer or just a watcher. You can even respond to specific messages within the thread instead of just a top down (one email after the other). > There is definitely room for improvement; submitted patches do > occasionally fall through the cracks, for example. I would personally be > interested in a "bug-tracking system" that is closer to a shared email > archive. That would be another nice part of RT. RT automatically deals with attachments and although I wouldn't use it for this you could even use it as a semi patch repository until the patch is actually approved for submission. > issues, searching through issues, etc. But the point is that the current > system works well; Well does it though? I am not saying it is bad, well yes I am ;). There is no central place for me to point one of my developers and say -- Hey, look at this patch... weren't we working on something like this? Let's help them out. I have to have the dig through the mail archives which is fairly counter productive. It would be much better to be able to say, hey... look at patch #42345. What do you think? > I'm not sure which existing systems fit this model (suggestions are > welcome) -- email needs to be the primary interface, not an afterthought > (as is often the case). Perhaps RT would work, I'm not sure. RT supports complete email integration. Most of the interaction I do with it is actually through email not through the web interface. It also has the ability to have a knowledge base dropped right on top of it. Sincerely, Joshua D. Drake > > -Neil > > [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point > effectively. > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org
Joshua D. Drake wrote: > You can even respond to specific messages within the thread instead of > just a top down (one email after the other). Well, that seems pretty fundamental... >> But the point is that the current system works well; > > Well does it though? I am not saying it is bad, well yes I am ;). There > is no central place for me to point one of my developers and say -- Hey, > look at this patch... weren't we working on something like this? Let's > help them out. I'm not saying there is not room for improvement -- my point is that the fundamental workflow (email submission of patches, discussion and resolution via mailing list discussion) works well, and I don't see any need to change it. If there are tools that help us improve this process (e.g. archiving the resolution of old issues, as you suggest), they are worth considering. In other words, I'd like a tool that fits the way we work now, not one that forces us to change our processes to adapt to its requirements. Anyway, RT sounds like perhaps it is worth investigating. -Neil
> It also seems that, once you get it up and running, any worthwhile dev > management system is going to actually take less time / effort to > maintain than, say, maintaining manually concocted todo lists and > coordinating development via a mailing list. > > Call me a normaliser, but even if the maintenance cost is higher, I > think it's worth it to have a centralised, authoratitive, organised > repository for dev task data. I 100% agree... There's also this: http://www.issue-tracker.com/ Chris
Neil Conway wrote: > Joshua D. Drake wrote: > > You can even respond to specific messages within the thread instead of > > just a top down (one email after the other). > > Well, that seems pretty fundamental... > > >> But the point is that the current system works well; > > > > Well does it though? I am not saying it is bad, well yes I am ;). There > > is no central place for me to point one of my developers and say -- Hey, > > look at this patch... weren't we working on something like this? Let's > > help them out. > > I'm not saying there is not room for improvement -- my point is that the > fundamental workflow (email submission of patches, discussion and > resolution via mailing list discussion) works well, and I don't see any > need to change it. If there are tools that help us improve this process > (e.g. archiving the resolution of old issues, as you suggest), they are > worth considering. In other words, I'd like a tool that fits the way we > work now, not one that forces us to change our processes to adapt to its > requirements. Agreed. Basically, there is the ideal world, where everything is organized around bug numbers, and there is a tracking system of who has reported the bugs and who fixed them, with a roadmap, and there is the real world, where such organization takes time, and takes time away from doing actual productive work. Now, you can argue that the time to do the maintenance of such a system will pay off, but it is far from clear that is true. No one has shown me a project that has such a system that works better than what we have now, nor a roadmap that is better than ours. If this new setup is so great, please point me to a real project that uses it effectively. The only two projects I have worked with in this area are Mozilla (bugzilla, terribly complex bug tracking and roadmap that drove them off the road), and gaim, which seems to work (sourceforge, everything gets put into a box of feature/bug, etc, and someone comes along and manages that). I don't think either are more effective than what we have now. What we have now is _bad_ for new people trying to jump in and figure things out --- that is the real problem with our current setup. You can't just point someone at bug number XXX. How much is that worth to us in terms of time? I am unsure. I imagine the Mozilla guys spending all day closing bugs and putting things in little boxes (oh, that bug is a duplicate), but the whole time the project is not user-focused and they get superceeded by Firefox because the new project actually gives users what they want. Do we really want people to fill out a bug form, and have us get an email and get an email and reply to the request and close the bug, rather than just email the guy to give them the fix? What does the big bug database actually do for us except give us a big list of thousands of items. I just don't see the huge value in tracking stuff for little payback. Sure, it sounds great, but in practice it seems pretty useless, and there is maintenance cost. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Neil Conway <neilc@samurai.com> writes:
> Beyond "the core developers want to stick to email", I think there is a
> good reason that we should stick primarily to email for project
> management: Bugzilla and similar systems are "point to point", whereas a
> mailing list is multicast[1].
That seems to me to be a great summary of the issue. I've been dealing
with Bugzilla for a few years now in my employment with Red Hat, and
I think the bottom line for that kind of system is that it's designed
to limit the visibility of issues, rather than expose them.
Now that is just exactly what you want for a corporate-sized bug
tracking system --- at Red Hat, I do not want to hear about bugs in the
kernel, or X, or a thousand other components that I have no expertise in
--- but I cannot see that restricting the flow of information is what we
need for Postgres.
I think most of the real advantages of bug trackers that have been
mentioned in this thread have to do with history and searchability.
We have the raw info for that, in the pgsql-bugs and pgsql-commmitters
mail archives, and so it seems to me that this reduces to the perennial
gripe that we don't have good enough search tools for the archives.
regards, tom lane
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > > Beyond "the core developers want to stick to email", I think there is a > > good reason that we should stick primarily to email for project > > management: Bugzilla and similar systems are "point to point", whereas a > > mailing list is multicast[1]. > > That seems to me to be a great summary of the issue. I've been dealing > with Bugzilla for a few years now in my employment with Red Hat, and > I think the bottom line for that kind of system is that it's designed > to limit the visibility of issues, rather than expose them. > > Now that is just exactly what you want for a corporate-sized bug > tracking system --- at Red Hat, I do not want to hear about bugs in the > kernel, or X, or a thousand other components that I have no expertise in > --- but I cannot see that restricting the flow of information is what we > need for Postgres. > > I think most of the real advantages of bug trackers that have been > mentioned in this thread have to do with history and searchability. > We have the raw info for that, in the pgsql-bugs and pgsql-commmitters > mail archives, and so it seems to me that this reduces to the perennial > gripe that we don't have good enough search tools for the archives. Good point, and I think the big criticism of our current system is that it is hard for someone to come in and see only a limited view of our issues. For example, if you only want to see ecpg issues, we don't make it very easy. This is the same issue Joshua Drake was mentioning, that there is no easy way to point someone at bug number XXX and assume they will have a full summary of the issue. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Steve Atkins <steve@blighty.com> writes:
> The useful bug tracking systems I've used have also included QA. Any
> bug submitted doesn't get accepted without a standalone test case.
Side note: while test cases are certainly Good Things that make life
easier for developers, so we should encourage people to provide 'em,
I can't say that I like the idea of a tracking system designed around
the concept that a bug for which you don't have a test case isn't real.
It's not all that easy to make a test case for bugs involving concurrent
behavior. I'd go so far as to say that most of the seriously
interesting bugs that I've dealt with in this project were ones that the
original reporter didn't have a reproducible test case for.
regards, tom lane
On Wed, May 18, 2005 at 12:07:14AM -0400, Tom Lane wrote: > Steve Atkins <steve@blighty.com> writes: > > The useful bug tracking systems I've used have also included QA. Any > > bug submitted doesn't get accepted without a standalone test case. > > Side note: while test cases are certainly Good Things that make life > easier for developers, so we should encourage people to provide 'em, > I can't say that I like the idea of a tracking system designed around > the concept that a bug for which you don't have a test case isn't real. > It's not all that easy to make a test case for bugs involving concurrent > behavior. I'd go so far as to say that most of the seriously > interesting bugs that I've dealt with in this project were ones that the > original reporter didn't have a reproducible test case for. Depends on the context. For a code base like PGs (with, as you say, many possibilities for weird concurrency issues or data driven bugs), or for a development style like PGs (i.e. mostly volunteer), _requiring_ a test case before a bug is worked on makes no sense. Some environments I've worked in, though, have had a stage between "bug submitted" and "bug passed to developer" where someone in QA makes an attempt to create a test case where one was not submitted with the bug. That was more the idea I was suggesting as a possibility - if someone has a QA itch to scratch then trolling postgresql-bugs for bugs without test cases and creating recreatable test cases to attach to those bugs might be a useful thing to do. Cheers, Steve
Steve Atkins <steve@blighty.com> writes:
> On Wed, May 18, 2005 at 12:07:14AM -0400, Tom Lane wrote:
>> It's not all that easy to make a test case for bugs involving concurrent
>> behavior. I'd go so far as to say that most of the seriously
>> interesting bugs that I've dealt with in this project were ones that the
>> original reporter didn't have a reproducible test case for.
> ...
> Some environments I've worked in, though, have had a stage between "bug
> submitted" and "bug passed to developer" where someone in QA makes an
> attempt to create a test case where one was not submitted with the bug.
> That was more the idea I was suggesting as a possibility - if someone has
> a QA itch to scratch then trolling postgresql-bugs for bugs without test
> cases and creating recreatable test cases to attach to those bugs might
> be a useful thing to do.
It's absolutely useful --- in fact, creating a case that fails at least
once-in-a-while is normally the first thing that a developer will try to
do when faced with this sort of report. But that effort doesn't always
require intimacy with the code, so farming it out is not a bad idea for
spreading the work around.
This certainly ties in with the recent discussions about "how can you
contribute when you haven't already learned all of the code base" ...
but to bring it back to the immediate topic, would a bugzilla or RT
system really help compared to our existing mailing-list system?
I've noticed Michael Fuhr and some other folk doing the confirm-bug-
and-provide-test-cases spadework recently, so it seems like this is
already something we can handle.
What it comes down to is that a mailing list encourages many-eyes-on-
one-bug synergy, whereas Bugzilla is designed to send a bug report
to just one pair of eyes, or at most a small number of eyes. I haven't
used RT but I doubt it's fundamentally different.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > What it comes down to is that a mailing list encourages many-eyes-on- > one-bug synergy, whereas Bugzilla is designed to send a bug report > to just one pair of eyes, or at most a small number of eyes. I haven't > used RT but I doubt it's fundamentally different. Actually RT is quite different. It's very closely tied to email. You get all the updates in email and can respond to the emails and the results are archived in the ticket. However RT isn't really targeted at bug tracking specifically. It's more of a trouble ticket system. Targeted largely to things like NOCs or incident response ticketing systems. It's much more flexible than pure bug tracking systems like bugzilla and might be able to adapt to a more open email based working model better. But by the same token it would take more attention to set it up and adapt it to bug tracking. -- greg
Greg Stark <gsstark@mit.edu> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> What it comes down to is that a mailing list encourages many-eyes-on-
>> one-bug synergy, whereas Bugzilla is designed to send a bug report
>> to just one pair of eyes, or at most a small number of eyes. I haven't
>> used RT but I doubt it's fundamentally different.
> Actually RT is quite different. It's very closely tied to email. You get all
> the updates in email and can respond to the emails and the results are
> archived in the ticket.
[ shrug... ] BZ sends me email too --- for the things *it* thinks I
should know about.
The basic point here is that these systems are designed on the
assumption that there is a small, easily identified set of people
who need-to-know about any given problem. We (Postgres) have done
well by *not* using that assumption, and I'm not eager to adopt a
tool that forces us to buy into that mindset.
regards, tom lane
Joshua, does RT has full support of PostgreSQL ? Oleg On Tue, 17 May 2005, Joshua D. Drake wrote: > >> discuss it, and contribute to resolving it. More often than not, a >> web-based interface like Bugzilla leads to a single "bug master", who does >> most of this work by themselves. Besides the fact we don't have such a >> person, it would also mean that knowledge of bugs/patches and the >> discussion about resolving issues is distributed among a smaller pool of >> people. > > I can only speak for RT but with RT you can easily avoid this. For example > you can set it up so that anything that would go to patches@postgresql.org > would automatically create a ticket an alert all people within the patches > group. > > Multiple people can be assigned to a ticket as a maintainer or just a > watcher. > > You can even respond to specific messages within the thread instead of just a > top down (one email after the other). > > >> There is definitely room for improvement; submitted patches do occasionally >> fall through the cracks, for example. I would personally be interested in a >> "bug-tracking system" that is closer to a shared email archive. > > That would be another nice part of RT. RT automatically deals with > attachments and although I wouldn't use it for this you could even use it as > a semi patch repository until the patch is actually approved for submission. > >> issues, searching through issues, etc. But the point is that the current >> system works well; > > Well does it though? I am not saying it is bad, well yes I am ;). There is no > central place for me to point one of my developers and say -- Hey, > look at this patch... weren't we working on something like this? Let's help > them out. > > I have to have the dig through the mail archives which is fairly counter > productive. It would be much better to be able to say, hey... look at patch > #42345. What do you think? > >> I'm not sure which existing systems fit this model (suggestions are >> welcome) -- email needs to be the primary interface, not an afterthought >> (as is often the case). Perhaps RT would work, I'm not sure. > > RT supports complete email integration. Most of the interaction I do with it > is actually through email not through the web interface. It also has the > ability to have a knowledge base dropped right on top of it. > > Sincerely, > > Joshua D. Drake > > > >> >> -Neil >> >> [1] Hat-tip to Andrew Morton's keynote at LCA, which made this point >> effectively. >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 6: Have you searched our list archives? >> >> http://archives.postgresql.org > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Tom Lane wrote: > Greg Stark <gsstark@mit.edu> writes: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > >> What it comes down to is that a mailing list encourages many-eyes-on- > >> one-bug synergy, whereas Bugzilla is designed to send a bug report > >> to just one pair of eyes, or at most a small number of eyes. I haven't > >> used RT but I doubt it's fundamentally different. > > > Actually RT is quite different. It's very closely tied to email. You get all > > the updates in email and can respond to the emails and the results are > > archived in the ticket. > > [ shrug... ] BZ sends me email too --- for the things *it* thinks I > should know about. > > The basic point here is that these systems are designed on the > assumption that there is a small, easily identified set of people > who need-to-know about any given problem. We (Postgres) have done > well by *not* using that assumption, and I'm not eager to adopt a > tool that forces us to buy into that mindset. What we do now is not to require the reporter or the developers to classify the email traffic, and the burden is on the people looking for specific information to find it. I am not suggesting we change that, but this the trade-off we have made. The only classification we do is the TODO list and the release notes --- everything else is email searches. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On K, 2005-05-18 at 02:23 -0400, Bruce Momjian wrote: > What we do now is not to require the reporter or the developers to > classify the email traffic, and the burden is on the people looking for > specific information to find it. > > I am not suggesting we change that, but this the trade-off we have made. > The only classification we do is the TODO list and the release notes --- > everything else is email searches. Maybe we should look for some mail-archive software which allows adding such tagging after the mail is stored in the list, so that once someone has found the information he was looking for, he could check some checkboxes or make some selections to make finding the info easier the next time. > -- Hannu Krosing <hannu@skype.net>
Tom Lane said: > Greg Stark <gsstark@mit.edu> writes: >> Tom Lane <tgl@sss.pgh.pa.us> writes: >>> What it comes down to is that a mailing list encourages many-eyes-on- >>> one-bug synergy, whereas Bugzilla is designed to send a bug report to >>> just one pair of eyes, or at most a small number of eyes. I haven't >>> used RT but I doubt it's fundamentally different. > >> Actually RT is quite different. It's very closely tied to email. You >> get all the updates in email and can respond to the emails and the >> results are archived in the ticket. > > [ shrug... ] BZ sends me email too --- for the things *it* thinks I > should know about. > > The basic point here is that these systems are designed on the > assumption that there is a small, easily identified set of people > who need-to-know about any given problem. We (Postgres) have done well > by *not* using that assumption, and I'm not eager to adopt a > tool that forces us to buy into that mindset. > Actually, when BZ sends you mail, it's acting on choices that you have made, or someone at RedHat has made for you. You have a lot of control over what it sends. You want all the email? Tell BZ and you should get it. By contrast with these fine-grained controls, a mailing list offers you one choice: subscribe or don't. Apart from the question of who gets notifications, tracking systems provide some structure and manageability to the data. I find it mildly ironic to see database people eschew the methods of organisation which their own product could help to provide. But all this discussion seems to me pointless anyway - I don't see anybody with enough experience and respect being able to devote enough time to keep a tracking system healthy and useful. And without that we might as well just sit tight. Meanwhile, how about the earlier suggestions related to improving the TODO list a bit (e.g. a "beginner's list")? cheers andrew
Tom Lane <tgl@sss.pgh.pa.us> writes: > [ shrug... ] BZ sends me email too --- for the things *it* thinks I > should know about. Right, what I'm saying is that in RT it's more flexible; you can set it up to send mail for the things *you* think people should know about. Also, BZ and most bug tracking systems make it hard to keep email as the communication mechanism of choice. Most of them (like BZ) just send you email with URLs to click to go to the web. There's also the Debian bug tracking system. It also works well with a mailing list set to be the maintainer. Then everyone on the mailing list gets every update on any bug. And you can update or close bugs by just sending email. Several of the larger Debian packages use this model including the X packages. -- greg
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > I think most of the real advantages of bug trackers that have been > mentioned in this thread have to do with history and searchability. > We have the raw info for that, in the pgsql-bugs and pgsql-commmitters > mail archives, and so it seems to me that this reduces to the perennial > gripe that we don't have good enough search tools for the archives. This also means, to some extent anyway, that someone who wants to show off the latest-greatest bug tracking system that will satisfy all our needs could 'seed' the system with at least some of the history that's available currently through the mailing list archives. If they (or the part of the community interested in it, whatever) then work to keep it up to date and show that it's a better system in whatever way, that'd go a great deal farther towards acceptance. Stephen
People: I think maybe we're putting on the frosting without the cake here. The primary purpose of bug trackers is to help get bugs fixed. Over the last couple of days, we've had a lot of comments from major bug-fixers that a BT isn't *needed* to get bugs fixed. Let's look at tools which address what we actually *do* need, rather than what we don't. Here's where I see a lack: 1) The TODO list is a bit impenetrable for new hackers wanting to get started with PostgreSQL tasks. 2) Users could use a place to look up their current bug and find out what version it was/will be fixed in. 3) Users could use a place to look up known issues/misunderstandings and find education and workarounds. None of those tasks necessarily requires a bug tracker. In fact, I'd advocate a project task list for (1) (which we conveninetly have in pgFoundry) and a knowledge base for (2) and (3). The issue in all cases is upkeep. -- Josh Berkus Aglio Database Solutions San Francisco
On Wednesday 18 May 2005 04:54, Andrew Dunstan wrote:
> Meanwhile, how about the earlier suggestions related to improving the TODO
> list a bit (e.g. a "beginner's list")?
>
I think it would be simple enough to tag certain items on the list as low
hanging fruit that there is no reason not to do it.
On a side note, I think that also moving a few items in to a "urgent" section
like we had for 8.0 would be a really good idea for the start of each
development cycle. Tom mentioned that an item being included on the TODO list
doesn't mean all of core has bought in to it, so let's see a few items that
all of core has bought in to and agrees we might be close to. (Hierarchical
queries and updateable views, both of which are items with outstanding
patches/work and general core approval, come to mind.)
While we can't garauntee these things will be included in any release, a
section of 4-5 items that core/hackers agreed that should be in the next
release would probably help steer people to tackling those problems.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
Oleg Bartunov wrote: > Joshua, > > does RT has full support of PostgreSQL ? It support's Postgres, but it uses a dynamic query builder that is pretty brain dead. It only implements features that are cross DB compatible. It comes up with some pretty ugly queries. -- Brad Nicholson 416-673-4106 Database Administrator, Afilias Canada Corp.
On Tuesday 17 May 2005 01:41, Josh Berkus wrote: > > > To put it much more bluntly: PostgreSQL development (both the process > > > and the codebase) has one of the steepest learning curves around, > You haven't looked at the OpenOffice.org code. <wince> Yes, I have. Yes, it's steeper. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
* Lamar Owen (lowen@pari.edu) wrote:
> On Tuesday 17 May 2005 01:41, Josh Berkus wrote:
> > > > To put it much more bluntly: PostgreSQL development (both the process
> > > > and the codebase) has one of the steepest learning curves around,
>
> > You haven't looked at the OpenOffice.org code. <wince>
>
> Yes, I have. Yes, it's steeper.
That seems rather odd to me. I havn't really looked at the
OpenOffice.org code very much but generally I've found the PostgreSQL
code to be pretty well commented and generally well thought-out. I've
also found the acceptance, understanding and hand-holding of the
PostgreSQL developers to be *better* than I've found in other
communities (such as the Linux kernel...) that I've developed and have
had code included in.
I havn't actually gotten anything real into PostgreSQL *yet*, but I've
been spending a fair bit of time on implementing support for SQL Roles
and have had alot of help developing the approach for best implementing
it (thanks Tom!) and help with stupid questions (what's a tuple?) from
a couple developers on IRC (thanks Neil! thanks Andrew!).
So, no, I don't think the barrier to entry is all that steep, and it's
certainly not *too* steep by any means.
Thanks,
Stephen
On Wed, May 18, 2005 at 05:19:55PM -0400, Stephen Frost wrote: > * Lamar Owen (lowen@pari.edu) wrote: > > On Tuesday 17 May 2005 01:41, Josh Berkus wrote: > > > > > To put it much more bluntly: PostgreSQL development (both the process > > > > > and the codebase) has one of the steepest learning curves around, > > > > > You haven't looked at the OpenOffice.org code. <wince> > > > > Yes, I have. Yes, it's steeper. > > That seems rather odd to me. I havn't really looked at the > OpenOffice.org code very much but generally I've found the PostgreSQL > code to be pretty well commented and generally well thought-out. I've > also found the acceptance, understanding and hand-holding of the > PostgreSQL developers to be *better* than I've found in other > communities (such as the Linux kernel...) that I've developed and have > had code included in. Certainly the code is exceptionally beautiful. Anyone who has seen both Postgres' and MySQL sources can confirm that I think. Now *that* is an unreadable mess :-( > I havn't actually gotten anything real into PostgreSQL *yet*, but I've > been spending a fair bit of time on implementing support for SQL Roles > and have had alot of help developing the approach for best implementing > it (thanks Tom!) and help with stupid questions (what's a tuple?) from > a couple developers on IRC (thanks Neil! thanks Andrew!). Say, how are you doing on that front? -- Alvaro Herrera (<alvherre[a]surnet.cl>) "No es bueno caminar con un hombre muerto"
Josh Berkus wrote: >1) The TODO list is a bit impenetrable for new hackers wanting to get started >with PostgreSQL tasks. > > > [snip] >In fact, I'd >advocate a project task list for (1) (which we conveninetly have in >pgFoundry) > > It belongs as part of the TODO list, I believe, or keeping it in sync will bedevil it. Just mark possible beginner tasks with something, like *, # or whatever. Or else maybe give them their own section. cheers andrew
* Alvaro Herrera (alvherre@surnet.cl) wrote:
> > I havn't actually gotten anything real into PostgreSQL *yet*, but I've
> > been spending a fair bit of time on implementing support for SQL Roles
> > and have had alot of help developing the approach for best implementing
> > it (thanks Tom!) and help with stupid questions (what's a tuple?) from
> > a couple developers on IRC (thanks Neil! thanks Andrew!).
>
> Say, how are you doing on that front?
Current status is- it now compiles with a few pieces still missing:
Better parser/backend setup needs to be done. I've hacked 'create role'
into place where 'create group' was, but really I need to sit down and
think about the *correct* statements, looking at the standard, etc,
and write those and the associated back-end parts (most of the back-end
parts are already done I think). Once those are done and implemented
I'll see about backwards compatibility to the create user/create group
parts.
pg_group and associated views (information_schema, etc). We don't
currently have an aggregate-into-array function that I saw so either
we'll need to write one or we'll have to fake the information in
pg_group (as, say, just the first group you're in, or something). This
is only for backwards-compatibility to things which used pg_group so I'm
not sure how important it is for it to be fully functional. I *think* I
updated all the information_schema views to not use pg_group but to use
the new system tables and that they're implemented correctly. I'm
trying to think but there might be another view that was involved in
this but I'm not sure.
Write the base-case (no cache available) 'in_role' lookup code. I
expect this code will also be used during role assignment to verify
there are no loops. 'in_role' currently works for the one-level case,
but doesn't handle the multi-level case. Shouldn't be too hard to do.
Per-connection cacheing code for 'in_role' information. Discussed
this with Tom, basically it'll be similar to the search_path cacheing
code which is in namespace.c where the cache is marked out of date
and regenerated whenever there's a change to the pg_auth_members
table. Don't expect this to be very difficult. Once this is done
the 'in_role' code in the ACL system will need to be updated for it.
flat-file startup updating. This is what I'm currently working on. The
difficulty is that I want the flat-files to have only names but the
role/member information is in terms of Oids which need to be looked up
to role names. Since this is during startup code now the syscache isn't
available. What I'm doing is building a copy of the tables in memory
(since they should be reasonably small), qsorting them and using bsearch
for the lookups. Since they're in memory already and the
write-new-role-information situation is much less common than startup I
think I'm also going to qsort based on role name and define the format
of the pg_auth table to be already-sorted so that the startup code
doesn't need to sort it.
Once I get all of the startup code working and can actually *connect* to
the database I'll be doing a great deal more testing, bug fixing, and
implementing the remaining items and testing them.
Thanks,
Stephen
Stephen Frost <sfrost@snowman.net> writes:
>> Say, how are you doing on that front?
> Current status is- it now compiles with a few pieces still missing:
> [snip]
It's essential IMHO that we provide pg_shadow and pg_group as reasonably
backward-compatible views on the new pg_roles catalog. It's not at all
negotiable that CREATE USER and CREATE GROUP have to still work in a
sane fashion --- to say otherwise is to say that we aren't going to load
pg_dumpall scripts from older PG versions, and that is a Non Starter.
(Not too many releases ago, we couldn't even say that: once upon a time
pg_dumpall tried to emit "COPY TO pg_shadow" commands :-(. But I hope
that it's no longer necessary to handle that ...)
regards, tom lane
sfrost@snowman.net (Stephen Frost) writes: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> I think most of the real advantages of bug trackers that have been >> mentioned in this thread have to do with history and searchability. >> We have the raw info for that, in the pgsql-bugs and >> pgsql-commmitters mail archives, and so it seems to me that this >> reduces to the perennial gripe that we don't have good enough >> search tools for the archives. > > This also means, to some extent anyway, that someone who wants to > show off the latest-greatest bug tracking system that will satisfy > all our needs could 'seed' the system with at least some of the > history that's available currently through the mailing list > archives. If they (or the part of the community interested in it, > whatever) then work to keep it up to date and show that it's a > better system in whatever way, that'd go a great deal farther > towards acceptance. There's a good point. If you can take something like RT and "seed" it with a sufficiently sizable set of reasonably deeply interlinked data, such that it could be useful for some "use cases," that could represent a useful experiment. I have some small understanding of what's good and bad about RT; there's certainly some merit to it from several perspectives: 1. It adds a way to support uploaded 'objects.' 2. It adds a way to link together related discussions for posterity. 3. It allows associating various extended attributes with tickets. Commonly, that is used for associating them with customers or business partners. It would be obvious for PostgreSQL to have software components as associations. It certainly does offer the ability for interested folk to see a "multicasted" presentation of discussion. The "deeper" the initial seeding, the better, of course. -- (format nil "~S@~S" "cbbrowne" "acm.org") http://www.ntlug.org/~cbbrowne/sap.html Rules of the Evil Overlord #78. "I will not tell my Legions of Terror "And he must be taken alive!" The command will be: ``And try to take him alive if it is reasonably practical.''" <http://www.eviloverlord.com/>
Andrew Dunstan wrote: > Tom Lane said: > > Greg Stark <gsstark@mit.edu> writes: > >> Tom Lane <tgl@sss.pgh.pa.us> writes: > >>> What it comes down to is that a mailing list encourages many-eyes-on- > >>> one-bug synergy, whereas Bugzilla is designed to send a bug report to > >>> just one pair of eyes, or at most a small number of eyes. I haven't > >>> used RT but I doubt it's fundamentally different. > > > >> Actually RT is quite different. It's very closely tied to email. You > >> get all the updates in email and can respond to the emails and the > >> results are archived in the ticket. > > > > [ shrug... ] BZ sends me email too --- for the things *it* thinks I > > should know about. > > > > The basic point here is that these systems are designed on the > > assumption that there is a small, easily identified set of people > > who need-to-know about any given problem. We (Postgres) have done well > > by *not* using that assumption, and I'm not eager to adopt a > > tool that forces us to buy into that mindset. > > > > Actually, when BZ sends you mail, it's acting on choices that you have made, > or someone at RedHat has made for you. You have a lot of control over what > it sends. You want all the email? Tell BZ and you should get it. By contrast > with these fine-grained controls, a mailing list offers you one choice: > subscribe or don't. Right, if you classify the information coming in, you can set controls over who sees it. What we don't do now is any kind of classification. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
On May 20, 2005, at 11:43 PM, Bruce Momjian wrote: > Andrew Dunstan wrote: > >> Actually, when BZ sends you mail, it's acting on choices that you >> have made, >> or someone at RedHat has made for you. You have a lot of control >> over what >> it sends. You want all the email? Tell BZ and you should get it. >> By contrast >> with these fine-grained controls, a mailing list offers you one >> choice: >> subscribe or don't. >> > > Right, if you classify the information coming in, you can set controls > over who sees it. What we don't do now is any kind of classification. This may be a bit off-the-wall, but I recall Joel Spolsky recently writing about using Bayesian filtering to classify mail into groups other than spam/ham. I wonder if there's any use for something like that in this case. http://www.joelonsoftware.com/articles/FogBugzII.html Michael Glaesemann grzm myrealbox com
On Fri, May 20, 2005 at 11:59:00PM +0900, Michael Glaesemann wrote: > >Right, if you classify the information coming in, you can set controls > >over who sees it. What we don't do now is any kind of classification. > > This may be a bit off-the-wall, but I recall Joel Spolsky recently > writing about using Bayesian filtering to classify mail into groups > other than spam/ham. I wonder if there's any use for something like > that in this case. > > http://www.joelonsoftware.com/articles/FogBugzII.html No, definitely not. Pseudo-bayesian classification as used by the more optimistic spam-filtering folks is pretty crappy at the best of times, and it's really unusuable for more than 3-4 categories. There are natural language analysis techniques that'll do this sort of thing, but they're in the realms of research projects, not canned tools. Cheers, Steve
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > It's essential IMHO that we provide pg_shadow and pg_group as reasonably > backward-compatible views on the new pg_roles catalog. It's not at all > negotiable that CREATE USER and CREATE GROUP have to still work in a > sane fashion --- to say otherwise is to say that we aren't going to load > pg_dumpall scripts from older PG versions, and that is a Non Starter. Right, makes sense, I had just busted them while getting the initial code written. I've now gone back and cleaned up the main parser quite a bit with regard to create/alter/drop/etc user/role. My latest work is available here: http://kenobi.snowman.net/~sfrost/pg_role/latest-role_20050609.1.patch.gz Also the .h files in the same directory (pg_auth_members.h, pg_authid.h) which need to be put into src/include/catalog/. It patches and compiles cleanly against latest CVS (at least, latest as of a few hours ago). I've also updated and flushed out a bit the set of milestones/todo items. My latest version of that can be found here: http://kenobi.snowman.net/~sfrost/pg_role/role_milestones * Means completed in the patch, ? means I'm not sure if it's something that should be done or not. No marker means it needs to be done and hasn't been yet. In general I feel it's starting to get close to meeting all the expectations that I had for it. The more critical things, imv, are the ACL changes for multi-level role resolution (for owners and others) and the per-backend role-member cacheing and fixing the other parsers (ecpg, etc, shouldn't be too hard now that I've got it figured out for the main parser, or at least think I do). Unfortunately, it's starting to get close to July 1st and my availablity is rather sporadic in terms of when I can spend time on this. I'd certainly be willing to work with others (I'm generally pretty responsive to email) to get this finished off and polished up. I do hope to spend some more time on it over the next two weeks and may be able to finish it by July 1st myself but I can't really be 100% sure on that. Thanks, Stephen