Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[Brian Dolbec <dolsen@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3288 bytes --]

On Mon, 2014-01-13 at 15:46 +0100, Tom Wijsman wrote:
> On Mon, 13 Jan 2014 16:15:37 +0700
> "C. Bergström" <cbergstrom@pathscale.com> wrote:
> 
> > Long term the API to pkgcore could be beneficial, but 
> > again I'm not sure it's a game changer for users.
> 
> Long term, we should have an independent API backend that tools can
> query; not rewrite our tools every time users want to use them with a
> different package manager. 
> 

I have been working towards that for years, but, things keep getting in
the way.  By things, I mean other project work that needs to be done as
well.  I got started in all this working on porthole, which uses
portage's api for much of it's information.  To get more features,
information, I wanted to be able to incorporate some of gentoolkit's
info.  Namely equery, but most of it's working code was embedded with
it's output.  I worked hard at separating out it's working code from
it's output so it would be usable by other tools.  I have also been
working on making a pkgcore backend for porthole.  In doing that it
required making a different backend for portage to get some uniformity
for the frontend.  I have had to put development of those on hold, due
to taking over layman's development.  I gave it a new high level api,
modified it's mid level code and gave it a nice api that can be used by
other apps, guis, etc..  One of the things that came up with layman was
to be able to gpg enable it to verify it's repositories.xml list it
downloads.  I did that.  In so doing created  dev-python/pyGPG a python
lib, which has now brought me in to developing Gentoo-keys (another
project that could use help) to manage gentoo's gpg release, developer
keys, and verification.  Also at the same time a year ago, there was a
lot of talk about moving the default location of the gentoo tree, but it
could not be done with current catalyst code.  So offered to help out as
that project was severely lacking people with decent python skills.
That code base is like what portage code was 8 years ago.  And if you
thought todays portage code is bad... you would cringe to see it's code
from 8 years ago.

Now portage was in trouble, while there were some people stepping in to
fix things, I stepped up to help drive out a new release.  I am now
interim lead till we hold an election.  So most of my time now is spent
steering projects, more than coding.  Hey, it's all work that has to be
done.  So I'm putting out fires where it needs it most.

With that aside.  One of the biggest hurdles new developers face with
pkgcore is the lack of decent api docs and flow charts.  Brian was
brilliant and OCD about attaining speed, but at the cost of difficulty
in following the code and creating the steep learning curve.  I have
been trying to get these other projects to a point I could create the
docs and charts needed so that it would be easier for new developers to
find their way in pkgcores code.  That is when pkgcore will make more
headway at becoming portage's replacement.  But some new fires keep
popping up.


Long story in a nutshell, gentoo could use more GOOD firefighters.

Sorry for the long speech ;)
your friendly gentoo python firefighter

-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]