Re: RFC: Remove contrib entirely

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: RFC: Remove contrib entirely
Дата
Msg-id 20150529143026.GV26667@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: RFC: Remove contrib entirely  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: RFC: Remove contrib entirely  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
* Joshua D. Drake (jd@commandprompt.com) wrote:
> On 05/28/2015 11:01 PM, Fabien COELHO wrote:
> >Also, removing a feature is a regression, and someone is always bound to
> >complain...
>
> We aren't removing any features. These are all items that are NOT
> installed or functional by default.

Uh, we've already had reports by Debian users about problems upgrading
when they forgot to install the contrib package for the version they're
moving to, so I'm not sure it's quite that simple.  Or, at least, it
won't be for the packagers, who I do believe this would be creating a
fair bit of work for.

That work will be much less if we simply split what's in contrib now
into extension and contrib directories, as it's still all one source
repo to the packagers.  If we punt things out (unless they're being
formally deprecated/removed) to another repo somewhere, then the
packagers are going to have to deal with new source repos and related
complexity.  I'm not saying that's a horrible thing and it might make
sense in some cases, but generally it's a lot easier to go from one
soruce package to a bunch of binary ones than from lots of tiny source
packages to lots of tiny packages.

The versioning aspect of this does come into play though, as having
everything with one relatively slow versioning cycle (on the order of
months) is actually keeping the load on the packagers down.  Lots of
little releases, all at different times, from lots of different source
packages, would increase the workload.

I'm not sure where I ultimately come down on the question about in-repo
vs. out-of-repo.  My gut feeling is that if the community is willing to
continue maintaining contrib modules, then that's ultimately a good
thing and many of them are relatively low-maintenance anyway.  Having a
high barrier to entry for new modules looks a bit odd, given the
definition of contrib, but would be more understandable with a proper
'extensions' directory.  Of course, we'd have to collectivly agree that
we feel comfortable with a lower barrier for contrib that what is being
done now, if the distinction is going to have any meaning.
Thanks!
    Stephen

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Document that directly callable functions may use fn_extra