Justin Clift <justin@postgresql.org> writes:
> With 7.1/7.2, Tom mentioned us being delayed because specific features
> we were waiting for became dependant on one person.
> Would it be feasible to investigate approaches for having the Win32 and
> PITR work be shared amongst a few very-interested volunteers, so that
> people can cover for each other's downtime?
It would certainly be good to bring as much manpower to bear on those
problems as we can. But that doesn't really address my concern: if the
schedule is defined as "we go beta when feature X is done", then no one
who's working on stuff other than feature X knows how to plan their
time. The only fair way to run the project is "we go beta at time T";
that way everyone knows what they need to shoot for and can plan
accordingly.
I don't mind setting the planned time T on the basis of what we think
it will take for certain popular feature X's to be done. But if the
guys working on X aren't done at T, it's not fair to everyone else to
hold our breaths waiting for them to be done at T-plus-who-knows-what.
I don't really have any sympathy for the argument that "it won't be a
compelling release if we don't have feature X". If the release isn't
compelling for someone, they don't have to upgrade; they can wait for
the next release. The folks who *are* eager for what's been gotten done
will be glad of having a release now rather than N months from now.
And do I need to point out that "it runs on Windoze" is not of
earth-shattering importance for everyone?
regards, tom lane
