Обсуждение: Commit fest queue
Tom lane said over on the concurrent psql thread: If we do split them then there is going to be some added effort to maintain the commit fest queue. Bruce has made it pretty clear that he doesn't want to put in any extra cycles here. So someone else has to step up to the plate if this is going to work. Any volunteers out there? What exactly are we talking about here? It sounds to me as if my tracman email with modification might work for this. If not, o.k. but it seems to fit. http://archives.postgresql.org/pgsql-hackers/2008-04/msg00324.php 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
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Tom lane said over on the concurrent psql thread:
>> If we do split them then there is going to be some added effort to
>> maintain the commit fest queue.
> What exactly are we talking about here? It sounds to me as if my
> tracman email with modification might work for this. If not, o.k. but
> it seems to fit.
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
regards, tom lane
On Wed, 09 Apr 2008 00:28:35 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > Tom lane said over on the concurrent psql thread: > >> If we do split them then there is going to be some added effort to > >> maintain the commit fest queue. > > > What exactly are we talking about here? It sounds to me as if my > > tracman email with modification might work for this. If not, o.k. > > but it seems to fit. > > This isn't really about tools. It's about who wants to put in the > day-after-day, year-after-year drudge work to maintain the queue. > Whoever wants to do the work can pick their tools... So you are saying, only one person should do this versus a team of individuals? That doesn't seem sustainable. Maybe I am misunderstanding what the root of the problem is and most likely what the requirements are but either way, there is a tool involved, even if it is vi. 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
"Joshua D. Drake" <jd@commandprompt.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This isn't really about tools. It's about who wants to put in the
>> day-after-day, year-after-year drudge work to maintain the queue.
>> Whoever wants to do the work can pick their tools...
> So you are saying, only one person should do this versus a team of
> individuals? That doesn't seem sustainable.
Uh, no, I did not say that; and indeed I'd much rather see it done
by a team. My point was that the volunteer(s) need to come first,
and then they get to pick their tools.
regards, tom lane
On Wed, 09 Apr 2008 00:59:03 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > > So you are saying, only one person should do this versus a team of > > individuals? That doesn't seem sustainable. > > Uh, no, I did not say that; and indeed I'd much rather see it done > by a team. My point was that the volunteer(s) need to come first, > and then they get to pick their tools. I would be willing to help but I obviously need a better understanding of what the requirements are for the queue. 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
Tom Lane wrote: > This isn't really about tools. It's about who wants to put in the > day-after-day, year-after-year drudge work to maintain the queue. > Whoever wants to do the work can pick their tools... I still think it would be best if the patch authors did the work. They are the ones who care about the patch and want the review, and they're in the best position to know what the status of a patch is. Others can do it as well of course, in the spirit of a Wiki. That leaves out most of the discussion threads, potential TODO items etc. that Bruce collects in the patches queue. Depending on your viewpoint that's either a good or a bad thing. It's good because it keeps the patch queue short and relevant; we'll only have patches or design proposals in the list that are genuinely waiting for review. But it's bad because good patches from one-off submitters might fall through the cracks. That's where I'd love to have Bruce to help. He's good at following up items and making sure nothing falls through the cracks. I don't mind what tool he uses for doing that, the mailbox probably is the easiest for that task. And that's the kind of work that's hard to do as a team. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > Tom Lane wrote: > > This isn't really about tools. It's about who wants to put in the > > day-after-day, year-after-year drudge work to maintain the queue. > > Whoever wants to do the work can pick their tools... > > I still think it would be best if the patch authors did the work. They > are the ones who care about the patch and want the review, and they're > in the best position to know what the status of a patch is. Others can > do it as well of course, in the spirit of a Wiki. Does that move us in the direction of the patch tracker? That does raise the bar for patch submitters, though I would catch any patches that weren't in the tracker. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> I still think it would be best if the patch authors did the work. They
> are the ones who care about the patch and want the review, and they're
> in the best position to know what the status of a patch is.
Unfortunately, a lot of submitters are way too optimistic about that ...
> it's bad because good patches from one-off submitters might fall through
> the cracks.
Exactly. Somebody (or preferably somebodies) has to accept the
responsibility of seeing to it that everything gets onto the commit-fest
page; requiring the authors to do it simply won't work reliably. And
it'd be more work for them anyway --- consider an author who hasn't got
an account on our wiki and/or has never edited a wiki page before.
Somebody who does it every day will certainly be a lot faster.
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
> That's where I'd love to have Bruce to help.
Bruce has made it perfectly clear that he doesn't want to take on any
added maintenance work.
regards, tom lane
Tom Lane wrote: > This doesn't seem particularly hard, just a matter of following the > relevant mailing lists (mostly -patches, but various offenders send > patches elsewhere) and adding links to the current wiki page. > > > That's where I'd love to have Bruce to help. > > Bruce has made it perfectly clear that he doesn't want to take on any > added maintenance work. Yea, I would like to reduce the amount of maintenance work I do, not add to it. Now, you might say that if this works I will have less maintenance work to do because more people will be doing it, but I will believe it when I see it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
* Tom Lane <tgl@sss.pgh.pa.us> [080409 10:40]: > This doesn't seem particularly hard, just a matter of following the > relevant mailing lists (mostly -patches, but various offenders send > patches elsewhere) and adding links to the current wiki page. I've often been confused that discussion seem to seamlessly be on either -patches, or -hackers. From the understanding I got on the mailing list pages (http://archives.postgresql.org/), it seems like -patches is supposed to be only for patches, and -hackers for the general discussion, issues, features, etc on anything development related. But from observation, it seems like -patches and -hackers are different lists of the same thing, except that -patches has a much bigger message size limit. Is that the intended operational status? If not, would it be possible to some how force reply-to of pg-patches to -hackers? I know, that blows chunks with the usual mailling-list reply-to issues, but it would make -hackers the single place to follow discussions, and maybe make -patches a more pointed "list of things to track". Tracking 2 lists really isn't a big deal - I'm guessing most others dump both -patches and -hackers into the same mailbox anyways too, but it does seem like the 2 lists are a needless split as they currently are used. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Aidan Van Dyk wrote: -- Start of PGP signed section. > * Tom Lane <tgl@sss.pgh.pa.us> [080409 10:40]: > > > This doesn't seem particularly hard, just a matter of following the > > relevant mailing lists (mostly -patches, but various offenders send > > patches elsewhere) and adding links to the current wiki page. > > I've often been confused that discussion seem to seamlessly be on either > -patches, or -hackers. From the understanding I got on the mailing > list pages (http://archives.postgresql.org/), it seems like -patches is > supposed to be only for patches, and -hackers for the general > discussion, issues, features, etc on anything development related. > > But from observation, it seems like -patches and -hackers are different > lists of the same thing, except that -patches has a much bigger message > size limit. > > Is that the intended operational status? > > If not, would it be possible to some how force reply-to of pg-patches to > -hackers? I know, that blows chunks with the usual mailling-list > reply-to issues, but it would make -hackers the single place to follow > discussions, and maybe make -patches a more pointed "list of things to > track". > > Tracking 2 lists really isn't a big deal - I'm guessing most others dump > both -patches and -hackers into the same mailbox anyways too, but it > does seem like the 2 lists are a needless split as they currently are > used. Yea, the split is kind of odd. I think the idea is that discussion about patch details happens on 'patches' and more general discussion on hackers, though it doesn't work that way all the time. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Aidan Van Dyk <aidan@highrise.ca> writes: > I've often been confused that discussion seem to seamlessly be on either > -patches, or -hackers. From the understanding I got on the mailing > list pages (http://archives.postgresql.org/), it seems like -patches is > supposed to be only for patches, and -hackers for the general > discussion, issues, features, etc on anything development related. That's the theory. > But from observation, it seems like -patches and -hackers are different > lists of the same thing, except that -patches has a much bigger message > size limit. Practice is often different from theory ;-). I don't mind discussion about a patch on -patches, as long as it's not getting into major design decisions --- if it does, then the thread should get moved to -hackers, though that doesn't always happen. > If not, would it be possible to some how force reply-to of pg-patches to > -hackers? No, we aren't going to do that. It wouldn't work anyway; you can't force people to send messages to one list rather than another, and the mail list software is surely not bright enough to distinguish "patch" from "not a patch" on its own. regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes: >> If not, would it be possible to some how force reply-to of pg-patches to >> -hackers? > > No, we aren't going to do that. It wouldn't work anyway; you can't > force people to send messages to one list rather than another, and > the mail list software is surely not bright enough to distinguish > "patch" from "not a patch" on its own. I did suggest something a while back that I think died for because too many other things were changing at the same time. Perhaps would be more practical with the current infrastructure. I suggested eliminating pgsql-patches as a separate mailing list for people to send mail to. Instead you could subscribe to a version of pgsql-hackers which automatically had large attachments removed and replaced with a link to the file on a web page. So all followups would be on -hackers because they would follow the headers on the original message. The only place the -noattachments list would show up would be buried in the Received headers. I could help make a perl script to do the message munging but this assumes there's a way to hook it into the mail server and get the files to the web server. I'm not familiar with the infrastructure so I don't know how accessible these things are to each other. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
"Bruce Momjian" <bruce@momjian.us> writes: >> I still think it would be best if the patch authors did the work. They >> are the ones who care about the patch and want the review, and they're >> in the best position to know what the status of a patch is. Others can >> do it as well of course, in the spirit of a Wiki. > > Does that move us in the direction of the patch tracker? That does > raise the bar for patch submitters, though I would catch any patches > that weren't in the tracker. Not really, whatever tool it's in the hard part is reading the emails and deciding what to do with them. What would move us in the direction of this mythical "patch tracker" would be if we knew exactly what our workflow was. Once we know what our workflow is then we could pick a tool which enforces that workflow. That's the whole point of a special purpose tool for things like this, enforcing that all the ts are crossed, is dotted, and all procedures followed. Eg, requiring that the "Patch status" field be filled in or that two reviewers don't grab the same patch. What a request tracker does *not* do is magically make decisions for us. We still have to review the patches, we still have to make technical decisions. Patches which are too hard to wrap our head around would still sit there until someone stands up and applies or rejects it. (Anyone who's reported a Mozilla bug in the past 8 years might know what such a tracker looks like...) Frankly until we decide what our workflow is and what information we want to track I don't see why -- or even how -- we would pick a tool to track it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
Gregory Stark <stark@enterprisedb.com> writes:
> What would move us in the direction of this mythical "patch tracker" would be
> if we knew exactly what our workflow was. Once we know what our workflow is
> then we could pick a tool which enforces that workflow.
Well, I don't think we want or need an "enforced" workflow. What we
need is just a list of pending patches so that nothing falls through the
cracks. As you say, most of the work is in recognizing which emails
deserve to be entered into the list, and that's not subject to
automation (not in this decade anyway).
regards, tom lane
Bruce Momjian wrote: > Tom Lane wrote: >> This doesn't seem particularly hard, just a matter of following the >> relevant mailing lists (mostly -patches, but various offenders send >> patches elsewhere) and adding links to the current wiki page. >> >>> That's where I'd love to have Bruce to help. >> Bruce has made it perfectly clear that he doesn't want to take on any >> added maintenance work. > > Yea, I would like to reduce the amount of maintenance work I do, not add > to it. Now, you might say that if this works I will have less > maintenance work to do because more people will be doing it, but I will > believe it when I see it. Ok. In that case I'd suggest that we do roughly the same thing we did this commit fest. You, Bruce, collect all the relevant threads into the patch queue as before, and at the beginning of commit fest someone else goes through that list and puts the threads that have a commit-fest worthy patch or design proposal in them to the Wiki (thanks Alvaro for doing that in this fest!). Then we can use the Wiki page as the official list during the commit fest. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
> I suggested eliminating pgsql-patches as a
> separate mailing list for people to send mail to.
> Instead you could subscribe to a version of pgsql-hackers which automatically
> had large attachments removed and replaced with a link to the file on a web
> page.
Interesting thought. I dunno how implementable it is either, but it
definitely would help to cut down fragmentation of discussions.
regards, tom lane
On Wed, 9 Apr 2008, Tom Lane wrote: > Gregory Stark <stark@enterprisedb.com> writes: >> What would move us in the direction of this mythical "patch tracker" would be >> if we knew exactly what our workflow was. Once we know what our workflow is >> then we could pick a tool which enforces that workflow. > > Well, I don't think we want or need an "enforced" workflow. What we > need is just a list of pending patches so that nothing falls through the > cracks. Making sure nothing falls through the cracks is exactly the point of an enforced workflow. It might be a manual operation, it might be some piece of software, but ultimately you need a well-defined process where things move around but don't get dropped. Exactly how said enforcement happens is certainly open to discussion though. Last time I chimed in on this subject I tried unsuccessfully to move discussion into this area--trying to nail down the structure of a patch processing workflow--but all I managed to do was kick off was a discussion of the trivia involved with one step. A better attempt is below. > As you say, most of the work is in recognizing which emails deserve to > be entered into the list, and that's not subject to automation (not in > this decade anyway). Sure, but that can still be an input to the workflow. Since I'm unphased by criticism and have been watching this whole 'Fest fairly closely, I'll even throw out a sample for a more formal workflow outline. Always easier to map this stuff out when you've got a dummy proposal to beat up. This is aimed to look somewhat like what happened this time around (except using the newer tools that are basically built now) rather than to be a more grand vision: Input: submissions to -patches and -hackers Processing: Saved via mail reader software Output: mbox file with relevant items Person: Bruce Input: mbox file Processing: Run script Output: Patch queue detail wiki page, with links to the archives Person: Greg Stark via his script Input: Patch queue detail Processing: Manually editing page, perhaps with some tool assistance Output: Patch queue summary wiki page Person: Alvaro Input: Patch queue summary Processing: Patch committed, removed from page Output: Updated patch queue summary, e-mail to author Person: Tom, Bruce, other committers Input: Patch queue summary Processing: Patch changed to be a TODO item Output: Expanded TODO list, updated patch queue summary, e-mail to author Person: Bruce Input: Patch queue summary Processing: Patch rejected or bounced back with comments Output: Reduced patch queue summary, e-mail to author Person: Bruce There's a clear hole for messages to fall into when they're being summarized into the patch summary step, I recall Tom saying something about items that didn't make it into the current summary. That needs to be improved a bit. I also note that I didn't diagram separate review steps because I didn't see them happen in a formal way this time around that I could use as a model. As a sideline observer here it seems to me that Bruce has a good and hard to replace process to kick this all off already going, so don't mess with that. It would be nice to find vict...err, volunteers to pull him out of the later steps though for a net reduction in his time. Simply getting things organized better from the start should help with getting more people helping out with review; the common complaint seemed to be "I can't figure out what to help with in this big mess" which having a summary from the start should improve. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote: > Making sure nothing falls through the cracks is exactly the point of an > enforced workflow. It might be a manual operation, it might be some piece > of software, but ultimately you need a well-defined process where things > move around but don't get dropped. Exactly how said enforcement happens > is certainly open to discussion though. As a volunteer organization we don't have much enforcement control. We can control what we do, but not require others to do anything. This makes trying to enforce uniform behavior difficult. Companies have a much easier time with enforcement because there is a paycheck attached to it. > As a sideline observer here it seems to me that Bruce has a good and hard > to replace process to kick this all off already going, so don't mess with > that. It would be nice to find vict...err, volunteers to pull him out of > the later steps though for a net reduction in his time. Simply getting > things organized better from the start should help with getting more > people helping out with review; the common complaint seemed to be "I can't > figure out what to help with in this big mess" which having a summary from > the start should improve. And when we did whittle it down to a short list there were still very few people helping. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Heikki Linnakangas wrote: > Bruce Momjian wrote: > > Tom Lane wrote: > >> This doesn't seem particularly hard, just a matter of following the > >> relevant mailing lists (mostly -patches, but various offenders send > >> patches elsewhere) and adding links to the current wiki page. > >> > >>> That's where I'd love to have Bruce to help. > >> Bruce has made it perfectly clear that he doesn't want to take on any > >> added maintenance work. > > > > Yea, I would like to reduce the amount of maintenance work I do, not add > > to it. Now, you might say that if this works I will have less > > maintenance work to do because more people will be doing it, but I will > > believe it when I see it. > > Ok. In that case I'd suggest that we do roughly the same thing we did > this commit fest. You, Bruce, collect all the relevant threads into the > patch queue as before, and at the beginning of commit fest someone else > goes through that list and puts the threads that have a commit-fest > worthy patch or design proposal in them to the Wiki (thanks Alvaro for > doing that in this fest!). Then we can use the Wiki page as the official > list during the commit fest. 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 Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Apr 10, 2008 at 12:33 AM, Bruce Momjianwrote: > Heikki Linnakangas wrote: > > I still think it would be best if the patch authors did the work. They > > are the ones who care about the patch and want the review, and they're > > in the best position to know what the status of a patch is. Others can > > do it as well of course, in the spirit of a Wiki. > I very much agree. > Does that move us in the direction of the patch tracker? That does > raise the bar for patch submitters, though I would catch any patches > that weren't in the tracker. > I suppose you could say that it would raise the bar, but for what it's worth I would much *rather* be maintaining a wiki page / row in a wiki table than sending emails with attachments to a list. Especially if the wiki is equipped with clever templates for doing same*. When you consider the hours spent reading and understanding existing code, making changes and compiling/recompiling/regression testing that a patch author needs to do in order to even create a patch, the extra five minutes it takes to add a line to a wiki table doesn't really signify. And pretty much pays for itself in terms of the immediate satisfaction of knowing that your patch is now safely in the correct queue. Cheers, BJ * I'd be interested in helping to build such templates -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH/WxK5YBsbHkuyV0RAmQXAJ43vvIPse1HNa3Me92W706kcLeYGgCgiCM3 JjrsH7Ot5uVQrwC9JHT88hQ= =GlX7 -----END PGP SIGNATURE-----
On Wed, 9 Apr 2008 20:50:28 -0400 (EDT) Bruce Momjian <bruce@momjian.us> wrote: > Greg Smith wrote: > > Making sure nothing falls through the cracks is exactly the point > > of an enforced workflow. It might be a manual operation, it might > > be some piece of software, but ultimately you need a well-defined > > process where things move around but don't get dropped. Exactly > > how said enforcement happens is certainly open to discussion though. > > As a volunteer organization we don't have much enforcement control. We don't? It's like this :) "You want to submit a patch, this is how it's done." "Oh... You don't want to do it that way?" "Tough" Why is it that because we are a volunteer organization we can't have enforcement? You document the procedure, and every single time the issue arises you paste a link with that procedure :) > We can control what we do, but not require others to do anything. We do it all the time now, or does Tom actually like going through all the patches and rewriting half of them? There is a very distinct way we allow things to happen in this community, let's not fool ourselves. It is just a lot of it isn't documented so we have this fuzzy feeling of being all malleable and not in control. > > And when we did whittle it down to a short list there were still very > few people helping. > Yes and that is a much bigger problem. 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
Brendan Jurd wrote: > > Does that move us in the direction of the patch tracker? That does > > raise the bar for patch submitters, though I would catch any patches > > that weren't in the tracker. > > > > I suppose you could say that it would raise the bar, but for what it's > worth I would much *rather* be maintaining a wiki page / row in a wiki > table than sending emails with attachments to a list. Especially if > the wiki is equipped with clever templates for doing same*. > > When you consider the hours spent reading and understanding existing > code, making changes and compiling/recompiling/regression testing that > a patch author needs to do in order to even create a patch, the extra > five minutes it takes to add a line to a wiki table doesn't really > signify. And pretty much pays for itself in terms of the immediate > satisfaction of knowing that your patch is now safely in the correct > queue. I think there is concern that trivial patches wouldn't be submitted to a patch tracker, especially by new submitters. Again, I am willing to track the ones that aren't in the patch tracker, but then we have two places where patches exist (perhaps three with the wiki). -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake wrote: > > And when we did whittle it down to a short list there were still very > > few people helping. > > > > Yes and that is a much bigger problem. I was looking for some more text after that sentence. :-( -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, 9 Apr 2008 21:38:29 -0400 (EDT) Bruce Momjian <bruce@momjian.us> wrote: > I think there is concern that trivial patches wouldn't be submitted > to a patch tracker, especially by new submitters. Again, I am > willing to track the ones that aren't in the patch tracker, but then > we have two places where patches exist (perhaps three with the wiki). > Which is horrible. We need to have one place to find this information. 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
On Wed, 9 Apr 2008 21:40:25 -0400 (EDT) Bruce Momjian <bruce@momjian.us> wrote: > Joshua D. Drake wrote: > > > And when we did whittle it down to a short list there were still > > > very few people helping. > > > > > > > Yes and that is a much bigger problem. > > I was looking for some more text after that sentence. :-( > Sorry man :). I was afraid if I continued down that path it wouldn't be good. I actually have some ideas on this but I need time to align some ducks first. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, April 09, 2008 18:33:30 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: > On Wed, 9 Apr 2008 20:50:28 -0400 (EDT) > Bruce Momjian <bruce@momjian.us> wrote: > >> Greg Smith wrote: >> > Making sure nothing falls through the cracks is exactly the point >> > of an enforced workflow. It might be a manual operation, it might >> > be some piece of software, but ultimately you need a well-defined >> > process where things move around but don't get dropped. Exactly >> > how said enforcement happens is certainly open to discussion though. >> >> As a volunteer organization we don't have much enforcement control. > > We don't? It's like this :) > > "You want to submit a patch, this is how it's done." > "Oh... You don't want to do it that way?" > "Tough" > > Why is it that because we are a volunteer organization we can't have > enforcement? You document the procedure, and every single time the > issue arises you paste a link with that procedure :) Damn, this is starting to get to be a trend ... but, I can't but agree 100% with this ... we *can* enforce, and I doubt it will have much (if any) affect on the # of patches that come in, since ppl want to see their work committed, and will follow any *reaonable* procedure we have for them to do so ... Do other large projects accept patches 'ad hoc' like we do? FreeBSD? Linux? KDE? - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf9dI8ACgkQ4QvfyHIvDvOFgQCfZ74Yefkh3TGxlmoxf6ujI4La VxIAn3dJRWm4pLUn9Qr7Y2zobyCpXHeG =pazk -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Apr 10, 2008 at 11:38 AM, Bruce Momjianwrote: > I think there is concern that trivial patches wouldn't be submitted to a > patch tracker, especially by new submitters. Again, I am willing to > track the ones that aren't in the patch tracker, but then we have two > places where patches exist (perhaps three with the wiki). For new submitters, there's always going to be some set of hoops to jump through. Whether it's emailing -patches, adding a ticket to a Trac or bugzilla, or adding a wiki entry, there will be some process that they need to conform to if they want their patch to get reviewed. Personally I don't feel that using a patch tracker or wiki is any more onerous than using an email list, and it's a whole lot more responsive (i.e., doesn't require Bruce to personally and manually shift the entry from -patches to the queue). It's not like we'd be asking submitters to draw a chalk circle on their floor and conduct an arcane ritual. =) It's just a website. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH/XU55YBsbHkuyV0RAg5DAJ9faAwOxlGPGmqkroHLjwkDpE0lWwCfcMrH dDHcBjpQy5uspFljnv463/k= =1Tuq -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, April 09, 2008 21:38:29 -0400 Bruce Momjian <bruce@momjian.us> wrote: > I think there is concern that trivial patches wouldn't be submitted to a > patch tracker, especially by new submitters. Can I see a show of hands as to who (other then Bruce) is concerned that new submitters are too lazy to submit their patches through a proper patch tracker vs simply sending via email? 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 ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf9dPoACgkQ4QvfyHIvDvP3vwCg5+PG39xHUDhiDUKPcEzH8fZi Ei4An140iNV/q/Ne/B7NpsziNDXQaIoU =PlXR -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > - --On Wednesday, April 09, 2008 21:38:29 -0400 Bruce Momjian <bruce@momjian.us> > wrote: > > > > I think there is concern that trivial patches wouldn't be submitted to a > > patch tracker, especially by new submitters. > > Can I see a show of hands as to who (other then Bruce) is concerned that new > submitters are too lazy to submit their patches through a proper patch tracker > vs simply sending via email? Uh, I am not concerned. I was just stating what others have said. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Wed, 09 Apr 2008 22:59:43 -0300 "Marc G. Fournier" <scrappy@hub.org> wrote: > Damn, this is starting to get to be a trend ... but, I can't but > agree 100% with this ... we *can* enforce, and I doubt it will have > much (if any) affect on the # of patches that come in, since ppl want > to see their work committed, and will follow any *reaonable* > procedure we have for them to do so ... > > Do other large projects accept patches 'ad hoc' like we do? > FreeBSD? Linux? KDE? > KDE is fairly structured. Linux... I don't know. I do know that at one time a very well known Alan slammed a very well known Linux for using his inbox as a patch queue (funny isn't it, no offense Bruce). FreeBSD I would think you would know better than I. However even Debian for all of its warts is *very* structured. 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
On Wed, 09 Apr 2008 23:01:30 -0300 "Marc G. Fournier" <scrappy@hub.org> 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. 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
On Thu, 10 Apr 2008 12:02:37 +1000 "Brendan Jurd" <direvus@gmail.com> wrote: > It's not like we'd be asking submitters to draw a chalk circle on > their floor and conduct an arcane ritual. =) It's just a website. No, but that is essentially what we do now :P. 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
On Wed, 9 Apr 2008, Marc G. Fournier wrote: > Do other large projects accept patches 'ad hoc' like we do? FreeBSD? Linux? > KDE? The Linux procedure is documented at http://www.mjmwired.net/kernel/Documentation/SubmittingPatches Linux was forced into some structure by the SCO lawsuit circa 2004, in that they track who patches came from more carefully now. But the process of submission to the Linux kernel developer's mailing list is even less organized than here; as stated in that document, they will drop patches without comment whenever they please. However, they do have a person designated "Trivial Patch Monkey" which is such a great title that you have to forgive the rest of the problems in the process. FreeBSD includes a program called send-pr just to submit "problem reports" into their system which can include feature changes. You can get an idea how sophisticated their tracking for bug patches is by looking at http://www.freebsd.org/cgi/query-pr-summary.cgi?query KDE's process works similarly to here, e-mail based with specific people assigned to track submissions to the various portions of the project: http://developer.kde.org/documentation/other/developer-faq.html#q2.21 GNOME makes all submitters create a report in bugzilla and tracks from there: http://live.gnome.org/GnomeLove/SubmittingPatches 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. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, April 09, 2008 19:06:30 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: > On Wed, 09 Apr 2008 22:59:43 -0300 > "Marc G. Fournier" <scrappy@hub.org> wrote: > >> Damn, this is starting to get to be a trend ... but, I can't but >> agree 100% with this ... we *can* enforce, and I doubt it will have >> much (if any) affect on the # of patches that come in, since ppl want >> to see their work committed, and will follow any *reaonable* >> procedure we have for them to do so ... >> >> Do other large projects accept patches 'ad hoc' like we do? >> FreeBSD? Linux? KDE? >> > > KDE is fairly structured. Linux... I don't know. I do know that at one > time a very well known Alan slammed a very well known Linux for using > his inbox as a patch queue (funny isn't it, no offense Bruce). FreeBSD I > would think you would know better than I. However even Debian for all > of its warts is *very* structured. FreeBSD, *everything* goes through GnATs ... bug reports *and* patches ... - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf9g/4ACgkQ4QvfyHIvDvNRhgCgtxXpF9+9ruMRfOmVBQsHctfe Z2AAoJbKGw05+BAxLaw38MxjiU41dMrS =O5g6 -----END PGP SIGNATURE-----
"Brendan Jurd" <direvus@gmail.com> writes:
> Personally I don't feel that using a patch tracker or wiki is any more
> onerous than using an email list, and it's a whole lot more responsive
There are a couple of differences in my mind. One is that the email
list provides an automatic historical archive, whereas trackers tend to
be all about current state. 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.
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.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Apr 10, 2008 at 3:24 PM, Tom Lane wrote: > "Brendan Jurd" writes: > > Personally I don't feel that using a patch tracker or wiki is any more > > onerous than using an email list, and it's a whole lot more responsive > > There are a couple of differences in my mind. One is that the email > list provides an automatic historical archive, whereas trackers tend to > be all about current state. They do? We must be thinking about different species of trackers then, because not only do trackers like bugzilla and Trac have automatic historical archives, but they are much easier to query than an email archive. Even a wiki page has a built-in history (list of changes) although admittedly this is not friendly to queries like "have we already rejected similar patches" and such. > 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. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH/asy5YBsbHkuyV0RAkJoAJ9yJCZ1da5FN015xxmKY1g5LbAzygCfUpXQ xJ0S/rcBzv2S3L8mQxz9aAs= =MzEJ -----END PGP SIGNATURE-----
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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
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
"Brendan Jurd" <direvus@gmail.com> 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!
Gregory Stark wrote: > "Brendan Jurd" <direvus@gmail.com> 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
On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark <stark@enterprisedb.com> 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
Tom Dunstan wrote: > On Thu, Apr 10, 2008 at 1:07 PM, Gregory Stark <stark@enterprisedb.com> 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
On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> 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
"Stefan Kaltenbrunner" <stefan@kaltenbrunner.cc> 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!
Tom Dunstan wrote: > On Thu, Apr 10, 2008 at 3:03 PM, Stefan Kaltenbrunner > <stefan@kaltenbrunner.cc> 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
On Thu, Apr 10, 2008 at 3:41 PM, Gregory Stark <stark@enterprisedb.com> 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
Joshua D. Drake escribió: > On Wed, 09 Apr 2008 23:01:30 -0300 > "Marc G. Fournier" <scrappy@hub.org> 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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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
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
On Thu, 10 Apr 2008 09:29:10 -0400 Andrew Dunstan <andrew@dunslane.net> 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
On Thu, 10 Apr 2008 09:36:23 -0400 Alvaro Herrera <alvherre@commandprompt.com> 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
Joshua D. Drake wrote: > On Thu, 10 Apr 2008 09:36:23 -0400 > Alvaro Herrera <alvherre@commandprompt.com> 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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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.
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.
On Thu, 10 Apr 2008 10:15:29 -0400 Alvaro Herrera <alvherre@commandprompt.com> 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
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.
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>.
Joshua D. Drake wrote: > On Thu, 10 Apr 2008 10:15:29 -0400 > Alvaro Herrera <alvherre@commandprompt.com> 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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Thu, 10 Apr 2008 10:28:55 -0400 Alvaro Herrera <alvherre@commandprompt.com> 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
On Thu, 10 Apr 2008 07:30:32 -0700 "Joshua D. Drake" <jd@commandprompt.com> 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/87wsn82lda.fsf@oxford.xeocode.com 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 againand 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? * Whatabout 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
Peter Eisentraut <peter_e@gmx.net> 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
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 thatyourpatch will not receive any immediate feedback....Be persistent but polite. Post to the developers list pointingoutyour patch and why you feel it is important. Feel free to dothis about once a week and continue until you geta 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Joshua D. Drake" <jd@commandprompt.com> 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
* Bruce Momjian <bruce@momjian.us> [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, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
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 <jd@commandprompt.com> [080410 10:48]: > I click the patch for EXPLAIN progress info: > > http://archives.postgresql.org/message-id/87wsn82lda.fsf@oxford.xeocode.com > > 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 thefollowups to it) from my huge list of even more things to look at without expending lots of time re-reading the wholethread to make sure it didn't just die out" -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Joshua D. Drake" <jd@commandprompt.com> 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
Stefan Kaltenbrunner wrote: > Gregory Stark wrote: > > "Brendan Jurd" <direvus@gmail.com> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Peter Eisentraut" <peter_e@gmx.net> 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
On Thu, 10 Apr 2008 11:15:08 -0400 Aidan Van Dyk <aidan@highrise.ca> 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
On Thu, 10 Apr 2008 11:17:37 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> 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
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/47F2B9D8.90702@dunslane.net 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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
On Thu, 10 Apr 2008 11:41:51 -0400 Alvaro Herrera <alvherre@commandprompt.com> 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/47F2B9D8.90702@dunslane.net > 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
* Joshua D. Drake <jd@commandprompt.com> [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, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Thu, 10 Apr 2008 11:53:09 -0400 Aidan Van Dyk <aidan@highrise.ca> 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
Joshua D. Drake wrote: > On Thu, 10 Apr 2008 11:17:37 -0400 > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > "Joshua D. Drake" <jd@commandprompt.com> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
"Joshua D. Drake" <jd@commandprompt.com> 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
"Joshua D. Drake" <jd@commandprompt.com> 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'sPostgreSQL training!
On Thu, 10 Apr 2008 12:07:43 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Joshua D. Drake" <jd@commandprompt.com> 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
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera <alvherre@commandprompt.com> 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
Tom Lane wrote: > Alvaro Herrera <alvherre@commandprompt.com> 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 Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
* Joshua D. Drake <jd@commandprompt.com> [080410 11:55]: > On Thu, 10 Apr 2008 11:53:09 -0400 > Aidan Van Dyk <aidan@highrise.ca> 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/find-root.php?message_id=20080410085517.2fa3ec2d@commandprompt.com orhttp://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, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
* Joshua D. Drake <jd@commandprompt.com> [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, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
* Joshua D. Drake <jd@commandprompt.com> [080410 11:30]: > On Thu, 10 Apr 2008 11:15:08 -0400 > Aidan Van Dyk <aidan@highrise.ca> 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, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Joshua D. Drake wrote: > On Thu, 10 Apr 2008 11:15:08 -0400 > Aidan Van Dyk <aidan@highrise.ca> 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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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.
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
jd@commandprompt.com ("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.
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
-----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 <bruce@momjian.us> 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 <bruce@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + - -- Marc G. Fournier Hub.Org Hosting Solutions S.A. (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf+bf8ACgkQ4QvfyHIvDvMp9QCgm8zrjZogg6kzDazAqQLCzpeP WjoAn1+38NJ/+LscZXrUd5PuNoalweVd =7oz2 -----END PGP SIGNATURE-----
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 decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
"Peter Eisentraut" <peter_e@gmx.net> 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!
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Thu, 10 Apr 2008 14:18:52 -0400
Chris Browne <cbbrowne@acm.org> wrote:
> jd@commandprompt.com ("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
On Thu, 10 Apr 2008 12:13:38 -0400 Alvaro Herrera <alvherre@commandprompt.com> 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
On Thu, 10 Apr 2008 16:14:33 -0500 Decibel! <decibel@decibel.org> 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
"Joshua D. Drake" <jd@commandprompt.com> writes: > Yes Alvaro but that doesn't mean the process should be complicated for > the sake of being complicated. This is all utter BS though. The current process is about as simple for a submitter as it could possibly be: 1) If you want to send us a patch mail it to us. 2) For advanced users only: If you want to see our todo list it's over here; feel free to add things to it if you want usto do something like, say, give you feedback or commit your patch. Anything else is *more* complex. It might be justified by how much it would help us keep things organized and so on. But you have to come up with benefits which outweigh the additional complexities, not claim your favourite software is less complex than just keeping a todo list. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
"Joshua D. Drake" <jd@commandprompt.com> writes: > 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. This thread has already consumed far too many cycles. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
Alvaro Herrera wrote: > 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. > > I doubt we have much to learn from the Linux kernel development process, anyway. cheers andrew
On Thu, 10 Apr 2008 23:21:40 +0100 Gregory Stark <stark@enterprisedb.com> wrote: > "Joshua D. Drake" <jd@commandprompt.com> writes: > > > Yes Alvaro but that doesn't mean the process should be complicated > > for the sake of being complicated. > > This is all utter BS though. The current process is about as simple > for a submitter as it could possibly be: *sigh* I am not talking about our submission process. I am talking about our tracking and review process. 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
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.
Gregory Stark wrote: > Yes, if we're just tracking patches or major proposals in a bug tracker. > The hard part is actually deciding that they're closed. I am of the opinion that that will be very easy in practice.
Gregory Stark wrote: > The current process is about as simple for a > submitter as it could possibly be: Yes, but we are not talking about the process for the submitter but the process for the developer.
Gregory Stark wrote: > This thread has already consumed far too many cycles. If you are not interested, please go away and let those of us who are interested work out the details. So far, I've only seen you put down just about every proposal without anything constructive coming from your side. If you have something to add, please do so at some time, but if you are not interested in using a tracker anyway, just don't use it and ignore this thread.
Peter Eisentraut <peter_e@gmx.net> writes:
> If you have something to add, please do so at some time, but if you are not
> interested in using a tracker anyway, just don't use it and ignore this
> thread.
Hmm, well, I can hardly see how anyone could object to a tracker that
they didn't have to use --- that is, one that hadn't been declared to be
the new center of our development process. The push-back that you're
seeing is because just about every proposal for such a tracker has
included somewhere along the line the notion that the email lists will
stop being the primary reference. Making that happen will require
obtaining general consensus, not just telling objectors to go away.
regards, tom lane
On Fri, Apr 11, 2008 at 1:06 AM, Bruce Momjian <bruce@momjian.us> wrote: > 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, sadly, we probably *do* need such an entry in the FAQ. Without meaning any disrespect to Bruce's tremendous efforts, I have had up to 2 months -- months! -- elapse between sending a patch to -patches and getting the standard "your patch is in the queue" email from Bruce. Now that I'm used to the process, I understand that eventually Bruce will trawl the mailing list and queue-ify my email. But you can see that any new submitters are going to wonder what went wrong after a week or two. "Did I send my patch to the wrong place? Is nobody interested in it? What is going on here?" 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. Cheers, BJ
"Brendan Jurd" <direvus@gmail.com> writes:
> 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.
Uh, no, there is a difference between "not acted on instantly" and
"never acted on at all". The Apache docs that were quoted upthread
suggested that they might allow things to fall through the cracks
indefinitely without repeat prodding. That might be (in fact very
likely is) an unfair assessment of their real response habits.
But you are claiming that not getting to a patch right away is as
bad as never getting to it at all. I beg to disagree.
regards, tom lane
On Thu, 10 Apr 2008 22:47:34 -0400 Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > If you have something to add, please do so at some time, but if you > > are not interested in using a tracker anyway, just don't use it and > > ignore this thread. > > Hmm, well, I can hardly see how anyone could object to a tracker that > they didn't have to use --- that is, one that hadn't been declared to > be the new center of our development process. The push-back that > you're seeing is because just about every proposal for such a tracker > has included somewhere along the line the notion that the email lists > will stop being the primary reference. My suggestion wasn't that in the least. 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
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 Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
* Joshua D. Drake <jd@commandprompt.com> [080410 23:20]: > On Thu, 10 Apr 2008 22:47:34 -0400 > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > Peter Eisentraut <peter_e@gmx.net> writes: > > > If you have something to add, please do so at some time, but if you > > > are not interested in using a tracker anyway, just don't use it and > > > ignore this thread. > > > > Hmm, well, I can hardly see how anyone could object to a tracker that > > they didn't have to use --- that is, one that hadn't been declared to > > be the new center of our development process. The push-back that > > you're seeing is because just about every proposal for such a tracker > > has included somewhere along the line the notion that the email lists > > will stop being the primary reference. > > My suggestion wasn't that in the least. Then just do it. Set up your tracker. Subscribe it to the lists. Make it track everything. Manage it. Rub it's belly. And then anybody asking a question about the status of something gives you a pedestal to show how nicely your tracker works. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
Peter Eisentraut wrote: > 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. Yes, that is really another issue --- bug tracking. We have said in the past we don't want a bug tracker, but as you have shown that really does go against how almost all other open source projects are handling bugs. I am a little worried that trying a bug tracker or patch tracker in _addition_ to email tracking is going to be more complex than just choosing one or the other because there is going to be duplication of things happening on different communication channels. As I stated before I am ready to stop visibly doing what I normally do to see if another process will work better. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
On Fri, Apr 11, 2008 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Brendan Jurd" <direvus@gmail.com> writes: > > 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. > > Uh, no, there is a difference between "not acted on instantly" and > "never acted on at all". The Apache docs that were quoted upthread > suggested that they might allow things to fall through the cracks > indefinitely without repeat prodding. That might be (in fact very > likely is) an unfair assessment of their real response habits. > But you are claiming that not getting to a patch right away is as > bad as never getting to it at all. I beg to disagree. > Not really. I'm claiming that, to the submitter, a response that hasn't happened yet and a response that is never coming look pretty much identical. Cheers, BJ
"Brendan Jurd" <direvus@gmail.com> writes:
> Not really. I'm claiming that, to the submitter, a response that
> hasn't happened yet and a response that is never coming look pretty
> much identical.
I understand, but that seems a bit offtopic seeing that this whole
thread is about how to guarantee that we don't actually forget about
any patches or bug reports.
If you want to make the responses faster, then you gotta pony up some
genuine human resources to deal with the problems. Feel free to join
Bruce and me in the trenches.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Apr 11, 2008 at 1:40 PM, Tom Lane wrote: > "Brendan Jurd" writes: > > > Not really. I'm claiming that, to the submitter, a response that > > hasn't happened yet and a response that is never coming look pretty > > much identical. > > I understand, but that seems a bit offtopic seeing that this whole > thread is about how to guarantee that we don't actually forget about > any patches or bug reports. > > If you want to make the responses faster, then you gotta pony up some > genuine human resources to deal with the problems. Feel free to join > Bruce and me in the trenches. > I think we've gotten some wires crossed. We are, in effect, arguing the same point. Upthread (and previously in other threads) I agreed heartily with Heikki's comment that patch submitters should be putting their work in the queue themselves. I've been saying that I would happily add my own patches to the wiki. That *is* contributing human resources to the problem. And it is a simple solution to my complaint above; that it can be a long time before your patch moves into the queue. Anyone who doesn't want to wait for the Bruce Method to take effect can just do it for themselves. Cheers, BJ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFH/uPp5YBsbHkuyV0RAk/9AJsGjLVYpBx9J3zo6P1D8UsWqlS9FQCg1ZVw py7s/5M+KJmkSvAH/osx9tA= =77ab -----END PGP SIGNATURE-----
On Thu, 10 Apr 2008 23:26:28 -0400 Aidan Van Dyk <aidan@highrise.ca> 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
On Thu, 10 Apr 2008 23:23:20 -0400 (EDT) Bruce Momjian <bruce@momjian.us> 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
Joshua D. Drake wrote: > On Thu, 10 Apr 2008 23:23:20 -0400 (EDT) > Bruce Momjian <bruce@momjian.us> 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
On Fri, Apr 11, 2008 at 1:32 PM, Magnus Hagander <magnus@hagander.net> 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/msg00000.php
"Tom Dunstan" <pgsql@tomd.cc> 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!
On Fri, 11 Apr 2008 15:44:43 +0100 Gregory Stark <stark@enterprisedb.com> 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
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 Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Gregory Stark <stark@enterprisedb.com> 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
Tom Lane wrote: > Gregory Stark <stark@enterprisedb.com> 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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
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 <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
(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 <stark@enterprisedb.com> 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
"Tom Lane" <tgl@sss.pgh.pa.us> 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!
> 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 occasions, fall through the cracks. :) Solution 4: Now all new threads will show up in the new items list. If no one ever goes through the list they will still fall through the cracks. But at least there will be a list of items that need to be dealt with. It could also sort them by when they were submitted and even send out a notification if there are items older than x days/ weeks/months. Problem #5: Sometimes people want to be notified when an event happens. Solutions 5: Once we have the tracker going it is trivial to take any even within the system, and send notifications to those who want it and only those who want it. These notifications could contain as much or as little info as you like. All in all the intention here is to build a light wrapper around the email system that adds some needed functions but doesn't mess up anything that is currently working. Being that I am not actually involved in the process it's very likely that there is one or several fatal flaws in this proposal, but I have done my best to address everyone's needs. Hope this is useful, Rick
On Sat, Apr 12, 2008 at 3:13 AM, Gregory Stark <stark@enterprisedb.com> wrote: > "Tom Lane" <tgl@sss.pgh.pa.us> 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
> 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 occasions, fall through the cracks. :) Solution 4: Now all new threads will show up in the new items list. If no one ever goes through the list they will still fall through the cracks. But at least there will be a list of items that need to be dealt with. It could also sort them by when they were submitted and even send out a notification if there are items older than x days/ weeks/months. Problem #5: Sometimes people want to be notified when an event happens. Solutions 5: Once we have the tracker going it is trivial to take any even within the system, and send notifications to those who want it and only those who want it. These notifications could contain as much or as little info as you like. All in all the intention here is to build a light wrapper around the email system that adds some needed functions but doesn't mess up anything that is currently working. Being that I am not actually involved in the process it's very likely that there is one or several fatal flaws in this proposal. I have however followed the thread closely (and other similar threads over the past few years) and tried my best to address everyone's concerns. I have also used all of the other tracking tools (wiki, bruce's pages, etc) for the purpose of keeping myself informed as to what features are being worked on / committed to future releases. In the end, I think the structure of a system like this will end up being much, much easier to maintain than a more general purpose tool such as a wiki, if we can get it right. Hope this is useful, Rick
On Apr 11, 2008, at 9:30 AM, Tom Lane wrote: > Gregory Stark <stark@enterprisedb.com> 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 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 occasions, fall through the cracks. :) Solution 4: Now all new threads will show up in the new items list. If no one ever goes through the list they will still fall through the cracks. But at least there will be a list of items that need to be dealt with. It could also sort them by when they were submitted and even send out a notification if there are items older than x days/ weeks/months. Problem #5: Sometimes people want to be notified when an event happens. Solutions 5: Once we have the tracker going it is trivial to take any even within the system, and send notifications to those who want it and only those who want it. These notifications could contain as much or as little info as you like. All in all the intention here is to build a light wrapper around the email system that adds some needed functions but doesn't mess up anything that is currently working. Being that I am not actually involved in the process it's very likely that there is one or several fatal flaws in this proposal. I have however followed the thread closely (and other similar threads over the past few years) and tried my best to address everyone's concerns. I have also used all of the other tracking tools (wiki, bruce's pages, etc) for the purpose of keeping myself informed as to what features are being worked on / committed to future releases. In the end, I think the structure of a system like this will end up being much, much easier to maintain than a more general purpose tool such as a wiki, if we can get it right. Hope this is useful, Rick
"Brendan Jurd" <direvus@gmail.com> 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!
On Fri, 11 Apr 2008 18:46:18 +0100 Gregory Stark <stark@enterprisedb.com> 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
"Brendan Jurd" <direvus@gmail.com> 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
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
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
On Apr 11, 2008, at 12:54 PM, Tom Lane wrote: > "Brendan Jurd" <direvus@gmail.com> 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 decibel@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
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" <direvus@gmail.com> 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 >
On Sat, Apr 12, 2008 at 3:46 AM, Gregory Stark <stark@enterprisedb.com> 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
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.<br
/><br/>It seems to me that there are two main concerns in this area on discussion:<br /><br />1. How to create a list
ofpatches/review items/etc without adding a significant amount of noise to this list of patches/review items/etc.<br
/><br/>From the discussion so far, it seems obvious that this part needs to be done manually. Any automated system
wouldnot be smart enough to accurately pick the right messages. It would either require the user to remove many
non-listitems or would require the user to manually enter items.<br /><br />2. How to make this newly generated list
availableand easy to work with for those wishing to review. This method would need to (a) remain up to date, (b) easily
modifiedor rearranged, (c) has a significant amount of information about the patch (with attachments), and (d) make
surecomments or changes to the item's status are sent back to the mailing list.<br /><br />This last step is proving
mostdifficult. I'll quickly outline a few of the approaches and then present what I think might be what is needed.<br
/><br/>The original solution had Bruce generating the list by working through his mailbox and marking down the
importante-mails. I suspect that less than 50% of these actually ended up on his list. (please correct me if I'm wrong)
Thiswas awkward for everyone else because there was very little visibility of this list, so it was difficult for others
tosee what they could help with. (concern #2)<br /><br />The next, and current, solution involves someone saving the
listthey generate to a wiki page. This adds work for that person (Bruce, I think) to put it up in a wiki-style format,
butdoes improve visibility of the list. It ends up being a bit more work, but allows more than one person to help,
therebyspeeding up the process. It's still not perfect, as updating is manual (2a), links back to messages don't always
haveenough info (2c) and comments aren't sent back to the list (2d). That being said - it is a big improvement as
visibilityis much better.<br /><br />The third proposed idea is to use some sort of tracker. Ideas proposed were to (*)
addeverything from the mailing list to the tracker and close noise items manually or (**) manually add the specific
itemsof interest. These two approaches have concerns with causing the data to be in yet another location **, with
missingpatches in the process **, or with causing a massive amount of maintenance work *.<br /><br />>Proposed
Idea<<br/><br />It sounds like you need an e-mail controlled list. For example, setup a filter that would create a
trackerentry in response to a specific keyword/keyphrase in an e-mail. The tracker entry could then be modified
entirelythrough a set of e-mailed commands.<br /><br />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.<br /><br />This would allow the user to easily bring up a
listof open patches, or whatever other list they might want.<br /><br />There would, of course, need to be a few
additionalcommands accepted via e-mail, such as commands to change the status, mark tracker items as the same, and mark
trackeritems as addressed, or mark items as related. Also, there should be some limits as to who (e-mail address) is
allowedto modify the tracker items.<br /><br />Let's see how such a system addressed the 2 concerns listed at the start
ofthis mail.<br /><br />1. Items would not be automatically added to the tracker (at least not visibly), so noise would
notbe a problem. It would still require someone to fire off an e-mail to add (un-hide) an e-mail thread in the tracker.
Thisdoes not increase the work required in creating the list, so things are good here. Such an e-mail could also
includeBruce's usual 'patch has been added to the list' message, so this would be very visible and easily trackable.<br
/><br/>2a. The tracker would continue to process new messages from the list, so it would not fall out of date. (unless
anew e-mail thread was started - but this is no worse than you have today)<br />2b. The list could be easily modified
bya large number of people via e-mail or through the web interface (while keeping the e-mail list informed).<br /> 2c.
Thetracker items added would have the entire thread history all in one spot, so it is easy to review.<br />2d. The
trackerwould send comments (not just comment notifications) back to the list so information would not be missing from
thee-mail archives.<br /><br />So, that's the idea. Thoughts? (Or dare I ask!)<br /><br />
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
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
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
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.
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
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