Re: pg_reorg in core? - Mailing list pgsql-hackers

(2012/09/22 11:01), sakamoto wrote:
> (2012/09/22 10:02), Christopher Browne wrote:
>>
>> If the present project is having a tough time doing enhancements, I 
>> should think it mighty questionable to try to draw it into core, that 
>> presses it towards a group of already very busy developers.
>>
>> On the other hand, if the present development efforts can be made more 
>> public, by having them take place in a more public repository, that at 
>> least has potential to let others in the community see and 
>> participate.  There are no guarantees, but privacy is liable to hurt.
>>
>> I wouldn't expect any sudden huge influx of developers, but a steady 
>> visible stream of development effort would be mighty useful to a 
>> "merge into core" argument.
>>
>> A *lot* of projects are a lot like this.  On the Slony project, we 
>> have tried hard to maintain this sort of visibility.  Steve Singer, 
>> Jan Wieck and I do our individual efforts on git repos visible at 
>> GitHub to ensure ongoing efforts aren't invisible inside a corporate 
>> repo.  It hasn't led to any massive of extra developers, but I am 
>> always grateful to see Peter Eisentraut's bug reports.
>>
> 
> Agreed.  What reorg project needs first is transparency, including
> issue traking, bugs,  listup todo items, clearfied release schedules,
> quarity assurance and so force.
> Only after all that done, the discussion to put them to core can be 
> started.
> 
> Until now, reorg is developed and maintained behind corporate repository.
> But now that its activity goes slow, what I should do as a maintainer is to
> try development process more public and finds someone to corporate with:)

I think it's time to consider some *umbrella project* for maintaining
several small projects outside the core.

As you pointed out, the problem here is that it's difficult to keep
enough eyeballs and development resource on tiny projects outside
the core.

For examples, NTT OSSC has created lots of tools, but they're facing
some difficulties to keep them being maintained because of their
development resources. There're diffrent code repositories, different
web sites, diffirent issus tracking system and different dev mailing
lists, for different small projects. My xlogdump as well.

Actually, that's the reason why it's difficult to keep enough eyeballs
on small third-party projects. And also the reason why some developers
want to push their tools into the core, isn't it? :)

To solve this problem, I would like to have some umbrella project.
It would be called "pg dba utils", or something like this.
This umbrella project may contain several third-party tools (pg_reorg,
pg_rman, pg_filedump, xlogdump, etc, etc...) as its sub-modules.

And also it may have single web site, code repository, issue tracking
system and developer mailing list in order to share its development
resource for testing, maintening and releasing. I think it would help
third-party projects keep enough eyeballs even outside the core.

Of course, if a third-party project has faster pace on its development
and enough eyeballs to maintain, it's ok to be an independent project.
However when a tool have already got matured with less eyeballs,
it needs to be merged into this umbrella project.

Any comments?

> 
> Sakamoto
> 
> 


-- 
Satoshi Nagayasu <snaga@uptime.jp>
Uptime Technologies, LLC. http://www.uptime.jp