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

2012/9/22 Satoshi Nagayasu <snaga@uptime.jp>:
> (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?
>

good idea

Pavel

>>
>> Sakamoto
>>
>>
>
>
> --
> Satoshi Nagayasu <snaga@uptime.jp>
> Uptime Technologies, LLC. http://www.uptime.jp
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers