cvs commit: ports/java/eclipseme Makefile distinfo pkg-plist

[Alexey Dokuchaev]

On Wed, Mar 19, 2008 at 01:24:40PM +0100, Pav Lucistnik wrote:
> Alexey Dokuchaev p??e v st 19. 03. 2008 v 11:23 +0000:
> 
> > I wonder what's wrong with coherent and sane policies?  I don't expect
> > it would be hard to come to agreement about muting/not muting
> > mkdir's/installation statements.  These things are not of the type people
> > usually feel strongly about.
> 
> I like the high level of creative freedom the maintainer is entitled to.
> Rigid policies on unimportant details of style will kill the fun.

I've seen this reasoning before; IMHO it is more of speculation though.
Policies can be, and are, different.  Including ones that have impact on
one's "creative freedom", and ones that don't.  When people create or
improve on a port, no one tells them how to do what they intend, when
they do it correctly and sanely.  I have also observed what people who
know our bpm & friends well enough are less prone to errors and
non-optimal decisions and code.  It is also true that it takes time to
know about every possible implication of different way of doing things;
it takes time to get wisdom about compiler flags, right file permissions,
difference between port vs. package installation, := vs. = (yes, I'm
about BR_DEPS here), various upgrade-path scenarios, etc.  Even trivial
things, like starting COMMENT with "Foo is ..." are not obvious up
front.  There are many ways of doing things in a nice, clean manner.  Yet
there're more ways to come up with something cumbersome and obscure.
When I say we need policy, I think of carefully selected and documented
things to avoid and be careful with, not about strict recipes for doing
this thing or that.  I'm not talking about patching files vs. inplace
editing, or about amount of whitespace in OPTIONS items.  I'm talking
about that there's certainly a grow-space in our culture and taste for
something that can be treated as a state of art, e.g. our ports.  To me,
producing something *good* is more fun than just producing something.

This is important because vast number of maintainers are not committers,
ergo they might not be of high level of qualification a committer is
required to have.  Yet I see a tendency among us to overvalue the
tinderbox as a criteria whether new port or proposed change can go into
the tree or not.  This is obviously not enough.  By going with "it
compiles, installs/deinstalls, let's ship it" attitude we're not setting
a higher standard for people who are considering making their first port
or adopting existing one.  And we probably should.

Dixi.

./danfe