Re: [HACKERS] Commit fest queue
Peter Eisentraut wrote: Am Dienstag, 15. April 2008 schrieb Zdenek Kotala: JavaDB and Firebird community use Jira Jira had already been rejected many years ago because it is not open source. Jira is also tremendously slow. Not a good system when an individual has to move quickly through a lot of reports. -Bryce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut napsal(a): Bruce Momjian wrote: That is a nice list, but are these used for bug tracking or patch tracking? In my experience, these two concepts become mostly the same. Just one is classified normal or critical and the the other is tagged wishlist and patch or attachment or something like that. JavaDB and Firebird community use Jira which is similar to Bugzilla. At least JavaDB also uses jira as a patch tracking. Developer adds patch as a attachment and patch name contains version name. Jira also has email interface which is able process also email communication. IIRC, only new bug/devel project has to be created on web interface. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Dienstag, 15. April 2008 schrieb Zdenek Kotala: JavaDB and Firebird community use Jira Jira had already been rejected many years ago because it is not open source. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut napsal(a): Am Dienstag, 15. April 2008 schrieb Zdenek Kotala: JavaDB and Firebird community use Jira Jira had already been rejected many years ago because it is not open source. Yeah, I know, main point was that it is similar to bugzila. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
All, BTW, the lead developer for ReviewBoard stopped by the PostgreSQL booth at LUGRadio this weekend. He was interested in the possibility of us using ReviewBoard, but not very interested in adding an e-mail interface to the software. -- Josh Berkus PostgreSQL @ Sun San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom, All: Well, I can provide an easy example: my first patch [1]. A second one would be Meredith's original QBE patch. While we wouldn't have ever included it in the core code, it would have been nice if she'd gotten a reply explaining why. More importantly, we *think* we haven't missed any patches ... but we can't *know* because we have no way to systematically search them. -- Josh Berkus PostgreSQL @ Sun San Francisco -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
I'm just an observer here, but I thought I'd present an idea. Feel free to
tell me I'm nuts if you don't like it.
It seems to me that there are two main concerns in this area on discussion:
1. How to create a list of patches/review items/etc without adding a
significant amount of noise to this list of patches/review items/etc.
From the discussion so far, it seems obvious that this part needs to be done
manually. Any automated system would not be smart enough to accurately pick
the right messages. It would either require the user to remove many non-list
items or would require the user to manually enter items.
2. How to make this newly generated list available and easy to work with for
those wishing to review. This method would need to (a) remain up to date,
(b) easily modified or rearranged, (c) has a significant amount of
information about the patch (with attachments), and (d) make sure comments
or changes to the item's status are sent back to the mailing list.
This last step is proving most difficult. I'll quickly outline a few of the
approaches and then present what I think might be what is needed.
The original solution had Bruce generating the list by working through his
mailbox and marking down the important e-mails. I suspect that less than 50%
of these actually ended up on his list. (please correct me if I'm wrong)
This was awkward for everyone else because there was very little visibility
of this list, so it was difficult for others to see what they could help
with. (concern #2)
The next, and current, solution involves someone saving the list they
generate to a wiki page. This adds work for that person (Bruce, I think) to
put it up in a wiki-style format, but does improve visibility of the list.
It ends up being a bit more work, but allows more than one person to help,
thereby speeding up the process. It's still not perfect, as updating is
manual (2a), links back to messages don't always have enough info (2c) and
comments aren't sent back to the list (2d). That being said - it is a big
improvement as visibility is much better.
The third proposed idea is to use some sort of tracker. Ideas proposed were
to (*) add everything from the mailing list to the tracker and close noise
items manually or (**) manually add the specific items of interest. These
two approaches have concerns with causing the data to be in yet another
location **, with missing patches in the process **, or with causing a
massive amount of maintenance work *.
Proposed Idea
It sounds like you need an e-mail controlled list. For example, setup a
filter that would create a tracker entry in response to a specific
keyword/keyphrase in an e-mail. The tracker entry could then be modified
entirely through a set of e-mailed commands.
For example, a tracker could be setup that would create a *hidden* tracker
item for each e-mail thread, but only un-hide the tracker item when an
e-mail in the thread contains tr:add or other such suitable command. From
then on, the tracker item would continue to gather e-mail and updates as
normal. Those wishing to use the web based interface would be free to do so.
Any changes {comments,status updates,attachments} would be sent back to the
e-mail thread.
This would allow the user to easily bring up a list of open patches, or
whatever other list they might want.
There would, of course, need to be a few additional commands accepted via
e-mail, such as commands to change the status, mark tracker items as the
same, and mark tracker items as addressed, or mark items as related. Also,
there should be some limits as to who (e-mail address) is allowed to modify
the tracker items.
Let's see how such a system addressed the 2 concerns listed at the start of
this mail.
1. Items would not be automatically added to the tracker (at least not
visibly), so noise would not be a problem. It would still require someone to
fire off an e-mail to add (un-hide) an e-mail thread in the tracker. This
does not increase the work required in creating the list, so things are good
here. Such an e-mail could also include Bruce's usual 'patch has been added
to the list' message, so this would be very visible and easily trackable.
2a. The tracker would continue to process new messages from the list, so it
would not fall out of date. (unless a new e-mail thread was started - but
this is no worse than you have today)
2b. The list could be easily modified by a large number of people via e-mail
or through the web interface (while keeping the e-mail list informed).
2c. The tracker items added would have the entire thread history all in one
spot, so it is easy to review.
2d. The tracker would send comments (not just comment notifications) back to
the list so information would not be missing from the e-mail archives.
So, that's the idea. Thoughts? (Or dare I ask!)
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 23:26:28 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: And then anybody asking a question about the status of something gives you a pedestal to show how nicely your tracker works. If you think that is what I am after you obviously have no idea who are you replying to. I suggest you take a step back and take a teaspoon of reality. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit signature.asc Description: PGP signature
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 23:23:20 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: Brendan Jurd wrote: I'm not saying Bruce is doing a bad job, far from it. I'm saying the job is impossible. I just wanted to correct the apparent impression that patches don't get ignored here. Patches get ignored. The difference between us and Apache is we pretend it doesn't happen and don't suggest to submitters what action to take when it does. Which puts Apache ahead of us IMO. The apache group seems to say the patches are indeed ignored, rather then just delayed --- for us, every patch does get a reply, however delayed. Bruce, I think that this comes back to the perception versus reality discussion you and I have had on more than one occasion :). You are correct that we always, eventually reply but, until we do (especially when it takes a long time) it appears as if people are being ignored. I think a FAQ entry may actually be appropriate in this case. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit signature.asc Description: PGP signature
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 23:23:20 -0400 (EDT) Bruce Momjian [EMAIL PROTECTED] wrote: Brendan Jurd wrote: I'm not saying Bruce is doing a bad job, far from it. I'm saying the job is impossible. I just wanted to correct the apparent impression that patches don't get ignored here. Patches get ignored. The difference between us and Apache is we pretend it doesn't happen and don't suggest to submitters what action to take when it does. Which puts Apache ahead of us IMO. The apache group seems to say the patches are indeed ignored, rather then just delayed --- for us, every patch does get a reply, however delayed. Bruce, I think that this comes back to the perception versus reality discussion you and I have had on more than one occasion :). You are correct that we always, eventually reply but, until we do (especially when it takes a long time) it appears as if people are being ignored. I will continue to claim that no, we don't always do that. The vast majority of the time we do, but there is no way that we can claim to respond to them all. No, I cannot point you to an example where this has happened. I *know* it has happened, because I do recall it, but I don't recall the specific case. But more important, with the say things are set up now, there is no way we can prove that we *do* respond to them all. I'm not saying we don't respond to *enough* of them. We're close enough to all that I think that part is ok (though that still comes back to the inability for the outside party to know if something is missed or just delayed), but we can't honestly claim 100%. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Fri, Apr 11, 2008 at 1:32 PM, Magnus Hagander [EMAIL PROTECTED] wrote: The apache group seems to say the patches are indeed ignored, rather then just delayed --- for us, every patch does get a reply, however delayed. Bruce, I think that this comes back to the perception versus reality discussion you and I have had on more than one occasion :). You are correct that we always, eventually reply but, until we do (especially when it takes a long time) it appears as if people are being ignored. I will continue to claim that no, we don't always do that. The vast majority of the time we do, but there is no way that we can claim to respond to them all. No, I cannot point you to an example where this has happened. Well, I can provide an easy example: my first patch [1]. We hashed out the design on -hackers as contributors are encouraged to do, and I submitted my first patch to -patches. It included a bunch of first-time-contributor questions that I had about the proper pgsql way to do things. It got zero responses. It was as if I had dropped it into a black hole. Eventually I re-submitted it after 8.2 was released, and some time after that I got a your-patch-has-been-saved email. I have no idea how often that happens, perhaps I'm an exception, but it was incredibly discouraging. However I see this as being a side-issue - the problem is knowing the current status of patches, not the occasional patch that drops through. And if I as a submitter can stick a patch up on a wiki or tracker and then email the list for feedback that's probably good enough, and we could probably do away with -patches altogether, dealing with the fragmentation issue. That alone would reassure a contributor that their patch wouldn't get lost, though it wouldn't guarantee that anyone would look at it. The reason a tracker is better imo than a wiki is that a wiki still needs someone to maintain an index page (or multiple index pages for different queues), so there's still an opportunity for something to fall through. Or are we suggesting that a first-time contributor should be editing a patch queue index page on the wiki? Trackers don't have these issues though - managing lists like this is what they were born to do. Cheers Tom [1] http://archives.postgresql.org/pgsql-patches/2006-09/msg0.php -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Dunstan [EMAIL PROTECTED] writes: The reason a tracker is better imo than a wiki is that a wiki still needs someone to maintain an index page (or multiple index pages for different queues), so there's still an opportunity for something to fall through. For the umpteenth time bug trackers *still* require someone to maintain the list. It's more structured which is great if it matches the structure you want, but it still requires someone to go open bugs when a bug is reported by email, close bogus bugs or bugs fixed via collateral damage, update bugs when discussions happen on the list about them, etc. Imagining that bug trackers are all automatic and don't require any work or impose any restrictions is missing the whole point. The whole benefit they provide is precisely that they make that process systematic. They don't do it for you. I've seen no discussion about the structure the various bug trackers use and which would match better with our processes. *That* would be the only useful discussion to be having. What attributes do you think patch submissions have, what is the workflow which sets which attributes at which time, who is involved in which step of this workflow? Etc. Proposing specific tools without a consensus on what that process is putting the cart before the horse. You pick the tools to fit what you want to do. We haven't decided what we want to do yet. Personally I don't think we *know* what we want to do and that's why the wiki is a good interim tool. We'll see what info we need there and who needs to fill it in and find out what tool will fit our needs. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Fri, 11 Apr 2008 15:44:43 +0100 Gregory Stark [EMAIL PROTECTED] wrote: Proposing specific tools without a consensus on what that process is putting the cart before the horse. You pick the tools to fit what you want to do. We haven't decided what we want to do yet. Personally I don't think we *know* what we want to do and that's why the wiki is a good interim tool. We'll see what info we need there and who needs to fill it in and find out what tool will fit our needs. What I find interesting about this email is that it is just as useless as you claim Tom's is. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark escribió: Personally I don't think we *know* what we want to do and that's why the wiki is a good interim tool. We'll see what info we need there and who needs to fill it in and find out what tool will fit our needs. +1. Let's learn what we need first, and find an appropriate tool to let us do it more easily later. We just had our first commitfest, and the Wiki was already a change. Let's see what we can learn from it. For example it was suggested that we need templates to format the patch entries. What fields would have been useful? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark [EMAIL PROTECTED] writes: Personally I don't think we *know* what we want to do and that's why the wiki is a good interim tool. Yup, that is *exactly* the point. A wiki page is a zero-setup-cost, flexible way of experimenting with tracking commit-fest issues. A year from now, we might have enough experience to decide that some more-rigidly-structured tool will do what we need, but we don't have it today. We spent enough time fighting the limitations of Bruce's mhonarc page that we ought to be wary of adopting some other tool that wants you to do things its way. Perhaps an example will help make the point. Throughout this past fest I was desperately wishing for a way to group and label related issues --- we had a pile of items focused around index AM API questions, and another pile focused around mapping problems (FSM/DSM/Visibility map/etc), and being able to put those together would have made it a lot clearer what needed to be looked at together with what else. On a wiki page it'd have been no trouble at all to create ad-hoc sub-headings and sort the individual items into whatever grouping and ordering made sense (in fact, Alvaro did some of that on his own). It was basically impossible to do any such thing with Bruce's mhonarc page, though he did kluge up some ways to partially address the issue by merging threads. The bug trackers I've dealt with haven't got much flexibility in this respect either --- the sorts of global views you can get are entirely determined by the tool. I'm fairly certain that a tracker designed around the assumption that different entries are essentially independent isn't going to be very helpful. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Personally I don't think we *know* what we want to do and that's why the wiki is a good interim tool. Yup, that is *exactly* the point. A wiki page is a zero-setup-cost, flexible way of experimenting with tracking commit-fest issues. A year from now, we might have enough experience to decide that some more-rigidly-structured tool will do what we need, but we don't have it today. We spent enough time fighting the limitations of Bruce's mhonarc page that we ought to be wary of adopting some other tool that wants you to do things its way. Perhaps an example will help make the point. Throughout this past fest I was desperately wishing for a way to group and label related issues --- we had a pile of items focused around index AM API questions, and another pile focused around mapping problems (FSM/DSM/Visibility map/etc), and being able to put those together would have made it a lot clearer what needed to be looked at together with what else. On a wiki page it'd have been no trouble at all to create ad-hoc sub-headings and sort the individual items into whatever grouping and I feel subgroups is something we are going to need from a bug or patch tracker. The TODO list uses subgroups. I think a flat bug/patch list is harder to understand. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In the projects I'm involved in, tends to be for used for both purposes ... one central location for everything ... Yea, good point. I think our big question is what justification do we have for doing things different from everyone else? I think it is fine for us to be different, but we should know the reason why. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
(I've already said that I think the wiki is a great step forward, FWIW, and I'm not in any way suggesting that we should just drop it and pick my favorite issue tracker or anything. However, for those interested in discussion about theoretical benefits and cons of the different systems...) On Fri, Apr 11, 2008 at 8:14 PM, Gregory Stark [EMAIL PROTECTED] wrote: For the umpteenth time bug trackers *still* require someone to maintain the list. It's more structured which is great if it matches the structure you want, but it still requires someone to go open bugs when a bug is reported by email, close bogus bugs or bugs fixed via collateral damage, update bugs when discussions happen on the list about them, etc. Perhaps I wasn't clear. I was describing the specific case where a patch submitter would be required by project policy to submit a patch to a tracker of some kind before discussing it on the list. So there wouldn't be much of an opportunity for those to fall through. And owners of a particular patch would be expected to keep them up to date re discussions. I wasn't discussing emailed bug reports. The problem with a tracker is that it will give you a list of every damn thing that people have put in there, and the data in there can stagnate. The problem with manually maintained lists is that stuff might not get on there at all. What I and at least one other person have tried to say is that the problem of dead issues needing to be closed is a much easier problem to deal with than the problem of an issue not being there at all. Heck, *I* could trawl a tracker and email authors of seemingly dead patches. But there's no way I could maintain a patch list manually without following each and every discussion. I've seen no discussion about the structure the various bug trackers use and which would match better with our processes. *That* would be the only useful discussion to be having. What attributes do you think patch submissions have, what is the workflow which sets which attributes at which time, who is involved in which step of this workflow? Etc. Well, I do recall reading at least one thread (not terribly recently) discussing people's favourite trackers, but IIRC it turned into something similar to what happens when we discuss CVS replacements :) Proposing specific tools without a consensus on what that process is putting the cart before the horse. You pick the tools to fit what you want to do. We haven't decided what we want to do yet. This is true. But your processes get shaped by your tools, too. Our processes might be shaped by what we've got, and so continue forever. There should be some awareness of what else is out there. An example of this is the way code flows around the Linux kernel. I'm not for a minute advocating their general structure, but git seems a far better tool than the combination of CVS and emailing patches. Patch announcements aren't always here's the patch as much as please pull from over here. Their tool support seems rather better than ours. And it's changed the way they work. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Lane [EMAIL PROTECTED] writes: The bug trackers I've dealt with haven't got much flexibility in this respect either --- the sorts of global views you can get are entirely determined by the tool. I'm fairly certain that a tracker designed around the assumption that different entries are essentially independent isn't going to be very helpful. The bug trackers I've dealt with did have some way to merge bugs, though obviously nothing as flexible as a wiki page. Debbugs allows you to merge two bugs in which case the two bug#s are synonyms for each other. All messages related to either bug appear in one list and there's only one set of status bits for both bugs. Bugzilla allows you to mark bugs as duplicates but basically this amounts to marking one bug as a duplicate and closing it. Both bugs get notes indicating the other bug# but you have to click on a link to see the info attached to the closed duplicates. I've noticed Mozilla creates a lot of tracking bugs for classes of problems. I think this is related to your observation. The tracking bug just lists all the other related bugs which fall under that topic. I'm sure trac has a solution for this, I'm curious to hear how it works. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost, flexible way of experimenting with tracking commit-fest issues. A year from now, we might have enough experience to decide that some more-rigidly-structured tool will do what we need, but we don't have it today. We spent enough time fighting the limitations of Bruce's mhonarc page that we ought to be wary of adopting some other tool that wants you to do things its way. In case you don't recognize my name/email address I am just someone who has been lurking on hackers for several years now. I have been following this thread closely and I thought it might be useful for someone to try to summarize what it seems like people need so everyone can see if they are on the same page. After stating each problem I will also summarize proposed solutions and introduce a few of my own, just to see what people think. Also I have been a web developer for the 7 years so I may be able to help out with this, as long as the time span is sufficiently long. Please feel free to correct anything below (as if I have to say that). Remember I am not trying to push any idea here, I am just trying to summarize everyone else's ideas and humbly propose a few ideas that might help. It's clear that you want to keep the email list as the primary means of communication. So that obviously has to stay. The web archives should stay the primary means of referencing past discussion. Problem #1: The current archive system breaks threads across monthly boundaries. Solution 1A: Find other off the shelf software that does this better. Solution 1B: Write some custom software to do this. Can you set up hooks into the mail server so that a script could be run each time a new email is accepted? Given the full message headers and body, what is the algorithm for linking methods into threads? Given the right answers to those two questions and this might be a fairly simple task. Problem #2: When people are looking for something to do we need a list of all pending issues that can be easily searched. Ideally the maintenance of this list will be as low as possible. Solution 2: Create a custom tracker. The above email and others seem to indicate nothing off the shelf will do. Can a hook be set up into the mail server so that incoming emails can not only be read and indexed but also altered with a script? Each new thread from patches could automatically create a tracker item. At the bottom of each message a link could be added to the tracker item for that thread. Then going from email message (in your MUA or the web archives) to the tracker would be quick and easy. Each email from hackers could have a link at the bottom to create a tracker item for it. So patches threads get automatic tracker items. Hackers threads can be added manually. The tracker page for each message would include whatever metadata was needed. For instance: has this tracker item been processed yet? Is it a bug or a feature request or just a request for information or a fix to infrastructure? Is there a reviewer for the patch? Which fest does it belong to? Or any other metadata you might want to add to the item. Also on the page would be the thread that started the item. Initially it would show only subjects. Clicking on a subject will show the body of the message inline with the thread. Clicking it again will collapse it again. There will be a reply link for each message. If you reply via the web site it will simply send a message to the mail server just as it would if you had replies within your MUA. That way there is no difference between replying from within the tracker and replying from within your normal mail client. But you can still use either and the communication doesn't get scattered all over the place. There would also be an option to let you choose another tracker item to merge with the current one so that relevant threads can be aggregated into the same tracker item. At this point you could have a page that lists all unassigned tracker items so that someone looking for some work to do could quickly scan a short easy to read list and pick something. Problem #3: When a new patch creator posts a new patch they need feedback quickly so they know at least that they did the right thing and someone is aware of the patch. Solution 3: The tracker has a list of all new threads that haven't been looked at. Someone can then go through the list of unprocessed items and see if it has a patch. If it does he can flag that item as a patch submission and it will immediately show up on the list for patch reviewers to look through. It can also be assigned right there to a specific fest but will default to the soonest one. Once it is flagged an email will automatically go out telling them their patch is pending review. Problem #4: Patches may or may not, on rare
Re: [HACKERS] Commit fest queue
On Sat, Apr 12, 2008 at 3:13 AM, Gregory Stark [EMAIL PROTECTED] wrote: Tom Lane [EMAIL PROTECTED] writes: The bug trackers I've dealt with haven't got much flexibility in this respect either --- the sorts of global views you can get are entirely determined by the tool. I'm fairly certain that a tracker designed around the assumption that different entries are essentially independent isn't going to be very helpful. I'm sure trac has a solution for this, I'm curious to hear how it works. In Trac, if I just want to loosely associate several tickets together I'd use *keywords*, e.g., put index am in the keywords list for several tickets, and then they'll show up prominently when I search for those terms. If I want something more structured I'd use a *milestone*. I'd create an Index AM milestone and attach all the relevant tickets to it. Then I can easily pull up a report of all open tickets on the Index AM milestone (or all closed tickets, or all tickets regardless of status, or all tickets assigned to me, or all tickets not assigned to anyone yet, or ...) Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Yup, that is *exactly* the point. A wiki page is a zero-setup-cost, flexible way of experimenting with tracking commit-fest issues. A year from now, we might have enough experience to decide that some more-rigidly-structured tool will do what we need, but we don't have it today. We spent enough time fighting the limitations of Bruce's mhonarc page that we ought to be wary of adopting some other tool that wants you to do things its way. In case you don't recognize my name/email address I am just someone who has been lurking on hackers for several years now. I have been following this thread closely and I thought it might be useful for someone to try to summarize what it seems like people need so everyone can see if they are on the same page. After stating each problem I will also summarize proposed solutions and introduce a few of my own, just to see what people think. Also I have been a web developer for the 7 years so I may be able to help out with this, as long as the time span is sufficiently long. Please feel free to correct anything below (as if I have to say that). Remember I am not trying to push any idea here, I am just trying to summarize everyone else's ideas and humbly propose a few ideas that might help. It's clear that you want to keep the email list as the primary means of communication. So that obviously has to stay. The web archives should stay the primary means of referencing past discussion. Problem #1: The current archive system breaks threads across monthly boundaries. Solution 1A: Find other off the shelf software that does this better. Solution 1B: Write some custom software to do this. Can you set up hooks into the mail server so that a script could be run each time a new email is accepted? Given the full message headers and body, what is the algorithm for linking methods into threads? Given the right answers to those two questions and this might be a fairly simple task. Problem #2: When people are looking for something to do we need a list of all pending issues that can be easily searched. Ideally the maintenance of this list will be as low as possible. Solution 2: Create a custom tracker. The above email and others seem to indicate nothing off the shelf will do. Can a hook be set up into the mail server so that incoming emails can not only be read and indexed but also altered with a script? Each new thread from patches could automatically create a tracker item. At the bottom of each message a link could be added to the tracker item for that thread. Then going from email message (in your MUA or the web archives) to the tracker would be quick and easy. Each email from hackers could have a link at the bottom to create a tracker item for it. So patches threads get automatic tracker items. Hackers threads can be added manually. The tracker page for each message would include whatever metadata was needed. For instance: has this tracker item been processed yet? Is it a bug or a feature request or just a request for information or a fix to infrastructure? Is there a reviewer for the patch? Which fest does it belong to? Or any other metadata you might want to add to the item. Also on the page would be the thread that started the item. Initially it would show only subjects. Clicking on a subject will show the body of the message inline with the thread. Clicking it again will collapse it again. There will be a reply link for each message. If you reply via the web site it will simply send a message to the mail server just as it would if you had replies within your MUA. That way there is no difference between replying from within the tracker and replying from within your normal mail client. But you can still use either and the communication doesn't get scattered all over the place. There would also be an option to let you choose another tracker item to merge with the current one so that relevant threads can be aggregated into the same tracker item. At this point you could have a page that lists all unassigned tracker items so that someone looking for some work to do could quickly scan a short easy to read list and pick something. Problem #3: When a new patch creator posts a new patch they need feedback quickly so they know at least that they did the right thing and someone is aware of the patch. Solution 3: The tracker has a list of all new threads that haven't been looked at. Someone can then go through the list of unprocessed items and see if it has a patch. If it does he can flag that item as a patch submission and it will immediately show up on the list for patch reviewers to look through. It can also be assigned right there to a specific fest but will default to the soonest one. Once it is flagged an email will automatically go out telling them their patch is pending review. Problem #4: Patches may or may not, on rare
Re: [HACKERS] Commit fest queue
On Apr 11, 2008, at 9:30 AM, Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Personally I don't think we *know* what we want to do and that's why the wiki is a good interim tool. Yup, that is *exactly* the point. A wiki page is a zero-setup-cost, flexible way of experimenting with tracking commit-fest issues. A year from now, we might have enough experience to decide that some more-rigidly-structured tool will do what we need, but we don't have it today. We spent enough time fighting the limitations of Bruce's mhonarc page that we ought to be wary of adopting some other tool that wants you to do things its way. Perhaps an example will help make the point. Throughout this past fest I was desperately wishing for a way to group and label related issues --- we had a pile of items focused around index AM API questions, and another pile focused around mapping problems (FSM/DSM/Visibility map/etc), and being able to put those together would have made it a lot clearer what needed to be looked at together with what else. On a wiki page it'd have been no trouble at all to create ad-hoc sub-headings and sort the individual items into whatever grouping and ordering made sense (in fact, Alvaro did some of that on his own). It was basically impossible to do any such thing with Bruce's mhonarc page, though he did kluge up some ways to partially address the issue by merging threads. The bug trackers I've dealt with haven't got much flexibility in this respect either --- the sorts of global views you can get are entirely determined by the tool. I'm fairly certain that a tracker designed around the assumption that different entries are essentially independent isn't going to be very helpful. In case you don't recognize my name/email address I am just someone who has been lurking on hackers for several years now. I have been following this thread closely and I thought it might be useful for someone to try to summarize what it seems like people need so everyone can see if they are on the same page. After stating each problem I will also summarize proposed solutions and introduce a few of my own, just to see what people think. Also I have been a web developer for the 7 years so I may be able to help out with this, as long as the time span is sufficiently long. Please feel free to correct anything below (as if I have to say that). Remember I am not trying to push any idea here, I am just trying to summarize everyone else's ideas and humbly propose a few ideas that might help. It's clear that you want to keep the email list as the primary means of communication. So that obviously has to stay. The web archives should stay the primary means of referencing past discussion. Problem #1: The current archive system breaks threads across monthly boundaries. Solution 1A: Find other off the shelf software that does this better. Solution 1B: Write some custom software to do this. Can you set up hooks into the mail server so that a script could be run each time a new email is accepted? Given the full message headers and body, what is the algorithm for linking methods into threads? Given the right answers to those two questions and this might be a fairly simple task. Problem #2: When people are looking for something to do we need a list of all pending issues that can be easily searched. Ideally the maintenance of this list will be as low as possible. Solution 2: Create a custom tracker. The above email and others seem to indicate nothing off the shelf will do. Can a hook be set up into the mail server so that incoming emails can not only be read and indexed but also altered with a script? Each new thread from patches could automatically create a tracker item. At the bottom of each message a link could be added to the tracker item for that thread. Then going from email message (in your MUA or the web archives) to the tracker would be quick and easy. Each email from hackers could have a link at the bottom to create a tracker item for it. So patches threads get automatic tracker items. Hackers threads can be added manually. The tracker page for each message would include whatever metadata was needed. For instance: has this tracker item been processed yet? Is it a bug or a feature request or just a request for information or a fix to infrastructure? Is there a reviewer for the patch? Which fest does it belong to? Or any other metadata you might want to add to the item. Also on the page would be the thread that started the item. Initially it would show only subjects. Clicking on a subject will show the body of the message inline with the thread. Clicking it again will collapse it again. There will be a reply link for each message. If you reply via the web site it will simply send a message to the mail server just as it would if you had replies within your MUA. That way there is no difference between
Re: [HACKERS] Commit fest queue
Brendan Jurd [EMAIL PROTECTED] writes: In Trac, if I just want to loosely associate several tickets together I'd use *keywords*, e.g., put index am in the keywords list for several tickets, and then they'll show up prominently when I search for those terms. As an aside, you've reminded me about another thing that bothers me about Bugzilla and RT. In both cases they seem to put a lot of focus around the idea of searching bugs. I don't really get why. Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bugs that nobody ever sees let alone updates, but surely that isn't the goal. In fact it seems like having the UI centred around searching pretty much dooms you to that fate. Of course things will fall through the cracks if your main UI only presents the things you decide to go look for. I would think an interface which presents you with *all* unclosed bugs by default, perhaps organized in some way (keywords, milestones, etc) would be more conducive to getting attention to everything. I'm sure you can do something like that in Bugzilla and RT but it sure doesn't seem to be the way it's used in practice. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Fri, 11 Apr 2008 18:46:18 +0100 Gregory Stark [EMAIL PROTECTED] wrote: I would think an interface which presents you with *all* unclosed bugs by default, perhaps organized in some way (keywords, milestones, etc) would be more conducive to getting attention to everything. I'm sure you can do something like that in Bugzilla and RT but it sure doesn't seem to be the way it's used in practice. You can in RT (although I am not suggesting we use RT). You can also do it in trac. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Brendan Jurd [EMAIL PROTECTED] writes: In Trac, if I just want to loosely associate several tickets together I'd use *keywords*, e.g., put index am in the keywords list for several tickets, and then they'll show up prominently when I search for those terms. Assuming you know what to search for, of course ... If I want something more structured I'd use a *milestone*. I'd create an Index AM milestone and attach all the relevant tickets to it. Then I can easily pull up a report of all open tickets on the Index AM milestone (or all closed tickets, or all tickets regardless of status, or all tickets assigned to me, or all tickets not assigned to anyone yet, or ...) Yeah, you can do all that in bugzilla too (Red Hat uses tracking bugs to such an extent that I think they outnumber the plain bugs :-(). It still pretty much sucks for what I want, which is to easily see an overview of what's in the commit-fest queue organized in some helpful fashion. In any case, this still sounds like forcing our problem to fit the tool. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark wrote: As an aside, you've reminded me about another thing that bothers me about Bugzilla and RT. In both cases they seem to put a lot of focus around the idea of searching bugs. I don't really get why. Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bugs that nobody ever sees let alone updates, but surely that isn't the goal. No, there are several perfectly good reasons. It seems unlikely that you have never actually used bugzilla in earnest or you would not have made this comment. First, there are reports that get marked not a bug. If somebody has found some behaviour that might be a bug, then being able to search for similar reports in the past and see the response is very valuable (and saves developers from having to give the same answer over and over) Second, the system is used to track features as well as things that are strictly bugs. So, for example, you can find the response to a previous feature request. A list of open feature requests in effect gives you a TODO list for nothing. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Fri, Apr 11, 2008 at 06:46:18PM +0100, Gregory Stark wrote: As an aside, you've reminded me about another thing that bothers me about Bugzilla and RT. In both cases they seem to put a lot of focus around the idea of searching bugs. I don't really get why. To be fair to RT, it's really designed as a general-purpose trouble-ticket system. If you've ever worked a help desk, you'll have no trouble knowing why searching is a valuable function. But yes, you can (with some pain, like everything else in RT) completely rejigger the access screens to eliminate this. A -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Apr 11, 2008, at 12:54 PM, Tom Lane wrote: Brendan Jurd [EMAIL PROTECTED] writes: In Trac, if I just want to loosely associate several tickets together I'd use *keywords*, e.g., put index am in the keywords list for several tickets, and then they'll show up prominently when I search for those terms. Assuming you know what to search for, of course ... If I want something more structured I'd use a *milestone*. I'd create an Index AM milestone and attach all the relevant tickets to it. Then I can easily pull up a report of all open tickets on the Index AM milestone (or all closed tickets, or all tickets regardless of status, or all tickets assigned to me, or all tickets not assigned to anyone yet, or ...) Yeah, you can do all that in bugzilla too (Red Hat uses tracking bugs to such an extent that I think they outnumber the plain bugs :-(). It still pretty much sucks for what I want, which is to easily see an overview of what's in the commit-fest queue organized in some helpful fashion. Mozilla's bugzilla uses milestones to track what release something is scheduled for... I'm thinking the same mechanism could be used for commitfests (and releases). -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Commit fest queue
We use RT here for our trouble ticket system and the dashboard can easily be configured to display tickets based on any search criteria and you can have multiple views on the same screen. The search functionality can be viewed as the tool for configuring your views into the system, for whatever its purpose may be. It is easy to organize the views based on keywords, milestones, or anything else. It really is very flexible and its E-mail interface is very nice as well. Regards, Ken Marshall On Fri, Apr 11, 2008 at 06:46:18PM +0100, Gregory Stark wrote: Brendan Jurd [EMAIL PROTECTED] writes: In Trac, if I just want to loosely associate several tickets together I'd use *keywords*, e.g., put index am in the keywords list for several tickets, and then they'll show up prominently when I search for those terms. As an aside, you've reminded me about another thing that bothers me about Bugzilla and RT. In both cases they seem to put a lot of focus around the idea of searching bugs. I don't really get why. Maybe it makes sense if you plan to be like Mozilla and have 8-year-old bugs that nobody ever sees let alone updates, but surely that isn't the goal. In fact it seems like having the UI centred around searching pretty much dooms you to that fate. Of course things will fall through the cracks if your main UI only presents the things you decide to go look for. I would think an interface which presents you with *all* unclosed bugs by default, perhaps organized in some way (keywords, milestones, etc) would be more conducive to getting attention to everything. I'm sure you can do something like that in Bugzilla and RT but it sure doesn't seem to be the way it's used in practice. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark [EMAIL PROTECTED] wrote: As an aside, you've reminded me about another thing that bothers me about Bugzilla and RT. In both cases they seem to put a lot of focus around the idea of searching bugs. I don't really get why. Er, because pretty much everybody wants the ability to easily consult the project's development history? In a typical bugzilla scenario, the majority of users are going to be accessing the tracker either to file a bug or request a feature. Search must be front and centre for this to work effectively, because you want those users to search for similar bugs before creating a new one. Trac's UI is less focussed on search. The search box just sits up there in the upper right corner in case you want to use it. I would think an interface which presents you with *all* unclosed bugs by default, perhaps organized in some way (keywords, milestones, etc) would be more conducive to getting attention to everything. I'm sure you can do something like that in Bugzilla and RT but it sure doesn't seem to be the way it's used in practice. Yes, of course all reasonable trackers also have a way to pull up complete listings of open items. I think you've been thrown off the scent because bugzilla's primary UI is geared towards the submitter's usage pattern, not the reviewer's. It doesn't mean that the reviewer is left out in the cold. It does mean that, as a reviewer, you have to either place an extra click or two to bring up your favourite listing, or (!) make a bookmark. For example, in Trac you click on View Tickets and then Active Tickets. It's a two click operation. It's not like it's obfuscated. Cheers, BJ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008, Brendan Jurd wrote: [Automatic e-mail notification] is trivial to configure in a real tracker. Less so for a wiki page, but it could still be accomplished with the careful application of script-fu. Anyone who is interested can sign up for e-mail notification whenever a specific wiki page is modified right now, that's a standard MediaWiki feature. If you wanted you could even sign up a mailing list as the entity being notified. That's not exactly what you had in mind I think, but it's close enough to be useful for now. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Bruce Momjian wrote: Fine with me, but I was hoping someone would come up with an idea that would reduce what I need to do, like perhaps a new vacuum cleaner. ;- Bruce et al., If you need a reasonably (modestly?) intelligent person to put to work helping, I am more than willing to work with you on what needs to be done. I have absolutely no idea if this offer is realistically of any value to you. As a comparative Pg newbie but longtime DBA/developer, it's not easy to find an entry point into this aspect of the Pg project. So, if you're willing to put up with the initial hassle of telling someone how to help you out, here's a new vacuum cleaner. Or at least feather duster. Paul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Brendan Jurd [EMAIL PROTECTED] writes: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Much much better are the systems like debbugs where you get the actual ticket by email. And can respond by email. And basically never need to visit the web interface unless you want to see the summarized data. Personally I would consider any system without at least these attributes to be unusable: a) Never sends an email without the full content it's notifying you of b) Never sends an email which can't be replied to normally -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark wrote: Brendan Jurd [EMAIL PROTECTED] writes: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Much much better are the systems like debbugs where you get the actual ticket by email. And can respond by email. And basically never need to visit the web interface unless you want to see the summarized data. Personally I would consider any system without at least these attributes to be unusable: a) Never sends an email without the full content it's notifying you of b) Never sends an email which can't be replied to normally this is something that out bugzilla demo installation is actually capable of (ie it can be entirely driven by and automatically track mail discussions as long as the mail somehow contains a bugid or get's one assigned in the course of the discussion). Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark [EMAIL PROTECTED] wrote: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Yeah, it sucks, because people won't bother looking. It fails Tom's sniff test. (Although I can attest to having submitted a previously discussed patch to -patches and received *zero* feedback, even something like we're too busy getting 8.2 out, come back later). What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? Hi there, I just upload patch #12345 which implements TODO item n, can people please have a look? I've done x, y and z, not sure about p and q. Then discussion still happens on-list which is a much better discussion medium, and the patch has a proper status page which the author can keep up to date with the latest version etc etc. If we feel the need to link patch status pages to the email archive, there's no harm in asking that the original email contain the bug number in the subject or something like that. That's going towards a more structured approach than a wiki, but I don't personally see that as a bad thing. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. I presume you mean for -patches and not -hackers. Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, Apr 10, 2008 at 3:41 PM, Gregory Stark [EMAIL PROTECTED] wrote: What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? What's what we have today with the wiki. We don't need any special software to do that. It does require some patch queue maintainer(s) to make sure things get added or updated. Right, which is what a tracker gives you. A patch submitter can stick a patch up as WIP or whatever, and update it to ready-for-commit-review when they're ready, and it's easy to get a list of ready-to-review patches. If someone wants a patch to get reviewed in a commit fest, then it better have the latest version and an up-to-date status. I don't think getting submitters to follow the rules will be very hard - as someone pointed out it's trivial compared to the effort of writing a patch. The problem is more likely to be cleaning up old patches that people submit that never make it to prime time, but that's easier work for non-core people to help with. Anyway, I've said my piece and I don't want to discourage movement to a wiki - it seems a vast improvement in submitter-participation over the status quo. I just think there are even better tools for the job. Cheers Tom -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Dunstan wrote: On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark [EMAIL PROTECTED] wrote: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge Yeah, it sucks, because people won't bother looking. It fails Tom's sniff test. (Although I can attest to having submitted a previously discussed patch to -patches and received *zero* feedback, even something like we're too busy getting 8.2 out, come back later). What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? Hi there, I just upload patch #12345 which implements TODO item n, can people please have a look? I've done x, y and z, not sure about p and q. Then discussion still happens on-list which is a much better discussion medium, and the patch has a proper status page which the author can keep up to date with the latest version etc etc. well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: Tom Dunstan wrote: What's wrong with a patch submitter submitting a patch to a tracker, but then emailing the list for actual discussion? What's what we have today with the wiki. We don't need any special software to do that. It does require some patch queue maintainer(s) to make sure things get added or updated. well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This requires an AI which passes the turing test. How do you determine what patch is related to and how it affects the status of that patch? This is precisely the work Bruce was doing previously and it's a lot of work. This is precisely what we're asking people to do on the wiki now. Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Dunstan wrote: On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner [EMAIL PROTECTED] wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. I presume you mean for -patches and not -hackers. Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. well subscribe to both (so it can track discussions that move from -patches to -hackers) but only create tickets for stuff submitted to -patches. As for changing the status of a patch there will always need to be someone actually categorizing the patch - either by doing that in the tracker (or by adding an email command to one of the mails in the discussion or in the gui of whatever tool we use). The advantage would be that the information is fairly structured and most trackers have rather simply ways to condense the information down to a simple dashboard like thing (like what we have in the wiki) or provide an RSS feed or whatever. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake escribió: On Wed, 09 Apr 2008 23:01:30 -0300 Marc G. Fournier [EMAIL PROTECTED] wrote: I could see it with older submitters, who are used to just sending an email, but the new guys will go with whatever procedure is laid out for them *as long as* it is enforced ... Just as a note... email can be used as a submission procedure to a patch tracker. Yes, but it sucks, because either you create one for every email, or you have to give an explicit command to be captured by the system. I think the workflow over email is unstructured enough that there always needs to be a human to do some selective capturing of information. As soon as you get into things like creating templates which patch submitters are supposed to use, it's the about the same as having to go to the web interface to enter the patch. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Stefan Kaltenbrunner wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This is (more or less) what the Tracman system proposed by Josh Drake does -- and it's awful IMHO. Amusingly, it's also more or less the same thing that debbugs does, which IMHO is really good. The main difference (again IMHO) is that Tracman tries to stuff the info in Trac comments, so it has to forcefully extract things from the email with rather poor results; whereas debbugs uses the mbox itself as the definite storage. Note that neither are really subscribed to the lists; rather they are some sort of gatekeepers, which process the email *before* they get to the list. (Actually, AFAIK in debbugs there is no actual mail list -- it's all mainly about appropriate CC's.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Lane escribió: Obviously there are virtues on both sides of this, which is why I think we need both mechanisms. The simplest way to integrate them AFAICS is to use the tracker as an index on the email traffic. Agreed. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This is (more or less) what the Tracman system proposed by Josh Drake does -- and it's awful IMHO. Amusingly, it's also more or less the same thing that debbugs does, which IMHO is really good. The main difference (again IMHO) is that Tracman tries to stuff the info in Trac comments, so it has to forcefully extract things from the email with rather poor results; whereas debbugs uses the mbox itself as the definite storage. Note that neither are really subscribed to the lists; rather they are some sort of gatekeepers, which process the email *before* they get to the list. (Actually, AFAIK in debbugs there is no actual mail list -- it's all mainly about appropriate CC's.) The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. No tracker looks after itself. Everybody has their favorite tracker (editor, OS, SCM, ...) ... we can have endless fun debating them backwards and forwards and never reach a conclusion, just as we do fairly regularly. The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) (And yes, Trac sucks) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark wrote: Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. +1 -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Andrew Dunstan wrote: The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. I tested Stefan's installation a bit. The main conclusion I got from it was that the email interface was a late kludge. Even if it were improved to remove the bugs, the fact remains that the emails themselves are not the main storage. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) I haven't forgotten them :-) but from my PoV, the only important argument against debbugs is that the code is not readily available. The fact that it is tailored to Debian does not seem so much of a problem to me -- I'm sure we could easily lure it into doing our thing. IIRC Peter Eisentraut said he was going to talk to the guys in charge of debbugs at FOSDEM, or something like that. I wonder if it materialized, and whether something came out of that? -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Alvaro Herrera wrote: Andrew Dunstan wrote: The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. I tested Stefan's installation a bit. The main conclusion I got from it was that the email interface was a late kludge. Even if it were improved to remove the bugs, the fact remains that the emails themselves are not the main storage. True - but that might not actually be a problem as long as we have a way to correlate the comments there easily (and automatically) to the threads and the individual mails - and yes the emailinterface might need some work but well work will be required in one for or another anyway. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) I haven't forgotten them :-) but from my PoV, the only important argument against debbugs is that the code is not readily available. The fact that it is tailored to Debian does not seem so much of a problem to me -- I'm sure we could easily lure it into doing our thing. and keep maintaining it on our own forever ? IIRC Peter Eisentraut said he was going to talk to the guys in charge of debbugs at FOSDEM, or something like that. I wonder if it materialized, and whether something came out of that? fairly sure petere missed FOSDEM :-) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Andrew Dunstan wrote: Alvaro Herrera wrote: Stefan Kaltenbrunner wrote: well what about having the tracker being subscribed to the list and let it create a bug/patch/ticket id automatically for new mails - that way all stuff is automatically tracked ? - That way it can be categorized in the course of the following discussion but no history gets lost. This is (more or less) what the Tracman system proposed by Josh Drake does -- and it's awful IMHO. Amusingly, it's also more or less the same thing that debbugs does, which IMHO is really good. The main difference (again IMHO) is that Tracman tries to stuff the info in Trac comments, so it has to forcefully extract things from the email with rather poor results; whereas debbugs uses the mbox itself as the definite storage. Note that neither are really subscribed to the lists; rather they are some sort of gatekeepers, which process the email *before* they get to the list. (Actually, AFAIK in debbugs there is no actual mail list -- it's all mainly about appropriate CC's.) The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. No tracker looks after itself. heh very true ... Everybody has their favorite tracker (editor, OS, SCM, ...) ... we can have endless fun debating them backwards and forwards and never reach a conclusion, just as we do fairly regularly. The consensus last year among a group of us who examined a number of tracker systems was, IIRC, that Bugzilla had the best combination of features that people had requested. (And it does have some email interaction). Stefan Kaltenbrunner did some work on putting up a test instance and played with integrating it with the Postgres bug system - I forget how far exactly he got. the setup is more or less complete and the integration part was with the community login system (same we have now for wiki.postgresql.org) by adding a postgresql authentication backend as well as some experimental modifications to the email_in.pl script to enable autocreation of bugs from email. I did't push it further (or put it to a silent trial on say -bugs which is way less complex than -patches but might give us some ideas on the usability anyway) because I was fairly busy at the time and could not probably support it on a larger scale and it is far from clear that we actually want something like that. My understanding BTW is that debbugs is very specifically tailored to Debian needs, and is not suitable as a general purpose tracker system. And no other OSS project that we could find uses it. So, before we even look at it again I at least would want concrete proof that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) yeah that is my impression as well. (And yes, Trac sucks) +1 Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 09:29:10 -0400 Andrew Dunstan [EMAIL PROTECTED] wrote: The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. No tracker looks after itself. If you provide a reasonable interface to management (which we don't have now) you will get people to help. I can do pruning, triage and follow up so can a *lot* of other people that aren't C hackers. that these things have changed. (Perhaps Alvaro has forgotten those discussions ;-) ) (And yes, Trac sucks) You do realize that they *all* suck right? I have never seen *one* system that I have said, ooh ooh can I have my ice cream now, I have already had my cake. Trac is the only one that I have found that is anywhere near reasonable in its management of simplicity and features. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 09:36:23 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Gregory Stark wrote: Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. We really need to be looking at the bigger picture here. The more ridiculous our patch management and feedback procedures are, the more likely we won't get patches from new people (there are a whole of other reasons too, but for this context). Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 09:36:23 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Gregory Stark wrote: Bug/request trackers are great tools, but they're just tools. They don't replace actually having to do the work. Given the really trivial number of patches we're dealing with really just adding entries to a wiki page is a perfectly reasonable solution. I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. If you don't think it's a change, I claim you haven't used either :-P -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Tom Dunstan: Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. We don't actually receive that many new patches or bugs. One or two people going through the tracker once a week and closing the closed issues would be quite doable. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Andrew Dunstan: The issue frankly is not tracker features. The issue is who is going to maintain it, doing pruning and triage as necessary. I'll do it. Now just give me one I can maintain. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 10:15:29 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. If you don't think it's a change, I claim you haven't used either :-P I admit, I didn't use the wiki page because I got tired of trying to figure out which page, or list I should be looking at. I was still get js-kit replies from Bruces pages this week. Someone, anyone should be able to look exactly one place for the information required to process a patch. Of course we still have cvs etc.. but nobody on this list or new to the community should ever say to themselves, Which page am I supposed to go to? What list am I supposed to reply to now that I have feedback? Oh, I am supposed to go over to this wiki? Then what? You should be able to say, Hey here is the history of the patch for materialized views and then 30 hours later say, Phew large patch but here is my feedback Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Stefan Kaltenbrunner: the setup is more or less complete and the integration part was with the community login system (same we have now for wiki.postgresql.org) by adding a postgresql authentication backend as well as some experimental modifications to the email_in.pl script to enable autocreation of bugs from email. I did't push it further (or put it to a silent trial on say -bugs which is way less complex than -patches but might give us some ideas on the usability anyway) because I was fairly busy at the time and could not probably support it on a larger scale and it is far from clear that we actually want something like that. I would like to continue in that direction. Collect all -bugs and -patches threads as tracker items. I'll volunteer to close the closed ones. If someone has another tracking system to propose, I'd suggest checking it against http://wiki.postgresql.org/wiki/TrackerDiscussion. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 10:15:29 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: I don't think so because it really isn't a change from what we have now. There isn't much difference from having a wiki page versus just having conversations on the patch list and moving email around. If you don't think it's a change, I claim you haven't used either :-P I admit, I didn't use the wiki page because I got tired of trying to figure out which page, or list I should be looking at. I was still get js-kit replies from Bruces pages this week. I don't know what you're talking about. There are two wiki pages, one for the March commitfest and one for May. How can you be confused on which one are you supposed to look at? http://wiki.postgresql.org/wiki/CommitFest:March http://wiki.postgresql.org/wiki/CommitFest:May -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 10:28:55 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: I admit, I didn't use the wiki page because I got tired of trying to figure out which page, or list I should be looking at. I was still get js-kit replies from Bruces pages this week. I don't know what you're talking about. There are two wiki pages, one for the March commitfest and one for May. How can you be confused on which one are you supposed to look at? http://wiki.postgresql.org/wiki/CommitFest:March http://wiki.postgresql.org/wiki/CommitFest:May Am I supposed to look at the wiki page or bruce pages, or am I supposed to replying on the list about something. All of which happen during this fest. I have no doubt that it is obvious to you. It certainly wasn't to me. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Am Donnerstag, 10. April 2008 schrieb Tom Lane: Another is that the email list provides a push mechanism for putting the proposed patch under the noses of a bunch of people, a few of whom will hopefully take a sniff ;-). A tracker is very much more of a pull scenario where someone has to actively go looking for pending/proposed changes. In my mind the pull mechanism is exactly one of the major features I would expect from a proper tracking system, so I can pull and work on the issues that affect me at a time when it is convenient for me, instead of at the time when the push happens. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 07:30:32 -0700 Joshua D. Drake [EMAIL PROTECTED] wrote: I don't know what you're talking about. There are two wiki pages, one for the March commitfest and one for May. How can you be confused on which one are you supposed to look at? http://wiki.postgresql.org/wiki/CommitFest:March http://wiki.postgresql.org/wiki/CommitFest:May Am I supposed to look at the wiki page or bruce pages, or am I supposed to replying on the list about something. All of which happen during this fest. O.k. after reviewing it seems the wiki stuff came in a bit late but even looking at the wiki... this is the problem I see. I go to the wiki page: http://wiki.postgresql.org/wiki/CommitFest:May I click the patch for EXPLAIN progress info: http://archives.postgresql.org/message-id/[EMAIL PROTECTED] The message comes up. Granted... very, very cool that this is all linked, so +1. But now what? * Where do I comment? * Where do I submit my updated patch that fixes a small syntax error that Greg made? * How do I track it in the future? * Do I go to the wiki page again? * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? * If it takes me right back to the archives page, am I going to be plowing through 50 comments in the web archive format (which is laborious and inefficient for this sort of thing) in order to find the next relevant email (which would be the first one after I submitted my update to the patch?) * After I submitted my comments where do I go? * Do I submit them to -patches? * Or hackers? * What about cross threads? * Am I going to have to do that for every single patch I review? And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Lastly, how is this sustainable? I don't see anything that is reducing Bruce's workload. (for example) Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut [EMAIL PROTECTED] writes: Am Donnerstag, 10. April 2008 schrieb Tom Lane: Another is that the email list provides a push mechanism for putting the proposed patch under the noses of a bunch of people, a few of whom will hopefully take a sniff ;-). A tracker is very much more of a pull scenario where someone has to actively go looking for pending/proposed changes. In my mind the pull mechanism is exactly one of the major features I would expect from a proper tracking system, so I can pull and work on the issues that affect me at a time when it is convenient for me, instead of at the time when the push happens. Of course. The point is we need both, since each way scratches a different itch. Also, I'm quite hesitant to abandon a working process --- our email-based procedures have served the project pretty well over the past ten-plus years, else we'd not be here having this discussion. So, at least in the beginning, I want to layer any tracking process over what we already do, not make a big change for unproven results. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Greg Smith wrote: Apache also pushes everything through bugzilla: http://httpd.apache.org/dev/patches.html The interesting quote there is: Traditionally, patches have been submitted on the developer's mailing list as well as through the bug database. Unfortunately, this has made it hard to easily track the patches. And without being able to easily track them, too many of them have been ignored. Patches must now be submitted through the bug database... The thing that will obviously go away if this project were to switch to such a model is that right now, there are lots of ideas that go by that would never be submitted as patches like that. But Bruce snags them and turns them into todo items and such rather than letting the idea just get lost in the archives. I assume you also read this Apache heading: What if my patch gets ignored? Because Apache has only a small number of volunteer developers, and these developers are often very busy, it is possible that your patch will not receive any immediate feedback. ... Be persistent but polite. Post to the developers list pointing out your patch and why you feel it is important. Feel free to do this about once a week and continue until you get a response. This indicates to me that their patch system doesn't work too well in practice. ;-) Perhaps Apache is a more mature technology or more poorly managed. I can't imagine us requring an FAQ entry like that about ignored patches. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
* Bruce Momjian [EMAIL PROTECTED] [080410 11:06]: I assume you also read this Apache heading: What if my patch gets ignored? Because Apache has only a small number of volunteer developers, and these developers are often very busy, it is possible that your patch will not receive any immediate feedback. ... Be persistent but polite. Post to the developers list pointing out your patch and why you feel it is important. Feel free to do this about once a week and continue until you get a response. This indicates to me that their patch system doesn't work too well in practice. ;-) Perhaps Apache is a more mature technology or more poorly managed. I can't imagine us requring an FAQ entry like that about ignored patches. Well, currently *you* are the reason we don't ;-) a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
Warning - my development views and experiences are highly e-mail dependant (i.e. linux-kernel style dependant). So if you don't like email, you probably shouldn't read my response below. * Joshua D. Drake [EMAIL PROTECTED] [080410 10:48]: I click the patch for EXPLAIN progress info: http://archives.postgresql.org/message-id/[EMAIL PROTECTED] The message comes up. Granted... very, very cool that this is all linked, so +1. But now what? I think the point is that the PostgreSQL development happens via e-mail and on mailing lists. So the goal is to point you to the mail, so you can join in on the development (i.e. by mail on the mailing lists). Maybe the archives should offer a way to download the raw message? In addition to all the normal stuff people want from archives that mhonarc seems to do poorly ;-) * Where do I comment? In your mail program. * Where do I submit my updated patch that fixes a small syntax error that Greg made? Again - by mail, to -patches. And hopefully someone (the patch author, team of people, not Bruce) would update the wiki/tracker to say the patch has been revised, version X is $MSGID * How do I track it in the future? * Do I go to the wiki page again? Well, only if you want to pull the last status (i.e. someone else, not you may have updated it, and you haven't set yourself to be notified on changes). But again, since it's by email, you already have it all in your inbox, right? * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? Only if the wiki/tracker *hasn't* been updated. * If it takes me right back to the archives page, am I going to be plowing through 50 comments in the web archive format (which is laborious and inefficient for this sort of thing) in order to find the next relevant email (which would be the first one after I submitted my update to the patch?) Uh, don't you read your e-mail already? Any comment/discussions on the patch would have had you in the reply-to chain. All nicely threaded in your mail reader or gmane, (or not-so nicely on archives.postgresql.org) * After I submitted my comments where do I go? * Do I submit them to -patches? * Or hackers? * What about cross threads? Well, generally your comments go as a reply to the patch, which should (in theory) be already on -patches * Am I going to have to do that for every single patch I review? Well, you make it sound hard, but really, there is only 1 out-of-band action needed to happen to make this all work easily: Somebody (author, or team of people reading the mailling-lists) update the wiki/tracker when 1) New patch comes in 2) New version of patch is sent 3) A decision/consensus on a patch (or part of it) has been made And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Well, that's part of the general problem of the archives.postgresql.org... Lastly, how is this sustainable? I don't see anything that is reducing Bruce's workload. (for example) The only think that will ever reduce Bruce's workload is him trusting that things aren't getting overlooked. The value to the work Bruce does is that he really doesn't let anything slip through the cracks. One way we can do that is by having a tracker/wiki which is an easy place for Bruce to see that: Hey, this is/was looked after. I don't have to worry about this thing, I can delete it (and the followups to it) from my huge list of even more things to look at without expending lots of time re-reading the whole thread to make sure it didn't just die out -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
Brendan Jurd wrote: Another is that the email list provides a push mechanism for putting the proposed patch under the noses of a bunch of people, a few of whom will hopefully take a sniff ;-). A tracker is very much more of a pull scenario where someone has to actively go looking for pending/proposed changes. The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. This is trivial to configure in a real tracker. Less so for a wiki page, but it could still be accomplished with the careful application of script-fu. Not sure how others feel, but automated emails of come see my new stuff are kind of annoying if you get alot of them because you can't actually act on the email itself --- you have to take the step of going to the web site, which may be OK if they are clickable links, but you do end up hopping in and out of email. And if you read something on the web site then get an email it is hard to know if you have seen that entry already. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: But now what? If you've got substantive comments to make, you make them by replying to the original email, same as it ever was. The wiki page is an index of email threads that need attention. Small comments can just be left on the wiki page, but that's not the way to have significant discussions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Stefan Kaltenbrunner wrote: Gregory Stark wrote: Brendan Jurd [EMAIL PROTECTED] writes: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. Unfortunately that is the typical way to solve this. And it's awful. It's like the ubiquitous cryptic phone call in movies saying can't talk right now but there's something you should know. Meet me under the bridge And the guy dies before you meet him --- that is too funny. :-) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut [EMAIL PROTECTED] writes: Am Donnerstag, 10. April 2008 schrieb Tom Dunstan: Even so I reckon that would create vastly more noise than signal in the eventual tracker - part of the existing problem has been that wading through list archives is a pain for someone wanting to know the current status of a patch. I can't see the above helping that. We don't actually receive that many new patches or bugs. One or two people going through the tracker once a week and closing the closed issues would be quite doable. Yes, if we're just tracking patches or major proposals in a bug tracker. The hard part is actually deciding that they're closed. It's a big very cat-like herd of community members here. Reaching a consensus on taking action takes a long time and much teeth gnashing. Note that some people here are pushing a tracker as a way to organize the mailing lists and keep all discussions about the proposed changes from design to committing. I think they're crazy but they keep proposing that their favourite magical tracker will do it automatically. I think it will just end up looking like Bruce's lists where we couldn't even figure out how many patches were buried in those 2,000 messages. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: Am I supposed to look at the wiki page or bruce pages, or am I supposed to replying on the list about something. All of which happen during this fest. We were maintaining status on both pages for this fest, as an experiment to see which was more usable. IMHO the experiment is over and the wiki page won. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:15:08 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: * Where do I comment? In your mail program. To where? Development discussion is supposed to happen on -hackers but a patch is likely on -patches. Although we are allowed to discuss on -patches as long as it is limited, but then we push the discussion back to -hackers. How do you propose to track that? * How do I track it in the future? * Do I go to the wiki page again? Well, only if you want to pull the last status (i.e. someone else, not you may have updated it, and you haven't set yourself to be notified on changes). But again, since it's by email, you already have it all in your inbox, right? Do I? What if I am only using USENET to interfact? What if I just purged my mailbox because I get over 4500 messages a month from these lists? * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? Only if the wiki/tracker *hasn't* been updated. How do I know? Uh, don't you read your e-mail already? Any comment/discussions on the patch would have had you in the reply-to chain. All nicely threaded in your mail reader or gmane, (or not-so nicely on archives.postgresql.org) No it won't :). You are new here aren't you :P. It will be spread amongst at a minimum of two lists. * After I submitted my comments where do I go? * Do I submit them to -patches? * Or hackers? * What about cross threads? Well, generally your comments go as a reply to the patch, which should (in theory) be already on -patches Unless it gets into deeper discussion, then we are supposed to push it to -hackers and why do I have two interfaces again? One interface should be the goal. * Am I going to have to do that for every single patch I review? Well, you make it sound hard, but really, there is only 1 out-of-band action needed to happen to make this all work easily: Aidan it isn't hard, it ridiculous and inefficient. We are continually reinventing the wheel because we think we will somehow make it more round when in actuality all the other mature FOSS projects out there figured this out long ago. * Do I now respond to the hackers list? Well, that's part of the general problem of the archives.postgresql.org... What? I would never expect to track between mailing lists. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:17:37 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: But now what? If you've got substantive comments to make, you make them by replying to the original email, same as it ever was. The wiki page is an index of email threads that need attention. Tom I think you missed my point. I am long past email client here. I have opened a web browser, gone to a wiki, which pointed me to a archives page, which has a patch, which I have downloaded, reviewed and I am now ready to reply Oh but wait: I now need to open my mail client (fair enough, with me it is alt-tab), go to my projects-postgresql folder, put a search string in the search field, find the correct email, reply to the email with my comments, and possibly an updated patch or a patch to the patch. Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. Which would you honestly rather do? Especially if there was a email interface as well? Sincerely, Joshau D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Note that we expect that http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php and http://archives.postgresql.org/message-id/[EMAIL PROTECTED] are the same thing: a message on pgsql-hackers containing a patch and links to the subsequent discussion. You should be smart enough to figure out how to followup to that message. Hmm, I see two problems here -- one is that it's not obvious what list the message is in. I'll try to add the list name as part of the title. (I wonder what should happen if a message is posted to more than one list.) The other one is that the message-id page is not getting updated w.r.t. the thread index/main index links ... (If you try thread index on the message-id link, it doesn't work, but it does work on the other one.) Will fix. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue]
Aidan Van Dyk wrote: Lastly, how is this sustainable? I don't see anything that is reducing Bruce's workload. (for example) The only think that will ever reduce Bruce's workload is him trusting that things aren't getting overlooked. The value to the work Bruce does is that he really doesn't let anything slip through the cracks. One way we can do that is by having a tracker/wiki which is an easy place for Bruce to see that: Hey, this is/was looked after. I don't have to worry about this thing, I can delete it (and the followups to it) from my huge list of even more things to look at without expending lots of time re-reading the whole thread to make sure it didn't just die out Yes, the sooner someone applies or rejects a patch or idea the quicker I can remove it from my watch list and the fewer items I have to watch. Also, let me add the wiki does not have items that need discussion/feedback for this commit-fest. Is that going to be added someday? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue]
Bruce Momjian wrote: Also, let me add the wiki does not have items that need discussion/feedback for this commit-fest. Is that going to be added someday? Sure, we can create a new section titled items needing discussion. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:35]: I now need to open my mail client (fair enough, with me it is alt-tab), go to my projects-postgresql folder, put a search string in the search field, find the correct email, reply to the email with my comments, and possibly an updated patch or a patch to the patch. Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. Which would you honestly rather do? Especially if there was a email interface as well? Anything can be framed favourably, or not: But wait, I now need to open my web browser (fair enough, with me it is alt-tab), google for the postgresql tracker and find the correct site, look at some list of patches, click one, download, choose where to save it, and review it, then try and find my way back to the proper page, try to type a sane review into some textbox with limited editing capabilities, possibly find the upload new patch button, click it, check some box to say if it's a new patch, or a patch to the patch, try and find the patch on my system, add it, and upload it. Or ;-) I can grab the messageid (or mhonorc url, I've got tools to get the message id out if it), directly open the message in my reader of choice, and have the patch, all the discussion threaded nicely, so I can get a quick overview of some of the other things that might be happening with it), and simply reply to it with my review. Which would you honestly rather do? -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:41:51 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: And in looking at this further, if I look at the Column Level privelages patch on the wiki, the archive page goes to a -hackers email. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php * Do I now respond to the hackers list? Note that we expect that http://archives.postgresql.org/pgsql-hackers/2008-04/msg00049.php and http://archives.postgresql.org/message-id/[EMAIL PROTECTED] are the same thing: a message on pgsql-hackers containing a patch and links to the subsequent discussion. You should be smart enough to figure out how to followup to that message. Maybe but that isn't the point I am trying to make :). I shouldn't have to be. The most successful interfaces are those that are so dumb that my mother can use them. It should *always* be obvious exactly what I need to do. I should never have to guess (in terms of the interface it self). Consider graphical email clients. I want to send a message: Compose or New I want to reply to a message: Reply I want to read a message: Click Consider IM: I want to talk to mom: click, type Mom wants to get my attention: screen popup or glowing icon This is why email is so darn powerful. It isn't ubiquitous because of its age, its ubiquitous because it is dumb simple to use. Email can be just as complicated if I chose. Just add PGP to the mix, auto filters, aliases, tags, labels (not sure the difference but I have both), multiple identities etc.. But those are all features and are not required for email itself to work. The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue]
Bruce Momjian wrote: Also, let me add the wiki does not have items that need discussion/feedback for this commit-fest. Is that going to be added someday? I take that back. The March wiki has two items that are clearly not ready to be applied but need discussion that is happening: http://wiki.postgresql.org/wiki/CommitFest:March But the wiki is missing other items that need discussion: http://momjian.us/cgi-bin/pgpatches like the index items. So if the wiki is only supposed to only have patches worthy of review for possible application, the wiki should be empty at this point. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 11:53:09 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: I can grab the messageid (or mhonorc url, I've got tools to get the message id out if it), directly open the message in my reader of choice, and have the patch, all the discussion threaded nicely, so I My mail reader will do nothing with the message id. Likely the most widely used mail readers out there won't either. (I would have to check but I doubt Thunderbird for example would have any options, nor would outlook) Not everyone is willing to use mutt. Thanks, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 11:17:37 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: But now what? If you've got substantive comments to make, you make them by replying to the original email, same as it ever was. The wiki page is an index of email threads that need attention. Tom I think you missed my point. I am long past email client here. I have opened a web browser, gone to a wiki, which pointed me to a archives page, which has a patch, which I have downloaded, reviewed and I am now ready to reply Oh but wait: I now need to open my mail client (fair enough, with me it is alt-tab), go to my projects-postgresql folder, put a search string in the search field, find the correct email, reply to the email with my comments, and possibly an updated patch or a patch to the patch. Uh, how do you reply to an email from the archives web page? The only way I have found to do it is to cut/paste the email addresses (and fix the obfuscation), or download the mbox file. Because my personal system uses email I can reply to the email, or someone can download the mbox that goes with my queue. Either way going from the web to email is an extra step, for sure. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. And then no one sees your revised patch (except someone watching the tracker like a hawk). This is not the way to have a discussion, which is fundamentally what our process is. As I said before, I am uninterested in any proposals for a fundamental change in our processes. I want an index page that makes sure that nothing that's supposed to get done in a commit fest gets forgotten. I do not need what you propose, and I wouldn't voluntarily use it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake [EMAIL PROTECTED] writes: The message comes up. Granted... very, very cool that this is all linked, so +1. But now what? Now you return, suitably enlightened, to your regularly scheduled life talking about code (or trackers) on pgsql-hackers and other mailing lists. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Alvaro Herrera [EMAIL PROTECTED] writes: (I wonder what should happen if a message is posted to more than one list.) That's a good question. I suppose there are actually multiple archive entries in that case --- which one is the message-id link taking me to? I guess whichever list appears first in the To/Cc fields would be the best choice. This is a bit of a problem though, since if discussion ensued on the other list(s) you'd not see any link to it on that page. One of the things that would have to happen with any tracker system is that we'd need links to each of the related threads when a discussion gets fragmented like that. Is that a candidate for automation, or will it have to be done manually? (Another thing that really, really, really needs to get fixed is the archives' inability to link threads across month boundaries.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. I'm pretty sure we don't want a person who has never seen a C patch in his life anywhere near our patch queue. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 12:07:43 -0400 Tom Lane [EMAIL PROTECTED] wrote: Joshua D. Drake [EMAIL PROTECTED] writes: Or :) I can open a web browser, go to tracker.postgresql.org, review the list of open patches, click one, download, review, comment, upload new patch if required, done. And then no one sees your revised patch (except someone watching the This is false. As I said before, I am uninterested in any proposals for a fundamental Yes Tom I am aware of your particular opinion which is why I mention and email interface as well. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: (I wonder what should happen if a message is posted to more than one list.) That's a good question. I suppose there are actually multiple archive entries in that case --- which one is the message-id link taking me to? The one on the list which was first processed :-( They are processed in alphabetical order, so pgsql-hackers wins over pgsql-patches. However, there is an additional consideration: sometimes, Mhonarc rewrite message pages (for example because it needs to fix the hyperlinks which go to the thread index, when the thread index grows and the current message goes to a later page). If the link in pgsql-patches moves but the one in pgsql-hackers does not, then the pass over pgsql-patches would take precedence. (I don't really know if this actually happens or not -- it's pure speculation). I guess whichever list appears first in the To/Cc fields would be the best choice. This is a bit of a problem though, since if discussion ensued on the other list(s) you'd not see any link to it on that page. I don't see any way to solve this problem with the current implementation. I'm thinking we should ditch it and implement the one using the database. One of the things that would have to happen with any tracker system is that we'd need links to each of the related threads when a discussion gets fragmented like that. Is that a candidate for automation, or will it have to be done manually? Perhaps it could be done with the message-id on the search database. (Another thing that really, really, really needs to get fixed is the archives' inability to link threads across month boundaries.) Agreed. I examined Mhonarc to see if I could do it, but I don't think it's anywhere near its possibilities. I'm afraid we would have to switch to something completely different. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:55]: On Thu, 10 Apr 2008 11:53:09 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: I can grab the messageid (or mhonorc url, I've got tools to get the message id out if it), directly open the message in my reader of choice, and have the patch, all the discussion threaded nicely, so I My mail reader will do nothing with the message id. Likely the most widely used mail readers out there won't either. (I would have to check but I doubt Thunderbird for example would have any options, nor would outlook) Not everyone is willing to use mutt. s/mutt/a decent MUA/ ;-) But if you don't want to use a local MUA with those capabilities, then just go: http://news.gmane.org/[EMAIL PROTECTED] or http://www.highrise.ca/cgi-bin/mhonarc/http://archives.postgresql.org/pgsql-hackers/2008-04/msg00726.php And just click the action, and choose Followup And hey! It's all in your web-browser even, with a nice threaded interface of the discussion to boot! Now, if we could only get archives.postgresql.org to be as nice as that, or just punt to gmane for now ;-) Just for fun, put the following alias in your hosts file: 205.150.199.213 yugib.highrise.ca archives.postgresql.org And try that commitfest wiki page... a. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 10:24]: Someone, anyone should be able to look exactly one place for the information required to process a patch. That one place is (and I think always should be, but I'm biased) going to be the mailling list. Of course we still have cvs etc.. but nobody on this list or new to the community should ever say to themselves, Which page am I supposed to go to? What list am I supposed to reply to now that I have feedback? Oh, I am supposed to go over to this wiki? Then what? Well, ideally, they would just reply to the message that introduced the patch. Then it would go to both the list and the author, where further discussion can happen. Mailing lists are really good at discussion, threads, etc. You should be able to say, Hey here is the history of the patch for materialized views and then 30 hours later say, Phew large patch but here is my feedback Right, so you look at the message with the patch, save the patch (or download it if it's just linked), work, review, etc, and then just reply to the message. Again, the maililng list is an excellent interface to discuss things, manage threads of discussion, etc. Basically, as Tom keeps saying the wiki is just an index into the mailing list archives. Any tracker may be able to do that, with more or less complexity. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
* Joshua D. Drake [EMAIL PROTECTED] [080410 11:30]: On Thu, 10 Apr 2008 11:15:08 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: * Where do I comment? In your mail program. To where? Development discussion is supposed to happen on -hackers but a patch is likely on -patches. Although we are allowed to discuss on -patches as long as it is limited, but then we push the discussion back to -hackers. How do you propose to track that? Do I? What if I am only using USENET to interfact? What if I just purged my mailbox because I get over 4500 messages a month from these lists? No it won't :). You are new here aren't you :P. It will be spread amongst at a minimum of two lists. Unless it gets into deeper discussion, then we are supposed to push it to -hackers and why do I have two interfaces again? One interface should be the goal. What? I would never expect to track between mailing lists. All of these come down to the mailling-list. Last week I already asked about the distinction between -hackers and -patches, and what I saw as the consensus is that there both pretty much the same thing, by different names, and lots most people file them both away together. And in my MUA setup, (and gmane, a public NNTP interface to mailling-lists), threads *are* followed across lists seemlessly. I like this ability, so to me the -patches and -hackers distinction is just and address I pretty much ignore... But again, the point is, PostgreSQL development (and sure, I'm new, but I've been reading these lists for quite a while) has traditionally been via e-mail and the mailling-lists. Sure, there are some warts (like the current archives), but it's worked. *I* think trying to change the pending patches management *and* the whole development method of PostgreSQL at the same time isn't going to fly. And at least Tom seems against it too. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Commit fest queue
Joshua D. Drake wrote: On Thu, 10 Apr 2008 11:15:08 -0400 Aidan Van Dyk [EMAIL PROTECTED] wrote: Well, only if you want to pull the last status (i.e. someone else, not you may have updated it, and you haven't set yourself to be notified on changes). But again, since it's by email, you already have it all in your inbox, right? Do I? What if I am only using USENET to interfact? The NNTP interface is so unreliable that I doubt this is a problem in practice. What if I just purged my mailbox because I get over 4500 messages a month from these lists? You said it best yesterday: tough. That said, in the Majordomo interface there is an option to send you a message from its archives. Or you can get the mbox from the archives. * If I go to the wiki page again and click on the patch is it going to take me right back to the archive page? Only if the wiki/tracker *hasn't* been updated. How do I know? You go check. One interface should be the goal. The goal is making sure no patches are lost. I don't know why you feel so strongly about this topic. Are you a frequent patch reviewer? Not meant to bash you. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Marc G. Fournier wrote: Do other large projects accept patches 'ad hoc' like we do? FreeBSD? Linux? KDE? Here is what everyone else is using: FreeBSD - gnats Linux - bugzilla KDE - bugzilla GNOME - bugzilla Debian - debbugs Ubuntu - launchpad (proprietary) Mozilla - bugzilla OpenOffice - bugzilla Fedora - bugzilla Samba - bugzilla NTP - bugzilla Slony - bugzilla Apache - bugzilla Kolab - roundup GnuPG - roundup GCC - bugzilla glibc - bugzilla PHP - custom MySQL - from PHP Python - custom OpenSolaris - custom? Perl - RT OpenSUSE - bugzilla Ruby - ~gforge Exim - bugzilla Postfix is the only major project I looked at that didn't have any bug tracker linked at an obvious location. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut wrote: Here is what everyone else is using: FreeBSD - gnats Linux - bugzilla KDE - bugzilla GNOME - bugzilla Debian - debbugs Ubuntu - launchpad (proprietary) Mozilla - bugzilla OpenOffice - bugzilla Fedora - bugzilla Samba - bugzilla NTP - bugzilla Slony - bugzilla Apache - bugzilla Kolab - roundup GnuPG - roundup GCC - bugzilla glibc - bugzilla PHP - custom MySQL - from PHP Python - custom OpenSolaris - custom? Perl - RT OpenSUSE - bugzilla Ruby - ~gforge Exim - bugzilla Postfix is the only major project I looked at that didn't have any bug tracker linked at an obvious location. That is a nice list, but are these used for bug tracking or patch tracking? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
[EMAIL PROTECTED] (Joshua D. Drake) writes: The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. Are you sure about that? I think that our concern is about the sort of population of people that are capable of *creating* a C patch. I don't think the bar needs to be set as low as you're suggesting. -- output = reverse(ofni.secnanifxunil @ enworbbc) http://linuxfinances.info/info/oses.html As of next Monday, COMSAT will be flushed in favor of a string and two tin cans. Please update your software. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut wrote: Here is what everyone else is using: Kolab - roundup GnuPG - roundup Python - custom FWIW Python also uses roundup. This would be a pointless comment except that I think roundup is a bit closer to our ways than Bugzilla. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In the projects I'm involved in, tends to be for used for both purposes ... one central location for everything ... - --On Thursday, April 10, 2008 15:22:28 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Peter Eisentraut wrote: Here is what everyone else is using: FreeBSD - gnats Linux - bugzilla KDE - bugzilla GNOME - bugzilla Debian - debbugs Ubuntu - launchpad (proprietary) Mozilla - bugzilla OpenOffice - bugzilla Fedora - bugzilla Samba - bugzilla NTP - bugzilla Slony - bugzilla Apache - bugzilla Kolab - roundup GnuPG - roundup GCC - bugzilla glibc - bugzilla PHP - custom MySQL - from PHP Python - custom OpenSolaris - custom? Perl - RT OpenSUSE - bugzilla Ruby - ~gforge Exim - bugzilla Postfix is the only major project I looked at that didn't have any bug tracker linked at an obvious location. That is a nice list, but are these used for bug tracking or patch tracking? -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf+bf8ACgkQ4QvfyHIvDvMp9QCgm8zrjZogg6kzDazAqQLCzpeP WjoAn1+38NJ/+LscZXrUd5PuNoalweVd =7oz2 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Apr 10, 2008, at 12:52 AM, Brendan Jurd wrote: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. And that's part of the issue... come over to this other place to actually look at it. What I think we need is a tracker that has a web interface to email, along with archiving. That way the discussion can take place via email. -- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] Commit fest queue
Peter Eisentraut [EMAIL PROTECTED] writes: Marc G. Fournier wrote: Do other large projects accept patches 'ad hoc' like we do? FreeBSD? Linux? KDE? ... Postfix is the only major project I looked at that didn't have any bug tracker linked at an obvious location. Those are used for tracking bugs though. (Incidentally I just checked our debian packages and there are about half a dozen open bugs tagged upstream, some quite old) I know of no other project which mails around patches the way we do, not since, 1992. Other projects track proposed changes by keeping them in their revision control systems. This has a whole host of benefits including not losing version history when the patch is finally merged into the mainline code. Right now, for instance, if you want to understand why a change was made in HOT if you annotate it you'll always get the same commit and it'll just have a message from Tom saying he's committing HOT. All of Pavan's commit messages explaining the changes he made are lost. This is all a moot point as long as we CVS. Branching in CVS is such a pain to manage and so risky that we wouldn't want to be creating branches for every project. But I have some hope that git, svk, or something else will solve this problem for us. And indeed the closest analogue I can think of to our habit of mailing around patches is the Linux kernel where people often do post proposed patches and patches get signed off by a second developer. Each maintainer keeps track on his own todo list of patches to take and patches to send upstream though. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Gregory Stark wrote: And indeed the closest analogue I can think of to our habit of mailing around patches is the Linux kernel where people often do post proposed patches and patches get signed off by a second developer. Each maintainer keeps track on his own todo list of patches to take and patches to send upstream though. The difference between Linux and us is that we're so few people. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 14:18:52 -0400 Chris Browne [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Joshua D. Drake) writes: The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. Are you sure about that? I think that our concern is about the sort of population of people that are capable of *creating* a C patch. I don't think the bar needs to be set as low as you're suggesting. Why would you want to expend cycles understanding a process when you could expend cycles writing a C patch. Its about efficiency. If I have to *think* about some kind of process that takes cycles away from other more important and interesting things like algorithms. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 12:13:38 -0400 Alvaro Herrera [EMAIL PROTECTED] wrote: Joshua D. Drake wrote: The base requirements for this process must be so simple, so easy, that even if the person has never seen a C patch in his/her life they understand what is trying to be achieved. I'm pretty sure we don't want a person who has never seen a C patch in his life anywhere near our patch queue. Yes Alvaro but that doesn't mean the process should be complicated for the sake of being complicated. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
On Thu, 10 Apr 2008 16:14:33 -0500 Decibel! [EMAIL PROTECTED] wrote: On Apr 10, 2008, at 12:52 AM, Brendan Jurd wrote: The typical way to solve this is to have the tracker send an automatic notification email to a list saying Hey, there's a new ticket at , come and check it out. And that's part of the issue... come over to this other place to actually look at it. What I think we need is a tracker that has a web interface to email, along with archiving. That way the discussion can take place via email. You mean like how CMD interfaces with Trac :P (with some changes of course) Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
