Re: JDBC split and move ...

Поиск
Список
Период
Сортировка
От Nick Fankhauser
Тема Re: JDBC split and move ...
Дата
Msg-id NEBBLAAHGLEEPCGOBHDGCEDCEFAA.nickf@ontko.com
обсуждение исходный текст
Ответ на Re: JDBC split and move ...  (Kovács Péter <peter.kovacs@sysdata.siemens.hu>)
Список pgsql-jdbc
Reviewing the list this morning, there seem to be some emerging common
threads. All of them support some limited organizational changes, and none
support moving to GBorg as the development infrastructure:


1) The ability for users to pick & choose among desired components is good.

- This is more of a packaging issue. It would require some effort on the
part of the "make" gurus, but it seems reasonable to support several
standard component suites & even to make the process fully customizable.
This packaging work would be required with the GBorg plan as well.


2) An independent release cycle is mostly good and might encourage faster
development.

- This is an organizational issue that any component development group could
handle themselves if the community as a whole supported it. It's a bit more
work, but regardless of the development infrastructure, this work would need
to be done. Speaking as a user, the release cycle is currently very
important to me given the relative "youth" of JDBC, but it is likely to be
of little value a year from now when JDBC has matured a bit.


3) Integration of documentation between all components is good, and the
documentation should be in good order before the release of any component.

-Again, more of an organizational issue. Since the documentation tends to be
as modular as the components, it should be reasonable to create a "make"
process that pulls clean documentation out from each most current component
release.


4) Nobody seems excited about switching to GBorg as the development
infrastructure.

-Most people however are cautiously supportive of the goals that Marc had in
mind when proposing a change.


As a user, I'd like to see a nice, clean separation between components,
documentation that corresponds to the components in the same modular
fashion, and independent release cycles. As a user, I also don't care that
much about the development infrastructure, so my comments about GBorg are
more of an observation of others than a valid opinion. This is why the idea
seemed reasonable to me at the outset, but as a non-developer, I can only
judge the goals with validity. My vote really shouldn't count when it comes
to the methods.

-Nick


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

Предыдущее
От: Kovács Péter
Дата:
Сообщение: Re: JDBC split and move ...
Следующее
От: Glenn Holmer
Дата:
Сообщение: BigDecimal