Re: CVS commit: pkgsrc/mk/tools

[Alistair Crooks <agc%pkgsrc.org@localhost>]

On Mon, Feb 02, 2015 at 09:49:26AM +0900, OBATA Akio wrote:
> On Mon, 02 Feb 2015 06:23:13 +0900, Joerg Sonnenberger <joerg%britannica.bec.de@localhost> wrote:
> 
> >On Sun, Feb 01, 2015 at 02:50:26PM +0900, Ryo ONODERA wrote:
> >>Adding tool to infrastructure is so heavy to our project?
> >
> >I asked about this commit specifically, because unlink(8) is utterly
> >useless and only exist for silly historical reasons. So unless something
> >has a good reason for requiring it, it shouldn't exist.
> 
> Yes, sure!
> Let's try to drop it from NetBSD base in the first place!
> You can do it!

I'm a bit confused now - unlink(1) is required by SUSv2, but that's not
really what this email thread is about.

In general, if we're making changes to the infrastructure, approval in
advance is the best way of (1) getting buy-in from other pkgsrc
developers, (2) making sure that the proposed change has no side
effects, and (3) making sure that the change is necessary, and
couldn't be done better in a different way.  It's different to some
projects, which do write-behind approval.  Our method of approval in
advance is the desired way of working, as pkgsrc is now rather large,
and works on so many different platforms, that there's almost always
other ways to make the changes - whether these other ways are better
or worse is what should be discussed.  However, if a change is
beneficial, I don't see any problem with sensible, considered
discussion on the topic.

Now I really value your contributions to pkgsrc, you've been able to
help me on a number of things I should have known more about; that's
very useful for me.  It seems you've taken these questions about
unlink(1) to heart, and reverted other changes you've made.  I think
that's going too far, but it's done now, and so let's take it that
from now on, we'll discuss infrastructure changes in advance on
tech-pkg.

In general, though, I don't understand the reaction to valid
questions, and people looking for insight as to why changes were made. 
If a change is good, then we'll all be able to defend the change with
good, valid reasons.  If not, should the change have been made in the
first place?

Just to be clear - this mail is not criticism, it explains why we have
the processes and procedures we do, and as lightweight as they are -
we do no formal code review, we do not do architecture reviews either;
neither do we do post-mortems (we used to, and we should resurrect
them, they're incredibly valuable).  I'm sure we all get frustrated at
time by some others reactions to our proposed changes - what I have
learned on a personal level is that there's usually valid reasons
behind criticism, and if I take those reasons on board, I'll be better
at what I love doing.

I hope this mail helps - if you have any questions about it, please
contact me directly.

With thanks,
Alistair