public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
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 ;-)


  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