From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=DATE_IN_FUTURE_03_06, DMARC_NONE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from obelix.spectraweb.ch (obelix.plusnet.ch [194.158.230.8]) by chiba.3jane.net (Postfix) with ESMTP id E5228AC571 for ; Sun, 9 Jun 2002 06:38:15 -0500 (CDT) Received: from seul.org (adsl-p42-dialup-89.adslplus.ch [195.141.144.89]) by obelix.spectraweb.ch (8.11.2/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id g59BcA023356 for ; Sun, 9 Jun 2002 13:38:10 +0200 Message-ID: <3D0391D8.7090003@seul.org> Date: Sun, 09 Jun 2002 13:35:20 -0400 From: Marko Mikulicic User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: gentoo-dev@gentoo.org Subject: Re: [gentoo-dev] Contribute many ebuilds at once References: <3D02F8A8.7030108@seul.org> <200206091256.52748.pauldv@cs.kun.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 7f85093c-ba57-4856-97f1-3289f8e7dcce X-Archives-Hash: 40b9197f6a422816f3f457c2939c2c38 Paul de Vrieze wrote: > On Sunday 09 June 2002 08:41, Marko Mikulicic wrote: > >> Alternatively I could write a dummy client which connects to the >>bugzilla like a webbrowser and automates the submission. >> (I suppose there is not a secure straight connection to the bugzilla >>backend) >> > > The problem is not so much the submission itself, but what happens afterwards. > New ebuilds take a lot of time to be included in the tree (if you have bad > luck) This is why I thought it was better to group them, so at least they will get in all in once. > > The new system tries to resolve that. What are the main reasions for this latency ? I imagine the package need to be tested somehow. How is this "new system" you are talking about ? How is the "old system", from a maintainer perspective ? What appens "afterwards" ? Wouldn't be nice if new ebuilds would committed to a middle place (purgatory) where they wait in a queue. But in the mean time audacious users could try the ebuilds (simply downloading them with ftp, or ebuild rsyinc-purgatory -> /usr/portage/purgatory) so at least they can be tested. Does it make sense ? Marko