Re: Commitfest 2018-07 WOA items

[Andrew Dunstan]

On 08/09/2018 06:00 PM, Andrew Dunstan wrote:



https://commitfest.postgresql.org/18/1644/ Add 
--include-table-data-where option to pg_dump, to export only a subset 
of table data

I'm not really clear what we're waiting on the author for.

https://commitfest.postgresql.org/18/1635/ libpq compression
No activity since early June. The author and the reviewers seem to be 
somewhat at odds.

I'm inclined to return this with feedback.

https://commitfest.postgresql.org/18/1252/ Foreign Key Arrays
Nothing since May
Suggest Return with feedback.

https://commitfest.postgresql.org/18/1710/ Row filtering for logical 
replication

No progress since March
Suggest Return with Feedback






After consideration and rereading the email threads, I decided not to 
return any of these. The first two were changed to "needs review". libpq 
compression is still a bit of a worry, though.


cheers

andrew

Re: Commitfest 2018-07 WOA items

[Andrew Dunstan]

On 08/09/2018 06:19 PM, Alvaro Herrera wrote:

On 2018-Aug-09, Andrew Dunstan wrote:


https://commitfest.postgresql.org/18/1252/ Foreign Key Arrays
Nothing since May
Suggest Return with feedback.

Please keep it around for my sake.




OK. I spent some time looking at it today, and it's a bit of a mess, but 
over to you.


cheers

andrew

--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Commitfest 2018-07 RFC items

[Fabien COELHO]

Hello Andrew,

https://commitfest.postgresql.org/18/669/ pgbench - allow to store select 
results into variables



Latest patch has not been reviewed
Recommendation: change to "needs review" and move


AFAICS the latest patch is a trivial rebase after some perl automatic 
indentation changes, there was no new contents per se.


--
Fabien

Re: Commitfest 2018-07 WOA items

[Alvaro Herrera]

On 2018-Aug-09, Andrew Dunstan wrote:

> https://commitfest.postgresql.org/18/1252/ Foreign Key Arrays
> Nothing since May
> Suggest Return with feedback.

Please keep it around for my sake.

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: commitfest 2018-07

[Andrew Dunstan]

Well, here we are at the end of July.


here's the current state of Commitfest 2018-07:


*Status summary: *Needs review 
: 83. Waiting on 
Author : 31. Ready for 
Committer : 17. 
Committed : 54. Moved 
to next CF : 8. 
Rejected : 5. Returned 
with Feedback : 2. 
Total : 200.







My apologies to the community for not wrapping up the commitfest in a 
more timely fashion. I have been somewhat overtaken by events that 
unexpectedly claimed my time. I'm currently working through the open 
items to determine a recommended disposition.



cheers


andrew



--
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Commitfest 2018-07 is underway

[Tatsuo Ishii]

>>> Does this test doc building?
>>
>> Good question. Thomas?
> 
> Yes.  You can't see the resulting HTML or anything... but it does fail
> if you break the documentation build.

Great! Thanks for the explanation.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Re: Commitfest 2018-07 is underway

[Thomas Munro]

On Mon, Jul 2, 2018 at 11:24 AM, Andrew Dunstan
 wrote:
> On Sun, Jul 1, 2018 at 7:02 PM, Tatsuo Ishii  wrote:
>>> Patch authors are reminded of the very useful patch tester too at
>>> . You should check regularly if your
>>> patch is still applying, building, and testing nicely. There are
>>> currently quite a significant number of patches listed which don't
>>> apply or don't build/test cleanly in travis or appveyor.
>>
>> Does this test doc building?
>
> Good question. Thomas?

Yes.  You can't see the resulting HTML or anything... but it does fail
if you break the documentation build.

-- 
Thomas Munro
http://www.enterprisedb.com

Re: Commitfest 2018-07 is underway

[Andrew Dunstan]

On Sun, Jul 1, 2018 at 7:02 PM, Tatsuo Ishii  wrote:
>> Patch authors are reminded of the very useful patch tester too at
>> . You should check regularly if your
>> patch is still applying, building, and testing nicely. There are
>> currently quite a significant number of patches listed which don't
>> apply or don't build/test cleanly in travis or appveyor.
>
> Does this test doc building?
>


Good question. Thomas?

cheers

andrew

-- 
Andrew Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: Commitfest 2018-07 is underway

[Tatsuo Ishii]

