RFD: A modest proposal #2: unsupported

["Charles Wilson" <cygwin at cwilson dot fastmail dot fm>]

I'd like to add a 'release'-like directory tree to the cygwin mirror
system, called 'unsupported'.  Unlike the ill-fated 'contrib' tree from
years back, I believe this would be a positive and unconfusing addition.

To support this, cgf would simply need to call upset as 'upset release
unsupported' instead of just 'upset release' -- and OK the creation of
the tree.  So technically, this is easy.  Socially ...

WHAT'S IT FOR
-----------------------
setup.exe-compatible packages of software for which the porter is
unwilling to take on the role of maintainer.  There would be a few main
differences between these packages and "supported" (e.g. release/)
packages.

  1) install into /usr/local/* or /opt/<package>/* [see RFD #1] -- NEVER
  EVER touch ANYTHING under /usr/*.  This includes cygwin-specific doco:
  it should go under /usr/local/doc/ /usr/local/doc/Cygwin/ if desired,
  and NOT /usr/doc/.  Ditto --sysconfdir=/usr/local/etc and NOT /etc. 
  But cygwin-specific doco is not required for these ports.

  2) may not be as "finished" as regular packages.  E.g. openssh without
  the fancy ssh-install-user scripts and such.

  3) A strict "USE AT YOUR OWN RISK" policy.  The only appropriate
  discussion of these packages on the main cygwin list is "I think
  package unsupported/foo is cool, and I'd like to adopt it and support
  it, and become its official maintainer."  In other words, an adoption
  notice -- to be followed by a formal ITP on cygwin-apps and review for
  "real" inclusion under release/.  However, as long as a package is
  "unsupported" it is UNSUPPORTED.  Don't ask about it on the main
  mailing list.  setup.hints should be category = UNSUPPORTED and nothing
  else.  These packages should ONLY show up in the unsupported category
  in setup's chooser and NOT also under Libraries or Net or whatnot. 
  UNSUPPORTED.  PERIOD.
  NO questions on the cygwin mailing list.  NO questions or personal mail
  to the contributor.  UNSUPPORTED.  End of story.

  4) Anyone who contributes a package to 'unsupported/' retains no
  "ownership" -- they can't veto someone else's adoption of the package. 
  They can expect an acknowledgement in the cygwin-specific README as
  "the original porter" but that's it.  Also, the original porter can't
  veto someone else contributing a newer version to replace theirs.  If
  they want control, they should become a real maintainer and ITP the
  package for inclusion under release/.

WHY?
------------------
I think setup is a great tool.  I actually use it to manage local
unofficial packages.  BUT, when compiling "foo" for personal use, I don't
always go thru the effort of creating a cygwin-specific READMEs and
whatnot.  Further, I don't want to take over the official maintainance
burden for:
   netpbm  electricfence  epstool  glib  help2man  jpeg2ps   lacheck 
   mifXfig  plotutils  pngcheck  pstoedit  pstoepsi  pstotext  tgif 
   ungifsicle  mingw-cross-binutils  mingw-cross-gcc   
among others.  Yet, it's a shame to force folks to solve all of the basic
porting problems I've already solved (how many times have we heard "How
do I compile glib?" ?), so it'd be nice to make these available to
others.  Now, I'm lucky: I've got a website with virtually unlimited
bandwidth and storage space and I can put all this stuff up for public
consumption, and I have.  But not everybody is that lucky, and even in my
case wider dissemination is good (quick: what's my website?) -- and
publicity for "ADOPT ME" packages would also help increase the number of
*supported* packages available for cygwin.  Plus, this would encourage
contributors -- even casual contributors like the folks at the german
mirror (quick: what's the URL for the german mirror?) -- to make their
binaries setup-installable with setup.hints and everything.

Note: I do NOT propose that all new packages should go thru unsupported/
before being ITP'ed and added to the official release/ tree.  A complete
port + a willing maintainer == ITP immediately.  No need for extra
hassle.

HOW? (management)
---------------------
I don't think we need a new mailing list -- especially if the setup.exe
discussion moves off of cygwin-apps.  I can see a much shorter
(non-existent?) review cycle for "U-ITP"s:  "Hey, here's foo-1.2-2.  I'd
like it to go into unsupported/.  Okay?"  One review by one person ==
upload it.  Assuming cgf is willing, able, and free, "we" (e.g. he) might
even set up an unsupported/incoming/ directory, or a webpage submission
system -- although the latter would be more valuable for real release/
packages.

Comments?

--Chuck


-- 
  Charles Wilson
  cwilson at fastmail dot fm