Re: [CORE] postpone next week's release
От | Stephen Frost |
---|---|
Тема | Re: [CORE] postpone next week's release |
Дата | |
Msg-id | 20150529195344.GM26667@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: [CORE] postpone next week's release (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
* Magnus Hagander (magnus@hagander.net) wrote: > On Fri, May 29, 2015 at 9:46 PM, Stephen Frost <sfrost@snowman.net> wrote: > > > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > > Magnus Hagander <magnus@hagander.net> writes: > > > > On Fri, May 29, 2015 at 9:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > > >> I think there's no way that we wait more than one additional week to > > push > > > >> the fsync fix. So the problem is not with scheduling the update > > releases, > > > >> it's with whether we can also fit in a 9.5 beta release before PGCon. > > > > > > > I think 9.5 beta has to stand back. The question is what we do with the > > > > potentially two minor releases. Then we can slot in the beta whenever. > > > > > > > If we do the minor as currently planned, can we do another one the week > > > > after to deal with the multixact issues? (scheduling wise we're going > > to > > > > have to do one the week after *regardless*, the question is if we can > > make > > > > two different ones, or if we need to fold them into one) > > > > > > I suppose we could, but it doubles the amount of release gruntwork > > > involved, and it doesn't exactly make us look good to our users either. > > > > Agreed. Makes it look like we can't manage to figure out our bugs and > > put fixes for them together in sensible releases.. > > > > The flipside of that is that we have a bug fix that's preventing peoples > databases from starting, and we're the intentionally delaying the shipment > of it. Though i guess a mitigating fact there is that it is very easy to > manually recover from that. But it's painful if your db server restarts > awhen you're not around... And we have *another* fix for a *data corruption* bug which is coming in the following *week*. Yes, I think delaying a week to get both in is better than putting out a fix for one bug when we *know* there's a data corruption bug sitting in that code, and we're putting out a fix for it the following week. If we were talking about a month-long delay, that'd be one thing, but that isn't the impression I've got about what we're talking about. Thanks! Stephen
В списке pgsql-hackers по дате отправления: