Re: a few thoughts on the schedule

Поиск
Список
Период
Сортировка
От Joshua D. Drake
Тема Re: a few thoughts on the schedule
Дата
Msg-id 555B80B7.8020008@commandprompt.com
обсуждение исходный текст
Ответ на Re: a few thoughts on the schedule  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On 05/19/2015 10:44 AM, Andres Freund wrote:

>> I don't know what the solution is but I know I like the idea of a tree
>> freeze except for bug fixes for at least 3 weeks but I would be jumping for
>> joy if we froze the tree except for bug fixes for 6 or 12 weeks.
>
> We've done that for pretty much every release so far?
>

That isn't really my experience at least from perception and I will be 
honest and I haven't followed the releases for 9.4 and 9.3 that much but 
it used to be:

Branch Tree
Accept patches for new tree and closed tree (bug fixes)

What I am suggesting is that we don't accept ANY patches that are not 
directly related to the closed tree that is being prepped for release.

I am not suggesting a shutdown of collaboration or discussion. I am 
trying (and perhaps failing) to find a way to steer everyone in a single 
direction for this release:

Our focus is the quality of 9.5, nothing else.

>
>> I don't care about 9.6 at this point.
>
> But you don't develop things for it, so you're in a very different
> position. It takes a *lot* of time to come up with a serious proposal

I would argue I develop a lot more than you consider. I have to deal 
with the end result that -hackers create on a much wider scale (as do 
most other consultants) than most do.

> for a new feature, and then lots more time to come up with a reasonable
> patch. To get a serious feature into 9.6 you pretty much have to already
> have started by now.

Then extend the development time. Instead of 12-15 months, let's make it 
18-21 or 21-24 months or again, move to a staggered model (like Ubuntu).

>
>> We move so fast anyway, most people I know haven't even migrated to
>> 9.4.x and even more are happily plugging away on 9.2.
>
> I don't think that's really related to moving fast. It's just that
> existing systems don't necessarily need to move - after all they could
> put the system into production at their respective version.  That's
> different to when you consider adopting/extending postgres for a new use
> case/product.  And there people quit regularly lament a couple problems
> in postgres. Say if we, and there's been serious talk about that,
> addressed vacuuming being so painful, that'd certainly increase adoption
> in the mid term.

This is true but doesn't negate my argument, it enforces it. Most people 
aren't going to be anywhere near disappointed if we slow down and focus 
on quality versus innovativeness.

Note: I am not saying we don't try to release quality software, of 
course we do.

JD

-- 
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Problems with question marks in operators (JDBC, ECPG, ...)
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: a few thoughts on the schedule