From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12431 invoked by uid 1002); 22 Apr 2003 14:28:13 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 16142 invoked from network); 22 Apr 2003 14:28:12 -0000 From: Dan Armak Reply-To: danarmak@gentoo.org Organization: Gentoo Technologies, Inc. To: gentoo-dev@gentoo.org Date: Tue, 22 Apr 2003 17:26:35 +0300 User-Agent: KMail/1.5.1 References: <1050997108.2986.28.camel@amd.vsen.dk> <1051016369.4102.46.camel@entropy> In-Reply-To: <1051016369.4102.46.camel@entropy> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_bEVp+s0U59bfFTD"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200304221726.35741.danarmak@gentoo.org> Subject: Re: [gentoo-dev] Ebuilds not getting in :( X-Archives-Salt: 0ca8a5d8-30b8-4c10-bb51-84746eebe4a4 X-Archives-Hash: 572c7712cd2fa673b9a8334c91d426f4 --Boundary-02=_bEVp+s0U59bfFTD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Tuesday 22 April 2003 15:59, Frantz Dhin wrote: > I feel that this is one of the > reasons that we have an unstable branch, or maybe we could make a new > keyword? x86 for stable, ~x86 for unstable, and ^x86 for lunatic? :)=20 Just a quick note (without addressing your main point). ~arch is _not_=20 "unstable". It is not supposed to be unstable in the literal meaning of the= =20 word. It is 'testing', or 'works for me'. Developers can _not_ commit thing= s,=20 or leave things, unmasked in ~x86 that have known issues, or that are=20 alpha-quality releases from upstream. (This doesn't apply directly to what= =20 you were saying, I just don't like to see it called unstable...) =2D--- Now to the main issue. The main reason why submitted ebuilds aren't getting= =20 into portage easily and quckly is not the need for testing before committin= g.=20 It is that the person committing that ebuild, or _some_ other developer, wi= ll=20 have to maintain it later on. That means being responsible for problems wit= h=20 it (and there are always some problems eventually), and processing future=20 updates/bureports/feature requests etc. These require that developer to be well acquianted with the ebuild. If the = app=20 is nontrivial, and there are several such under this developer's care, it c= an=20 get quite troublesome. And remember this developer generally does not use=20 these apps himself - or he would have added an ebuild without waiting for a= =20 user submission. The points you and other people make in this thread are known and acknowled= ged=20 by us. We are busily working towards a setup that solves these problems. Th= e=20 first step is the upcoming (I hope) reorganization of the gentoo internal=20 development model so that every ebuild has explicit maintainer(s). The seco= nd=20 will facilitate quick acceptance of user-submitted ebuilds in some way -=20 probably drawing upon the submitters in one way or another. The implementation of this second step depends (imo) on the first, which is= =20 being busily discussed for the past week. Please give us time to put it int= o=20 place before we move into the second phase, which is when user opinions/ide= as=20 will be heard properly. =2D-=20 Dan Armak Gentoo Linux developer (KDE) Matan, Israel Public GPG key: http://cvs.gentoo.org/~danarmak/danarmak-gpg-public.key --Boundary-02=_bEVp+s0U59bfFTD Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA+pVEbUI2RQ41fiVERAgPxAKCHOqbDRzBeqaO0HX6jQQABvl+skgCdF7Wb LQVHAsCjwH9KsLtQU/pduI8= =BhJj -----END PGP SIGNATURE----- --Boundary-02=_bEVp+s0U59bfFTD--