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 по дате отправления: