Hi all,
Following the conclusions of the developer meeting whose minutes are here:
https://wiki.postgresql.org/wiki/PgCon_2017_Developer_Meeting
The commit fest schedule has been decided as the same as 2016-2017,
with four commit fest entries, planned for one month each:
- 2017-09
- 2017-11
- 2018
On Mon, Jan 25, 2010 at 12:01 PM, Greg Smith wrote:
> I think it's completely reasonable to say that someone could organize
> pgsql-rrreviewers (as an initial working area, maybe another list
> eventually) for periodic ReviewFest during periods where those patches won't
> be considered for commit,
Robert Haas wrote:
> Issues that are discussed and resolved in that forum will very
> possibly get brought up again on -hackers and reach a different
> conclusion the second time around. Now if people are OK with
> that, maybe it's OK
I would expect that. Heck, people get that to some degree
Greg Smith wrote:
> Kevin Grittner wrote:
>> Other posts have suggested that "review fests" might be helpful
>> in this period. Again, it sounds to me, from other posts on this
>> thread, as though the primary risk is that people working on the
>> release could see something they couldn't resist
Kevin Grittner wrote:
Other posts have suggested that "review fests" might be helpful in
this period. Again, it sounds to me, from other posts on this
thread, as though the primary risk is that people working on the
release could see something they couldn't resist getting drawn into
-- taking th
> Greg Stark wrote:
>> Tom Lane wrote:
>> What I think we really need for beta, and could reasonably hope to
>> get, is a larger and better-organized beta testing effort. But we
>> are not going to get that if people are thinking about new
>> development and commit fests instead of testing what
Dimitri Fontaine wrote:
> And there's already pgfouine to get the scenarios from the logs and
> tsung to act as a recording proxy:
> http://pgfouine.projects.postgresql.org/tsung.html
> http://tsung.erlang-projects.org/user_manual.html#htoc34
>
> So maybe it would be a good idea to have dtester
"Kevin Grittner" writes:
> Andrew Dunstan wrote:
>
>> As for getting more coverage of Beta, part of my trouble in
>> testing applications on Beta is that there aren't good tools I
>> know of for capture and replay of usage scenarios. Now there would
>> be a good project for someone, and it wou
Kevin Grittner wrote:
Andrew Dunstan wrote:
As for getting more coverage of Beta, part of my trouble in
testing applications on Beta is that there aren't good tools I
know of for capture and replay of usage scenarios. Now there would
be a good project for someone, and it would be unaffec
Andrew Dunstan wrote:
> As for getting more coverage of Beta, part of my trouble in
> testing applications on Beta is that there aren't good tools I
> know of for capture and replay of usage scenarios. Now there would
> be a good project for someone, and it would be unaffected by the
> Beta cycl
Kevin Grittner wrote:
You've as much as said that it's a given that many of the
contributors will continue to work on new patches during this period
to earn a living, while hopefully volunteering to help with getting
the release out the door on their own time. As I understand the
arguments, ha
Kevin Grittner wrote:
> Greg Smith wrote:
>
> > Developing new features is fun and tends to attract sponsorship
> > dollars. Testing a frozen release, finding bugs, and resolving them
> > is boring, and no one sponsors it. Therefore, if you let both
> > things go on at once, I guarantee you almo
Greg Smith wrote:
> Developing new features is fun and tends to attract sponsorship
> dollars. Testing a frozen release, finding bugs, and resolving them
> is boring, and no one sponsors it. Therefore, if you let both
> things go on at once, I guarantee you almost all of the community
> attentio
Andrew Dunstan wrote:
>>> Perhaps it isn't that five months is outrageous, but that it
>>> doesn't really benefit from an unorganized swarm of activity by
>>> all the developers, and we've not worked out a reasonable
>>> framework for who should do what during that time to best benefit
>>> the p
On Sat, Jan 23, 2010 at 7:59 PM, Andrew Dunstan wrote:
> And, BTW, more process and organization can itself consume scarce resources
> as well as annoying some of the people you want to do some of this work.
> There is a sweet spot that we need to aim at.
What, me annoy someone? That never happe
Robert Haas wrote:
On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan wrote:
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framewo
Greg Smith wrote:
> So why not do that? Developing new features is fun and tends to attract
> sponsorship dollars. Testing a frozen release, finding bugs, and
> resolving them is boring, and no one sponsors it. Therefore, if you let
> both things go on at once, I guarantee you almost all of t
On Sat, Jan 23, 2010 at 9:57 PM, Tom Lane wrote:
> What I find takes up a lot of time is post-commit patch review, fixing
> reported bugs, and documentation cleanup. Now we could doubtless find
> other people to do the purely copy-editing aspects of doc cleanup, like
> fixing less-than-stellar En
Andrew Dunstan wrote:
> The real problem is that we take a long time between the end of the
> development phase and the release. That is often not something you can
> just throw bodies at ("Nine women can't make a baby in a month.").
This is the best anti-analogy I have heard in years.
--
B
On Sat, Jan 23, 2010 at 12:07 PM, Andrew Dunstan wrote:
> Robert Haas wrote:
>>> Perhaps it isn't that five months is outrageous,
>>> but that it doesn't really benefit from an unorganized swarm of
>>> activity by all the developers, and we've not worked out a
>>> reasonable framework for who shou
On Sat, Jan 23, 2010 at 4:57 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Goal being to continue being responsive to authors in a way that will
>> not compromise our stability, but if that means *all* qualified talents
>> of the community get assigned to release management team… I stop seein
Tom Lane writes:
> There seems to be some weird notion abroad in this thread that the
> primary time sink during beta is unspecified low-skill "release
> management" tasks. There really isn't all that much of that.
I'd have said high-skill, which the following paragraph I parse as
confirming it:
Andres Freund writes:
> I find "not talented" enough quite a bit too harsh...
Ok sorry about the term choice: RRR who like me are able to review
patches and help their authors but have yet to submit a patch and have
their code part of PostgreSQL, e.g.
I hope this is more clear stated this way.
-
Dimitri Fontaine writes:
> Goal being to continue being responsive to authors in a way that will
> not compromise our stability, but if that means *all* qualified talents
> of the community get assigned to release management team⦠I stop seeing
> the point.
There seems to be some weird notion a
On Saturday 23 January 2010 22:24:41 Dimitri Fontaine wrote:
> I was under the illusion than we had some RRR people not talented enough
> to be full-speed contributors to release management that we could have
> this team run one or two ReviewFest while the "serious" guys were
> working.
I find "not
Tom Lane writes:
> There simply isn't a pool of (qualified) talent that can go off and
> do beta testing and stabilization in parallel with new development.
> It's pretty much the same people who do both tasks; so if we try to do
> that, one of two things is going to happen: beta takes even longe
Tom Lane wrote:
We already heard a lot of complaints that 8.4 should have gotten more
testing than it did. Proposing to continue development in parallel
with beta is a good way to ensure that that will get worse not better.
Right. If we really want to improve mat
Greg Smith writes:
> ... if you let
> both things go on at once, I guarantee you almost all of the community
> attention will be diverted toward new development during any period
> where both are happening at the same time.
Yes. This is the big problem that would have to be solved before we
c
Kevin Grittner wrote:
Does it really take the concerted efforts of the whole community five months to
take things from the
deadline for patch commits (end of last CF) to release?
The idea is that it takes five months of complete lockdown to give the
code enough testing time to hopefully reach
Robert Haas wrote:
Perhaps it isn't that five months is outrageous,
but that it doesn't really benefit from an unorganized swarm of
activity by all the developers, and we've not worked out a
reasonable framework for who should do what during that time to best
benefit the project while giving al
On Sat, Jan 23, 2010 at 10:47 AM, Kevin Grittner
wrote:
>> What I'd really like is to stop arguing about the number of
>> CommitFests per cycle and the exact charter of each CommitFest and
>> start talking about how we can create an environment where patch
>> authors can get their work committed r
Robert Haas wrote:
> That means I'd like releases to be reasonably frequent - like
> annually - and I'd like the time for which nobody can get anything
> committed to be relatively short.
Yeah, the current approach seems to be to develop a schedule around
a one-year cycle, with an implicit ass
2010/1/23 Dimitri Fontaine :
> Robert Haas writes:
>>> I agree with trying to cut down the submission-to-commit delay, but
>>
>> It seems to me that the CommitFest process is pretty darn effective at
>> reducing the submission-to-commit delay, except when you miss the last
>> one for the release -
Robert Haas writes:
>> I agree with trying to cut down the submission-to-commit delay, but
>
> It seems to me that the CommitFest process is pretty darn effective at
> reducing the submission-to-commit delay, except when you miss the last
> one for the release - then it sucks hard.
Too bad we can
On Fri, Jan 22, 2010 at 7:50 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
>>> Any ideas?
>
>> The lower bound on the release cycle is about 12 months right now
>> because we intend to support old versions for 5 years, and 5 or 6
>> branch
Tom Lane wrote:
Another problem is that it's very debatable whether users (as opposed
to developers) want a fast release cycle. Some of that reluctance to
update might dissipate if we had a better upgrade-in-place story, but
by no means all of it. People don't want to have to retest their
app
Peter Eisentraut writes:
> On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
>> Any ideas?
> The lower bound on the release cycle is about 12 months right now
> because we intend to support old versions for 5 years, and 5 or 6
> branches at once is about the most anyone can handle. That form
On fre, 2010-01-22 at 18:05 -0500, Robert Haas wrote:
> and start talking about
> how we can create an environment where patch authors can get their
> work committed reasonably quickly (assuming it's good, of course) and
> released within some reasonable time frame after that (like, say,
> within a
On Fri, Jan 22, 2010 at 5:15 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> I think feature freeze should be the beginning of the last CommitFest,
>> not the end.
>
> So you still want 3 CF per cycle rather than 4?
> http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php
>
> 3 C
Robert Haas writes:
> I think feature freeze should be the beginning of the last CommitFest,
> not the end.
So you still want 3 CF per cycle rather than 4?
http://archives.postgresql.org/pgsql-hackers/2009-12/msg02355.php
3 CF and a FixFest… -1 from me, if there's an open vote to be made here.
40 matches
Mail list logo
