Re: [HACKERS] On status data and summaries
On Thu, Oct 12, 2006 at 05:26:02PM -0400, Bruce Momjian wrote: What I think people wanted was something like that, but maintained during the development cycle, so they would know what features our being worked on, and by whom. I'd be happy to work on that. One great thing about the list I maintain is that it is a flat text file, so I can update it in seconds. If a wiki doesn't work, then surely a CVS repository with the flat file in it would? That'd be easy enough to post weekly or something, no? A -- Andrew Sullivan | [EMAIL PROTECTED] Windows is a platform without soap, where rats run around in open sewers. --Daniel Eran ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] On status data and summaries
Andrew Sullivan wrote: On Thu, Oct 12, 2006 at 05:26:02PM -0400, Bruce Momjian wrote: What I think people wanted was something like that, but maintained during the development cycle, so they would know what features our being worked on, and by whom. I'd be happy to work on that. One great thing about the list I maintain is that it is a flat text file, so I can update it in seconds. If a wiki doesn't work, then surely a CVS repository with the flat file in it would? That'd be easy enough to post weekly or something, no? I can give you an ssh account here, or you can just email a file to a special email address and my web site will reflect any changes. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] On status data and summaries
On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote: Funny, sounds like what I usually do. I welcome the assistance. Well, yes, that was my impression too. The complaint in the thread that started all this, as I understood it, was that there were big, hairy features that tended to have long discussions about them, and very few people among even the committers seemed to have a clear idea of exactly where things stood at the end of coding. But I take Jim Nasby's point, that the request for monitoring isn't going to come. How about an alternative: _you_ delegate threads/features/whatever to me to watch? Would that help? (I don't care how we do it, so long as it would be helpful and so long as it's wanted.) A -- Andrew Sullivan | [EMAIL PROTECTED] Unfortunately reformatting the Internet is a little more painful than reformatting your hard drive when it gets out of whack. --Scott Morris ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] On status data and summaries
On Thu, Oct 12, 2006 at 07:14:36AM -0400, Andrew Sullivan wrote: On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote: Funny, sounds like what I usually do. I welcome the assistance. Well, yes, that was my impression too. The complaint in the thread that started all this, as I understood it, was that there were big, hairy features that tended to have long discussions about them, and very few people among even the committers seemed to have a clear idea of exactly where things stood at the end of coding. Something else that would be helpful is summarizing discussions that don't result in code (perhaps on the developer wiki). That way if someone wants to see the history of something they don't have to wade through the list archives just to have some idea of what's being talked about. This is probably especially important when the discussion results in some design ideas/proposals but never moves forward from there. But I take Jim Nasby's point, that the request for monitoring isn't going to come. How about an alternative: _you_ delegate threads/features/whatever to me to watch? Would that help? (I don't care how we do it, so long as it would be helpful and so long as it's wanted.) I'd be happy to help as well. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] On status data and summaries
Jim C. Nasby wrote: On Thu, Oct 12, 2006 at 07:14:36AM -0400, Andrew Sullivan wrote: On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote: Funny, sounds like what I usually do. I welcome the assistance. Well, yes, that was my impression too. The complaint in the thread that started all this, as I understood it, was that there were big, hairy features that tended to have long discussions about them, and very few people among even the committers seemed to have a clear idea of exactly where things stood at the end of coding. Something else that would be helpful is summarizing discussions that don't result in code (perhaps on the developer wiki). That way if someone wants to see the history of something they don't have to wade through the list archives just to have some idea of what's being talked about. This is probably especially important when the discussion results in some design ideas/proposals but never moves forward from there. What I started to do for this is to add the thread URL to the TODO item it relates to. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] On status data and summaries
Andrew Sullivan wrote: On Wed, Oct 11, 2006 at 06:26:50PM -0400, Bruce Momjian wrote: Funny, sounds like what I usually do. I welcome the assistance. Well, yes, that was my impression too. The complaint in the thread that started all this, as I understood it, was that there were big, hairy features that tended to have long discussions about them, and very few people among even the committers seemed to have a clear idea of exactly where things stood at the end of coding. Yep. I think Tom and I have a clear picture, but we aren't make it visible enough, I guess. One idea I had was to either create a web page or add to the top of the TODO items that are currently being worked on. But I take Jim Nasby's point, that the request for monitoring isn't going to come. How about an alternative: _you_ delegate threads/features/whatever to me to watch? Would that help? (I don't care how we do it, so long as it would be helpful and so long as it's wanted.) I do think we need a structure for this to be valuable. We can perhaps use a wiki to track open development items, with some status, like I did for the open items list for 8.2. I usually only do that during feature freeze, but could expand it and open it up for others to edit. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] On status data and summaries
On Thu, Oct 12, 2006 at 10:20:43AM -0400, Bruce Momjian wrote: use a wiki to track open development items, with some status, like I did for the open items list for 8.2. I usually only do that during feature freeze, but could expand it and open it up for others to edit. So do I understand this as a suggestion to pick some threads, keep track of them, but otherwise shut up until feature freeze? That's ok with me, if that's what helps; but I was under the impression from the meta-discussion last time that people didn't think that was working. Anyone? A -- Andrew Sullivan | [EMAIL PROTECTED] If they don't do anything, we don't need their acronym. --Josh Hamilton, on the US FEMA ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] On status data and summaries
On Thu, Oct 12, 2006 at 01:53:27PM -0400, Andrew Sullivan wrote: On Thu, Oct 12, 2006 at 10:20:43AM -0400, Bruce Momjian wrote: use a wiki to track open development items, with some status, like I did for the open items list for 8.2. I usually only do that during feature freeze, but could expand it and open it up for others to edit. So do I understand this as a suggestion to pick some threads, keep track of them, but otherwise shut up until feature freeze? That's ok with me, if that's what helps; but I was under the impression from the meta-discussion last time that people didn't think that was working. Anyone? If the ball gets dropped on something we want to know well before feature-freeze. Something that might be useful would be to send out a monthly status report of all active development. That'd be pretty easy to do if there was a wiki with all the info available.. the trick would just be to *ahem* nudge people to update the status of what they're working on once a month. -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] On status data and summaries
On Thu, Oct 12, 2006 at 01:56:37PM -0500, Jim C. Nasby wrote: *ahem* nudge people to update the status of what they're working on once a month. Well, though, remember that the point of this was supposed to be to make things easier for the developers, who are already spending (it would seem) too many cycles keeping on top of this. Or maybe I just misunderstood what the problem was people were having. A -- Andrew Sullivan | [EMAIL PROTECTED] Users never remark, Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath. --Damien Katz ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] On status data and summaries
Andrew Sullivan wrote: On Thu, Oct 12, 2006 at 01:56:37PM -0500, Jim C. Nasby wrote: *ahem* nudge people to update the status of what they're working on once a month. Well, though, remember that the point of this was supposed to be to make things easier for the developers, who are already spending (it would seem) too many cycles keeping on top of this. Or maybe I just misunderstood what the problem was people were having. No, my point was that right now I only do it during feature freeze, so we know what has to happen to get to beta (and that seems to work well). What I think people wanted was something like that, but maintained during the development cycle, so they would know what features our being worked on, and by whom. One great thing about the list I maintain is that it is a flat text file, so I can update it in seconds. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] On status data and summaries
Hello, In a possible moment of insanity, in http://archives.postgresql.org/pgsql-hackers/2006-09/msg00579.php I volunteered to try to help solve a problem Tom Lane noted: The hard part of this problem is finding a convenient way to capture status data out of the community's conversations. I observed that companies who do this well actually employ people to do that sort of thing, and that this might be a way for code morons like yours truly to make a contribution to development. I've been struggling since then, trying to figure out where to start. There are a _lot_ of discussions on -hackers, and many of them are blind alleys. Moreover, I can't summarise everything, I don't think, and still make any of those summaries sufficiently detailed to allow them to be useful. So I have a proposal. I was thinking of tracking 3 or 4 such discussions in the next release cycle, as a kind of proof of concept. I'm willing to do that, but I'd need guidance from those who are trying to produce a complicated feature, telling me that they need the support. Therefore, if someone involved in some such discussion pokes me saying, Follow this thread, please, I'll follow the thread in question (as well as follow-up discussions that come of it), and produce regular (weekly?) summaries of what I take to be the state of the collective mind, until such time as the code supporting the feature is checked in and agreed to. Then, at release time, the developers can evaluate whether the tracking produced few surprises at the end (and, perhaps, less thrash), or whether the experiment did not provide any benefit. If it does, we can see whether we can make this sort of thing scale by adding some additional volunteers to do a similar job in future. Does that seem worth doing? A -- Andrew Sullivan | [EMAIL PROTECTED] The year's penultimate month is not in truth a good way of saying November. --H.W. Fowler ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] On status data and summaries
On Wed, Oct 11, 2006 at 04:27:41PM -0400, Andrew Sullivan wrote: Hello, In a possible moment of insanity, in http://archives.postgresql.org/pgsql-hackers/2006-09/msg00579.php I volunteered to try to help solve a problem Tom Lane noted: The hard part of this problem is finding a convenient way to capture status data out of the community's conversations. I observed that companies who do this well actually employ people to do that sort of thing, and that this might be a way for code morons like yours truly to make a contribution to development. I've been struggling since then, trying to figure out where to start. There are a _lot_ of discussions on -hackers, and many of them are blind alleys. Moreover, I can't summarise everything, I don't think, and still make any of those summaries sufficiently detailed to allow them to be useful. So I have a proposal. I was thinking of tracking 3 or 4 such discussions in the next release cycle, as a kind of proof of concept. I'm willing to do that, but I'd need guidance from those who are trying to produce a complicated feature, telling me that they need the support. Therefore, if someone involved in some such discussion pokes me saying, Follow this thread, please, I'll follow the thread in question (as well as follow-up discussions that come of it), and produce regular (weekly?) summaries of what I take to be the state of the collective mind, until such time as the code supporting the feature is checked in and agreed to. Then, at release time, the developers can evaluate whether the tracking produced few surprises at the end (and, perhaps, less thrash), or whether the experiment did not provide any benefit. If it does, we can see whether we can make this sort of thing scale by adding some additional volunteers to do a similar job in future. Does that seem worth doing? ISTM that it would be important to do that on threads/ideas that end up getting 'lost', which means you'll never get a cry for help. Though looking out for controversial threads might work... -- Jim Nasby[EMAIL PROTECTED] EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] On status data and summaries
Funny, sounds like what I usually do. I welcome the assistance. --- Andrew Sullivan wrote: Hello, In a possible moment of insanity, in http://archives.postgresql.org/pgsql-hackers/2006-09/msg00579.php I volunteered to try to help solve a problem Tom Lane noted: The hard part of this problem is finding a convenient way to capture status data out of the community's conversations. I observed that companies who do this well actually employ people to do that sort of thing, and that this might be a way for code morons like yours truly to make a contribution to development. I've been struggling since then, trying to figure out where to start. There are a _lot_ of discussions on -hackers, and many of them are blind alleys. Moreover, I can't summarise everything, I don't think, and still make any of those summaries sufficiently detailed to allow them to be useful. So I have a proposal. I was thinking of tracking 3 or 4 such discussions in the next release cycle, as a kind of proof of concept. I'm willing to do that, but I'd need guidance from those who are trying to produce a complicated feature, telling me that they need the support. Therefore, if someone involved in some such discussion pokes me saying, Follow this thread, please, I'll follow the thread in question (as well as follow-up discussions that come of it), and produce regular (weekly?) summaries of what I take to be the state of the collective mind, until such time as the code supporting the feature is checked in and agreed to. Then, at release time, the developers can evaluate whether the tracking produced few surprises at the end (and, perhaps, less thrash), or whether the experiment did not provide any benefit. If it does, we can see whether we can make this sort of thing scale by adding some additional volunteers to do a similar job in future. Does that seem worth doing? A -- Andrew Sullivan | [EMAIL PROTECTED] The year's penultimate month is not in truth a good way of saying November. --H.W. Fowler ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
