2012/9/22 Satoshi Nagayasu <sn...@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 <sn...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
