Re: pkg/22947: cleanups for the messages printed by the script generated by pkg.install.mk

["Greg A. Woods" <woods%weird.com@localhost>]

[ On Monday, March 21, 2005 at 18:09:14 (-0500), Amitai Schlair wrote: ]
> Subject: Re: pkg/22947
>
> I don't want to discourage you from contributing to NetBSD, but I do 
> want to discourage you from contributing in this particular fashion. 
> You can do better, and I for one look forward to it.

While I appreciate your concern and your suggestions, they are
ridiculous and completely out of context in this specific situation.

Have you actually read the PR in question!?!?!  It would seem not.

This PR contains a very VERY SIMPLE LITTLE patch that provides more
accurate and detailed messages about some very important package
installation steps.

The original patch submitted was against a revision of the file that was
only a couple of days old at the time.

It was submitted September 25, 2003.  Two thousand and THREE.  18 months!

No wonder the original patch failed to apply cleanly when someone
finally got around to looking at it.

That's OK -- I can accept a delay and a request for a more current
patch.  However the patch I just re-submitted is against the _current_
2004q4 branch and is only four revisions from the current HEAD revision
today.

Any experienced CVS user should easily be able to apply either of my
patches to the exact revision it was made against and then merge forward
all the more recent changes, fixing conflicts as necessary.  Alternately
it is quite easy for _anyone_ knowledgeable of the current state of the
code in question to manually apply such simple changes.  In fact these
procedures are both simple, basic, fundamental, required, change
management skills that are not even remotely specific to CVS.

If a NetBSD developer is too inexperienced to manage such very simple
merge conflicts, or unwilling to do that work for whatever reason, then
I must seriously question their position and/or their decision to accept
responsibility for handling PRs.  Some people are very good develpers,
but far fewer people are good at managing software changes, and it's
important to know who's who on any project.


On the other hand if these changes are not ever wanted then it's a very
simple matter to just say so.  Doing that would avoid this very stupid
and idiotic dancing around with irrelevant and/or bogus complaints, PR
gyrations, etc.  I would have been far less offended by a simple "no
thanks" than I am now by the way this has been mishandled.


The worst part of this is that these changes are just a tiny fraction of
the similar enhancements I could offer from my own source tree.  I
submitted these simple and obvious changes as a test to see if it would
be worth my time to individually extract, describe, and send-pr my other
changes.

However it seems the delays and agony of making such offers, as evident
from this experience, suggest that it's just not worth my time to submit
any other changes and that instead it's much easier for me just to keep
managing my own local changes for my own benefit.  I don't have any
trouble merging forward my own changes -- I've already done it many
times over for several years already, and I'm quite happy to have my
very own enhanced version of pkgsrc.  My own local change management
works well enough for me and while I would certainly like to share the
benefits of my changes with others, and of course reduce my own merging
effort, I simply cannot afford to do so if the cost of sharing is so
much higher than the cost of simply merging my own changes forward as I
need them.

My experiment has apparently had an unsatisfactory outcome overall, but
at least it is a result that can guide my own future efforts.

-- 
                                                Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack 
<woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>          Secrets of the Weird 
<woods%weird.com@localhost>