Chuck, this all sounds pretty complicated. One thing for sure: before anything like this would be tolerable we need SETUP.EXE enabled to *remove* a mirror. Right now I don't think that's possible. If I have a bad experience from a "contributor" I don't need to look at her stuff again! Once bitten, etc.
BTW, do you need to fix your "Reply-to:" on these things? My mailer wanted to send this just to you. Charles Wilson wrote: > Some time ago, I brought up the following issue: > > I have a number cygwin ports of various useful tools (see bottom), > that are packaged in a setup-compatible way. (Yes, I even use method > 2 for local compiles...call me a masochist). I would be perfectly > willing to make them available to a wider community -- but I do NOT > want to maintain them. They work for me; the only bug reports I care > about are my own. > > So, they are not going to be ITP'ed any time soon. OTOH, I would also > be willing (eager) for someone else to grab my finished port and just > "take over" -- they could ITP it and the whole deal. > > So, I previously had mentioned the possibility of a separate > "unmaintained" tree, on the cygwin mirrors, distinct from "release". > > Bad idea -- even if we do get semi-automated uploads to sourceware. > If the packages are distributed via the cygwin mirrors, then we WILL > get questions about them on the main lists. This is bad. > > So, here's an alternate proposal, given setup's existing capability > for federated, non-mirror download sites: > > ------------------------------- > > Packages (or "private" versions of official packages) from User URLS > (e.g. sites that are not official cygwin mirrors) should be presented > in a different color, or bold, or with a shaded background, or > something. Somehow, they need to be visually distinct (textually for > the visual impaired?) from "official" packages -- in fact, if I put a > version of gcc on my site, then someone clicking thru the available > versions should see the official version (without special > highlighting), my version (with special highlighting), etc. > > Heck, we may even want the actual URL to be displayed *right there* in > the chooser, for non-mirror sites: > > I use BOB's site for new game ports > I use BILL's site for extra perl module packages > > But I definitely DON'T want bob's perl module packages, so it's not > enough to know "perl_cpan_module-X.XX-X" is from a non-mirror URL -- I > need to know that it's from BILL and not BOB. > > Anyway, suppose there's a web page at cygwin.com which lists various > "unofficial cygwin package" locations -- like my /cygutils/testing > site, and the lilypond site, etc. > > Packages from user URLs need to be distinguished from packages from > official mirrors -- that's the only way a user can tell if the updated > version of gcc is an official update, or just someone's private > version -- or if some unofficial person was trying to pollute the > federation. [e.g. BOB makes a name for himself as a useful site for > cygwin ports of games, and then slip in a trojan "update" of bash] > > Anyway, in this scheme, 'unofficial' packages can be federated, and > not centrally controlled. It's understood that 'unofficial' packages > will NOT be supported by the main cygwin list -- and each person who > puts up a 'unofficial' site can set their own support policy. > > And end users should beware of updating 'core' cygwin packages from > non-mirror sites (as indicated by the color/bold/shading). If color > were sufficient (it isn't; think colorblind, visually impaired, laptop > displays), then I'd suggest: yellow(caution) for packages from > non-mirror sites, that do not have corresponding official packages; > red(danger) for packages from non-mirror sites that will "upgrade" > official packages. PLUS unofficial URLS printed *right there* in the > chooser. > > My support policy -- for "unofficial packages" from my website -- > would be "These packages work for me. If they don't work for you, I > don't care. If they trash your system, destroy your carpet, or kill > your dog, it's your problem, not mine. All mail goes to /dev/null. > Use at your own risk. If you want to see these packages as part of > the official cygwin distribution, download the -src archive(s), and > see http://www.cygwin.com/setup.html. I make no claim of ownership or > control on the cygwin ports of the packages provided here." > > The only danger (other than the trojan possibility mentioned above) > would be if two "unofficial" sites got into a pissing match: each site > provides its version of 'pkgfoo", and they get into a > release/version-number 'bidding war'. This is only a problem if both > unofficial sites are popular with the same people. Also, it's a > self-correcting problem: eventually, one site or the other or both > will become UNpopular with users and they'll drop it from their > setup.exe list -- hence no more conflict. > > ------------------------------ > > So, this proposal is actually two parts: > 1) policy: how to handle unofficial (e.g. non-ITP'ed) but setup > compatible ports. My proposal: don't. They don't need to be > distributed via the cygwin mirror system; that's what federation is > all about. But, to make things easier for end users, and to give some > slight warning against possible trojans... > 2) implementation: > (a) visually distinguish packages (or versions of official > packages) from User URLS -- and display the site URL in the chooser. > What's the best way to do this? > (b) an extension of the existing "related sites" web page, to > include a section with "Here are some setup-compatible sites that > offer cygwin packages. type these URLs in to setup.exe, and press Add > URL." > > I realize that (2)(a) is sort of a taboo "wouldn't it be nice if > setup.exe..." comment; and I'm willing to give it a go with the > sources, if no one else can. However, it's more important to know if > the community thinks this is a good idea or not, before wasting the > time implementing it... > > Comments? > > --Chuck > > epstool > help2man > jpeg2ps > libungif > netpbm > plotutils > pstoedit > pstoepsi > pstotext > tgif > ungifsicle > > > -- David A. Cobb, Software Engineer, Public Access Advocate "By God's Grace I am a Christian man, by my actions a great sinner." -- The Way of a Pilgrim; R. M. French, tr. Life is too short to tolerate crappy software. .