> Patch authors are reminded of the very useful patch tester too at
> . You should check regularly if your
> patch is still applying, building, and testing nicely. There are
> currently quite a significant number of patches listed which don't
> apply or don't build/test cleanly in travis or appveyor.

Does this test doc building?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Re: commitfest 2018-07

[Stephen Frost]

Greetings,

* Andrew Dunstan (andrew.duns...@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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Andrew Dunstan]

On 06/07/2018 09:01 AM, Ashutosh Bapat wrote:

On Thu, Jun 7, 2018 at 8:38 AM, Jonathan S. Katz  wrote:

On Jun 6, 2018, at 8:14 PM, Michael Paquier  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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Andres Freund]

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

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Ashutosh Bapat]

On Thu, Jun 7, 2018 at 8:38 AM, Jonathan S. Katz  wrote:
>
>> On Jun 6, 2018, at 8:14 PM, Michael Paquier  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

Re: commitfest 2018-07

[Jonathan S. Katz]

> On Jun 6, 2018, at 8:14 PM, Michael Paquier  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

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Andrew Dunstan]

On 06/06/2018 11:57 AM, Jonathan S. Katz wrote:


On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz 
> wrote:



On Jun 5, 2018, at 10:14 AM, Tom Lane > wrote:


Michael Paquier mailto:mich...@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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: commitfest 2018-07

[Jonathan S. Katz]

> On Jun 5, 2018, at 1:34 PM, Jonathan S. Katz  
> wrote:
> 
> 
>> On Jun 5, 2018, at 10:14 AM, Tom Lane  wrote:
>> 
>> Michael Paquier  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 

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Magnus Hagander]

On Wed, Jun 6, 2018 at 12:29 AM, Michael Paquier 
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".

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Jonathan S. Katz]

> On Jun 5, 2018, at 10:14 AM, Tom Lane  wrote:
> 
> Michael Paquier  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

Re: commitfest 2018-07

[David Rowley]

On 6 June 2018 at 03:17, Andres Freund  wrote:
> On 2018-06-06 03:14:58 +1200, David Rowley wrote:
>> On 6 June 2018 at 02:20, Tom Lane  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

Re: commitfest 2018-07

[Peter Eisentraut]

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

Re: commitfest 2018-07

[Andres Freund]

On 2018-06-06 03:14:58 +1200, David Rowley wrote:
> On 6 June 2018 at 02:20, Tom Lane  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

Re: commitfest 2018-07

[David Rowley]

On 6 June 2018 at 02:20, Tom Lane  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

Re: commitfest 2018-07

[Stephen Frost]

Greetings,

* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Joe Conway  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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Andrew Dunstan]

On 06/05/2018 10:43 AM, Andres Freund wrote:

On 2018-06-05 10:20:55 -0400, Tom Lane wrote:

Andres Freund  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 Dunstanhttps://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: commitfest 2018-07

[Tom Lane]

Joe Conway  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

Re: commitfest 2018-07

[Joe Conway]

On 06/05/2018 10:43 AM, Andres Freund wrote:
> On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
>> Andres Freund  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

Re: commitfest 2018-07

[Andres Freund]

On 2018-06-05 10:20:55 -0400, Tom Lane wrote:
> Andres Freund  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

Re: commitfest 2018-07

[Tom Lane]

Andres Freund  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

Re: commitfest 2018-07

[Tom Lane]

Michael Paquier  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

Re: commitfest 2018-07

[Andres Freund]

On 2018-06-04 23:32:18 -0400, Tom Lane wrote:
> Michael Paquier  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

Re: commitfest 2018-07

[Stephen Frost]

Greetings,

* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> On Tue, Jun 5, 2018 at 9:02 AM, Tom Lane  wrote:
> > Michael Paquier  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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Ashutosh Bapat]

On Tue, Jun 5, 2018 at 9:02 AM, Tom Lane  wrote:
> Michael Paquier  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

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature

Re: commitfest 2018-07

[Tom Lane]

Michael Paquier  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

Re: commitfest 2018-07

[Tom Lane]

David Rowley  writes:
> On 5 June 2018 at 11:16, Peter Eisentraut
>  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

Re: commitfest 2018-07

[David Rowley]

On 5 June 2018 at 11:16, Peter Eisentraut
 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

Re: commitfest 2018-07

[Michael Paquier]

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


signature.asc
Description: PGP signature