apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: cvs commit: apr-util/src/dbm apr_dbm.c
Date Sat, 09 Dec 2000 01:39:45 GMT
On Fri, Dec 08, 2000 at 04:20:17PM -0800, rbb@covalent.net wrote:
> 
> > > One last observation, sdbm.h does _not_ belong in apr-util/include/ and neither
> > > does the apu_private stuff.  Suggest we move those on out of there, but where?
> > > apr-util/include/private?  We don't need arch/ anything, since headers shouldn't
> > > change the same way in apr-util (it's already cross-platform, right :-?)
> > 
> > We could move apu_private to a subdirectory, but why? A handy subdir was
> > available in APR, so that was an easy choice to hide the include file. I say
> > that we leave the file and simply tell people "you're an adult. listen to us
> > when we say don't include it."
> 
> That didn't work with apr_private.h, which should it work for
> apu_private.h?

Because we'll continue to slap people around? :-)

> > > Note we don't appear to have an apr-util.h just yet for compiled-in features
> > > of the lib... we need one, no?
> > 
> > if/when we have separable features.
> 
> We absolutely MUST have separable features, and we must be able to build
> just those features that are required.  This code has no one thing that
> ties it all together, so there is no reason to think that any project
> other than Apache will want it all.  Inflicting it on everybody is not a
> valid way to do this.

Ryan -- a tip for interacting with other people in a shared development
environment: avoid the words "should", "must", and definitely "absolutely
must". Not everybody agrees with you, and these kinds of phrases are poor
leaders into a process where you are trying to reach a consensus. They can
alienate people from what should be a community process, by making it sound
as if your thoughts and decisions are the only ones that matter. I would
suggest that you be a bit more careful, and phrase things as "your thoughts"
or "your suggestions." Propose things, rather than issue demands. Your job
is to reach consenus and to move the project towards a shared vision, not to
say where it "absolutely MUST" go. Give us your thoughts and let us reach
the same decision with you. The people sharing this "work" environment will
feel much better about their participation and will enjoy it much more.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message