From: MON KEY <monkey@sandpframing.com>
To: emacs-devel@gnu.org
Cc: joakim@verona.se
Subject: Re: Integrating package.el
Date: Sun, 10 Jan 2010 17:06:33 -0500 [thread overview]
Message-ID: <d2afcfda1001101406w366fc251j5a3ca7d1a3d3c57e@mail.gmail.com> (raw)
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: `<LASTNAME>.<NUMBER>.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", <MY-FULL-NAME>, hereinafter <--BLOCK-4
| "DEVELOPER", hereby agrees as follows:
`----
The bottom of page two has two signature blocks:
,----
| Thank you for the contribution!
|
| Signed:
|
| __<MY_SIGNATURE>__
| <--BLOCK-5
| __<DATE_SIGNED>___
|
|
| Accepted by the Free Software Foundation
|
| __<EXECUTIVE_DIR_SIG__
| <--BLOCK-6
| __<DATE_SIGNED>_______
|
`----
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\
next reply other threads:[~2010-01-10 22:06 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-10 22:06 MON KEY [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-12-26 2:55 Autoload from a web page? Lennart Borgman
2009-12-27 3:13 ` Richard Stallman
2009-12-27 3:24 ` Lennart Borgman
2009-12-28 18:48 ` Richard Stallman
2009-12-28 18:55 ` Lennart Borgman
2009-12-29 2:45 ` joakim
2009-12-29 15:11 ` Ted Zlatanov
2009-12-29 18:46 ` Richard Stallman
2009-12-29 21:14 ` unsupported packages area in the Emacs repo (was: Autoload from a web page?) Ted Zlatanov
2009-12-29 21:36 ` unsupported packages area in the Emacs repo Tom Tromey
2009-12-30 16:15 ` Ted Zlatanov
2010-01-01 19:18 ` Tom Tromey
2010-01-03 5:38 ` Integrating package.el (was Re: unsupported packages area in the Emacs repo) Phil Hagelberg
2010-01-04 17:55 ` Integrating package.el Ted Zlatanov
2010-01-04 19:51 ` Tom Tromey
2010-01-05 5:02 ` Phil Hagelberg
2010-01-05 5:37 ` Lennart Borgman
2010-01-05 15:06 ` Stefan Monnier
2010-01-05 16:03 ` Ted Zlatanov
2010-01-05 16:47 ` Stefan Monnier
2010-01-05 20:18 ` Ted Zlatanov
2010-01-05 23:50 ` Jonas Bernoulli
2010-01-06 20:45 ` Richard Stallman
2010-01-06 21:49 ` Ted Zlatanov
2010-01-09 5:40 ` Phil Hagelberg
2010-01-09 14:32 ` Richard Stallman
2010-01-09 17:47 ` Phil Hagelberg
2010-01-10 10:41 ` Richard Stallman
2010-01-10 11:33 ` Stephen J. Turnbull
2010-01-10 14:04 ` Chong Yidong
2010-01-10 16:00 ` joakim
2010-01-10 20:43 ` Phil Hagelberg
2010-01-10 20:07 ` Phil Hagelberg
2010-01-10 21:24 ` Stefan Monnier
2010-01-10 23:02 ` Phil Hagelberg
2010-01-11 3:28 ` Stefan Monnier
2010-01-14 3:12 ` Phil Hagelberg
2010-01-19 11:40 ` Phil Hagelberg
2010-01-19 17:17 ` Dan Nicolaescu
2010-02-22 19:22 ` Ted Zlatanov
2010-02-22 20:36 ` joakim
2010-02-23 22:25 ` Stefan Monnier
2010-02-24 21:20 ` Ted Zlatanov
2010-02-25 20:05 ` Stefan Monnier
2010-03-01 14:59 ` Ted Zlatanov
2010-03-01 16:32 ` Jonas Bernoulli
2010-03-01 17:14 ` Ted Zlatanov
2010-03-01 20:59 ` Jonas Bernoulli
2010-03-02 17:39 ` Richard Stallman
2010-03-02 18:46 ` Ted Zlatanov
2010-03-01 21:19 ` Stefan Monnier
2010-03-02 13:34 ` Ted Zlatanov
2010-03-01 21:37 ` Jonas Bernoulli
2010-03-01 22:18 ` Štěpán Němec
2010-03-01 22:30 ` Štěpán Němec
2010-03-01 23:00 ` Jonas Bernoulli
2010-03-02 13:38 ` Ted Zlatanov
2010-03-03 20:13 ` Tom Tromey
2010-03-04 5:42 ` Phil Hagelberg
2010-03-02 19:03 ` Davis Herring
2010-02-25 22:56 ` David De La Harpe Golden
2010-03-04 5:39 ` Phil Hagelberg
2010-03-04 7:29 ` Stephen J. Turnbull
2010-03-04 18:27 ` Stefan Monnier
2010-03-05 4:41 ` Stephen J. Turnbull
2010-03-04 13:54 ` Ted Zlatanov
2010-03-04 18:29 ` Stefan Monnier
2010-03-04 18:33 ` Tom Tromey
2010-03-07 22:58 ` Phil Hagelberg
2010-03-04 20:39 ` Ted Zlatanov
2010-03-07 23:16 ` Phil Hagelberg
2010-03-08 3:17 ` Tom Tromey
2010-03-08 14:55 ` Ted Zlatanov
2010-03-08 17:01 ` Stefan Monnier
2010-03-08 17:53 ` Ted Zlatanov
2010-03-04 18:30 ` Tom Tromey
2010-03-05 0:22 ` Stefan Monnier
2010-03-01 14:43 ` Ted Zlatanov
2010-03-01 16:26 ` Jonas Bernoulli
2010-03-01 17:28 ` Ted Zlatanov
2010-03-01 18:06 ` Tom Tromey
2010-03-01 21:22 ` Jonas Bernoulli
2010-03-03 20:15 ` Tom Tromey
2010-03-03 20:22 ` Ted Zlatanov
2010-03-03 22:21 ` Tom Tromey
2010-03-02 13:31 ` Ted Zlatanov
2010-03-01 21:09 ` Jonas Bernoulli
2010-01-11 3:09 ` Stephen J. Turnbull
2010-01-12 20:06 ` Ted Zlatanov
2010-01-12 21:37 ` Phil Hagelberg
2010-01-05 15:50 ` Ted Zlatanov
2010-01-05 16:42 ` Stefan Monnier
2010-01-05 18:03 ` Phil Hagelberg
2010-01-05 18:40 ` Ted Zlatanov
2010-01-05 19:14 ` Tom Tromey
2010-01-05 20:04 ` Ted Zlatanov
2010-01-05 23:19 ` Tom Tromey
2010-01-06 15:42 ` Ted Zlatanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d2afcfda1001101406w366fc251j5a3ca7d1a3d3c57e@mail.gmail.com \
--to=monkey@sandpframing.com \
--cc=emacs-devel@gnu.org \
--cc=joakim@verona.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.