Commit fest queue
Tom lane said over on the concurrent psql thread:
If we do split them then there is going to be some added effort to
maintain the commit fest queue. Bruce has made it pretty clear
that he doesn't want to put in any extra cycles here. So someone
else has to step up to the plate if this is going to work.
Any volunteers out there?
What exactly are we talking about here? It sounds to me as if my
tracman email with modification might work for this. If not, o.k. but
it seems to fit.
http://archives.postgresql.org/pgsql-hackers/2008-04/msg00324.php
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit
"Joshua D. Drake" <jd@commandprompt.com> writes:
Tom lane said over on the concurrent psql thread:
If we do split them then there is going to be some added effort to
maintain the commit fest queue.
What exactly are we talking about here? It sounds to me as if my
tracman email with modification might work for this. If not, o.k. but
it seems to fit.
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
regards, tom lane
On Wed, 09 Apr 2008 00:28:35 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
"Joshua D. Drake" <jd@commandprompt.com> writes:
Tom lane said over on the concurrent psql thread:
If we do split them then there is going to be some added effort to
maintain the commit fest queue.What exactly are we talking about here? It sounds to me as if my
tracman email with modification might work for this. If not, o.k.
but it seems to fit.This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
So you are saying, only one person should do this versus a team of
individuals? That doesn't seem sustainable. Maybe I am misunderstanding
what the root of the problem is and most likely what the requirements
are but either way, there is a tool involved, even if it is vi.
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit
"Joshua D. Drake" <jd@commandprompt.com> writes:
Tom Lane <tgl@sss.pgh.pa.us> wrote:
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
So you are saying, only one person should do this versus a team of
individuals? That doesn't seem sustainable.
Uh, no, I did not say that; and indeed I'd much rather see it done
by a team. My point was that the volunteer(s) need to come first,
and then they get to pick their tools.
regards, tom lane
On Wed, 09 Apr 2008 00:59:03 -0400
Tom Lane <tgl@sss.pgh.pa.us> wrote:
So you are saying, only one person should do this versus a team of
individuals? That doesn't seem sustainable.Uh, no, I did not say that; and indeed I'd much rather see it done
by a team. My point was that the volunteer(s) need to come first,
and then they get to pick their tools.
I would be willing to help but I obviously need a better understanding
of what the requirements are for the queue.
Sincerely,
Joshua D. Drake
--
The PostgreSQL Company since 1997: http://www.commandprompt.com/
PostgreSQL Community Conference: http://www.postgresqlconference.org/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit
Tom Lane wrote:
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best position to know what the status of a patch is. Others can
do it as well of course, in the spirit of a Wiki.
That leaves out most of the discussion threads, potential TODO items
etc. that Bruce collects in the patches queue. Depending on your
viewpoint that's either a good or a bad thing. It's good because it
keeps the patch queue short and relevant; we'll only have patches or
design proposals in the list that are genuinely waiting for review. But
it's bad because good patches from one-off submitters might fall through
the cracks.
That's where I'd love to have Bruce to help. He's good at following up
items and making sure nothing falls through the cracks. I don't mind
what tool he uses for doing that, the mailbox probably is the easiest
for that task. And that's the kind of work that's hard to do as a team.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote:
Tom Lane wrote:
This isn't really about tools. It's about who wants to put in the
day-after-day, year-after-year drudge work to maintain the queue.
Whoever wants to do the work can pick their tools...I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best position to know what the status of a patch is. Others can
do it as well of course, in the spirit of a Wiki.
Does that move us in the direction of the patch tracker? That does
raise the bar for patch submitters, though I would catch any patches
that weren't in the tracker.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Heikki Linnakangas <heikki@enterprisedb.com> writes:
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best position to know what the status of a patch is.
Unfortunately, a lot of submitters are way too optimistic about that ...
it's bad because good patches from one-off submitters might fall through
the cracks.
Exactly. Somebody (or preferably somebodies) has to accept the
responsibility of seeing to it that everything gets onto the commit-fest
page; requiring the authors to do it simply won't work reliably. And
it'd be more work for them anyway --- consider an author who hasn't got
an account on our wiki and/or has never edited a wiki page before.
Somebody who does it every day will certainly be a lot faster.
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
That's where I'd love to have Bruce to help.
Bruce has made it perfectly clear that he doesn't want to take on any
added maintenance work.
regards, tom lane
Tom Lane wrote:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.That's where I'd love to have Bruce to help.
Bruce has made it perfectly clear that he doesn't want to take on any
added maintenance work.
Yea, I would like to reduce the amount of maintenance work I do, not add
to it. Now, you might say that if this works I will have less
maintenance work to do because more people will be doing it, but I will
believe it when I see it.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
* Tom Lane <tgl@sss.pgh.pa.us> [080409 10:40]:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.
I've often been confused that discussion seem to seamlessly be on either
-patches, or -hackers. From the understanding I got on the mailing
list pages (http://archives.postgresql.org/), it seems like -patches is
supposed to be only for patches, and -hackers for the general
discussion, issues, features, etc on anything development related.
But from observation, it seems like -patches and -hackers are different
lists of the same thing, except that -patches has a much bigger message
size limit.
Is that the intended operational status?
If not, would it be possible to some how force reply-to of pg-patches to
-hackers? I know, that blows chunks with the usual mailling-list
reply-to issues, but it would make -hackers the single place to follow
discussions, and maybe make -patches a more pointed "list of things to
track".
Tracking 2 lists really isn't a big deal - I'm guessing most others dump
both -patches and -hackers into the same mailbox anyways too, but it
does seem like the 2 lists are a needless split as they currently are
used.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
Aidan Van Dyk wrote:
-- Start of PGP signed section.
* Tom Lane <tgl@sss.pgh.pa.us> [080409 10:40]:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.I've often been confused that discussion seem to seamlessly be on either
-patches, or -hackers. From the understanding I got on the mailing
list pages (http://archives.postgresql.org/), it seems like -patches is
supposed to be only for patches, and -hackers for the general
discussion, issues, features, etc on anything development related.But from observation, it seems like -patches and -hackers are different
lists of the same thing, except that -patches has a much bigger message
size limit.Is that the intended operational status?
If not, would it be possible to some how force reply-to of pg-patches to
-hackers? I know, that blows chunks with the usual mailling-list
reply-to issues, but it would make -hackers the single place to follow
discussions, and maybe make -patches a more pointed "list of things to
track".Tracking 2 lists really isn't a big deal - I'm guessing most others dump
both -patches and -hackers into the same mailbox anyways too, but it
does seem like the 2 lists are a needless split as they currently are
used.
Yea, the split is kind of odd. I think the idea is that discussion
about patch details happens on 'patches' and more general discussion on
hackers, though it doesn't work that way all the time.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Aidan Van Dyk <aidan@highrise.ca> writes:
I've often been confused that discussion seem to seamlessly be on either
-patches, or -hackers. From the understanding I got on the mailing
list pages (http://archives.postgresql.org/), it seems like -patches is
supposed to be only for patches, and -hackers for the general
discussion, issues, features, etc on anything development related.
That's the theory.
But from observation, it seems like -patches and -hackers are different
lists of the same thing, except that -patches has a much bigger message
size limit.
Practice is often different from theory ;-). I don't mind discussion
about a patch on -patches, as long as it's not getting into major design
decisions --- if it does, then the thread should get moved to -hackers,
though that doesn't always happen.
If not, would it be possible to some how force reply-to of pg-patches to
-hackers?
No, we aren't going to do that. It wouldn't work anyway; you can't
force people to send messages to one list rather than another, and
the mail list software is surely not bright enough to distinguish
"patch" from "not a patch" on its own.
regards, tom lane
"Tom Lane" <tgl@sss.pgh.pa.us> writes:
If not, would it be possible to some how force reply-to of pg-patches to
-hackers?No, we aren't going to do that. It wouldn't work anyway; you can't
force people to send messages to one list rather than another, and
the mail list software is surely not bright enough to distinguish
"patch" from "not a patch" on its own.
I did suggest something a while back that I think died for because too many
other things were changing at the same time. Perhaps would be more practical
with the current infrastructure. I suggested eliminating pgsql-patches as a
separate mailing list for people to send mail to.
Instead you could subscribe to a version of pgsql-hackers which automatically
had large attachments removed and replaced with a link to the file on a web
page.
So all followups would be on -hackers because they would follow the headers on
the original message. The only place the -noattachments list would show up
would be buried in the Received headers.
I could help make a perl script to do the message munging but this assumes
there's a way to hook it into the mail server and get the files to the web
server. I'm not familiar with the infrastructure so I don't know how
accessible these things are to each other.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
"Bruce Momjian" <bruce@momjian.us> writes:
I still think it would be best if the patch authors did the work. They
are the ones who care about the patch and want the review, and they're
in the best position to know what the status of a patch is. Others can
do it as well of course, in the spirit of a Wiki.Does that move us in the direction of the patch tracker? That does
raise the bar for patch submitters, though I would catch any patches
that weren't in the tracker.
Not really, whatever tool it's in the hard part is reading the emails and
deciding what to do with them.
What would move us in the direction of this mythical "patch tracker" would be
if we knew exactly what our workflow was. Once we know what our workflow is
then we could pick a tool which enforces that workflow.
That's the whole point of a special purpose tool for things like this,
enforcing that all the ts are crossed, is dotted, and all procedures followed.
Eg, requiring that the "Patch status" field be filled in or that two reviewers
don't grab the same patch.
What a request tracker does *not* do is magically make decisions for us. We
still have to review the patches, we still have to make technical decisions.
Patches which are too hard to wrap our head around would still sit there until
someone stands up and applies or rejects it. (Anyone who's reported a Mozilla
bug in the past 8 years might know what such a tracker looks like...)
Frankly until we decide what our workflow is and what information we want to
track I don't see why -- or even how -- we would pick a tool to track it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
Gregory Stark <stark@enterprisedb.com> writes:
What would move us in the direction of this mythical "patch tracker" would be
if we knew exactly what our workflow was. Once we know what our workflow is
then we could pick a tool which enforces that workflow.
Well, I don't think we want or need an "enforced" workflow. What we
need is just a list of pending patches so that nothing falls through the
cracks. As you say, most of the work is in recognizing which emails
deserve to be entered into the list, and that's not subject to
automation (not in this decade anyway).
regards, tom lane
Bruce Momjian wrote:
Tom Lane wrote:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.That's where I'd love to have Bruce to help.
Bruce has made it perfectly clear that he doesn't want to take on any
added maintenance work.Yea, I would like to reduce the amount of maintenance work I do, not add
to it. Now, you might say that if this works I will have less
maintenance work to do because more people will be doing it, but I will
believe it when I see it.
Ok. In that case I'd suggest that we do roughly the same thing we did
this commit fest. You, Bruce, collect all the relevant threads into the
patch queue as before, and at the beginning of commit fest someone else
goes through that list and puts the threads that have a commit-fest
worthy patch or design proposal in them to the Wiki (thanks Alvaro for
doing that in this fest!). Then we can use the Wiki page as the official
list during the commit fest.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Gregory Stark <stark@enterprisedb.com> writes:
I suggested eliminating pgsql-patches as a
separate mailing list for people to send mail to.
Instead you could subscribe to a version of pgsql-hackers which automatically
had large attachments removed and replaced with a link to the file on a web
page.
Interesting thought. I dunno how implementable it is either, but it
definitely would help to cut down fragmentation of discussions.
regards, tom lane
On Wed, 9 Apr 2008, Tom Lane wrote:
Gregory Stark <stark@enterprisedb.com> writes:
What would move us in the direction of this mythical "patch tracker" would be
if we knew exactly what our workflow was. Once we know what our workflow is
then we could pick a tool which enforces that workflow.Well, I don't think we want or need an "enforced" workflow. What we
need is just a list of pending patches so that nothing falls through the
cracks.
Making sure nothing falls through the cracks is exactly the point of an
enforced workflow. It might be a manual operation, it might be some piece
of software, but ultimately you need a well-defined process where things
move around but don't get dropped. Exactly how said enforcement happens
is certainly open to discussion though.
Last time I chimed in on this subject I tried unsuccessfully to move
discussion into this area--trying to nail down the structure of a patch
processing workflow--but all I managed to do was kick off was a discussion
of the trivia involved with one step. A better attempt is below.
As you say, most of the work is in recognizing which emails deserve to
be entered into the list, and that's not subject to automation (not in
this decade anyway).
Sure, but that can still be an input to the workflow.
Since I'm unphased by criticism and have been watching this whole 'Fest
fairly closely, I'll even throw out a sample for a more formal workflow
outline. Always easier to map this stuff out when you've got a dummy
proposal to beat up. This is aimed to look somewhat like what happened
this time around (except using the newer tools that are basically built
now) rather than to be a more grand vision:
Input: submissions to -patches and -hackers
Processing: Saved via mail reader software
Output: mbox file with relevant items
Person: Bruce
Input: mbox file
Processing: Run script
Output: Patch queue detail wiki page, with links to the archives
Person: Greg Stark via his script
Input: Patch queue detail
Processing: Manually editing page, perhaps with some tool assistance
Output: Patch queue summary wiki page
Person: Alvaro
Input: Patch queue summary
Processing: Patch committed, removed from page
Output: Updated patch queue summary, e-mail to author
Person: Tom, Bruce, other committers
Input: Patch queue summary
Processing: Patch changed to be a TODO item
Output: Expanded TODO list, updated patch queue summary, e-mail to author
Person: Bruce
Input: Patch queue summary
Processing: Patch rejected or bounced back with comments
Output: Reduced patch queue summary, e-mail to author
Person: Bruce
There's a clear hole for messages to fall into when they're being
summarized into the patch summary step, I recall Tom saying something
about items that didn't make it into the current summary. That needs to
be improved a bit. I also note that I didn't diagram separate review
steps because I didn't see them happen in a formal way this time around
that I could use as a model.
As a sideline observer here it seems to me that Bruce has a good and hard
to replace process to kick this all off already going, so don't mess with
that. It would be nice to find vict...err, volunteers to pull him out of
the later steps though for a net reduction in his time. Simply getting
things organized better from the start should help with getting more
people helping out with review; the common complaint seemed to be "I can't
figure out what to help with in this big mess" which having a summary from
the start should improve.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Greg Smith wrote:
Making sure nothing falls through the cracks is exactly the point of an
enforced workflow. It might be a manual operation, it might be some piece
of software, but ultimately you need a well-defined process where things
move around but don't get dropped. Exactly how said enforcement happens
is certainly open to discussion though.
As a volunteer organization we don't have much enforcement control. We
can control what we do, but not require others to do anything. This
makes trying to enforce uniform behavior difficult. Companies have a
much easier time with enforcement because there is a paycheck attached
to it.
As a sideline observer here it seems to me that Bruce has a good and hard
to replace process to kick this all off already going, so don't mess with
that. It would be nice to find vict...err, volunteers to pull him out of
the later steps though for a net reduction in his time. Simply getting
things organized better from the start should help with getting more
people helping out with review; the common complaint seemed to be "I can't
figure out what to help with in this big mess" which having a summary from
the start should improve.
And when we did whittle it down to a short list there were still very
few people helping.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Heikki Linnakangas wrote:
Bruce Momjian wrote:
Tom Lane wrote:
This doesn't seem particularly hard, just a matter of following the
relevant mailing lists (mostly -patches, but various offenders send
patches elsewhere) and adding links to the current wiki page.That's where I'd love to have Bruce to help.
Bruce has made it perfectly clear that he doesn't want to take on any
added maintenance work.Yea, I would like to reduce the amount of maintenance work I do, not add
to it. Now, you might say that if this works I will have less
maintenance work to do because more people will be doing it, but I will
believe it when I see it.Ok. In that case I'd suggest that we do roughly the same thing we did
this commit fest. You, Bruce, collect all the relevant threads into the
patch queue as before, and at the beginning of commit fest someone else
goes through that list and puts the threads that have a commit-fest
worthy patch or design proposal in them to the Wiki (thanks Alvaro for
doing that in this fest!). Then we can use the Wiki page as the official
list during the commit fest.
Fine with me, but I was hoping someone would come up with an idea that
would reduce what I need to do, like perhaps a new vacuum cleaner. ;-)
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
