Обсуждение: commitfest 2018-07
Per decision from the developer meeting, there will be a commitfest 2018-07 (unless there are concerns from the RMT). Could we set up the commitfest app appropriately? There were some discussions about renaming the existing 2018-09 entry versus inserting a new one at -07 and requiring patches to be moved back explicitly. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Jun 04, 2018 at 07:16:33PM -0400, Peter Eisentraut wrote: > Per decision from the developer meeting, there will be a commitfest > 2018-07 (unless there are concerns from the RMT). Thanks for raising the thread. > Could we set up the commitfest app appropriately? Sure. I have admin rights for that so I could do it. > There were some discussions about renaming the existing 2018-09 entry > versus inserting a new one at -07 and requiring patches to be moved back > explicitly. I would do that to reduce unnecessary log noise, but I was unsure of the actual status we are at. I am pretty sure that nobody is going to complain if what they submitted gets looked up two months earlier than what was previously planned, so I would vote to rename the existing 2018-09 to 2018-07, to rename the existing 2018-11 to 2018-09, and to create three new CF entries. -- Michael
Вложения
On 5 June 2018 at 11:16, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > Per decision from the developer meeting, there will be a commitfest > 2018-07 (unless there are concerns from the RMT). In absence of concerns from the RMT, does this mean v12 will be a 5 'fest cycle? -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
David Rowley <david.rowley@2ndquadrant.com> writes:
> On 5 June 2018 at 11:16, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> Per decision from the developer meeting, there will be a commitfest
>> 2018-07 (unless there are concerns from the RMT).
> In absence of concerns from the RMT, does this mean v12 will be a 5 'fest cycle?
Yes, that's the plan. The remaining fests will be on the same schedule
as last time.
regards, tom lane
Michael Paquier <michael@paquier.xyz> writes:
> On Mon, Jun 04, 2018 at 07:16:33PM -0400, Peter Eisentraut wrote:
>> There were some discussions about renaming the existing 2018-09 entry
>> versus inserting a new one at -07 and requiring patches to be moved back
>> explicitly.
> I would do that to reduce unnecessary log noise, but I was unsure of the
> actual status we are at. I am pretty sure that nobody is going to
> complain if what they submitted gets looked up two months earlier than
> what was previously planned, so I would vote to rename the existing
> 2018-09 to 2018-07, to rename the existing 2018-11 to 2018-09, and to
> create three new CF entries.
+1 for just renaming 2018-09 to 2018-07, if we can do that. We'll end
up postponing some entries back to -09, but that seems like less churn
than the other way.
regards, tom lane
On Mon, Jun 04, 2018 at 11:32:18PM -0400, Tom Lane wrote: > +1 for just renaming 2018-09 to 2018-07, if we can do that. We'll end > up postponing some entries back to -09, but that seems like less churn > than the other way. Okay. If we tend toward this direction, I propose to do this switch in two days my time (Thursday afternoon in Tokyo) if there are no objections, so as anybody has hopefully time to argue back. -- Michael
Вложения
On Tue, Jun 5, 2018 at 9:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Michael Paquier <michael@paquier.xyz> writes: >> On Mon, Jun 04, 2018 at 07:16:33PM -0400, Peter Eisentraut wrote: >>> There were some discussions about renaming the existing 2018-09 entry >>> versus inserting a new one at -07 and requiring patches to be moved back >>> explicitly. > >> I would do that to reduce unnecessary log noise, but I was unsure of the >> actual status we are at. I am pretty sure that nobody is going to >> complain if what they submitted gets looked up two months earlier than >> what was previously planned, so I would vote to rename the existing >> 2018-09 to 2018-07, to rename the existing 2018-11 to 2018-09, and to >> create three new CF entries. > > +1 for just renaming 2018-09 to 2018-07, if we can do that. We'll end > up postponing some entries back to -09, but that seems like less churn > than the other way. > Notes at [1] about keeping this commitfest for small patches. Just renaming the commitfest would mean all the patches, big and small, can be reviewed and committed. [1] https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Meeting -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
Greetings, * Ashutosh Bapat (ashutosh.bapat@enterprisedb.com) wrote: > On Tue, Jun 5, 2018 at 9:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Michael Paquier <michael@paquier.xyz> writes: > >> On Mon, Jun 04, 2018 at 07:16:33PM -0400, Peter Eisentraut wrote: > >>> There were some discussions about renaming the existing 2018-09 entry > >>> versus inserting a new one at -07 and requiring patches to be moved back > >>> explicitly. > > > >> I would do that to reduce unnecessary log noise, but I was unsure of the > >> actual status we are at. I am pretty sure that nobody is going to > >> complain if what they submitted gets looked up two months earlier than > >> what was previously planned, so I would vote to rename the existing > >> 2018-09 to 2018-07, to rename the existing 2018-11 to 2018-09, and to > >> create three new CF entries. > > > > +1 for just renaming 2018-09 to 2018-07, if we can do that. We'll end > > up postponing some entries back to -09, but that seems like less churn > > than the other way. > > Notes at [1] about keeping this commitfest for small patches. Just > renaming the commitfest would mean all the patches, big and small, can > be reviewed and committed. "Yes and no." While there were concerns raised that larger patches committed earlier might cause back-patching issues, the general consensus from my read of it was that it wasn't likely to be that big of an issue. While I suspect we'll still generally focus on getting smaller changes in during the 2018-07 cycle, to try and "clear the way" for the larger patches, I'm no longer concerned about larger patches which are ready being committed during that cycle. As such, I'm also +1 on the proposal to rename 2018-09 to 2018-07, and make the other renames and add a new one to the end. > [1] https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Meeting Thanks! Stephen
Вложения
On 2018-06-04 23:32:18 -0400, Tom Lane wrote: > Michael Paquier <michael@paquier.xyz> writes: > > On Mon, Jun 04, 2018 at 07:16:33PM -0400, Peter Eisentraut wrote: > >> There were some discussions about renaming the existing 2018-09 entry > >> versus inserting a new one at -07 and requiring patches to be moved back > >> explicitly. > > > I would do that to reduce unnecessary log noise, but I was unsure of the > > actual status we are at. I am pretty sure that nobody is going to > > complain if what they submitted gets looked up two months earlier than > > what was previously planned, so I would vote to rename the existing > > 2018-09 to 2018-07, to rename the existing 2018-11 to 2018-09, and to > > create three new CF entries. > > +1 for just renaming 2018-09 to 2018-07, if we can do that. We'll end > up postponing some entries back to -09, but that seems like less churn > than the other way. I'd rather create a new 2018-07, and just manually move old patches to it. Otherwise we'll not really focus on the glut of old things, but everyone just restarts working on their own new thing. Greetings, Andres Freund
Michael Paquier <michael@paquier.xyz> writes:
> Okay. If we tend toward this direction, I propose to do this switch in
> two days my time (Thursday afternoon in Tokyo) if there are no
> objections, so as anybody has hopefully time to argue back.
I think we probably have to wait longer. It's not clear to me when the
RMT will decide that the 07 fest is go or no-go, but surely they've
not decided yet.
regards, tom lane
Andres Freund <andres@anarazel.de> writes:
> I'd rather create a new 2018-07, and just manually move old patches to
> it. Otherwise we'll not really focus on the glut of old things, but
> everyone just restarts working on their own new thing.
I thought the idea was to clear out the underbrush of small, ready-to-go
patches. How old they are doesn't enter into that.
There's a separate issue about what to do to prioritize old patches so
they don't linger indefinitely. We had a discussion about that at the
dev meeting, but I don't think any specific mechanism was agreed to?
regards, tom lane
On 2018-06-05 10:20:55 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I'd rather create a new 2018-07, and just manually move old patches to > > it. Otherwise we'll not really focus on the glut of old things, but > > everyone just restarts working on their own new thing. > > I thought the idea was to clear out the underbrush of small, ready-to-go > patches. How old they are doesn't enter into that. > > There's a separate issue about what to do to prioritize old patches so > they don't linger indefinitely. We had a discussion about that at the > dev meeting, but I don't think any specific mechanism was agreed to? I think we've not fully agreed on that. I'd argue we should manually filter things into the next CF. And both small patches and older things should qualify. Greetings, Andres Freund
On 06/05/2018 10:43 AM, Andres Freund wrote: > On 2018-06-05 10:20:55 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> I'd rather create a new 2018-07, and just manually move old patches to >>> it. Otherwise we'll not really focus on the glut of old things, but >>> everyone just restarts working on their own new thing. >> >> I thought the idea was to clear out the underbrush of small, ready-to-go >> patches. How old they are doesn't enter into that. >> >> There's a separate issue about what to do to prioritize old patches so >> they don't linger indefinitely. We had a discussion about that at the >> dev meeting, but I don't think any specific mechanism was agreed to? > > I think we've not fully agreed on that. I'd argue we should manually > filter things into the next CF. And both small patches and older things > should qualify. Would it work to rename 2018-09 to 2018-07 and then make a pass through and move some of the entries to the next commitfest right away? That seems easier than the alternative unless you think less than half of what is there should be in 2018-07. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
Joe Conway <mail@joeconway.com> writes:
> On 06/05/2018 10:43 AM, Andres Freund wrote:
>> I think we've not fully agreed on that. I'd argue we should manually
>> filter things into the next CF. And both small patches and older things
>> should qualify.
> Would it work to rename 2018-09 to 2018-07 and then make a pass through
> and move some of the entries to the next commitfest right away? That
> seems easier than the alternative unless you think less than half of
> what is there should be in 2018-07.
Either way, we need some consensus on which patches are not going to be
considered in 07.
regards, tom lane
On 06/05/2018 10:43 AM, Andres Freund wrote: > On 2018-06-05 10:20:55 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: >>> I'd rather create a new 2018-07, and just manually move old patches to >>> it. Otherwise we'll not really focus on the glut of old things, but >>> everyone just restarts working on their own new thing. >> I thought the idea was to clear out the underbrush of small, ready-to-go >> patches. How old they are doesn't enter into that. >> >> There's a separate issue about what to do to prioritize old patches so >> they don't linger indefinitely. We had a discussion about that at the >> dev meeting, but I don't think any specific mechanism was agreed to? > I think we've not fully agreed on that. I'd argue we should manually > filter things into the next CF. And both small patches and older things > should qualify. > Maybe we should just move everything that was there on say May 1 and not accept anything new for July. I note a substantial number of items in the bug fix category. It would certainly be good to reduce that. On a positive note, as a result of adding the new committers, quite a large number of patches now have a committer as author and/or reviewer. So I'm somewhat hopeful we can clear away a lot of the deadwood in July. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Greetings, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Joe Conway <mail@joeconway.com> writes: > > On 06/05/2018 10:43 AM, Andres Freund wrote: > >> I think we've not fully agreed on that. I'd argue we should manually > >> filter things into the next CF. And both small patches and older things > >> should qualify. > > > Would it work to rename 2018-09 to 2018-07 and then make a pass through > > and move some of the entries to the next commitfest right away? That > > seems easier than the alternative unless you think less than half of > > what is there should be in 2018-07. > > Either way, we need some consensus on which patches are not going to be > considered in 07. I have a pretty hard time believing that we're going to actually manage to pull this off, and the argument against larger patches going in during the July commitfest was largely shot down during the dev meeting anyway. Let's keep the tech side of this simple and just do the rename as suggested and then we can encourage committers to review the smaller/older patches by providing information about the objective size and age of them, which will likely lead to the same result without all the fuss over what patch should be in what commitfest. Thanks! Stephen
Вложения
On 6 June 2018 at 02:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I thought the idea was to clear out the underbrush of small, ready-to-go > patches. How old they are doesn't enter into that. I don't recall a 'fest where small ready to go patches getting anything but priority. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
On 2018-06-06 03:14:58 +1200, David Rowley wrote: > On 6 June 2018 at 02:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I thought the idea was to clear out the underbrush of small, ready-to-go > > patches. How old they are doesn't enter into that. > > I don't recall a 'fest where small ready to go patches getting > anything but priority. I'm not following what you mean. Tom's referencing a discussion at the developer meeting last week... Greetings, Andres Freund
On 6/5/18 09:12, Andres Freund wrote: > I'd rather create a new 2018-07, and just manually move old patches to > it. My concern is whether the commitfest app will handle that well. There is no "move to previous commit fest" button. So you'd have to do it in some evil way, possibly confusing the continuity of the patch records. There might be other issues of this sort. I don't think this use case is fully worked out. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6 June 2018 at 03:17, Andres Freund <andres@anarazel.de> wrote: > On 2018-06-06 03:14:58 +1200, David Rowley wrote: >> On 6 June 2018 at 02:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > I thought the idea was to clear out the underbrush of small, ready-to-go >> > patches. How old they are doesn't enter into that. >> >> I don't recall a 'fest where small ready to go patches getting >> anything but priority. > > I'm not following what you mean. Tom's referencing a discussion at the > developer meeting last week... I mean that if the idea was to use the July 'fest to just process the small patches that are ready to go, then I didn't see the point as those ones are generally the first to get looked at anyway. It's the big patches that take the time. Getting rid of the smaller ones first has always made sense since it reduces the list and admin time maintaining the status page. I personally think that some of the trouble we have on the final 'fest is due to 4 fests not being enough for larger patches and people (I'll include myself) are often stubborn to concede to waiting another year. If larger patches can get looked at even earlier, then perhaps the situation will be slightly better in March 2019. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
> On Jun 5, 2018, at 10:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Michael Paquier <michael@paquier.xyz> writes: >> Okay. If we tend toward this direction, I propose to do this switch in >> two days my time (Thursday afternoon in Tokyo) if there are no >> objections, so as anybody has hopefully time to argue back. > > I think we probably have to wait longer. It's not clear to me when the > RMT will decide that the 07 fest is go or no-go, but surely they've > not decided yet. The RMT has its every-other-week catchup planned for tomorrow, and we will discuss if we see any obstacles then and report back posthaste. Jonathan
On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote: > Let's keep the tech side of this simple and just do the rename as > suggested and then we can encourage committers to review the > smaller/older patches by providing information about the objective size > and age of them, which will likely lead to the same result without all > the fuss over what patch should be in what commitfest. From a technical point of view with the CF app, it is possible to move a patch to the "next" CF but it is not possible to choose to which commit fest a patch is moved. I am not sure how the CF app chooses this next CF, does it choose based on the ID number of a CF, which increases for each new creation or based on its name? Magnus would know that, my bet goes for the ID-based selection.. If my guess is right and that you create a CF with a name older than an existing entry, then the whole patch flow would be messed up. So a rename is just much more simple at the end. -- Michael
Вложения
On Wed, Jun 6, 2018 at 12:29 AM, Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Jun 05, 2018 at 11:03:33AM -0400, Stephen Frost wrote:
> Let's keep the tech side of this simple and just do the rename as
> suggested and then we can encourage committers to review the
> smaller/older patches by providing information about the objective size
> and age of them, which will likely lead to the same result without all
> the fuss over what patch should be in what commitfest.
From a technical point of view with the CF app, it is possible to move a
patch to the "next" CF but it is not possible to choose to which commit
fest a patch is moved. I am not sure how the CF app chooses this next
CF, does it choose based on the ID number of a CF, which increases for
each new creation or based on its name? Magnus would know that, my bet
goes for the ID-based selection.. If my guess is right and that you
create a CF with a name older than an existing entry, then the whole
patch flow would be messed up. So a rename is just much more simple at
the end.
The logic for what it moves it to is basically:
* If there is an open CF, move it to that one unless we are moving from that one
* If there is more than one open CF, error
* Else find the "future" commitfest, if one exists, and movei t ther
* If more than one future commitfest exists, error
* If no future commitfest exists, error.
I think it's also setting us up for all sorts of fun errors if it get bounced *again*. E.g. if you "move to next cf" from the 09 cf to the 07, but then have to "move to next cf" *again* back to 09. That would violate a unique constraint, so it wouldn't work, and I'm unsure how the system would actually react to it.
Thus, if we don't want to have to risk doing surgery on the system (or guarantee we won't bounce any patches from the 07 CF, but that seems like the wrong thing to do), we should rename the existing 09 CF to 07, so all patches automatically end up there, and stick to only "bouncing patches in the forward direction".
On Tue, Jun 05, 2018 at 11:20:57AM -0400, Peter Eisentraut wrote: > On 6/5/18 09:12, Andres Freund wrote: >> I'd rather create a new 2018-07, and just manually move old patches to >> it. > > My concern is whether the commitfest app will handle that well. There > is no "move to previous commit fest" button. So you'd have to do it in > some evil way, possibly confusing the continuity of the patch records. > There might be other issues of this sort. I don't think this use case > is fully worked out. Yeah, that's the point I just raised before seeing this email. Renaming is just going to be more simple at the end. -- Michael
Вложения
On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz <jonathan.katz@excoventures.com> wrote:On Jun 5, 2018, at 10:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael@paquier.xyz> writes:Okay. If we tend toward this direction, I propose to do this switch in
two days my time (Thursday afternoon in Tokyo) if there are no
objections, so as anybody has hopefully time to argue back.
I think we probably have to wait longer. It's not clear to me when the
RMT will decide that the 07 fest is go or no-go, but surely they've
not decided yet.
The RMT has its every-other-week catchup planned for tomorrow,
and we will discuss if we see any obstacles then and report back
posthaste.
Reporting back from the RMT meeting, the final decision on this has not yet
been made, but here is some guidance:
- The main focus of the RMT is ensuring that PostgreSQL 11 is as stable
as possible and we encourage the community to continue working on the
open items[1] and ensuring this list is small.
- We do need someone to volunteer for CFM (and for anyone new,
CFM means "commitfest manager” :-) because without a CFM there is
no commitfest.
- Per discussions at the developer meeting, we do encourage the CFM
to perform some initial triage to try to move larger patches to 2018-09 CF
so that way we are not distracted while polishing and stabilizing the 11
release.
With the usual exception for forward looking statements, based on the
current open items we do not anticipate anything delaying the start of the
2018-07 CF, unless something really bad comes up, but let’s ensure we
have someone who is ready to lead the CF effort and we continue
solving the open issues.
Thanks,
Jonathan
On 06/06/2018 11:57 AM, Jonathan S. Katz wrote: > >> On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz >> <jonathan.katz@excoventures.com >> <mailto:jonathan.katz@excoventures.com>> wrote: >> >> >>> On Jun 5, 2018, at 10:14 AM, Tom Lane <tgl@sss.pgh.pa.us >>> <mailto:tgl@sss.pgh.pa.us>> wrote: >>> >>> Michael Paquier <michael@paquier.xyz <mailto:michael@paquier.xyz>> >>> writes: >>>> Okay. If we tend toward this direction, I propose to do this switch in >>>> two days my time (Thursday afternoon in Tokyo) if there are no >>>> objections, so as anybody has hopefully time to argue back. >>> >>> I think we probably have to wait longer. It's not clear to me when the >>> RMT will decide that the 07 fest is go or no-go, but surely they've >>> not decided yet. >> >> The RMT has its every-other-week catchup planned for tomorrow, >> and we will discuss if we see any obstacles then and report back >> posthaste. > > Reporting back from the RMT meeting, the final decision on this has > not yet > been made, but here is some guidance: > > - The main focus of the RMT is ensuring that PostgreSQL 11 is as stable > as possible and we encourage the community to continue working on the > open items[1] and ensuring this list is small. > > - We do need someone to volunteer for CFM (and for anyone new, > CFM means "commitfest manager” :-) because without a CFM there is > no commitfest. > > - Per discussions at the developer meeting, we do encourage the CFM > to perform some initial triage to try to move larger patches to 2018-09 CF > so that way we are not distracted while polishing and stabilizing the 11 > release. > > With the usual exception for forward looking statements, based on the > current open items we do not anticipate anything delaying the start of the > 2018-07 CF, unless something really bad comes up, but let’s ensure we > have someone who is ready to lead the CF effort and we continue > solving the open issues. > > Thanks, > > Jonathan > > [1] https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items I'll volunteer for CFM, which seems appropriate since I was one of the supporters of having an extra CF. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: > I'll volunteer for CFM, which seems appropriate since I was one of the > supporters of having an extra CF. I don't mind helping out either. There are many patches to handle. -- Michael
Вложения
> On Jun 6, 2018, at 8:14 PM, Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: >> I'll volunteer for CFM, which seems appropriate since I was one of the >> supporters of having an extra CF. > > I don't mind helping out either. There are many patches to handle. +1 to either both of you working together or one of you taking the charge. Doing a scan, there are currently 152 patches in there and presumably more on the way. Scanning through the most recent CFs it appears # patches ranged from 150-250, and conceivably the lower end of that # is still a lot to manage for one person. Jonathan
On Thu, Jun 7, 2018 at 8:38 AM, Jonathan S. Katz <jkatz@postgresql.org> wrote: > >> On Jun 6, 2018, at 8:14 PM, Michael Paquier <michael@paquier.xyz> wrote: >> >> On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: >>> I'll volunteer for CFM, which seems appropriate since I was one of the >>> supporters of having an extra CF. >> >> I don't mind helping out either. There are many patches to handle. > > +1 to either both of you working together or one of you taking the charge. > > Doing a scan, there are currently 152 patches in there and presumably > more on the way. Scanning through the most recent CFs it appears # patches > ranged from 150-250, and conceivably the lower end of that # is still a lot to > manage for one person. Count on me if you need more helping hands. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company
On Wed, Jun 06, 2018 at 12:38:56AM +0200, Magnus Hagander wrote: > Thus, if we don't want to have to risk doing surgery on the system (or > guarantee we won't bounce any patches from the 07 CF, but that seems like > the wrong thing to do), we should rename the existing 09 CF to 07, so all > patches automatically end up there, and stick to only "bouncing patches in > the forward direction". So, we have confirmation from the RTM that there will be a 2018-07. And there is visibly consensus that renaming 2018-09 to 2018-07 makes the most sense. Any objections in moving forward with this renaming at the 5-CF plan for v12? -- Michael
Вложения
Hi, On 2018-06-11 11:50:55 +0900, Michael Paquier wrote: > On Wed, Jun 06, 2018 at 12:38:56AM +0200, Magnus Hagander wrote: > > Thus, if we don't want to have to risk doing surgery on the system (or > > guarantee we won't bounce any patches from the 07 CF, but that seems like > > the wrong thing to do), we should rename the existing 09 CF to 07, so all > > patches automatically end up there, and stick to only "bouncing patches in > > the forward direction". > > So, we have confirmation from the RTM that there will be a 2018-07. And > there is visibly consensus that renaming 2018-09 to 2018-07 makes the > most sense. Any objections in moving forward with this renaming at the > 5-CF plan for v12? FWIW, I still think it'd be a better plan to explicitly move things, rather than just rename. But concensus isn't unamity, so ... Greetings, Andres Freund
On Mon, Jun 11, 2018 at 10:34:55AM -0700, Andres Freund wrote: > On 2018-06-11 11:50:55 +0900, Michael Paquier wrote: >> So, we have confirmation from the RTM that there will be a 2018-07. And >> there is visibly consensus that renaming 2018-09 to 2018-07 makes the >> most sense. Any objections in moving forward with this renaming at the >> 5-CF plan for v12? > > FWIW, I still think it'd be a better plan to explicitly move things, > rather than just rename. But concensus isn't unamity, so ... Well, at least we have a consensus. I have gone through the CF app and just did the renaming, creating new commit fests on the way. -- Michael
Вложения
On 06/07/2018 09:01 AM, Ashutosh Bapat wrote: > On Thu, Jun 7, 2018 at 8:38 AM, Jonathan S. Katz <jkatz@postgresql.org> wrote: >>> On Jun 6, 2018, at 8:14 PM, Michael Paquier <michael@paquier.xyz> wrote: >>> >>> On Wed, Jun 06, 2018 at 12:40:40PM -0400, Andrew Dunstan wrote: >>>> I'll volunteer for CFM, which seems appropriate since I was one of the >>>> supporters of having an extra CF. >>> I don't mind helping out either. There are many patches to handle. >> +1 to either both of you working together or one of you taking the charge. >> >> Doing a scan, there are currently 152 patches in there and presumably >> more on the way. Scanning through the most recent CFs it appears # patches >> ranged from 150-250, and conceivably the lower end of that # is still a lot to >> manage for one person. > Count on me if you need more helping hands. > Well, this went quiet. I'm happy to be CFM and assisted by Michael and Ashutosh Are there any privileges required that I should see about obtaining? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Greetings, * Andrew Dunstan (andrew.dunstan@2ndquadrant.com) wrote: > Well, this went quiet. I'm happy to be CFM and assisted by Michael and > Ashutosh > > Are there any privileges required that I should see about obtaining? I've set you up with the cf admin privs (which Michael also has). Please let me know if you need anything further. Thanks! Stephen