Thread: commit fest schedule for 9.4
In the last two years, the first commit fest started in June, which is about a month from now. If we are going to do that again, we should clarify that as soon as possible. And if we are not, then we should also clarify that, because some people are probably expecting that we are. So, any thoughts on the commit fest schedule, any need for deviations, or same old?
Peter Eisentraut <peter_e@gmx.net> writes:
> In the last two years, the first commit fest started in June, which is
> about a month from now. If we are going to do that again, we should
> clarify that as soon as possible. And if we are not, then we should
> also clarify that, because some people are probably expecting that we
> are.
> So, any thoughts on the commit fest schedule, any need for deviations,
> or same old?
Usually this is settled at the PGCon developers' meeting ...
regards, tom lane
On Mon, 2013-05-13 at 22:38 -0400, Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > In the last two years, the first commit fest started in June, which is > > about a month from now. If we are going to do that again, we should > > clarify that as soon as possible. And if we are not, then we should > > also clarify that, because some people are probably expecting that we > > are. > > > So, any thoughts on the commit fest schedule, any need for deviations, > > or same old? > > Usually this is settled at the PGCon developers' meeting ... But it doesn't have to, does it? If there is nothing to change then we might as well settle it here and save the meeting for more interesting things. But if someone wants to argue for adjustments, it'd be better to collect arguments here rather than argue all of it out in 15 mins or so without any preparation. (The same goes for all agenda items in that meeting. At one point there was a guideline to discuss items on the mailing list before the meeting.)
On 14.05.2013 05:34, Peter Eisentraut wrote: > In the last two years, the first commit fest started in June, which is > about a month from now. If we are going to do that again, we should > clarify that as soon as possible. And if we are not, then we should > also clarify that, because some people are probably expecting that we > are. > > So, any thoughts on the commit fest schedule, any need for deviations, > or same old? Same old sounds good to me. We released 9.3beta1 at the same time this year that we released 9.2beta1 last year. I've been quite happy with the 9.3 schedule. There are a few items on the 9.3 Open Items list, but I would expect them to be resolved in the next week or two, so that barring any major new issues, we could release 9.3beta2 at the end of May, like we released 9.2beta2 last year. - Heikki
On 05/13/2013 08:13 PM, Peter Eisentraut wrote: > On Mon, 2013-05-13 at 22:38 -0400, Tom Lane wrote: >> Peter Eisentraut <peter_e@gmx.net> writes: >>> In the last two years, the first commit fest started in June, which is >>> about a month from now. If we are going to do that again, we should >>> clarify that as soon as possible. And if we are not, then we should >>> also clarify that, because some people are probably expecting that we >>> are. Given the long list of patches in 2013-next, I see no reason we couldn't open a CF on 6/15. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On Mon, May 13, 2013 at 11:13 PM, Peter Eisentraut <peter_e@gmx.net> wrote: > On Mon, 2013-05-13 at 22:38 -0400, Tom Lane wrote: >> Peter Eisentraut <peter_e@gmx.net> writes: >> > In the last two years, the first commit fest started in June, which is >> > about a month from now. If we are going to do that again, we should >> > clarify that as soon as possible. And if we are not, then we should >> > also clarify that, because some people are probably expecting that we >> > are. >> >> > So, any thoughts on the commit fest schedule, any need for deviations, >> > or same old? >> >> Usually this is settled at the PGCon developers' meeting ... > > But it doesn't have to, does it? > > If there is nothing to change then we might as well settle it here and > save the meeting for more interesting things. But if someone wants to > argue for adjustments, it'd be better to collect arguments here rather > than argue all of it out in 15 mins or so without any preparation. > > (The same goes for all agenda items in that meeting. At one point there > was a guideline to discuss items on the mailing list before the > meeting.) +1 from me for prior discussion via email of any and all topics to be covered at the meeting. And +1 from me for keeping the same CommitFest schedule we had last year, and using the meeting time for something more interesting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Heikki Linnakangas wrote: > On 14.05.2013 05:34, Peter Eisentraut wrote: > >In the last two years, the first commit fest started in June, which is > >about a month from now. If we are going to do that again, we should > >clarify that as soon as possible. And if we are not, then we should > >also clarify that, because some people are probably expecting that we > >are. > > > >So, any thoughts on the commit fest schedule, any need for deviations, > >or same old? > > Same old sounds good to me. We released 9.3beta1 at the same time > this year that we released 9.2beta1 last year. I've been quite happy > with the 9.3 schedule. There are a few items on the 9.3 Open Items > list, but I would expect them to be resolved in the next week or > two, so that barring any major new issues, we could release 9.3beta2 > at the end of May, like we released 9.2beta2 last year. Uhm. If I've been anything wrt the 9.3 schedule, happy is not it. We completely failed to manage it in any kind of sane way. I vote +1 for keeping the same commitfest schedule this year, but please let's do everyone a favor and make sure we get some more (stricter?) management of the commitfests this time. Not closing the November commitfest in March would be appreciated, I think. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 05/15/2013 10:30 AM, Alvaro Herrera wrote: > Uhm. If I've been anything wrt the 9.3 schedule, happy is not it. We > completely failed to manage it in any kind of sane way. I vote +1 for > keeping the same commitfest schedule this year, but please let's do > everyone a favor and make sure we get some more (stricter?) management > of the commitfests this time. Not closing the November commitfest in > March would be appreciated, I think. Well, we could actually *follow* the schedule we outlined at the Developer Meeting last year, including the triage periods. I'll also say: * we need to assign CF managers at least 2 weeks in advance of each CF * we need to replace them if they get too busy to follow-through, * and the last CF needs two managers. We went pretty far off schedule this year because we didn't manage the process. Especially given the rudimentary tools we have to work with, we can't afford to do that. I'd be happy to manage the first CF on June 15th, if nobody else wants to. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
Josh Berkus wrote: > On 05/15/2013 10:30 AM, Alvaro Herrera wrote: > > Uhm. If I've been anything wrt the 9.3 schedule, happy is not it. We > > completely failed to manage it in any kind of sane way. I vote +1 for > > keeping the same commitfest schedule this year, but please let's do > > everyone a favor and make sure we get some more (stricter?) management > > of the commitfests this time. Not closing the November commitfest in > > March would be appreciated, I think. > > Well, we could actually *follow* the schedule we outlined at the > Developer Meeting last year, including the triage periods. > > I'll also say: > * we need to assign CF managers at least 2 weeks in advance of each CF * > we need to replace them if they get too busy to follow-through, > * and the last CF needs two managers. Obviously we need a meta-manager who makes sure we have managers, and is able to notice that a manager is MIA and needs replaced (or at least backed-up). -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
> Obviously we need a meta-manager who makes sure we have managers, and is > able to notice that a manager is MIA and needs replaced (or at least > backed-up). And then a meta-meta-manager to make sure that the meta-manager is meta-managing. And an Inspector General. Anyone have Danny Kaye's phone number? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
On 05/15/2013 02:00 PM, Josh Berkus wrote: >> Obviously we need a meta-manager who makes sure we have managers, and is >> able to notice that a manager is MIA and needs replaced (or at least >> backed-up). > And then a meta-meta-manager to make sure that the meta-manager is > meta-managing. > > And an Inspector General. Anyone have Danny Kaye's phone number? > Or Gogol's? cheers andrew
On 05/15/2013 11:05 AM, Andrew Dunstan wrote: > > On 05/15/2013 02:00 PM, Josh Berkus wrote: >>> Obviously we need a meta-manager who makes sure we have managers, and is >>> able to notice that a manager is MIA and needs replaced (or at least >>> backed-up). Actuall, on a more serious basis, we could simply assign a backup CFM (CFM-b) for each CF. The backup CFM would jump in if nobody has heard from the CFM for several days. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
2013-05-15 20:05 keltezéssel, Andrew Dunstan írta: > > On 05/15/2013 02:00 PM, Josh Berkus wrote: >>> Obviously we need a meta-manager who makes sure we have managers, and is >>> able to notice that a manager is MIA and needs replaced (or at least >>> backed-up). >> And then a meta-meta-manager to make sure that the meta-manager is >> meta-managing. >> >> And an Inspector General. Anyone have Danny Kaye's phone number? >> > > Or Gogol's? You have to learn the dialing chant to call them... ;-) > > cheers > > andrew > > -- ---------------------------------- 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 05/16/2013 01:44 AM, Josh Berkus wrote: > I'll also say: > * we need to assign CF managers at least 2 weeks in advance of each CF * > we need to replace them if they get too busy to follow-through, > * and the last CF needs two managers. Strong +1 on both of those. I tried to pick up a CF that was already totally off the rails most of the way through, then had a bunch of other work come in. Add inexperience with the process and, well, it didn't go well. I see nothing but advantages in having more than one person involved. A decent lead-in rather than trying to step in once it's already in progress and badly behind would make a world of difference too. Finally, I'd like to see the CFs can be kept short enough and closed on schedule ready-or-not with all open work bumped to the next CF, so that people doing the CF as part of their work can schedule their participation properly rather than having it open-ended and uncertain. This would make it a lot easier to get a firm commitment of dedicated time. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 28.05.2013 01:12, Craig Ringer wrote: > On 05/16/2013 01:44 AM, Josh Berkus wrote: >> I'll also say: >> * we need to assign CF managers at least 2 weeks in advance of each CF * >> we need to replace them if they get too busy to follow-through, >> * and the last CF needs two managers. > Strong +1 on both of those. > > I tried to pick up a CF that was already totally off the rails most of > the way through, then had a bunch of other work come in. Add > inexperience with the process and, well, it didn't go well. > > I see nothing but advantages in having more than one person involved. Shared responsibility is no-one's responsibility. If we are to have multiple CF managers, I think it would be good to have one who's mainly responsible, and the second one's job is to nag the first manager if nothing happens, and quickly take over if necessary. Ie. a hot standby arrangement, rather than two equal CF managers. - Heikki
> Shared responsibility is no-one's responsibility. If we are to have > multiple CF managers, I think it would be good to have one who's mainly > responsible, and the second one's job is to nag the first manager if > ernothing happens, and quickly take over if necessary. Ie. a hot standby > arrangement, rather than two equal CF managers. Because, of course, we have zero experience coordinating tasks with other contributors over the internet. I agree that one CFM needs to be "senior" (there's a lot of judgement calls involved) but I don't agree that CFM needs to be a single-threaded task. Speaking of which, I still need a backup CFM for CF1. Any volunteers? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com