From: "Steven J. Long" <slong@rathaus.eclipse.co.uk>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: [OT] pkgcore bikeshed
Date: Mon, 13 Jan 2014 11:02:10 +0000 [thread overview]
Message-ID: <20140113110210.GA1993@rathaus.eclipse.co.uk> (raw)
In-Reply-To: <52D3AEB9.7080500@pathscale.com>
On Mon, Jan 13, 2014 at 04:15:37PM +0700, "C. Bergström" wrote:
> On 01/13/14 03:43 PM, Alexander Berntsen wrote:
> > Realistically, we have to keep updating them both in parallel. pkgcore
> > needs to be brought up to portage-level functionality,
Yeah but it already outshines under the hood: all you're talking about is
EAPI and radhermit is working on it; I'm sure he and dol-sen would be
happy for more help as well, so long as it's supportive. ISTR TomWij is
involved too.
Updating both in parallel isn't hard: once pkgcore is up to EAPI-5, EAPI-6
isn't that much work (mostly bash afair.) At that point, put portage into
feature-freeze, and only bugfix it. Call a hiatus on new EAPIs for 6 months
and put all effort into making damn sure pkgcore is a drop-in replacement.
There's certainly enough devs to do that, and definitely enough interest
in finally moving to portage-NG.
> > and we need to keep fixing portage bugs for its many users.
Sure.
> > We could have a technical
> > discussion on the merits of pkgcore vs. portage, but in the end, it's
> > about the users.
I don't think anyone who's serious can come down on any side but pkgcore
in that debate, so I agree we skip that discussion.
You won't get any disagreement from me on your last point.
> > For the record, I would be very happy if you hacked on pkgcore. Just
> > as happy as if you hacked on portage, even. So please do. :-)
Good good :-)
> We can blah blah about performance of resolving package dependencies
> all day long, but it's clearly not a game changer feature for users.
> (or they just don't know)
They just don't know: and it really is a game-changer, once you've tried it.
We must be able to finally deliver pkgcore speed, 5 years after the event.
> Long term the API to pkgcore could be beneficial, but again I'm not sure
> it's a game changer for users.
Doesn't matter: it's good to have something the devs can get hyped about too.
snakeoil is a lovely bit of code.
> [1] /* Side details */
> In a nutshell we make it possible to track the results of "make check"
> or equivalent test coverage for every source package. There's a little
> work involved for setting up each package, but it gives the easy ability
> to *know* and prove that between xyz ${FLAGS} there's no regressions.
> For example: How do you *know* that fftw or ssl is regression free when
> you enable avx, fma or some other higher level of optimization (-O3). By
> knowing I don't mean just result correctness, but also potentially
> runtime performance, code size and potentially compile times. (If those
> are things you care about)
OFC they are, or we wouldn't be using Gentoo ;) And that does sound like
an interesting project, of wider interest to the community. (hint hint;)
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
next prev parent reply other threads:[~2014-01-13 10:50 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-06 5:33 [gentoo-dev] Portage team, Zac's development break and stepping down as lead Brian Dolbec
2014-01-06 7:53 ` Dirkjan Ochtman
2014-01-06 8:27 ` Brian Dolbec
2014-01-13 3:07 ` Brian Dolbec
2014-01-13 5:05 ` Brian Dolbec
2014-01-13 8:39 ` C. Bergström
2014-01-13 8:43 ` Alexander Berntsen
2014-01-13 9:15 ` [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) "C. Bergström"
2014-01-13 9:31 ` Fabio Erculiani
2014-01-13 9:38 ` "C. Bergström"
2014-01-13 14:58 ` Tom Wijsman
2014-01-13 15:38 ` Luis Ressel
2014-01-13 15:46 ` Tom Wijsman
2014-01-13 17:03 ` Luis Ressel
2014-01-13 18:07 ` Tom Wijsman
2014-01-13 18:05 ` Ciaran McCreesh
2014-01-13 18:19 ` Tom Wijsman
2014-01-13 16:49 ` Alec Warner
2014-01-13 17:10 ` Fabio Erculiani
2014-01-13 18:16 ` Tom Wijsman
2014-01-13 18:21 ` Ciaran McCreesh
2014-01-13 18:32 ` Tom Wijsman
2014-01-13 23:22 ` Patrick Lauer
2014-01-13 23:49 ` Tom Wijsman
2014-01-13 11:02 ` Steven J. Long [this message]
2014-01-13 12:28 ` [gentoo-dev] Re: [OT] pkgcore bikeshed Alexander Berntsen
2014-01-13 13:06 ` Andreas K. Huettel
2014-01-13 13:50 ` Ulrich Mueller
2014-01-13 15:28 ` Tom Wijsman
2014-01-13 17:51 ` [gentoo-dev] " Ulrich Mueller
2014-01-14 7:41 ` [gentoo-dev] pkgcore EAPI-6 (Was: OT: pkgcore bikeshed) Steven J. Long
2014-01-13 15:21 ` [gentoo-dev] Re: [OT] pkgcore bikeshed Tom Wijsman
2014-01-13 20:29 ` Donnie Berkholz
2014-01-13 14:46 ` [gentoo-dev] [OT] pkgcore bikeshed (was Portage team) Tom Wijsman
2014-01-13 14:56 ` Ian Stakenvicius
2014-01-13 15:31 ` Tom Wijsman
2014-01-13 18:01 ` Brian Dolbec
2014-01-13 18:07 ` Ciaran McCreesh
2014-01-13 18:27 ` Tom Wijsman
2014-01-13 18:37 ` Ciaran McCreesh
2014-01-14 7:56 ` [gentoo-dev] " Steven J. Long
2014-01-13 14:53 ` [gentoo-dev] " Tom Wijsman
2014-01-19 8:25 ` Mike Frysinger
2014-01-13 17:37 ` Greg KH
2014-01-13 17:42 ` "C. Bergström"
2014-01-13 17:56 ` Greg KH
2014-01-13 8:59 ` [gentoo-dev] Portage team, Zac's development break and stepping down as lead Dirkjan Ochtman
2014-01-13 14:42 ` Tom Wijsman
2014-01-13 14:46 ` Peter Stuge
2014-01-13 15:38 ` Tom Wijsman
2014-01-13 16:41 ` Alec Warner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140113110210.GA1993@rathaus.eclipse.co.uk \
--to=slong@rathaus.eclipse.co.uk \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox