From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27597 invoked by alias); 15 Nov 2001 23:00:04 -0000 Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sources.redhat.com Received: (qmail 27575 invoked from network); 15 Nov 2001 23:00:03 -0000 Received: from unknown (HELO pwi-mail.wapme.net) (213.70.39.36) by sourceware.cygnus.com with SMTP; 15 Nov 2001 23:00:03 -0000 Received: from wapme-systems.de (192.168.121.136 [192.168.121.136]) by pwi-mail.wapme.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id WKNLHD98; Fri, 16 Nov 2001 00:04:31 +0100 Message-ID: <3BF44917.93F7AFAB@wapme-systems.de> Date: Sun, 11 Nov 2001 08:26:00 -0000 From: Stipe Tolj Organization: Wapme Systems AG X-Mailer: Mozilla 4.7 [de]C-CCK-MCD QXW0322b (WinNT; I) X-Accept-Language: de,en MIME-Version: 1.0 To: Robert Collins CC: Corinna Vinschen Subject: Re: no more package moratorium? References: <007f01c16cde$5016de20$0200a8c0@lifelesswks> <20011114124323.C24614@cygbert.vinschen.de> <049601c16d58$d8565250$0200a8c0@lifelesswks> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-SW-Source: 2001-11/txt/msg00351.txt.bz2 > Nope. I don't think this is appropriate. cygwin-developers is for > developers of cygwin1.dll. Last I heard, Linus has no input into what > Redhat put into the (say) the RawHide distro, so why should the > cygwin1.dll developers care what goes into 'cygwin the net > distribution'. > > I think we should either get a consensus from all the package > maintainers, or perhaps, wait 3 days for objections. If no objections, > then the package is allowed in. If there are objections, discuss until > resolved. To prevent deadlock, a single individual objecting will not > cause a package to be rejected, the objections must be agreed with by > other package maintainers. I agree with Robert here. A simple -1,0,+1 voting valid from all current package maintainers should indicate the aprover if the package is considered "good enough". -1 for "no, I'm against " 0 for "I have no objections or do not care" +1 for "yes, go ahead from my point of view" This way we have a democrative way, but still without unnecessary reglementations for the aprover. The aprover decides on the global scope of the votings if the package should be within the official net distro. > Some sort of voting thing might be nice (mentioning to show I've thought > about it) but for now it seems too hard for too little benefit. I do > like the idea of a sponsor, so yep, as proclaimed above. > once a package is decided to be allowed in, if its the first package > from the maintainer (ie a new maintainer) then an existing maintainer > must sponsor the package, and vet package quality - > textmode/patches/postinstall scripts etc. good point -- package maintainers should be cycling in sponsoring for new package maintainers. This makes the communication between package maintainers more reliable and improves the quality of work. > I think the process for that part should be something like > > sponsor (for new maintainers) or maintainer (2nd package or new version > of existing) places the packages files at a URL. > They tell someone from . > uploads to cygwin.com. > > If there is _any_ doubt about the package quality, upload it as > experimental. Wait 3 weeks, and if there are no bugs reported, then edit > setup.hint to make that new versiom current. A package maintaining system (via the web site) would help here. I had this in mind for some time. (see my thread on the file conflict issues). Stipe tolj@wapme-systems.de ------------------------------------------------------------------- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: info@wapme-systems.de Internet: http://www.wapme-systems.de ------------------------------------------------------------------- wapme.net - wherever you are -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/