From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 815171381F3 for ; Sun, 16 Jun 2013 17:09:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6AB98E08D1; Sun, 16 Jun 2013 17:09:39 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 790CAE0856 for ; Sun, 16 Jun 2013 17:09:38 +0000 (UTC) Received: from [192.168.1.210] (S010600222de111ff.vc.shawcable.net [96.49.5.156]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dolsen) by smtp.gentoo.org (Postfix) with ESMTPSA id 5A1B333DD04 for ; Sun, 16 Jun 2013 17:09:37 +0000 (UTC) Message-ID: <1371402560.28535.79.camel@big_daddy.dol-sen.ca> Subject: Re: [gentoo-dev] Packages up for grabs From: Brian Dolbec To: gentoo-dev@lists.gentoo.org Date: Sun, 16 Jun 2013 10:09:20 -0700 In-Reply-To: <20130616164445.0c8f8f55@TOMWIJ-GENTOO> References: <1371376191.10717.15.camel@localhost> <1371390923.28535.67.camel@big_daddy.dol-sen.ca> <20130616164445.0c8f8f55@TOMWIJ-GENTOO> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Archives-Salt: 4ffb80a7-8461-4989-ba04-16a185bc1418 X-Archives-Hash: 22f92e85d5b324a3500066c0f889f4de On Sun, 2013-06-16 at 16:44 +0200, Tom Wijsman wrote: > On Sun, 16 Jun 2013 06:55:23 -0700 > Brian Dolbec wrote: > > > I'll take pkgcore (if somehow we can get eapi 5 finished.) > > Here's the catch: it's not only about finishing EAPI 5, but also about > implementing the upcoming EAPI 6 changes and fixing any bugs that arise. > > For it to be feasible to use it would need an upstream maintainer > for that package; it goes a little further than "let's implement X or > fix Y", the code has to be understood to gain the necessary insight. > > If one just hacks in things to make it work, he'll waste efforts. > Think before anyone plans to pick this up, it is quite a commitment. > > http://c2.com/cgi/wiki?LegacyCode > > http://www.amazon.com/books/dp/0131177052 > > I sincerely have interest in working on a heavily refactored PM or a PM > from scratch; but, I can't see myself pick up a big Python project as > I'm not really used to anything beyond average Python scripts. Or maybe > I'm afraid of nothing, I can't tell in advance not knowing its code. > > I'll take it into consideration though; there is quite a huge choice > between applying software re-engineering practices (mostly reverse > engineering) to pkgcore, applying those practices (mostly refactoring) > to Portage or implementing an all new PM from scratch. > Thank you for considering helping. I have stayed away form the intricate details of package management in the past, but I also do not like how long portage is taking now for dep calculations. So, I am going to look into what it needs to be completed. I know there are others out there that would also like to see pkgcore keep going. If we (that means I want help, so please speak up) can get EAPI 5 finished. Then EAPI 6 will be that much easier when the time comes, which is hopefully not too soon. For the record, I have admin capability to pkgcore's repo, so if we can get things ironed out. It will be possible to push the changes to the main repo and release it. But, I also admit that pkgcore may have to move to an overlay to get it up to speed with current required functionality.