beta to release
in [PgSql]
|
From: Tom Lane on 7 May 2010 11:31 Robert Haas <robertmhaas(a)gmail.com> writes: > I am fuzzier on what happens now. I understand that it depends on > what bug reports we get as a result of beta testing, but what I don't > quite know is what the expectations are for individual developers, how > we're tracking what issues still need to be resolved, or what the > process is for deciding when it's time to release. Any clarification > from the old hands who have been through this few times before would > be much appreciated. It's pretty fuzzy. Usually we don't even think about making a release decision until a couple of months have elapsed, and at that point we have a somewhat better handle on what sorts of problems beta has been turning up. I think trying to set release criteria for 9.0 right now would be premature. I would say the expectation for individual developers is "test, and read code". It's certainly not time to be starting new feature development yet. As for tracking, historically Bruce has maintained a list of open items, but I think we ought to move that over to a wiki page. The existing PostgreSQL_9.0_Open_Items page would serve fine. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 7 May 2010 16:38 On Fri, May 7, 2010 at 11:31 AM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > I would say the expectation for individual developers is "test, and > read code". It's certainly not time to be starting new feature > development yet. I am humbly of the opinion that the expectation you have enclosed in quotation marks is far too general to allow me to contribute anything useful. If you, or whoever is driving this release process (if indeed it's being driven and not just meandering rudderless), would care to outline something more specific that you feel it would be useful to have me test, look at, or attempt to address, then I will devote some of my time to doing that. But I won't volunteer to go reread the entire code base or test things at random in the hopes of finding a bug. I don't believe that most other developers are doing that, either. What I think they are doing is lying low and developing their patches without the benefit of feedback from the list so as to avoid getting yelled at for writing them during beta, or else doing non-PostgreSQL work until beta is over. For small patches, that probably doesn't matter very much: those can be developed just as well later on as they can now. For large patches, it's evil incarnate: people who don't start working on those patches (or don't get any useful feedback on them) for another 3 months will be at least 3 months later in finishing them (maybe more, depending on their summer vacation schedule and just when their boss will let them put time into it), and that means they'll be done right at the end of next release cycle. From a project management perspective, I think we will be FAR better off if we take the time to respond to design proposals early and often. I agree we don't have time to do detailed code review now, but telling people not to write any code or ask any questions at this stage of the process is not going to result in them spending more time on beta; it's going to result in them spending less time on PostgreSQL. In further support of the above, let's consider the three largest patches that were outstanding at the end of the 8.4 release cycle. I believe these to be (1) Hot Standby, (2) Streaming Replication, and (3) SE-PostgreSQL. How much work got done on those patches between the end of the last CommitFest for 8.4 and the beginning of the first CommitFest for 8.5? If you go back and look at the archives, I believe you will find that the answer is "virtually none". SR and SEPG were submitted *virtually unchanged* from the versions that existed at the end of 8.4 and were both summarily bounced out of the 2009-07 CommitFest for exactly that reason. Hot Standby wasn't even submitted to that CommitFest. There could be many reasons for this and correlation does not imply causality, but wouldn't it have been nice at least SOME of the development that happened between July and November (by which time the bulk of the development was done) had instead happened between February and July? I sure think so. I think we'd be a whole lot happier about this release right now if we'd committed HS and SR in September rather than November and January, and while we can speculate all day about whether that would have happened under any circumstances, our process rendered it a virtual impossibility. > As for tracking, historically Bruce has maintained a list of open > items, but I think we ought to move that over to a wiki page. > The existing PostgreSQL_9.0_Open_Items page would serve fine. +1. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 7 May 2010 17:35 Robert Haas <robertmhaas(a)gmail.com> writes: > [ argues, in effect, for starting 9.1 development right now ] I can't stop you from spending your time as you please. My development time for at least the next month or two is going to be spent on code-reading the HS/SR code and fixing bugs as they come in. I don't foresee having any time to work on my own 9.1 projects, let alone review anyone else's. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 7 May 2010 18:26 On Fri, May 7, 2010 at 5:35 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> [ argues, in effect, for starting 9.1 development right now ] > > I can't stop you from spending your time as you please. My development > time for at least the next month or two is going to be spent on > code-reading the HS/SR code and fixing bugs as they come in. I don't > foresee having any time to work on my own 9.1 projects, let alone > review anyone else's. I'm really making an effort to be a "good" community member. There are a couple of reasons I don't think that I can spend ALL of my PG time over the next few months on release prep: 1. I'm not really sure what I would spend that much time doing. 2. My employer has things they want done for 9.1. That having been said, I am perfectly happy to devote a substantial amount of time to helping with 9.0, but I think it needs a little more organization to make it productive. I am not the first person to make this observation and I'm sure I won't be the last. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Marc G. Fournier" on 8 May 2010 00:04 On Fri, 7 May 2010, Robert Haas wrote: > On Fri, May 7, 2010 at 5:35 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> [ argues, in effect, for starting 9.1 development right now ] >> >> I can't stop you from spending your time as you please. �My development >> time for at least the next month or two is going to be spent on >> code-reading the HS/SR code and fixing bugs as they come in. �I don't >> foresee having any time to work on my own 9.1 projects, let alone >> review anyone else's. > > I'm really making an effort to be a "good" community member. There > are a couple of reasons I don't think that I can spend ALL of my PG > time over the next few months on release prep: > > 1. I'm not really sure what I would spend that much time doing. > 2. My employer has things they want done for 9.1. IMHO, there is nothing wrong with you (or any other developer) spending time working on v9.1 features if said person feels that they have satisfied themselves that v9.0 is ready for release (ie. I think the best test anyone can run, espeecially those whose employer uses PostgreSQL, is to run tests using their own applications / environment ... regressions are great and all, but real world always finds something new) ... Tom's employer requires *as clean* a release as possible, so for him, his priority is to go through and test everything and anything he can think of .... and that includes doing review of the code that got added ... but, that is what *his* employer is paying his time to do ... Again, IMHO, the critical thing throughout beta is that if a bug is reported, or an oddiity, that any 'development for 9.1' gets drop'd fast and teh bug report is jumped on / fixed ASAP ... To me, beta is ... we're ready for release, we're not throwing in any new code .. it is a time for more 'end users' to start testing real world applications (even if they won't run 9.0, but will wait for 9.0.1) to start evaluating, which inevitable will generate bug reports to be fixed .... ---- Marc G. Fournier Hub.Org Hosting Solutions S.A. scrappy(a)hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy(a)hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] beta to release Next: [HACKERS] Two C-interface issues on -Testers |