[Pan-users] Re: ANN: Pan 0.134 "Wait for Me"

[Duncan]

Steve Davies posted on Mon, 21 Feb 2011 10:38:41 +0000 as excerpted:

> I think part of my confusion is that Petr has left Charles name on the
> change logs, so it suggested Charles was pitching in again.

Well, regardless of current status, he gets credit for the patches/commits 
that he did, several of which didn't make it into 0.133, so only now into 
0.134.

FWIW, one of the things that Eric S Raymond pointed out (regardless of 
what one thinks about his other positions/politics) in his "The Cathedral 
and the Bazaar" series of essays is that because so much of the FLOSS 
movement is volunteer commitments, a "Gifting Society", like most such 
"gifting societies", credit and respect for those gifts is the "exchange 
value" ("money") upon which the society is based.  To recognize or fail to 
recognize the contributions, code especially but not just code, that one 
has made, is to pay them or rob them of their "payment" -- the only 
payment many receive.  Thus, giving credit where credit is due is a *HUGE* 
*DEAL*; it's *NOT* a matter one can be careless with.

Thus, it's not just "being nice" to recognize that Charles did those 
patches and apply credit in the change logs, etc, accordingly, in a very 
real way it's robbing him of payment to FAIL to recognize it.  
Particularly now that he's not so intimately a part of pan's future, to 
fail to recognize the work he did on those last patches is in some way to 
fail to recognize all he did to make pan what it is today!  Obviously, 
then, it's something we want to make sure gets done. =:^)

Of course, one of the strengths of git and the practices the Linux kernel 
in particular has established around using it as the common distributed 
development repository tool that it is, is that it/they make tracking such 
credits even easier than it tended to be with centralized repositories.  
Git's distributed nature and the way git (and to a large extent other 
distributed versioniing systems) merges changes, makes it rather easier to 
keep development/review/testing credit with a patch as it moves thru the 
process, as compared to "loose patches", which tended to lose some of that 
data as they moved up the chain and evolved.  But it's not /just/ that, as 
to a major degree we're seeing continued development of the customs and 
norms of the society in real time, as the tools develop and evolve and we 
begin to recognize not just the value of properly crediting not just the 
code and coder (which was what Raymond was primarily talking about), but 
the related contributions and contributors, bug reporters, patch reviewers 
and testers, etc, the whole way thru from initial bug report to final 
deployment of the patch in a released version.  Where Raymond recognized 
that robbing the coder of his due wasn't something accepted by the 
community of his time, now, that has expanded to include the bug 
reporters, bug confirmers, of course the patch providers, reviewers, 
testers, etc, the whole way thru.  This is a relatively new development in 
the community, in fact, still developing so not universally practiced yet, 
and a very good thing as the complexity of our ecosystem and along with it 
the opportunity for contribution and recognition grows. =:^)  The Linux 
kernel (and with it, git) is a flagship in this regard, as not only does 
git (when used correctly) automatically credit patches to their originator 
and track that as it moves up the chain, but looking at the long-form 
changelogs, it's now quite common to see a half dozen or more "original 
patch by" (if submitted in patch rather than native git form), "reported 
by", "tested by", "reviewed by", and "acked by" entries, tracing the 
various people who've had a role in the patch and the contributions 
they've made to its development.

Of course, the trigger for the practice was the SCO suit, as that 
emphasized in stark relief the benefits of legal level tracking and 
checkoff thru the patch development process, but once the tools and 
practice were there for that, people realized just how easy and beneficial 
to all involved it was, to expand that to track bug reporters, testers, 
etc, and so it came to pass, with the practice continuing to evolve and 
expand even now.  As was predicted, that which didn't kill us only made us 
stronger, altho I'm not sure anyone predicted the detail of the 
"stronger".  So the whole SCO thing /did/ have its benefits.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman