From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29432 invoked by uid 1002); 29 Apr 2003 18:17:17 -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 21366 invoked from network); 29 Apr 2003 18:17:15 -0000 Date: Tue, 29 Apr 2003 11:17:13 -0700 From: Robin H.Johnson To: Mikael Andersson Cc: gentoo-dev@gentoo.org Message-ID: <20030429181713.GA5827@cherenkov.orbis-terrarum.net> Mail-Followup-To: Mikael Andersson , gentoo-dev@gentoo.org References: <20030425T113433Z_B95E00150000@gentoo.org> <20030425195715.GA10001@fco-gimeno.com> <20030425210049.GA15299@cherenkov.orbis-terrarum.net> <200304291944.43442.snikkt@telia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline In-Reply-To: <200304291944.43442.snikkt@telia.com> User-Agent: Mutt/1.5.3i Subject: Re: [gentoo-dev] Community driven meta distribution or only distribution (was Re: Several portage trees) X-Archives-Salt: ad9fa417-9f2f-4f09-8c0d-d733c0c4552a X-Archives-Hash: 179fda816045f5b81787de0b9fab1498 --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 29, 2003 at 07:44:41PM +0000, Mikael Andersson wrote: > Gentoo is moving to slow this is why this kind of ideas emerge. It might = be=20 > moving fast, but obviously still too slow for many. I've got a few ebuild= s=20 > done which i haven't even bothered to try to get in since i've seen the q= ueue=20 > in bugzillla and I'm sure several others are in the same situation. Seeing this. I have a specific request to make. Could you please ensure that your ebuilds are tagged with the 'EBUILD' keyword, to make them easier to find firstly. Secondly, just as an idea, a developer that has some time to go thru submitted ebuilds and review them for style and correctness (as I did for the ebuild mentioned above in this thread). > On Friday 25 April 2003 21.00, Robin H.Johnson wrote: > > On Fri, Apr 25, 2003 at 09:57:15PM +0200, kikov@fco-gimeno.com wrote: > > > Well... I'm a developer of a project. I have submitted via bugzilla > > > several bugs of one of the packages I need ( not from the project, ju= st > > > a dependency ). Let see: http://bugs.gentoo.org/show_bug.cgi?id=3D2333 > > > ohh, yeah, 2002-05-02 07:28 EST... One year ago... > > > The bug is still opened. > > Go back and read my posting about why many ebuilds don't get into the > > tree. > I didn't see a lot of comments about the ebuild not being up to par in=20 > bugzilla. Maybe if a developer seeing a build not beeing 'good-enough' co= uld=20 > add a small note about this so we - The Users(tm) - or in another word, = the=20 > user community [3] can fix whats wrong. We aim to please ... My comments were included below in my previous email. I have also attached them to the bug item now. > > If you fix those issues, and fix that ebuild. > > Things to fix: > > add SLOT, add KEYWORDS, add IUSE, 'use foo' statement style, use PATCHES > > instead of patch+src_unpack, local variable declarations, unnessicary > > statement block in src_install, broken homepage URI, ALL documentation > > with the package should be installed (manpages and even the guys pgp > > key) , einstall instead of 'make install' and most importantly EBUILD > > CHANGELOG!!!!! > No need to yell, instead add that information to [1]. In a way it's writt= en in=20 > [2] but as that is targeted for developers it's hard to know whether or n= ot=20 lintool/repoman do remind you that some of those are required, but for the most part they require a human to check. The original ebuild looked as if it was written using only the guide, and none of the existing ebuilds in portage, many of which server as excellent examples of ebuild style and how things are done. However you are partially correct that some of this should be added to [1]. most importantly, - say required items SLOT/KEYWORDS/IUSE/HOMEPAGE - say that all documentation should be installed - recommend econf/emake/einstall instead of normal variants - patch+src_unpack is not efficent and maybe incorrect, use PATCHES=3D"..." Some of the things I mentioned are also partially my personal preferences to make life easier on myself. People's code says a lot about them generally, and if your submitted ebuilds look sloppy and that lessens the chance that developers will even go thru them and say what is wrong, let along clean them up. > I'm required to add that to my update, and if i should attach another fil= e=20 > with the entire changelog/changelog entry. Attaching a simple text file with just your changelog entry would be sufficent if you are updating an existing package, or including a new changelog from the skeleton file for a new ebuild. (This is a personal preference again). > And equally important, somebody with the proper knowledge should get > lintool online again. Apparently it's broken ( see warnings in [2] ) > and sure enough it reports errors for baselayout and other core > packages so it's probably at least somewhat broken. Repoman replaced lintool. I don't unfortunetly know of a tool that users can use to check ebuilds themselves, as repoman requires a CVS checkout. I have said previously that lintool needs to come back myself, and I have submitted some fixes for it to bugzilla myself. That document [2] does appear to contradict itself. > > Is libcap even actively maintained still? If not and it is not widely > > used, then it is not likely to get into the tree at all. > Maybe Larry the cow will stop using gentoo then ? After all he liked bein= g in=20 > control. If the users isn't in control gentoo will stop beeing bleeding e= dge=20 > and maybe end up only bleeding. I personally try to avoid packages that do not fill at least one of the following requirements: 1) is actively maintained 2) is widely used 3) not directly useful to myself the reasoning behind 1) is that unmaintained packages upstream of Gentoo do cause problems. media-plugins/avi-xmms is a recent example. It is presently masked in packages.mask while it dies down further, at which=20 point if it is no maintained again, it will probably be trimmed from the=20 tree. > What are the purpose of being a meta distribution if only widely used pac= kages=20 > get into the tree ? > > If you resolve all of the above issues, and the package is still widely > > used (I want some proof of this), then I'll take the ebuild and maintain > > it in portage myself. > Well, this is a problem since not all packages wanting to be in portage w= ill=20 > be widely used. But i have hopes that these kind of problems will be reso= lved=20 > with the restructuring of ebuild submission and maintainance in progress. For 2) packages that aren't actively maintained, but are widely used usually have enough other support and people working with them that it is possible to support them ourselves. An active and responsive mailing list for a package fills this well, or if there are good pages written up about the package on the web. Several actively maintained packages that use the library as a requirement would also serve to show that it is still in general use. Item 3) is somewhat different than the other two. If there is a package that doesn't fit into the other two, and I have a personal everyday use for it, I'm willing to put some of my time to keeping it working. > [1] http://www.gentoo.org/doc/en/ebuild-submit.xml > [2] http://www.gentoo.org/doc/en/gentoo-howto.xml > [3] http://www.gentoo.org/main/en/about.xml --=20 Robin Hugh Johnson E-Mail : robbat2@orbis-terrarum.net Home Page : http://www.orbis-terrarum.net/?l=3Dpeople.robbat2 ICQ# : 30269588 or 41961639 GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Robbat2 @ Orbis-Terrarum Networks iD8DBQE+rsGpsnuUTjSIToURAnzRAJ4pHesJkCuMsClBe2SdUwE7g9dd8ACfbUCT WNbmk4kSS0ua2eINHbWm/cU= =OGAa -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--