Thread: Commit fest queue

Commit fest queue

From
"Joshua D. Drake"
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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


Re: Commit fest queue

From
Heikki Linnakangas
Date:
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


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Heikki Linnakangas
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Greg Smith
Date:
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


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
"Brendan Jurd"
Date:
-----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-----


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Marc G. Fournier"
Date:
-----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-----



Re: Commit fest queue

From
"Brendan Jurd"
Date:
-----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-----


Re: Commit fest queue

From
"Marc G. Fournier"
Date:
-----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-----



Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Greg Smith
Date:
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


Re: Commit fest queue

From
"Marc G. Fournier"
Date:
-----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-----



Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
"Brendan Jurd"
Date:
-----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-----


Re: Commit fest queue

From
Greg Smith
Date:
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


Re: Commit fest queue

From
paul rivers
Date:
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







Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Stefan Kaltenbrunner
Date:
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


Re: Commit fest queue

From
"Tom Dunstan"
Date:
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


Re: Commit fest queue

From
Stefan Kaltenbrunner
Date:
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


Re: Commit fest queue

From
"Tom Dunstan"
Date:
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


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Stefan Kaltenbrunner
Date:
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


Re: Commit fest queue

From
"Tom Dunstan"
Date:
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


Re: Commit fest queue

From
Alvaro Herrera
Date:
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.


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Andrew Dunstan
Date:

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


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Stefan Kaltenbrunner
Date:
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


Re: Commit fest queue

From
Stefan Kaltenbrunner
Date:
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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Alvaro Herrera
Date:
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.


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Peter Eisentraut
Date:
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>.


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue

From
Aidan Van Dyk
Date:
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.

Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Gregory Stark
Date:
"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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Alvaro Herrera
Date:
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.


Re: Commit fest queue]

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue]

From
Alvaro Herrera
Date:
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.


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue]

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
Gregory Stark
Date:
"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!
 


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Alvaro Herrera
Date:
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.


Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Chris Browne
Date:
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.


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
"Marc G. Fournier"
Date:
-----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-----



Re: Commit fest queue

From
Decibel!
Date:
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



Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Gregory Stark
Date:
"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!
 


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Andrew Dunstan
Date:

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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
"Brendan Jurd"
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Aidan Van Dyk
Date:
* 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.

Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
"Brendan Jurd"
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
"Brendan Jurd"
Date:
-----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-----


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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


Re: Commit fest queue

From
Magnus Hagander
Date:
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


Re: Commit fest queue

From
"Tom Dunstan"
Date:
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


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Alvaro Herrera
Date:
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


Re: Commit fest queue

From
Tom Lane
Date:
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


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
Bruce Momjian
Date:
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. +


Re: Commit fest queue

From
"Tom Dunstan"
Date:
(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


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
Rick Gigger
Date:
> 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



Re: Commit fest queue

From
"Brendan Jurd"
Date:
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


Re: Commit fest queue

From
Rick Gigger
Date:
> 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


Re: Commit fest queue

From
Rick Gigger
Date:
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


Re: Commit fest queue

From
Gregory Stark
Date:
"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!


Re: Commit fest queue

From
"Joshua D. Drake"
Date:
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




Re: Commit fest queue

From
Tom Lane
Date:
"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


Re: Commit fest queue

From
Andrew Dunstan
Date:

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



Re: Commit fest queue

From
Andrew Sullivan
Date:
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



Re: Commit fest queue

From
Decibel!
Date:
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



Re: Commit fest queue

From
Kenneth Marshall
Date:
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
> 


Re: Commit fest queue

From
"Brendan Jurd"
Date:
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


Re: Commit fest queue

From
"Nathan Buchanan"
Date:
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 /> 

Re: Commit fest queue

From
Josh Berkus
Date:
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


Re: Commit fest queue

From
Josh Berkus
Date:
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


Re: Commit fest queue

From
Zdenek Kotala
Date:
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


Re: Commit fest queue

From
Peter Eisentraut
Date:
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.


Re: Commit fest queue

From
Zdenek Kotala
Date:
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


Re: Commit fest queue

From
Bryce Nesbitt
Date:
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