Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От Rod Taylor
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id 1082600472.80320.224.camel@jester
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Список pgsql-hackers
On Wed, 2004-04-21 at 21:29, Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Rod Taylor wrote:
> 
> > > I think most of the current contrib projects are more missing the
> > > advantage version independence would have for the ease of "sitting" in
> > > contrib and having the whole project management around them just done.
> > > Yes, doing your own gborg project costs time. You have to maintain
> > > pages, do your own release cycles with announcement, BETA phase,
> > > tarballs, packaging and all the nine yards. Being in contrib avoids all
> > > that in a very convenient way.
> >
> > I think Gnome (and KDE) have the right idea. Several independent small
> > projects that once or twice a year get together and have a big release.
> >
> > We could co-ordinate a set of projects (phppgadmin, pgadmin, slony,
> > jdbc, odbc, etc. etc.) to make a release on the same day as PostgreSQL.
> >
> > We then setup several 'meta' packages. For example, PostgreSQL-lite
> > might be just the core. PostgreSQL-Advanced might include jdbc, pgadmin,
> > slony, tsearch, postgis and everything in postgresql-lite.
> 
> I'd like to agree with this concept, but it falls way short of addressing
> the problem ... and the problem isn't even pulling things out of contrib
> ... there are alot of good projects out there that aren't on gforge or in
> the core distribution that ppl just aren't finding ...
> 
> a 'Meta Package' doesn't help much, since unless you put *everything* into
> it that you can possibly find, there is always going to be something
> missing that someone would find useful ... and if you put everything into
> it, most ppl would only use a small percentage of what is there ...

We have the current issue of people not knowing that projects like
pgadmin exist or where to find the jdbc drivers.

These basic components (and others a large segment uses that are well
maintained) should go through a release cycle with the -core including
the platform test/report phase and be prominently listed in the
downloads area and documentation areas -- just as we do for PostgreSQL
proper.

Goto http://postgresql.org, now track down the jdbc drivers or how to
use them. To a significant portion of our users this is more important
than CREATE FUNCTION is and in 7.5 jdbc documentation will be much more
difficult to find, but no less important than it used to be.


Another issue is organizing the hundreds of addon programs that do
everything from parsing logs and various specialized interfaces to
schema documentation and special function languages (plsh or plr).

With an upcoming windows release coming where the masses will be
watching, I think the former is more important at the moment.



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: cannot drop active portal
Следующее
От: "Marc G. Fournier"
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions