public inbox for gnap-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: "josé Alberto Suárez López" <bass@gentoo.org>
To: gnap-dev@lists.gentoo.org
Subject: Re: [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love
Date: Wed, 26 Mar 2008 14:19:03 +0100	[thread overview]
Message-ID: <1206537543.15053.9.camel@supercoco> (raw)
In-Reply-To: <1206536227.3183.71.camel@troy.riegger.name>

hi :)

as we talked before...

El mié, 26-03-2008 a las 13:57 +0100, Philipp Riegger escribió:
> Good morning,
> 
> I have some ideas for Summer of Code which i'd like to discuss with you.

new ideas ever welcome

> I'm mostly interested in making GNAP usable and my proposal includes
> lots of tasks in GNAP and catalyst, of which i'd like to finish as many
> as possible and do some research on the rest.
> 
> catalyst tasks:
> 
> • Squashfs snapshot support
> I don't like it, that it takes so much time to unpack a new snapshot and
> it takes so much disk space to store it. Plan is: distribute tree
> snapshots as squashfs images, mount them directly into the workdir,
> use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories.

i like this can be usefull, the problem is how mcuh espace you need to
redistribute all sources we need (not only gnap-core srcs, i mean
extensions srcs too)

> • (Squashfs seedstage support)
> Maybe the same is possible for stages? A future plan for this could be
> to mount the squashfs image directly and use unionfs for the real work,
> but i have no idea how deleting files in such a setup works. Research is
> necessary here.

i dont understand it well

> • uclibc-cross-compiling support
> Cross compiling is hard, but it should be possible to build arch-uclibc
> from arch. Research, what needs to be done combined with the
> implementation, if possible. This would also make GNAP more flexible.

this will be one of the biggest features so as you know is hard.

> • Documentation
> In an email from some days ago i read, that documentation is planed for
> after the release. I could support this and proofread it, since i need
> the knowledge anyway.

you mean gnap doc or catalyst doc?

> • (Code cleanups)
> I write this everywhere, but since i need a basic understanding, i have
> to read (parts of) the source and maybe i find something worth
> improving.

ever welcome :)

> • Cross compiling research
> This is the continuation of the uclibc stuff with some plans on what
> could be done how.
> 
> • Non-root builds research
> Wouldn't it be nice if being root was not necessary for using catalyst?
> I would like to look into the possibilities there and what is needed to
> make it reality.

i think that is hard, you dont need root only for catalyst, other GNAP
operations need to be root.

> GNAP tasks:
> 
> • Code/Tree hosting, VCS
> I've done some work last year and that does only exist as some patches,
> since there is no central repository for GNAP development. First i'd
> like to establish one and move all existing resources there.

yes, what about your google-code testing?

> • GNAP 2.1
> There are some known and easy to fix bugs in GNAP 2.0. There have also
> been some code cleanups. The last thing is, that the current GNAP is not
> really usable, since the tree snapshot is so old, that most of the
> distfiles are not fetchable from mirrors or other places. So i'd like to
> make a new release, be it in the tree or in an overlay.

you are right, but first we need and updated tree

> • Reimplementation in python research
> Catalyst is written in python, maybe we could make better use of it if
> we reimplemented some parts of GNAP in python? This is just a research
> item, i'd like to look into it and form some statement about it. I'll
> probably not do it.

i prefer to keep bash

> • uclibc-cross-compiling support
> This depends on catalyst.
> 
> • (Cross-compiling support)
> My last years project. My thoughts/plans about that should be discussed
> with the community and put on the GNAP development website.
> 
> • GNAP releases, long term support
> This is just an idea i have. Think of something like this: With each
> gentoo release, we take the release snapshot, form our reduced GNAP
> snapshot (only supported profiles, unsupported USE flags masked,
> unneeded ebuilds (X, desktop stuff) not in the tree) and support it for
> some time security wise (like the releng team does during release). This
> is more of a research topic, with informing what needs to be done,
> writing of scripts, maybe doing a proof of concept (maintaining a
> snapshot for some weeks to see how it works).


--
gnap-dev@lists.gentoo.org mailing list



  reply	other threads:[~2008-03-26 13:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-26 12:57 [gnap-dev] [RFC] Summer of Code Proposal: GNAP Love Philipp Riegger
2008-03-26 13:19 ` josé Alberto Suárez López [this message]
2008-03-26 13:45   ` Philipp Riegger
2008-03-28  9:07 ` Philipp Riegger

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=1206537543.15053.9.camel@supercoco \
    --to=bass@gentoo.org \
    --cc=gnap-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