Andrew Dunstan wrote: > >> I think the only other thing we _could_ do is to re-open normal 8.3 > >> development, so we aren't hampering updates to trivial parts of the > >> code. Many of the patches now in the queue had been developed for months > >> before 8.3 started, so the hope is that we wouldn't have many more new > >> large patches, but several small ones we could deal with while we > >> whittle away at the larger patches during the next few months. > >> > >> The question is whether it is healthy for us to remain in feature freeze > >> for months, and if it is unhealthy, what are our options? > >> > > > > I don't see any reason development has to stop while the tree is in feature > > freeze. If it led to patches being ready for review and getting reviewed and > > committed early in the cycle rather than just before release I think it > > would > > actually be extremely healthy. > > > > > > If we had multiple dev branches it might be more possible. That has its > own costs, of course - having a single dev branch makes management much > easier, and we never have to worry about things like merging. > > Patches seem to be getting larger, more complex, and harder to review. > That is stressing our processes more than somewhat. > > Short cycles would only make matters worse - the frictional cost of each > dev cycle is growing. I think at least we have learned not to repeat > this exercise.
Agreed. Good summary. Let's look at our problems honestly now and find a direction, rather than pushing them off for later. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
