Thread: beta to release
On Mon, Jan 11, 2010 at 10:45 PM, Bruce Momjian <bruce@momjian.us> wrote: >> > What amazes me is how many people who closely follow our development are >> > mystified by what we do during that pre-beta period. >> >> Hey, I'm still mystified. Maybe you and Tom could do twice-a-week >> status updates on what you're working on and anything you could use >> help with, or something. > > Yea, that would probably help. I know I am not very transparent in this > area. I was fairly satisfied with the way that our path from the end of the last CommitFest to beta unfolded from a process standpoint this time (if not entirely from a time standpoint, but that's my own fault as much as anyone - the rest of my life got in the way of PostgreSQL). We had a list of open items on the wiki (actually several lists which were eventually merged) which we worked through and then released beta1. I felt like that was pretty transparent and I understood what the blockers were When we cleared them, we went onto the next thing. 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. Thanks, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
Robert Haas <robertmhaas@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
On Fri, May 7, 2010 at 11:31 AM, Tom Lane <tgl@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
Robert Haas <robertmhaas@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
On Fri, May 7, 2010 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@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
On Fri, 7 May 2010, Robert Haas wrote: > On Fri, May 7, 2010 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@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@hub.org http://www.hub.org Yahoo:yscrappy Skype: hub.org ICQ:7615664 MSN:scrappy@hub.org
On Fri, 2010-05-07 at 18:26 -0400, Robert Haas wrote: > On Fri, May 7, 2010 at 5:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas@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. I've often faced the issue you describe. I think its difficult for everybody to help at this stage. In many ways it is a serialization and it's good that Tom holds the gate tighter than normal at this point. The main thing I've tried to do was map out plans for my time so you know which features will be worked on, in which order. Most of that planning needs to happen quietly because its not really possible to say "I intend to work on X" without it becoming a discussion about what X should look like, which is distracting to the release process. Having said that, I've often found that discussing things off-list with other hackers leads to later grief. I think Bruce wrote a good piece on that once. What 2 or 3 people think is a good way forwards is seldom shared by others, and many ideas fall foul of complete blockers, or simply easier or better ideas. Last year we both worked on the same issues. I'd ask that if you intend to work on anything you know myself or other hackers are working on, please ask so we can avoid duplicating any efforts. -- Simon Riggs www.2ndQuadrant.com
On Sat, May 8, 2010 at 12:04 AM, Marc G. Fournier <scrappy@hub.org> wrote: > 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 ... That all sounds reasonable to me, and is about how I feel about it myself. Thinking about Tom's comments a little more, I think there are probably a few things that I could/should go back over in a little more detail, and I'm going to make time to do that, but I'm also going to work on 9.1 features as time permits. I will also take the time to respond to design proposals for proposed 9.1 projects, especially from anyone who similarly takes the time to respond to mine. I probably will not look at actual patches very much just yet. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Sat, May 8, 2010 at 6:34 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > I've often faced the issue you describe. I think its difficult for > everybody to help at this stage. In many ways it is a serialization and > it's good that Tom holds the gate tighter than normal at this point. > > The main thing I've tried to do was map out plans for my time so you > know which features will be worked on, in which order. Most of that > planning needs to happen quietly because its not really possible to say > "I intend to work on X" without it becoming a discussion about what X > should look like, which is distracting to the release process. > > Having said that, I've often found that discussing things off-list with > other hackers leads to later grief. I think Bruce wrote a good piece on > that once. What 2 or 3 people think is a good way forwards is seldom > shared by others, and many ideas fall foul of complete blockers, or > simply easier or better ideas. Yeah, I think we need to start having those discussions on-list. Trying to develop things quietly so it doesn't become a distraction can result in "wasting a lot of time going down a dead end". Tom and Alvaro saved me a ton of time on the temporary-relations-get-different-filenames patch I submitted earlier this week, and I really appreciate that. My guess is that it didn't take them much time to respond to my emails, either. Even if neither of them actually read for several months, I have a lot more confidence that the basic approach is sound than I would otherwise, and I was able to develop it much more quickly than would have been possible in a complete vacuum. Of course, as you say, we don't want to go nuts and get into long arguments about things, but I think that high-level design discussions should be viewed as in order. This is important (1) to avoid duplication, (2) to enable people to get done the work their employers are willing to fund at the time their employers are willing to fund it, and (3) to create a reasonable hope of some of the big patches landing earlier in the cycle. > Last year we both worked on the same issues. I'd ask that if you intend > to work on anything you know myself or other hackers are working on, > please ask so we can avoid duplicating any efforts. I will try to do that. Currently, the things that I know I will be spending some effort on for 9.1 are (1) global temporary and/or unlogged tables, (2) inner join removal, and (3) mentoring the GSoC projects on matviews, json, and merge. Everything else is pretty amorphous at this point, but I typically send out design emails fairly early on in the process. Please also share your plans for 9.1. Come to think of it, I think we should start a page on the wiki for developers to list major projects they plan to work on for 9.1, maybe also with a space to indicate whether the project is possible or definite. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
On Sat, 2010-05-08 at 08:12 -0400, Robert Haas wrote: > (3) mentoring the GSoC > projects on matviews, json, and merge. Everything else is pretty > amorphous at this point, That's good you volunteered. I'm sorry to say that I'm really surprised to hear anyone thinks MERGE or matviews are suitable student projects. I regard both as long and hard projects and feel we shouldn't be encouraging people to do things like that as their first project. (Not aimed at you, or any individual.) > Please also share your plans for 9.1. Will do. Synch rep. is one, there are others, but not as much thought gone into this as usual yet. -- Simon Riggs www.2ndQuadrant.com