On Sat, Aug 05, 2006 at 03:55:17PM -0700, Ron Mayer wrote:
> andrew@dunslane.net wrote:
> >Ron Mayer wrote:
> >>>We have not had that many cases where lack of
> >>>communication was a problem.
> >>One could say too much communication was the problem this time.
> >>
> >>I get the impression people implied they'd do something on a TODO
> >>and didn't. Arguably the project had been better off if noone
> >>had claimed the TODO, so if another company/team/whatever needed
> >>the feature badly, they could have worked on it themselves rather
> >>than waiting in hope of the feature.
> >
> >This is just perverse. Surely you are not seriously suggesting that we
> >should all develop in secret and then spring miracles fully grown on the
> >community?
>
> Of course not. What I'm suggesting is two things.
>
> (1) That misleading information is worse than no information; and
> that speculative information next to TODOs can do as much harm
> discouraging others as it the good it does for communication. Perhaps
> a name/assignment/claim on a todo might be nice if someone wanted a
> private conversation with someone who knows about a feature; but
> even there wouldn't a public discussion on the lists likely be better?
Yes, a name by itself is pretty useless. Having an idea of the status of
that TODO item is a completely different story. If one month after
claiming an item the status is "the old patch I thought would work is
junk, this will need to be written from scratch, help wanted!" then
clearly anyone who's interested in that item and had the ability to help
would know that now was the time to step up.
Going one step further, if that item was in a system that allowed people
to get emails any time status changed then *everyone* who was interested
in that feature would immediately know that help was needed. I fail to
see how that's a bad thing.
> (2) That much corporate development on BSD projects is indeed
> developed in secret. Although may want to be contributed later
> either because the company no longer decides it's a trade-secret
> or gets tired of maintaining their own fork. Sure, such patches
> might need even more discussion and revision than if they were
> designed with core - but I think it's a reality that such work
> exists.
I think this goes way beyond patches... there's got to be dozens of
home-grown scripts to handle PITR (for one example). Granted, most of
those will be rather specific to an individual environment, but if
people would at least share them then someone setting up PITR for the
first time wouldn't have to start from scratch.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461