From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: Integrating package.el Date: Sun, 10 Jan 2010 17:06:33 -0500 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1263161213 14736 80.91.229.12 (10 Jan 2010 22:06:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2010 22:06:53 +0000 (UTC) Cc: joakim@verona.se To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 10 23:06:45 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NU5vo-0000rp-VG for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2010 23:06:45 +0100 Original-Received: from localhost ([127.0.0.1]:58190 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NU5vp-00068R-Cw for ged-emacs-devel@m.gmane.org; Sun, 10 Jan 2010 17:06:45 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NU5vj-00065v-SV for emacs-devel@gnu.org; Sun, 10 Jan 2010 17:06:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NU5vf-00063a-9W for emacs-devel@gnu.org; Sun, 10 Jan 2010 17:06:39 -0500 Original-Received: from [199.232.76.173] (port=55711 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NU5vf-00063X-2x for emacs-devel@gnu.org; Sun, 10 Jan 2010 17:06:35 -0500 Original-Received: from mail-yx0-f191.google.com ([209.85.210.191]:41142) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NU5ve-0006mf-KH for emacs-devel@gnu.org; Sun, 10 Jan 2010 17:06:34 -0500 Original-Received: by yxe29 with SMTP id 29so1595133yxe.14 for ; Sun, 10 Jan 2010 14:06:33 -0800 (PST) Original-Received: by 10.150.252.14 with SMTP id z14mr9081410ybh.228.1263161193739; Sun, 10 Jan 2010 14:06:33 -0800 (PST) X-Google-Sender-Auth: 1fa3e2371e07f85c X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:119798 Archived-At: Joakim Verona writes, > A well made package system might also conceivably make it easier to > acquire papers right? > > For instance, it might be more prestigious to have ones package in the > FSF repos. > > Also, digital signatures might be legally binding at some point. (I think > they are in Swedenalready, we have a national system for it anyway) I don't get why the licensing/assignment need necessarily be an issue. For example, I was issued a `.pdf' file for my assignment. The file name has format: `..EMACS.pdf' Following the letterhead on pg 1 are the lines: ,---- | SURNAME-UID <--BLOCK-1 | RT NNNNNN <--BLOCK-2 | ASSIGNMENT - GNU EMACS <--BLOCK-3 `---- Following that, the opening paragraph reads: ,---- | For $1 and other good { boilerplate elided } | hereinafter "FSF", , hereinafter <--BLOCK-4 | "DEVELOPER", hereby agrees as follows: `---- The bottom of page two has two signature blocks: ,---- | Thank you for the contribution! | | Signed: | | ____ | <--BLOCK-5 | _____ | | | Accepted by the Free Software Foundation | | _________ | `---- The scan also has an inked date stamp which appears in the manner of a Bates number. :NOTE The above template is recent, obv. older such docs may differ. While I'm quite sure the FSF has facilities to OCR/digitize this type of content in bulk it is surely outside their purview to extend such facility (and time required to do so) to the Emacs project or any other GNU project FTM. That said, Joakim's has developed dragbox.el which using GOCR should already be capable of the following: o Extracting digital images key portions of the document Blocks 1-6, o Extracting OCR'd conversion of Blocks 1-4, The `Bates Date stamp' (BLOCK-7) would prob. need to be manually identified and extracted as these most likely appear skewed, incompletely inked, and arbitrarily placed for the majority of assignment papers. Regardless, Joakim's dragbox.el already provides adequate facilities for accommodating a manual crops of BLOCK-7 as well. With such extractions, the digital image portions of Blocks 1-7, and the OCR'd conversion of Blocks 1-4, a `sanctioned repository maintainer' would key-sign/encrypt each block (or the entire bundle) of extracted content for: o The package author(s); o The Emacs-devels; This encrypted bundle could be and distributed with the package or retained separately. In either case, the bundle would receive a Unique ID which would be included in the header commentary of each file distributed with the package. Assuming all the elements of this regime are technically possible what are the benefits it would provide that other approaches wouldn't: o It promotes user awareness of, and re-assures the user benefits of, using a suite of congruent and consistently licensed packages. o It promotes and encourages package authors to acquire assignment _papers_ in addition to incorporating boilerplate license terms in package/library headers. o Once an authors assignment papers have been processed per above it provides a mechanism whereby package authors can readily integrate new libraries with a sanctioned repository without additional overhead. IOW assuming no change of employment, surname, etc. an author simply notifies the repository maintainer that a new package exists and that said new package should fall under the existing Unique ID umbrella. o Changes in assignment status e.g. withdrawal of assignment, change of employment, contact address, surname, etc. can be more readily propagates through the system. The repository maintainer is notified and alters the scope of the Unique ID umbrella accordingly; this alteration is made known to users and devels upon next synchronization. o It can be integrated with existing assignment papers dating back to ???. o It reinforces the existing practice that assignment papers need be signed on physical media (e.g. _paper_). o It allows upstream Emacs-devels to verify assignment should they elect to incorporate a package or portions of code therein with less burdensome overhead. o It may remove some of the initial immediate overhead Emacs-devels face with regards incorporation of new features in the absence of existing assignment papers. IOW going forward new packages/authors will presumably already have acquired papers and these papers will already have been converted processed. o It may ease management of existing/future assignment papers w/re upstream Emacs-devels, i.e. by breaking up the assignment document into discrete elements Blocks 1-7 could be databased in any number of ways including xrefs across multiple authors/packages, verification of date and timestamp incongruities etc. Assuming the above are points are indeed beneficial what are the detractors: o It places a burden on package authors that may not have been there before; namely, acquisition of assignment papers. o For new authors there is a time-delay between the initial creation of package/source and any sequencing of assignment papers, digitization, propagation etc. required before a package can become part of a repository. IOW An author can publish code with a GPL header to github, bit-bucket, launchpad, etc. in seconds. o It places a significant burden on `sanctioned repository maintainers' to accomplish the initial digital conversion and subsequent propagation to appropriate parties. o It may place a burden on FSF if it has to process more assignment papers. o It doesn't (currently) address the issue of older assignment papers that are in a different format, are lost, out of date, etc. o It doesn't accommodate purely digital code signing models. o It doesn't accommodate alternative licenses (philosophical negative). o It places a burden on users to grok the benefits/rationale of what in other situations would be considered an esoteric approach, i.e. One can _fax_ a contract that is binding but authors/contributors of a premier piece of software must make available hand signed media. o None of this exists yet. Personally, I believe there is a net gain for package authors when there is a cost of entry to a project. AFAIK Right now there isn't a cost of entry because there isn't really an entry point and what little there is places the burden on CYD, Stefan, et al to manage the assignment but that this generally takes a backseat to other more pressing concerns... So, some neat stuff lingers because it is a chore to manage the paperwork (real or metaphorical). Likewise, I believe there is a net gain for community package repository maintainers when there is some cost of entry to accept/process a package. There are many examples of projects which maintain `unofficial repositories' of third party tools. Those that provide a degree of oversight seem to be more trustworthy and propagate more reliable code than those that to quote Dennis Hopper in the movie Blue Velvet, "F**k anything that moves". When package authors understand that some legwork is required of them in order to play they may be more apt to contribute more robust and tested code (as contributions aren't worth the trouble otherwise) where this is the case repository maintainers will benefit from less need to troubleshoot, and less need for frequent integration of code changes. Most likely there will continue to be more than one model of Emacs community developed and distributed packages. These will either compete for attention/resources or each will offer appropriate paths to increased integration with Emacs. In a competitive environment (read forking) environment the repo with the _most_ packages will thrive i.e. "Worse is Better" even if/when it isn't. In a cooperative/integrated/tired community repository environment the repo with the best, cleanest, most open, code will achieve a higher "status" than her fast and loose neighbor. IOW repository maintainers have no incentive to adopt the above assignment clearing regime where a competing repo environment is afforded an equal status by the upstream Emacs-devels. However, where there is some upstream endorsement preference for a particular _regime_ then disparate repo maintainers and package authors can participate with, promote, and adopt this regime (or not) according to their particular philosophy, time restraints, personalities, etc. /s_P\