Re: pg_reorg in core?
От | Michael Paquier |
---|---|
Тема | Re: pg_reorg in core? |
Дата | |
Msg-id | CAB7nPqSHjsVeUGJuHxF43iF6RY8_7QiKKCRqmNm8rbcvQfW1ig@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_reorg in core? (Satoshi Nagayasu <snaga@uptime.jp>) |
Ответы |
Re: pg_reorg in core?
|
Список | pgsql-hackers |
On Mon, Sep 24, 2012 at 1:14 AM, Satoshi Nagayasu <snaga@uptime.jp> wrote:
Michael Paquier2012/09/23 12:37, Greg Sabino Mullane wrote:Exactly --- I do not care the SCM system though. :)
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: RIPEMD160
>
>
>>> I think it's time to consider some *umbrella project* for maintaining
>>> several small projects outside the core.
>>
>> Well, that was pgfoundry, and it didn't work out.
>
> I'm not sure that is quite analogous to what was being proposed.
> I read it as more of "let's package a bunch of these small utilities
> together into a single project", such that installing one installs them
> all (e.g. aptitude install pg_tools), and they all have a single bug
> tracker, etc. That tracker could be github, of course.
The bug tracker is going to be a mess if it has to manage 100 subprojects, knowing that each of them is strictly independant.
Maintainers are also different people for each tool.
Maintainers are also different people for each tool.
For example, xlogdump had not been maintained for 5 years when
> I'm not convinced of the merit of that plan, but that's an alternative
> interpretation that doesn't involve our beloved pgfoundry. :)
I picked it up last year. And the latest pg_filedump that supports 9.2
has not been released yet. pg_reorg as well.
If those tools are in a single project, it would be easier to keep
attention on it. Then, developers can easily build *all of them*
at once, fix them, and post any patch on the single mailing list.
Actually, it would save developers from waisting their time.
>From my viewpoint, it's not just a SCM or distributing issue.
It's about how to survive for such small projects around the core
even if these could not come in the core.
The package manager system could be easily pgxn. It is already designed for that.
For development what you are looking for here is something that github could perfectly manage.
As proposed by Masahiko, a single organization grouping all the tools (one repository per tool) would be enough. Please note that github can also host documentation. Bug tracker would be tool-dedicated in this case.
--
For development what you are looking for here is something that github could perfectly manage.
As proposed by Masahiko, a single organization grouping all the tools (one repository per tool) would be enough. Please note that github can also host documentation. Bug tracker would be tool-dedicated in this case.
--
http://michael.otacoo.com
В списке pgsql-hackers по дате отправления: