On Wed, Apr 17, 2013 at 3:20 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Please also note that the first series of patches did include the > support code for all the core PL, but Robert didn't feel like commiting > that and no other commiter did step up.
Of course, the chances of that would have been a lot higher had you actually resubmitted the patches for other PLs as separate patches as I suggested. It's asking a bit much to suppose that some other committer was going to go root back through the old patches, extract the portion that applied to the PL they know something about, revise it to match the other changes that were made subsequent to the last patch version that incorporated those changes, and then commit it, without so much as a CommitFest entry to point them in the right direction. > I'm struggling to understand how to properly solve the problem here from > an organisation perspective. Before beta was not the good time for the > people involved, and was not the good time for other people to get > involved. Beta is not the good time to fix what couldn't be done before. Event triggers are suffering from the same problem as materialized views and CRCs: stuff that gets committed in the last CommitFest tends to be big and buggy. We could fix that problem by having one more CommitFest where we only accepted small patches, but then people would just try to force large patches into it after all, on the theory that they were almost done in the previous CommitFest or weren't, really, all that big (attachment: 30kB patch file). No matter what we do, there's always going to be some pain around the end of the development cycle. It's painful to see work that feels nearly done get its release date bumped by a year. And yet it's also painful to squeeze it in and find that there are still loose ends that you just don't quite have time to fix. You can phrase that problem in a way that makes it sound like it's about project policy or committers being jerks, but I think it's mostly just that deadlines suck. I have yet to work in a development organization - EnterpriseDB included - that suffered any less agita around release deliverables than the PostgreSQL community does. There are always - always! - people who want to slip the schedule to fit more into the release, people who want to slip more into the release WITHOUT slipping the schedule (thus upping the defect count), and people who want to stick to the schedule at any cost (and even if it means dumping the feature personally requested by God Himself). And, all the intermediate positions, too. All of those camps are as well-represented on pgsql-hackers as anywhere else. It is not as if any patches submitted now are going to go away. We will presumably have a CommitFest sometime in the next couple of months during which whatever didn't make it into 9.3 can go into 9.4 (or maybe, as I suspect, 10.0). Peter's complaint is legitimate, but it's not a stop-ship issue for 9.3, and the next train will be along shortly. I know that you're disappointed in how much got done with this feature for 9.3, but I think it will have more use cases than you realize, and the next version can and will be even better. Sure, in some ideal world, we could have done more, but you, I, and Alvaro all put a hell of a lot of work into this feature just to get it where it is, and I think we should take some significant pride in making as much progress as we did. If you'd asked me 2 years ago when PostgreSQL would have a feature of this type, my money would have been on NEVER. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
