From: Charles W. <cwi...@us...> - 2011-10-16 17:55:20
|
On 10/16/2011 6:39 AM, Keith Marshall wrote: > On 13/10/11 13:33, Earnie wrote: >> My stance has been that if someone is willing to maintain and upload >> the package then we can offer it. > > Mine too; indeed, I think we should actively *encourage* users to offer > such contributed packages. That does impose a responsibility on us, to > ensure that such contributed packages are completely compatible with the > core MinGW distribution, (and if they are fully packaged for delivery by > mingw-get, so much the better). Actually, IMO this should be a requirement for hosting on mingw.org. What good is a contribution if it can't be installed like all the other packages -- it becomes even more of a third-class citizen (rather than simply second-class, since it wouldn't actually be "core") What concerns me is this: for a typical package update, it takes me about a half hour to (1) upload the package tarballs (2) update the xml manifest & mingw-dist ChangeLog (3) build mingw-dist (to create the .lmza of the xml, with the YYYYMMDDNN internal timestamp update) (4) put a copy of the (unpacked) .lzma in my local mingw /var area (5) test that mingw-get can install/upgrade the package with the new .xml manifest (6) check it in the mingw-dist changes (7) upload the new manifest, and finally (8) send an annoucement email. Some of these steps require the ability to access mingw's frs, others require the ability to check in to mingw's cvs repo. Unless we plan to grant these privileges to any and all contributors, some/most/all of these steps would fall on one of us. If there are a half-dozen contributed packages, not a big deal. If there are hundreds...it becomes unmanageable. Maybe #2 could be done by the contributor who just posts a patch for mignw-dist, for us to apply and commit, and #3-#5 could be deferred until/unless an actual complaint arises on the mailing list (e.g. we just accept a proposed patch to mingw-dist and blindly apply it, if the contributor is "experienced"). Naturally, #8 would be the contributor's responsibility...leaving "us" to do #1, repeat #3 locally, #6, and #7. Note that cygwin has a similar bottleneck: only a few people have upload permissions to sourceware. However, given the design of *cygwin's* install program, the burden on those few people amounts to only steps #1 and #7 -- which takes far less time [*] [*] Usually. I was the "shepherd" for JonY's cygwin->mingw64 cross toolchain packages, so I usually upload his updates. But...they are HUGE and there are a lot of packages, so...just step#1 sometimes takes a while. Cygwin also has a procedure for "vetting" and "approving" new packages. A contributor will post an "ITP" ("Intend to Provide/Package") announcement to the cygwin-apps mailing list. If the package exists in any major linux distribution, it is assumed to be approved provided the next step is satisfied; otherwise, five existing package maintainers must give it an affirmative assent. (Arguably, the benevolent dictators cgf and Corinna could NAK a ITP even after it had five approvals, but I don't recall that ever happening). The next step is the "GTG" ("good to go") approval. Any experienced package maintainer can download the proposed packages' -src archive, and verify that it builds correctly (using a common build/packaging tool like cygport [or mgwport, in our case] obviously makes this easier). That person should also verify that all the other subcomponents follow the generally accepted package rules. If so, they can post a "GTG" reply to the original ITP. At that point, all that remains is uploading to sourceware. Contributors are expected to send their own announcements (to cygwin-announce). After a package has been accepted, later updates are pro forma: the contributor posts an "RFU" ("Request For Upload") message to the cygwin-apps mailing list, with the URL to publicly accessible copies of the new packages. One of the folks with upload privs handles uploading the packages and setup.hints to sourceware; if a few days pass without action, a Ping usually gets an immediate response. > However, this does *not* imply a > responsibility for continued maintenance, in perpetuity... Right, hence my preference for partitioning them into a separate Contrib category --- as a directory under MinGW/ and MSYS/ on frs, and also as a separate <affiliate group="MinGW Contrib"/> or "MSYS Contrib". We should also have a rule, that no "official" package may depend on (<require />) a Contributed package, unless that package is also "promoted" to core -- see below. Segregating contributed packages, by frs directory and mingw-get affiliate group, make this rule easier to obey. >> Often though the maintainer doesn't stick around long enough to allow >> for updating the packages. > > I don't see this as a serious problem. If the original contributor > withdraws support, then the package will simply become "unmaintained"; > it may remain as such, until another volunteer steps forward to adopt > it, and contribute further updates. This is why "core" packages must not depend on "Contrib" ones -- because doing so effectively promotes them TO core, since we (the MinGW team) would effectively be assuming a perpetual responsibility for them via the transitive dependence of the core package. And, addition tons of new stuff to the "core" set makes it less Minimal than ever. >> Certainly a separate project to do this isn't in the best interest >> of MinGW. > > I agree. From a user's perspective, I would always favour a package > from a MinGW sanctioned repository, with its implied endorsement of > compatibility, over any third party offering, (unless the third party > offering provides a more recent feature which I absolutely require). Sure. As a counterexample, the cygwin-ports project has a large following, and its own mailing list for support (yay!). It grew because Yaakov developed a reputation for quality and reliability, and his repository hosts over 2000 packages that are not part of cygwin's own offerings, or provide features that cygwin's versions do not [**]. Now, I don't use cygwin-ports, precisely because I maintain a large number of cygwin's official packages, and don't want to accidentally pick up a dependence on a "third party" (e.g. cygwin-ports) package in my official cygwin releases. [**] usually because those features require additional supporting packages, which nobody has officially submitted to cygwin itself -- but which cygwin-ports does provide. >> Keith, what is your standing on this issue? > > As summarised above. Also... > > On 12/10/11 20:21, Charles Wilson wrote: >> Stuff like PDCurses falls under the "historical exception" because >> long ago, there used to be a PDCurses mingwPORT "contrib" item, and >> somebody offered to update it to make it "mingw-get" compatible. > > As Erwin subsequently noted, it was he who provided that update. Right, I had a momentary brainfreeze and forgot who exactly did that. > FWFW, > and without implying any stigma, I would continue to classify Erwin's > PDCurses as a "contributed" package. While I don't anticipate that > Erwin will abandon it in the immediate future, that could happen at any > time. If it should happen, then PDCurses may again become unmaintained; > even as such, it would remain as a useful contribution, without > requiring immediate adoption by a new maintainer, since it is not an > essential prerequisite of any core package. Ack and agree. So, to sum up the areas of agreement so far: 1) Contributions are welcome, and can/should be hosted on mingw.org 2) They must be completely compatible with the core MinGW (or MSYS) distribution (e.g. not clobber existing files, are installed "properly" into the appropriate directory hierarchy, etc). a) It is the responsibility of the MinGW devs to ensure this is true before approving a new contribution for upload. [***] Propositions for which consensus has not yet been achieved: 3) Contributions should be mingw-get compatible (manifests, package naming scheme, etc) 4) Policies and procedures for approving new contributions. Also, division of responsibility: what is the contributor responsible for, and what are the MinGW devs responsible for? 5) Policies and procedures for handling updates of existing contributions. Also, division of responsibility. 6) No "official" or "core" package may depend on a Contributed item, unless that item is also promoted to core. As this imposes a higher (and perpetual) responsibility on the MinGW devs, this promotion probably needs unanimous agreement from the exising MinGW devs. 7) Contributed items should be housed on frs in their own subdirectory of the appropriate subsystem. 8) The xml manifests for Contributed items should specify a specific affiliate group, either "MinGW Contributed" or "MSYS Contributed" 9) Should contributors be given write access to CVS to update their own manifests, even if they do not join the project as MinGW devs? Should they be given upload access to the frs to upload their own contributions, even if they do not join the project as MinGW devs? [***] I assert (well, at this point it's just "hope") that if contributors use mgwport for the Contribution, both (2) and (2a) will be easier for us (MinGW devs) to do -- and therefore will get quicker response to the Contributor. -- Chuck |