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

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

The following reply was made to PR pkg/22947; it has been noted by GNATS.

From: "Greg A. Woods" <woods%weird.com@localhost>
To: Amitai Schlair <schmonz%schmonz.com@localhost>
Cc: pkg-manager%netbsd.org@localhost, Johnny Lam <jlam%netbsd.org@localhost>,
        pkgsrc-bugs%netbsd.org@localhost,
        NetBSD GNATS submissions and followups 
<gnats-bugs%netbsd.org@localhost>,
        gnats-admin%netbsd.org@localhost
Subject: Re: pkg/22947: cleanups for the messages printed by the script 
generated by pkg.install.mk
Date: Mon, 21 Mar 2005 19:07:22 -0500 (EST)

 [ 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>