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