Thread: Last gasp
These patches aren't marked with a committer FK arrays ECPG fetch foreign stats command triggers check function parallel pg_dump Does that mean myself or others should be claiming them for commit/reject? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > These patches aren't marked with a committer > > FK arrays > ECPG fetch > foreign stats > command triggers > check function > parallel pg_dump > > Does that mean myself or others should be claiming them for commit/reject? I've been right in the middle of the command triggers stuff, so I suppose I would pick that up for commit if it were ready, but there hasn't been a new version this week unless I've missed it, and even if the new version arrived right this minute, I don't think I or anyone else can do a good job committing a patch of that size in the time remaining. So I think it's time to formally put that one out of its misery. I think the ECPG fetch patch is about ready to go. Normally Michael Meskes handles all ECPG patches, but I'm not sure what his schedule is like. I'm not sure what the politics are of someone else touching that code. Heikki recently produced a revision of the check function patch, but I'm not sure whether he's planning to commit that or whether it's a demonstration of a broader rework he wants Pavel (or someone else) to do. At any rate, I think it's up to him whether or not to commit that. I think Andrew is working on parallel pg_dump, so I suspect the rest of us should stay out of the way. I've also looked at it extensively and will work on it if Andrew isn't, but I don't think it's ready to commit. A few preliminary pieces could go in, perhaps. I am not sure what the state of the foreign stats patch is, or FK arrays. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 05.04.2012 21:00, Robert Haas wrote: > Heikki recently produced a revision of the check function patch, but > I'm not sure whether he's planning to commit that or whether it's a > demonstration of a broader rework he wants Pavel (or someone else) to > do. At any rate, I think it's up to him whether or not to commit > that. Yeah, I guess it's up to me, now that I've touched that code. I don't feel ready to commit it yet. It needs some more cleanup, which I could do, but frankly even with the refactoring I did I'm still not totally happy with the way it works. I feel that there ought to be a less duplicative approach, but I don't have any more concrete proposals. Unless someone more motivated picks up the patch now, I think it needs to be pushed to 9.3. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> These patches aren't marked with a committer
> I think the ECPG fetch patch is about ready to go. Normally Michael
> Meskes handles all ECPG patches, but I'm not sure what his schedule is
> like. I'm not sure what the politics are of someone else touching
> that code.
I think we should leave that one for Michael. Frankly, none of the
rest of us pay enough attention to ecpg to be candidates to take
responsibility for nontrivial patches there.
In fact, for *most* of these patches the fact that they're still here
should give you pause about just committing them.
> I am not sure what the state of the foreign stats patch is, or FK arrays.
I'm taking the foreign stats one; as I mentioned a bit ago, I think we
need to push an FDW ANALYZE hook into 9.2. I don't like the details of
what's in the current submission but I think it's fixable with not much
effort.
The FK arrays one I'm kind of queasy about. It's a cool-sounding idea
but I'm not convinced that all the corner-case details have been
adequately thought through, and I'm scared of being unable to fix any
such bugs in later versions because of backwards compatibility worries.
It'd be a lot better to be pushing this in at the start of a devel cycle
than the end.
Most of the rest of this stuff I'm about ready to put off to 9.3.
The risk/reward ratio for committing it on the last day of the last
9.2 fest doesn't look good.
regards, tom lane
On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> These patches aren't marked with a committer >> >> FK arrays >> ECPG fetch >> foreign stats >> command triggers >> check function >> parallel pg_dump >> >> Does that mean myself or others should be claiming them for commit/reject? > > I've been right in the middle of the command triggers stuff, so I > suppose I would pick that up for commit if it were ready, but there > hasn't been a new version this week unless I've missed it, and even if > the new version arrived right this minute, I don't think I or anyone > else can do a good job committing a patch of that size in the time > remaining. So I think it's time to formally put that one out of its > misery. I think doing so will cause substantial misery for many users. I find it hard to believe that such a simple concept hasn't managed to produce some workable subset after months of work. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> These patches aren't marked with a committer >>> >>> FK arrays >>> ECPG fetch >>> foreign stats >>> command triggers >>> check function >>> parallel pg_dump >>> >>> Does that mean myself or others should be claiming them for commit/reject? >> >> I've been right in the middle of the command triggers stuff, so I >> suppose I would pick that up for commit if it were ready, but there >> hasn't been a new version this week unless I've missed it, and even if >> the new version arrived right this minute, I don't think I or anyone >> else can do a good job committing a patch of that size in the time >> remaining. So I think it's time to formally put that one out of its >> misery. > > I think doing so will cause substantial misery for many users. I find > it hard to believe that such a simple concept hasn't managed to > produce some workable subset after months of work. I am not interested in relitigating on this thread what has already been extensively discussed nearby. Dimitri and I agreed on numerous changes to try to make the behavior sane, and those changes were suggested and agreed to for good reason. We didn't agree on every point, of course, but we did agree on most of it, and there is no patch that implements what was agreed. Even if there were, there is not time to review and commit a heavily revised version of a >1000 line patch before tomorrow, and any suggestion to the contrary is just plain wrong. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2012/4/5 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>: > On 05.04.2012 21:00, Robert Haas wrote: >> >> Heikki recently produced a revision of the check function patch, but >> I'm not sure whether he's planning to commit that or whether it's a >> demonstration of a broader rework he wants Pavel (or someone else) to >> do. At any rate, I think it's up to him whether or not to commit >> that. > > > Yeah, I guess it's up to me, now that I've touched that code. I don't feel > ready to commit it yet. It needs some more cleanup, which I could do, but > frankly even with the refactoring I did I'm still not totally happy with the > way it works. I feel that there ought to be a less duplicative approach, but > I don't have any more concrete proposals. Unless someone more motivated > picks up the patch now, I think it needs to be pushed to 9.3. I played with more general plpgpsm walker, but I am sure, so it is wrong way - request for checking and dumping, and releasing plans are too different. So there are not too much possibilities :( The main issue is in design of exec nodes. I have no idea how to move checking to there without increasing complexity in pl_exec.c. Some are relative simply, but "case", "if", "block" are not. Other idea is moving plpgsql_check_function to contrib. Regards Pavel > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com t
On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In fact, for *most* of these patches the fact that they're still here > should give you pause about just committing them. Um, yeah. >> I am not sure what the state of the foreign stats patch is, or FK arrays. > > I'm taking the foreign stats one; as I mentioned a bit ago, I think we > need to push an FDW ANALYZE hook into 9.2. I don't like the details of > what's in the current submission but I think it's fixable with not much > effort. Cool. > The FK arrays one I'm kind of queasy about. It's a cool-sounding idea > but I'm not convinced that all the corner-case details have been > adequately thought through, and I'm scared of being unable to fix any > such bugs in later versions because of backwards compatibility worries. > It'd be a lot better to be pushing this in at the start of a devel cycle > than the end. I've been feeling that that patch has been suffering from a lack of reviewer attention, which is a real shame, because I think the functionality is indeed really cool. But I haven't looked at it enough to know what kind of shape it's in. > Most of the rest of this stuff I'm about ready to put off to 9.3. > The risk/reward ratio for committing it on the last day of the last > 9.2 fest doesn't look good. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Simon Riggs's message of jue abr 05 14:28:54 -0300 2012: > These patches aren't marked with a committer > > FK arrays > ECPG fetch > foreign stats > command triggers > check function > parallel pg_dump > > Does that mean myself or others should be claiming them for commit/reject? The FK locking patch isn't on this list; however, I'm hijacking this thread to say that some benchmarking runs we tried weren't all that great, showing 9% performance degradation on stock pgbench -- i.e. a large hit that will harm everybody even if they are not using FKs at all. I'm thus setting the patch returned with feedback, which is sure to make several hackers happy and tons of users unhappy. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Thu, Apr 5, 2012 at 7:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > The FK arrays one I'm kind of queasy about. It's a cool-sounding idea > but I'm not convinced that all the corner-case details have been > adequately thought through, and I'm scared of being unable to fix any > such bugs in later versions because of backwards compatibility worries. > It'd be a lot better to be pushing this in at the start of a devel cycle > than the end. OK, that's clear. I would have taken it, but not now. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Apr 5, 2012 at 2:37 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > The FK locking patch isn't on this list; however, I'm hijacking this > thread to say that some benchmarking runs we tried weren't all that > great, showing 9% performance degradation on stock pgbench -- i.e. a > large hit that will harm everybody even if they are not using FKs at > all. I'm thus setting the patch returned with feedback, which is sure > to make several hackers happy and tons of users unhappy. Ouch! That's a real bummer. It makes me glad that you tested it, but I can't say I'm happy about the outcome. Did you get in any insight into where the regression is coming from? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 5, 2012 at 7:37 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > The FK locking patch isn't on this list; We'd agreed you were the assigned committer, hence not on list. > however, I'm hijacking this > thread to say that some benchmarking runs we tried weren't all that > great, showing 9% performance degradation on stock pgbench -- i.e. a > large hit that will harm everybody even if they are not using FKs at > all. I'm thus setting the patch returned with feedback, which is sure > to make several hackers happy and tons of users unhappy. I've done what I can to alter that, but I think its the right decision at this point. I would say its been the largest and most subtle patch submitted, so please don't be down by that. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote: > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > On Thu, Apr 5, 2012 at 7:00 PM, Robert Haas <robertmhaas@gmail.com> wrote: > >> On Thu, Apr 5, 2012 at 1:28 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > >>> These patches aren't marked with a committer > >>> > >>> FK arrays > >>> ECPG fetch > >>> foreign stats > >>> command triggers > >>> check function > >>> parallel pg_dump > >>> > >>> Does that mean myself or others should be claiming them for commit/reject? > >> > >> I've been right in the middle of the command triggers stuff, so I > >> suppose I would pick that up for commit if it were ready, but there > >> hasn't been a new version this week unless I've missed it, and even if > >> the new version arrived right this minute, I don't think I or anyone > >> else can do a good job committing a patch of that size in the time > >> remaining. So I think it's time to formally put that one out of its > >> misery. > > > > I think doing so will cause substantial misery for many users. I find > > it hard to believe that such a simple concept hasn't managed to > > produce some workable subset after months of work. > > I am not interested in relitigating on this thread what has already > been extensively discussed nearby. Dimitri and I agreed on numerous > changes to try to make the behavior sane, To me it looked like the scope of the patch started to suddenly expand exponentially a few days ago from a simple COMMAND TRIGGERS, which would have finally enabled trigger-based or "logical" replication systems to do full replication to something recursive which would attempt to cover all weird combinations of commands triggering other commands for which there is no real use-case in view, except a suggestion "don't do it" :) The latest patch (v18) seemed quite ok for its original intended purpose. > and those changes were > suggested and agreed to for good reason. We didn't agree on every > point, of course, but we did agree on most of it, and there is no > patch that implements what was agreed. Even if there were, there is > not time to review and commit a heavily revised version of a >1000 > line patch before tomorrow, and any suggestion to the contrary is just > plain wrong. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
On Thu, Apr 05, 2012 at 02:23:03PM -0400, Tom Lane wrote: > > I think the ECPG fetch patch is about ready to go. Normally Michael > > Meskes handles all ECPG patches, but I'm not sure what his schedule is > > like. I'm not sure what the politics are of someone else touching > > that code. > > I think we should leave that one for Michael. Frankly, none of the > rest of us pay enough attention to ecpg to be candidates to take > responsibility for nontrivial patches there. I will take care of this over the next couple days. Is the patch that Zoltan send last Friday the latest version? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote: > On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote: > > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote: ... > > > I think doing so will cause substantial misery for many users. I find > > > it hard to believe that such a simple concept hasn't managed to > > > produce some workable subset after months of work. > > > > I am not interested in relitigating on this thread what has already > > been extensively discussed nearby. Dimitri and I agreed on numerous > > changes to try to make the behavior sane, > > To me it looked like the scope of the patch started to suddenly expand > exponentially a few days ago from a simple COMMAND TRIGGERS, which would > have finally enabled trigger-based or "logical" replication systems to > do full replication to something recursive which would attempt to cover > all weird combinations of commands triggering other commands for which > there is no real use-case in view, except a suggestion "don't do it" :) > > The latest patch (v18) seemed quite ok for its original intended > purpose. Sorry, i hit "send!" too early. Would it be possible to put some "command trigger hooks" in a few strategic places so that some trigger-like functionality could be loaded at run time, mainly with a view of writing DDL replication 'non-triggers' , mostly based on current v18 code, but of course without all the nice CREATE TRIGGER syntax ? perhaps created with a pg_create_command_trigger(...) that is something in the line of how Full Text Indexing was done for a long time. > > and those changes were > > suggested and agreed to for good reason. We didn't agree on every > > point, of course, but we did agree on most of it, and there is no > > patch that implements what was agreed. Even if there were, there is > > not time to review and commit a heavily revised version of a >1000 > > line patch before tomorrow, and any suggestion to the contrary is just > > plain wrong. > > > > -- > > Robert Haas > > EnterpriseDB: http://www.enterprisedb.com > > The Enterprise PostgreSQL Company > > > > >
On 04/05/2012 02:00 PM, Robert Haas wrote: > I think Andrew is working on parallel pg_dump, so I suspect the rest > of us should stay out of the way. I've also looked at it extensively > and will work on it if Andrew isn't, but I don't think it's ready to > commit. A few preliminary pieces could go in, perhaps. I am working on it when I get time, but I am slammed. It would probably take me a couple of full days to do a thorough code review, and finding that is hard. cheers andrew
On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing <hannu@krosing.net> wrote: > To me it looked like the scope of the patch started to suddenly expand > exponentially a few days ago from a simple COMMAND TRIGGERS, which would > have finally enabled trigger-based or "logical" replication systems to > do full replication to something recursive which would attempt to cover > all weird combinations of commands triggering other commands for which > there is no real use-case in view, except a suggestion "don't do it" :) > > The latest patch (v18) seemed quite ok for its original intended > purpose. OK, so here we go, rehashing the discussion we already had on thread A on thread B. The particular issue you are mentioning there was not the reason that patch isn't going to end up in 9.2. If the only thing the patch had needed was a little renaming and syntax cleanup, I would have done it myself (or Dimitri would have) and I would have committed it. That is not the problem, or at least it's not the only problem. There are at least two other major issues: - The patch as posted fires triggers at unpredictable times depending on which command you're executing. Some things that are really sub-commands fire triggers anyway as if they were toplevel commands; others don't; whether or not it happens in a particular case is determined by implementation details rather than by any consistent principle of operation. In the cases where triggers do fire, they don't always fire at the same place in the execution sequence. - The patch isn't safe if the triggers try to execute DDL on the object being modified. It's not exactly clear what misbehavior will result in every case, but it is clear that that it hasn't really been thought about. Now, if anyone who was actually following the conversation thought these things were not problems, they could have written back to the relevant thread and said, hey, I don't mind if the trigger firing behavior changes every time someone does any refactoring of our badly-written DDL code and if the server blows up in random ways when someone does something unexpected in the trigger that's OK with me too. Maybe not surprisingly, no one said that. Two people wrote into that thread after my latest round of reviewing and both of them disagreed with only minor points of my review, and we had a technical discussion about those issues. But showing up after the fact and acting as if there were no serious issues found during that review is either disingenuous or a sign that you didn't really read the thread. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing <hannu@krosing.net> wrote: > On Thu, 2012-04-05 at 20:46 +0200, Hannu Krosing wrote: >> On Thu, 2012-04-05 at 14:27 -0400, Robert Haas wrote: >> > On Thu, Apr 5, 2012 at 2:17 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > > ... >> > > I think doing so will cause substantial misery for many users. I find >> > > it hard to believe that such a simple concept hasn't managed to >> > > produce some workable subset after months of work. >> > >> > I am not interested in relitigating on this thread what has already >> > been extensively discussed nearby. Dimitri and I agreed on numerous >> > changes to try to make the behavior sane, >> >> To me it looked like the scope of the patch started to suddenly expand >> exponentially a few days ago from a simple COMMAND TRIGGERS, which would >> have finally enabled trigger-based or "logical" replication systems to >> do full replication to something recursive which would attempt to cover >> all weird combinations of commands triggering other commands for which >> there is no real use-case in view, except a suggestion "don't do it" :) >> >> The latest patch (v18) seemed quite ok for its original intended >> purpose. > > Sorry, i hit "send!" too early. > > Would it be possible to put some "command trigger hooks" in a few > strategic places so that some trigger-like functionality could be loaded > at run time, mainly with a view of writing DDL replication > 'non-triggers' , mostly based on current v18 code, but of course without > all the nice CREATE TRIGGER syntax ? I certainly think that would be a possible way forward, but I don't think we should try to engineer that in the next 24 hours. Had the original goals of the patch been somewhat more modest, I think we could have gotten it into 9.2, but there's no time to rethink the scope of the patch now. With all respect for Dimitri and his *very* hard work on this subject, submitting a brand new major feature to the last CommitFest is not really a great way to get it committed, especially given that we didn't have consensus on the design before he started coding. There is every reason to think that we can get this feature into 9.3 with some more work, but it's not ready yet, and wishing won't make it so. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Robert Haas's message of jue abr 05 15:40:17 -0300 2012: > > On Thu, Apr 5, 2012 at 2:37 PM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: > > The FK locking patch isn't on this list; however, I'm hijacking this > > thread to say that some benchmarking runs we tried weren't all that > > great, showing 9% performance degradation on stock pgbench -- i.e. a > > large hit that will harm everybody even if they are not using FKs at > > all. I'm thus setting the patch returned with feedback, which is sure > > to make several hackers happy and tons of users unhappy. > > Ouch! That's a real bummer. It makes me glad that you tested it, but > I can't say I'm happy about the outcome. Did you get in any insight > into where the regression is coming from? Not really -- after reaching that conclusion I dropped immediate work on the patch to do other stuff (like checking whether there's any other patch I can help with in commitfest). I will resume work later, for a (hopefully early) 9.3 submission. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Thu, 2012-04-05 at 15:02 -0400, Robert Haas wrote: > On Thu, Apr 5, 2012 at 2:46 PM, Hannu Krosing <hannu@krosing.net> wrote: > > To me it looked like the scope of the patch started to suddenly expand > > exponentially a few days ago from a simple COMMAND TRIGGERS, which would > > have finally enabled trigger-based or "logical" replication systems to > > do full replication to something recursive which would attempt to cover > > all weird combinations of commands triggering other commands for which > > there is no real use-case in view, except a suggestion "don't do it" :) > > > > The latest patch (v18) seemed quite ok for its original intended > > purpose. > > OK, so here we go, rehashing the discussion we already had on thread A > on thread B. The particular issue you are mentioning there was not > the reason that patch isn't going to end up in 9.2. If the only thing > the patch had needed was a little renaming and syntax cleanup, I would > have done it myself (or Dimitri would have) and I would have committed > it. That is not the problem, or at least it's not the only problem. > There are at least two other major issues: > > - The patch as posted fires triggers at unpredictable times depending > on which command you're executing. Some things that are really > sub-commands fire triggers anyway as if they were toplevel commands; > others don't; whether or not it happens in a particular case is > determined by implementation details rather than by any consistent > principle of operation. In the cases where triggers do fire, they > don't always fire at the same place in the execution sequence. For me it would be enough to know if the trigger is fired by top-level command or not. In worst case I could probably detect it myself, just give me something to hang the detection code to . > - The patch isn't safe if the triggers try to execute DDL on the > object being modified. It's not exactly clear what misbehavior will > result in every case, but it is clear that that it hasn't really been > thought about. It never seemed important for me, as the only thing I was ever expecting to do in a command trigger was inserting rows in one unrelated table. To me DDL-triggered-by-DDL seemed like a very bad idea anyway. But as you seemed to be envisioning some use-cases for that I did not object to you working it out. > Now, if anyone who was actually following the conversation thought > these things were not problems, they could have written back to the > relevant thread and said, hey, I don't mind if the trigger firing > behavior changes every time someone does any refactoring of our > badly-written DDL code and if the server blows up in random ways when > someone does something unexpected in the trigger that's OK with me > too. I don't mind if the trigger firing behavior changes every time someone does any refactoring of our badly-written DDL code Here :) > Maybe not surprisingly, no one said that. Two people wrote into > that thread after my latest round of reviewing and both of them > disagreed with only minor points of my review, and we had a technical > discussion about those issues. But showing up after the fact and > acting as if there were no serious issues found during that review is > either disingenuous or a sign that you didn't really read the thread. As there are other ways to blow up the backend, i did not object to you either working out a better solution or leaving it as it is. I am speaking up now as this is the first time I am told I have to wait another year for this feature to arrive. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
On Thu, 2012-04-05 at 15:07 -0400, Robert Haas wrote: > On Thu, Apr 5, 2012 at 2:58 PM, Hannu Krosing <hannu@krosing.net> wrote: > > > Would it be possible to put some "command trigger hooks" in a few > > strategic places so that some trigger-like functionality could be loaded > > at run time, mainly with a view of writing DDL replication > > 'non-triggers' , mostly based on current v18 code, but of course without > > all the nice CREATE TRIGGER syntax ? > > I certainly think that would be a possible way forward, but I don't > think we should try to engineer that in the next 24 hours. Why not ? If they are in wrong places, they just wont work, when they are in right places, we ca get (kind of) command triggers. We have had hooks for DTrace for some time and nobody has complained . If somebody misuses the command trigger hooks, it is his fault not core developers > Had the > original goals of the patch been somewhat more modest, I think we > could have gotten it into 9.2, but there's no time to rethink the > scope of the patch now. With all respect for Dimitri and his *very* > hard work on this subject, submitting a brand new major feature to the > last CommitFest is not really a great way to get it committed, > especially given that we didn't have consensus on the design before he > started coding. I guess it grew into a mayor feature because the few earlier attempts at DDL triggers (or begin/commit/abort triggers etc.) were shot down because they did not address the "other" issues of the bigger scope ;) > There is every reason to think that we can get this > feature into 9.3 with some more work, but it's not ready yet, and > wishing won't make it so. Sad but true. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing <hannu@krosing.net> wrote: > For me it would be enough to know if the trigger is fired by top-level > command or not. Well, you would have been out of luck, then. >> - The patch isn't safe if the triggers try to execute DDL on the >> object being modified. It's not exactly clear what misbehavior will >> result in every case, but it is clear that that it hasn't really been >> thought about. > > It never seemed important for me, as the only thing I was ever expecting > to do in a command trigger was inserting rows in one unrelated table. > > To me DDL-triggered-by-DDL seemed like a very bad idea anyway. > > But as you seemed to be envisioning some use-cases for that I did not > object to you working it out. Whether or not it works is one thing. I think it's acceptable for it to not do anything useful, although actually I think that given a week to work on it I could make it to completely safe. I don't think it's acceptable for it to, say, corrupt the system catalog contents. >> Now, if anyone who was actually following the conversation thought >> these things were not problems, they could have written back to the >> relevant thread and said, hey, I don't mind if the trigger firing >> behavior changes every time someone does any refactoring of our >> badly-written DDL code and if the server blows up in random ways when >> someone does something unexpected in the trigger that's OK with me >> too. > > I don't mind if the trigger firing behavior changes every time someone > does any refactoring of our badly-written DDL code > > Here :) Duly noted, but color me unconvinced. >> Maybe not surprisingly, no one said that. Two people wrote into >> that thread after my latest round of reviewing and both of them >> disagreed with only minor points of my review, and we had a technical >> discussion about those issues. But showing up after the fact and >> acting as if there were no serious issues found during that review is >> either disingenuous or a sign that you didn't really read the thread. > > As there are other ways to blow up the backend, i did not object to you > either working out a better solution or leaving it as it is. > > I am speaking up now as this is the first time I am told I have to wait > another year for this feature to arrive. Really? You've never seen a patch punted to the next release before because it wasn't robust enough? Considering that I see your name mentioned in the 8.2 release notes, I find that a bit hard to believe. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote: > On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing <hannu@krosing.net> wrote: > > For me it would be enough to know if the trigger is fired by top-level > > command or not. > > Well, you would have been out of luck, then. It seemed to me you were coming along nicely with fixing that by adding the "toplevel", except that the disussion drifted away to solving some bigger problems of DDL triggering DDL. > >> - The patch isn't safe if the triggers try to execute DDL on the > >> object being modified. It's not exactly clear what misbehavior will > >> result in every case, but it is clear that that it hasn't really been > >> thought about. > > > > It never seemed important for me, as the only thing I was ever expecting > > to do in a command trigger was inserting rows in one unrelated table. > > > > To me DDL-triggered-by-DDL seemed like a very bad idea anyway. > > > > But as you seemed to be envisioning some use-cases for that I did not > > object to you working it out. > > Whether or not it works is one thing. I think it's acceptable for it > to not do anything useful, although actually I think that given a week > to work on it I could make it to completely safe. Due to fractal nature of programming problems I doubt the "completely safe" part ;) You (or someone else) would have found a next obscure set of conditions where specially crafted function and/or schema could wreak havoc somewhere. > I don't think it's > acceptable for it to, say, corrupt the system catalog contents. Sure, but any C function can do that already, and we have had C UDF-s from the start. > >> Now, if anyone who was actually following the conversation thought > >> these things were not problems, they could have written back to the > >> relevant thread and said, hey, I don't mind if the trigger firing > >> behavior changes every time someone does any refactoring of our > >> badly-written DDL code and if the server blows up in random ways when > >> someone does something unexpected in the trigger that's OK with me > >> too. > > > > I don't mind if the trigger firing behavior changes every time someone > > does any refactoring of our badly-written DDL code > > > > Here :) > > Duly noted, but color me unconvinced. I can say it again :) > >> Maybe not surprisingly, no one said that. Two people wrote into > >> that thread after my latest round of reviewing and both of them > >> disagreed with only minor points of my review, and we had a technical > >> discussion about those issues. But showing up after the fact and > >> acting as if there were no serious issues found during that review is > >> either disingenuous or a sign that you didn't really read the thread. > > > > As there are other ways to blow up the backend, i did not object to you > > either working out a better solution or leaving it as it is. > > > > I am speaking up now as this is the first time I am told I have to wait > > another year for this feature to arrive. > > Really? You've never seen a patch punted to the next release before > because it wasn't robust enough? Considering that I see your name > mentioned in the 8.2 release notes, I find that a bit hard to believe. I must admit I did check it only occasionally and to me it seemed to come along nicely. I really should have started panicking earlier. > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company >
On Thu, Apr 5, 2012 at 8:30 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I am speaking up now as this is the first time I am told I have to wait >> another year for this feature to arrive. > > Really? You've never seen a patch punted to the next release before > because it wasn't robust enough? Considering that I see your name > mentioned in the 8.2 release notes, I find that a bit hard to believe. Hannu didn't say he hadn't seen a patch punted. He said this was the first time he knew he would have to wait another year for the feature to arrive. It's shocking since after months of work and an especially extended edition CF, we expect people to deliver something, not just shunt the whole thing off as rejected with 1 days's notice to alter that outcome. Of course nobody can alter the outcome with such short notice. I don't care to hear the reasons, cos such excuses aren't good enough, whoever they come from. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 4/5/12 12:56 PM, Hannu Krosing wrote: >> Really? You've never seen a patch punted to the next release before >> > because it wasn't robust enough? Considering that I see your name >> > mentioned in the 8.2 release notes, I find that a bit hard to believe. > I must admit I did check it only occasionally and to me it seemed to > come along nicely. I have to agree ... for anyone just following the email thread, the patch did not seem to be in trouble. I'm not clear that Dimitri knew that it was, either. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Thu, Apr 5, 2012 at 3:56 PM, Hannu Krosing <hannu@krosing.net> wrote: > On Thu, 2012-04-05 at 15:30 -0400, Robert Haas wrote: >> On Thu, Apr 5, 2012 at 3:20 PM, Hannu Krosing <hannu@krosing.net> wrote: >> > For me it would be enough to know if the trigger is fired by top-level >> > command or not. >> >> Well, you would have been out of luck, then. > > It seemed to me you were coming along nicely with fixing that by adding > the "toplevel", except that the disussion drifted away to solving some > bigger problems of DDL triggering DDL. Well, here's the basic issue. If you want to trigger at the very beginning or very end of a DDL command, that's really not that hard. It can be done just by modifying ProcessUtility. And just to be clear, by "not very hard" what I really mean is "you could get it done in 2 CommitFests if you are a talented and experienced hacker". The problem is that what Dimitri really wants, at least in part, is command triggers that fire in the *middle* of commands - say, just after locking the object we're performing surgery on. That turns out to be a lot harder than it looks for reasons that are NOT Dimitri's fault. We tend to assume that PostgreSQL's code is basically good code, and in general that's true, but some of the code that is at issue here is actually really bad code. It uses ugly, nasty hacks to get the different things that have to happen as part of a DDL operation to happen in the right order, and it's not very careful about doing locking, name lookups, and permissions checking in one and only one place. This means that if you stick a hook in the right place to fire triggers for command A, you actually end up firing the triggers as part of commands B, C, and D when they reach under the hood and trick the function that runs command A into thinking that it's executing the toplevel command A is supposed to process when, in reality, we're doing something completely different and just using that function as a subroutine. It is probably not a tremendous amount of work to refactor ourselves out of this problem, but that work hasn't been done yet. There's a second problem, too, which is that not every place in the backend is a safe place to execute arbitrary user-defined code. Now, the approach you are proposing to that problem is to say, hey, if it crashes the backend, then don't do it that way. And obviously, with functions written in C, we have no choice about that; native code can crash the backend whether we like it or not. However, I think that we rightly have a higher standard for features that are exposed at the SQL level. It is likely true that if you or I or Dimitri were using this feature, we could tiptoe our way around doing anything that was dangerous, and we probably wouldn't be very confused by the strange trigger-firing behavior either, because we understand how the code is written. I don't think our users will be so forgiving. They right expect that the behavior will be logical and documented, that it won't eat their data or crash without a good reason, and that when things do go wrong they'll get an intelligible error message. The current approach doesn't guarantee any of those things. >> Whether or not it works is one thing. I think it's acceptable for it >> to not do anything useful, although actually I think that given a week >> to work on it I could make it to completely safe. > > Due to fractal nature of programming problems I doubt the "completely > safe" part ;) > > You (or someone else) would have found a next obscure set of conditions > where specially crafted function and/or schema could wreak havoc > somewhere. Well, it's not possible to write completely perfect code for anything other than a completely trivial program, and I think there is certainly a time to say, hey, you know, this patch may not be perfect in every way, but it is good enough that we should start with this as a base, and then build on it. But I think that forseeable catalog or data corruption hazards and anything that might pop out an elog() are generally accepted as things that we want to avoid even in initial commits. > I really should have started panicking earlier. Yep. I think Tom and I and others were all pretty clear that there were not enough people reviewing this CommitFest, and that we were spread pretty thin trying to make sure every patch got at least some attention. There were many patches that I could have done more with if I hadn't had >30 of them to do something with, and this is one of them. I could have looked at it sooner; I could have spent time revising it. Your position is apparently that since I noted problems with the patch, it was my job to fix it. I don't know how to square that with the seemingly-universal assumption that every patch is entitled to get looked at by a committer. I cannot both look at every patch and fix every problem I find with each one. If the lesson we take from this CommitFest is that the people who put the most time into making it successful are jerks for not having done even more, I'm going to find that rather demoralizing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 5, 2012 at 4:38 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 4/5/12 12:56 PM, Hannu Krosing wrote: >>> Really? You've never seen a patch punted to the next release before >>> > because it wasn't robust enough? Considering that I see your name >>> > mentioned in the 8.2 release notes, I find that a bit hard to believe. >> I must admit I did check it only occasionally and to me it seemed to >> come along nicely. > > I have to agree ... for anyone just following the email thread, the > patch did not seem to be in trouble. I'm not clear that Dimitri knew > that it was, either. I said repeatedly that there wasn't enough time to get this done for 9.2, starting many weeks ago. It would have been more clear if I'd had time to hone in on the specific problems sooner, but see the other note I just sent for why that didn't happen. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 5, 2012 at 1:40 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Yep. I think Tom and I and others were all pretty clear that there > were not enough people reviewing this CommitFest, Sorry to derail the thread just a little, but I've thought a little about this and I wonder if part of the problem is just that some of the patches are really large: doing a really thorough job reviewing is quite demanding, and the amount and kind of lore everyone has at their disposal is different. To get to the point, I wonder if it makes sense for someone who has a better sense a-priori what they're looking for in a committable patch (i.e. a committer, or someone with a telepathic link to one or more) to delegate specific pieces of patches for thorough review, sketching some thoughts about pitfalls or hazards to look for. Think of it as a patch checklist that is informed by the experience of a committer skimming its contents. -- fdr
Robert Haas <robertmhaas@gmail.com> writes: > I am not interested in relitigating on this thread what has already > been extensively discussed nearby. Dimitri and I agreed on numerous > changes to try to make the behavior sane, and those changes were > suggested and agreed to for good reason. We didn't agree on every Those changes are about done now. I didn't have as much time as I would have wanted to spend on that this week, so if you want to see my command trigger patch re-painted into an event trigger system, please go see the github repository: https://github.com/dimitri/postgres/tree/event_triggers https://github.com/dimitri/postgres/compare/command_triggers...event_triggers https://github.com/dimitri/postgres/compare/master...event_triggers dim=# create event trigger snitch before command_start execute procedure snitch(); create event trigger snitch before command_start execute procedure snitch(); CREATE EVENT TRIGGER dim=# create event trigger another_snitch before command_start when tag in (create table, create view) execute proceduresnitch(); create event trigger another_snitch before command_start when tag in (create table, create view) execute procedure snitch(); CREATE EVENT TRIGGER > point, of course, but we did agree on most of it, and there is no > patch that implements what was agreed. Even if there were, there is > not time to review and commit a heavily revised version of a >1000 > line patch before tomorrow, and any suggestion to the contrary is just > plain wrong. The main problems were, as you say it in another mail, the hook placement and the ddl-in-ddl. The hook placement is being solved thanks to naming several "events" where the trigger are fired. We could have done that in a much simpler way by deciding on when a BEFORE trigger really ought to be called, instead of doing that we're generalizing the system so that you can register your user function before events such as "command_start", or "create_command" or "security_check". Coming next, calling user functions *instead of* those steps (not done in the 9.2 version). The ideas about toplevel commands and calling user functions on CASCADEd objects drops is now possible to implement but not yet in the patch, it's simple enough to do. Calling DDL from a DDL trigger in a way that could change the conditions in which the main command is expecting to run (drop the object being altered in the trigger) is certainly a "shoot yourself in the foot" case and the feature is superuser only: we're talking about a doc patch here. My conclusion here is very simple: if we *want* that feature, we can easily enough have it in 9.2 in some form. That will include the possibility to code a C-extension to implementing command rewriting for use in our 3 major trigger based replication systems, and custom applications too. It's been about a year since we started talking about that topic, and it only changed from being "command triggers" to being "event triggers" last week during review, at version 18 of the patch, each previous version having been both public and reviewed and tested. So, as a community, do we want the feature and are we able to cook something up for 9.2? Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Thu, Apr 5, 2012 at 4:27 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Thu, Apr 5, 2012 at 8:30 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> I am speaking up now as this is the first time I am told I have to wait >>> another year for this feature to arrive. >> >> Really? You've never seen a patch punted to the next release before >> because it wasn't robust enough? Considering that I see your name >> mentioned in the 8.2 release notes, I find that a bit hard to believe. > > Hannu didn't say he hadn't seen a patch punted. He said this was the > first time he knew he would have to wait another year for the feature > to arrive. Oh. I misunderstood what he was saying, then. When ANY patch is still pending after a month of CommitFest, everyone should assume it's in trouble. Triply so if it's a big patch. We are almost three months into this one, and the patch in question is very large. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 5, 2012 at 5:04 PM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote: > Those changes are about done now. Huh? AFAICS, there are vestiges of the old terminology all over the patch, although some very incomplete renaming has been done. I'm pretty sure you haven't made the firing points consistent either, although I'd have to spend more time reviewing to be sure of that. I think it's fair to say that there's probably another month of work here to get this committed. It is, of course, up to the community as a whole whether they want to delay 9.2 another month for this and perhaps other patches that are not yet done. But the idea that we're going to pull it together into committable form in the next 24 hours is not realistic. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes: > Huh? AFAICS, there are vestiges of the old terminology all over the > patch, although some very incomplete renaming has been done. I'm > pretty sure you haven't made the firing points consistent either, > although I'd have to spend more time reviewing to be sure of that. I've choosen to internally have command triggers built in an event trigger framework, because clearly the only kind of events we have an idea how to manage are commands here. Don't generalize an API with only one use case, etc. So internally it's very much command oriented, while the usage is all about "events". The firing point didn't move yet, I finished the mechanism. It's now about picking the right event name for each of them, I've begin to explore about that in aggregatecmds.c already. So I think that's only a policy issue now when it was just impossible some days ago. > I think it's fair to say that there's probably another month of work > here to get this committed. It is, of course, up to the community as > a whole whether they want to delay 9.2 another month for this and > perhaps other patches that are not yet done. But the idea that we're > going to pull it together into committable form in the next 24 hours > is not realistic. All of that depends on what you want to see commit, I'm still under the illusion that parts of it are going to be salvaged. For example we could decide to implement "command_start" and "commend_end" in utility.c and remove all special variables support apart from the parse tree for user functions written in C. That would already be something. Of course as I wasn't running for that outcome that's not what you currently see in the branch. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On Fri, 2012-04-06 at 00:02 +0200, Dimitri Fontaine wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > Huh? AFAICS, there are vestiges of the old terminology all over the > > patch, although some very incomplete renaming has been done. I'm > > pretty sure you haven't made the firing points consistent either, > > although I'd have to spend more time reviewing to be sure of that. > > I've choosen to internally have command triggers built in an event > trigger framework, because clearly the only kind of events we have an > idea how to manage are commands here. Don't generalize an API with only > one use case, etc. So internally it's very much command oriented, while > the usage is all about "events". > > The firing point didn't move yet, I finished the mechanism. It's now > about picking the right event name for each of them, I've begin to > explore about that in aggregatecmds.c already. So I think that's only a > policy issue now when it was just impossible some days ago. > > > I think it's fair to say that there's probably another month of work > > here to get this committed. It is, of course, up to the community as > > a whole whether they want to delay 9.2 another month for this and > > perhaps other patches that are not yet done. But the idea that we're > > going to pull it together into committable form in the next 24 hours > > is not realistic. > > All of that depends on what you want to see commit, I'm still under the > illusion that parts of it are going to be salvaged. I would really like the controversial parts of the recent feature creep to get un-creeped :) At least until 9.3 . > For example we could > decide to implement "command_start" and "commend_end" in utility.c and > remove all special variables support apart from the parse tree for user > functions written in C. That would already be something. I would need only one of those - just something to record the DDL command that was done. I'd prefer to get "command_end" triggers if "command_start" would mean it could fail later. CREATE TRIGGER AFTER ANY DDL EXECUTE record_ddl(); My next wish after the above is available would be triggers on BEGIN/ROLLBACK/COMMIT to implement "streaming" and possibly also "synchronous" logical replication - the current logical replication systems rely on trigger-gathered events only being available after commit and so don't need to get notified about COMMIT/ROLLBACK. CREATE TRIGGER AFTER BEGIN EXECUTE remote_transaction_begin_(); CREATE TRIGGER AFTER ROLLBACK EXECUTE remote_transaction_rollback(); CREATE TRIGGER AFTER COMMIT EXECUTE remote_transaction_commit(); > Of course as I wasn't running for that outcome that's not what you > currently see in the branch. I would very much like to see the stripped down, after command only version to get into 9.2 I would not mind at all waiting a week or two for this to happen. And i promise I will keep a very keen eye on further development and also will start testing right away for it being sufficient for DDL replication as soon as the stripping is completed :) Also, I suspect that the rest of the "event" trigger functionality could better be served as simple hooks anyway, at least until we have some good real life use-case to test against before working on a more involved implementation. > Regards, > -- > Dimitri Fontaine > http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support >
On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote: > On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea > > but I'm not convinced that all the corner-case details have been > > adequately thought through, and I'm scared of being unable to fix any > > such bugs in later versions because of backwards compatibility worries. > > It'd be a lot better to be pushing this in at the start of a devel cycle > > than the end. > > I've been feeling that that patch has been suffering from a lack of > reviewer attention, which is a real shame, because I think the > functionality is indeed really cool. But I haven't looked at it > enough to know what kind of shape it's in. As the reviewer, I'm not aware of any unexplored corner cases or problems that ought to preclude commit. That said, it is a large patch; I doubt anyone could pick it up from scratch and commit it with less than a solid day's effort, and 2-3 days might be more likely. In retrospect, I should have suggested splitting the new ON DELETE/ON UPDATE actions into their own patch. That would have nicely slimmed the base patch and also isolated it from the ON DELETE EACH CASCADE judgement call.
On 04/05/2012 04:27 PM, Simon Riggs wrote: > It's shocking since after months of work and an especially extended > edition CF, we expect people to deliver something, not just shunt the > whole thing off as rejected with 1 days's notice to alter that > outcome. I don't think this is being fair to Robert. You agreed with the hard deadline last week. And the fact that the CF is late isn't a good reason to say it's OK for it to be more late. Every patch that had been reviewed but still had problems has been on life support the entire month of March. The surprising part isn't when one of them is finally returned, it's that they were still alive at all. The theory here is supposed to be that large patches show up in the next to last CF, and by the time they hit the last one they're close to being ready. Just since the beginning of March, Command Triggers picked up useful feedback from all three listed reviewers (plus other commentary and related committer work), going through six revisions. There was still rippling impact like the CTAS/SELECT INTO utility command work going on six weeks into the CF. The way Dimitri has been updating something this large so often makes me dizzy, and I think everyone is disappointed that we haven't seen any great subsets of this separate out to focus on. But regardless of who's right or wrong about what's left to do, any objective look at this one would say it's surely not settled down. And the bar at this point here in April isn't "is this an important feature?" anymore. It should be "is this such an important feature that it's worth delaying the release and taking a risk on recently churning code for?" Let's not kill the messenger who delivers that reminder just because the news is painful. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Greg Smith <greg@2ndQuadrant.com> writes:
> On 04/05/2012 04:27 PM, Simon Riggs wrote:
>> It's shocking since after months of work and an especially extended
>> edition CF, we expect people to deliver something, not just shunt the
>> whole thing off as rejected with 1 days's notice to alter that
>> outcome.
> I don't think this is being fair to Robert.
If we're going to ship a release at all, somebody's got to be willing
to say "no". Personally, been there, done that, got the t-shirt [1].
Robert's just pointing out what has to be pointed out.
regards, tom lane
[1] http://imageshack.us/photo/my-images/199/b9w.jpg/
On 04/05/2012 05:03 PM, Daniel Farina wrote: > To get to the point, I wonder if it makes sense for someone who has a > better sense a-priori what they're looking for in a committable patch > (i.e. a committer, or someone with a telepathic link to one or more) > to delegate specific pieces of patches for thorough review, sketching > some thoughts about pitfalls or hazards to look for. Think of it as a > patch checklist that is informed by the experience of a committer > skimming its contents. It's tricky to add this sort of idea into the current patch workflow in all cases. A decent percentage of submissions bounce off a reviewer who doesn't commit, such that no committer spends time on them yet they still move forward. Any idea that tries to involve committers earlier in the process risks using more of their time on things that ultimately are never going to pass toward commit anyway. That is after all where this whole process started at, before CFs, and we know that didn't scale well. We already have a loose bar in this exact area, one that suggests larger patches should first appear earlier in the development cycle. That happened in this case, with a first submission in mid November, but it wasn't enough to make things go smoothly. When I trace back how that played out, I think the gap in this case came from not being sure who was going to commit the result at the end. If it's early January, and the community knows there's a large feature approaching because it's been around for over a month already, we better be asking who is going to commit it eventually already. Many patch submitters agonize over "which committer is going to grill me most?", and the bigger the patch the more that impacts them. Nailing that down and putting together the sort of early committer checklist you're describing strikes me as something that might happen in the first week of a CF, before there are normally a large pile of "Ready for Committer" things around. Raising these question--who is interesting in committing big things and where they consider the bar to be--is something submitters who have a stake in seeing their patches go on might do. It's better if people who are already working hard on features don't feel like they need to wander around begging for someone to pay attention to them though. Ideally it would be the sort of thing a proper CF manager would highlight for them. Unfortunately we often don't quite have one of those, instead just having people who sometimes make a bunch of noise at the beginning of a CF and then go AWOL. (cough) No one is happy about that, and it's something that clearly needs to be solved better too. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Fri, Apr 6, 2012 at 3:22 AM, Greg Smith <greg@2ndquadrant.com> wrote: > On 04/05/2012 05:03 PM, Daniel Farina wrote: >> To get to the point, I wonder if it makes sense for someone who has a >> better sense a-priori what they're looking for in a committable patch >> (i.e. a committer, or someone with a telepathic link to one or more) >> to delegate specific pieces of patches for thorough review, sketching >> some thoughts about pitfalls or hazards to look for. Think of it as a >> patch checklist that is informed by the experience of a committer >> skimming its contents. > > It's tricky to add this sort of idea into the current patch workflow in all > cases. A decent percentage of submissions bounce off a reviewer who doesn't > commit, such that no committer spends time on them yet they still move > forward. Any idea that tries to involve committers earlier in the process > risks using more of their time on things that ultimately are never going to > pass toward commit anyway. That is after all where this whole process > started at, before CFs, and we know that didn't scale well. > > We already have a loose bar in this exact area, one that suggests larger > patches should first appear earlier in the development cycle. That happened > in this case, with a first submission in mid November, but it wasn't enough > to make things go smoothly. > > When I trace back how that played out, I think the gap in this case came > from not being sure who was going to commit the result at the end. If it's > early January, and the community knows there's a large feature approaching > because it's been around for over a month already, we better be asking who > is going to commit it eventually already. Many patch submitters agonize > over "which committer is going to grill me most?", and the bigger the patch > the more that impacts them. > > Nailing that down and putting together the sort of early committer checklist > you're describing strikes me as something that might happen in the first > week of a CF, before there are normally a large pile of "Ready for > Committer" things around. Raising these question--who is interesting in > committing big things and where they consider the bar to be--is something > submitters who have a stake in seeing their patches go on might do. > > It's better if people who are already working hard on features don't feel > like they need to wander around begging for someone to pay attention to them > though. Ideally it would be the sort of thing a proper CF manager would > highlight for them. Unfortunately we often don't quite have one of those, > instead just having people who sometimes make a bunch of noise at the > beginning of a CF and then go AWOL. (cough) No one is happy about that, and > it's something that clearly needs to be solved better too. I think this basically just boils down to too many patches and not enough people. I was interested in Command Triggers from the beginning of this CommitFest, and I would have liked to pick it up sooner, but there were a LOT of patches to work on for this CommitFest. The first three CommitFests of this cycle each had between 52 and 60 patches, while this one had 106 which included several very complex and invasive patches, command triggers among them. So there was just a lot more to do, and a number of the people who submitted all of those patches didn't do a whole lot to help review them, sometimes because they were still furiously rewriting their submissions. It's not surprising that more patches + fewer reviewers = each patch getting less attention, or getting it later. Even before this CommitFest, it's felt to me like this hasn't been a great cycle for reviewing. I think we have generally had fewer people doing reviews than we did during the 9.0 and 9.1 cycles. I think we had a lot of momentum with the CommitFest process when it was new, but three years on I think there's been some ebbing of the relative enthusiastic volunteerism that got off the ground. I don't have a very good idea what to do about that, but I think it bears some thought. On a related note, letting CommitFests go on for three months because there's insufficient reviewer activity to get them done in one or two is, in my opinion, not much of a solution. If there's even less reviewer activity next time, are we going to let it go on for four months? Six months? Twelve months? At some point, it boils down to "we're just going to stop accepting patches for an indefinite period of time". Yuck. I also think we need to be generally more open to negative feedback than we are. Most if not all people who give negative feedback are not doing so because they wish to torpedo a given patch as because they have legitimate concerns which, since we are a community of smart and talented people here, are often well-founded. I've been there myself, and it's occasionally frustrating, but overall it leads to me doing better work than I otherwise would, which is a hard outcome to complain about when you get right down to it. When it's discovered and agreed that a patch has serious problems that can't be corrected in a few days, the response to that should be "crap, OK, see you next CommitFest". When people aren't willing to accept that, then we end up having arguments. Sure, there will sometimes be times when someone (often Tom, but sometimes another committer or some other experienced volunteer) will be able to step in and rewrite it enough to make it committable. But it seems to me that trying to minimize problems that are found by well-intentioned review for purposes of trying to squeeze something in under a deadline don't work out well. Either the feature goes in buggy, and we spend months trying to sort it out, or else we end up impugning the good will or technical judgement of the people who volunteer to review, which is not a good way to get the larger number of reviewers and CommitFest managers that we so desperately need. Whoever wins the argument, the community loses. I think that there are many projects that are more open to "just committing things" than we are - perhaps no better exemplified than by Tom's recent experiences with Henry Spencer's regular expression engine and the Tcl project. If you're willing to do work, we'll assume it's good; if you know something and are willing to do work, here are the keys. We could decide to take that approach, and just generally lower our standards for commit across the board. I am not in favor of that. I think the fact that we insist on good design and high-quality code is a real strength of this project and something that makes me proud to be associated with it. Yeah, it's harder that way. Yeah, sometimes it means that it takes longer before a given feature gets committed. Yeah, some things don't get done at all. But on the flip side, it means that when you use a PostgreSQL feature, you can pretty much count on it working. And if by some chance it doesn't, you can count on it being an oversight that will be corrected in the next maintenance release rather than a design problem that will never get fixed. I like that, and I think our users do too. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> [ among other good points ]
> ... On a related note, letting CommitFests go on for three
> months because there's insufficient reviewer activity to get them done
> in one or two is, in my opinion, not much of a solution. If there's
> even less reviewer activity next time, are we going to let it go on
> for four months? Six months? Twelve months? At some point, it boils
> down to "we're just going to stop accepting patches for an indefinite
> period of time". Yuck.
Yeah, this is something I was thinking about yesterday. In the first
couple of release cycles with the CommitFest process, we were willing to
let the last fest of a release cycle go on for "as long as it takes",
or at least that was what I felt the policy to be. This time we
eventually gave up and declared closure, but in hindsight we should
likely have done that a month earlier. The fact of the matter is that
quite a few of the patches we were dealing with were *not* ready to
commit, or even close to that, at the start of the fest. If it weren't
the last fest they would have gotten marked Returned With Feedback a
lot sooner.
I wonder whether we ought to have a preset schedule for last fests
just like the others. I'd be willing to let them run, say, 2 months
instead of 1, but no deadline at all risks turning the whole affair
into a death march, which is no fun for anybody and threatens the
quality of the end result too. There's too much temptation to commit
patches that are not really ready, just to get them out of the way.
In short, the idea of strongly calendar-driven releases looks more
and more attractive to me the more times we go through this process.
If your patch isn't ready on date X, then it's not getting into this
release; but there'll be another bus coming along before long.
Stretching out release cycles to get in those last few neat features
just increases the pressure for more of the same, because people don't
know how long it will be to the next release.
regards, tom lane
On 7 April 2012 22:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In short, the idea of strongly calendar-driven releases looks more > and more attractive to me the more times we go through this process. > If your patch isn't ready on date X, then it's not getting into this > release; but there'll be another bus coming along before long. > Stretching out release cycles to get in those last few neat features > just increases the pressure for more of the same, because people don't > know how long it will be to the next release. I'd imagine that clear deadlines may provide the impetus necessary to get patches in earlier, patches updated more promptly, enthuse patch-writers to lobby for review, and overall make commitfests a bit more manageable. And I'd be *strongly* against any relaxing of the current review process, and I don't think it's realistic for PostgreSQL. I want cool new features to get in as much as anyone, but if there are genuine concerns, those features really aren't yet ready for prime time. A perfect example of this is command triggers (now known as event triggers), where the feature that would have got committed wouldn't have been as flexible, elegant or sane as the feature that probably will get committed in 9.3, and I think there's plenty of outstanding questions around it too. There wouldn't be enough room for movement if the design needed anything beyond tweaking, and being painted into a corner would be depressing for all concerned. -- Thom
On 7 April 2012 22:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > In short, the idea of strongly calendar-driven releases looks more > and more attractive to me the more times we go through this process. > If your patch isn't ready on date X, then it's not getting into this > release; but there'll be another bus coming along before long. > Stretching out release cycles to get in those last few neat features > just increases the pressure for more of the same, because people don't > know how long it will be to the next release. I hope that that policy will not be applied without some degree of discrimination. I understand that this is an open-source project, and on a certain level it has to be that simple, because we don't have any other way of making contributors more conscientious about scheduling considerations, except of course for giving them a nudge. That said, all features are not equal, and clearly some are of particular strategic importance to the project, and as such may be worth holding up the release for, subject to certain parameters. Which of these features are worth holding the release up for is highly dependent on their state at the time of the final commitfest deadline. Which features are of strategic importance is of course a matter of opinion, but that's the kind of thing that we have a steering committee for, right? Perhaps a good compromise would be to formalise the process through which patches get a second chances in the final commitfest. I don't think that it will prove workable to have a final deadline that is adhered to blindly. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 7 April 2012 22:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In short, the idea of strongly calendar-driven releases looks more
>> and more attractive to me the more times we go through this process.
>> If your patch isn't ready on date X, then it's not getting into this
>> release; but there'll be another bus coming along before long.
> I hope that that policy will not be applied without some degree of
> discrimination.
Sure, but ...
> I understand that this is an open-source project, and on a certain
> level it has to be that simple, because we don't have any other way of
> making contributors more conscientious about scheduling
> considerations, except of course for giving them a nudge. That said,
> all features are not equal, and clearly some are of particular
> strategic importance to the project, and as such may be worth holding
> up the release for, subject to certain parameters. Which of these
> features are worth holding the release up for is highly dependent on
> their state at the time of the final commitfest deadline. Which
> features are of strategic importance is of course a matter of opinion,
> but that's the kind of thing that we have a steering committee for,
> right?
... we have tried that approach repeatedly in the past, and it's
basically never worked. There were multiple release cycles where we
held up a release to get some "super important" feature in, and
invariably either the release was *way* later than anybody expected,
or we gave up waiting and released without it. Meanwhile, development
of anything else ground to a standstill. Check the archives and you'll
see this theme played out a number of times. We've more or less learned
not to do that, but we've never taken the plunge of setting hard feature
freeze deadlines well in advance. I'm thinking maybe we should.
As for the steering committee, core tries hard not to make technical
decisions for the project; it's better to let those emerge by consensus.
regards, tom lane
On 04/07/2012 06:33 PM, Peter Geoghegan wrote: > On 7 April 2012 22:20, Tom Lane<tgl@sss.pgh.pa.us> wrote: >> In short, the idea of strongly calendar-driven releases looks more >> and more attractive to me the more times we go through this process. >> If your patch isn't ready on date X, then it's not getting into this >> release; but there'll be another bus coming along before long. >> Stretching out release cycles to get in those last few neat features >> just increases the pressure for more of the same, because people don't >> know how long it will be to the next release. > I hope that that policy will not be applied without some degree of > discrimination. If we are to have time based releases, then I assume it won't, it will be pretty much a hard and fast rule. I admit I haven't been a fan in the past, but I can see advantages, not least being predictability of release times. It would be nice to be able to say "In June" when asked when the next release will be, as I often am. cheers andrew
On 7 April 2012 23:51, Tom Lane <tgl@sss.pgh.pa.us> wrote: > As for the steering committee, core tries hard not to make technical > decisions for the project; it's better to let those emerge by consensus. I don't really consider this to be an engineering problem, which is precisely why I bring up the role of core here. Holding up a release for a feature has costs (the feature is delayed, which in some way hurts us, as our users don't have a new release for that much longer, etc) and benefits (when the release is available, Postgres is that much better one release sooner). Naturally, the maturity of the existing code, as judged by the community, would be heavily weighed in this process, but the wider importance of the feature, and how much of an advantage having it earlier provides, would also be weighed. Open source products (as distinct from projects) often have this sort of cost-benefit analysis made by individuals who are somewhat removed from the engineering decisions themselves. While I'm certainly not advocating that we switch to that model - in particular, I am not advocating anything less than full transparency - surely there is something to be said for some aspects of it, mostly to break the sorts of deadlocks that can sometimes occur. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Andrew Dunstan <andrew@dunslane.net> writes:
> On 04/07/2012 06:33 PM, Peter Geoghegan wrote:
>> I hope that that policy will not be applied without some degree of
>> discrimination.
> If we are to have time based releases, then I assume it won't, it will
> be pretty much a hard and fast rule.
> I admit I haven't been a fan in the past, but I can see advantages, not
> least being predictability of release times. It would be nice to be able
> to say "In June" when asked when the next release will be, as I often am.
Just to be clear ... I don't believe that we can have hard-and-fast
*release* dates. I am suggesting that it might be a good idea to have
a hard deadline for committing new features. But beta test phase will
take however long it takes. I don't think shaking out bugs is a
predictable process.
regards, tom lane
On Sat, Apr 7, 2012 at 5:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wonder whether we ought to have a preset schedule for last fests > just like the others. It's always been my feeling that we should have that. > There's too much temptation to commit > patches that are not really ready, just to get them out of the way. This is something I'm really concerned about. During both the 9.0 and 9.1 cycle, we did some of this, and ended up paying for it with months of bug fixing - not of *everything* that was committed late in the cycle, but of certain particular patches. We ended up producing quality releases anyway, but I think if we had pushed it much farther than we did, that might not have happened, or it might have pushed the release out quite a bit more. I think we have to be careful not to set the bar for big patches unreasonably high (or big features will never get done) but I honestly do not believe we have that problem. Which recent release did not end up with its share of big features? People like Jeff Davis, KaiGai Kohei, and myself who submitted their major work (or the preparatory refactorings) relatively early in this release cycle had no real trouble getting commits. It is the patches that showed up in November, December, and January that ended up on the skids. On the flip side, we do have a problem with looming deadlines causing a lot of pressure to push stuff in that isn't ready. There were a number of times this CommitFest when someone said, hey, I'm going to push X, and I said... uh, let me drop what I'm doing and take a look at that, because it doesn't sound ready to me. Some of those commits happened anyway and others didn't, but all of them seemed like the outgrowth of time pressure rather than real certainty that we were in a good place. > In short, the idea of strongly calendar-driven releases looks more > and more attractive to me the more times we go through this process. > If your patch isn't ready on date X, then it's not getting into this > release; but there'll be another bus coming along before long. > Stretching out release cycles to get in those last few neat features > just increases the pressure for more of the same, because people don't > know how long it will be to the next release. Well, the other side of the coin is that the next release will probably be in a little over a year, and that's longer than people want to wait even if it's a known quantity. But I'm not sure there's much we can do about that, unless we want to cut the cycle from four CommitFests to three, or something like that. I think I'd actually be in favor of that, because it seems to me that nearly every feature anyone wants can be gotten done in two CommitFests. There are a few exceptions, like sepgsql and SSI and (now) command triggers, but it's not like we have tons of developers who start in CF1 and just barely get their work in by CF4. What happens more often is that the early CommitFests are kind of dead, and then there's a huge flood of stuff for the last one because, hey, there's gonna be a release soon, I should do something for it! We might find that if we did 3-CF cycles rather than 4-CF cycles we got the same number of features about two months sooner. Or we might not find that. But it's not clear that cutting off a CommitFest would have hurt this release much, or that adding another one would have helped much. Adding one *now* might help, because some of the big patches that were submitted at the beginning might then make it in, but if we'd had all of this extra time budgeted in from the beginning (e.g. last CommitFest planned for March 1st instead of January 15th) I think a decent number of the submissions would have just come that much later. Love may be the strongest human emotion, but procrastination has got to be in the top five. The only thing I can really see helping us to avoid the crush of last minute patches is to have strong, clear, and vigorously enforced rules about rejecting major features that are not submitted early enough, or that are not in good enough shape when submitted. As you said in your reply to Peter, making exceptions because features are "important" is not helpful. My features are important, too, but I get them done early. Granted, not everyone has as much work time to work on community PostgreSQL as I do, but it's simply impossible to believe that everyone's schedule suddenly clears up in the first half of January every year. If there's something magic about that half-month then we've chosen a poor timing for our final CommitFest, but my theory is that we'd have the same problem no matter when we did it. If we start aggressively booting things early, then we don't have to have arguments at the end. But then again, we'd have to have the arguments earlier. I continue to think that there's no real solution here if people are bound on claiming that the feature they particularly like ought to be excepted from the deadlines that apply to everyone else. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Apr 5, 2012 at 6:33 PM, Hannu Krosing <hannu@krosing.net> wrote: > I would really like the controversial parts of the recent feature creep > to get un-creeped :) > > At least until 9.3 . This argument would hold more water if I hadn't been encouraging Dimitri to pick a less aggressive target for this feature in just about every review of the feature that I did. Yes, I want a general syntax that will accommodate not only our immediate goals, but also other things that we will certainly want to do in the future. I think anything else would be very short-sighted. That having been said, I have repeatedly encouraged whittling this feature down to a smaller initial subset, with only partial success. I still think that's one of the things to happen for next CommitFest. Introducing both a general framework for command/event triggers and a rather complex and invasive initial firing point that requires surgery on the guts of every DDL command in the system basically means we've got two major features in one patch. That's a lot to review, and twice as many ways to fail. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
2012-04-05 20:55 keltezéssel, Michael Meskes írta: > On Thu, Apr 05, 2012 at 02:23:03PM -0400, Tom Lane wrote: >>> I think the ECPG fetch patch is about ready to go. Normally Michael >>> Meskes handles all ECPG patches, but I'm not sure what his schedule is >>> like. I'm not sure what the politics are of someone else touching >>> that code. >> I think we should leave that one for Michael. Frankly, none of the >> rest of us pay enough attention to ecpg to be candidates to take >> responsibility for nontrivial patches there. > I will take care of this over the next couple days. Thank you. > Is the patch that Zoltan > send last Friday the latest version? Yes. > > Michael -- ---------------------------------- Zoltán Böszörményi Cybertec Schönig& Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt, Austria Web: http://www.postgresql-support.de http://www.postgresql.at/
On 04/07/2012 11:03 PM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> On 04/07/2012 06:33 PM, Peter Geoghegan wrote: >>> I hope that that policy will not be applied without some degree of >>> discrimination. >> If we are to have time based releases, then I assume it won't, it will >> be pretty much a hard and fast rule. >> I admit I haven't been a fan in the past, but I can see advantages, not >> least being predictability of release times. It would be nice to be able >> to say "In June" when asked when the next release will be, as I often am. > Just to be clear ... I don't believe that we can have hard-and-fast > *release* dates. I am suggesting that it might be a good idea to have > a hard deadline for committing new features. But beta test phase will > take however long it takes. I don't think shaking out bugs is a > predictable process. > > I agree, but I think the release date will be much closer to being predictable if we chop off the last commitfest more rigorously. But time will tell. cheers andrew
> In short, the idea of strongly calendar-driven releases looks more > and more attractive to me the more times we go through this process. > If your patch isn't ready on date X, then it's not getting into this > release; but there'll be another bus coming along before long. > Stretching out release cycles to get in those last few neat features > just increases the pressure for more of the same, because people don't > know how long it will be to the next release. As you know, I've supported this view for several years. > Just to be clear ... I don't believe that we can have hard-and-fast > *release* dates. I am suggesting that it might be a good idea to have > a hard deadline for committing new features. But beta test phase will > take however long it takes. I don't think shaking out bugs is a > predictable process. It could have more visibility though, which would probably also make it go faster. Something to work on. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 04/07/2012 04:51 PM, Robert Haas wrote: > On a related note, letting CommitFests go on for three > months because there's insufficient reviewer activity to get them done > in one or two is, in my opinion, not much of a solution. If there's > even less reviewer activity next time, are we going to let it go on > for four months? Six months? Twelve months? There should be a feedback loop here, one that makes it increasingly obvious to people writing features that such work will screech to a halt unless it's paired with review work. An extreme enforcement might be a bias toward outright rejecting things from people we haven't seen a review from before. That sort of message is hard to deliver without discouraging new developers though, even though I think there's a lot of data to support such a thing. You learn a lot about how to harden a submission against the things any reviewer is likely to do by doing a review yourself. That said, it seems to me that the large patches are the ones that clog the review system the most, and those are usually coming from known contributors. Unfortunately, even if you know the situation here, making it clear to sponsors that review is just as important as new development is a hard sell sometimes. There's a sales pitch needed there, one that makes it clear to people that the review workflow is actually an essential part of why the PostgreSQL code is high quality. Going through review isn't overhead, it's a key part of the process for the benefit of the feature. > I think that there are many projects that are more open to "just > committing things" than we are - perhaps no better exemplified than by > Tom's recent experiences with Henry Spencer's regular expression > engine and the Tcl project. If you're willing to do work, we'll > assume it's good; if you know something and are willing to do work, > here are the keys. We could decide to take that approach, and just > generally lower our standards for commit across the board. This is a bit of a strawman argument as you constructed it. There's a large middle ground between the current CF process and "just committing things". One problem here is that there just isn't enough unique people committing things, and adjusting the commit standards may be necessary to improve that. Right now I think there's a systemic structural problem to how people and companies approach the development cycle for each release. Getting things into the last CF just before a release has a better rate of return on the work, making it easier for people to justify spending time on. There's less elapsed time before you will see the results of your work in production. But that's completely backwards from the risk/reward curve for committers, and it's no wonder clashes here are so common. The idea of committing something that may not be perfect yet is a lot easier to stomach if there's plenty of time left in the release cycle for testing it. Even a full reversion is straightforward to handle when something is changed early in the release. In a risk adverse project like this one, the last batch of feature commits for a release should be extremely picky about what they accept. On a related note, one reason I'm not quite as concerned about the 9.2 schedule is that none of the more speculative submissions went in near the end this time. The changes that scare me most have been committed for months already. That was surely not the case for the last month of 9.0 or 9.1 development, where some pretty big and disruptive things didn't land until very late. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Sat, Apr 07, 2012 at 04:51:03PM -0400, Robert Haas wrote: > I think this basically just boils down to too many patches and not > enough people. I was interested in Command Triggers from the > beginning of this CommitFest, and I would have liked to pick it up > sooner, but there were a LOT of patches to work on for this > CommitFest. The first three CommitFests of this cycle each had > between 52 and 60 patches, while this one had 106 which included > several very complex and invasive patches, command triggers among > them. So there was just a lot more to do, and a number of the people > who submitted all of those patches didn't do a whole lot to help > review them, sometimes because they were still furiously rewriting > their submissions. It's not surprising that more patches + fewer > reviewers = each patch getting less attention, or getting it later. > > Even before this CommitFest, it's felt to me like this hasn't been a > great cycle for reviewing. I think we have generally had fewer people > doing reviews than we did during the 9.0 and 9.1 cycles. I think we > had a lot of momentum with the CommitFest process when it was new, but > three years on I think there's been some ebbing of the relative > enthusiastic volunteerism that got off the ground. I don't have a > very good idea what to do about that, but I think it bears some > thought. http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a patch Returned with Feedback after five consecutive days of Waiting on Author. That was a great tool for keeping things moving, and I think we should return to it or a similar timer. It's also an objective test approximating the subjective "large patch needs too much rework" test. One cure for insufficient review help is to then ratchet down the permitted Waiting on Author days. The queue will clear faster, and patch authors will have clearer schedules to consider assisting with review of the remaining patches. Incidentally, I can't feel too sorry for any patch bounced after one solid review when some other patch gets an implicit bounce after incomplete review or no review. No patch in the latest CF has or will have that fate. Several patches in CF 2011-11 did end that way, and it wasn't the first incident thereof. I liked Simon's idea[1] for increasing the review supply: make a community policy that patch submitters shall furnish commensurate review effort. If review is available-freely-but-we-hope-you'll-help, then the supply relative to patch submissions is unpredictable. Feature sponsors should see patch review as efficient collaborative development. When patch authorship teams spend part of their time reviewing other submissions with the expectation of receiving comparable reviews of their own work, we get a superior final product compared to allocating all that time to initial patch writing. (The details might need work. For example, do we give breaks for new contributors or self-sponsored authors?) [1] http://archives.postgresql.org/pgsql-hackers/2012-03/msg01612.php > When it's discovered > and agreed that a patch has serious problems that can't be corrected > in a few days, the response to that should be "crap, OK, see you next > CommitFest". When people aren't willing to accept that, then we end > up having arguments. Agreed. If we can develop consensus on a litmus test for that condition, it can and should be the author recognizing it and marking his own patch Returned with Feedback. When the author fails to do so, the reviewer should do it. When neither of them take action, only then should it fall on the CF manager. We have relied on the CF manager to make the bulk of these calls, and that's a demonstrated recipe for patch-specific policy debates and CF manager burnout. > I think the fact that we insist on good design and > high-quality code is a real strength of this project and something > that makes me proud to be associated with it. Yeah, it's harder that > way. Yeah, sometimes it means that it takes longer before a given > feature gets committed. Yeah, some things don't get done at all. But > on the flip side, it means that when you use a PostgreSQL feature, you > can pretty much count on it working. And if by some chance it > doesn't, you can count on it being an oversight that will be corrected > in the next maintenance release rather than a design problem that will > never get fixed. I like that, and I think our users do too. Fully agreed. We could occasionally benefit from allowing "experimental" features documented as liable to mutate in any later major release. They should exhibit the same high implementation quality, but we can relax somewhat about perfecting a long-term user interface. Take pg_autovacuum as a rough example of this strategy from the past. Thanks, nm
On Mon, Apr 9, 2012 at 1:38 AM, Noah Misch <noah@leadboat.com> wrote: > http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a patch > Returned with Feedback after five consecutive days of Waiting on Author. That > was a great tool for keeping things moving, and I think we should return to it > or a similar timer. It's also an objective test approximating the subjective > "large patch needs too much rework" test. One cure for insufficient review > help is to then ratchet down the permitted Waiting on Author days. Fully agreed. However, attempts by me to vigorously enforce that policy in previous releases met with resistance. However, not enforcing it has led to the exact same amount of unhappiness by, well, more or less the exact same set of people. > I liked Simon's idea[1] for increasing the review supply: make a community > policy that patch submitters shall furnish commensurate review effort. If > review is available-freely-but-we-hope-you'll-help, then the supply relative > to patch submissions is unpredictable. Feature sponsors should see patch > review as efficient collaborative development. When patch authorship teams > spend part of their time reviewing other submissions with the expectation of > receiving comparable reviews of their own work, we get a superior final > product compared to allocating all that time to initial patch writing. (The > details might need work. For example, do we give breaks for new contributors > or self-sponsored authors?) I guess my problem is that I have always viewed it as the responsibility of patch submitters to furnish commensurate review effort. The original intent of the CommitFest process was that everyone would stop working on their own patches and review other people's patches. That's clearly not happening any more. Instead, the CommitFest becomes another month (or three) in which to continue working on your own patches while expecting other people to review and commit them. The reviewing is getting done by people who happen to be interested in what the patch does, often people who are not code contributors themselves, or by a small handful of dedicated reviewers who actually conform to what I see as the original spirit of this process by reviewing whatever's there because it's there, rather than because they care about it personally. Of course, part of the problem here is that it's very hard to enforce sanctions. First, people don't like to be sanctioned and tend to argue about it, which is not only un-fun for the person attempting to impose the sanction but also chews up even more of the limited review time in argument. Second, the standard is inevitably going to be fuzzy. If person A submits a large patch and two small patches and reviews two medium-size patches and misses a serious design flaw in one of them that Tom spends four days fixing, what's the appropriate sanction for that? Especially if their own patches are already committed? Does it matter whether they missed the design flaw due to shoddy reviewing or just because most of us aren't as smart as Tom? I mean, we can't go put time clocks on everyone's desk and measure the amount of time they spend on patch development and patch review and start imposing sanctions when that falls below some agreed-upon ratio.In the absence of some ability to objectively measurepeople's contributions in this area, we rely on everyone's good faith. So the we-should-require-people-to-review thing seems like a bit of a straw man to me. It's news to me that any such policy has ever been lacking. The thing is that, aside from the squishiness of the criteria, we have no enforcement mechanism. As a result, some people choose to take advantage of the system, and the longer we fail to enforce, the more people go that route, somewhat understandably. David Fetter has floated the idea, a few times, of appointing a release manager who, AIUI, would be given dictatorial power to evict patches from the last CommitFest according to that person's technical judgement and ultimately at their personal discretion to make sure that the release happens in a timely fashion. I remarked at the last developer meeting that I would be happy to have such a role, as long as I got to occupy it. This was actually intended as a joking remark, but I think several people took it more seriously than I meant it. The point I was going for is: nobody really likes having a dictator, unless either (1) they themselves are the dictator or (2) the dictator is widely perceived as benevolent and impartial. In reality, there are probably half a dozen people I would trust in such a role, or maybe it could be some small group of individuals. I would in every way prefer not to have to go this route, because I think that self-policing is in every way better: less adversarial and, if people are honest with themselves and each other, more fair. But the current system has become dysfunctional, so we're going to have to do something. > Fully agreed. We could occasionally benefit from allowing "experimental" > features documented as liable to mutate in any later major release. They > should exhibit the same high implementation quality, but we can relax somewhat > about perfecting a long-term user interface. Take pg_autovacuum as a rough > example of this strategy from the past. Right, I agree. But I think this approach is mostly useful when we have something that we're sure is better than the status quo ante, but not very sure that it's actually good. That wasn't really the problem this time through. Most of what fell out of this CommitFest either broke stuff or had identifiable design problems. Labeling something as experimental because you're not sure how to make it better is one thing; labeling it as experimental because you know how to make it better and haven't yet done the work is something else entirely. It must be deployed judiciously in any event: our code base is littered with the remnants (and complexity) of previous, failed experiments - cf. non-SELECT rules, contrib/xml2. contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non-SELECT rules are a land mine for the unwary at best. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non- > SELECT rules are a land mine for the unwary at best. Which we could start deprecating now btw. since INSTEAD triggers landed in 9.1. There were quite some use-cases for non-select rules that couldn't be fullfilled before but I think saying that we won't support those rules for more than 3 releases or so might be a good idea. I have seen too many bugs being caused by experienced people not realizing the pitfalls of rules. Andres
On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote: > On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: > > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non- > > SELECT rules are a land mine for the unwary at best. > Which we could start deprecating now btw. since INSTEAD triggers landed in > 9.1. There were quite some use-cases for non-select rules that couldn't be > fullfilled before but I think saying that we won't support those rules for > more than 3 releases or so might be a good idea. I have seen too many bugs > being caused by experienced people not realizing the pitfalls of rules. A new documentation section "Pitfalls of the Rule System" discussing the known hazards would help users immediately and be far easier to adopt. In contrast to the breathless vitriol against rules that periodically appears on these lists, current documentation barely hints at the trouble.
On Mon, Apr 9, 2012 at 11:32 AM, Noah Misch <noah@leadboat.com> wrote: > On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote: >> On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: >> > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but non- >> > SELECT rules are a land mine for the unwary at best. >> Which we could start deprecating now btw. since INSTEAD triggers landed in >> 9.1. There were quite some use-cases for non-select rules that couldn't be >> fullfilled before but I think saying that we won't support those rules for >> more than 3 releases or so might be a good idea. I have seen too many bugs >> being caused by experienced people not realizing the pitfalls of rules. > > A new documentation section "Pitfalls of the Rule System" discussing the known > hazards would help users immediately and be far easier to adopt. In contrast > to the breathless vitriol against rules that periodically appears on these > lists, current documentation barely hints at the trouble. We already have a section on rules-vs-triggers, but it presents them as being about equal in terms of advantages and disadvantages; in fact, there are some implications that rules are generally superior. This is a minority point of view on this list, and a rewrite of that section seems overdue. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On lör, 2012-04-07 at 16:51 -0400, Robert Haas wrote: > Even before this CommitFest, it's felt to me like this hasn't been a > great cycle for reviewing. I think we have generally had fewer people > doing reviews than we did during the 9.0 and 9.1 cycles. I think we > had a lot of momentum with the CommitFest process when it was new, but > three years on I think there's been some ebbing of the relative > enthusiastic volunteerism that got off the ground. I don't have a > very good idea what to do about that, but I think it bears some > thought. But the patches left in the current commit fest all have gotten a decent amount of reviewing. The patches are still there because the reviews have identified problems and there was not enough development time to fix them. I don't think more reviewing resources would have changed this in a significant way.
On Mon, Apr 09, 2012 at 09:25:36AM -0400, Robert Haas wrote: > On Mon, Apr 9, 2012 at 1:38 AM, Noah Misch <noah@leadboat.com> wrote: > > http://wiki.postgresql.org/wiki/Running_a_CommitFest suggests marking a patch > > Returned with Feedback after five consecutive days of Waiting on Author. ?That > > was a great tool for keeping things moving, and I think we should return to it > > or a similar timer. ?It's also an objective test approximating the subjective > > "large patch needs too much rework" test. ?One cure for insufficient review > > help is to then ratchet down the permitted Waiting on Author days. > > Fully agreed. However, attempts by me to vigorously enforce that > policy in previous releases met with resistance. However, not > enforcing it has led to the exact same amount of unhappiness by, well, > more or less the exact same set of people. Incidentally, a limit of ~8 total days in Waiting on Author might work better than a limit of 5 consecutive days in Waiting on Author. It would bring fewer perverse incentives at the cost of taking more than a glance to calculate. > > I liked Simon's idea[1] for increasing the review supply: make a community > > policy that patch submitters shall furnish commensurate review effort. ?If > > review is available-freely-but-we-hope-you'll-help, then the supply relative > > to patch submissions is unpredictable. ?Feature sponsors should see patch > > review as efficient collaborative development. ?When patch authorship teams > > spend part of their time reviewing other submissions with the expectation of > > receiving comparable reviews of their own work, we get a superior final > > product compared to allocating all that time to initial patch writing. ?(The > > details might need work. ?For example, do we give breaks for new contributors > > or self-sponsored authors?) > > I guess my problem is that I have always viewed it as the > responsibility of patch submitters to furnish commensurate review > effort. The original intent of the CommitFest process was that > everyone would stop working on their own patches and review other > people's patches. That's clearly not happening any more. Maybe we'd just reemphasize/formalize that past understanding, then. > Of course, part of the problem here is that it's very hard to enforce > sanctions. First, people don't like to be sanctioned and tend to > argue about it, which is not only un-fun for the person attempting to > impose the sanction but also chews up even more of the limited review > time in argument. Second, the standard is inevitably going to be > fuzzy. If person A submits a large patch and two small patches and > reviews two medium-size patches and misses a serious design flaw in > one of them that Tom spends four days fixing, what's the appropriate > sanction for that? Especially if their own patches are already > committed? Does it matter whether they missed the design flaw due to > shoddy reviewing or just because most of us aren't as smart as Tom? I > mean, we can't go put time clocks on everyone's desk and measure the > amount of time they spend on patch development and patch review and > start imposing sanctions when that falls below some agreed-upon ratio. > In the absence of some ability to objectively measure people's > contributions in this area, we rely on everyone's good faith. > > So the we-should-require-people-to-review thing seems like a bit of a > straw man to me. It's news to me that any such policy has ever been > lacking. The thing is that, aside from the squishiness of the > criteria, we have no enforcement mechanism. As a result, some people > choose to take advantage of the system, and the longer we fail to > enforce, the more people go that route, somewhat understandably. I don't envision need for sanctions based on missing things in reviews. It doesn't take much of a review to be better than nothing, so let's keep the process friendly to new and tentative reviewers. When an experienced hacker misses something sufficiently-obvious, the self-recognition will regularly motivate greater care going forward. Nonetheless, yes, I don't see any of this insulating us from bad faith or gaming of the system. I tentatively assume that we have people acting in good faith on perverse incentives, not people acting in bad faith. > David Fetter has floated the idea, a few times, of appointing a > release manager who, AIUI, would be given dictatorial power to evict > patches from the last CommitFest according to that person's technical > judgement and ultimately at their personal discretion to make sure > that the release happens in a timely fashion. I remarked at the last > developer meeting that I would be happy to have such a role, as long > as I got to occupy it. This was actually intended as a joking remark, > but I think several people took it more seriously than I meant it. > The point I was going for is: nobody really likes having a dictator, > unless either (1) they themselves are the dictator or (2) the dictator > is widely perceived as benevolent and impartial. In reality, there > are probably half a dozen people I would trust in such a role, or > maybe it could be some small group of individuals. I would in every > way prefer not to have to go this route, because I think that > self-policing is in every way better: less adversarial and, if people > are honest with themselves and each other, more fair. But the current > system has become dysfunctional, so we're going to have to do > something. Right. If this hypothetical dictator made all decisions justly, who could complain? But objective rules do not require a just judge, and they have a different advantage: predictability. If I know that a clock starts ticking the moment I get my first review, I'll shape my personal plan accordingly. That works even if I don't favor that timer to govern CFs. There's no comparable coping strategy under the administration of an unjust dictator. Similarly, seeing a technicality kick a cherished patch from a final CF will hurt, but that will feed back into earlier submissions of future large, cherished patches from the same author. When we let 10, 20, 30 days elapse between patch revisions, authors have no advance idea how much slack is available and proceed to contend for more of it as needed. This bears similarity to the contrast between civil law and common law legal systems. Civil law systems have greater potential to remedy situation-specific injustice, but they're less predictable. Thanks, nm
On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch <noah@leadboat.com> wrote: > But objective rules do not require a just judge, and they have a > different advantage: predictability. If I know that a clock starts ticking > the moment I get my first review, I'll shape my personal plan accordingly. > That works even if I don't favor that timer to govern CFs. In theory this is true, but previous attempts at enforcing a time-based rule were, as I say, not a complete success. Maybe we just need greater consensus around the rule, whatever it is. At any rate, I think your comments are driving at a good point, which is that CommitFests are a time for patches that are done or very nearly done to get committed, and a time for other patches to get reviewed if they haven't been already. If we make it clear that the purpose of the CommitFest is to assess whether the patch is committable, rather than to provide an open-ended window for it to become committable, we might do better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> At any rate, I think your comments are driving at a good point, which
> is that CommitFests are a time for patches that are done or very
> nearly done to get committed, and a time for other patches to get
> reviewed if they haven't been already. If we make it clear that the
> purpose of the CommitFest is to assess whether the patch is
> committable, rather than to provide an open-ended window for it to
> become committable, we might do better.
Yeah, earlier today I tried to draft a reply saying more or less that,
though I couldn't arrive at such a succinct formulation. It's clear
that in this last fest, there was a lot of stuff submitted that was not
ready for commit or close to it. What we should have done with that was
review it, but *not* hold open the fest while it got rewritten.
We've previously discussed ideas like more and shorter commitfests
--- I seem to recall proposals like a week-long fest once a month,
for instance. That got shot down on the argument that it presumed
too much about authors and reviewers being able to sync their schedules
to a narrow review window. But I think that fests lasting more than a
month are definitely not good.
regards, tom lane
On Mon, Apr 9, 2012 at 7:38 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Mon, Apr 9, 2012 at 6:23 PM, Noah Misch <noah@leadboat.com> wrote: >> But objective rules do not require a just judge, and they have a >> different advantage: predictability. If I know that a clock starts ticking >> the moment I get my first review, I'll shape my personal plan accordingly. >> That works even if I don't favor that timer to govern CFs. > > In theory this is true, but previous attempts at enforcing a > time-based rule were, as I say, not a complete success. Maybe we just > need greater consensus around the rule, whatever it is. > > At any rate, I think your comments are driving at a good point, which > is that CommitFests are a time for patches that are done or very > nearly done to get committed, and a time for other patches to get > reviewed if they haven't been already. If we make it clear that the > purpose of the CommitFest is to assess whether the patch is > committable, rather than to provide an open-ended window for it to > become committable, we might do better. Yeah, I think there's pretty good room for a "+1" on that. We have seen a number of patches proposed where things have clearly stepped backwards into the Design Phase, and when that happens, it should be pretty self-evident that the would-be change can NOT possibly be nearly-ready-to-commit. It seems as though we need to have a "bad guy" that will say, "that sure isn't ready to COMMIT, so we'd better step back from imagining that it ought to be completed as part of this COMMITfest." But there is also a flip side to that, namely that if we do so, there ought to be some aspect to the process to help guide those items that *aren't* particularly close to being committable. That seems nontrivial, as it shouldn't involve quite the same behaviors, and I'm not quite certain what the differences ought to be. Further, the "HackFest" activities will be somewhat immiscible with CommitFest activities, as they're of somewhat different kinds. Or perhaps I'm wrong there. Perhaps it's just that we need to be *much* more willing to have the final 'fest bounce things. I wonder if we're starting to have enough data to establish meaningful statistics on feedback. The "Scrum" development methodology tries to attach estimated costs to tasks and then compare to completion rates to then refine the estimates on completion rates to therefore improve future estimates. We have a fair body of data available from the CommitFest data; perhaps it is time to try to infer some rules as to what patterns on patches may indicate troubled features that are particularly likely to get deferred. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
On Monday, April 09, 2012 05:32:43 PM Noah Misch wrote: > On Mon, Apr 09, 2012 at 03:35:06PM +0200, Andres Freund wrote: > > On Monday, April 09, 2012 03:25:36 PM Robert Haas wrote: > > > contrib/xml2 isn't doing us much harm beyond being an ugly wart, but > > > non- SELECT rules are a land mine for the unwary at best. > > > > Which we could start deprecating now btw. since INSTEAD triggers landed > > in 9.1. There were quite some use-cases for non-select rules that > > couldn't be fullfilled before but I think saying that we won't support > > those rules for more than 3 releases or so might be a good idea. I have > > seen too many bugs being caused by experienced people not realizing the > > pitfalls of rules. > > A new documentation section "Pitfalls of the Rule System" discussing the > known hazards would help users immediately and be far easier to adopt. Youre right. The pitfalls should at least be hinted at. Writing a comprehensive guide on whats safe and whats not isn't exactly easy without going into quite a bit of detail. Here is what I know and what comes to my mind right now: 1. anything but INSTEAD rules are unsafe 2. the use of volatile functions (like nextval()) directly or indirectly (DEFAULT) needs to be vetted very carefully even if 1. is adherred to 3. the snapshots behaviour of an expanded statement is a bit confusing if it contains multiple statements which causes problems with the rather frequent attempts to build rules with upsert'is behaviour While documenting it is sensible a hidden note somewhere doesn't help very much. I personally think the rule system is too broken to be salvageable for anything but internals of views. A very trivial, seemingly innocuous, but totally broken usage of rules: CREATE TABLE data(data_id serial primary key, data int); CREATE TABLE audit(audit_id serial primary key, data_id int NOT NULL, data int); CREATE RULE data_audit AS ON INSERT TO data DO ALSO INSERT INTO audit(data_id, data) VALUES(NEW.data_id, NEW.data); INSERT INTO data(data) VALUES(1); SELECT * FROM data; SELECT * FROM audit; Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
Andres Freund <andres@2ndquadrant.com> writes:
> Here is what I know and what comes to my mind right now:
> 1. anything but INSTEAD rules are unsafe
How so? I agree that volatile functions are problematic, but unless
there's one of those in the picture I think rules work pretty much as
documented.
> 3. the snapshots behaviour of an expanded statement is a bit confusing if it
> contains multiple statements which causes problems with the rather frequent
> attempts to build rules with upsert'is behaviour
Again, not sure what you're complaining about here.
> A very trivial, seemingly innocuous, but totally broken usage of rules:
The problem illustrated here is all down to nextval() being volatile,
no?
regards, tom lane
Christopher Browne <cbbrowne@gmail.com> wrote: > Robert Haas <robertmhaas@gmail.com> wrote: >> CommitFests are a time for patches that are done or very nearly >> done to get committed, and a time for other patches to get >> reviewed if they haven't been already. If we make it clear that >> the purpose of the CommitFest is to assess whether the patch is >> committable, rather than to provide an open-ended window for it >> to become committable, we might do better. > > Yeah, I think there's pretty good room for a "+1" on that. Yeah, +1 for sure. One other sort of mechanical test which I think can and should be applied to patches submitted to the last CF is that if *at the start of the CF* the patch doesn't apply, compile, pass regression tests, and demonstrably provide the functionality claimed for the patch, it should not be a candidate for inclusion in the release. A patch on which the author is continuing to work even in the absence of review should be considered a WIP "want feedback" submission; it should not be allowed to constitute a "placeholder" for inclusion in the release. It's one thing if review turns up corner case bugs missed by the author; it's quite another if there is a month or two of solid development left to be done. The CF period is not the time for "now I'll get serious about wrapping this up." <onlyhalfkidding>Perhaps we should have a concept of "feature months" -- so that when we look at holding up a release with 20 features for two months so that one more feature can make it in, the cost side of the equation is 40 feature-months, and the benefit is 10 feature-months. (Remember, you can't count the added feature as though it's there for a year before the next release if it holds the release up.)</onlyhalfkidding> -Kevin
On 6 April 2012 01:19, Noah Misch <noah@leadboat.com> wrote: > On Thu, Apr 05, 2012 at 02:34:30PM -0400, Robert Haas wrote: >> On Thu, Apr 5, 2012 at 2:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > The FK arrays one I'm kind of queasy about. ?It's a cool-sounding idea >> > but I'm not convinced that all the corner-case details have been >> > adequately thought through, and I'm scared of being unable to fix any >> > such bugs in later versions because of backwards compatibility worries. >> > It'd be a lot better to be pushing this in at the start of a devel cycle >> > than the end. >> >> I've been feeling that that patch has been suffering from a lack of >> reviewer attention, which is a real shame, because I think the >> functionality is indeed really cool. But I haven't looked at it >> enough to know what kind of shape it's in. > > As the reviewer, I'm not aware of any unexplored corner cases or problems that > ought to preclude commit. That said, it is a large patch; I doubt anyone > could pick it up from scratch and commit it with less than a solid day's > effort, and 2-3 days might be more likely. In retrospect, I should have > suggested splitting the new ON DELETE/ON UPDATE actions into their own patch. > That would have nicely slimmed the base patch and also isolated it from the ON > DELETE EACH CASCADE judgement call. As a likely user of this feature (not sure if this needs a "disclaimer", but my employer offered a small bounty towards the development), I'd only need "ON DELETE RESTRICT" behaviour, currently, and wouldn't ever need "ON UPDATE ..." as the referent column would always be a SERIAL. In the meantime, I'm pretty sure the restriction could be handled by a hand-rolled trigger on insert and delete, but the delete one would be a lot slower without some kind of indexing.
On 10 April 2012 15:26, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > A patch on which the author is continuing to work even in the absence of review > should be considered a WIP "want feedback" submission; it should not > be allowed to constitute a "placeholder" for inclusion in the > release. To be fair, I doubt that anyone actually believes that. If they did, they wouldn't have to pay attention very long to receive a rude awakening. > <onlyhalfkidding>Perhaps we should have a concept of "feature > months" -- so that when we look at holding up a release with 20 > features for two months so that one more feature can make it in, the > cost side of the equation is 40 feature-months, and the benefit is > 10 feature-months. (Remember, you can't count the added feature as > though it's there for a year before the next release if it holds the > release up.)</onlyhalfkidding> I am broadly in favour of assessing the value of features in the same way that a commercial organisation might - the more adoption a feature spurs, the more valuable it is, and the more hesitant we should be to bump it (though other factors are also very important). I take this idea seriously, or at the very least share the mentality of the idea - I'm just not sure that we can formalise it, or that we should. I also think that we should try and reward good will. I think that we generally do so, but an automatic cut-off date seems contrary to that. The law of unintended consequences might see us lower our standards to commit something to meet the deadline, that would otherwise not be immediately committed. We're only human, and it would be foolish to assume that committers don't feel that kind of pressure. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
On Tue, Apr 10, 2012 at 11:24 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > On 10 April 2012 15:26, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: >> A patch on which the author is continuing to work even in the absence of review >> should be considered a WIP "want feedback" submission; it should not >> be allowed to constitute a "placeholder" for inclusion in the >> release. > > To be fair, I doubt that anyone actually believes that. If they did, > they wouldn't have to pay attention very long to receive a rude > awakening. Uhm, this has been done, repeatedly. It is not an imaginary problem. I've observed people doing the following anti-social things: 1. Adding patches to the CommitFest after the deadline, sometimes weeks after. The system doesn't prohibit this because there can be legitimate reasons for doing it, such as when a patch submitted on time gets a minor piece of it split out into a separate entry. 2. Adding "fake" CommitFest" entries that point to a non-existing email, and then editing them later to point to the real patch. 3. Posting a patch in time for the CommitFest deadline that is not even code-complete and then continuing to hack on it vigorously throughout the CommitFest. Or, a variant: it's code completed, but not debugged. Both command triggers and foreign key locks fell into this category, AFAICT. When these things are pointed out to the people who are doing them, the response is often either (a) this feature is so important we're all going to die if it's not in the release how can you even think about bouncing it or (b) I'm not really still hacking on it these are all just minor changes. It's surprisingly easy to hoodwink even experienced contributors into thinking that your patch is really, really almost done, honest, it just needs a couple more tweaks when in fact it's nowhere close. I try not to attribute to bad faith what can be explained by incurable optimism, so maybe we just have a lot of incurable optimism. But it's doing nobody any good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10 April 2012 16:51, Robert Haas <robertmhaas@gmail.com> wrote: > When these things are pointed out to the people who are doing them, > the response is often either (a) this feature is so important we're > all going to die if it's not in the release how can you even think > about bouncing it or (b) I'm not really still hacking on it these are > all just minor changes. It's surprisingly easy to hoodwink even > experienced contributors into thinking that your patch is really, > really almost done, honest, it just needs a couple more tweaks when in > fact it's nowhere close. I try not to attribute to bad faith what can > be explained by incurable optimism, so maybe we just have a lot of > incurable optimism. But it's doing nobody any good. I think that you may be missing the greater point here. The people that do this are kind of like the defectors in prisoner's dilemma - at a certain point, some people cannot resist the temptation to push their own patch forward at the expense of others by asserting dubiously that it's ready-for-committer, or maybe they really do incorrectly believe it to be so, or maybe, unlike you, they understand that term to mean "I've done as much as I can, as has my reviewer", or whatever. To play devil's advocate, that might be an anti-social act, but at a certain point, who wants to be the last honest sap? Besides, isn't everyone's crime no crime at all? ISTM that this is symptomatic of the wider problem of a dire shortage of committer resources. 100% of my non-doc patches so far have been committed by 3 people. I would really like to see us figure out a way of making more hackers committers, perhaps subject to certain conditions that don't currently exist for committers. You might find that given commit bits, some people will take their responsibilities as a reviewer far more seriously. Maybe you don't think that any of the likely candidates are quite ready for that responsibility, but you must admit that it's a serious problem. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> One other sort of mechanical test which I think can and should be
> applied to patches submitted to the last CF is that if *at the start
> of the CF* the patch doesn't apply, compile, pass regression tests,
> and demonstrably provide the functionality claimed for the patch, it
> should not be a candidate for inclusion in the release.
I would not be in favor of inflexible application of such a rule.
For instance, if a patch had gotten broken by a conflict with some
other patch applied the day before the CF starts, it would be unfair
to not give the patch author a reasonable amount of time to rebase.
And such conflicts occurring after the CF starts are hardly unusual
either.
> A patch on
> which the author is continuing to work even in the absence of review
> should be considered a WIP "want feedback" submission; it should not
> be allowed to constitute a "placeholder" for inclusion in the
> release. It's one thing if review turns up corner case bugs missed
> by the author; it's quite another if there is a month or two of
> solid development left to be done. The CF period is not the time for
> "now I'll get serious about wrapping this up."
Agreed here, though. Chris Browne mentioned upthread that we really
need a somewhat different process for WIP patches as opposed to those
that are thought to be committable or nearly so. I don't know if we
should institute his idea of a separate series of "HackFest" events,
but at the very least we should try harder to draw a distinction between
WIP and finished patches. They need different sorts of reviewing.
regards, tom lane
Robert Haas <robertmhaas@gmail.com> writes:
> ... It's surprisingly easy to hoodwink even
> experienced contributors into thinking that your patch is really,
> really almost done, honest, it just needs a couple more tweaks when in
> fact it's nowhere close. I try not to attribute to bad faith what can
> be explained by incurable optimism, so maybe we just have a lot of
> incurable optimism. But it's doing nobody any good.
The first, and possibly most significant, observation in Brooks' classic
_The Mythical Man-Month_ is: "All programmers are optimists." I don't
think you're going to get rid of the incurable-optimism problem.
Rather, we'd better design around it.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> One other sort of mechanical test which I think can and should be >> applied to patches submitted to the last CF is that if *at the >> start of the CF* the patch doesn't apply, compile, pass >> regression tests, and demonstrably provide the functionality >> claimed for the patch, it should not be a candidate for inclusion >> in the release. > > I would not be in favor of inflexible application of such a rule. > For instance, if a patch had gotten broken by a conflict with some > other patch applied the day before the CF starts, it would be > unfair to not give the patch author a reasonable amount of time to > rebase. And such conflicts occurring after the CF starts are > hardly unusual either. I didn't mean to exclude rebasing because of conflicts with recent commits, so perhaps "mechanical" was overstating it. But maybe not -- perhaps each patch submission should state which commit it was last confirmed to compile and work with, and if there are problems against HEAD that could be confirmed before asking for the rebase. That wouldn't be too much extra work for the initial reviewer, and it would help establish objective criteria for categorizing whether a patch should be treated as WIP. -Kevin
On 04/09/2012 11:12 PM, Christopher Browne wrote: > It seems as though we need to have a "bad guy" that will say, "that > sure isn't ready to COMMIT, so we'd better step back from imagining > that it ought to be completed as part of this COMMITfest." There's no reward for anyone in the PostgreSQL community to be a bad guy. If you're too aggressive about it, submitters get mad; too loose, and you get both committers and people worried about the release schedule mad. And the community is tight enough that the person you tick off today might be someone you have to work with next week. Having sat in this particular seat several times now, I'd say the role needed here is more mediator than pointy-haired boss. When I write bad news e-mail to submitters, I try to make the tone more about clarifying what was learned and what is needed to improve things for a next round of submissions. It's not easy to adopt a writing tone for that sort of message while not coming off as insulting to someone. Getting a feature punted forward is easier to take if a submitter leaves with a better roadmap and idea what standards they have to meet. On bigger features in particular, that sometimes requires feedback from a committer earlier in the process, even if they haven't reached "Ready for Committer" via a reviewer yet. My comment upthread about nailing down the committer for big features earlier than smaller ones was along these same lines. > I wonder if we're starting to have enough data to establish meaningful > statistics on feedback. I had Robert send me a dump of the data that's in the CF app the other day. I'm hoping to do some useful data mining on it before PGCon. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Tue, Apr 10, 2012 at 12:28 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > I think that you may be missing the greater point here. The people > that do this are kind of like the defectors in prisoner's dilemma - at > a certain point, some people cannot resist the temptation to push > their own patch forward at the expense of others ... The question is - what exactly are we supposed to do about that? I think that when prisoner A rats out prisoner B and prisoner B spends 10 years in Leavenworth, prisoner B is unlikely to be very happy with the situation, even though he's surely not confused about *why* prisoner A did it. So here. If we accept your argument that some people simply cannot help themselves, then the only solution is to make it cease to be a prisoner's dilemma, and that can only be done by changing the incentives, which presumably means handing down punishments to people who push their own patches forward at the expense of others. Unless we care to choose a benevolent dictator, I don't see any way to accomplish that. It's feasible to think that we might be able to streamline the process of booting patches that are not close to committable at the start of a CommitFest, and especially at the start of the final CommitFest. For example, limiting patches to a small number of days in the "Waiting on Author" state would help a great deal. But the more general problem of people arguing that *their* patch is the special one without which the earth will cease to revolve about its axis is more difficult to solve, or that it's ready when it's really not, is more difficult to solve. How would you propose we deal with that problem? > ISTM that this is symptomatic of the wider problem of a dire shortage > of committer resources. 100% of my non-doc patches so far have been > committed by 3 people. I would really like to see us figure out a way > of making more hackers committers, perhaps subject to certain > conditions that don't currently exist for committers. You might find > that given commit bits, some people will take their responsibilities > as a reviewer far more seriously. Maybe you don't think that any of > the likely candidates are quite ready for that responsibility, but you > must admit that it's a serious problem. I don't agree with that. I think that there are a few people who don't now have commit bits who should be given them - in particular, Fujii Masao and Kevin Grittner, both of whom have been doing consistently excellent work for several years. But giving people a commit bit in the hopes that they will do better reviews seems completely backwards to me: we should instead give commit bits to people who have *already* demonstrated that they can be trusted to do good reviews and exercise good judgement, and no one else. The fact is that we have no shortage of committers - there are 19 people who have access to push code into our master git repository. A handful of those people have basically completely left the project and their commit rights should probably be revoked on that basis; most of them are still involved in one way or another but just not able to devote a lot of time to reviewing other people's code. The problem is even more acute for large patches, which only a handful of people are qualified to review, and which also take a lot of wall clock time to review thoroughly. But that's not a problem that's going to go away because we make more committers. Giving more people the ability to commit stuff will neither force them to devote time to it nor make them qualified to do it if they aren't already. Every time someone's favorite patch gets rejected, there is an outcry of - the standards for commit are too high! But this overlooks the fact that there are some people who regularly meet them. A patch from Fujii Masao, Kevin, or Noah is about ten times more likely to be applied without comment than one from the average submitter. That's not because I like them (although I have to admit to liking Kevin quite a lot; I have met Fujii Masao at most briefly and Noah not at all), or because I necessarily care about their patches more than anyone else's; it's because they do really good work. Over time, such people tend to become committers, and then everyone complains that the committers have high standards. Well, yes. They are committers *because* they have high standards, and that is exactly as it should be. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Apr 10, 2012 at 1:27 PM, Greg Smith <greg@2ndquadrant.com> wrote: > There's no reward for anyone in the PostgreSQL community to be a bad guy. > If you're too aggressive about it, submitters get mad; too loose, and you > get both committers and people worried about the release schedule mad. And > the community is tight enough that the person you tick off today might be > someone you have to work with next week. Yep. > Having sat in this particular seat several times now, I'd say the role > needed here is more mediator than pointy-haired boss. When I write bad news > e-mail to submitters, I try to make the tone more about clarifying what was > learned and what is needed to improve things for a next round of > submissions. It's not easy to adopt a writing tone for that sort of message > while not coming off as insulting to someone. Agreed. I used to be better at this, but the increasing volume of patches that get reviewed by no one else has forced me to curtail the amount of time I spend on each one, and that is causing my natural bluntness to come to the fore. Unfortunately. I also think that people were more receptive to my reviews before I got a commit bit. Back then, I was the guy who was telling you what you were going to have to fix so Tom didn't boot your patch. Now, I'm the guy who is threatening to boot your patch if you don't fix what I want fixed. It comes off differently, even if the content is identical. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 10 April 2012 18:28, Robert Haas <robertmhaas@gmail.com> wrote: > If we accept your argument that some > people simply cannot help themselves, then the only solution is to > make it cease to be a prisoner's dilemma, and that can only be done by > changing the incentives, which presumably means handing down > punishments to people who push their own patches forward at the > expense of others. Unless we care to choose a benevolent dictator, I > don't see any way to accomplish that. Well, I was really pointing out that people are somewhat forced into a corner by the current state of affairs, because committers are not typically able to look at anything in sufficient detail that isn't "ready for committer", particularly as we approach crunch-time - their time is simply too precious. By not marking the patch ready for committer, they are basically asking for their patch to be passed over, and they may be incapable of bridging the chasm between what really is their best effort, and what'd you'd consider to be the ready-for-committer gold standard. Some people cannot exclusively dedicate their time to their patch, or lack sufficient experience to meet that standard. > It's feasible to think that we might be able to streamline the process > of booting patches that are not close to committable at the start of a > CommitFest, and especially at the start of the final CommitFest. For > example, limiting patches to a small number of days in the "Waiting on > Author" state would help a great deal. But the more general problem > of people arguing that *their* patch is the special one without which > the earth will cease to revolve about its axis is more difficult to > solve, or that it's ready when it's really not, is more difficult to > solve. How would you propose we deal with that problem? As I've already said, I think that needs to be decided impartially, ideally by people who are removed from the engineering process. I don't mean that we'd get a marketing person to make those decisions - far from it. I just mean that some separation of powers can be a good thing in some circumstances. > I don't agree with that. I think that there are a few people who > don't now have commit bits who should be given them - in particular, > Fujii Masao and Kevin Grittner, both of whom have been doing > consistently excellent work for several years. I agree with you about both individuals. I hope that this happens sooner rather than later. > Giving more people the ability to > commit stuff will neither force them to devote time to it nor make > them qualified to do it if they aren't already. One major component of being qualified, is, of course, knowing what you don't know, and the risk of being left with egg on your face turns out to be a pretty effective way of preventing new committers from being too eager. Giving more people bits has a cost: in general, I'd expect it to result in a higher bug-to-line ratio when code is committed. However, not doing so has an opportunity cost: less code is committed, which may, on balance, result in an inferior release than what we could have had. Maybe you think that we have the balance perfectly right, and you are of course perfectly entitled to that view, as well as being perfectly entitled to having your opinion more heavily weighed than mine, but I'd like to see a dialogue about it at some point. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 10 April 2012 18:28, Robert Haas <robertmhaas@gmail.com> wrote:
>> I don't agree with that. �I think that there are a few people who
>> don't now have commit bits who should be given them - in particular,
>> Fujii Masao and Kevin Grittner, both of whom have been doing
>> consistently excellent work for several years.
> I agree with you about both individuals. I hope that this happens
> sooner rather than later.
FYI, the core committee traditionally has a discussion about whom
to appoint as new committers at the end of each release cycle.
I'm sure we'll be thinking about these names this time.
>> Giving more people the ability to
>> commit stuff will neither force them to devote time to it nor make
>> them qualified to do it if they aren't already.
> One major component of being qualified, is, of course, knowing what
> you don't know, and the risk of being left with egg on your face turns
> out to be a pretty effective way of preventing new committers from
> being too eager. Giving more people bits has a cost: in general, I'd
> expect it to result in a higher bug-to-line ratio when code is
> committed. However, not doing so has an opportunity cost: less code is
> committed, which may, on balance, result in an inferior release than
> what we could have had. Maybe you think that we have the balance
> perfectly right, and you are of course perfectly entitled to that
> view, as well as being perfectly entitled to having your opinion more
> heavily weighed than mine, but I'd like to see a dialogue about it at
> some point.
We've done pretty well over the past fifteen years by being chary in
handing out commit bits. I don't particularly want to change that
policy. Obviously we do need a steady supply of new blood, since
people do leave the project, but relaxing our standards doesn't seem
like the way to get it. The impression I have is that we have a pretty
good and even increasing supply of new interested people, so letting
them acquire experience with the code base and eventually mature into
qualified committers doesn't look like a dead-end strategy from here.
regards, tom lane
On Tue, Apr 10, 2012 at 2:49 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > Well, I was really pointing out that people are somewhat forced into a > corner by the current state of affairs, because committers are not > typically able to look at anything in sufficient detail that isn't > "ready for committer", particularly as we approach crunch-time - their > time is simply too precious. By not marking the patch ready for > committer, they are basically asking for their patch to be passed > over, and they may be incapable of bridging the chasm between what > really is their best effort, and what'd you'd consider to be the > ready-for-committer gold standard. Some people cannot exclusively > dedicate their time to their patch, or lack sufficient experience to > meet that standard. I think that's partly true and partly false. I actually spend a lot of time looking at patches that are not marked Ready for Committer, on the theory that I'd like to move things along that haven't been formally tagged with that designation if they are nevertheless ready to go, whereas Tom I think actively avoids it, on the theory that no one else will volunteer to review if the committers just do everything. These positions are in tension but neither seems to me to be without merit. I do understand that not everyone is going to write code that meets our standards for commit, and I have rewritten my share of patches - sometimes, even quite large patches - to try to bring them up to that level. I had more time to do that last year than I have this year, because this year I've been focused on performance stuff. But, on the flip side, I think we still did a pretty good job handling pretty much everything submitted before November. The stuff that ran into trouble was the stuff that came in at the end, which in many cases was not only late to the table but overly ambitious in its scope. I think the question should be not so much "why didn't those big patches get committed?" as "why does anyone think that they have a right to be upset that they didn't?". They were given, basically, two to three extra months to become committable, and still fell short. And I'm still very willing to devote more time to them to make them committable *even though they are not my projects*, but I am *not* willing to do it while the features I worked hard on to get ready early sit there and don't get released. That might be a reasonable expectation if the original patches were submitted in May and I had blithely ignored them in favor of my own work all year, but that ain't what happened. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, 2012-04-09 at 23:12 -0400, Christopher Browne wrote: > But there is also a flip side to that, namely that if we do so, there > ought to be some aspect to the process to help guide those items that > *aren't* particularly close to being committable. I have benefited immensely from review of my WIP patches, and a lot of the serious review tends to happen during commitfests. This is most important for features with a significant user interface, where it's harder to guess what people will want. My current strategy is to submit WIP-marked patches during a commitfest. I agree that we should continue to have a mechanism to review patches that aren't ready for commit, though I'm fine if we change it. Regards,Jeff Davis
On 04/10/2012 01:33 PM, Robert Haas wrote: > I also think that people were more receptive to my reviews before I > got a commit bit. That's not true; many people were just as annoyed at you back then. (Robert knows I'm kidding. I hope.) -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Tue, Apr 10, 2012 at 11:53:23AM -0500, Kevin Grittner wrote: > Tom Lane <tgl@sss.pgh.pa.us> wrote: > > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: > >> One other sort of mechanical test which I think can and should be > >> applied to patches submitted to the last CF is that if *at the > >> start of the CF* the patch doesn't apply, compile, pass > >> regression tests, and demonstrably provide the functionality > >> claimed for the patch, it should not be a candidate for inclusion > >> in the release. > > > > I would not be in favor of inflexible application of such a rule. > > For instance, if a patch had gotten broken by a conflict with some > > other patch applied the day before the CF starts, it would be > > unfair to not give the patch author a reasonable amount of time to > > rebase. And such conflicts occurring after the CF starts are > > hardly unusual either. > > I didn't mean to exclude rebasing because of conflicts with recent > commits, so perhaps "mechanical" was overstating it. But maybe not > -- perhaps each patch submission should state which commit it was > last confirmed to compile and work with, and if there are problems > against HEAD that could be confirmed before asking for the rebase. > That wouldn't be too much extra work for the initial reviewer, and > it would help establish objective criteria for categorizing whether > a patch should be treated as WIP. Of the patches I've reviewed that fall into one the problem categories Robert outlined, all applied cleanly and passed regression tests. On the flip side, I have submitted at least two patches that failed regression tests for the reviewer due to isolated, easily-fixed blunders. Consequently, I'm not hopeful about these checks as coarse indicators of patch readiness. I would certainly like an objective test for assigning patches to those categories, but I don't have a better idea for such a test. nm
On 04/10/2012 01:28 PM, Robert Haas wrote:
> The fact is that we have no shortage of committers - there are 19
> people who have access to push code into our master git repository. A
> handful of those people have basically completely left the project and
> their commit rights should probably be revoked on that basis; most of
> them are still involved in one way or another but just not able to
> devote a lot of time to reviewing other people's code.
Let's use realistic numbers here: I count 7 people who regularly review
and commit other people's code in a variety of areas. There are also
several subject matter experts who commit things in a relatively narrow
area. But most bigger patches are going to hit a bottleneck whose
capacity could be measured in 3 bits.
I would actually be happy to have more of the people whose commits were
expected to be in targeted areas. It's not like anyone who commits
outside of their scope of expertise is going to survive doing that for
long before getting publicly shamed and/or booted. The pressure to not
screw up is so high in this project, I suspect concerns over making a
mistake is behind some people's reticence to commit other people's work. Committing sketchy code that blows up later
isstill going to haunt
its committer, regardless of the original author.
> Giving more people the ability to
> commit stuff will neither force them to devote time to it nor make
> them qualified to do it if they aren't already.
There are a couple of directions from which I don't completely agree
with this.
To use a personal example I don't think is unique, I would set aside
more time to hack on the documentation if I didn't have to bug one of
the existing committers each time I wanted to work on something there.
It really feels like I'm wasting the time of someone who could be doing
more difficult things every time I submit a doc patch. I'd merrily
write more of those and consume things like the never ending stream of
corrections from Thom Browne if I could turn that into a larger part of
my job. I don't do more of that now because it's very unsatisfying work
unless you can do the whole thing yourself. Knowing everything is going
to pass through another person regardless removes some of the incentive
to polish something until it's perfect for submitters.
As for broader concerns about whether people will alter their quality of
work based on being able to commit, I'd suggest turning a look at
yourself. Your quality of work was high before it was a primary job
goal, but it's surely gotten better now that it is, right? Seems that
way to me at least. But it's really hard to get funding to work
full-time on this project unless someone can commit their work. There
are plenty of people contributing here who rummage up enough part-time
hours to develop the occasional feature, but not quite enough to make
things perfect even by their own standards. And not being recognized
for your work on the project can be a self-fulfilling prophecy.
The main reason I worry about this is because of a very real chicken/egg
problem here that I keep banging into. Since the commit standards for
so many other open-source projects are low, there are a non trivial
number of business people who assume "!committer ==
![trusted|competent]". That makes having such a limited number of
people who can commit both a PR issue ("this project must not be very
important if there are only 19 committers") and one limiting sponsorship
("I'm not going to pay someone to work on this feature who's been
working on it for years but isn't even a committer").
There are a significant number of companies who are willing to sponsor
committers to open-source projects; there are almost none who will
sponsor reviewers or "contributors" of any stature unless they're
already deep into the PostgreSQL community. That's one of the many
reasons it's easier for a committer to attract funding for core
PostgreSQL work, be it in the form of a full-time job or
project-oriented funding. The corresponding flip side to that is that
the small number of committers is limiting the scope of funding the
project can accumulate.
I'm somewhat oddly pleased at how the overflow of incoming submissions
for 9.2 has raised questions around not having enough active committers. I hope decisions about adding more recognizes
thatdistributing that
power really does influence the ability of people to contribute, on
average in a positive way. All I see coming for next year is a dramatic
increase in this class of problem.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith <greg@2ndquadrant.com> wrote: > To use a personal example I don't think is unique, I would set aside more > time to hack on the documentation if I didn't have to bug one of the > existing committers each time I wanted to work on something there. It really > feels like I'm wasting the time of someone who could be doing more difficult > things every time I submit a doc patch. I'd merrily write more of those and > consume things like the never ending stream of corrections from Thom Browne > if I could turn that into a larger part of my job. I don't do more of that > now because it's very unsatisfying work unless you can do the whole thing > yourself. Knowing everything is going to pass through another person > regardless removes some of the incentive to polish something until it's > perfect for submitters. I wouldn't object to creating some doc-only committers. OTOH, I would object to anyone making non-trivial documentation enhancements without posting their patches first and having a second person look it over, so how much difference is there, really? > As for broader concerns about whether people will alter their quality of > work based on being able to commit, I'd suggest turning a look at yourself. > Your quality of work was high before it was a primary job goal, but it's > surely gotten better now that it is, right? Seems that way to me at least. I think my quantity of work has gone up. I'm not sure the quality is much different, although perhaps I've gotten a bit sharper with practice. > I'm somewhat oddly pleased at how the overflow of incoming submissions for > 9.2 has raised questions around not having enough active committers. I hope > decisions about adding more recognizes that distributing that power really > does influence the ability of people to contribute, on average in a positive > way. All I see coming for next year is a dramatic increase in this class of > problem. My perception of what's going on here is dramatically different from yours. I don't think there was any overflow of submissions for 9.2. For the most part I would describe it as a slow and boring release cycle, with the usual spike in half-baked submissions right near the end, except this release they were less baked than usual, which is why most of them didn't go in. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Apr 10, 2012 at 10:28 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > It's feasible to think that we might be able to streamline the process > of booting patches that are not close to committable at the start of a > CommitFest, and especially at the start of the final CommitFest. I'd usually consider "booting" a patch to be the domain of committers (or the commit fest manager), not non-committing reviewers. Could enough patches get enough attention from committers early enough in the process to make early booting happen? > For > example, limiting patches to a small number of days in the "Waiting on > Author" state would help a great deal. Could it be something like a limit on "waiting on author" days, but only days that are after 2 weeks after the submission deadline count (and days later than 3 weeks after the submission deadline count twice). That would encourage people to submit before the deadline, rather than on the deadline. Cheers, Jeff
On Wednesday, April 11, 2012 03:14:41 AM Robert Haas wrote: > > I'm somewhat oddly pleased at how the overflow of incoming submissions > > for 9.2 has raised questions around not having enough active committers. > > I hope decisions about adding more recognizes that distributing that > > power really does influence the ability of people to contribute, on > > average in a positive way. All I see coming for next year is a dramatic > > increase in this class of problem. > > My perception of what's going on here is dramatically different from > yours. I don't think there was any overflow of submissions for 9.2. > For the most part I would describe it as a slow and boring release > cycle, with the usual spike in half-baked submissions right near the > end, except this release they were less baked than usual, which is why > most of them didn't go in. They might have been half-baked. But several of those didn't get design-level review for several weeks which makes it rather hard to fully bake them in time... Andres
Andres Freund <andres@anarazel.de> writes:
> On Wednesday, April 11, 2012 03:14:41 AM Robert Haas wrote:
>> My perception of what's going on here is dramatically different from
>> yours. I don't think there was any overflow of submissions for 9.2.
>> For the most part I would describe it as a slow and boring release
>> cycle, with the usual spike in half-baked submissions right near the
>> end, except this release they were less baked than usual, which is why
>> most of them didn't go in.
> They might have been half-baked. But several of those didn't get design-level
> review for several weeks which makes it rather hard to fully bake them in
> time...
But if they didn't already have design-level review, that means they
were not seen in any previous CF, which means they were not following
the expectation that nontrivial patches should be submitted earlier than
the last CF.
I think the key point here is that people have to expect that it's going
to take more than one round of review to land most nontrivial patches.
And we have to discourage the expectation that that can happen within
the last CF of a release cycle. If anything, the last CF has to be
tighter not looser than others on what we will accept, because there is
no time to recover if something proves wrong with a patch after a
month or three.
I keep coming back to the thought that we need more and shorter CFs,
and/or ReviewFests that are meant to help push WIP patches further
down the track. We need to make it easier to get those early reviews
done while there's still development time left.
regards, tom lane
On 11 April 2012 02:14, Robert Haas <robertmhaas@gmail.com> wrote: > My perception of what's going on here is dramatically different from > yours. I don't think there was any overflow of submissions for 9.2. That is just not true. See the attached graph (couldn't produce one with better resolution at short notice) - I've just eyeballed the graph, but it looks like an upward trend to me. I think I submitted my first patch in late April 2011. Now that Andres has joined 2ndQuadrant, it seems likely that his output will increase by a large amount too. I think that Noah began contributing less than 2 years ago. It certainly seems to me like we're getting more submissions that are more complex...this image was generated by the tool gitstat, and as such does not include figures for the patches that we were unable to commit, though there also appears to be an upward trend there. > For the most part I would describe it as a slow and boring release > cycle, with the usual spike in half-baked submissions right near the > end, except this release they were less baked than usual, which is why > most of them didn't go in. That is uncalled for. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Attachment
Peter Geoghegan <peter@2ndquadrant.com> writes:
> That is just not true. See the attached graph (couldn't produce one
> with better resolution at short notice) - I've just eyeballed the
> graph, but it looks like an upward trend to me.
[ scratches head... ] That's supposed to be total lines of code in our
source tree? What's the big drop in late 2009, then?
Other than that one-time whatever-it-was, it looks to me like the growth
rate has been roughly constant since about 2003. There might be some
acceleration lately but then again there might not. In any case, total
SLOC doesn't have that much to do with volume or complexity of patches.
What I'd be interested to see is number of lines changed per unit time;
that would be a much better measure of patch rate IMHO.
regards, tom lane
On Tue, Apr 10, 2012 at 9:32 PM, Andres Freund <andres@anarazel.de> wrote: > They might have been half-baked. But several of those didn't get design-level > review for several weeks which makes it rather hard to fully bake them in > time... Yeah, I noticed. People other than committers can do design reviews, of course, and historically have, just not so much this time (though Noah, for example, did excellent reviews of everything he looked at). And people can post a design and ask for feedback before starting to code. In fact, once upon a time, it was understood to be recommended practice. I think that Alvaro got a little bit of a bum steer in this area: his patch was big and complicated, he posted design stuff well in advance, including both many emails to hackers and multiple blog articles, and he got very little review from anyone. I personally would have liked to spend more time on that, but I simply did not have time. More people reviewing would have helped with that. Making Alvaro a committer wouldn't, because he already is. I also think that the array foreign key thing didn't get reviewed until awfully late. But on the flip side, when it did get reviewed, it was Noah who did it, not a committer, and all signs suggest he did quite a good job pushing the patch toward a sensible design, as well as cleaning up implementation problems. Admittedly, if Noah were a committer, the patch would likely be committed now, but I am not entirely prepared to second-guess Tom's decision about whether it should go into 9.2. The real problem with the command triggers patch is that we got a blizzard of code. It's unrealistic to expect anyone to devote serious review time to a patch that's under constant development. It also strikes me that a tremendous amount of pain could have been avoided by posting a clear and detailed design sketch for that patch before beginning to code. Dimitri contended that without code, no one will read design sketches, but that doesn't for the most part jive with my experience, and I think that the strategy he actually chose backfired, because it was clear that any review would be hitting a moving target. Page checksums didn't really follow the design-before-code rule either, but in spite of that it got no shortage of attention: Heikki, Noah, and I all spent significant time on it. pgsql_fdw provoked a lot of discussion involving many people. I am not sure we really know what the right design is there, but it's not because nobody offered an opinion. Had I the time I would have thrown my opinion on the pile, but I'm not sure that would have saved it. I have a feeling this might be a big patch with a small patch struggling to get out of it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > On 11 April 2012 02:14, Robert Haas <robertmhaas@gmail.com> wrote: >> My perception of what's going on here is dramatically different from >> yours. I don't think there was any overflow of submissions for 9.2. > > That is just not true. See the attached graph (couldn't produce one > with better resolution at short notice) - I've just eyeballed the > graph, but it looks like an upward trend to me. I don't know what this is a graph of, but if you look at the number of patches in each of the CommitFests for the last couple of releases, you see this: 9.0: 66, 40, 38, 60 9.1: 53, 52, 43, 96 9.2: 60, 52, 53, 104 There might be an upward trend there, but it isn't a very steep one. It also seems pretty clear to me (although you are welcome to disagree) that even if the *number* of patches in 9.2 was higher than 9.1, the average complexity was less, at least for the first three CommitFests. By the way, let's take a look at the major features list for 9.0 and 9.1, as well as who wrote them. From the 9.0 release notes: - Streaming Replication (Fujii Masao - not a committer) - Hot Standby (Simon Riggs - committer - though he wasn't when he wrote the first version of this patch) - GRANT/REVOKE IN SCHEMA (Petr Jelinek - not a committer) - ALTER DEFAULT PRIVILEGES (Petr Jelinek - not a committer) - DO (Peter Jelinek - not a committer) - 64-bit Windows (Tsutomu Yamada, Magnus Hagander - not a committer and a committer, respectively) - Better window functions (Hitoshi Harada - not a committer) - ORDER BY for aggregates (Andrew Gierth - not a committer) - Deferrable unique constraints (Dean Rasheed - not a committer) - Exclusion constraints (Jeff Davis - not a committer) - RADIUS (Magnus Hagander - a committer) - LDAP improvements (Robert Fleming, Magnus Hagander - not a committer and a committer, respectively) - Better LISTEN/NOTIFY (Joachim Wieland - not a committer) - Better VACUUM FULL (Itagaki Takahiro, Tom Lane - both now committers, but Itagaki Takahiro became one only later) - pg_upgrade (Bruce Momjian - a committer) - join removal (Robert Haas - now a committer, but not then) - EXPLAIN enhancements (Robert Haas - now a committer, but not then) - hstore enhancments (Andrew Gierth - now a committer, but not then) And for 9.1: - synchronous replication (Simon Riggs - committer) - foreign tables (Shigeru Hanada, Robert Haas, Jan Urbanski, Heikki Linnakangas - two committers and two non-committers) - per-column collation (Peter Eisentraut, Tom Lane - both committers) - extensions (Dimitri Fontaine, Tom Lane - one non-committer, one committer) - SSI (Kevin Grittner, Dan Ports - not committers) - unlogged tables (Robert Haas - committer) - DML WITH (Marko Tiikkaja, Hitoshi Harada - not committers) - KNN-GIST (Teodor Sigaev, Tom Lane - both committers) - SECURITY LABEL and sepgsql (KaiGai Kohei - not a committer) - Update the PL/Python server-side language (Jan Urbanski - not a committer) We don't have the release notes for 9.2 yet, and I don't want to speculate too much about exactly what things will get labelled as major features, but.... we might have shifted slightly in the direction of major features coming from committers, because I worked on three things that could arguably be placed in that category and Tom's query planner stuff might qualify as well. OTOH, Fujii Masao wrote cascading replication, which I am positive will be listed, and you did the pg_stat_statements rework, which is certainly awfully nifty whether it makes the major features cut or not, and Jeff Davis did range types, which I think may be the most innovative thing in 9.2 even though it doesn't have quite as broad an appeal. However exactly the list turns out, there is no question that non-committers have been quite successful in getting significant feature enhancements committed in each of the last three releases, and I'm pretty confident it goes back a lot further than that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wednesday, April 11, 2012, Robert Haas wrote:
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Apr 10, 2012 at 10:05 PM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
> On 11 April 2012 02:14, Robert Haas <robertmhaas@gmail.com> wrote:
>> My perception of what's going on here is dramatically different from
>> yours. I don't think there was any overflow of submissions for 9.2.
>
> That is just not true. See the attached graph (couldn't produce one
> with better resolution at short notice) - I've just eyeballed the
> graph, but it looks like an upward trend to me.
I don't know what this is a graph of, but if you look at the number of
patches in each of the CommitFests for the last couple of releases,
you see this:
9.0: 66, 40, 38, 60
9.1: 53, 52, 43, 96
9.2: 60, 52, 53, 104
There might be an upward trend there, but it isn't a very steep one.
It also seems pretty clear to me (although you are welcome to
disagree) that even if the *number* of patches in 9.2 was higher than
9.1, the average complexity was less, at least for the first three
CommitFests.
By the way, let's take a look at the major features list for 9.0 and
9.1, as well as who wrote them.
>From the 9.0 release notes:
- Streaming Replication (Fujii Masao - not a committer)
- Hot Standby (Simon Riggs - committer - though he wasn't when he
wrote the first version of this patch)
- GRANT/REVOKE IN SCHEMA (Petr Jelinek - not a committer)
- ALTER DEFAULT PRIVILEGES (Petr Jelinek - not a committer)
- DO (Peter Jelinek - not a committer)
- 64-bit Windows (Tsutomu Yamada, Magnus Hagander - not a committer
and a committer, respectively)
- Better window functions (Hitoshi Harada - not a committer)
- ORDER BY for aggregates (Andrew Gierth - not a committer)
- Deferrable unique constraints (Dean Rasheed - not a committer)
- Exclusion constraints (Jeff Davis - not a committer)
- RADIUS (Magnus Hagander - a committer)
- LDAP improvements (Robert Fleming, Magnus Hagander - not a committer
and a committer, respectively)
- Better LISTEN/NOTIFY (Joachim Wieland - not a committer)
- Better VACUUM FULL (Itagaki Takahiro, Tom Lane - both now
committers, but Itagaki Takahiro became one only later)
- pg_upgrade (Bruce Momjian - a committer)
- join removal (Robert Haas - now a committer, but not then)
- EXPLAIN enhancements (Robert Haas - now a committer, but not then)
- hstore enhancments (Andrew Gierth - now a committer, but not then)
For the sake of the archives - Andrew Gierth is not a committer now either.
//Magnus
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On Tue, Apr 10, 2012 at 8:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: > However exactly > the list turns out, there is no question that non-committers have been > quite successful in getting significant feature enhancements committed > in each of the last three releases, and I'm pretty confident it goes > back a lot further than that. I agree that in practice non-committers do get a lot of great stuff done, but the question is if *more* stuff would get done if things were slightly different. To that end, I'd like to share my own anecdote on why I don't attempt large projects to Postgres at this time: I used to work on a proprietary postgres offspring and ship quite a bit of internals code. A couple of people I worked with are frequenters of this list, even. I spent nearly two years doing it, full time, without having to (or being able to) go through a full-blown community process from design to ship: I got a lot of nuts-and-bolts practice, and I really enjoyed it. Yet I don't take on large projects in the project now, and I'm even employed in a place where I could start doing that on-the-job. Why don't I? One reason I don't do that is because there is an unavoidable information asymmetry problem between myself and the committers. When I think of a committer and what makes me different than them, this is what I come up with: * More experience and expertise, both in general and with the project * Proven intent to maintain the work submitted by others for a long time. In a word, "stewardship" or "ownership" I'm grateful for both, but the latter point is one where some mind-reading is required: what's strategically important enough that's it is important enough to compromise on something? What compromises are acceptable? That is tantamount to guessing "what compromises is a committer willing to maintain?" And that can be a pretty personal thing and is hard to guess, and I don't think that's solvable as long as there seems to be this handoff from "the contributor" to "the project." It's hard to feel a sense of ownership -- and thus commitment -- if one cannot simply change one's own code, especially for trivia or churning around a future intent or purpose. If there is a bottleneck with the development process that is having a chilling effect on my ability to justify larger projects, it is this. I don't know what the most apparent way to optimize that bottleneck is, but there's my thoughts. I think part of the answer is more hooks, even if they come with reduced contracts in terms of maintenance (here this release, gone the next release), and less required justification to commit those; consider https://github.com/dimitri/pgextwlist, which relies on such a hook and is the only thing that makes 9.1's extension support viable for Heroku, yet is cohesive feeling with the rest of the system to the point that it pretty much goes unnoticed. That's a great property I wish I could see more of. Also, I am not able to spend as much time on large Postgres-projects because some of the tooling outside the database is still the weakest link in my chain for now, so the good news is that I've shifted my attention to projects that are very much related but not part postgres-proper. The point of having more hooks is to open up more opportunities for such tools without making the result feel incohesive and terrible for reasons not intrinsic to the idea it is trying to add (consider: using the statement hook in pgextwlist rather than preloaded security-definer UDFs that would run CREATE EXTENSION for you. Yuck.) -- fdr
On 04/10/2012 09:14 PM, Robert Haas wrote: > I wouldn't object to creating some doc-only committers. OTOH, I would > object to anyone making non-trivial documentation enhancements without > posting their patches first and having a second person look it over, > so how much difference is there, really? This workflow is the easy one: -Committer suggests doc change -No one has an opinion against it strong enough to comment, or minor review comments are made -Commit change with feedback when received That's a predictable, short process unless the change is controversial, in which case good feedback normally comes out of that discussion. And if I feel review is needed but don't catch any volunteers, there is a much broader pool of people who can be hired to help with review work, relative to the size of the committer one. Compare with: -Submitter suggests doc change -No one has a strong opinion on it, may not be picked up at all -Submitter adds to the next CF -Wait for review -[Possible repost update with reviewer changes] -Ready for committer -Committer takes time away from code review to look at it -Possibly another feedback/review resubmission -Commit final versions It's usually not this bad, but in every case it's pulling resources off of more valuable jobs. I'd like to dump around 50 pages of new material into the docs as a start, but I don't want to take so much time away from the code oriented committers to chew on that much. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Greg Smith <greg@2ndQuadrant.com> writes:
> On 04/10/2012 09:14 PM, Robert Haas wrote:
>> I wouldn't object to creating some doc-only committers. OTOH, I would
>> object to anyone making non-trivial documentation enhancements without
>> posting their patches first and having a second person look it over,
>> so how much difference is there, really?
> ...
> I'd like to dump around 50 pages of new material into the docs as a
> start, but I don't want to take so much time away from the code oriented
> committers to chew on that much.
Well, with all due respect, that does not sound like a change that
doesn't need review.
I have not noticed people adding docs-only changes to the CFs; usually
it's more like "post a patch, somebody looks it over and commits it".
I agree that this is still too much overhead for simple fixes, such
as the editorial glitches that Thom Brown is so good at finding
(and I'm about ready to vote to give him a commit bit for that work).
But a fifty-page chunk is not that, indeed it sounds like it would have
enough technical content that it might actually merit a full-scale
review.
regards, tom lane
On 11 April 2012 03:26, Tom Lane <tgl@sss.pgh.pa.us> wrote: > [ scratches head... ] That's supposed to be total lines of code in our > source tree? What's the big drop in late 2009, then? I had wondered about that myself - all I can tell you is that I used the tool as advertised, without any adornments. This particular tool is a bit misleading, because it counts lines of code as lines of checked-in text, which can include things that are very verbose without necessarily being what we really think of as code - it doesn't make any effort to discriminate against non-code, nor does it expose the option of doing so. I chose it at short notice simply because it produces graphs. I do intend to take a look at this problem in more detail, and get better statistics on changes to our codebase - it's a tricky proposition, though. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
On Wed, Apr 11, 2012 at 16:24, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Smith <greg@2ndQuadrant.com> writes: >> On 04/10/2012 09:14 PM, Robert Haas wrote: >>> I wouldn't object to creating some doc-only committers. OTOH, I would >>> object to anyone making non-trivial documentation enhancements without >>> posting their patches first and having a second person look it over, >>> so how much difference is there, really? > >> ... >> I'd like to dump around 50 pages of new material into the docs as a >> start, but I don't want to take so much time away from the code oriented >> committers to chew on that much. > > Well, with all due respect, that does not sound like a change that > doesn't need review. > > I have not noticed people adding docs-only changes to the CFs; usually > it's more like "post a patch, somebody looks it over and commits it". > I agree that this is still too much overhead for simple fixes, such > as the editorial glitches that Thom Brown is so good at finding > (and I'm about ready to vote to give him a commit bit for that work). > But a fifty-page chunk is not that, indeed it sounds like it would have > enough technical content that it might actually merit a full-scale > review. Since the topic is somewhat drifting here anyway.. :-) Might it be worthwhile to allow some sort of "staging repository" and actually start using the git stuff a bit more around this? E.g. we could have a "docs repo" somewhere where more people have commit bits, and then they are just regularly merged back into the main tree? Sort of the way different people can own different subsystems in other projects, but someone does the "trusted merge"? For example, Thom (and others) could collect a number of typo fixes in their own repo and then just ask for a merge.The advantage over just staging multiple commits and then submitting a patch would be that multiple people could work on it... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 04/10/2012 08:43 PM, Greg Smith wrote: > On 04/10/2012 01:28 PM, Robert Haas wrote: >> The fact is that we have no shortage of committers - there are 19 >> people who have access to push code into our master git repository. A >> handful of those people have basically completely left the project and >> their commit rights should probably be revoked on that basis; most of >> them are still involved in one way or another but just not able to >> devote a lot of time to reviewing other people's code. > > Let's use realistic numbers here: I count 7 people who regularly > review and commit other people's code in a variety of areas. There > are also several subject matter experts who commit things in a > relatively narrow area. But most bigger patches are going to hit a > bottleneck whose capacity could be measured in 3 bits. Robert's point is fairly important. A few years ago one of the Postgres companies hired me for a few weeks to push along some of the stuff that was holding up a release at a critical time. (This was in the pre CF days.) Several important features made it into that release that almost certainly would not have otherwise. But generally that hasn't happened, and the time I've devoted has been my own, and thus subject to competing demands of business and the mythical "life AFK". Sometimes that makes it quite hard to arrange time to spend on reviewing and committing large patches. > > > There are a significant number of companies who are willing to sponsor > committers to open-source projects; there are almost none who will > sponsor reviewers or "contributors" of any stature unless they're > already deep into the PostgreSQL community. That's one of the many > reasons it's easier for a committer to attract funding for core > PostgreSQL work, be it in the form of a full-time job or > project-oriented funding. The corresponding flip side to that is that > the small number of committers is limiting the scope of funding the > project can accumulate. > > Yep. The plus side is that Postgres business seems to be growing quite rapidly (if our experience at PostgreSQL Experts Inc is anything to go by), so maybe there will be more sources of funding available. More work needs to be done to generate funds to support getting features reviewed and committed. Patches seems to be getting ever larger and more complex, and that makes reviewing them harder and much more time consuming. cheers andrew
Excerpts from Magnus Hagander's message of mié abr 11 11:35:10 -0300 2012: > For example, Thom (and others) could collect a number of typo fixes in > their own repo and then just ask for a merge.The advantage over just > staging multiple commits and then submitting a patch would be that > multiple people could work on it... The other advantage is that committers could have that tree as another remote in their main PG tree, and so changesets could be pulled into the same clone and cherry-picked into the master branch. (I'd also set up a clone for Alex Hunsaker to commit to pl/perl). -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander <magnus@hagander.net> wrote: > Since the topic is somewhat drifting here anyway.. :-) > > Might it be worthwhile to allow some sort of "staging repository" and > actually start using the git stuff a bit more around this? E.g. we > could have a "docs repo" somewhere where more people have commit bits, > and then they are just regularly merged back into the main tree? Sort > of the way different people can own different subsystems in other > projects, but someone does the "trusted merge"? > > For example, Thom (and others) could collect a number of typo fixes in > their own repo and then just ask for a merge.The advantage over just > staging multiple commits and then submitting a patch would be that > multiple people could work on it... If our goal is to give people more or less unfettered access to certain areas of the tree, but not the whole thing, we should perhaps consider just doing that directly. There's no particular reason why Thom Brown can't be made a committer just for docs, or why Alex Hunsaker can't be made a committer just for PL/perl (and presumably docs, since he'd need to update the docs if he updates the code), if that's actually what we want to do. Now, the advantage of a staging tree is that it gives the people who have commit rights to the main repository the ability to decline to merge. The question is - what happens then, especially given that we have so many committers already? In Linux-land, it becomes the subsystem maintainer's responsibility to put the tree into a state where Linus will again become willing to merge it, or he can fire the subsystem maintainer and pick a new one that'll do what he wants. But we don't work that way. Instead, the committers as a group have the responsibility for not breaking stuff. So who would decide whether to do the merge, and who would be responsible for fixing things if the merge were refused? As far as I can see, this basically amounts to bundling lots of unrelated changes into one big pile and then asking to have them all committed at once instead of one at a time, which sounds like more work not less, unless we're just going to blindly merge without reviewing, in which case we may as well just let people commit to the main repository themselves. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> Might it be worthwhile to allow some sort of "staging repository" and
>> actually start using the git stuff a bit more around this?
> ... As far as I can see, this basically amounts to
> bundling lots of unrelated changes into one big pile and then asking
> to have them all committed at once instead of one at a time, which
> sounds like more work not less, unless we're just going to blindly
> merge without reviewing, in which case we may as well just let people
> commit to the main repository themselves.
Yeah. I'm also worried that we would either lose linear history, or
(if we squash the merge commits) lose change log history for the
individual fixes. Neither of those sounds terribly attractive.
We've frequently had, and still have today, committers who are
understood to have limited areas of expertise and are given commit
bits on the honor system to not break what they don't know well.
I don't have any problem with continuing in that line.
regards, tom lane
On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Apr 11, 2012 at 10:35 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> Might it be worthwhile to allow some sort of "staging repository" and >>> actually start using the git stuff a bit more around this? > >> ... As far as I can see, this basically amounts to >> bundling lots of unrelated changes into one big pile and then asking >> to have them all committed at once instead of one at a time, which >> sounds like more work not less, unless we're just going to blindly >> merge without reviewing, in which case we may as well just let people >> commit to the main repository themselves. > > Yeah. I'm also worried that we would either lose linear history, or > (if we squash the merge commits) lose change log history for the > individual fixes. Neither of those sounds terribly attractive. > > We've frequently had, and still have today, committers who are > understood to have limited areas of expertise and are given commit > bits on the honor system to not break what they don't know well. > I don't have any problem with continuing in that line. Me neither, but I don't know how far it scales. Having certain people who are defined as, say, doc-only committers will not only make it clear to those people what they're expected to commit, but also clear to everyone else who the people are who might commit any given patch they might write. If we just end up with 50 committers and you have to follow pgsql-hackers to understand who knows what and which people are even still around, it's not going to make anything easier for anyone. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Excerpts from Robert Haas's message of mié abr 11 12:44:02 -0300 2012: > Me neither, but I don't know how far it scales. Having certain people > who are defined as, say, doc-only committers will not only make it > clear to those people what they're expected to commit, but also clear > to everyone else who the people are who might commit any given patch > they might write. If we just end up with 50 committers and you have > to follow pgsql-hackers to understand who knows what and which people > are even still around, it's not going to make anything easier for > anyone. Since we're so keen on copying what Linux does, we could just have a MAINTAINERS file. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
All, From my observation, the CF process ... in fact, all development processes we've had in Postgres ... have suffered from onlyone problem: lack of consensus on how the process should work. For example, we've *never* had consensus around the criteriafor kicking a patch out of a commitfest. This lack of consensus has resulted in disorganization, ennui towards theprocess, deadline overruns, and a lot of general unhappiness. People have stopped believing in the CF system becausewe've stopped running it. I'm encouraged at this point that we've seen where this lack of consensus can lead us, maybe at this point we're willingto set aside individual differences of opinion on what the criteria should be (especially when it comes to the patcheswe each individually care about) in service of a smoother-running process. Some suggestions: - for the first 2 weeks of each CF, there should be a *total* moritorium on discussing any features not in the current CFon -hackers. - the CF manager should have unquestioned authority to kick patches. As in, no arguing. - we should have simple rules for the CF manager for kicking patches, as in: * no response from author in 5 days * judgedas needing substantial work by reviewer * feature needs spec discussion However, the real criteria don't matter as much as coming up with a set of criteria we're all willing to obey, whatever theyare. We also need better tools for the CF, but frankly better tools is a minor issue and easily solved if we have a consensuswhich people are willing to obey. For that matter, if we have a smooth and impartial process, we can do other things,including: training new reviewers, promoting new committers, changing the length of the CF cycle, or changing thePostgreSQL release cycle (yes, really). While our review and commit process is completely subjective and inconsistent,though, we can't do any of these things. --Josh Berkus
On 11 April 2012 15:35, Magnus Hagander <magnus@hagander.net> wrote: > Might it be worthwhile to allow some sort of "staging repository" and > actually start using the git stuff a bit more around this? E.g. we > could have a "docs repo" somewhere where more people have commit bits, > and then they are just regularly merged back into the main tree? Sort > of the way different people can own different subsystems in other > projects, but someone does the "trusted merge"? > > For example, Thom (and others) could collect a number of typo fixes in > their own repo and then just ask for a merge.The advantage over just > staging multiple commits and then submitting a patch would be that > multiple people could work on it... This is hardly a radical idea at all - it's basically how git was really intended to be used at scale. Of course, unless some committer is going to make it their responsibility to merge those commits say every 3 months, there's no point in bothering. This could consolidate the number of typo commits to boot, as they could be rebased. TBH, I find it slightly embarrassing to have to ask a committer to fix a minor typo, and it's hardly reasonable to expect me to save my typos up. Big +1 from me. It might be the case that over time, we become comfortable with this approach and upgrade the tree to a "linux-next" style tree (much like the -mm tree was repurposed into the progenitor of linux-next), with a lesser (though still substantial) standard for committers to meet. There could be an understanding that by committing to the tree, the developer makes a representation that they are confident that the feature is ready for prime-time, in just the same way that a commit currently represents - don't underestimate the power of that ceremony. Less senior contributors could have their work scrutinised by a wider body of people that haven't necessarily taken enough of an interest in the contributor's work to want to follow them on github or whatever - enthusiast power users who wouldn't really consider themselves hackers. This partially solves the "you want us to fund feature development but you're not even a committer?" problem that Greg referred to. It's also how big projects scale - technically, there are relatively few committers to the linux-stable tree. This approach formalises Tom's view that "I think the key point here is that people have to expect that it's going to take more than one round of review to land most nontrivial patches". On 11 April 2012 16:27, Robert Haas <robertmhaas@gmail.com> wrote: > Now, the advantage of a staging tree is that it gives the people who > have commit rights to the main repository the ability to decline to > merge. The question is - what happens then, especially given that we > have so many committers already? In Linux-land, it becomes the > subsystem maintainer's responsibility to put the tree into a state > where Linus will again become willing to merge it, or he can fire the > subsystem maintainer and pick a new one that'll do what he wants. But > we don't work that way. Instead, the committers as a group have the > responsibility for not breaking stuff. So who would decide whether to > do the merge, and who would be responsible for fixing things if the > merge were refused? This seems like a non-issue to me. We just try and match the Linux model. In practice I'd imagine that the roles would not really be perfectly delineated like that, and I find it really doubtful that they are in Linux land either. There was a time when some people were somewhat skeptical of the git migration (at least privately), and that was, as far as I can tell, a roaring success. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Tom Lane <tgl@sss.pgh.pa.us> wrote: > What I'd be interested to see is number of lines changed per unit > time; that would be a much better measure of patch rate IMHO. Based on `git diff --shortstat` between tags, for the whole tree, this is what shows up: files git tag changed insertions deletions =========== ======= ========== ========= PG95-1_01 Release_1_0_2 133 10373 1046 REL2_0 1079 65115 41987 REL6_1 770 70656 42995 REL6_2 919 195720 141153 REL6_3 1140 104845 34326 REL6_4_2 1583 171053 69832 REL6_5 1366 136665 85013 REL7_0 1991 272086 142201 REL7_1 2164 441090 212481 REL7_2 1826 314583 139238 REL7_3 2258 631434 245295 REL7_4 2018 436323 283074 REL8_0_0 2398 446392 258825 REL8_1_0 1796 235680 181193 REL8_2_0 2343 288467 168438 REL8_3_0 2355 405974 174798 REL8_4_0 2464 339085 462065 REL9_0_0 2270 292187 191852 REL9_1_0 3225 443037 186042 HEAD 2014 189648 111194 -Kevin
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 11, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> We've frequently had, and still have today, committers who are
>> understood to have limited areas of expertise and are given commit
>> bits on the honor system to not break what they don't know well.
>> I don't have any problem with continuing in that line.
> Me neither, but I don't know how far it scales. Having certain people
> who are defined as, say, doc-only committers will not only make it
> clear to those people what they're expected to commit, but also clear
> to everyone else who the people are who might commit any given patch
> they might write. If we just end up with 50 committers and you have
> to follow pgsql-hackers to understand who knows what and which people
> are even still around, it's not going to make anything easier for
> anyone.
When and if we have 50 committers, we can worry about that problem ;-).
But in practice people have different areas of expertise already.
There was some mumbling upthread about trying to identify early who
would be the responsible committer for any given CF submission ---
doesn't seem to me like that is much different.
regards, tom lane
On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote: > On 11 April 2012 15:35, Magnus Hagander <magnus@hagander.net> wrote: >> For example, Thom (and others) could collect a number of typo fixes in >> their own repo and then just ask for a merge.The advantage over just >> staging multiple commits and then submitting a patch would be that >> multiple people could work on it... > > This is hardly a radical idea at all - it's basically how git was > really intended to be used at scale. Of course, unless some committer > is going to make it their responsibility to merge those commits say > every 3 months, there's no point in bothering. This could consolidate > the number of typo commits to boot, as they could be rebased. TBH, I > find it slightly embarrassing to have to ask a committer to fix a > minor typo, and it's hardly reasonable to expect me to save my typos > up. > > Big +1 from me. Particularly for the docs, it'd be nice to have more committer bandwidth available, if there's a reasonable way to do so without causing needless merge work for existing committers. Like Peter, I hate to bother busy committers with trivial typofixes, and sometimes I just don't bother sending such changes in, and they get lost :-( Maybe keeping doc/ as a 'git submodule' could work? Or, as Tom suggests, adding a global committer who could focus on docs changes would effectively solve the problem as well. Josh
On Wed, Apr 11, 2012 at 18:29, Josh Kupershmidt <schmiddy@gmail.com> wrote: > On Wed, Apr 11, 2012 at 8:59 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote: >> On 11 April 2012 15:35, Magnus Hagander <magnus@hagander.net> wrote: > >>> For example, Thom (and others) could collect a number of typo fixes in >>> their own repo and then just ask for a merge.The advantage over just >>> staging multiple commits and then submitting a patch would be that >>> multiple people could work on it... >> >> This is hardly a radical idea at all - it's basically how git was >> really intended to be used at scale. Of course, unless some committer >> is going to make it their responsibility to merge those commits say >> every 3 months, there's no point in bothering. This could consolidate >> the number of typo commits to boot, as they could be rebased. TBH, I >> find it slightly embarrassing to have to ask a committer to fix a >> minor typo, and it's hardly reasonable to expect me to save my typos >> up. >> >> Big +1 from me. > > Particularly for the docs, it'd be nice to have more committer > bandwidth available, if there's a reasonable way to do so without > causing needless merge work for existing committers. Like Peter, I > hate to bother busy committers with trivial typofixes, and sometimes I > just don't bother sending such changes in, and they get lost :-( > > Maybe keeping doc/ as a 'git submodule' could work? Or, as Tom > suggests, adding a global committer who could focus on docs changes > would effectively solve the problem as well. git submodule would be a really bad idea imho. Then you couldn't make a single commit that deals with both code and docs. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Joshua Berkus <josh@agliodbs.com> writes:
> From my observation, the CF process ... in fact, all development
> processes we've had in Postgres ... have suffered from only one
> problem: lack of consensus on how the process should work. For
> example, we've *never* had consensus around the criteria for kicking
> a patch out of a commitfest.
True, but "put that decision entirely in the hands of the CF manager"
doesn't seem to me to be a workable solution. Half the time we
don't even have a CF manager, AFAICT. Now admittedly the opportunity
to wield absolute power might attract more interest in the position ;-)
but I don't think we want people who are attracted by that.
> Some suggestions:
> - for the first 2 weeks of each CF, there should be a *total* moritorium on discussing any features not in the
currentCF on -hackers.
We've tried that in the past, and it's never been adhered to very well,
and I think it's folly to assume that we'll get much better at it.
The nature of a mailing list is that there's a lot of noise. Even if
95% of the membership knows about and agrees with the restriction, the
other 5% will still post about non-CF stuff.
> - we should have simple rules for the CF manager for kicking patches, as in:
> * no response from author in 5 days
> * judged as needing substantial work by reviewer
> * feature needs spec discussion
These rules still seem to me to require a lot of judgment, hence
opportunity for argument. What's "substantial work"? How big a quibble
about the spec is big enough to get a patch booted?
> However, the real criteria don't matter as much as coming up with a set of criteria we're all willing to obey,
whateverthey are.
Ultimately, we're herding cats here. I don't think you're going to get
the community to suddenly be willing to march in lockstep instead.
regards, tom lane
On Wed, Apr 11, 2012 at 11:49 AM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Robert Haas's message of mié abr 11 12:44:02 -0300 2012: >> Me neither, but I don't know how far it scales. Having certain people >> who are defined as, say, doc-only committers will not only make it >> clear to those people what they're expected to commit, but also clear >> to everyone else who the people are who might commit any given patch >> they might write. If we just end up with 50 committers and you have >> to follow pgsql-hackers to understand who knows what and which people >> are even still around, it's not going to make anything easier for >> anyone. > > Since we're so keen on copying what Linux does, we could just have a > MAINTAINERS file. I'm actually not particularly keen on copying what Linux does. It seems that they have a lot of the same problems that we have, only worse. Unless you can get the proper person to take notice of your patch and merge it into his tree, from where it will get merged into somebody else's tree, from where it will eventually get merged into Linus's tree (maybe with one more tree in the path just for good measure), your patch is just going to fall on the floor and die. The lseek contention stuff in Linux 3.2 was submitted in substantially identical form years ago and didn't get merged - mostly, AFAICT, just because nobody cared about it enough. Our process is not perfect, but in recent years we have at least done a fairly good job preventing things from dying of apathy, even if not everybody agrees on which things ultimately should or should not have gotten committed. Small doc changes might be an exception. I used to apply those regularly, but I've had to fall back to making occasional sweeps of my pgsql-docs email box and looking for unresolved issues. Having a few more committers, and specifically people focused on documentation, would, I think, be a a step forward. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On ons, 2012-04-11 at 06:04 -0400, Greg Smith wrote: > Compare with: > > -Submitter suggests doc change > -No one has a strong opinion on it, may not be picked up at all > -Submitter adds to the next CF > -Wait for review > -[Possible repost update with reviewer changes] > -Ready for committer > -Committer takes time away from code review to look at it > -Possibly another feedback/review resubmission > -Commit final versions I totally get that. Just as a personal view, if people were to send me doc or "trivial" patches in git-am format, with proper commit message, and Acked or Signed-off etc. lines from recognized contributors, and proper References: mail header linked to the discussion or "suggestion" message, I could probably commit 20 of those in an hour. Instead, I have to review the entire email thread for discussion, any possible reviews or test runs, extract the patch from the email, mangle it into proper form, apply it, think of a commit message, make sure I register all the right people in the message, re-review the commit, push, reply to email, optionally, log into commit fest, find the patch, click a bunch of times, close it, done -- I think. That takes 15 minutes per patch, and after two patches like that I'm tired.
> Ultimately, we're herding cats here. I don't think you're going to > get > the community to suddenly be willing to march in lockstep instead. If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and Andrew agreed on a calendar-driven, mostly unambiguousprocess and adhered to that process, then the one or two people who didn't follow along wouldn't matter. Everyoneelse would follow you. The reason things are chaotic now is that our lead committers do not have consensus and areeven inconsistent from CF to CF individually. In other words: the problem is only unsolvable because *you* think it's unsolvable. If you decide the problem is solvable,you already have the means to solve it. --Josh Berkus
On ons, 2012-04-11 at 12:48 -0400, Tom Lane wrote: > > However, the real criteria don't matter as much as coming up with a > set of criteria we're all willing to obey, whatever they are. > > Ultimately, we're herding cats here. I don't think you're going to > get the community to suddenly be willing to march in lockstep > instead. Yeah, I think what's forgotten in this discussion is that we're all volunteers. (Even those who have jobs related to this are still volunteers with respect to the project.) So people will do whatever they want. If you don't let them do what they want, they will do it elsewhere. Now it's fine to encourage a little bit of team spirit and community values here and there, but you can't build your process on making people do what they don't want to do.
On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus <josh@agliodbs.com> wrote: >> Ultimately, we're herding cats here. I don't think you're going to >> get >> the community to suddenly be willing to march in lockstep instead. > > If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and Andrew agreed on a calendar-driven, mostly unambiguousprocess and adhered to that process, then the one or two people who didn't follow along wouldn't matter. Everyoneelse would follow you. The reason things are chaotic now is that our lead committers do not have consensus andare even inconsistent from CF to CF individually. > > In other words: the problem is only unsolvable because *you* think it's unsolvable. If you decide the problem is solvable,you already have the means to solve it. That's a somewhat bizarre list of people. It both includes people who haven't expressed many concerns about our process one way or the other and excludes some who have. At any rate, clearly the problem is exactly that there isn't consensus on this. I would generally say that Tom, Greg Smith, and I are pretty close together on this issue, and Peter G., Simon, and Dimitri are pretty close together on this issue, but with a big gap in between those two groups. I am less clear on how everyone else feels, but I think that saying that "all we need" is to get consensus among those people is to define the problem, not the solution. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Peter Eisentraut <peter_e@gmx.net> writes:
> Just as a personal view, if people were to send me doc or "trivial"
> patches in git-am format, with proper commit message, and Acked or
> Signed-off etc. lines from recognized contributors, and proper
> References: mail header linked to the discussion or "suggestion"
> message, I could probably commit 20 of those in an hour.
> Instead, I have to review the entire email thread for discussion, any
> possible reviews or test runs, extract the patch from the email, mangle
> it into proper form, apply it, think of a commit message, make sure I
> register all the right people in the message, re-review the commit,
> push, reply to email, optionally, log into commit fest, find the patch,
> click a bunch of times, close it, done -- I think. That takes 15
> minutes per patch, and after two patches like that I'm tired.
I hear you ... but, given that the source material is a mailing-list
thread, *somebody* has to do all that work to produce an acceptable
commit. And if you're just going to commit what that somebody sends you
without further review, then you might as well give that person a commit
bit, because you're trusting them to get all this right. So I'm not
sure how this moves us forward, other than to the obvious observation
that it'd be great if we had more qualified committers.
regards, tom lane
On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote: > I hear you ... but, given that the source material is a mailing-list > thread, *somebody* has to do all that work to produce an acceptable > commit. And if you're just going to commit what that somebody sends > you without further review, then you might as well give that person a > commit bit, because you're trusting them to get all this right. I'd still review it, but I'd be able to spend say 3 minutes on review and 30 seconds on committing it, versus 3 minutes on review, 3 minutes on research, and 8 minutes on bookkeeping.
On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote: >> I hear you ... but, given that the source material is a mailing-list >> thread, *somebody* has to do all that work to produce an acceptable >> commit. And if you're just going to commit what that somebody sends >> you without further review, then you might as well give that person a >> commit bit, because you're trusting them to get all this right. > > I'd still review it, but I'd be able to spend say 3 minutes on review > and 30 seconds on committing it, versus 3 minutes on review, 3 minutes > on research, and 8 minutes on bookkeeping. Well, I am not averse to figuring out a better workflow, or some better tools. In practice, I think it's going to be hard to reduce the time to review a trivial patch much below 5-10 minutes, which is what it takes me now, because you've got to read the email, download the patch, check that it doesn't break the build, review, commit, and push, and I can't really see any of those steps going away. But that doesn't mean we shouldn't make the attempt, because I've got to admit that the current workflow seems a little cumbersome to me, too. I'm not sure I have a better idea, though. git remotes seem useful for collaborating on topic branches, but I don't think they can really be expected to save much of anything during the final commit process - which is basically all the process there is, when the patch is trivial. Now what would be sort of neat is if we had a way to keep all the versions of patch X plus author and reviewer information, links to reviews and discussion, etc. in some sort of centralized place. The CommitFest app was actually designed to track a lot of this information, but it's obviously not completely succeeding in tracking everything that people care about - it only contains links to patches and not patches themselves; it doesn't have any place to store proposed commit messages; etc. There might be room for improvement there, although getting consensus on what improvement looks like may not be totally straightforward, since I think Tom's ideal process for submitting a patch starts with attaching a file to an email and many other people I think would like to see it start with a pull request. This is not entirely a tools issue, of course, but it's in there somewhere. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> I'd still review it, but I'd be able to spend say 3 minutes on review
>> and 30 seconds on committing it, versus 3 minutes on review, 3 minutes
>> on research, and 8 minutes on bookkeeping.
> Well, I am not averse to figuring out a better workflow, or some
> better tools. In practice, I think it's going to be hard to reduce
> the time to review a trivial patch much below 5-10 minutes, which is
> what it takes me now, because you've got to read the email, download
> the patch, check that it doesn't break the build, review, commit, and
> push, and I can't really see any of those steps going away. But that
> doesn't mean we shouldn't make the attempt, because I've got to admit
> that the current workflow seems a little cumbersome to me, too. I'm
> not sure I have a better idea, though. git remotes seem useful for
> collaborating on topic branches, but I don't think they can really be
> expected to save much of anything during the final commit process -
> which is basically all the process there is, when the patch is
> trivial.
> Now what would be sort of neat is if we had a way to keep all the
> versions of patch X plus author and reviewer information, links to
> reviews and discussion, etc. in some sort of centralized place. The
> CommitFest app was actually designed to track a lot of this
> information, but it's obviously not completely succeeding in tracking
> everything that people care about - it only contains links to patches
> and not patches themselves; it doesn't have any place to store
> proposed commit messages; etc. There might be room for improvement
> there, although getting consensus on what improvement looks like may
> not be totally straightforward, since I think Tom's ideal process for
> submitting a patch starts with attaching a file to an email and many
> other people I think would like to see it start with a pull request.
> This is not entirely a tools issue, of course, but it's in there
> somewhere.
It strikes me that there are two different scenarios being discussed
here, and we'd better be sure we keep them straight: small-to-trivial
patches, and complex patches.
I think that for the trivial case, what we need is less tooling not more.
Entering a patch in the CF app, updating and closing it will add a
not-small percentage to the total effort required to deal with a small
patch (as Peter already noted, and he wasn't even counting the time to
put the patch into CF initially). The only reason to even consider
doing that is to make sure the patch doesn't get forgotten. Perhaps
we could have some lighter-weight method of tracking such things?
At the other end of the scale, I think it's true that the CF app could
be more helpful than it is for tracking the state of complex patches.
I don't really have any concrete suggestions, other than that I've
seen far too many cases where the latest version of a patch was not
linked into the CF entry. Somehow we've got to make that more robust.
Maybe the answer is to tie things more directly into git workflows,
though I'm not sure about details. I am concerned about losing
traceability of submissions if all that ever shows up in the list
archives is a URL.
regards, tom lane
On Thu, Apr 12, 2012 at 05:49, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut <peter_e@gmx.net> wrote: >>> I'd still review it, but I'd be able to spend say 3 minutes on review >>> and 30 seconds on committing it, versus 3 minutes on review, 3 minutes >>> on research, and 8 minutes on bookkeeping. > >> Well, I am not averse to figuring out a better workflow, or some >> better tools. In practice, I think it's going to be hard to reduce >> the time to review a trivial patch much below 5-10 minutes, which is >> what it takes me now, because you've got to read the email, download >> the patch, check that it doesn't break the build, review, commit, and >> push, and I can't really see any of those steps going away. But that >> doesn't mean we shouldn't make the attempt, because I've got to admit >> that the current workflow seems a little cumbersome to me, too. I'm >> not sure I have a better idea, though. git remotes seem useful for >> collaborating on topic branches, but I don't think they can really be >> expected to save much of anything during the final commit process - >> which is basically all the process there is, when the patch is >> trivial. > >> Now what would be sort of neat is if we had a way to keep all the >> versions of patch X plus author and reviewer information, links to >> reviews and discussion, etc. in some sort of centralized place. The >> CommitFest app was actually designed to track a lot of this >> information, but it's obviously not completely succeeding in tracking >> everything that people care about - it only contains links to patches >> and not patches themselves; it doesn't have any place to store >> proposed commit messages; etc. There might be room for improvement >> there, although getting consensus on what improvement looks like may >> not be totally straightforward, since I think Tom's ideal process for >> submitting a patch starts with attaching a file to an email and many >> other people I think would like to see it start with a pull request. >> This is not entirely a tools issue, of course, but it's in there >> somewhere. > > It strikes me that there are two different scenarios being discussed > here, and we'd better be sure we keep them straight: small-to-trivial > patches, and complex patches. > > I think that for the trivial case, what we need is less tooling not more. > Entering a patch in the CF app, updating and closing it will add a > not-small percentage to the total effort required to deal with a small > patch (as Peter already noted, and he wasn't even counting the time to > put the patch into CF initially). The only reason to even consider > doing that is to make sure the patch doesn't get forgotten. Perhaps > we could have some lighter-weight method of tracking such things? If we were actually using git branches for it, the CF app could automatically close entries when they were committed. But that requires them to be committed *unmodified*, and I'm not sure that's reasonable. I also think requiring a git branch for the *simple* changes is adding more tooling and not less, and thus fails on that suggestion. It might be helpful (if the CF app had a trivial API) with a small tool that could run from a git hook (or manual script or alias) that would prompt for "which cf entry, if any, did this commit close"? > At the other end of the scale, I think it's true that the CF app could > be more helpful than it is for tracking the state of complex patches. > I don't really have any concrete suggestions, other than that I've > seen far too many cases where the latest version of a patch was not > linked into the CF entry. Somehow we've got to make that more robust. > Maybe the answer is to tie things more directly into git workflows, > though I'm not sure about details. I am concerned about losing > traceability of submissions if all that ever shows up in the list > archives is a URL. I've suggested before that it would be a good idea to be able to register a git repo + branch name in the commitfest app, and be able to track that. If it was smart enough to figure out that for something like github or bitbucket it could also add a web link (but keep the git link for whoever wants to pull it remotely) with the full differences to master, that would make *some* of those issues go away. (Certainly not all, it's not a magic solution, but I believe it would be a tool that could help). I've pretty much given up on that happening though... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Apr 10, 2012 at 08:43:12PM -0400, Greg Smith wrote:
> The main reason I worry about this is because of a very real
> chicken/egg problem here that I keep banging into. Since the commit
> standards for so many other open-source projects are low, there are
> a non trivial number of business people who assume "!committer ==
> ![trusted|competent]". That makes having such a limited number of
> people who can commit both a PR issue ("this project must not be
> very important if there are only 19 committers") and one limiting
> sponsorship ("I'm not going to pay someone to work on this feature
> who's been working on it for years but isn't even a committer").
>
> There are a significant number of companies who are willing to
> sponsor committers to open-source projects; there are almost none
> who will sponsor reviewers or "contributors" of any stature unless
> they're already deep into the PostgreSQL community. That's one of
> the many reasons it's easier for a committer to attract funding for
> core PostgreSQL work, be it in the form of a full-time job or
> project-oriented funding. The corresponding flip side to that is
> that the small number of committers is limiting the scope of funding
> the project can accumulate.
I want to caution against adjusting things to improve funding
possibilities. There is nothing wrong with increasing funding
possibilities, per say, but such changes often distort behavior in
unforeseen ways that adversely affect our community process.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
Excerpts from Tom Lane's message of jue abr 12 00:49:38 -0300 2012: > At the other end of the scale, I think it's true that the CF app could > be more helpful than it is for tracking the state of complex patches. > I don't really have any concrete suggestions, other than that I've > seen far too many cases where the latest version of a patch was not > linked into the CF entry. Somehow we've got to make that more robust. > Maybe the answer is to tie things more directly into git workflows, > though I'm not sure about details. I am concerned about losing > traceability of submissions if all that ever shows up in the list > archives is a URL. Two suggestions: 1. it might be convenient to have the patch author attach a suggested commit message to the patch entry in the commifest site. Would save some jiffies for the trivial patch case, I hope. 2. instead of just sending a URL to the list, maybe it'd be better if the patch is uploaded to the CF site, and the CF site sends it to pgsql-hackers for archival and reference, with appropriate In-Reply-To headers so that it is appropriately linked to the thread. But since the patch has been registered into the CF, the site can additionally present a link to download the patch directly instead of sending you to the archives. So redundant storage, for convenience. (Alternatively, the CF app could reach into archives to grab the patch file. With some appropriate ajaxy stuff this shouldn't be particularly hard.) -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On 12 April 2012 13:45, Bruce Momjian <bruce@momjian.us> wrote: > I want to caution against adjusting things to improve funding > possibilities. There is nothing wrong with increasing funding > possibilities, per say, but such changes often distort behavior in > unforeseen ways that adversely affect our community process. Funding is a necessary component of what we do. So, for example, while I'm very glad that EnterpriseDB afford various people the opportunity to work on community stuff for a significant proportion of their time - I do, after all, indirectly benefit from it - it is rather obviously the case that the particular things that those people work on is influenced to some degree by management. That is an assessment that isn't based on any particular observation about the things that EDB people work on. It's just common sense. This generally isn't a bad thing, since I think that the goals of the Postgres companies are broadly aligned with those of the community. When you get right down to it though, as Tom said, we are a herd of cats, and it isn't particularly obvious that we've zeroed in on some specific vision that we all agree on that must be pursued without diversion. Given the extensibility of Postgres, it isn't usually necessary for anyone to pursue development of a feature that is clearly of niche interest, that we don't really want to have to support. I cannot think of any example of a proposed patch that mostly just scratched some particular organisation's itch. No one is able to hoodwink the community like that. People have always wanted to get their patches accepted, and we've always had high standards. The fact that there might be an additional financial incentive to do so doesn't seem to fundamentally alter that dynamic. It is not a coincidence that I did not send any code to -hackers prior to joining 2ndQuadrant. I certainly had the enthusiasm for it, but I could not afford to dedicate sufficient time. With the kind of dedication required to make a noticeable contribution, this is hardly surprising. There are some good counter-examples of this of course - one in particular that comes to mind is Greg Smith's work on the background writer that made it into 8.3 . However, the general trend is that somebody has to pay for this work for it to be maintainable over months and years, even with the level of dedication that we all have. Something that I would suggest is that those that are receiving funding be transparent about it. It isn't essential of course, but to do any less might lead to the perception of there being a conflict of interests in some people's minds, which is best avoided. I am conscious of the fact that I've expressed lots of opinions on this thread on our processes and so on, some of which, if followed through on, would be quite large departures. I hope that they were received as modest suggestions. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
On 04/11/2012 10:24 AM, Tom Lane wrote: > Greg Smith<greg@2ndQuadrant.com> writes: >> I'd like to dump around 50 pages of new material into the docs as a >> start, but I don't want to take so much time away from the code oriented >> committers to chew on that much. > > Well, with all due respect, that does not sound like a change that > doesn't need review. I wasn't trying to suggest large changes should be made without review. I'd just like some new paths for work to progresswithout one of the more coding oriented committers being compelled to join and keep up with everything. The quality level I aimed for in my book wouldn't have been possible without Kevin Grittner, Scott Marlowe, and Jim Mlodgenski as reviewers; it didn't require anyone with commit bits though. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
> If we were actually using git branches for it, the CF app could > automatically close entries when they were committed. But that > requires them to be committed *unmodified*, and I'm not sure that's > reasonable. I also think requiring a git branch for the *simple* > changes is adding more tooling and not less, and thus fails on that > suggestion. Well actually, the other advantage of using branches is that it would encourage committers to bounce a patch back to thesubmitter for modification *instead of* doing it themselves. This would both have the advantage of saving time for thecommitter, and doing a better job of teaching submitters how to craft patches which don't need to be modified. Ultimately,we need to train new major contributors in order to get past the current bottleneck. Of course, this doesn't work as well for contributors who *can't* improve their patches, such as folks who have a languagebarrier with the comments. But it's something to think about. --Josh
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I want to caution against adjusting things to improve funding > possibilities. There is nothing wrong with increasing funding > possibilities, per say, but such changes often distort behavior in > unforeseen ways that adversely affect our community process. I don't see this as much of a problem. If somewhat arbitrary labels and powers allow the project to succeed, we should think long and hard before rejecting the idea. It's not like we are going to make anyone who asks a committer, like MediaWiki does. Indeed, we have been super cautious about handing out both commit bits, and labels (e.g. "Major Developer"). One wrinkle is the subsystems: there are some people who only work on certain parts, yet have a commit bit (with the understanding that they won't start editing core or other parts). From an outside perspective however, a "Postgres committer [of certain subsystems]" is a "Postgres committer". One thing I think would help potential and current developers, and act as a further code review and safety valve, is to have a mailing list that actually shows the committed diffs. Links to a webpage showing the diff is just not the same. pgsql-commit-diffs@postgresql.org, anyone? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201204121121 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk+G8/sACgkQvJuQZxSWSsh7HACgn7Wf/AQyUJwtvxgjYSHSIHkJ hq4AnjMgPlDakupg4mo204+N1p4C0mMZ =z+cR -----END PGP SIGNATURE-----
On Thu, Apr 12, 2012 at 03:34:31PM +0100, Peter Geoghegan wrote:
> Something that I would suggest is that those that are receiving
> funding be transparent about it. It isn't essential of course, but to
> do any less might lead to the perception of there being a conflict of
> interests in some people's minds, which is best avoided.
>
> I am conscious of the fact that I've expressed lots of opinions on
> this thread on our processes and so on, some of which, if followed
> through on, would be quite large departures. I hope that they were
> received as modest suggestions.
I appreciate everything everyone said in this thread, and I can't think
of an example off the top of my head where vendors adversely affected
our process. I think the _big_ reason for that is that our community
members have always acted with a "community first" attitude that has
insulated us from many of the pressures vendors can place on the
development process. I am sure that protection will continue --- I just
wanted to point out that it is a necessary protection so we can all be
proud of our released code and feature set, and continue working as a
well-coordinated team.
The specific suggestion that vendors are not taking contributors
seriously unless they have commit-bits is perhaps something that
requires education of vendors, or perhaps my blogging about this will
help. Greg Smith's analysis really hit home with me:
> a non trivial number of business people who assume "!committer ==
> ![trusted|competent]". That makes having such a limited number of
> people who can commit both a PR issue ("this project must not be
> very important if there are only 19 committers") and one limiting
> sponsorship ("I'm not going to pay someone to work on this feature
> who's been working on it for years but isn't even a committer").
I think the big take-away, education-wise, is that for our project,
committer == grunt work. Remember, I used to be the big committer of
non-committer patches --- need I say more. ;-) LOL
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
> I think the big take-away, education-wise, is that for our project, > committer == grunt work. Remember, I used to be the big committer of > non-committer patches --- need I say more. ;-) LOL Well, promoting several people to committer specifically and publically because of their review work would send that messagea lot more strongly than your blog would. It would also provide an incentive for a few of our major contributorsto do more review work, if it got them to committer. --Josh Berkus
On Thu, Apr 12, 2012 at 11:34:48AM -0400, Bruce Momjian wrote: > On Thu, Apr 12, 2012 at 03:34:31PM +0100, Peter Geoghegan wrote: > > Something that I would suggest is that those that are receiving > > funding be transparent about it. It isn't essential of course, but to > > do any less might lead to the perception of there being a conflict of > > interests in some people's minds, which is best avoided. > > > > I am conscious of the fact that I've expressed lots of opinions on > > this thread on our processes and so on, some of which, if followed > > through on, would be quite large departures. I hope that they were > > received as modest suggestions. > > I appreciate everything everyone said in this thread, and I can't think > of an example off the top of my head where vendors adversely affected > our process. I think the _big_ reason for that is that our community > members have always acted with a "community first" attitude that has > insulated us from many of the pressures vendors can place on the > development process. I am sure that protection will continue --- I just > wanted to point out that it is a necessary protection so we can all be > proud of our released code and feature set, and continue working as a > well-coordinated team. Let me add one more thing. As someone who has been funded for Postgres work since 2000, I am certainly "pro-funding"! Since our community members have a "community first" attitude, it is the community's responsibility to help them get funding. We have thrown around a few ideas in this thread, but perhaps someone should start a new email thread with first-hand suggestions of how we can help people get funding. I am certainly ready to help however I can. My reason for replying to this thread was to highlight our valuable "community first" attitude. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On 04/12/2012 11:34 AM, Bruce Momjian wrote: > The specific suggestion that vendors are not taking contributors > seriously unless they have commit-bits is perhaps something that > requires education of vendors, or perhaps my blogging about this will > help. I'm glad I managed to vent my frustration in this area in a way that was helpful. Just recognize that any experienced person at pitching software solutions will tell you to never wander down this path at all. If you have to tell someone a story and make themadmit they're wrong about something as an early step toward adoption, you've just dumped a home-made FUD bomb on them. It's not a high percentage path toward credibility. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Wed, Apr 11, 2012 at 12:00:39PM -0300, Alvaro Herrera wrote: > remote in their main PG tree, and so changesets could be pulled into the > same clone and cherry-picked into the master branch. If you're talking about a way of using git to support reviewing, the Gerrit tool has an interesting workflow. Essentially anything you want reviewed you push to a fake tag refs/for/master which always creates a new branch. As such you have a repository which contains every patch ever submitted, but it simultaneously tracks the parents so you know which version of the tree a patch was against. In the case of Postgres each entry in the CF app would have its own tag (say refs/cf/234) which would create a new patch for that entry. In the end accepted patches are cherry-picked onto the real tree. But because all patches are now in the same place you can build tooling around it easier, like testing: does this patch cherry-pick cleanly or is there a conflict. No merge commits, just using git purely as patch storage. (Note to make this work it has a git server emulation which may or may not be easy to do, but it's just a thought about workflow.) Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
Alvaro Herrera wrote: > Now what would be sort of neat is if we had a way to keep all the > versions of patch X plus author and reviewer information, links to > reviews and discussion, etc. in some sort of centralized place. FWIW: y'all might have discussed to death during the git migration, so *please* do not let me derail you if so... github does a great job of exactly this. You open an issue, you reference it from commits, all the related commits are listed in (and browseable from) the issue, you can comment on specific lines of the commit, it integrates w/email, it has an API to write tools (both workflow and archival) against, etc. Rather than extend the CF app into a trivial-patch workflow app, it might be worth looking at integrating it with github. Jay Levitt
On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt <jay.levitt@gmail.com> wrote: > Rather than extend the CF app into a trivial-patch workflow app, it might be > worth looking at integrating it with github. There's a reluctance to require a proprietary component that could disappear on us without notice. The existence of git itself is a result of *exactly* that circumstance, as Linux kernel developers had gotten dependent on BitKeeper, whereupon the owner decided to take his toys home, at which point they were left bereft of "their" SCM tool. <http://kerneltrap.org/node/4966> I expect that it would be more worthwhile to look into enhancements to git workflow such as <http://code.google.com/p/gerrit/> Gerrit. I don't know that Gerrit is THE answer, but there are certainly projects that have found it of value, and it doesn't have the "oops, it's proprietary" problem. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Robert Haas <robertmhaas@gmail.com> writes: > Even before this CommitFest, it's felt to me like this hasn't been a > great cycle for reviewing. I think we have generally had fewer people > doing reviews than we did during the 9.0 and 9.1 cycles. I think we > had a lot of momentum with the CommitFest process when it was new, but > three years on I think there's been some ebbing of the relative > enthusiastic volunteerism that got off the ground. I don't have a I have another analysis here. Tom once said that commiters won't grow on tree, and that is true for submitters too, obviously. I think the CF process has been good into growing more submitters and growing existing ones abilities too. So you don't have that fewer reviewers available, it may be that they're just heavily involved into being submitters too. Tom Lane <tgl@sss.pgh.pa.us> writes: > Yeah, this is something I was thinking about yesterday. In the first > couple of release cycles with the CommitFest process, we were willing to > let the last fest of a release cycle go on for "as long as it takes", > or at least that was what I felt the policy to be. This time we > eventually gave up and declared closure, but in hindsight we should > likely have done that a month earlier. The fact of the matter is that > quite a few of the patches we were dealing with were *not* ready to > commit, or even close to that, at the start of the fest. If it weren't > the last fest they would have gotten marked Returned With Feedback a > lot sooner. This and other posts in this threads are all hinting the same thing to me: the last commit fest is *not* about feedback at all. If you still need reviewers rather than commiters, you're out of luck for this release, see you next time. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Tom Lane <tgl@sss.pgh.pa.us> writes: > Andres Freund <andres@anarazel.de> writes: >> They might have been half-baked. But several of those didn't get design-level >> review for several weeks which makes it rather hard to fully bake them in >> time... > > But if they didn't already have design-level review, that means they > were not seen in any previous CF, which means they were not following > the expectation that nontrivial patches should be submitted earlier than > the last CF. That's not true, unfortunately. I had several rounds of design review in the previous CF, then some more in the last CF, then another one that basically meant baking another patch: same feature but spelled out differently (renaming catalog, files and APIs is no fun in a big patch) to be able to have a new way to organize the code and docs. It's for the best, and it's better to do that before commit, no question. I appreciate having had that review, really. The problem with the command trigger has been another one. First, if we want the last CF to be only about commits and not about feedback, we should simply bite the bullet and spell it out loud. Second, we should have been talking about the hard decision rather than pretending we could still do something in this release. That's mainly on me and I know it, but not being a commiter I have no other power than influence, and I've been optimistic (and playing by the rules). > I think the key point here is that people have to expect that it's going > to take more than one round of review to land most nontrivial patches. > And we have to discourage the expectation that that can happen within > the last CF of a release cycle. If anything, the last CF has to be > tighter not looser than others on what we will accept, because there is > no time to recover if something proves wrong with a patch after a > month or three. The more I think about that, the more I think we should declare the last CF to be about preparing a release, not providing another round of feedback. That could well be all we need here. > I keep coming back to the thought that we need more and shorter CFs, > and/or ReviewFests that are meant to help push WIP patches further > down the track. We need to make it easier to get those early reviews > done while there's still development time left. Separating away commit fest made for commits and those meant for feedback is a good idea too. I'm not sure how much benefit we would get there for non-last CFs, though. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Robert Haas <robertmhaas@gmail.com> writes: > The real problem with the command triggers patch is that we got a > blizzard of code. It's unrealistic to expect anyone to devote serious > review time to a patch that's under constant development. It also > strikes me that a tremendous amount of pain could have been avoided by > posting a clear and detailed design sketch for that patch before > beginning to code. Dimitri contended that without code, no one will > read design sketches, but that doesn't for the most part jive with my > experience, and I think that the strategy he actually chose backfired, > because it was clear that any review would be hitting a moving target. In my mind at least it's been more subtle. I had an agreed-on design months before I started to code anything, at the Cluster Hackers Meeting in Ottawa, where several commiters and long term contributors have been participating in the discussion. The big mistake seems to be starting to code with that rather than spending another couple of months (or easily way more than that) of rehashing it on-list. About the design sketches, IME, what you can agree on on-list is a very high level view about how to implement a feature, anything detailed enough to have practical impact on the code you're writing happens while reviewing code. Again, as I though the high level view was ok as of the Cluster Hackers Meeting, I skipped that part and went directly to the code level review. Greg Smith will certainly stamp that email with a big red “Lesson Learned” stamp here: nothing happened if you don't have a link to a pgsql-hackers thread on the archives. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
On tor, 2012-04-12 at 10:12 -0500, Joshua Berkus wrote: > Well actually, the other advantage of using branches is that it would > encourage committers to bounce a patch back to the submitter for > modification *instead of* doing it themselves. This would both have > the advantage of saving time for the committer, and doing a better job > of teaching submitters how to craft patches which don't need to be > modified. I don't see how using branches changes that. You could (or should) be doing that already anyway.
On ons, 2012-04-11 at 23:30 -0400, Robert Haas wrote: > Now what would be sort of neat is if we had a way to keep all the > versions of patch X plus author and reviewer information, links to > reviews and discussion, etc. in some sort of centralized place. Well, a properly linked email thread contains all this. I have seen a couple of anti-patterns evolving, though, including patch authors starting a new email thread for each patch version, and reviewers starting a new email thread for each review. When that happens, the existence of the commitfest app makes things worse, in a way. (Of course, any discussion here about bug trackers emphasizes the need for email to be the primary communications method for this very reason.)
On tor, 2012-04-12 at 07:59 +0200, Magnus Hagander wrote: > It might be helpful (if the CF app had a trivial API) with a small > tool that could run from a git hook (or manual script or alias) that > would prompt for "which cf entry, if any, did this commit close"? An API for the CF app would actually be nice in general, because then I could write an small command-line tool and just type 'cf close 123' or something instead of having to click around a bunch of times.
On tor, 2012-04-12 at 18:19 -0400, Christopher Browne wrote: > On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt <jay.levitt@gmail.com> wrote: > > Rather than extend the CF app into a trivial-patch workflow app, it might be > > worth looking at integrating it with github. > > There's a reluctance to require a proprietary component that could > disappear on us without notice. Yeah, I think initially this was more of a matter-of-principle decision, but seeing the current spam problem on github.com, I'm glad we didn't do it. For me it has disqualified itself as a platform for intense collaborative development.
Peter Eisentraut <peter_e@gmx.net> writes: > On ons, 2012-04-11 at 23:30 -0400, Robert Haas wrote: >> Now what would be sort of neat is if we had a way to keep all the >> versions of patch X plus author and reviewer information, links to >> reviews and discussion, etc. in some sort of centralized place. > > Well, a properly linked email thread contains all this. I have seen a > couple of anti-patterns evolving, though, including patch authors > starting a new email thread for each patch version, and reviewers > starting a new email thread for each review. When that happens, the > existence of the commitfest app makes things worse, in a way. (Of > course, any discussion here about bug trackers emphasizes the need for > email to be the primary communications method for this very reason.) I didn't follow this whole thread, but have we considered Redmine[1]? We at CMD rely on it as the primary means of customer communication, via email. New email to a mailing list backed by Redmine triggers new ticket creation and any followups result into an update to the ticket. The ticket history is searchable, browsable (and updateable) on the web. It's GPL-ed, uses Ruby on Rails, and comes with a broad range of plugins[2]. Also it is quite hackable (for a RoR guy, of course.) We could integrate Redmine with the CommitFest or even replace it completely with a custom-written plugin. A command line interface[3] exists, so 'cf close ###' suggested further in this thread should be also possible. -- Regards, Alex [1] http://www.redmine.org/ [2] http://www.redmine.org/plugins [3] https://github.com/diasjorge/redmine-cli
On 04/14/2012 03:02 AM, Alex wrote: > I didn't follow this whole thread, but have we considered Redmine[1]? It comes up every couple of years in contexts near this one, such as http://wiki.postgresql.org/wiki/TrackerDiscussion -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Greg Smith <greg@2ndQuadrant.com> writes: > On 04/14/2012 03:02 AM, Alex wrote: >> I didn't follow this whole thread, but have we considered Redmine[1]? > > It comes up every couple of years in contexts near this one, such as > http://wiki.postgresql.org/wiki/TrackerDiscussion Oh, I see. I wonder maybe it is time to actually take some action? Given that the list of disadvantages on that wiki page looks really bad (to me.) -- Alex
Alex <ash@commandprompt.com> writes: > Greg Smith <greg@2ndQuadrant.com> writes: > >> On 04/14/2012 03:02 AM, Alex wrote: >>> I didn't follow this whole thread, but have we considered Redmine[1]? >> >> It comes up every couple of years in contexts near this one, such as >> http://wiki.postgresql.org/wiki/TrackerDiscussion > > Oh, I see. I wonder maybe it is time to actually take some action? > Given that the list of disadvantages on that wiki page looks really bad > (to me.) Err, the list of Disadvantages of Current Situation I mean.
Christopher Browne wrote: > On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt<jay.levitt@gmail.com> wrote: >> Rather than extend the CF app into a trivial-patch workflow app, it might be >> worth looking at integrating it with github. > > There's a reluctance to require a proprietary component that could > disappear on us without notice. Excellent point. I was thinking that GitHub's API would allow archival exporting to counter that, along the lines of "let's take advantage of it for the next five years until it goes south, and THEN we could write our own". But I can see how that might not be the best choice for a project that expects to preserve history for a few decades. GitHub does offer an "enterprise version" that you can self-host, but it seems to be priced per-user and intended for solely intranet use. If the feature set is desirable, though, I wonder if Postgres is big/high profile enough for them to figure out some sort of better arrangement. They *love* it when big open-source projects use GitHub as their public repo - they'll email and blog announcements about it - and if there's interest I'd be happy to open a conversation with them. > The existence of git itself is a result of *exactly* that > circumstance, as Linux kernel developers had gotten dependent on > BitKeeper, whereupon the owner decided to take his toys home, at which > point they were left bereft of "their" SCM tool. > <http://kerneltrap.org/node/4966> Good history lesson there, with a great outcome. > I expect that it would be more worthwhile to look into enhancements to > git workflow such as<http://code.google.com/p/gerrit/> Gerrit. I > don't know that Gerrit is THE answer, but there are certainly projects > that have found it of value, and it doesn't have the "oops, it's > proprietary" problem. I've looked at it in conjunction with Jenkins CI; it looked nice but was way too heavy-weight for a four-person startup (what's code review?). It's probably much more suitable for this sized project. Gerrit's a full-featured code review app with a tolerable UI; I was thinking of GitHub more as a great lightweight UI for doc patches and other trivial patches where you might have lots of casual review and comments but no need for, say, recording regression tests against each patch version. e.g.: https://github.com/rails/rails/pull/5730 Also, for doc patches, GitHub has the great advantage of in-place editing right from the web UI. Peter mentioned the desire to bring more eyes and hands onto these type of patches - I think the phrase was "enthusiast power users who wouldn't really consider themselves hackers." The advantage of GitHub here would be its (current) widespread adoption; the perceived barrier to entry is far lower and the workflow is far more obvious than a mailing list, formatting patches by email, not quite knowing what the process is. I mention all this not to try to push GitHub specifically, but to say "these are the types of features that modern, open-source collaborative systems offer, and could improve community involvement". From a human- rather than technology-oriented perspective: I was shocked to find that you folks *WANT* reviews from non-contributors. It was my assumption as a newcomer that if I don't feel well-versed enough to submit patches yet, the last thing you'd want me to do was to look over someone else's patch and say "Yeah, that looks good", any more than I care if my mom thinks my latest web app is "very nice". I see now that the "Reviewing a Patch" wiki page explains this, but maybe this info should be pushed higher into the docs and web site; a "How can I contribute" page, open calls for reviewers on the non-hackers mailing lists, things like that. Or maybe just make the wiki page bright red and blink a lot. Jay
Alex wrote: > I didn't follow this whole thread, but have we considered Redmine[1]? As the resident "Ruby is shiny, let's do everything in Rails on my MacBook" guy, I'd like to make a statement against interest: I've tried Redmine a few times and it's been painful. Much of the codebase is deprecated, it's slow, it has no meaningful search (in 2012?!), I've seen wiki edits disappear, and at the moment pulling up its own FAQ page at redmine.org times out. Maybe you've had better luck with it, but whenever I've Googled for Redmine questions, the collective Internet has sighed and said "Yeah, it was a really good idea, though." Jay Levitt
On Tue, Apr 10, 2012 at 8:43 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> The main reason I worry about this is because of a very real chicken/egg
> problem here that I keep banging into. Since the commit standards for so
> many other open-source projects are low, there are a non trivial number of
> business people who assume "!committer == ![trusted|competent]". That makes
> having such a limited number of people who can commit both a PR issue ("this
> project must not be very important if there are only 19 committers") and one
> limiting sponsorship ("I'm not going to pay someone to work on this feature
> who's been working on it for years but isn't even a committer").
I'm not sure what the best way to address this problem is, but I don't
think it's to make more people committers if they aren't truly
qualified. If someone's work is going to require substantial
revision, it is much better and much less work to do that revision
before the code goes into our repository (and particularly, before it
gets released) rather than after. And, on a related note, I am having
a hard time imagining that it's a good idea to give very many people
commit bits primarily so that they can commit their own work. We
could create quite a few such committers and not really solve whatever
bottleneck exists here. What we really need are committers who are
willing and able to spend the time to do high-quality reviews of other
people's work.
I find this whole line of thinking particularly troubling in view of
Peter's comments that contributors face a prisoner's dilemma situation
and will inevitably push their own patches forward at the expense of
other people's patches. That behavior is only a mild nuisance when
people without a commit bit do it, but it's potentially a lot more
disruptive if someone who has a commit bit does it, because the
default for whether the patch gets committed flips from no to yes. I
think our committers need to be people we can trust enough NOT to
engage in such behavior.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Jay Levitt <jay.levitt@gmail.com> writes: > Alex wrote: >> I didn't follow this whole thread, but have we considered Redmine[1]? > > As the resident "Ruby is shiny, let's do everything in Rails on my > MacBook" guy, I'd like to make a statement against interest: I've > tried Redmine a few times and it's been painful. Much of the codebase > is deprecated, it's slow, it has no meaningful search (in 2012?!), > I've seen wiki edits disappear, and at the moment pulling up its own > FAQ page at redmine.org times out. Yay, that's totally FUD to me. Could you please elaborate a bit on your points? Deprecated codebase? Let me guess... It runs on an outdated version of Rails (2.3) but only because Rails is changing so rapidly, I believe. There is work in progress[1] to move to the supported branch Rails-3.x. Slow? Do you have any data to back this point up? No meaningful search, eh? Works for me. Disappearing wiki edits? Never seen that, but you can always file a bug. > Maybe you've had better luck with it, but whenever I've Googled for > Redmine questions, the collective Internet has sighed and said "Yeah, > it was a really good idea, though." Certainly *you've* had some terrible luck with it. ;-) -- Regards, Alex [1] http://www.redmine.org/issues/4796
On Sat, Apr 14, 2012 at 2:28 PM, Jay Levitt <jay.levitt@gmail.com> wrote: > Christopher Browne wrote: >> >> On Thu, Apr 12, 2012 at 6:11 PM, Jay Levitt<jay.levitt@gmail.com> wrote: >>> >>> Rather than extend the CF app into a trivial-patch workflow app, it might >>> be >>> worth looking at integrating it with github. >> >> >> There's a reluctance to require a proprietary component that could >> disappear on us without notice. > > > Excellent point. I was thinking that GitHub's API would allow archival > exporting to counter that, along the lines of "let's take advantage of it > for the next five years until it goes south, and THEN we could write our > own". But I can see how that might not be the best choice for a project that > expects to preserve history for a few decades. > > GitHub does offer an "enterprise version" that you can self-host, but it > seems to be priced per-user and intended for solely intranet use. > > If the feature set is desirable, though, I wonder if Postgres is big/high > profile enough for them to figure out some sort of better arrangement. They > *love* it when big open-source projects use GitHub as their public repo - > they'll email and blog announcements about it - and if there's interest I'd > be happy to open a conversation with them. > > >> The existence of git itself is a result of *exactly* that >> circumstance, as Linux kernel developers had gotten dependent on >> BitKeeper, whereupon the owner decided to take his toys home, at which >> point they were left bereft of "their" SCM tool. >> <http://kerneltrap.org/node/4966> > > > Good history lesson there, with a great outcome. > > >> I expect that it would be more worthwhile to look into enhancements to >> git workflow such as<http://code.google.com/p/gerrit/> Gerrit. I >> don't know that Gerrit is THE answer, but there are certainly projects >> that have found it of value, and it doesn't have the "oops, it's >> proprietary" problem. > > > I've looked at it in conjunction with Jenkins CI; it looked nice but was way > too heavy-weight for a four-person startup (what's code review?). It's > probably much more suitable for this sized project. > > Gerrit's a full-featured code review app with a tolerable UI; I was thinking > of GitHub more as a great lightweight UI for doc patches and other trivial > patches where you might have lots of casual review and comments but no need > for, say, recording regression tests against each patch version. e.g.: > > https://github.com/rails/rails/pull/5730 > > Also, for doc patches, GitHub has the great advantage of in-place editing > right from the web UI. I don't know if GitHub's pull request or Gerrit is a good tool (I doubt, actually), but I've been thinking how we could improve our review process in terms of both of human process perspective and tool process. As we have our simple CF app (while there are a bunch of tools like JIRA or something), I'd think we could have our own review UI connected to the rest of our toolset including CF app. I know we want the mail archive history of the whole discussion, but still giving feedback to the submitter via email is hard-work and the successors cannot read it entirely. > From a human- rather than technology-oriented perspective: I was shocked to > find that you folks *WANT* reviews from non-contributors. It was my > assumption as a newcomer that if I don't feel well-versed enough to submit > patches yet, the last thing you'd want me to do was to look over someone > else's patch and say "Yeah, that looks good", any more than I care if my mom > thinks my latest web app is "very nice". > > I see now that the "Reviewing a Patch" wiki page explains this, but maybe > this info should be pushed higher into the docs and web site; a "How can I > contribute" page, open calls for reviewers on the non-hackers mailing lists, > things like that. Or maybe just make the wiki page bright red and blink a > lot. I found myself enjoying reviewing other patches where I don't have strong knowledge. I strongly believe we should encourage more and more people who haven't worked particular patches in that area, to review patches. The more eyeballs there are, the more quality we get. Thanks, -- Hitoshi Harada
On Fri, Apr 6, 2012 at 8:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Smith <greg@2ndQuadrant.com> writes: >> On 04/05/2012 04:27 PM, Simon Riggs wrote: >>> It's shocking since after months of work and an especially extended >>> edition CF, we expect people to deliver something, not just shunt the >>> whole thing off as rejected with 1 days's notice to alter that >>> outcome. > >> I don't think this is being fair to Robert. > > If we're going to ship a release at all, somebody's got to be willing > to say "no". Personally, been there, done that, got the t-shirt [1]. > Robert's just pointing out what has to be pointed out. Just returned from a week away, so I'm chipping in on key points only. I accept the command trigger patch is gone now and I would add comments only about our processes. The problem remains that we have wasted many months of development and slipped a release on what appears to be an important, universally popular feature that had bucket loads of early planning. We shouldn't hide from recognising that as an issue. I completely agree that somebody has to be willing to say No, since we all agree that the default for any patch is non-acceptance. My first observation is that if No is received early enough for something to be done, then the outcome could be different. It was not clear that this important patch was going to be totally refused and many people have expressed their surprise about that. Noah signalled to everybody that the FK locks patch was likely to be rejected and a number of us have tried hard to save that, unluckily as it turns out. So an early No helped people allocate their time on what they considered to be important. In contrast the Command Triggers and FKs for arrays patches received a No so late that nothing could be done. So I fully agree that people should say No, but the key point is *when* they say it. For the future, I think we should have a triage week as the first week in each CF; lets shake out the No comments early - in some cases nothing can be done and we can refocus attention onto important topics. Second, my point was that No should not be applied in black/white form if at all possible. If some aspect of a patch is unworkable, it may be possible to provide some of the functionality, rather than simply nothing at all. That wasn't possible with FK locks, and maybe it was possible with command triggers. I do consider it the responsibility of a reviewer to salvage as much as is easily and reasonably possible from each contribution. In most cases that requires a few words from the reviewer, since many patch contributors listen carefully to what is said and try hard to make changes that work. Frequently I see reviewers simply making authors dance around with various additions and tweaks; all very well if the patch is acceptable, but its just a waste of time if there is no route to acceptance laid out clearly by the reviewer. That's something I've mentioned before: the reviewer *must* supply a list of things which, if solved, would allow the patch to be accepted. Clearly there will always be last minute issues that cause rejection. If we can get our information transfer a little slicker we'd be able to find more review time. Instead of spending months on their own dead patches, people would be available to assist on those with a chance to be saved. Our problem is not lack of resource, it is ineffective delegation. As Hannu points out, he didn't know the patch would be rejected, so he didn't know help was needed to save something useful. I considered that the job of the CF manager, but perhaps it is was not. In any case, it would seem best for the future if the CF manager was not also a committer, since those people are clearly too busy to do both roles as well as the project needs them to be. Just as our processes evolved into the creation of CFs and a CF manager, we must evolve again towards someone/team whose main task is ensuring that the delegation problem is solved. That won't work by bossing people around, it has to work by informing and encouraging people to contribute in the ways that they wish. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Wed, Apr 11, 2012 at 6:59 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Apr 11, 2012 at 1:39 PM, Joshua Berkus <josh@agliodbs.com> wrote: >>> Ultimately, we're herding cats here. I don't think you're going to >>> get >>> the community to suddenly be willing to march in lockstep instead. >> >> If you, Peter, Simon, Robert, Heikki, Magnus, Peter G., Greg, Bruce and Andrew agreed on a calendar-driven, mostly unambiguousprocess and adhered to that process, then the one or two people who didn't follow along wouldn't matter. Everyoneelse would follow you. The reason things are chaotic now is that our lead committers do not have consensus andare even inconsistent from CF to CF individually. >> >> In other words: the problem is only unsolvable because *you* think it's unsolvable. If you decide the problem is solvable,you already have the means to solve it. > > That's a somewhat bizarre list of people. It both includes people who > haven't expressed many concerns about our process one way or the other > and excludes some who have. At any rate, clearly the problem is > exactly that there isn't consensus on this. I would generally say > that Tom, Greg Smith, and I are pretty close together on this issue, > and Peter G., Simon, and Dimitri are pretty close together on this > issue, but with a big gap in between those two groups. I am less > clear on how everyone else feels, but I think that saying that "all we > need" is to get consensus among those people is to define the problem, > not the solution. Having just come back from a week away, I'm not really clear what you mean by "this issue". It worries me greatly to see my name in a divisive list like that. There are no teams here; each issue needs to be judged on its own, independently of each other and without regard to the person speaking. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Sat, Apr 7, 2012 at 10:20 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> [ among other good points ] >> ... On a related note, letting CommitFests go on for three >> months because there's insufficient reviewer activity to get them done >> in one or two is, in my opinion, not much of a solution. If there's >> even less reviewer activity next time, are we going to let it go on >> for four months? Six months? Twelve months? At some point, it boils >> down to "we're just going to stop accepting patches for an indefinite >> period of time". Yuck. > > Yeah, this is something I was thinking about yesterday. In the first > couple of release cycles with the CommitFest process, we were willing to > let the last fest of a release cycle go on for "as long as it takes", > or at least that was what I felt the policy to be. This time we > eventually gave up and declared closure, but in hindsight we should > likely have done that a month earlier. The fact of the matter is that > quite a few of the patches we were dealing with were *not* ready to > commit, or even close to that, at the start of the fest. If it weren't > the last fest they would have gotten marked Returned With Feedback a > lot sooner. > > I wonder whether we ought to have a preset schedule for last fests > just like the others. I'd be willing to let them run, say, 2 months > instead of 1, but no deadline at all risks turning the whole affair > into a death march, which is no fun for anybody and threatens the > quality of the end result too. There's too much temptation to commit > patches that are not really ready, just to get them out of the way. > > In short, the idea of strongly calendar-driven releases looks more > and more attractive to me the more times we go through this process. > If your patch isn't ready on date X, then it's not getting into this > release; but there'll be another bus coming along before long. > Stretching out release cycles to get in those last few neat features > just increases the pressure for more of the same, because people don't > know how long it will be to the next release. A 2 month hard deadline seems enough for me. I spoke in favour of reasonableness previously, but that didn't mean no dates at all. If we can do Triage Week at the beginning, that will keep out the ones that aren't ready and allow us to focus our attention on the ones we really care about. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas <robertmhaas@gmail.com> wrote: > I think this basically just boils down to too many patches and not > enough people. I was interested in Command Triggers from the > beginning of this CommitFest, and I would have liked to pick it up > sooner, but there were a LOT of patches to work on for this > CommitFest. The first three CommitFests of this cycle each had > between 52 and 60 patches, while this one had 106 which included > several very complex and invasive patches, command triggers among > them. So there was just a lot more to do, and a number of the people > who submitted all of those patches didn't do a whole lot to help > review them, sometimes because they were still furiously rewriting > their submissions. It's not surprising that more patches + fewer > reviewers = each patch getting less attention, or getting it later. This is a good point. The current process lacks inherent scalability. I would really like us to enforce a policy of 1 patch => 1 review. That way we automatically have enough review time, no matter how many patches we get. If we don't enforce that, then patch sponsors are more likely to take the attitude that review isn't something they need to pay for, just the dev work. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On Tue, Apr 10, 2012 at 3:26 PM, Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote: > Christopher Browne <cbbrowne@gmail.com> wrote: >> Robert Haas <robertmhaas@gmail.com> wrote: > >>> CommitFests are a time for patches that are done or very nearly >>> done to get committed, and a time for other patches to get >>> reviewed if they haven't been already. If we make it clear that >>> the purpose of the CommitFest is to assess whether the patch is >>> committable, rather than to provide an open-ended window for it >>> to become committable, we might do better. >> >> Yeah, I think there's pretty good room for a "+1" on that. > > Yeah, +1 for sure. The top comment that has been +1'd presents just 2 states; 1 is deliberately phrased to be ridiculous, so of course everybody will vote for the other one. What is missing there is all of the other possible states between those two extremes. Let me re-phrase that: I think open ended CFs aren't much use. Hard edges are needed. But having said that, I can't think of a major feature that didn't have some tweaking after commit, and after end of CF. > One other sort of mechanical test which I think can and should be > applied to patches submitted to the last CF is that if *at the start > of the CF* the patch doesn't apply, compile, pass regression tests, > and demonstrably provide the functionality claimed for the patch, it > should not be a candidate for inclusion in the release. A patch on > which the author is continuing to work even in the absence of review > should be considered a WIP "want feedback" submission; it should not > be allowed to constitute a "placeholder" for inclusion in the > release. It's one thing if review turns up corner case bugs missed > by the author; it's quite another if there is a month or two of > solid development left to be done. The CF period is not the time for > "now I'll get serious about wrapping this up." Agreed. But again, mistakes do happen, so reasonableness is required. CommitFests should be a finalisation period where submissions get tweaked to fix problems/bugs and allow them to be committed by the end of the CF. Again, in some cases that might be on the last day of the CF (else its not the last day...). In the past, patches could "starve" on the queue for very long periods, sometimes years. Having a too-harsh process makes it then easy to go back to the old way of quickly bouncing things that lack popularity from committers. Anyway, this discussion is just the annual "make things better" discussion. Our process was good to start with and has get better each release for years and years now, so objectively we are doing quite well. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Simon Riggs <simon@2ndQuadrant.com> writes:
> I completely agree that somebody has to be willing to say No, since we
> all agree that the default for any patch is non-acceptance.
> My first observation is that if No is received early enough for
> something to be done, then the outcome could be different. It was not
> clear that this important patch was going to be totally refused and
> many people have expressed their surprise about that. Noah signalled
> to everybody that the FK locks patch was likely to be rejected and a
> number of us have tried hard to save that, unluckily as it turns out.
> So an early No helped people allocate their time on what they
> considered to be important. In contrast the Command Triggers and FKs
> for arrays patches received a No so late that nothing could be done.
I think this is a rather unfair summary of the history. It was clear
very early in the CF that people thought Command Triggers had major
design problems, and Dimitri was doing significant rewrites to try to
fix that. Anyone who did not think that patch was at serious risk of
not being committed simply wasn't paying attention. Given the range
of different design options that were considered, I think it's just
as well that the patch has been put off till 9.3: we will probably
get a better feature than if it had made it this time, and we will
certainly be taking less schedule risk.
I will agree that the array-FKs patch got the short end of the stick:
had we been willing to let the CF go on for another month, it would
have gotten looked at more carefully, and quite possibly committed.
But once we made the decision to cut off the CF, there was not time
to look at it closely enough. Again, to my mind this was mostly
a risk minimization decision: when you make up a fundamental feature
out of whole cloth, there's substantial risk that you didn't get the
design right. At this point we don't have enough time for the
feature to settle in and get used before 9.2 will ship and it'll be
too late to correct any design problems.
The more general point here is that the last fest of a release cycle
is the worst possible time to be landing big, destabilizing patches.
I think we ought to be conservative at this stage of the cycle, in
hopes of keeping beta phase short and predictable.
regards, tom lane
Simon Riggs <simon@2ndQuadrant.com> writes:
> If we can do Triage Week at the beginning, that will keep out the ones
> that aren't ready and allow us to focus our attention on the ones we
> really care about.
I think there's some merit in this idea, but there needs to be time
allocated to examine all the large patches before we make any hard
go/no-go decisions. Maybe we could make such choices about two weeks
in, rather than at the very start?
Another thought is that "triage" is probably not the right image to
have here. Patches that are obviously going to be rejected altogether
are not that common, and they don't take up much time when they do show
up. Where I think we have been fooling ourselves is in failing to tell
the difference between a patch that is committable in the current fest,
versus one that is still WIP and is going to need more development time.
Now the latter category *is still deserving of review*, just as much as
the former. So even if we can correctly determine early on which
patches are WIP, it doesn't mean we should bounce them out of the fest.
But it would mean they get approached differently by the reviewers.
regards, tom lane
On Sun, Apr 15, 2012 at 4:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I think this is a rather unfair summary of the history. It was clear > very early in the CF that people thought Command Triggers had major > design problems, and Dimitri was doing significant rewrites to try to > fix that. Anyone who did not think that patch was at serious risk of > not being committed simply wasn't paying attention. Fair comment, since I was definitely not paying attention. My I-Want-a-Pony idea is some kind of rating system that allows us all to judge patches in terms of importance/popularity, complexity and maturity. I guess a Balanced Scorecard for the development process. So we can all see whats going on. We already do this when we speak to each other in hushed tones that so-and-so a patch looks unlikely etc.. If we could do that more openly it would help. > The more general point here is that the last fest of a release cycle > is the worst possible time to be landing big, destabilizing patches. > I think we ought to be conservative at this stage of the cycle, in > hopes of keeping beta phase short and predictable. There is a definite selection effect that means the bigger the patch the more likely it is to land later in the release cycle, regrettably. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 04/14/2012 06:03 PM, Robert Haas wrote: > If someone's work is going to require substantial > revision, it is much better and much less work to do that revision > before the code goes into our repository (and particularly, before it > gets released) rather than after. I would think one of the major factors in deciding who should be able to commit code is whether they'll likely to commit substandard material. Someone who reviews and is seen to mark patches "ready for commit", and they're not, should surely not be committing things either. The review process we have now does a pretty good job of identifying which submissions are baked and which aren't. I'd never argue that there should be more people to commit so they can slip in half baked material. Someone doesn't need to know how to bake everything to be useful as a committer though; they just need to know what they can and can't handle. > And, on a related note, I am having > a hard time imagining that it's a good idea to give very many people > commit bits primarily so that they can commit their own work. If someone has committed their own work after that submission went through the full CF and review process, I don't see a lot of harm in them committing the result. I'd certainly never suggest that the reason to have more committers is so that the CF workflow was easier to subvert. Yes, there are problems with having enough reviewers and ushering large patches through the CF process. But it seems to me there are a fair number of submission that start solid, turn excellent through thorough review, and once they do hit "ready for committer" they could be picked up for commit by more people than the existing very small pool (committers who process other people's submissions regularly). Also, and I'm aware this is a more controversial point, I believe there are some people who would do more review if they could just move toward committing the stuff that looks good without going through quite as much process. At some times, if you realize something is close and just needs a bit more work, the easy path is to just do it yourself and be done. Non committing reviewers can't get that efficiency boost in the cases it's appropriate. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On 04/14/2012 05:28 PM, Jay Levitt wrote: > I see now that the "Reviewing a Patch" wiki page explains this, but > maybe this info should be pushed higher into the docs and web site; a > "How can I contribute" page, open calls for reviewers on the non-hackers > mailing lists, things like that. Or maybe just make the wiki page bright > red and blink a lot. It is too bad the page we used to have like this on MySpace isn't around anymore. Right now there's some rumbling at multiple companies around things like how to sponsor new features for PostgreSQL. Tying that into a larger page covering the various ways people can contribute is an interesting idea. I think we've only recently crossed the point where there's enough details on pages like "Reviewing a Patch" that it's clear to people what they should do on the technical side. That pretty well completely work could use something that's more like marketing now though. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On 04/15/2012 05:46 AM, Simon Riggs wrote: > Our problem is not lack of resource, it is ineffective > delegation. As Hannu points out, he didn't know the patch would be > rejected, so he didn't know help was needed to save something useful. > I considered that the job of the CF manager, but perhaps it is was > not. Note that one of the influences on the "death march" here was lack of a fully devoted CF manager for the full duration. I did some rabble rousing to get things started in the usual way, but my time for this only budgeted for six weeks in that role. And that was quite optimistic for this one. Trying to quantify how much time investment the CF manager role really involves is one of my important projects to chew on. Whoever ends up doing that should at least have an idea what scale of problem they're getting into. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Excerpts from Alex's message of dom abr 15 01:52:16 -0300 2012: > > Jay Levitt <jay.levitt@gmail.com> writes: > > > Alex wrote: > >> I didn't follow this whole thread, but have we considered Redmine[1]? > > > > As the resident "Ruby is shiny, let's do everything in Rails on my > > MacBook" guy, I'd like to make a statement against interest: I've > > tried Redmine a few times and it's been painful. Much of the codebase > > is deprecated, it's slow, it has no meaningful search (in 2012?!), > > I've seen wiki edits disappear, and at the moment pulling up its own > > FAQ page at redmine.org times out. > > Yay, that's totally FUD to me. I've used Redmine a lot, as you know, and I only keep using it because it's a requirement at work. It is certainly not close to usable for general pgsql stuff. (Trac, which we used to use prior to Redmine, was certainly much worse, though). I can't say that it's all that slow, or that there's a problem with the code, or that the search doesn't work right (and I've never had a wiki edit disappear, either, and I've used that a lot). It's just the wrong tool altogether. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Sun, Apr 15, 2012 at 11:31 PM, Greg Smith <greg@2ndquadrant.com> wrote: > On 04/15/2012 05:46 AM, Simon Riggs wrote: >> >> Our problem is not lack of resource, it is ineffective >> delegation. As Hannu points out, he didn't know the patch would be >> rejected, so he didn't know help was needed to save something useful. >> I considered that the job of the CF manager, but perhaps it is was >> not. > > > Note that one of the influences on the "death march" here was lack of a > fully devoted CF manager for the full duration. I did some rabble rousing > to get things started in the usual way, but my time for this only budgeted > for six weeks in that role. And that was quite optimistic for this one. > > Trying to quantify how much time investment the CF manager role really > involves is one of my important projects to chew on. Whoever ends up doing > that should at least have an idea what scale of problem they're getting > into. Again, if the CF manager role is too big, then we delegate. No reason why we can't have a CF team, with different people responsible for different areas. The key thing is working out how to mobilise the resources we have to best effect. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Alvaro Herrera <alvherre@commandprompt.com> writes: > I've used Redmine a lot, as you know, and I only keep using it because > it's a requirement at work. It is certainly not close to usable for > general pgsql stuff. (Trac, which we used to use prior to Redmine, was > certainly much worse, though). Same story here, still using redmine a lot, all with custom reports etc. > I can't say that it's all that slow, or that there's a problem with the > code, or that the search doesn't work right (and I've never had a wiki > edit disappear, either, and I've used that a lot). It's just the wrong > tool altogether. It's indeed slow here, and I agree that's not the problem. Not the tool we need, +1. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > Alvaro Herrera <alvherre@commandprompt.com> writes: >> I've used Redmine a lot, as you know, and I only keep using it because >> it's a requirement at work. It is certainly not close to usable for >> general pgsql stuff. (Trac, which we used to use prior to Redmine, was >> certainly much worse, though). > > Same story here, still using redmine a lot, all with custom reports etc. > >> I can't say that it's all that slow, or that there's a problem with the >> code, or that the search doesn't work right (and I've never had a wiki >> edit disappear, either, and I've used that a lot). It's just the wrong >> tool altogether. > > It's indeed slow here, and I agree that's not the problem. Not the tool > we need, +1. I still fail to see how Redmine doesn't fit into requirements summarized at that wiki page[1], so that must be something other than formal requirement of being free/open software and running postgres behind (some sort of "feeling" maybe?) Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you please describe your ideal tool for the task? Given that every other existing tool likely have pissed off someone already, I guess our best bet is writing one from scratch. Or maybe there isn't really a need for a tracker? The core team have managed to live without one for so long after all... -- Regards, Alex [1] http://wiki.postgresql.org/wiki/TrackerDiscussion
On Mon, Apr 16, 2012 at 18:24, Alex <ash@commandprompt.com> wrote: > > Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes: > >> Alvaro Herrera <alvherre@commandprompt.com> writes: >>> I've used Redmine a lot, as you know, and I only keep using it because >>> it's a requirement at work. It is certainly not close to usable for >>> general pgsql stuff. (Trac, which we used to use prior to Redmine, was >>> certainly much worse, though). >> >> Same story here, still using redmine a lot, all with custom reports etc. >> >>> I can't say that it's all that slow, or that there's a problem with the >>> code, or that the search doesn't work right (and I've never had a wiki >>> edit disappear, either, and I've used that a lot). It's just the wrong >>> tool altogether. >> >> It's indeed slow here, and I agree that's not the problem. Not the tool >> we need, +1. > > I still fail to see how Redmine doesn't fit into requirements summarized > at that wiki page[1], so that must be something other than formal > requirement of being free/open software and running postgres behind > (some sort of "feeling" maybe?) One thing to note is that the referenced wiki page is over a year old. And that many more things have been said on email lists than are actually in that page. But as one note - I don't believe you can drive redmine completely from email, which is certainly a requirement that has been discussed, but is not entirely listed on that page. > Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you > please describe your ideal tool for the task? > > Given that every other existing tool likely have pissed off someone > already, I guess our best bet is writing one from scratch. FWIW, I think the closest thing we've found so far would be debbugs - which IIRC doesn't have any kind of reasonable database backend, which would be a strange choice for a project like ours :) And makes many things harder... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes: > One thing to note is that the referenced wiki page is over a year old. > And that many more things have been said on email lists than are > actually in that page. Yeah, I went through it briefly and rather important concern seem to have been raised by Tom Lane in this msg: http://archives.postgresql.org/pgsql-hackers/2011-05/msg01480.php This paragraph: > The real question is, who is going to keep it up to date? GSM has the > right point of view here: we need at least a couple of people who are > willing to invest substantial amounts of time, or it's not going to go > anywhere. Seeing that we can barely manage to keep the mailing list > moderator positions staffed, I'm not hopeful. > But as one note - I don't believe you can drive redmine completely > from email, which is certainly a requirement that has been discussed, > but is not entirely listed on that page. Ugh, what do you mean by that? You can change any attribute (like status, priority, assigned person, etc.) of a ticket via email. Anything else? > FWIW, I think the closest thing we've found so far would be debbugs - > which IIRC doesn't have any kind of reasonable database backend, which > would be a strange choice for a project like ours :) And makes many > things harder... What stops us from writing a postgres backend for debbugs if it is so brilliant on handing email and stuff? -- Alex
On 04/15/2012 12:01 PM, Tom Lane wrote: > Where I think we have been fooling ourselves is in failing to tell > the difference between a patch that is committable in the current fest, > versus one that is still WIP and is going to need more development time. I wonder if this bit of state might be worth extending the UI to include. Just a little toggle box with the options "WIP" and "Commit Submission" there. [I am unattached to those particular terms] I think everyone is clear that Command Triggers is an example that reflects a more general problem seen many times before; I'll continue using it as a fresh example here without meaning to pick on Dimitri in particular. If Dimitri had submitted that in January while ticking "Commit Submission", it might have sparked a talk about the difference in expectations earlier. If we use Robert as the bad guy watching the CF progress (again, just as an example, not trying to paint him with that title), I think it would have been easier for him to write an e-mail like this: "It's March now, and this feature has been under heavy review and development for 6 weeks. This looks more like a WIP feature to me, not one that arrived as a Commit Submission. Is there any useful subset to consider instead?" Compared to the current way such things happen, that's a more factual style of message without as much emotion or judging, and one that can be raised much earlier in the CF cycle. I think it will be easier for people to write those, compared with having to be the person saying "this isn't ready to commit" only at the end. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Alex wrote: > Jay Levitt<jay.levitt@gmail.com> writes: > >> Alex wrote: >>> I didn't follow this whole thread, but have we considered Redmine[1]? >> As the resident "Ruby is shiny, let's do everything in Rails on my >> MacBook" guy, I'd like to make a statement against interest: I've >> tried Redmine a few times and it's been painful. Much of the codebase >> is deprecated, it's slow, it has no meaningful search (in 2012?!), >> I've seen wiki edits disappear, and at the moment pulling up its own >> FAQ page at redmine.org times out. > > Yay, that's totally FUD to me. You're right, it was. My bad. Someday I will find the balance between precision and concision. > Could you please elaborate a bit on your points? > > Deprecated codebase? Let me guess... > > It runs on an outdated version of Rails (2.3) but only because Rails is > changing so rapidly, I believe. There is work in progress[1] to move to > the supported branch Rails-3.x. I wasn't even thinking of that; I know many production systems still run on Rails 2.3, and in fact it probably even performs better for some workloads. 3.x is a mixed bag. I don't hold that against Redmine. But it's still FUD, because I can't remember where I saw this information. So: withdrawn. > > Slow? Do you have any data to back this point up? No measurable data; just a sigh of relief when switching from Redmine to Github - and GitHub ain't a speed demon. In general, I've seen multi-second page load times on crazy-simple things like wiki edits; this was on a hosted provider (sourcerepo.com), but they also hosted our git repo and we had no speed problems there. > No meaningful search, eh? Works for me. Redmine searches return partial-word matches, and there's no way to disable that. Searching for "test" finds "latest". To me, that's broken. Also, the UI is very 5 years ago; e.g., "compare revisions" uses the same columns-of-radio-buttons approach as MediaWiki. If the goal is a tool to reduce friction and increase involvement, you want a smoother UX. Jay
Alex wrote: > I still fail to see how Redmine doesn't fit into requirements summarized > at that wiki page[1], so that must be something other than formal > requirement of being free/open software and running postgres behind > (some sort of "feeling" maybe?) Well, if those requirements are in fact requirements, Redmine could suit the purpose (perhaps with some custom extensions). But yes, Redmine "feels" wrong to me, though I have never been particularly happy with *any* self-hosted bug tracker. Of those I've used - Redmine, Mantis, JIRA, Trac, Bugzilla, GForge, RT - Redmine feels the least-worst to me; it's about equal to Trac, and it's in Ruby so I could theoretically(!) improve it. I think the biggest missing pieces in Redmine aside from custom CF stuff are: better search, single sign-on (it requires Yet Another Login), a better UX (AJAX, syntax highlighting) and better git integration (a la pull requests, where private git commits = patches). Those are some pretty big pieces. I don't think Redmine out-of-the-box would improve either CFs or community involvement. > Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you > please describe your ideal tool for the task? My opinion isn't all that important, since I currently have an infinite opinion-to-contribution ratio, but in my unicorniverse: We'd accept that open source hasn't always produced great UX, we'd use GitHub's issue tracker, allow volunteers to do "bug wrangling" triage via tags, use GitHub hooks to integrate with the existing CF app, and write archiving tools that would let us easily export everything off of GitHub for when (a) something better comes along or (b) GitHub pops out of existence or adds egregious licensing terms like BitKeeper. Reasons: - Familiarity: Many developers already have a GitHub account and use it - Discoverability: GitHub has great SEO - Tight integration of git with patch and issue management (pull requests, fork networks, etc); eliminates ceremony rather than adding to it - Readable UI with syntax highlighting, etc - Patch commenting and git integration encourage actual review-resubmit cycles instead of "Here, look, I fixed it for you" reviews - Two-way email/web integration - Meets Tom's "would be sort of neat" criteria[1] - Could easily implement Simon's "pony" criteria[2] with tags and API - Easily extensible with API and hooks - Subjectively: Its design encourages better community and core interactions than any I've seen in 25 years. GitHub could well be a non-starter, but if third-party-dependence is really the holdup, I'd volunteer to write the tools - in fact, a google of [export issues from github] shows a few that might already suffice. > Given that every other existing tool likely have pissed off someone > already, I guess our best bet is writing one from scratch. ISTR there's a great "Writing your own bug tracker is an anti-pattern" blog, but I can't find it anymore. > Or maybe there isn't really a need for a tracker? The core team have > managed to live without one for so long after all... As an end-user, I've reported exactly one bug in a release version of Postgres, and it was fixed (and back-ported!) the next day. So I really can't complain about the tracking of actual bugs. Sounds like we do need something better for CF/patch workflow, tho. Jay [1] Tom wrote: > Now what would be sort of neat is if we had a way to keep all the versions > of patch X plus author and reviewer information, links to reviews and > discussion, etc. in some sort of centralized place [2] Simon wrote: > My I-Want-a-Pony idea is some kind of rating system that allows us all > to judge patches in terms of importance/popularity, complexity and > maturity. I guess a Balanced Scorecard for the development process. So > we can all see whats going on.
On 04/16/2012 09:24 AM, Alex wrote: > Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you > please describe your ideal tool for the task? > > Given that every other existing tool likely have pissed off someone > already, I guess our best bet is writing one from scratch. > > Or maybe there isn't really a need for a tracker? The core team have > managed to live without one for so long after all... I believe the biggest hurdle for many hackers is that in redmine, email is not a first class citizen. The majority of hackers are never going to want to go into a web interface to get something done, they live in VI/Emacs and the command line. One thing that redmine definitely breaks is proper handling of attachments in email, thus the first thing moving to redmine would break would be patch submission. JD > -- > Regards, > Alex > > [1] http://wiki.postgresql.org/wiki/TrackerDiscussion > >
On Mon, Apr 16, 2012 at 06:29:47PM +0200, Magnus Hagander wrote: > FWIW, I think the closest thing we've found so far would be debbugs - > which IIRC doesn't have any kind of reasonable database backend, which > would be a strange choice for a project like ours :) And makes many > things harder... FWIW, Don Armstrong (the main debbugs hacker these days I believe) recently posted a blog post about a more obscure feature of debuugs (forcemerge), where he finishs with "so we can eventually keep a postgresql database updated in addition to the flatfile database.": http://www.donarmstrong.com/posts/debbugs_forcemerge/ I don't know whether this implies a full PostgreSQL backend or just a helper DB for some part of the functionality, but it might be something to keep watching. Regards, Michael
> > I believe the biggest hurdle for many hackers is that in redmine, > email is not a first class citizen. The majority of hackers are never > going to want to go into a web interface to get something done, they > live in VI/Emacs and the command line. > > One thing that redmine definitely breaks is proper handling of > attachments in email, thus the first thing moving to redmine would > break would be patch submission. Right. This is not too hard to fix, however, and I didn't suggest we move to vanilla Redmine. It's hackable, so we can just bash it into shape we need (and we need a few Ruby hackers, so there's always someone in the postgres community to fix it when it breaks, of course.) -- Alex
On Mon, Apr 16, 2012 at 23:48, Jay Levitt <jay.levitt@gmail.com> wrote: > Alex wrote: >> >> I still fail to see how Redmine doesn't fit into requirements summarized >> at that wiki page[1], so that must be something other than formal >> requirement of being free/open software and running postgres behind >> (some sort of "feeling" maybe?) > > > Well, if those requirements are in fact requirements, Redmine could suit the > purpose (perhaps with some custom extensions). But yes, Redmine "feels" > wrong to me, though I have never been particularly happy with *any* > self-hosted bug tracker. That's probably one reason people aren't jumping on this. Because there is no tracker out there that people actually *like*... > Of those I've used - Redmine, Mantis, JIRA, Trac, Bugzilla, GForge, RT - > Redmine feels the least-worst to me; it's about equal to Trac, and it's in > Ruby so I could theoretically(!) improve it. It being in ruby is actually generally a liability in the postgresql.org world - we have very few people who actually know it. And some of those who know it no longer want to work with it. So if you're good with Ruby, and want to contribute, feel free to contact me off-list because we have some things we need help with :-) > I think the biggest missing pieces in Redmine aside from custom CF stuff > are: better search, single sign-on (it requires Yet Another Login), a better We already have redmine working with single password (though not single signon) for a limited number of projects such as pgweb. > UX (AJAX, syntax highlighting) and better git integration (a la pull > requests, where private git commits = patches). Those are some pretty big > pieces. I don't think Redmine out-of-the-box would improve either CFs or > community involvement. I think we can all agree on that :-) >> Jay, Alvaro, Dimitri (and whoever else wants to speak up) could you >> please describe your ideal tool for the task? > > > My opinion isn't all that important, since I currently have an infinite > opinion-to-contribution ratio, but in my unicorniverse: We'd accept that > open source hasn't always produced great UX, we'd use GitHub's issue > tracker, allow volunteers to do "bug wrangling" triage via tags, use GitHub > hooks to integrate with the existing CF app, and write archiving tools that > would let us easily export everything off of GitHub for when (a) something > better comes along or (b) GitHub pops out of existence or adds egregious > licensing terms like BitKeeper. > > Reasons: > > - Familiarity: Many developers already have a GitHub account and use it Most of the more senior developers don't use github. Other than possibly as a place to store a plain git repository. So that's not really relevant. > - Discoverability: GitHub has great SEO I'm willing to bet that postgresql.org has better SEO when it comes to postgres. > - Tight integration of git with patch and issue management (pull requests, > fork networks, etc); eliminates ceremony rather than adding to it There are some things that help there, certainly. Pull requests is basically email, but fork network tracking and such can be darn useful sometimes. > - Readable UI with syntax highlighting, etc Yes, this part is very nice. > - Patch commenting and git integration encourage actual review-resubmit > cycles instead of "Here, look, I fixed it for you" reviews The amount of spam coming through that system, and the inability/unwillingness of github to even care about it is a killer argument *against* github. We have working antispam for email. The github antispam is somewhere around where email antispam was in 1994. > - Two-way email/web integration > - Meets Tom's "would be sort of neat" criteria[1] > - Could easily implement Simon's "pony" criteria[2] with tags and API > - Easily extensible with API and hooks > - Subjectively: Its design encourages better community and core interactions > than any I've seen in 25 years. > > GitHub could well be a non-starter, but if third-party-dependence is really > the holdup, I'd volunteer to write the tools - in fact, a google of [export > issues from github] shows a few that might already suffice. It *is* a non-starter, because (a) it's a third party dependency, and (b) AFAIK they don't provide *data access* to the issue trackers. If the actual issue trackers were stored in git, like the webpages are for example, it would be a different story...b >> Given that every other existing tool likely have pissed off someone >> already, I guess our best bet is writing one from scratch. > > ISTR there's a great "Writing your own bug tracker is an anti-pattern" blog, > but I can't find it anymore. I'm sure there's more than one :-) If it was that easy we would've written one already. But doing that is likely going to be a lot of work, and it needs to be maintained. (Not that picking another one means it doesn't need to be maintained - I've seen so many things broken by upgrading redmine or bugzilla that it's silly...) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > If the feature set is desirable, though, I wonder if Postgres is > big/high profile enough for them to figure out some sort of better > arrangement. They *love* it when big open-source projects use GitHub > as their public repo - they'll email and blog announcements about > it - and if there's interest I'd be happy to open a conversation > with them. No need to wonder, we've been in contact with them before and they are very pro Postgres. > I've looked at it in conjunction with Jenkins CI; it looked nice but was way > too heavy-weight for a four-person startup (what's code review?). It's > probably much more suitable for this sized project. > Gerrit's a full-featured code review app with a tolerable UI; MediaWiki is just starting to jump into git/Gerrit and there are definitely a lot of rough edges in that workflow still. ... Someone mentioned upthread that github spam was a problem. I'm not sure I see the issue here - wouldn't mail from them still go through our lists and out current anti-spam measures anyway? - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201204170623 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk+NRO4ACgkQvJuQZxSWSshPpACg9+ZB6NzCsvnkQwuoD/BzIHgL yMkAn3zwksbKxaSDt3k/YzKY7UVLmUZb =igZu -----END PGP SIGNATURE-----
Magnus Hagander wrote: > On Mon, Apr 16, 2012 at 23:48, Jay Levitt<jay.levitt@gmail.com> wrote: >> - Familiarity: Many developers already have a GitHub account and use it > Most of the more senior developers don't use github. Other than > possibly as a place to store a plain git repository. So that's not > really relevant. I meant outside developers - the folks you'd like to see more involved in the process. >> - Patch commenting and git integration encourage actual review-resubmit >> cycles instead of "Here, look, I fixed it for you" reviews > > The amount of spam coming through that system, and the > inability/unwillingness of github to even care about it is a killer > argument *against* github. > > We have working antispam for email. The github antispam is somewhere > around where email antispam was in 1994. Interesting; I haven't run into this but you're the second person to mention it here. Antispam is (in the large) a technically unsolvable problem; even in the '90s, we'd see hackers start poking at our newest countermeasures within the hour. GitHub is a giant target, and PG probably benefits here from NOT being one. (A quick Google shows redmine and especially Trac having spam issues of their own.) Pedantic note/fun fact: There was no email antispam in 1994; Canter & Siegel posted their infamous USENET Green Card spam that year, but it didn't really spread to email for another year or two. Once it did, there were fervent debates about whether it should be called "velveeta" to distinguish from the USENET variety. >> GitHub could well be a non-starter, but if third-party-dependence is really >> the holdup, I'd volunteer to write the tools - in fact, a google of [export >> issues from github] shows a few that might already suffice. > > It *is* a non-starter, because (a) it's a third party dependency, and > (b) AFAIK they don't provide *data access* to the issue trackers. Sure they do: http://developer.github.com/v3/issues/ Jay
Jay Levitt <jay.levitt@gmail.com> writes: > > (A quick Google shows redmine and especially Trac having spam issues > of their own.) Ugh, redmine (or trac for that matters) has nothing to with handling spam. I believe a typical bug tracker doesn't handle spam itself, it lets the mailing system do that. Surely you can throw in some captcha plugins to try to reduce the spam posted from the web UI. -- Alex
Jay Levitt <jay.levitt@gmail.com> writes: > >> No meaningful search, eh? Works for me. > > Redmine searches return partial-word matches, and there's no way to > disable that. Searching for "test" finds "latest". To me, that's > broken. Well, I believe one can plug in a different search engine, like lucene or xapian. However it doesn't look like some one already did (for ticket/wiki history, but there's xapian search plugin[1] to index attachments.) > Also, the UI is very 5 years ago; e.g., "compare revisions" uses the > same columns-of-radio-buttons approach as MediaWiki. If the goal is a > tool to reduce friction and increase involvement, you want a smoother > UX. Nothing that could not be tweaked with a plugin or core code modification here either. Not sure about the magnitude of the effort required, though. -- Alex [1] https://github.com/xelkano/redmine_xapian
Alex Shulgin wrote: > Jay Levitt<jay.levitt@gmail.com> writes: >> (A quick Google shows redmine and especially Trac having spam issues >> of their own.) > > Ugh, redmine (or trac for that matters) has nothing to with handling > spam. I believe a typical bug tracker doesn't handle spam itself, it > lets the mailing system do that. > > Surely you can throw in some captcha plugins to try to reduce the spam > posted from the web UI. Maybe I'm confused - Magnus et al, are we talking spammy issues/issue comments/etc, or are we talking more about exposed email addresses? I assumed we meant spammy issues, like blog comments - spammers post issues and comments with links, to get PageRank to their sites. Email defenses wouldn't help here. Captchas are fairly pointless nowadays, assuming you have someone dedicated enough to write a spambot against your bug tracker. Most of them (even reCAPTCHA!) can be >80% defeated by software - many 99% - and there are millions of humans hanging out on Mechanical Turk who'll solve them for you 100%. Modern anti-spam ends up being a machine learning and systems exercise.. but that's another mailing list :) I think Google gets more use out of reCAPTCHA for OCR tweaking than for anti-spam. Jay
On 04/17/2012 09:20 AM, Jay Levitt wrote: > Antispam is (in the large) a technically unsolvable > problem; even in the '90s, we'd see hackers start poking at our newest > countermeasures within the hour. GitHub is a giant target, and PG > probably benefits here from NOT being one. Everyone who deals with list moderation and spam issues around PostgreSQL just got a belly laugh from that comment. Hint: the PostgreSQL lists had already been around and therefore were being targeted by spammers for over ten years before GitHub even existed. > Pedantic note/fun fact: There was no email antispam in 1994 I like it when Magnus really gets the details perfect when making a deadpan joke. Anyway, back to serious talk, I believe GitHub is a dead end here because the "primary key" as it were for issues is a repo. A bug tracker for PostgreSQL would need to have issues broken down per branch and include information similar to the release notes for each minor point release. Tracking when and how a bug is backported to older versions is one hard part of the problem here. For example, Trac, Redmine, and Github all have ways to make a commit message reference an issue, something like "fixes #X". That's fine for projects that don't have a complicated backport policy, but I haven't been able to figure out how to make it work well enough for a PostgreSQL bug tracker, to end up saving any work here. In some cases, a bug shouldn't be closed until it's been backported to all supported releases. Others will only fix in relevant releases. Let's pick a real example from the last week of my life, where having a bug tracker would have helped me out. This appears in a log: ERROR: missing chunk number 0 for toast value 1167375 in pg_toast_2619 What I should be able to do here is search the bug tracker for these words and have it spit out an issue that looks like this === Bug: Fix race condition during toast table access from stale syscache entries Impact: Transient query failures Fixed in: 9.2.0: http://archives.postgresql.org/pgsql-committers/2011-11/msg00012.php 9.1.2: http://archives.postgresql.org/pgsql-committers/2011-11/msg00016.php 9.0.6: http://archives.postgresql.org/pgsql-committers/2011-11/msg00014.php 8.4.10: http://archives.postgresql.org/pgsql-committers/2011-11/msg00013.php 8.3.17: http://archives.postgresql.org/pgsql-committers/2011-11/msg00017.php 8.2.23: http://archives.postgresql.org/pgsql-committers/2011-11/msg00015.php === Note that the "fixed in" version information doesn't show up until some time *after* the bug fix is committed, because they normally get rolled into the next minor release in bulk. A bug tracking system for PostgreSQL will start looking attractive when it makes life easier for the people who do these backports and the associated release notes. Start looking at the problem from their perspective if you want to figure out how to make that happen. I don't have a good answer to that; I just know that Trac, Redmine, and GitHub haven't felt like a good fit, having used every one of that trio for multiple years now at some point. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On Sun, Apr 15, 2012 at 8:23 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Sat, Apr 7, 2012 at 9:51 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> I think this basically just boils down to too many patches and not >> enough people. I was interested in Command Triggers from the >> beginning of this CommitFest, and I would have liked to pick it up >> sooner, but there were a LOT of patches to work on for this >> CommitFest. The first three CommitFests of this cycle each had >> between 52 and 60 patches, while this one had 106 which included >> several very complex and invasive patches, command triggers among >> them. So there was just a lot more to do, and a number of the people >> who submitted all of those patches didn't do a whole lot to help >> review them, sometimes because they were still furiously rewriting >> their submissions. It's not surprising that more patches + fewer >> reviewers = each patch getting less attention, or getting it later. > > This is a good point. The current process lacks inherent scalability. > > I would really like us to enforce a policy of 1 patch => 1 review. > That way we automatically have enough review time, no matter how many > patches we get. If we don't enforce that, then patch sponsors are more > likely to take the attitude that review isn't something they need to > pay for, just the dev work. I would be generally in favor of that policy, but I would relax it for people who have only ever submitted a handful of patches, so as to continue encouraging them to become involved in the community. It's also worth noting that not all reviews are created equal. It takes a lot more time to review command triggers than it does to review pg_archivecleanup extension-skipping. It's not important that the review effort is *exactly* proportional to the size of what has been submitted, but it *is* important that when we're having a CommitFest, people are spending the majority of their time on reviewing, rather than continuing to spend it developing patches that aren't done yet. It's perfectly right to say that people should be given a chance to finish up patches that are almost there, but our definition of "almost there" has a tendency to expand to the point where it's laughable when the last CommitFest of the cycle rolls along. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Greg Smith wrote: > On 04/17/2012 09:20 AM, Jay Levitt wrote: >> Antispam is (in the large) a technically unsolvable >> problem; even in the '90s, we'd see hackers start poking at our newest >> countermeasures within the hour. GitHub is a giant target, and PG >> probably benefits here from NOT being one. > Everyone who deals with list moderation and spam issues around PostgreSQL > just got a belly laugh from that comment. Hint: the PostgreSQL lists had > already been around and therefore were being targeted by spammers for over > ten years before GitHub even existed. Hehe. OK, we will have to battle this out over drinks if I ever make it to PGCon.. but teaser: I've bankrupted Sanford Wallace and taught the DOJ what spam was. >> Pedantic note/fun fact: There was no email antispam in 1994 > I like it when Magnus really gets the details perfect when making a deadpan > joke. Dammit. I *fail*. > Anyway, back to serious talk, I believe GitHub is a dead end here because > the "primary key" as it were for issues is a repo. A bug tracker for > PostgreSQL would need to have issues broken down per branch and include > information similar to the release notes for each minor point release. > Tracking when and how a bug is backported to older versions is one hard part > of the problem here. That's a great point. Both GitHub and git itself have no real concept of releases, and can't tell you when a commit made it in. Although.. there's some sort of new release-note functionality. Maybe I'll play and see if it'd be applicable here. Jay
Jay Levitt <jay.levitt@gmail.com> writes:
> Greg Smith wrote:
>> Tracking when and how a bug is backported to older versions is one hard part
>> of the problem here.
> That's a great point. Both GitHub and git itself have no real concept of
> releases, and can't tell you when a commit made it in.
We do actually have a somewhat-workable solution for that, see
src/tools/git_changelog. It relies on cooperation of the committers
to commit related patches with the same commit message and more or
less the same commit time, but that fits fairly well with our practices
anyway. If we did have an issue tracker I could see expecting commit
messages to include a reference to the issue number, and then it would
not be hard to adapt this program to key on that instead of matching
commit message texts.
regards, tom lane
On 04/17/2012 04:38 PM, Tom Lane wrote: > Jay Levitt<jay.levitt@gmail.com> writes: >> Greg Smith wrote: >>> Tracking when and how a bug is backported to older versions is one hard part >>> of the problem here. >> That's a great point. Both GitHub and git itself have no real concept of >> releases, and can't tell you when a commit made it in. > We do actually have a somewhat-workable solution for that, see > src/tools/git_changelog. It relies on cooperation of the committers > to commit related patches with the same commit message and more or > less the same commit time, but that fits fairly well with our practices > anyway. If we did have an issue tracker I could see expecting commit > messages to include a reference to the issue number, and then it would > not be hard to adapt this program to key on that instead of matching > commit message texts. > > Yeah, that would be good. BTW, since we're discussing trackers yet again, let me put in a plug for Bugzilla, which has mature Postgres support, is written in Perl (which a large number of hackers are familiar with and which we use extensively), has a long history and a large organization behind it (Mozilla) and last but not least has out of the box support for creating updating and closing bugs via email (I just set up an instance of the latest release with this enabled to assure myself that it works, and it does.) It also has XML-RPC and JSON-RPC interfaces, as well as standard browser support, although I have not tested the RPC interfaces. cheers andrew
On Tue, Apr 17, 2012 at 4:15 PM, Jay Levitt <jay.levitt@gmail.com> wrote: > That's a great point. Both GitHub and git itself have no real concept of > releases, and can't tell you when a commit made it in. Those factors likely play together in this. Git is a tool, not a workflow, and intentionally allows its users to use it in a variety of ways. (Which includes some very interesting pathologies visible with stuff like git-annex, git-mail.) It's not a bug that git can do things differently than the Postgres project wants things done. Likewise, it's not a bug that github, which intends to support all kinds of users using git, does not enforce the preferred Postgres workflow. I think it's pretty *normal* that we'd need tooling that won't be identical to (say) GitHub, and we shouldn't get too exercised about this. I wonder if our "fix" instead involves: a) Adding an ArchiveOpteryx instance to archive mailing list traffic; http://archiveopteryx.org/ b) A bit more tooling to make it easier to link to threads in that instance c) Perhaps some management tools based on debbugs to ease scripting of issues being tracked That's not prescriptive; just ideas. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander <magnus@hagander.net> wrote: > That's probably one reason people aren't jumping on this. Because > there is no tracker out there that people actually *like*... I think this is a point worth serious thought. The bug trackers I've used have been mostly terrible; saying that they are to bug tracking what CVS is to version control is insulting CVS. They're more like what editing RCS files in vi is to version control - i.e. worse than not having version control. To put that in practical terms, I think everyone (including people like Tom and I) who (a) are old curmudgeons or anyway middle-aged curmudgeons and (b) would spend much more time in bed with any system that we adopted than the average hacker would agree that the current system is kind of a pain. But there is no point in replacing it with something else unless that new thing is going to be significantly better than what we are doing now. And it's not entirely clear that such a thing exists. There are certainly people out there, and even on this list, who will tell you that system ABC is great. But for any given ABC there are also people who will tell you that it's got significant problems. We don't need to change anything to get a system that's got significant problems; we already have one. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander <magnus@hagander.net> wrote:
>> That's probably one reason people aren't jumping on this. Because
>> there is no tracker out there that people actually *like*...
> I think this is a point worth serious thought.
Indeed. The only one I've got extensive experience with is Bugzilla
(because Red Hat uses it) and I do cordially hate it. At least some
of that is due to bureaucratic practices RH has evolved, like cloning
bugs N times for N affected releases, but I think the tool encourages
such things. So when I read Andrew's recent suggestion that we use
Bugzilla, my immediate reaction was "egad, can't we do better?".
Maybe we can't :-(.
regards, tom lane
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > But for any > given ABC there are also people who will tell you that it's got > significant problems. We don't need to change anything to get a > system that's got significant problems; we already have one. Let's not let perfect be the enemy of good. In this case, *anything* that actually tracks bugs (and they are all quite good at that, if nothing else) is an improvement over what we have now, and thus, quite good. :) Personally, I'm okay with, and have extensively hacked on, Bugzilla and RT, but anything should be fine as long as we have someone to take ownership. - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201204172131 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk+OL/0ACgkQvJuQZxSWSshMxACeJdr+WO4ttA2mkrGLv98PTTSH jSoAniKwQNPzokA3f0GYN8gB+hAOc0Hy =oPn6 -----END PGP SIGNATURE-----
On Tue, Apr 17, 2012 at 11:07 PM, Greg Sabino Mullane <greg@turnstep.com> wrote: > Let's not let perfect be the enemy of good. In this case, *anything* > that actually tracks bugs (and they are all quite good at that, > if nothing else) is an improvement over what we have now, and thus, > quite good. :) I respectfully disagree. I would rather be chained to an angry cat for a day than have to use Bugzilla on a regular basis. RT is better, but the UI is still laughably bad. Try sticking a 74-email long thread into an RT ticket and then try to do anything with it. Now try in Gmail (even the new, revised, slightly-harder-to-use Gmail). It's not close. > Personally, I'm okay with, and have extensively hacked on, Bugzilla > and RT, but anything should be fine as long as we have someone > to take ownership. Therein lies another problem... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 04/17/2012 10:30 PM, Tom Lane wrote: > Indeed. The only one I've got extensive experience with is Bugzilla > (because Red Hat uses it) and I do cordially hate it. At least some > of that is due to bureaucratic practices RH has evolved, like cloning > bugs N times for N affected releases, but I think the tool encourages > such things. That's along the same lines as my comments toward Jay Levitt, that bugs where the fixes span multiple releases are the part nobody seems to handle very well. Rather than talk about adopting one of the available torture devices, I'd happily consider the simplest thing possible that would be useful here instead. Here's my proposed tiny tracker: -If a bug is found in a released version, but it didn't originate on pgsql-bugs, send a message to that list so it gets assigned a bug id. -Write something that consumes pgsql-bugs and dumps all bug numbers and their subject lines into a database. Start them with a state of "Unconfirmed". -Make commits that fix a bug reference it in one of the standard ways that's done by every one of these bug trackers. Just throw "Fixes #6596" into the commit message. These will probably work if a more serious tool is adopted, too. -Update src/tools/git_changelog to understand these messages and produce a delimited file about every bug fix discovered. Import new entries into another table with the bug id as the foreign key. -Provide a command line tool to change bug state, basically a thin wrapper around an UPDATE statement. Make it easy to change ranges that are currently "Unconfirmed" to "Not a bug", for the bug reports that weren't really bugs. -When point release tagging happens, run another script that looks for bug fix commits since the last one, and then save that version number into a "fixed in" table. -Generate a web page out of the database. I think I've outlined that in a way that would make useful steps toward adopting one of the full packages, too. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
Greg Smith <greg@2ndQuadrant.com> writes:
> Rather than talk about adopting one of the available torture devices,
> I'd happily consider the simplest thing possible that would be useful
> here instead. Here's my proposed tiny tracker:
Wasn't Jay just muttering about "writing your own bug tracker" being an
anti-pattern? But still, there's something in what you say, because ...
> -Make commits that fix a bug reference it in one of the standard ways
> that's done by every one of these bug trackers. Just throw "Fixes
> #6596" into the commit message. These will probably work if a more
> serious tool is adopted, too.
... I think you'll find a lot of that data could be mined out of our
historical commit logs already. I know I make a practice of mentioning
"bug #NNNN" whenever there is a relevant bug number, and I think other
committers do too. It wouldn't be 100% coverage, but still, if we could
bootstrap the tracker with a few hundred old bugs, we might have
something that was immediately useful, instead of starting from scratch
and hoping it would eventually contain enough data to be useful.
At the same time, I think we'd likely be a lot better off squirting this
data into bugzilla or another standard tracker, instead of building our
own infrastructure.
regards, tom lane
On 04/17/2012 11:44 PM, Tom Lane wrote: > At the same time, I think we'd likely be a lot better off squirting this > data into bugzilla or another standard tracker, instead of building our > own infrastructure. Perhaps. It just struck me that a lot of the custom bits needed here regardless could be built/added to the usual workflow bottom-up. You don't have to assume that either a full tracker or something like my simple POC idea will show up at the end to get started. Making goal #1 involve just mining for the data that's already around and squirting it onto a web page would be a useful exercise, one that's likely to benefit any tracker adoption. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
On 18 April 2012 13:44, Tom Lane <tgl@sss.pgh.pa.us> wrote: > ... I think you'll find a lot of that data could be mined out of our > historical commit logs already. I know I make a practice of mentioning > "bug #NNNN" whenever there is a relevant bug number, and I think other > committers do too. It wouldn't be 100% coverage, but still, if we could > bootstrap the tracker with a few hundred old bugs, we might have > something that was immediately useful, instead of starting from scratch > and hoping it would eventually contain enough data to be useful. Just as a data point, git tells me that there are 387 commits where the commit log message matches '#\d+', and 336 where it matches 'bug #\d+'. Cheers, BJ
On Wed, Apr 18, 2012 at 04:30, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> That's probably one reason people aren't jumping on this. Because >>> there is no tracker out there that people actually *like*... > >> I think this is a point worth serious thought. > > Indeed. The only one I've got extensive experience with is Bugzilla > (because Red Hat uses it) and I do cordially hate it. At least some > of that is due to bureaucratic practices RH has evolved, like cloning > bugs N times for N affected releases, but I think the tool encourages > such things. So when I read Andrew's recent suggestion that we use > Bugzilla, my immediate reaction was "egad, can't we do better?". > Maybe we can't :-(. Personally, I'd say we *already* do better than that... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Tue, Apr 17, 2012 at 19:59, Greg Smith <greg@2ndquadrant.com> wrote: > On 04/17/2012 09:20 AM, Jay Levitt wrote: > Let's pick a real example from the last week of my life, where having a bug > tracker would have helped me out. This appears in a log: > > ERROR: missing chunk number 0 for toast value 1167375 in pg_toast_2619 > > What I should be able to do here is search the bug tracker for these words > and have it spit out an issue that looks like this I'm snipping the actual usecase, because it's nice and deatailed, but. I think this cleraly outlines that we need to remember that there are *two* different patterns that people are trying tosolve with the bugtracker. One is the simple "someone reported a bug. track until someone fixes it to make sure we don't miss it. Possibly even flag who is currently working on/responsible for this bug". The other one is for the *outsider* (sorry, Greg, in this scenario you get to represent an outsider for once). Who comes in and wants to know if the problem he/she has exists before, if it's fixed, and in which versions it's fixed in. There is some overlap, but the general usecase is drastically different. And we do a decent enough job of the first one today, partially because we have a few people who are very good at remembering these things and then finding them in the list archives. It works. However, we do very bad on the second one, IMHO. Any tool we'd go for should aim to cover *both* usecases. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Wed, Apr 18, 2012 at 05:44, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Greg Smith <greg@2ndQuadrant.com> writes: >> Rather than talk about adopting one of the available torture devices, >> I'd happily consider the simplest thing possible that would be useful >> here instead. Here's my proposed tiny tracker: > > Wasn't Jay just muttering about "writing your own bug tracker" being an > anti-pattern? But still, there's something in what you say, because ... The caes where it would work to do that is if we agreed it'd be a "tiny tracker". And not actually try to do too much. As in basicaly a neater frontend over the mailinglist archives. I actually started on a demo of that at one point. Currently blocked behind the fact that we have to fix the mailinglist archives as well, in particular the break-on-month-boundary kills any attempt to do such a thing. Which is also being worked on, but backlogged as usual :S I'll admit that one reason it's been sitting fairly low on the prio list is the guaranteed months of bikeshedding that it would bring along ;) >> -Make commits that fix a bug reference it in one of the standard ways >> that's done by every one of these bug trackers. Just throw "Fixes >> #6596" into the commit message. These will probably work if a more >> serious tool is adopted, too. > > ... I think you'll find a lot of that data could be mined out of our > historical commit logs already. I know I make a practice of mentioning > "bug #NNNN" whenever there is a relevant bug number, and I think other > committers do too. It wouldn't be 100% coverage, but still, if we could > bootstrap the tracker with a few hundred old bugs, we might have > something that was immediately useful, instead of starting from scratch > and hoping it would eventually contain enough data to be useful. I have always considered that a *requirement*, not a neat addon. > At the same time, I think we'd likely be a lot better off squirting this > data into bugzilla or another standard tracker, instead of building our > own infrastructure. I'm somewhat doubtful. As a first step, we should at least stick in a tracker with a reasonable SQL schema so it's possible to extract and do smomething with the data. IIRC, bugzilla (and others) at least used to just concatenate all comments into a single text field, and not even keep them apart, for example. Because clearly this whole JOIN thing is evil and difficult. They may have fixed that by now, but what i've seen from most trackers shows signs of people who have never seen a database beyond an Excel sheet... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> On Wed, Apr 18, 2012 at 04:30, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> So when I read Andrew's recent suggestion that we use
>> Bugzilla, my immediate reaction was "egad, can't we do better?".
>> Maybe we can't :-(.
> Personally, I'd say we *already* do better than that...
Just meditating a little ... one of my big beefs with Bugzilla is that
it shows basically a historical record of how a bug was discovered and
dealt with. While that surely has, er, historical value, it's not that
useful to read when you want to know which bug matches your symptoms,
what the possible consequences are, which versions it was fixed in,
etc. One particularly nasty point is that (AFAIK) it's impossible to
delete or edit incorrect comments, only to add new ones.
I wonder whether a better model would be a wiki page per bug, with
an editable description and some links to reports, commits, etc.
Not but what I hate every wiki I've ever used too ... but at least
they let you fix the information when it's wrong or unhelpful.
regards, tom lane
On Wed, Apr 18, 2012 at 07:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> On Wed, Apr 18, 2012 at 04:30, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> So when I read Andrew's recent suggestion that we use >>> Bugzilla, my immediate reaction was "egad, can't we do better?". >>> Maybe we can't :-(. > >> Personally, I'd say we *already* do better than that... > > Just meditating a little ... one of my big beefs with Bugzilla is that > it shows basically a historical record of how a bug was discovered and > dealt with. While that surely has, er, historical value, it's not that > useful to read when you want to know which bug matches your symptoms, > what the possible consequences are, which versions it was fixed in, > etc. One particularly nasty point is that (AFAIK) it's impossible to > delete or edit incorrect comments, only to add new ones. > > I wonder whether a better model would be a wiki page per bug, with > an editable description and some links to reports, commits, etc. > Not but what I hate every wiki I've ever used too ... but at least > they let you fix the information when it's wrong or unhelpful. There's no reason why a bugtracker couldn't and shoulldn't make it possible to do that. I think the reason Bugzilla doesn't goes back to the "all comments are concatenated into a huge text field", which means you'd have to prase that text field to get the actual data back, instead of having it easily available... The discussion should in that case be about whether history shoudl be kept for each individual comment, or just thrown away... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Magnus Hagander <magnus@hagander.net> writes:
> I think this cleraly outlines that we need to remember that there are
> *two* different patterns that people are trying tosolve with the
> bugtracker.
Yeah, remember we drifted to this topic from discussion of management of
CF patches, which might be yet a third use-case. It's not obvious that
it's the same as tracking unfixed bugs, at least; though maybe the
requirements end up the same.
> Any tool we'd go for should aim to cover *both* usecases.
Not convinced that we should expect one tool to be good at both
(or all three) things.
regards, tom lane
First of all I think a bug tracker will never be a system that is somehow "loved". Bugs are things which developers hate. Bugs in a cute nice small bug house aren't nice, are they?
Question: Is there a reasonable chance from may be Tom Lane's idea of a wiki to an improved (define improvements) version which PG developers think may be useful?
Wolfgang
Von: Robert Haas <robertmhaas@gmail.com>
An: Magnus Hagander <magnus@hagander.net>
CC: Jay Levitt <jay.levitt@gmail.com>; Alex <ash@commandprompt.com>; Dimitri Fontaine <dimitri@2ndquadrant.fr>; Alvaro Herrera <alvherre@commandprompt.com>; Peter Eisentraut <peter_e@gmx.net>; Tom Lane <tgl@sss.pgh.pa.us>; Greg Smith <greg@2ndquadrant.com>; Pg Hackers <pgsql-hackers@postgresql.org>
Gesendet: 3:07 Mittwoch, 18.April 2012
Betreff: Re: [HACKERS] Bug tracker tool we need
On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander <magnus@hagander.net> wrote:
> That's probably one reason people aren't jumping on this. Because
> there is no tracker out there that people actually *like*...
I think this is a point worth serious thought. The bug trackers I've
used have been mostly terrible; saying that they are to bug tracking
what CVS is to version control is insulting CVS. They're more like
what editing RCS files in vi is to version control - i.e. worse than
not having version control.
To put that in practical terms, I think everyone (including people
like Tom and I) who (a) are old curmudgeons or anyway middle-aged
curmudgeons and (b) would spend much more time in bed with any system
that we adopted than the average hacker would agree that the current
system is kind of a pain. But there is no point in replacing it with
something else unless that new thing is going to be significantly
better than what we are doing now. And it's not entirely clear that
such a thing exists. There are certainly people out there, and even
on this list, who will tell you that system ABC is great. But for any
given ABC there are also people who will tell you that it's got
significant problems. We don't need to change anything to get a
system that's got significant problems; we already have one.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes: > On Tue, Apr 17, 2012 at 1:47 AM, Magnus Hagander <magnus@hagander.net> wrote: >> That's probably one reason people aren't jumping on this. Because >> there is no tracker out there that people actually *like*... > > I think this is a point worth serious thought. I wonder why do people keep complaining how their bug tracker of choice sucks, instead of doing something about that. I can see a few possible factors: a) people do like to complain, and it's easier than submitting meaningful bug reports or feature requests, patches :-) b) the developers don't listen to their users, which happens far too often unfortunately c) (I had yet another idea here, but I forgot what it was :-p) d) a wild mix of the above However, this doesn't imply existing tracker software cannot be improved and more of that must be written from scratch (unless the code is cryptic and/or is written, probably poorly, in some rarely used programming language, and is unmaintainable.) Also, the reasons outlined above do not pertain only to bug tracker software somehow: any piece of software could suffer from that and I believe many of us have seen it. So maybe there's something fundamentally wrong with every existing bug tracker (e.g. they don't fix bugs for you?) Well, just kidding. ;-) -- Alex
On Wed, Apr 18, 2012 at 1:38 AM, Magnus Hagander <magnus@hagander.net> wrote: >> At the same time, I think we'd likely be a lot better off squirting this >> data into bugzilla or another standard tracker, instead of building our >> own infrastructure. > > I'm somewhat doubtful. Me, too. It's very tempting to assume that the problem we're trying to solve must already have been well-solved by someone else, and therefore we ought to use their thing instead of inventing our own. But that presumes that our problem is exactly the same as other people's problem, which may not really be true. IME, bug trackers typically work best when used by a tightly integrated team. For example, EnterpriseDB uses a bug-tracker-ish system for tracking bugs and feature requests and another one for support requests. Those systems get the job done and, certainly, are better designed than Bugzilla (it doesn't take much), but a lot of what they manage is workflow. Person A assigns a ticket to person B, and person B is then responsible for taking some action, and if they don't then someone will come along and run a report and grouse at person B for failing to take that action. If those reports weren't run and people didn't get groused at, the system would degenerate into utter chaos; and of course in a community setting it's hard to imagine that any such thing could possibly occur, since this is an all-volunteer effort. So I think Greg has exactly the right idea: we shouldn't try to incorporate one of these systems that aims to manage workflow; we should just design something really simple that tracks what happened and lets people who wish to volunteer to do so help keep that tracking information up to date. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote: > Maybe I'm confused - Magnus et al, are we talking spammy issues/issue > comments/etc, or are we talking more about exposed email addresses? My github.com account currently has 4264 notifications in the inbox. Almost all of those are spam, growing constantly. Because of that, the platform is currently fairly useless to me for actually communicating or collaborating on code.
On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote: > It's very tempting to assume that the problem we're trying to solve > must already have been well-solved by someone else, and therefore we > ought to use their thing instead of inventing our own. But that > presumes that our problem is exactly the same as other people's > problem, which may not really be true. It's also very tempting to assume the opposite. ;-) > IME, bug trackers typically work best when used by a tightly > integrated team. Well, very many loosely distributed open-source projects use bug trackers quite successfully. > So I think Greg has exactly the right idea: we shouldn't try to > incorporate one of these systems that aims to manage workflow; Um, isn't half of the commitfest app about workflow? Patch is waiting for review, who is the reviewer, patch is waiting for author, who is the author, patch is ready for committer, who is the committer? And every week or so the commitfest manager (if any) produces a report on patch progress. Isn't that exactly what these "workflow management" systems provide?
On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote: > I wonder why do people keep complaining how their bug tracker of > choice sucks, instead of doing something about that. Lack of time, and to some degree a lack of clarity of what they want out of the thing. (Most people are very clear on what they don't want.)
On Wed, Apr 18, 2012 at 10:15 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On ons, 2012-04-18 at 08:28 -0400, Robert Haas wrote: >> It's very tempting to assume that the problem we're trying to solve >> must already have been well-solved by someone else, and therefore we >> ought to use their thing instead of inventing our own. But that >> presumes that our problem is exactly the same as other people's >> problem, which may not really be true. > > It's also very tempting to assume the opposite. ;-) Fair enough. >> IME, bug trackers typically work best when used by a tightly >> integrated team. > > Well, very many loosely distributed open-source projects use bug > trackers quite successfully. > >> So I think Greg has exactly the right idea: we shouldn't try to >> incorporate one of these systems that aims to manage workflow; > > Um, isn't half of the commitfest app about workflow? Patch is waiting > for review, who is the reviewer, patch is waiting for author, who is the > author, patch is ready for committer, who is the committer? And every > week or so the commitfest manager (if any) produces a report on patch > progress. Isn't that exactly what these "workflow management" systems > provide? Yeah, but I thought we'd veered off into a digression about tracking bug reports. Here's our workflow for bugs: 1. If they seem interesting, Tom fixes them. 2. Or occasionally someone else fixes them. 3. Otherwise, they drift forever in the bleakness of space. I've been conducting the experiment for a year or two now of leaving unresolved bug reports unread in my mailbox. I've got over 100 such emails now... and some of them may not really be bugs, but nobody's put in the work to figure that out. It would be useful to have a system that would keep track of which ones those are so people could look over them and maybe get inspired to go do some bug-fixing, or at least bug-analysis, but what good is workflow going to do us? We could "assign" all those bugs to people who are "supposed" to look at them, and maybe some of those people would actually do it, but a more likely outcome is that everybody's list of assigned issues would slowly converge to infinity, or they'd just start closing them as wontfix. We don't need a system to help us ignore bug reports; our existing process handles that with admirable efficiency. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Peter Eisentraut <peter_e@gmx.net> wrote: > On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote: >> I wonder why do people keep complaining how their bug tracker of >> choice sucks, instead of doing something about that. > > Lack of time, and to some degree a lack of clarity of what they > want out of the thing. (Most people are very clear on what they > don't want.) Personally, I haven't worked with one which had the data organized in what I would consider a sensible and useful way. In my view there should be a *problem* report table, to describe the problem from a user perspective. What the user experienced, without any attempt to explain why. Error messages, steps to reproduce, environments in which it's been seen, independent confirmation of behavior, etc. This would be what you would primarily want to search when you hit a bug. There would be a separate table for an analysis of each contributing *cause* of the observed behavior. Describe why it caused or contributed to the observed behavior. There should be a list of these which exist independently of the problem statement, so that you can reference several causes for a problem report, and the cause can be linked from multiple reports. Each cause should include a separate section for user-oriented explanation of what to do when confronted by this issue -- limitations, workarounds, alternative approaches, documentation to read, etc. Each cause should maybe have a "Not a bug" check-box. Through a table linking problems to causes, not only could one easily look at all the contributing causes for a problem report, but all the problem reports with a given cause. In a field separate from the analysis, there could be a summary of what the community consensus on a solution is. Each cause should have a (possibly empty) *task* list describing what would need to be done by the community for resolution. Tasks would exist independently of problem statements or cause analysis and could be shared among various causes. (Of course, this being a relational database, one could easily find the related problem and cause rows that a to-do addressed.) I'm less clear on how work-flow management and resolution data would tie in, but it seems like there's plenty to attach that to. The muddling of problem description, cause analysis, solution design, tasks needed for correction, and assignments to tasks has been an insurmountable problem in the systems I've used so far (although there are a great many I've never seen, so maybe someone has this in what I would consider a reasonable structure). Any system which starts with a "problem description" and "solution description" as big text blobs and then jumps to a list of "assignments" (as one product I have to use) is hopelessly broken from the start, IMO. Now, possibly the problem is that other people think the above would be horrible for them, and that there *is* no design that works for everyone; but the above seems to me to model reality much better than any bug-tracking system I've used so far. And, as an aside, I think that calling an approach an anti-pattern is too often a cheap way to avoid serious thought about an issue which merits it, while pretending to the moral high ground. Better to leave that aside and stick to remarks with actual meaning and content. In other words, declaring something to be anti-pattern is, IMO, an anti-pattern. -Kevin
On 04/18/2012 11:29 AM, Kevin Grittner wrote: > Peter Eisentraut<peter_e@gmx.net> wrote: >> On ons, 2012-04-18 at 13:33 +0300, Alex Shulgin wrote: >>> I wonder why do people keep complaining how their bug tracker of >>> choice sucks, instead of doing something about that. >> Lack of time, and to some degree a lack of clarity of what they >> want out of the thing. (Most people are very clear on what they >> don't want.) > > Personally, I haven't worked with one which had the data organized > in what I would consider a sensible and useful way. Part of the trouble is that the whole area is fuzzy. So any organization that imposes some sort of order on the data will not fit well in some cases. Most tracker systems have ended up either trying to cater for increasingly complex and varied circumstances, or staying simple and more or less throwing in the towel on the complexity problem. That doesn't necessarily mean that it's not worth having a tracker, just that we need to recognize the limitations. cheers andrew
Robert, Peter, all: >>> IME, bug trackers typically work best when used by a tightly >>> integrated team. >> >> Well, very many loosely distributed open-source projects use bug >> trackers quite successfully. ... most of them, actually. >> Um, isn't half of the commitfest app about workflow? Patch is waiting >> for review, who is the reviewer, patch is waiting for author, who is the >> author, patch is ready for committer, who is the committer? And every >> week or so the commitfest manager (if any) produces a report on patch >> progress. Isn't that exactly what these "workflow management" systems >> provide? > > Yeah, but I thought we'd veered off into a digression about tracking > bug reports. Here's our workflow for bugs: I think assuming we can use the *same* tool for the CommitFests as for tracking bug reports would be a mistake. The workflow for both things is very different. > 1. If they seem interesting, Tom fixes them. > 2. Or occasionally someone else fixes them. > 3. Otherwise, they drift forever in the bleakness of space. Well, that *is* a workflow, even if it's a very simple one. And it could (should) be handled by a very simple bug tracker with a very simple workflow; as much as it irritates me otherwise, Bugzilla does this with its 4-5 bug "statuses", although the whole "assignment" approach wouldn't really work for us. Frankly, the concept of "assignment" doesn't work very well for OSS projects, period, in my experience. Often as not, it simply means that one person is ignoring the bug instead of a whole group of people. So a simple bug tracker which has four statuses ( "Submitted","Verified","Fixed","Invalid") would describe our entire bug workflow. Pretty much every bugtracker available can do this minimal level of bug tracking. BTW, given our heavy reliance on email, let me put a word in here for RT, which is 100% email-driven. RT has other limitations, but if your goal is to never log into a web interface, it's hard to beat. > wontfix. We don't need a system to help us ignore bug reports; our > existing process handles that with admirable efficiency. I think I have this year's pgCon T-Shirt quote. ;-) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus <josh@agliodbs.com> wrote: >> 3. Otherwise, they drift forever in the bleakness of space. Seems to me that this line, is pretty close to being T-shirt-worthy. > wontfix. We don't need a system to help us ignore bug reports; our >> existing process handles that with admirable efficiency. > > I think I have this year's pgCon T-Shirt quote. ;-) Not bad, sir, not bad... -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
On 04/17/2012 11:29 PM, Andrew Dunstan wrote: > > > On 04/17/2012 04:38 PM, Tom Lane wrote: >> Jay Levitt<jay.levitt@gmail.com> writes: >>> Greg Smith wrote: >>>> Tracking when and how a bug is backported to older versions is one >>>> hard part >>>> of the problem here. >>> That's a great point. Both GitHub and git itself have no real concept of >>> releases, and can't tell you when a commit made it in. >> We do actually have a somewhat-workable solution for that, see >> src/tools/git_changelog. It relies on cooperation of the committers >> to commit related patches with the same commit message and more or >> less the same commit time, but that fits fairly well with our practices >> anyway. If we did have an issue tracker I could see expecting commit >> messages to include a reference to the issue number, and then it would >> not be hard to adapt this program to key on that instead of matching >> commit message texts. >> >> > > > Yeah, that would be good. > > BTW, since we're discussing trackers yet again, let me put in a plug for > Bugzilla, which has mature Postgres support, is written in Perl (which a > large number of hackers are familiar with and which we use extensively), > has a long history and a large organization behind it (Mozilla) and last > but not least has out of the box support for creating updating and > closing bugs via email (I just set up an instance of the latest release > with this enabled to assure myself that it works, and it does.) It also > has XML-RPC and JSON-RPC interfaces, as well as standard browser > support, although I have not tested the RPC interfaces. years ago when I did the PoC install for PostgreSQL i used the RPC-Interface for replacing the bug-reporting form on the main website, it was prett ylimited back then (especially around authentication and a way to actually make the report show up with the reporters name (which very likely does not have a BZ account), but all those were solvable. BZ really has the drawback that it is kind of a monster on the featureside and you need to invest some significant time to make the UI understandable before you can actually present it to a wider audience. Stefan
On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus <josh@agliodbs.com> wrote: > BTW, given our heavy reliance on email, let me put a word in here for > RT, which is 100% email-driven. RT has other limitations, but if your > goal is to never log into a web interface, it's hard to beat. If your goal is to never log into a good web interface, it's even harder to beat. I actually don't mind logging into a web interface to update information. That doesn't slow me down much, as long as I can still also email *without* using the web interface. Now, RT's web interface is poor. But, if that's what everyone else likes, I could tolerate it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Wed, Apr 18, 2012 at 08:12, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Magnus Hagander <magnus@hagander.net> writes: >> I think this cleraly outlines that we need to remember that there are >> *two* different patterns that people are trying tosolve with the >> bugtracker. > > Yeah, remember we drifted to this topic from discussion of management of > CF patches, which might be yet a third use-case. It's not obvious that > it's the same as tracking unfixed bugs, at least; though maybe the > requirements end up the same. > >> Any tool we'd go for should aim to cover *both* usecases. > > Not convinced that we should expect one tool to be good at both > (or all three) things. True. That means that it's more important than ever that whatever tools are used "plays well with others". Which in my experience very few of the existing trackers out there actually do. That can of course have changed since I last looked, but I have been very discouraged previously when looking, both for in the postgresql context and in others. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Wed, Apr 18, 2012 at 16:08, Peter Eisentraut <peter_e@gmx.net> wrote: > On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote: >> Maybe I'm confused - Magnus et al, are we talking spammy issues/issue >> comments/etc, or are we talking more about exposed email addresses? > > My github.com account currently has 4264 notifications in the inbox. > Almost all of those are spam, growing constantly. Because of that, the > platform is currently fairly useless to me for actually communicating or > collaborating on code. That's about the same amount that I have. And yeah, it works great for hosting git repos. And it works great for browsing git repos and viewing differences and networks. But anything to do with pull requests, issues, comments or anything like that is completely useless these days. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Wed, Apr 18, 2012 at 19:17, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> wrote: > On 04/17/2012 11:29 PM, Andrew Dunstan wrote: >> >> >> On 04/17/2012 04:38 PM, Tom Lane wrote: >>> Jay Levitt<jay.levitt@gmail.com> writes: >>>> Greg Smith wrote: >>>>> Tracking when and how a bug is backported to older versions is one >>>>> hard part >>>>> of the problem here. >>>> That's a great point. Both GitHub and git itself have no real concept of >>>> releases, and can't tell you when a commit made it in. >>> We do actually have a somewhat-workable solution for that, see >>> src/tools/git_changelog. It relies on cooperation of the committers >>> to commit related patches with the same commit message and more or >>> less the same commit time, but that fits fairly well with our practices >>> anyway. If we did have an issue tracker I could see expecting commit >>> messages to include a reference to the issue number, and then it would >>> not be hard to adapt this program to key on that instead of matching >>> commit message texts. >>> >>> >> >> >> Yeah, that would be good. >> >> BTW, since we're discussing trackers yet again, let me put in a plug for >> Bugzilla, which has mature Postgres support, is written in Perl (which a >> large number of hackers are familiar with and which we use extensively), >> has a long history and a large organization behind it (Mozilla) and last >> but not least has out of the box support for creating updating and >> closing bugs via email (I just set up an instance of the latest release >> with this enabled to assure myself that it works, and it does.) It also >> has XML-RPC and JSON-RPC interfaces, as well as standard browser >> support, although I have not tested the RPC interfaces. > > years ago when I did the PoC install for PostgreSQL i used the > RPC-Interface for replacing the bug-reporting form on the main website, > it was prett ylimited back then (especially around authentication and a > way to actually make the report show up with the reporters name (which > very likely does not have a BZ account), but all those were solvable. BZ > really has the drawback that it is kind of a monster on the featureside > and you need to invest some significant time to make the UI > understandable before you can actually present it to a wider audience. What I saw from it, it would take more time and work to make the UI understandable and workable, and to get it to adapt to *our* process and workflow than to design a whole new tool from scratch... The problem I've found with most tools is that they work reasonably well if you let them control the entire workflow. But when you want to do things your own way, and it doesn't match up with what they were originally designed to do, it all comes falling down quickly... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On 04/18/2012 01:26 PM, Robert Haas wrote: > On Wed, Apr 18, 2012 at 1:08 PM, Josh Berkus<josh@agliodbs.com> wrote: >> BTW, given our heavy reliance on email, let me put a word in here for >> RT, which is 100% email-driven. RT has other limitations, but if your >> goal is to never log into a web interface, it's hard to beat. > If your goal is to never log into a good web interface, it's even > harder to beat. > > I actually don't mind logging into a web interface to update > information. That doesn't slow me down much, as long as I can still > also email *without* using the web interface. > > Now, RT's web interface is poor. But, if that's what everyone else > likes, I could tolerate it. I think it's just frightful, TBH. And I do use the web for tracker interaction. cheers andrew
On Wed, Apr 18, 2012 at 1:48 PM, Magnus Hagander <magnus@hagander.net> wrote: > The problem I've found with most tools is that they work reasonably > well if you let them control the entire workflow. But when you want to > do things your own way, and it doesn't match up with what they were > originally designed to do, it all comes falling down quickly... That's pretty much characteristic of the average SAP R/3 project. If you can change the organization's business processes to follow SAP's defined "best practices," then it's easy to install and use R/3.But that normally not being the case, every "SAP project"winds up having hideous customization costs to kludge the practices towards one another. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
Am 18.04.2012 14:28, schrieb Robert Haas: > So I think Greg has exactly the right idea: we shouldn't try to > incorporate one of these systems that aims to manage workflow; we > should just design something really simple that tracks what happened > and lets people who wish to volunteer to do so help keep that tracking > information up to date. I tested a lot tools for bug / issue tracking and I figured out that almost all of them either have had too much overhead or not really were made for database business. Additionally more often the sentence "we support PostgreSQL" just was a marketing trap. Means I figured out that the PostgreSQL support totally sucked. My opinion is that a tool should mirror your business and not that you build your business around the given tool. Looking for a bug tracking too - there are some points that are mandatory for us: 1. it should run on PostgreSQL 2. it should be open source - if possible BSD license - if possible there shouldn't be a single company behind it 3. it should be user friendly - no need to click here and there to get all informations 4. It should be able to communicate with our version control system - when we get the idea to move away from git to somethingelse - it should be able by just a few changes that the tool will communicate with the new system 5. it should be possible to do almost all via email My personal dream would be that it would be possible to do almost all via irc bot but that is fiction. I think a tool should be slim and simple. It should exactly do what you want to do. You should be able to change the tool code that way that it exactly is doing what you want to do. Let me give you an example: bugs.mysql.com might be far away from being perfect. It is slim - and on developer side it has had all that the development needed. My information is that originally they took the code from the php bug tracking system and recoded it / implemented features so that it was doing a good job on database bugs. When the developers needed tool changes or additionally features then they just were coded. I never heard a developer saying that he hates the system. There just were lots of ideas how this or that could be solved better. That is normal - when you are working with the tool every day - of course you will get ideas what could be solved better. So yes - I think Greg is right. We should design something really simple that exactly is doing what we need. With some luck we might not need to start from scratch. Maybe there is a tool outside that is slim and good enough to deliver the base code on which we can start recoding. Just my 2ct, Susanne -- Dipl. Inf. Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com
Excerpts from Tom Lane's message of mié abr 18 03:12:09 -0300 2012: > > Magnus Hagander <magnus@hagander.net> writes: > > I think this cleraly outlines that we need to remember that there are > > *two* different patterns that people are trying tosolve with the > > bugtracker. > > Yeah, remember we drifted to this topic from discussion of management of > CF patches, which might be yet a third use-case. It's not obvious that > it's the same as tracking unfixed bugs, at least; though maybe the > requirements end up the same. > > > Any tool we'd go for should aim to cover *both* usecases. > > Not convinced that we should expect one tool to be good at both > (or all three) things. So maybe we need more than one tool to present the information to different kinds of users, but we need only *one* database backing them all, right? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > So I think Greg has exactly the right idea: we shouldn't try to > incorporate one of these systems that aims to manage workflow; we > should just design something really simple that tracks what happened > and lets people who wish to volunteer to do so help keep that tracking > information up to date. Note: the above is the other Greg :) If we are serious about building this ourselves, and we feel it is important, maybe we should sponsor it via our group funds or some other means? Seems like everyone here has lots of ideas but little free time. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201204191031 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk+QIeUACgkQvJuQZxSWSsi5NACg4ruX3jvuQ5zKnxbBPu2Kc9wW C+EAoPsIt2n0bbYau/aPhPbVdm+JPHj3 =j1XN -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> My github.com account currently has 4264 notifications in the inbox. >> Almost all of those are spam, growing constantly. �Because of that, the >> platform is currently fairly useless to me for actually communicating or >> collaborating on code. > > That's about the same amount that I have. I have no spam at all, despite being a fairly early github adopter. Wonder what the difference is? - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 201204191044 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAk+QJO4ACgkQvJuQZxSWSsg7OgCggq2MVw10W2+XxCyoDSdbjTYP JOAAoLVJeX/V5j1h8r0dpvyJAw9/O+BU =puT/ -----END PGP SIGNATURE-----
On Thu, Apr 19, 2012 at 16:45, Greg Sabino Mullane <greg@turnstep.com> wrote: > >>> My github.com account currently has 4264 notifications in the inbox. >>> Almost all of those are spam, growing constantly. �Because of that, the >>> platform is currently fairly useless to me for actually communicating or >>> collaborating on code. >> >> That's about the same amount that I have. > > I have no spam at all, despite being a fairly early github adopter. > Wonder what the difference is? The vast majority of the spam I have originates in the postgresql git repository. You don't have any commits there... But I would've assumed it should hit equally hard on other repositories that's been around a long time. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Thu, Apr 19, 2012 at 10:49 AM, Magnus Hagander <magnus@hagander.net> wrote: > On Thu, Apr 19, 2012 at 16:45, Greg Sabino Mullane <greg@turnstep.com> wrote: >> >>>> My github.com account currently has 4264 notifications in the inbox. >>>> Almost all of those are spam, growing constantly. �Because of that, the >>>> platform is currently fairly useless to me for actually communicating or >>>> collaborating on code. >>> >>> That's about the same amount that I have. >> >> I have no spam at all, despite being a fairly early github adopter. >> Wonder what the difference is? > > The vast majority of the spam I have originates in the postgresql git > repository. You don't have any commits there... > > But I would've assumed it should hit equally hard on other > repositories that's been around a long time. I have plenty of commits on the Slony Git repo, which has had clones at github for about as long as PostgreSQL has. And I don't get any noticeable amounts of spam at github. Not all notifications are hugely interesting, but I don't see anything that's not reasonably related to things I have commented on. So I think there has to be some other effect in play. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
On 04/19/2012 11:25 AM, Christopher Browne wrote: >> >> The vast majority of the spam I have originates in the postgresql git >> repository. You don't have any commits there... >> >> But I would've assumed it should hit equally hard on other >> repositories that's been around a long time. > I have plenty of commits on the Slony Git repo, which has had clones > at github for about as long as PostgreSQL has. > > And I don't get any noticeable amounts of spam at github. Not all > notifications are hugely interesting, but I don't see anything that's > not reasonably related to things I have commented on. > > So I think there has to be some other effect in play. The spammers pick certain well known projects, I believe. At any rate, I found that my spam went to nil by turning off notifications for comments on my commits and comments that mention me. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> At any rate, I found that my spam went to nil by turning off
> notifications for comments on my commits and comments that mention me.
The first part of that seems like it would destroy most of the point
of having the mechanism at all?
regards, tom lane
On 04/19/2012 03:05 PM, Tom Lane wrote: > Andrew Dunstan<andrew@dunslane.net> writes: >> At any rate, I found that my spam went to nil by turning off >> notifications for comments on my commits and comments that mention me. > The first part of that seems like it would destroy most of the point > of having the mechanism at all? > > Yes, the notification piece is pretty much useless, because of the spammers. I use github as a convenient place to stash public repositories (e.g. buildfarm code), and PostgreSQL Experts uses it for both public and private repos, but if people want me to get their comments they need to go to the trouble of emailing me. cheers andrew
On Wed, Apr 18, 2012 at 05:08:06PM +0300, Peter Eisentraut wrote: > On tis, 2012-04-17 at 10:52 -0400, Jay Levitt wrote: > > Maybe I'm confused - Magnus et al, are we talking spammy issues/issue > > comments/etc, or are we talking more about exposed email addresses? > > My github.com account currently has 4264 notifications in the inbox. > Almost all of those are spam, growing constantly. Because of that, the > platform is currently fairly useless to me for actually communicating or > collaborating on code. FYI, I just looked and my notification counter brown popup box has an infinity symbol in it: https://github.com/inbox/notifications -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Wed, Apr 18, 2012 at 10:29:26AM -0400, Robert Haas wrote: > >> IME, bug trackers typically work best when used by a tightly > >> integrated team. > > > > Well, very many loosely distributed open-source projects use bug > > trackers quite successfully. > > > >> So I think Greg has exactly the right idea: we shouldn't try to > >> incorporate one of these systems that aims to manage workflow; > > > > Um, isn't half of the commitfest app about workflow? Patch is waiting > > for review, who is the reviewer, patch is waiting for author, who is the > > author, patch is ready for committer, who is the committer? And every > > week or so the commitfest manager (if any) produces a report on patch > > progress. Isn't that exactly what these "workflow management" systems > > provide? > > Yeah, but I thought we'd veered off into a digression about tracking > bug reports. Here's our workflow for bugs: > > 1. If they seem interesting, Tom fixes them. > 2. Or occasionally someone else fixes them. > 3. Otherwise, they drift forever in the bleakness of space. > > I've been conducting the experiment for a year or two now of leaving > unresolved bug reports unread in my mailbox. I've got over 100 such > emails now... and some of them may not really be bugs, but nobody's > put in the work to figure that out. It would be useful to have a I saved this email from April and have given it some thought. I decided to approach it by looking at our current workflow, then deciding what the problems were, rather than approaching it with "we need a bug tracker". I started by drawing a diagram of our current development process: http://momjian.us/main/writings/pgsql/work_flow.pdf I did this so I could see the weaknesses. First, the left and right sides are what our users see, and the middle is controlled by developers. Looking at the chart, the three sections, left, middle, and right, seem to work fine in isolation. Our interaction with bug reporters is very good, our development flow seems fine, and people are certainly happy with the quality of our releases. Yes, there are problems, like the ability of patches to get lost, but in general, things are good. I think our big gap is in integrating these sections. There is no easy way for a bug reporter to find out what happens to his report unless the patch is applied in the same email thread as the report. It is hard for users to see _all_ the changes made in a release because the release notes are filtered. Our current system is designed to have very limited friction of action, and this give us a high-quality user experience and release quality, but it does have limits in how well we deal with complex cases. OK, now for the question about a bug tracker. A bug tracker would provide a track-able contact for everyone reporting a bug, and allow them to see exactly what release fixes the bug (in an ideal world). It also allows for more detailed reporting of what is each release. For me, the big problem with a bug trackers is that it adds so much friction to the development process, meaning fewer people are involved and less work gets done. If you have company-sponsored development, you can just hire more people to overcome that friction, but for volunteer development, I am not sure a bug tracker really works well, and given the chaotic content in almost every bug tracker database, I think that is true. So, my question is, what can we do to better integrate these sections? Assign a bug number on email that gets stamped on the commit and release note item? Add email notification of commits somehow? Should we publish the entire git log for each release? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian <bruce@momjian.us> wrote: > I think our big gap is in integrating these sections. There is no easy > way for a bug reporter to find out what happens to his report unless the > patch is applied in the same email thread as the report. It is hard for > users to see _all_ the changes made in a release because the release > notes are filtered. > > Our current system is designed to have very limited friction of action, > and this give us a high-quality user experience and release quality, but > it does have limits in how well we deal with complex cases. I do basically agree with this. I was reflecting on the bug tracker issue (or lack thereof) for unrelated reasons earlier today and I think there are some very nice things to recommend the current email-based system, which are the reasons you identify above. Perhaps the area where it falls down is structured searches (such as for "closed" or "wontfix") and tracking progress of related, complex, or multi-part issues that span multiple root email messages. Maybe just using the message-ids to cross reference things (or at least morally: perhaps a point of indirection as to collapse multiple bug reports about the same thing, or to provide a place to add more annotation would be good, not unlike the CommitFest web application in relation to emails) is enough. Basically, perhaps an overlay on-top-of email might be a more supple way to figure out what process improvements work well without committing to a whole new tool chain and workflow all at once. -- fdr
On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote: > On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian <bruce@momjian.us> wrote: > > I think our big gap is in integrating these sections. There is no easy > > way for a bug reporter to find out what happens to his report unless the > > patch is applied in the same email thread as the report. It is hard for > > users to see _all_ the changes made in a release because the release > > notes are filtered. > > > > Our current system is designed to have very limited friction of action, > > and this give us a high-quality user experience and release quality, but > > it does have limits in how well we deal with complex cases. > > I do basically agree with this. I was reflecting on the bug tracker > issue (or lack thereof) for unrelated reasons earlier today and I > think there are some very nice things to recommend the current > email-based system, which are the reasons you identify above. Perhaps > the area where it falls down is structured searches (such as for > "closed" or "wontfix") and tracking progress of related, complex, or > multi-part issues that span multiple root email messages. I normally assume "friction" is just something that slows you down from attaining a goal, but open source development is only _possible_ because of the low friction communication available via the Internet. It isn't that open source development would be slower --- it would probably not exist in its current form (think shareware diskettes for an alternative). So, while it is hopeful to think of a bug trackers as just slowing us down, it might really alter our ability to develop software. Yes, I know most other projects use bug trackers, but I doubt their development and user interactions are the same quality as ours. On the flip side, for complex cases, some of our user interactions are terrible. > Maybe just using the message-ids to cross reference things (or at > least morally: perhaps a point of indirection as to collapse multiple > bug reports about the same thing, or to provide a place to add more > annotation would be good, not unlike the CommitFest web application in > relation to emails) is enough. Basically, perhaps an overlay > on-top-of email might be a more supple way to figure out what process > improvements work well without committing to a whole new tool chain > and workflow all at once. I know there is work to allow cross-month email archive threading, and that might help. I feel we have to be honest in what our current development process does poorly. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
<p>I wonder if maybe the nearest step towards "better bug tracker" is a more readily referenceable mail archive. <p>Clearly,one of our "frictions" is searching for relevant messages, so improved mail archive == lowered friction, no?<p>There'sa very particular use case; people keep rueing that indexes get cut off on a monthly basis. That's doubtlessnot the only pain, but it keeps getting mentioned, so solving it seems valuable.<p>Having a correlation betweencommits, commitfest entries, and associated email seems like another valuable addition.<p>Perhaps there are more... I'm not yet poking at anything that would suggest "email database", either.<p>A lot of the analysis would be morenetwork-oriented; putting more of a Prolog hat on, not so much tabular / relational ...
On Fri, Jul 06, 2012 at 08:44:13PM -0400, Christopher Browne wrote: > I wonder if maybe the nearest step towards "better bug tracker" is a more > readily referenceable mail archive. > > Clearly, one of our "frictions" is searching for relevant messages, so improved > mail archive == lowered friction, no? > > There's a very particular use case; people keep rueing that indexes get cut off > on a monthly basis. That's doubtless not the only pain, but it keeps getting > mentioned, so solving it seems valuable. Agreed. I think Magnus is working on having the threads span months. The big question is what are we going to do with this ability once we get it. > Having a correlation between commits, commitfest entries, and associated email > seems like another valuable addition. Yep. > Perhaps there are more... I'm not yet poking at anything that would suggest > "email database", either. > > A lot of the analysis would be more network-oriented; putting more of a Prolog > hat on, not so much tabular / relational ... To put a finer point on this, I think projects that interact with users via a bug tracker have much poorer user/developer communication, and also less impetus to fix bugs quickly, because it is already recorded in the tracker. And after not dealing with bugs immediately for a while, the bug database becomes huge, and developers can only triage the database, fixing commonly-reported bugs, and leaving the rest for later, which effectively means never. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Fri, Jul 6, 2012 at 6:41 PM, Daniel Farina <daniel@heroku.com> wrote: > I do basically agree with this. I was reflecting on the bug tracker > issue (or lack thereof) for unrelated reasons earlier today and I > think there are some very nice things to recommend the current > email-based system, which are the reasons you identify above. Perhaps > the area where it falls down is structured searches (such as for > "closed" or "wontfix") and tracking progress of related, complex, or > multi-part issues that span multiple root email messages. > > Maybe just using the message-ids to cross reference things (or at > least morally: perhaps a point of indirection as to collapse multiple > bug reports about the same thing, or to provide a place to add more > annotation would be good, not unlike the CommitFest web application in > relation to emails) is enough. Basically, perhaps an overlay > on-top-of email might be a more supple way to figure out what process > improvements work well without committing to a whole new tool chain > and workflow all at once. +1. This is almost word-for-word how I feel about it myself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Sat, Jul 7, 2012 at 1:46 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Fri, Jul 06, 2012 at 03:41:41PM -0700, Daniel Farina wrote: >> On Fri, Jul 6, 2012 at 12:21 PM, Bruce Momjian <bruce@momjian.us> wrote: >> > I think our big gap is in integrating these sections. There is no easy >> > way for a bug reporter to find out what happens to his report unless the >> > patch is applied in the same email thread as the report. It is hard for >> > users to see _all_ the changes made in a release because the release >> > notes are filtered. >> > >> > Our current system is designed to have very limited friction of action, >> > and this give us a high-quality user experience and release quality, but >> > it does have limits in how well we deal with complex cases. >> >> I do basically agree with this. I was reflecting on the bug tracker >> issue (or lack thereof) for unrelated reasons earlier today and I >> think there are some very nice things to recommend the current >> email-based system, which are the reasons you identify above. Perhaps >> the area where it falls down is structured searches (such as for >> "closed" or "wontfix") and tracking progress of related, complex, or >> multi-part issues that span multiple root email messages. > > I normally assume "friction" is just something that slows you down from > attaining a goal, but open source development is only _possible_ because > of the low friction communication available via the Internet. It isn't > that open source development would be slower --- it would probably not > exist in its current form (think shareware diskettes for an > alternative). I've never thought of it in terms of "friction", but I think that term makes a lot of sense. And it sums up pretty much one of the things that I find the most annoying with the commitfest app - in the end it boils down to the same thing. I find it annoying that whenever someone posts a new review or new comments, one has to *also* go into the CF app and add them there. Which leads to a lot of friction, which in turn leads to people not actually putting their comments in there, which decreases the value of the tool. Don't get me wrong - the cf app is a huge step up from no app at all. But it's just not done yet. >> Maybe just using the message-ids to cross reference things (or at >> least morally: perhaps a point of indirection as to collapse multiple >> bug reports about the same thing, or to provide a place to add more >> annotation would be good, not unlike the CommitFest web application in >> relation to emails) is enough. Basically, perhaps an overlay >> on-top-of email might be a more supple way to figure out what process >> improvements work well without committing to a whole new tool chain >> and workflow all at once. > > I know there is work to allow cross-month email archive threading, and > that might help. Yup, it's being worked on. FWIW, somewhere there's a piece of bugtracker code in a dusty corner that I once wrote that was intended as a prototype for something sitting as this "thin overlay on top of email". It worked reasonably well, and then crashed and burned when it came to the cross-month thread splitting. Once that is fixed (and unlike most times before (yes, there are exceptions) it's being actively worked on right now), it could be dusted off again - or something else could be built on top of that capability. > I feel we have to be honest in what our current development process does > poorly. +1. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: > I've never thought of it in terms of "friction", but I think that term > makes a lot of sense. And it sums up pretty much one of the things > that I find the most annoying with the commitfest app - in the end it > boils down to the same thing. I find it annoying that whenever someone > posts a new review or new comments, one has to *also* go into the CF > app and add them there. Which leads to a lot of friction, which in > turn leads to people not actually putting their comments in there, > which decreases the value of the tool. > > Don't get me wrong - the cf app is a huge step up from no app at all. > But it's just not done yet. Well, if that's the issue then there are well known solutions to that. Give each commitfest entry a tag, say, CF#8475 and add a bot to the mail server that examines each email for this tag and if found adds it to the CF app. This could then easily track commit messages, emails on mailing list and even bug reports. (For example, someone replys to a bug report with "See CF#8484" and then a reference to the bug thread gets pushed into the CF app.) It's also a searchable identifier, which is also useful for google. We do this at my work, it's a very low barrier method of linking different systems. Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > He who writes carelessly confesses thereby at the very outset that he does > not attach much importance to his own thoughts. -- Arthur Schopenhauer
On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout <kleptog@svana.org> wrote: > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: >> I've never thought of it in terms of "friction", but I think that term >> makes a lot of sense. And it sums up pretty much one of the things >> that I find the most annoying with the commitfest app - in the end it >> boils down to the same thing. I find it annoying that whenever someone >> posts a new review or new comments, one has to *also* go into the CF >> app and add them there. Which leads to a lot of friction, which in >> turn leads to people not actually putting their comments in there, >> which decreases the value of the tool. >> >> Don't get me wrong - the cf app is a huge step up from no app at all. >> But it's just not done yet. > > Well, if that's the issue then there are well known solutions to that. > Give each commitfest entry a tag, say, CF#8475 and add a bot to the > mail server that examines each email for this tag and if found adds it > to the CF app. So now you moved the friction over to the initial submitter instead, because he/she how has to get this tag before posting the patch in the first place. And this would need to happen before it's even known if this needs to go on a CF or will just be approved/rejected directly without even getting there. That's not to say it's a horrible idea, it's just to say that things are never as easy as they first look. BTW, the *bigger* issue with this path is that now we suddenly have different kinds of identifiers for different things. So you have a bug id, and a cf id, and they are different things. So you're going to end up tagging things with multiple id's. etc. That part goes to show that we cannot just "solve" this in one part of the workflow. We can put in useful workarounds that go pretty far - like the cf app - but we cannot get the "complete solution". OTOH, maybe we never can get the complete solution, but we should work hard at not locking into something else. > This could then easily track commit messages, emails on mailing list > and even bug reports. (For example, someone replys to a bug report > with "See CF#8484" and then a reference to the bug thread gets pushed > into the CF app.) All of these things are already "emails on mailing lists", after all... > It's also a searchable identifier, which is also useful for google. Yes, I agree that having a searchable and *referencable* identifier is a good thing. In fact, one of the main reasons to do something like this. Right now we just tell people "look in the archives", and that doesn't work. Heck, *I* search them quite often and I still don't understand how some people can find things so quickly :) -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: > >> I do basically agree with this. I was reflecting on the bug tracker > >> issue (or lack thereof) for unrelated reasons earlier today and I > >> think there are some very nice things to recommend the current > >> email-based system, which are the reasons you identify above. Perhaps > >> the area where it falls down is structured searches (such as for > >> "closed" or "wontfix") and tracking progress of related, complex, or > >> multi-part issues that span multiple root email messages. > > > > I normally assume "friction" is just something that slows you down from > > attaining a goal, but open source development is only _possible_ because > > of the low friction communication available via the Internet. It isn't > > that open source development would be slower --- it would probably not > > exist in its current form (think shareware diskettes for an > > alternative). > > I've never thought of it in terms of "friction", but I think that term > makes a lot of sense. And it sums up pretty much one of the things > that I find the most annoying with the commitfest app - in the end it > boils down to the same thing. I find it annoying that whenever someone > posts a new review or new comments, one has to *also* go into the CF > app and add them there. Which leads to a lot of friction, which in > turn leads to people not actually putting their comments in there, > which decreases the value of the tool. For me, we can't just say that our process is the the way it is because we have always done it that way, or because we are too lazy to change it. I think most of us have a gut feeling that our process is good, but we have to have some logic behind why we are doing things differently than most other projects, I think "friction" does explain a lot of it. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote: > On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout > <kleptog@svana.org> wrote: > > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: > >> I've never thought of it in terms of "friction", but I think that term > >> makes a lot of sense. And it sums up pretty much one of the things > >> that I find the most annoying with the commitfest app - in the end it > >> boils down to the same thing. I find it annoying that whenever someone > >> posts a new review or new comments, one has to *also* go into the CF > >> app and add them there. Which leads to a lot of friction, which in > >> turn leads to people not actually putting their comments in there, > >> which decreases the value of the tool. > >> > >> Don't get me wrong - the cf app is a huge step up from no app at all. > >> But it's just not done yet. > > > > Well, if that's the issue then there are well known solutions to that. > > Give each commitfest entry a tag, say, CF#8475 and add a bot to the > > mail server that examines each email for this tag and if found adds it > > to the CF app. > > So now you moved the friction over to the initial submitter instead, > because he/she how has to get this tag before posting the patch in the > first place. And this would need to happen before it's even known if > this needs to go on a CF or will just be approved/rejected directly > without even getting there. > > That's not to say it's a horrible idea, it's just to say that things > are never as easy as they first look. > > BTW, the *bigger* issue with this path is that now we suddenly have > different kinds of identifiers for different things. So you have a bug > id, and a cf id, and they are different things. So you're going to end > up tagging things with multiple id's. etc. That part goes to show that > we cannot just "solve" this in one part of the workflow. We can put in > useful workarounds that go pretty far - like the cf app - but we > cannot get the "complete solution". OTOH, maybe we never can get the > complete solution, but we should work hard at not locking into > something else. Yes, we would almost need to number each incoming email, and use that reference all the way through to the release note item text. or at least a searchable git log of the release note commits. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, Jul 7, 2012 at 4:42 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Sat, Jul 07, 2012 at 12:59:02PM +0200, Magnus Hagander wrote: >> On Sat, Jul 7, 2012 at 12:48 PM, Martijn van Oosterhout >> <kleptog@svana.org> wrote: >> > On Sat, Jul 07, 2012 at 11:36:41AM +0200, Magnus Hagander wrote: >> >> I've never thought of it in terms of "friction", but I think that term >> >> makes a lot of sense. And it sums up pretty much one of the things >> >> that I find the most annoying with the commitfest app - in the end it >> >> boils down to the same thing. I find it annoying that whenever someone >> >> posts a new review or new comments, one has to *also* go into the CF >> >> app and add them there. Which leads to a lot of friction, which in >> >> turn leads to people not actually putting their comments in there, >> >> which decreases the value of the tool. >> >> >> >> Don't get me wrong - the cf app is a huge step up from no app at all. >> >> But it's just not done yet. >> > >> > Well, if that's the issue then there are well known solutions to that. >> > Give each commitfest entry a tag, say, CF#8475 and add a bot to the >> > mail server that examines each email for this tag and if found adds it >> > to the CF app. >> >> So now you moved the friction over to the initial submitter instead, >> because he/she how has to get this tag before posting the patch in the >> first place. And this would need to happen before it's even known if >> this needs to go on a CF or will just be approved/rejected directly >> without even getting there. >> >> That's not to say it's a horrible idea, it's just to say that things >> are never as easy as they first look. >> >> BTW, the *bigger* issue with this path is that now we suddenly have >> different kinds of identifiers for different things. So you have a bug >> id, and a cf id, and they are different things. So you're going to end >> up tagging things with multiple id's. etc. That part goes to show that >> we cannot just "solve" this in one part of the workflow. We can put in >> useful workarounds that go pretty far - like the cf app - but we >> cannot get the "complete solution". OTOH, maybe we never can get the >> complete solution, but we should work hard at not locking into >> something else. > > Yes, we would almost need to number each incoming email, and use that > reference all the way through to the release note item text. or at least > a searchable git log of the release note commits. Which we in a lot of ways have - we have the messageid. But we need a nicer interface for people to use than that... But that serves pretty well as an underlying identifier. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote: > >> That's not to say it's a horrible idea, it's just to say that things > >> are never as easy as they first look. > >> > >> BTW, the *bigger* issue with this path is that now we suddenly have > >> different kinds of identifiers for different things. So you have a bug > >> id, and a cf id, and they are different things. So you're going to end > >> up tagging things with multiple id's. etc. That part goes to show that > >> we cannot just "solve" this in one part of the workflow. We can put in > >> useful workarounds that go pretty far - like the cf app - but we > >> cannot get the "complete solution". OTOH, maybe we never can get the > >> complete solution, but we should work hard at not locking into > >> something else. > > > > Yes, we would almost need to number each incoming email, and use that > > reference all the way through to the release note item text. or at least > > a searchable git log of the release note commits. > > Which we in a lot of ways have - we have the messageid. But we need a > nicer interface for people to use than that... But that serves pretty > well as an underlying identifier. Imagine a case where a single message-id could show all emails before and after that refer to it, and all commits and release note text associated with it. I think there are going to be cases where multiple email threads all represent the same item, of course, and might not be linked via email references. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Sat, Jul 7, 2012 at 4:48 PM, Bruce Momjian <bruce@momjian.us> wrote: > On Sat, Jul 07, 2012 at 04:45:42PM +0200, Magnus Hagander wrote: >> >> That's not to say it's a horrible idea, it's just to say that things >> >> are never as easy as they first look. >> >> >> >> BTW, the *bigger* issue with this path is that now we suddenly have >> >> different kinds of identifiers for different things. So you have a bug >> >> id, and a cf id, and they are different things. So you're going to end >> >> up tagging things with multiple id's. etc. That part goes to show that >> >> we cannot just "solve" this in one part of the workflow. We can put in >> >> useful workarounds that go pretty far - like the cf app - but we >> >> cannot get the "complete solution". OTOH, maybe we never can get the >> >> complete solution, but we should work hard at not locking into >> >> something else. >> > >> > Yes, we would almost need to number each incoming email, and use that >> > reference all the way through to the release note item text. or at least >> > a searchable git log of the release note commits. >> >> Which we in a lot of ways have - we have the messageid. But we need a >> nicer interface for people to use than that... But that serves pretty >> well as an underlying identifier. > > Imagine a case where a single message-id could show all emails before > and after that refer to it, and all commits and release note text > associated with it. I think there are going to be cases where multiple > email threads all represent the same item, of course, and might not be > linked via email references. Yes, that's the part that has to be taken care of by that "thin overlay over email". Some way of grouping multiple threads together,and somehow keep the end-status of them (rejected/comitted/wontfix/whatevryouwantocallthestatus). But not actually keeping a copy of the information anywhere else. -- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
Hackers, So I want to repeat this because I think we are conflating several uses for a "bug tracker" which aren't the same, and which really need to be dealt with seperately. -- Better CF App: to track feature submissions, discussion, revisions and reviews. -- Bug Submitter: easy-access way for users to submit bugs and check on their status later. -- Fix-Bug-Later Bug Tracker: a place to track bugs which are not immediately fixable due to complexity/breakage/external dependancies/priority. -- Fix Tracker: way for users to search if a particular issue was fixed, and what release it was fixed in. -- Testing Tracker: tool for user-testers to submit test reports for development and beta releases. The above are 5 different tasks with different requirements, and it's far from clear that we want a new tool for all of them (or even want all of them). -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 07/09/2012 12:02 PM, Josh Berkus wrote: > > Hackers, > > So I want to repeat this because I think we are conflating several uses > for a "bug tracker" which aren't the same, and which really need to be > dealt with seperately. > > -- Better CF App: to track feature submissions, discussion, revisions > and reviews. > > -- Bug Submitter: easy-access way for users to submit bugs and check on > their status later. > =============== > -- Fix-Bug-Later Bug Tracker: a place to track bugs which are not > immediately fixable due to complexity/breakage/external > dependancies/priority. > > -- Fix Tracker: way for users to search if a particular issue was fixed, > and what release it was fixed in. =============== These two should be able to be the same piece of sotware. > > -- Testing Tracker: tool for user-testers to submit test reports for > development and beta releases. > This might be able to be the same piece as fix-bug-later... with a different front end. > The above are 5 different tasks with different requirements, and it's > far from clear that we want a new tool for all of them (or even want all > of them). > Not sure how to handle the first two. Bug submission is always a pita and although we could use the fix-bug-later app, it would clutter it as we were trying to determine real bugs vs user error. Sincerely, jD -- Command Prompt, Inc. - http://www.commandprompt.com/ PostgreSQL Support, Training, Professional Services and Development The PostgreSQL Conference - http://www.postgresqlconference.org/ @cmdpromptinc - @postgresconf - 509-416-6579
On Mon, Jul 9, 2012 at 3:26 PM, Joshua D. Drake <jd@commandprompt.com> wrote: > > On 07/09/2012 12:02 PM, Josh Berkus wrote: >> >> >> Hackers, >> >> So I want to repeat this because I think we are conflating several uses >> for a "bug tracker" which aren't the same, and which really need to be >> dealt with seperately. >> >> -- Better CF App: to track feature submissions, discussion, revisions >> and reviews. >> >> -- Bug Submitter: easy-access way for users to submit bugs and check on >> their status later. > Not sure how to handle the first two. Bug submission is always a pita and > although we could use the fix-bug-later app, it would clutter it as we were > trying to determine real bugs vs user error. And whatever you/we do, be *VERY* aware of the "pile-of-...-in-the-bugtracker problem". I just happend to have Joel Spolsky's post come through my RSS reader, where he talked about about bugtrackers, and suggested: - Do not allow more than two weeks (in fix time) of bugs to get into the bug database. - If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back. The biggest problem of whatever tool is used for anything, is making sure tool is useful enough to people that need to use it to make it worth their while. A tracker (of any type) that is even *insanely* useful for users, but that doesn't give *developpers* (note, that's developpers, not managers, or cat-herders, or cheer-leaders) any extra value is bound to fill and soon become un-usefull for even uses.. If you want the develops to use it, it has to be worth their time *to them* to use it. Witness the hundreds of graves that are he thousands bugzilla bugs out there filed against even active open-source projects. a. -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
>>> -- Bug Submitter: easy-access way for users to submit bugs and check on >>> their status later. > >> Not sure how to handle the first two. Bug submission is always a pita and >> although we could use the fix-bug-later app, it would clutter it as we were >> trying to determine real bugs vs user error. > > And whatever you/we do, be *VERY* aware of the > "pile-of-...-in-the-bugtracker problem". I just happend to have Joel > Spolsky's post come through my RSS reader, where he talked about about > bugtrackers, and suggested: Well, frankly, I don't think we really want to make it easier for the *general public* to submit bugs than it already is. We're already getting enough quality bug reports to keep us busy. And I'm all-too-familiar with the failings of a "bug-losing system"; check the number of bugs I have filed against Thunderbird sometime. Where bug submission is broken that we care about is in two areas: 1. it's very difficult for the existing bug submitters to check status of their bugs after submission, or even find out if they went anywhere (if using the webform). 2. we don't have an API for downstream projects and products to submit bugs, which makes those projects think we don't care about bugs. Note that both of the above could be solved without having a public bugzilla instance. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com