[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

copyright papers (was: complete: APR-ized svn_parse_date replacement)

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-08-28 22:16:55 CEST

Or we can just forget all this crap, all play nice, and get back to
producing great code.

Leave this problem to CollabNet.

-g

On Tue, Aug 28, 2001 at 01:08:07PM -0400, C. Scott Ananian wrote:
> On 28 Aug 2001 kfogel@collab.net wrote:
>
> > An idea for making this work better than it does with the FSF (where
> > long delays in getting copyright papers from contributors are the
> > norm): send people self-addressed stamped envelopes and printouts of
> > the papers to sign. This makes it much more likely that they will be
> > returned in a finite amount of time. :-)
>
> and accept *faxes*! The FSF is playing it safe, even at the expense of
> contributors, because it fully expects to have to fight the court case one
> day. It's hard to imagine a violation of SVN's license, liberal as it is,
> so the greater flexibility of faxed signatures should definitely be in.
>
> and provide an easy way to see the *status* of the paperwork. many FSF
> contributors sent in their paperwork and then waited around
> for a confirmation notice or some such before finishing their patches.
> No notice is ever sent by the FSF, and so people assume that the paperwork
> got lost, or something, and eventually give up on their getting patches
> committed.
>
> Finally: with an adequate version control system, it ought to be possible
> to commit patches *immediately* pending paperwork. The commit can always
> be reverted if the paperwork doesn't come through. You should be careful
> to specially flag/lock further modification of lines where a patch is
> still 'pending' to avoid messy reverts in the abort case, but such a lock
> could provide a powerful incentive to all involved to deal with the
> paperwork expeditiously. You don't want to leave potential contributors
> hanging in paperwork limbo while their enthusiasm drains.
>
> And the implementation of this system with SVN may be an excellent test
> case for the flexibility of the access control mechanism.
> --s
>
> [needless to say, the comments above come from experience, and not the
> good kind.]
>
> United Nations hack explosives Leitrim Bush operative RUCKUS cracking
> interception Hager Peking algorithm Justice security supercomputer
> ( http://lesser-magoo.lcs.mit.edu/~cananian )
> --
> "These students are going to have to find out what law and order is
> all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
> minutes before his troops shot 13 unarmed Kent State students, killing 4.
> --
> [http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
> #!/usr/bin/perl -w
> # 526-byte qrpff, Keith Winstein and Marc Horowitz <sipb-iap-dvd@mit.edu>
> # MPEG 2 PS VOB file on stdin -> descrambled output on stdout
> # arguments: title key bytes in least to most-significant order
> $_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
> $_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
> unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
> >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
> ,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
> ^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
> [$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:37 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.