commitfest 2018-07

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]https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Meeting 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