1 |
hi :) |
2 |
|
3 |
as we talked before... |
4 |
|
5 |
El mié, 26-03-2008 a las 13:57 +0100, Philipp Riegger escribió: |
6 |
> Good morning, |
7 |
> |
8 |
> I have some ideas for Summer of Code which i'd like to discuss with you. |
9 |
|
10 |
new ideas ever welcome |
11 |
|
12 |
> I'm mostly interested in making GNAP usable and my proposal includes |
13 |
> lots of tasks in GNAP and catalyst, of which i'd like to finish as many |
14 |
> as possible and do some research on the rest. |
15 |
> |
16 |
> catalyst tasks: |
17 |
> |
18 |
> • Squashfs snapshot support |
19 |
> I don't like it, that it takes so much time to unpack a new snapshot and |
20 |
> it takes so much disk space to store it. Plan is: distribute tree |
21 |
> snapshots as squashfs images, mount them directly into the workdir, |
22 |
> use /mnt/distfiles and /mnt/packages instead of snapshot subdirectories. |
23 |
|
24 |
i like this can be usefull, the problem is how mcuh espace you need to |
25 |
redistribute all sources we need (not only gnap-core srcs, i mean |
26 |
extensions srcs too) |
27 |
|
28 |
> • (Squashfs seedstage support) |
29 |
> Maybe the same is possible for stages? A future plan for this could be |
30 |
> to mount the squashfs image directly and use unionfs for the real work, |
31 |
> but i have no idea how deleting files in such a setup works. Research is |
32 |
> necessary here. |
33 |
|
34 |
i dont understand it well |
35 |
|
36 |
> • uclibc-cross-compiling support |
37 |
> Cross compiling is hard, but it should be possible to build arch-uclibc |
38 |
> from arch. Research, what needs to be done combined with the |
39 |
> implementation, if possible. This would also make GNAP more flexible. |
40 |
|
41 |
this will be one of the biggest features so as you know is hard. |
42 |
|
43 |
> • Documentation |
44 |
> In an email from some days ago i read, that documentation is planed for |
45 |
> after the release. I could support this and proofread it, since i need |
46 |
> the knowledge anyway. |
47 |
|
48 |
you mean gnap doc or catalyst doc? |
49 |
|
50 |
> • (Code cleanups) |
51 |
> I write this everywhere, but since i need a basic understanding, i have |
52 |
> to read (parts of) the source and maybe i find something worth |
53 |
> improving. |
54 |
|
55 |
ever welcome :) |
56 |
|
57 |
> • Cross compiling research |
58 |
> This is the continuation of the uclibc stuff with some plans on what |
59 |
> could be done how. |
60 |
> |
61 |
> • Non-root builds research |
62 |
> Wouldn't it be nice if being root was not necessary for using catalyst? |
63 |
> I would like to look into the possibilities there and what is needed to |
64 |
> make it reality. |
65 |
|
66 |
i think that is hard, you dont need root only for catalyst, other GNAP |
67 |
operations need to be root. |
68 |
|
69 |
> GNAP tasks: |
70 |
> |
71 |
> • Code/Tree hosting, VCS |
72 |
> I've done some work last year and that does only exist as some patches, |
73 |
> since there is no central repository for GNAP development. First i'd |
74 |
> like to establish one and move all existing resources there. |
75 |
|
76 |
yes, what about your google-code testing? |
77 |
|
78 |
> • GNAP 2.1 |
79 |
> There are some known and easy to fix bugs in GNAP 2.0. There have also |
80 |
> been some code cleanups. The last thing is, that the current GNAP is not |
81 |
> really usable, since the tree snapshot is so old, that most of the |
82 |
> distfiles are not fetchable from mirrors or other places. So i'd like to |
83 |
> make a new release, be it in the tree or in an overlay. |
84 |
|
85 |
you are right, but first we need and updated tree |
86 |
|
87 |
> • Reimplementation in python research |
88 |
> Catalyst is written in python, maybe we could make better use of it if |
89 |
> we reimplemented some parts of GNAP in python? This is just a research |
90 |
> item, i'd like to look into it and form some statement about it. I'll |
91 |
> probably not do it. |
92 |
|
93 |
i prefer to keep bash |
94 |
|
95 |
> • uclibc-cross-compiling support |
96 |
> This depends on catalyst. |
97 |
> |
98 |
> • (Cross-compiling support) |
99 |
> My last years project. My thoughts/plans about that should be discussed |
100 |
> with the community and put on the GNAP development website. |
101 |
> |
102 |
> • GNAP releases, long term support |
103 |
> This is just an idea i have. Think of something like this: With each |
104 |
> gentoo release, we take the release snapshot, form our reduced GNAP |
105 |
> snapshot (only supported profiles, unsupported USE flags masked, |
106 |
> unneeded ebuilds (X, desktop stuff) not in the tree) and support it for |
107 |
> some time security wise (like the releng team does during release). This |
108 |
> is more of a research topic, with informing what needs to be done, |
109 |
> writing of scripts, maybe doing a proof of concept (maintaining a |
110 |
> snapshot for some weeks to see how it works). |
111 |
|
112 |
|
113 |
-- |
114 |
gnap-dev@l.g.o mailing list |