* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 5:50 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 5:50 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 05:50:13
Added: ideas.xml
Log:
Initial skeleton for ideas page to host on our infra, which is hopefully more reliable than the wiki has been. (The wiki died this time last year and again this year.)
Revision Changes Path
1.1 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.1&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.1&content-type=text/plain
Index: ideas.xml
===================================================================
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="/xsl/guide.xsl" type="text/xsl"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide>
<title>Summer of Code ideas</title>
<author>dberkholz</author>
<abstract>This guide is intended to be read by anyone who is interested
in applying to Gentoo in the Google Summer of Code. Interested students
need not be Gentoo developers; anyone who meets the eligibility requirements of
Google is encouraged to apply.
</abstract>
<version>1.0</version>
<date>2011-03-19</date>
<chapter>
<title>Read this first</title>
<section>
<body>
<p>
<b>Most ideas listed here have a contact person associated with them. Please
get in touch with them earlier rather than later to develop your idea into a
complete application.</b> You can find many of them on Freenode's IRC network
under the same username. If there is no contact information, please join the
gentoo-soc mailing list or #gentoo-soc on the Freenode IRC network, and we
will work with you to find a mentor and discuss your idea.
</p>
<p>
You don't have to apply for one of these ideas! You can come up with your own,
and as long as it fits into Gentoo, we'll be happy to work with you to develop
it. Remember, your project needs to have deliverables in less than 3 months of
<b>full-time</b> work. Be ambitious but not too ambitious ;)
</p>
<p>
<b>Applications are not yet open</b> — the earlier the better, but don't rush
through it! We have a custom application template that we will ask you to fill
out. Here it is:
</p>
<p>
<b>Congratulations on applying for a project with Gentoo!</b> To improve your
chances of succeeding with this project, we want to make sure you're
sufficiently prepared to invest a full summer's worth of time on it. <b>In
addition to the usual application, there are 2 specific actions and 1 piece of
info we would like to see from you:</b>
</p>
<ul>
<li>
<b>Use the tools that you will use in your project to make changes to code</b>
(e.g., source code management [SCM] software such as CVS, Subversion, or
git). Please use the same SCM as you will use for your project to check out
one of our repositories (more repositories), make a change to it, and post
that change as a patch on a mailing list or bug. Please fix a real bug
reported in Bugzilla to show that you can use the tools to make a meaningful
change; your mentor can help you identify a good one. Your contact in Gentoo
can help you determine which SCM and repository you should use for this. If
your idea doesn't have a contact, please get in touch with us on the
gentoo-soc mailing list or in real-time on IRC at Freenode/#gentoo-soc. Once
you've made your change, link to it from your application.
</li>
<li>
<b>Participate in our development community.</b> Please make a post to one of
our mailing lists and link to it from your application (archives.gentoo.org
holds past postings). The gentoo-soc list would be a good starting point, if
you aren't subscribed to any others already. The best posts would be an
introduction of the project you're applying for and a little background about
you, to introduce yourself to the community and get some broader input about
your project.
</li>
<li>
<b>Give us your contact info and working hours.</b> Please provide your email
address, home mailing address, and phone number. This is a requirement and
provides for accountability on both your side and ours. Also, please tell us
what hours you will be working and responsive to contact via email and IRC;
these should sum to at least 35 hours a week.
</li>
</ul>
<p>
These actions are things you will do extremely commonly as an open-source developer, and they really aren't that hard, so don't let them hold you back! The remainder of the application is free-form. Please read our application guidelines and Google's FAQ to complete it. Good luck!
</p>
</body>
</section>
</chapter>
<chapter>
<title>Ideas</title>
<section>
<title>libbash runtime</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Ebuild QA checks based on libbash AST</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Kernel Security issue handling/notifications</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Package statistics reporting tool</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Porthole plug-ins and extensions</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Support for Fortran modules/libraries with multiple compilers</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Virtual Machine Builder (website or desktop client)</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Porthole backend re-structure</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>gentoo-x86 QA website</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Add "tags" support to Portage</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Add "mnemonic names" to Packages in metadata.xml</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Fastboot on Gentoo</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Systemd/Upstart on Gentoo</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Cache sync</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Improved binary package support</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>User Generated Content for Portage packages</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Automated numerical libraries benchmark suite</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>SCM snapshot management infrastructure</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>EBuild generator</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Maven integration</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Gentoo/Java IDE integration</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Rewrite java-config in C++ or python</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Web interface for submitting Documentation changes</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Package Manager Specification (PMS) compliance test suite</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Repository of self-contained ebuild source packages</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Make the clustering LiveCD from a previous GSoC bootable from USB</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>OpenBSD port of Gentoo</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Glendix: Create a lean distro based on Gentoo and Plan 9 (Glentoo?)</title>
<body>
<p>
</p>
</body>
</section>
<section>
<title>Provide Gentoo 11 LiveDVDs with Anaconda installer</title>
<body>
<p>
</p>
</body>
</section>
</chapter>
</guide>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:12 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:12 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:12:30
Modified: ideas.xml
Log:
Fill out structure from wiki ideas page.
Revision Changes Path
1.2 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.2&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.2&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.1&r2=1.2
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- ideas.xml 20 Mar 2011 05:50:13 -0000 1.1
+++ ideas.xml 20 Mar 2011 06:12:30 -0000 1.2
@@ -90,204 +90,529 @@
<section>
<title>libbash runtime</title>
<body>
-<p>
+<p>Libbash will enable programs to use Abstract Syntax Trees to parse bash commands directly instead of using regular expressions. This will be a great benefit to programs both outside and inside Gentoo, including Portage and repoman. Also, it will be a library that allows C++ to talk to bash (using this AST).
+</p>
+<p>Last year we started work on the libbash project. We got the grammar running, so this year the next step is to tackle the runtime parts. The existing code can be found here:
+<uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/libbash.git;a=summary">http://git.overlays.gentoo.org/gitweb/?p=proj/libbash.git;a=summary</uri>
</p>
+<p><b>Skills</b>:
+</p>
+<ul><li> C++
+</li><li> Antlr
+</li><li> Bash
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="betelgeuse@gentoo.org">Petteri Räty</mail>
+</li>
+</ul>
</body>
</section>
<section>
<title>Ebuild QA checks based on libbash AST</title>
<body>
-<p>
-</p>
+<p>From last year (see idea above) we have a working grammar to produce an AST for bash scripts, which allows us to programatically parse bash within non-bash programs (C++, Python, etc). Now that we are able to analyze bash scripts, the goal of this project is to start producing actual ebuild QA checks against the AST.
+</p><p><b>Skills</b>:
+</p>
+<ul><li> Antlr
+</li><li> Bash
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="betelgeuse@gentoo.org">Petteri Räty</mail>
+</li></ul>
</body>
</section>
<section>
<title>Kernel Security issue handling/notifications</title>
<body>
-<p>
-</p>
+<p>Kernels are not part of the normal Gentoo security advisory process because of the multitude of available kernel variants and versions.
+Instead of writing advisories for a group of issues, we rather want to tag each Kernel vulnerability with the information in what kernel version or what patchset version it is fixed.
+That's the purpose of the kernel-check tool which reads these tags and checks them against the used Kernel version on users' machines.
+</p><p>There is a Python implementation started at <uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git;a=tree">http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git;a=tree</uri> which still has some things that need to be done (see TODO).
+</p><p>We're looking for a student interested in finishing and long-term maintaining the tool as well as joining the Gentoo Security team for populating and updating fixed version information in the bugs in the future.
+</p><p><b>Skills</b>:
+</p>
+<ul><li> Python
+</li><li> Basic understanding of information security processes
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="a3li@gentoo.org">Alex Legler</mail> (<b>Also, you're encouraged to propose other projects related to improving security on Gentoo!</b>)
+</li></ul>
</body>
</section>
<section>
<title>Package statistics reporting tool</title>
<body>
-<p>
-</p>
+<p><b>Quick description:<br /></b>
+A user end program to upload anonymous information about installed packages on a users machine to a database that package maintainers and developers have access to. <br /><br />
+<uri link="http://blog.jolexa.net/2010/12/29/gentoo-a-critical-look-at-the-qa-process/">This post</uri> from planet Gentoo titled, 'Gentoo: A critical look at the QA process' suggests that it is difficult for maintainers to decide whether
+or not to mark a package as stable. The main issue being: if it's not marked as stable then users wont use it, and it's very difficult for maintainers to test the package properly on their own. This creates a blurring between ~arch and arch. If stable packages are left in ~arch for long periods of time, users will begin to use ~arch as if it were stable more often, which defeats the purpose of ~arch in the first place. If maintainers push packages into arch because it works on their machines but breaks on users due to the high number of different system setups this makes gentoo look unreliable, further blurring ~arch and arch. <br />
+Here are some reasons why this project would help Gentoo:<br />
+</p>
+<ul><li>Now developers can't see when users are happy with a package, only when they are not.
+</li><li>Finding incompatibilities between specific package versions
+</li><li>General user interest in specific packages to help trim down unused packages from portage.
+</li></ul>
+<p><b>Skills</b>
+</p>
+<ul><li>A programming language and GUI toolkit<br />
+</li><li>Understanding of databases and SQL.<br />
+</li><li>Understanding of portage
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="chris@basementcode.com">Christopher Harvey</mail>
+</li></ul>
</body>
</section>
<section>
<title>Porthole plug-ins and extensions</title>
<body>
-<p>
-</p>
+<p>Porthole is a GTK+-based frontend to Portage. This project would enable Porthole to improve its ability to manage remote computers, gather and report package statistics, and more. The work would encompass creating:
+</p>
+<ul><li>A basic python based control interface API for linking to remote computers and groups of computers to gather information about installed packages, and install/update those using portage and/or pkgcore as remote backends.
+</li></ul>
+<ul><li>Extending the work started in the public_api branch of portage to include running emerge via the public api.
+</li></ul>
+<ul><li>Create a simple cli for gathering/reporting update info for #1
+</li></ul>
+<ul><li>Create a porthole plug-in for connecting to the control interface, displaying the info in portholes views and and dispatching desired actions to the remotes via the control interface.
+</li></ul>
+<p><b>Skills</b>:
+</p>
+<ul><li> python
+</li><li> gtk+, pygtk
+</li><li> ssh
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="brian.dolbec@gmail.com">Brian Dolbec <dolsen></mail>
+</li></ul>
</body>
</section>
<section>
<title>Support for Fortran modules/libraries with multiple compilers</title>
<body>
-<p>
-</p>
+<p>Fortran modules and libraries are highly compiler dependent. Even minor version
+change in gfortran renders them incompatible. However, we are often forced to work
+with multiple compilers at the same time (e.g. scientific software development).
+The project aim is to create a Fortran framework that would allow to install concurrent
+versions of Fortran binaries in a PMS (Package Manager Specification)-aware fashion, along with a configuration module for eselect to rule them all.
+</p><p><b>Skills</b>:
+</p>
+<ul><li> shell scripting, compilers, python
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li> <mail link="xarthisius@gentoo.org">Kacper Kowalik</mail>
+</li></ul>
+<p>Refs:
+</p>
+<ul><li> <uri link="http://dberkholz.com/2010/12/02/linux-problems-you-never-considered-handling-fortran90-modules-for-multiple-compilers/">Linux problems you never considered handling - Fortran90 modules for multiple compilers</uri> (Donnie's Berkholz blog post)
+</li></ul>
</body>
</section>
<section>
<title>Virtual Machine Builder (website or desktop client)</title>
<body>
-<p>
-</p>
+<p>The idea is to implement a user interface to build a on-demand modular Virtual Machine image operating system based on Gentoo. The VM could be tuned for a number of pre-defined profiles, such as High Performance Computing modern architectures, Gentoo testing tinderboxes, desktops,... It could be based on any of existing tools such as virt-mananager.
+</p><p>This could be a Web-based or desktop-based tool, depending on your analysis of the requirements while working with the mentor.
+</p><p><b>Skills</b>:
+</p>
+<ul><li> virtualization, interface design, scripting, low-level operating system
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li> <mail link="bicatali@gentoo.org">Sebastien Fabbro</mail>
+</li></ul>
</body>
</section>
<section>
<title>Porthole backend re-structure</title>
<body>
-<p>
+<p>Porthole is a GTK+-based frontend to Portage. This is to work at developing a new backend structure to use a new public API for Portage. With this, Porthole could run emerge processes from the imported Portage code. Once the basic restructuring is completed, begin creating a new pkgcore based backend that can be used as an alternate package manager.
</p>
+<p><b>Skills</b>:
+</p>
+<ul><li>python, connecting python processes via pipes for data/command exchange so one process can run unprivileged, the other privileged.
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="brian.dolbec@gmail.com">Brian Dolbec <dol-sen></mail>
+</li></ul>
</body>
</section>
<section>
<title>gentoo-x86 QA website</title>
<body>
-<p>
-</p>
+<p>The idea is simple enough, take the QA results from various tools and present it via a searchable website. Think <uri link="http://packages.gentoo.org/">packages.gentoo.org</uri>, just for QA results. The implementation work required would primarily be building the website itself- the user could rely upon pkgcore-checks for the initial data stream (it can output it's results as a pickle stream) leaving the candidate to focus on generating a site providing insight into the status of current architectures, current stabling, etc.
+</p><p>One additional constraint would be that the underlying DB schema should be written in a fashion that allows multiple data imports to be used- while pkgcore-checks right now can provide data for a candidate to work with, the candidate should be designing a system also able to pull in other data sources (at some point repoman for example).
+</p><p>Finally, an additional feature could be designing the underlying schema and website to allow for the possibility of being able to handle multiple repositories- think about if the gnome herd wanted their overlay to be scanned/accessible. This complicates the design a bit (specifically keeping it fast), but is likely to be desired functionality down the line.
+</p><p>The relevant gentoo-soc discussion (with a bit more details) is accessible on <uri link="http://archives.gentoo.org/gentoo-soc/msg_474d9ffb2fde05a9fb8ff032cac58622.xml">in the gentoo-soc archives</uri>
+</p><p><b>Skills</b>:
+</p>
+<ul><li> python (data importation)
+</li><li> web frameworks- this includes some html/css/JS knowledge, depending on how complex the candidate wishes to make the site
+</li><li> RDBMs schema design.
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="ferringb@gmail.com">Brian Harring; contact for code/frameworks/overall</mail>
+</li><li><mail link="mr_bones_@gentoo.org">Michael Sterret; contact for feedback on useful views, currently does something similar to this manually</mail>
+</li></ul>
</body>
</section>
<section>
<title>Add "tags" support to Portage</title>
<body>
-<p>
-</p>
+<p>Gentoo uses categories now. A package can only be in a single category, which is very limiting because generally things don't fit perfectly into one place without other possibilities. Tags could make it a lot easier to find packages they're looking for by doing Boolean searches like: kde AND mail. This project would add support for tags to Portage and would allow for backwards compatibility of categories as tags.
+</p><p><b>Note</b>: This project in its current form is considered trivial and not suitable for a complete SoC project <uri link="http://archives.gentoo.org/gentoo-soc/msg_f082a4346ffc9578948ce2f987a80465.xml">[1]</uri>. If you wish to work on this, you should expand the scope of the work significantly.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Python
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li>Your name here.
+</li></ul>
</body>
</section>
<section>
<title>Add "mnemonic names" to Packages in metadata.xml</title>
<body>
-<p>
-</p>
+<p>Gentoo package names are ugly, not suited for shiny Graphical User Interfaces. It would be good enough to add a new field to metadata.xml that exposes a more user friendly "application name". For example, media-sound/amarok could get in metadata.xml an application name like "Amarok, the music player". Moreover, this "mnemonic name" should be used in repository queries matching.
+</p><p><b>Note</b>: This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Portage, Python, XML
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="lxnay@gentoo.org">Fabio Erculiani</mail>
+</li></ul>
</body>
</section>
<section>
<title>Fastboot on Gentoo</title>
<body>
-<p>
-</p>
+<p>Recently, some kernel developers working at Intel got boot times on solid-state drives down to 5 seconds (10 on hard drive). It would be awesome to have this in Gentoo. This would require significant changes to our custom init system, OpenRC, as well as lots of profiling of the kernel boot and userspace boot processes using tools like <uri link="http://www.bootchart.org/">bootchart</uri>. <uri link="http://moblin.org/projects/fast-boot">More info about fastboot is here</uri>. Note that the work of fastboot was primarily concerned with:
+</p>
+<ol><li>sreadahead, for which there already are packages in the tree, and
+</li><li>optimizing the init system (which might be a bit tough for OpenRC).
+</li><li>optimizing the services in the init system (easier)
+</li><li>asynchronous kernel function calling (in 2.6.29)
+</li><li>speeding up loading of the desktop environment (early GDM start, profiling etc)
+</li></ol>
+<p><b>NOTE</b>: There have been a large number of applicants for this idea, and a lot of discussions about this on the <uri link="http://archives.gentoo.org/gentoo-soc/">mailing list archives</uri>. Because of this, we have decided to <b>raise the bar for this idea</b>. Applicants expecting to get selected should show us their capability by plucking some of the low-hanging fruit (aka, easy fixes) in the boot process. Show us the code.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Shell scripting, C
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="nirbheek@gentoo.org">Nirbheek Chauhan</mail> (Got far too excited after reading the <uri link="http://lwn.net/Articles/299483/">LWN article</uri>)
+</li></ul>
</body>
</section>
<section>
<title>Systemd/Upstart on Gentoo</title>
<body>
-<p>
-</p>
+<p>Related to the Fastboot objectives, it has been suggested that new init daemons, Systemd and/or Upstart, could be modified to support the Gentoo init.d scripts. Our init scripts already provide nearly all the same metadata required for upstart scripts. This would enable drop-in use of either init daemon on Gentoo, without rewriting any init.d scripts. It would/could be used in conjunction with OpenRC, and not be a replacement for OpenRC. This will require modifications to both OpenRC (so it can use either SystemV init or upstart/systemd) and the init daemon itself.
+</p><p>Before applying for systemd, please check the status of <uri link="https://bugs.gentoo.org/show_bug.cgi?id=318365#c141">bug #318365</uri>, where much of the discussion on doing this work has occurred.
+</p><p><b>Skills</b>:
+</p>
+<ul><li> Shell scripting, C
+</li><li> A solid understanding of Gentoo init.d scripts.
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="steev@gentoo.org">Steev Klimaszewski</mail>
+</li><li><mail link="robbat2@gentoo.org">Robin H. Johnson</mail>
+</li></ul>
</body>
</section>
<section>
<title>Cache sync</title>
<body>
-<p>
-</p>
+<p>The portage tree and all its overlays keep growing. Right now only the official portage tree occupies more than 600Mb on a regular filesystem. However the package manager does not need the whole tree of full ebuilds, patches and manifests to perform most of its work. The idea would be to sync a smaller database or a cache of only needed information for global package manager operations, then fetch the required package only when needed. It would speed considerably tree synchronization and reduce the space occupied by portage tree (see the <uri link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas#Repository_of_Self-Contained_Ebuild_Source_Packages">"Repository of Self-Contained Ebuild Source Packages"</uri> idea for an alternative approach). Currently the cache system in portage is also really slow and so is the search feature. The project could be inspired by the Debian or RPM system but with the usability and choices offered by Gentoo, and would probably
include:
+</p>
+<ul><li> design and implement automatic cache builder to be produced by a given repository/overlay
+</li><li> make portage/paludis/pkgcore to do delta-sync with a local cache and fetch only the required files to be installed when requested
+</li></ul>
+<p><b>Skills</b>:
+</p>
+<ul><li>Python (portage/pkgcore) or C++ (paludis)
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li>Your name here.
+</li></ul>
</body>
</section>
<section>
<title>Improved binary package support</title>
<body>
<p>
-</p>
+Gentoo better for derived binary distros. One of them is more intelligent handling of library versions with binpkgs (and installed packages, which are a form of binpkg). For example, it's possible to build a binpkg against an old version of a library, then install it against a new version and have it be broken by default because of a shared-library version bump. It's also possible to break reverse ABI dependencies when upgrading a package, and there is currently no convenient way for package managers to detect such breakage in advance. Ideally, a package would have a way to specify its ABI dependencies in the <b>built</b> state instead of just which versions it can build against from <b>source</b>. It is possible to create an ABI dependency abstraction that is flexible enough to cover all possible kinds of ABI dependencies. Using an ABI abstraction, it will not matter whether or not there exists a specific soname to be referenced by dependencies. See <uri link="https://bugs.
gentoo.org/192319">bug #192319</uri>.
+</p><p>Another problem is saving binpkgs with different USE flag and other build settings on the same host. See <uri link="https://bugs.gentoo.org/150031">bug #150031</uri>. The way forward is one or more hashes of the metadata. A third problem is the lack of binpkg support for the kernel. This could be changed through modifying the kernel eclass to support a binary USE flag that also did configuration & build, or perhaps some kind of genkernel modification, or both. See <uri link="https://bugs.gentoo.org/154495">bug #154495</uri>.
+</p><p>Two other minor problems:
+</p>
+<ul><li> Compilation related messages are thrown to user when installing a binary package. This <b>should be avoided</b> somehow. Bad developers habit.
+</li><li> It would be nice to have elog output stored in /var/db for later consumption and perhaps, have it embedded in xpak metadata. This would improve PackageKit support, which doesn't allow any output from package phases during install.
+</li></ul>
+<p><b>Note</b>: base binary kernel ebuilds and eclasses are available in the "sabayon" overlay and its maintainer would like to apply to this part of the task.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Python, shell scripting
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="zmedico@gentoo.org">Zac Medico</mail>
+</li></ul>
</body>
</section>
<section>
<title>User Generated Content for Portage packages</title>
<body>
-<p>
-</p>
+<p>It would be nice to port the User Generated Content infrastructure used in Sabayon to Gentoo. It's actually a bunch of well-tested SQL tables a set of API that can work over a simple, perhaps Python-based, web service. A minimal effort is also required client-side, to implement the client API that could suit the Portage codebase. This could couple with <b>Package statistics reporting tool</b> listed above
+</p><p><b>Example of how it works</b>: <uri link="http://packages.sabayon.org">Sabayon "Entropy Store"</uri>
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Python, Web services development, JSON, HTTP and Web skills
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="lxnay@gentoo.org">Fabio Erculiani</mail> (who would like to apply as "student")
+</li></ul>
</body>
</section>
<section>
<title>Automated numerical libraries benchmark suite</title>
<body>
-<p>
-</p>
+<p>Quite a few numerical libraries are available in Gentoo (BLAS, LAPACK, FFTW,...), and some of them offered in different implementations. The work would consist on implementing a benchmark suite and an automated mechanism to test numerical libraries on Gentoo for bugs, correctness and speed. That is for any combination of compilers, compiler and USE flags, versions, and dependencies. It could rely on existing or future eselect framework.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Shell scripting, packaging, compilers, C/Fortran and numerical libraries knowledge.
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="bicatali@gentoo.org">Sébastien Fabbro</mail>
+</li></ul>
</body>
</section>
<section>
<title>SCM snapshot management infrastructure</title>
<body>
-<p>
-</p>
+<p>A growing number of projects provide binary-only releases of their packages with
+the source available only as a tag in a version control system. This presents
+obvious problems for source-based distributions, as we must provide one of two
+possible solutions:
+</p>
+<ul><li> live ebuilds, which pull the tag directly, making them vulnerable to a single point of failure (the upstream SCM server) and the possibility of upstream altering the tagged contents, as well as possibly placing an excess load on the upstream servers; or
+</li></ul>
+<ul><li> snapshots, which must be pulled and manually packaged by a developer and hosted on Gentoo infrastructure. Snapshot archives are often not reproducible bit-for-bit and do not have upstream's direct "blessing".
+</li></ul>
+<note><b>Note:</b> there's a third solution, which is to copy the scm tree and provide our own.</note>
+<p>This project would implement a Gentoo snapshot management infrastructure (an extension of Gentoo's existing mirror infrastructure) to provide a better alternative. The process would be:
+</p>
+<ul><li> The ebuild writer specifies a scm url and tag
+</li></ul>
+<ul><li> If the writer has no access (the ebuild is not uploaded to main tree or a listed overlay), the ebuild behaves as a live ebuild.
+</li></ul>
+<ul><li> Otherwise, the snapshot manager daemon packages the snapshot and posts it on Gentoo mirrors. The ebuild fetches the snapshot and uses it. (this will require a manifest update upon/after commit...)
+</li></ul>
+<ul><li> The snapshot manager daemon periodically checks the sources of all snapshots for changes that would alter the contents of the snapshot. It alerts the ebuilds' authors to any such changes.
+</li></ul>
+<p>The coding part would involve writing the aforementioned daemon. The mentor would have to be someone from infra, or at least the student would be interacting with infra a lot.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Likely Python or shell scripting
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="lu_zero@gentoo.org">Luca Barbato</mail>
+</li></ul>
</body>
</section>
<section>
<title>EBuild generator</title>
<body>
-<p>
-</p>
+<p>It would be great if we had a simple tool to generate ebuilds for the most straightforward packages and build systems. For the basics, writing an ebuild could be a Python-based GUI to get stuff like dependencies and some common code blocks in there. One attempt to create such a tool was <uri link="http://abeni.sourceforge.net/">Abeni</uri>.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Python
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li>? (Your name here)
+</li></ul>
</body>
</section>
<section>
<title>Maven integration</title>
<body>
-<p>
-</p>
+<p>Be able to easily write ebuilds for projects using Maven, a popular build system for Java projects.
+</p><p>The goal of this project is to be easily able to write ebuilds for
+upstream projects that use Maven as the build system. The work can
+either be finishing the work started in java-overlay or a new approach.
+</p><p><b>Skills:</b>
+</p>
+<ul><li> Maven
+</li><li> basic Gentoo/Java understading
+</li></ul>
+<p><b>Contacts:</b>
+</p>
+<ul><li><mail link="betelgeuse@gentoo.org">Petteri Räty</mail>
+</li></ul>
</body>
</section>
<section>
<title>Gentoo/Java IDE integration</title>
<body>
-<p>
-</p>
+<p>Be able to easily work with system libraries in IDEs.
+</p><p>Fix Netbeans or Eclipse so that they are easily able to find system
+installed libraries and their javadocs. Potentially work with PackageKit so that the system libraries could automatically be installed based in imports etc.
+</p><p><b>Skills:</b>
+</p>
+<ul><li> Java
+</li><li> basic Gentoo/Java understading
+</li></ul>
+<p><b>Contacts:</b>
+</p>
+<ul><li><mail link="betelgeuse@gentoo.org">Petteri Räty</mail>
+</li><li><mail link="serkan@gentoo.org">Serkan Kaba</mail>
+</li></ul>
</body>
</section>
<section>
<title>Rewrite java-config in C++ or python</title>
<body>
-<p>
-</p>
+<p>Gentoo's tool for switching between Java versions and implementations, java-config, needs love. It could use a lot of new features and even a rewrite, as it has a lot of legacy from the generation 1 days.
+</p><p>We could drop the need of python for the Gentoo/Java tools if this is written
+in C++ but python can also be acceptable. Ideally the need for external libraries
+is kept to minimum.
+</p><p><b>Skills:</b>
+</p>
+<ul><li> XML transformations
+</li><li> basic Gentoo/Java understanding
+</li></ul>
+<p><b>Contacts:</b>
+</p>
+<ul><li><mail link="betelgeuse@gentoo.org">Petteri Räty</mail>
+</li></ul>
</body>
</section>
<section>
<title>Web interface for submitting Documentation changes</title>
<body>
-<p>
-</p>
+<p>People are often intimated by XML, and finding the "source code" to the documentation can be painful for people. So having a user interface to our documentation would help out a lot with contributions.
+</p><p>Workflow would be something like:
+</p>
+<ul><li> person visits documentation page
+</li><li> person notices a mistake
+</li><li> person clicks an embedded "edit" link
+</li><li> person makes the correction and hits "save"
+</li><li> proposed correction is sent to gentoo-doc mailing list
+</li></ul>
+<p>Sending to the mailing list would be the easiest way to integrate with current infrastructure and wouldn't require the person to create a bugzilla account just to submit a suggestion.
+</p>
</body>
</section>
<section>
<title>Package Manager Specification (PMS) compliance test suite</title>
<body>
-<p>
-</p>
+<p>Right now there is no way to validate that a pkg manager implementation is compliant w/ what the Package Manager Specification (PMS) specifies, nor any way to track what affects a spec change may have on the various managers w/out testing each.
+</p><p>The idea is simple enough; write a test suite that allows for plugging a package manager into it (whether it be portage, pkgcore, or paludis) and verifying PMS compliance. Most likely this would take the form of custom ebuild trees the package manager is told to operate on, but other approaches may exist.
+</p><p><b>Skills</b>:
+</p>
+<ul><li> dynamic language of some sort for the test harness, and potential test case generation
+</li><li> bash
+</li><li> close attention to detail (this is implementing tests for spec compliance after all)
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="ferringb@gmail.com">Brian Harring</mail>
+</li></ul>
</body>
</section>
<section>
<title>Repository of self-contained ebuild source packages</title>
<body>
-<p>
-</p>
+<p>This proposal is similar in scope to the <uri link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas#Cache_sync">Cache sync</uri> proposal, except that it will focus on implementing support for repositories that host self-contained ebuild source packages that are analogous to source RPMs (SRPMs). The repository layout will be similar to existing PORTAGE_BINHOST repositories (like those hosted at <uri link="http://tinderbox.dev.gentoo.org/default-linux/x86/">tinderbox.dev.gentoo.org</uri>), and will include a metadata index file which is similar to <uri link="http://tinderbox.dev.gentoo.org/default-linux/x86/Packages">$PKGDIR/Packages</uri>. Each source package hosted in the repository will contain a single ebuild, its metadata, and all files it requires from the portage tree (including all inherited eclasses and any additional files such as patches from the files directory). A zip file will be a suitable container for one of these source packages.
+</p><p>A synchronization script will generate source packages from a source portage tree (or overlay), and it will avoid unnecessary regeneration of a given source package in cases when no relevant files have changed timestamps or been added/removed. This script will be run as often as the repository maintainer wants to synchronize with the source tree.
+</p><p>The syncronization script will have an option to preserve source packages that no longer exist in the source tree, perhaps updating such packages if they happen to contain outdated versions of eclasses. The ability to retain packages that no longer exist in the source tree may be useful for some cases of the stable tree idea which was proposed in <uri link="http://www.gentoo.org/proj/en/glep/glep-0019.html">GLEP 19</uri>.
+</p><p>In order to ensure that repository updates do not interfere with clients, it may be desirable to publish the repository as a series of snapshots that are contained in directories which are named corresponding to snapshot date/time. This will ensure that a previous snapshot is still accessible when a newer snapshot becomes available. So, clients will never have any trouble downloading a specific source package that corresponds to a metadata index which was downloaded earlier and used for a dependency calculation. Without some kind of snapshot mechanism like this (similar to <uri link="http://en.wikipedia.org/wiki/Read-copy-update">RCU</uri>), a race condition would exist such that dependency calculations would be somewhat unreliable, and downloaded source packages might have different checksums and dependencies from those listed in a metadata index that was downloaded only a minute earlier.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Python (portage/pkgcore) or C++ (paludis)
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="zmedico@gentoo.org">Zac Medico</mail>
+</li></ul>
</body>
</section>
<section>
<title>Make the clustering LiveCD from a previous GSoC bootable from USB</title>
<body>
-<p>
-</p>
+<p>The clustering LiveCD is a bootable image that allows you to instantly turn a full room of computers into a functional cluster. You only need one CD because the rest of the nodes boot disklessly from the master node with the CD. This project would be a huge improvement to the existing version because it will allow us to use persistent, writable USB media instead of a read-only CD. That means clusters won't need to be reconfigured from scratch on every boot. That will save a lot of admin time on each boot and make it possible to do things like run a cluster in 10 different computer labs with different settings on each, as easily as inserting 1 USB stick in each lab and rebooting all the computers.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Shell scripting, maybe some Python
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="kyron@neuralbs.com">Eric Thibodeau</mail>
+</li></ul>
</body>
</section>
<section>
<title>OpenBSD port of Gentoo</title>
<body>
-<p>
-</p>
+<p>The OpenBSD port is dead. This project would involve investigating and implementing the necessary porting work to get a Gentoo userland running on a BSD kernel and base system (the base system is also managed by Gentoo).
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Shell scripting, C (patch creation)
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li> <mail link="patrick@gentoo.org">Patrick Lauer</mail>
+</li></ul>
</body>
</section>
<section>
<title>Glendix: Create a lean distro based on Gentoo and Plan 9 (Glentoo?)</title>
<body>
-<p>
-</p>
+<p><uri link="http://www.glendix.org/">Glendix</uri> is a port of the Plan 9 userspace to the Linux kernel. In its current state it is just a set of patches to the Linux kernel to make sure Plan 9 binaries are able to run unmodified. However, in order to bring the entire Plan 9 userspace experience to Linux, we need a lightweight Linux distribution that packages all of this nicely. Gentoo provides us a great base for this because of it's customizability.
+</p><p>The objective of this project would be to create a LiveCD based on Gentoo and Glendix, providing the end user with a nice experience of Linux with a non-GNU (namely Plan 9) userspace.
+</p><p><b>Skills</b>:
+</p>
+<ul><li><uri link="http://www.gentoo.org/proj/en/releng/catalyst/index.xml">Catalyst</uri>
+</li><li>Likely Shell Scripting
+</li><li>General knowledge of how a Linux distro is put together, what the init process is and so on
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="anant@kix.in">Anant Narayanan</mail>
+</li></ul>
</body>
</section>
<section>
<title>Provide Gentoo 11 LiveDVDs with Anaconda installer</title>
<body>
-<p>
-</p>
+<p><uri link="http://www.sabayon.org/">Sabayon</uri> is maintaining an Anaconda Installer snapshot from Fedora in their git repositories. It would be nice to have it assimilated in Gentoo and provide quick-install features to our users too.
+</p><p><b>Skills</b>:
+</p>
+<ul><li>Python
+</li><li>Shell Scripting
+</li><li>Ebuild writing
+</li></ul>
+<p><b>Contacts</b>:
+</p>
+<ul><li><mail link="lxnay@gentoo.org">Fabio Erculiani</mail>
+</li></ul>
</body>
</section>
</chapter>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:24 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:24 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:24:57
Modified: ideas.xml
Log:
To improve quick navigation, reformat so each idea is a chapter rather than a section.
Revision Changes Path
1.3 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.3&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.3&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.2&r2=1.3
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ideas.xml 20 Mar 2011 06:12:30 -0000 1.2
+++ ideas.xml 20 Mar 2011 06:24:57 -0000 1.3
@@ -88,7 +88,19 @@
<chapter>
<title>Ideas</title>
<section>
+<body>
+<p>
+Our suggestions for project ideas are below. Please feel free to propose your
+own ideas; those are often among our favorites! You can find an easily
+browseable ideas listing in the Content dropdown at the top of the page.
+</p>
+</body>
+</section>
+</chapter>
+
+<chapter>
<title>libbash runtime</title>
+<section>
<body>
<p>Libbash will enable programs to use Abstract Syntax Trees to parse bash commands directly instead of using regular expressions. This will be a great benefit to programs both outside and inside Gentoo, including Portage and repoman. Also, it will be a library that allows C++ to talk to bash (using this AST).
</p>
@@ -108,8 +120,11 @@
</ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Ebuild QA checks based on libbash AST</title>
+<section>
<body>
<p>From last year (see idea above) we have a working grammar to produce an AST for bash scripts, which allows us to programatically parse bash within non-bash programs (C++, Python, etc). Now that we are able to analyze bash scripts, the goal of this project is to start producing actual ebuild QA checks against the AST.
</p><p><b>Skills</b>:
@@ -123,8 +138,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Kernel Security issue handling/notifications</title>
+<section>
<body>
<p>Kernels are not part of the normal Gentoo security advisory process because of the multitude of available kernel variants and versions.
Instead of writing advisories for a group of issues, we rather want to tag each Kernel vulnerability with the information in what kernel version or what patchset version it is fixed.
@@ -142,8 +160,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Package statistics reporting tool</title>
+<section>
<body>
<p><b>Quick description:<br /></b>
A user end program to upload anonymous information about installed packages on a users machine to a database that package maintainers and developers have access to. <br /><br />
@@ -167,8 +188,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Porthole plug-ins and extensions</title>
+<section>
<body>
<p>Porthole is a GTK+-based frontend to Portage. This project would enable Porthole to improve its ability to manage remote computers, gather and report package statistics, and more. The work would encompass creating:
</p>
@@ -192,15 +216,21 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Support for Fortran modules/libraries with multiple compilers</title>
+<section>
<body>
-<p>Fortran modules and libraries are highly compiler dependent. Even minor version
-change in gfortran renders them incompatible. However, we are often forced to work
-with multiple compilers at the same time (e.g. scientific software development).
-The project aim is to create a Fortran framework that would allow to install concurrent
-versions of Fortran binaries in a PMS (Package Manager Specification)-aware fashion, along with a configuration module for eselect to rule them all.
-</p><p><b>Skills</b>:
+<p>Fortran modules and libraries are highly compiler dependent. Even minor
+version change in gfortran renders them incompatible. However, we are often
+forced to work with multiple compilers at the same time (e.g. scientific
+software development). The project aim is to create a Fortran framework that
+would allow to install concurrent versions of Fortran binaries in a PMS
+(Package Manager Specification)-aware fashion, along with a configuration
+module for eselect to rule them all. </p>
+
+<p><b>Skills</b>:
</p>
<ul><li> shell scripting, compilers, python
</li></ul>
@@ -214,8 +244,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Virtual Machine Builder (website or desktop client)</title>
+<section>
<body>
<p>The idea is to implement a user interface to build a on-demand modular Virtual Machine image operating system based on Gentoo. The VM could be tuned for a number of pre-defined profiles, such as High Performance Computing modern architectures, Gentoo testing tinderboxes, desktops,... It could be based on any of existing tools such as virt-mananager.
</p><p>This could be a Web-based or desktop-based tool, depending on your analysis of the requirements while working with the mentor.
@@ -229,8 +262,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Porthole backend re-structure</title>
+<section>
<body>
<p>Porthole is a GTK+-based frontend to Portage. This is to work at developing a new backend structure to use a new public API for Portage. With this, Porthole could run emerge processes from the imported Portage code. Once the basic restructuring is completed, begin creating a new pkgcore based backend that can be used as an alternate package manager.
</p>
@@ -244,8 +280,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>gentoo-x86 QA website</title>
+<section>
<body>
<p>The idea is simple enough, take the QA results from various tools and present it via a searchable website. Think <uri link="http://packages.gentoo.org/">packages.gentoo.org</uri>, just for QA results. The implementation work required would primarily be building the website itself- the user could rely upon pkgcore-checks for the initial data stream (it can output it's results as a pickle stream) leaving the candidate to focus on generating a site providing insight into the status of current architectures, current stabling, etc.
</p><p>One additional constraint would be that the underlying DB schema should be written in a fashion that allows multiple data imports to be used- while pkgcore-checks right now can provide data for a candidate to work with, the candidate should be designing a system also able to pull in other data sources (at some point repoman for example).
@@ -264,8 +303,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Add "tags" support to Portage</title>
+<section>
<body>
<p>Gentoo uses categories now. A package can only be in a single category, which is very limiting because generally things don't fit perfectly into one place without other possibilities. Tags could make it a lot easier to find packages they're looking for by doing Boolean searches like: kde AND mail. This project would add support for tags to Portage and would allow for backwards compatibility of categories as tags.
</p><p><b>Note</b>: This project in its current form is considered trivial and not suitable for a complete SoC project <uri link="http://archives.gentoo.org/gentoo-soc/msg_f082a4346ffc9578948ce2f987a80465.xml">[1]</uri>. If you wish to work on this, you should expand the scope of the work significantly.
@@ -279,8 +321,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Add "mnemonic names" to Packages in metadata.xml</title>
+<section>
<body>
<p>Gentoo package names are ugly, not suited for shiny Graphical User Interfaces. It would be good enough to add a new field to metadata.xml that exposes a more user friendly "application name". For example, media-sound/amarok could get in metadata.xml an application name like "Amarok, the music player". Moreover, this "mnemonic name" should be used in repository queries matching.
</p><p><b>Note</b>: This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.
@@ -294,8 +339,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Fastboot on Gentoo</title>
+<section>
<body>
<p>Recently, some kernel developers working at Intel got boot times on solid-state drives down to 5 seconds (10 on hard drive). It would be awesome to have this in Gentoo. This would require significant changes to our custom init system, OpenRC, as well as lots of profiling of the kernel boot and userspace boot processes using tools like <uri link="http://www.bootchart.org/">bootchart</uri>. <uri link="http://moblin.org/projects/fast-boot">More info about fastboot is here</uri>. Note that the work of fastboot was primarily concerned with:
</p>
@@ -316,8 +364,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Systemd/Upstart on Gentoo</title>
+<section>
<body>
<p>Related to the Fastboot objectives, it has been suggested that new init daemons, Systemd and/or Upstart, could be modified to support the Gentoo init.d scripts. Our init scripts already provide nearly all the same metadata required for upstart scripts. This would enable drop-in use of either init daemon on Gentoo, without rewriting any init.d scripts. It would/could be used in conjunction with OpenRC, and not be a replacement for OpenRC. This will require modifications to both OpenRC (so it can use either SystemV init or upstart/systemd) and the init daemon itself.
</p><p>Before applying for systemd, please check the status of <uri link="https://bugs.gentoo.org/show_bug.cgi?id=318365#c141">bug #318365</uri>, where much of the discussion on doing this work has occurred.
@@ -333,8 +384,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Cache sync</title>
+<section>
<body>
<p>The portage tree and all its overlays keep growing. Right now only the official portage tree occupies more than 600Mb on a regular filesystem. However the package manager does not need the whole tree of full ebuilds, patches and manifests to perform most of its work. The idea would be to sync a smaller database or a cache of only needed information for global package manager operations, then fetch the required package only when needed. It would speed considerably tree synchronization and reduce the space occupied by portage tree (see the <uri link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas#Repository_of_Self-Contained_Ebuild_Source_Packages">"Repository of Self-Contained Ebuild Source Packages"</uri> idea for an alternative approach). Currently the cache system in portage is also really slow and so is the search feature. The project could be inspired by the Debian or RPM system but with the usability and choices offered by Gentoo, and would probably
include:
</p>
@@ -351,8 +405,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Improved binary package support</title>
+<section>
<body>
<p>
Gentoo better for derived binary distros. One of them is more intelligent handling of library versions with binpkgs (and installed packages, which are a form of binpkg). For example, it's possible to build a binpkg against an old version of a library, then install it against a new version and have it be broken by default because of a shared-library version bump. It's also possible to break reverse ABI dependencies when upgrading a package, and there is currently no convenient way for package managers to detect such breakage in advance. Ideally, a package would have a way to specify its ABI dependencies in the <b>built</b> state instead of just which versions it can build against from <b>source</b>. It is possible to create an ABI dependency abstraction that is flexible enough to cover all possible kinds of ABI dependencies. Using an ABI abstraction, it will not matter whether or not there exists a specific soname to be referenced by dependencies. See <uri link="https://bugs.
gentoo.org/192319">bug #192319</uri>.
@@ -373,8 +430,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>User Generated Content for Portage packages</title>
+<section>
<body>
<p>It would be nice to port the User Generated Content infrastructure used in Sabayon to Gentoo. It's actually a bunch of well-tested SQL tables a set of API that can work over a simple, perhaps Python-based, web service. A minimal effort is also required client-side, to implement the client API that could suit the Portage codebase. This could couple with <b>Package statistics reporting tool</b> listed above
</p><p><b>Example of how it works</b>: <uri link="http://packages.sabayon.org">Sabayon "Entropy Store"</uri>
@@ -388,8 +448,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Automated numerical libraries benchmark suite</title>
+<section>
<body>
<p>Quite a few numerical libraries are available in Gentoo (BLAS, LAPACK, FFTW,...), and some of them offered in different implementations. The work would consist on implementing a benchmark suite and an automated mechanism to test numerical libraries on Gentoo for bugs, correctness and speed. That is for any combination of compilers, compiler and USE flags, versions, and dependencies. It could rely on existing or future eselect framework.
</p><p><b>Skills</b>:
@@ -402,8 +465,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>SCM snapshot management infrastructure</title>
+<section>
<body>
<p>A growing number of projects provide binary-only releases of their packages with
the source available only as a tag in a version control system. This presents
@@ -436,8 +502,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>EBuild generator</title>
+<section>
<body>
<p>It would be great if we had a simple tool to generate ebuilds for the most straightforward packages and build systems. For the basics, writing an ebuild could be a Python-based GUI to get stuff like dependencies and some common code blocks in there. One attempt to create such a tool was <uri link="http://abeni.sourceforge.net/">Abeni</uri>.
</p><p><b>Skills</b>:
@@ -450,8 +519,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Maven integration</title>
+<section>
<body>
<p>Be able to easily write ebuilds for projects using Maven, a popular build system for Java projects.
</p><p>The goal of this project is to be easily able to write ebuilds for
@@ -468,8 +540,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Gentoo/Java IDE integration</title>
+<section>
<body>
<p>Be able to easily work with system libraries in IDEs.
</p><p>Fix Netbeans or Eclipse so that they are easily able to find system
@@ -486,8 +561,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Rewrite java-config in C++ or python</title>
+<section>
<body>
<p>Gentoo's tool for switching between Java versions and implementations, java-config, needs love. It could use a lot of new features and even a rewrite, as it has a lot of legacy from the generation 1 days.
</p><p>We could drop the need of python for the Gentoo/Java tools if this is written
@@ -504,8 +582,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Web interface for submitting Documentation changes</title>
+<section>
<body>
<p>People are often intimated by XML, and finding the "source code" to the documentation can be painful for people. So having a user interface to our documentation would help out a lot with contributions.
</p><p>Workflow would be something like:
@@ -520,8 +601,11 @@
</p>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Package Manager Specification (PMS) compliance test suite</title>
+<section>
<body>
<p>Right now there is no way to validate that a pkg manager implementation is compliant w/ what the Package Manager Specification (PMS) specifies, nor any way to track what affects a spec change may have on the various managers w/out testing each.
</p><p>The idea is simple enough; write a test suite that allows for plugging a package manager into it (whether it be portage, pkgcore, or paludis) and verifying PMS compliance. Most likely this would take the form of custom ebuild trees the package manager is told to operate on, but other approaches may exist.
@@ -537,8 +621,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Repository of self-contained ebuild source packages</title>
+<section>
<body>
<p>This proposal is similar in scope to the <uri link="http://en.gentoo-wiki.com/wiki/Google_Summer_of_Code_2011_ideas#Cache_sync">Cache sync</uri> proposal, except that it will focus on implementing support for repositories that host self-contained ebuild source packages that are analogous to source RPMs (SRPMs). The repository layout will be similar to existing PORTAGE_BINHOST repositories (like those hosted at <uri link="http://tinderbox.dev.gentoo.org/default-linux/x86/">tinderbox.dev.gentoo.org</uri>), and will include a metadata index file which is similar to <uri link="http://tinderbox.dev.gentoo.org/default-linux/x86/Packages">$PKGDIR/Packages</uri>. Each source package hosted in the repository will contain a single ebuild, its metadata, and all files it requires from the portage tree (including all inherited eclasses and any additional files such as patches from the files directory). A zip file will be a suitable container for one of these source packages.
</p><p>A synchronization script will generate source packages from a source portage tree (or overlay), and it will avoid unnecessary regeneration of a given source package in cases when no relevant files have changed timestamps or been added/removed. This script will be run as often as the repository maintainer wants to synchronize with the source tree.
@@ -554,8 +641,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Make the clustering LiveCD from a previous GSoC bootable from USB</title>
+<section>
<body>
<p>The clustering LiveCD is a bootable image that allows you to instantly turn a full room of computers into a functional cluster. You only need one CD because the rest of the nodes boot disklessly from the master node with the CD. This project would be a huge improvement to the existing version because it will allow us to use persistent, writable USB media instead of a read-only CD. That means clusters won't need to be reconfigured from scratch on every boot. That will save a lot of admin time on each boot and make it possible to do things like run a cluster in 10 different computer labs with different settings on each, as easily as inserting 1 USB stick in each lab and rebooting all the computers.
</p><p><b>Skills</b>:
@@ -568,8 +658,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>OpenBSD port of Gentoo</title>
+<section>
<body>
<p>The OpenBSD port is dead. This project would involve investigating and implementing the necessary porting work to get a Gentoo userland running on a BSD kernel and base system (the base system is also managed by Gentoo).
</p><p><b>Skills</b>:
@@ -582,8 +675,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Glendix: Create a lean distro based on Gentoo and Plan 9 (Glentoo?)</title>
+<section>
<body>
<p><uri link="http://www.glendix.org/">Glendix</uri> is a port of the Plan 9 userspace to the Linux kernel. In its current state it is just a set of patches to the Linux kernel to make sure Plan 9 binaries are able to run unmodified. However, in order to bring the entire Plan 9 userspace experience to Linux, we need a lightweight Linux distribution that packages all of this nicely. Gentoo provides us a great base for this because of it's customizability.
</p><p>The objective of this project would be to create a LiveCD based on Gentoo and Glendix, providing the end user with a nice experience of Linux with a non-GNU (namely Plan 9) userspace.
@@ -599,8 +695,11 @@
</li></ul>
</body>
</section>
-<section>
+</chapter>
+
+<chapter>
<title>Provide Gentoo 11 LiveDVDs with Anaconda installer</title>
+<section>
<body>
<p><uri link="http://www.sabayon.org/">Sabayon</uri> is maintaining an Anaconda Installer snapshot from Fedora in their git repositories. It would be nice to have it assimilated in Gentoo and provide quick-install features to our users too.
</p><p><b>Skills</b>:
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:27 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:27 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:27:07
Modified: ideas.xml
Log:
Use <note> properly for notes.
Revision Changes Path
1.4 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.4&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.4&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.3&r2=1.4
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ideas.xml 20 Mar 2011 06:24:57 -0000 1.3
+++ ideas.xml 20 Mar 2011 06:27:07 -0000 1.4
@@ -310,8 +310,8 @@
<section>
<body>
<p>Gentoo uses categories now. A package can only be in a single category, which is very limiting because generally things don't fit perfectly into one place without other possibilities. Tags could make it a lot easier to find packages they're looking for by doing Boolean searches like: kde AND mail. This project would add support for tags to Portage and would allow for backwards compatibility of categories as tags.
-</p><p><b>Note</b>: This project in its current form is considered trivial and not suitable for a complete SoC project <uri link="http://archives.gentoo.org/gentoo-soc/msg_f082a4346ffc9578948ce2f987a80465.xml">[1]</uri>. If you wish to work on this, you should expand the scope of the work significantly.
-</p><p><b>Skills</b>:
+</p><note>This project in its current form is considered trivial and not suitable for a complete SoC project <uri link="http://archives.gentoo.org/gentoo-soc/msg_f082a4346ffc9578948ce2f987a80465.xml">[1]</uri>. If you wish to work on this, you should expand the scope of the work significantly.</note>
+<p><b>Skills</b>:
</p>
<ul><li>Python
</li></ul>
@@ -328,8 +328,8 @@
<section>
<body>
<p>Gentoo package names are ugly, not suited for shiny Graphical User Interfaces. It would be good enough to add a new field to metadata.xml that exposes a more user friendly "application name". For example, media-sound/amarok could get in metadata.xml an application name like "Amarok, the music player". Moreover, this "mnemonic name" should be used in repository queries matching.
-</p><p><b>Note</b>: This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.
-</p><p><b>Skills</b>:
+</p><note>Note: This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.</note>
+<p><b>Skills</b>:
</p>
<ul><li>Portage, Python, XML
</li></ul>
@@ -353,8 +353,8 @@
</li><li>asynchronous kernel function calling (in 2.6.29)
</li><li>speeding up loading of the desktop environment (early GDM start, profiling etc)
</li></ol>
-<p><b>NOTE</b>: There have been a large number of applicants for this idea, and a lot of discussions about this on the <uri link="http://archives.gentoo.org/gentoo-soc/">mailing list archives</uri>. Because of this, we have decided to <b>raise the bar for this idea</b>. Applicants expecting to get selected should show us their capability by plucking some of the low-hanging fruit (aka, easy fixes) in the boot process. Show us the code.
-</p><p><b>Skills</b>:
+<note>: There have been a large number of applicants for this idea, and a lot of discussions about this on the <uri link="http://archives.gentoo.org/gentoo-soc/">mailing list archives</uri>. Because of this, we have decided to <b>raise the bar for this idea</b>. Applicants expecting to get selected should show us their capability by plucking some of the low-hanging fruit (aka, easy fixes) in the boot process. Show us the code.</note>
+<p><b>Skills</b>:
</p>
<ul><li>Shell scripting, C
</li></ul>
@@ -419,8 +419,8 @@
<ul><li> Compilation related messages are thrown to user when installing a binary package. This <b>should be avoided</b> somehow. Bad developers habit.
</li><li> It would be nice to have elog output stored in /var/db for later consumption and perhaps, have it embedded in xpak metadata. This would improve PackageKit support, which doesn't allow any output from package phases during install.
</li></ul>
-<p><b>Note</b>: base binary kernel ebuilds and eclasses are available in the "sabayon" overlay and its maintainer would like to apply to this part of the task.
-</p><p><b>Skills</b>:
+<note>: base binary kernel ebuilds and eclasses are available in the "sabayon" overlay and its maintainer would like to apply to this part of the task.</note>
+<p><b>Skills</b>:
</p>
<ul><li>Python, shell scripting
</li></ul>
@@ -480,7 +480,7 @@
</li></ul>
<ul><li> snapshots, which must be pulled and manually packaged by a developer and hosted on Gentoo infrastructure. Snapshot archives are often not reproducible bit-for-bit and do not have upstream's direct "blessing".
</li></ul>
-<note><b>Note:</b> there's a third solution, which is to copy the scm tree and provide our own.</note>
+<note>There's a third solution, which is to copy the scm tree and provide our own.</note>
<p>This project would implement a Gentoo snapshot management infrastructure (an extension of Gentoo's existing mirror infrastructure) to provide a better alternative. The process would be:
</p>
<ul><li> The ebuild writer specifies a scm url and tag
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:34 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:34 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:34:53
Modified: ideas.xml
Log:
Restore links in intro.
Revision Changes Path
1.6 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.6&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.6&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.5&r2=1.6
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ideas.xml 20 Mar 2011 06:31:24 -0000 1.5
+++ ideas.xml 20 Mar 2011 06:34:53 -0000 1.6
@@ -21,8 +21,9 @@
get in touch with them earlier rather than later to develop your idea into a
complete application.</b> You can find many of them on Freenode's IRC network
under the same username. If there is no contact information, please join the
-gentoo-soc mailing list or #gentoo-soc on the Freenode IRC network, and we
-will work with you to find a mentor and discuss your idea.
+<uri link="http://www.gentoo.org/main/en/lists.xml">gentoo-soc mailing
+list</uri> or #gentoo-soc on the Freenode IRC network, and we will work with
+you to find a mentor and discuss your idea.
</p>
<p>
@@ -51,23 +52,28 @@
<b>Use the tools that you will use in your project to make changes to code</b>
(e.g., source code management [SCM] software such as CVS, Subversion, or
git). Please use the same SCM as you will use for your project to check out
-one of our repositories (more repositories), make a change to it, and post
-that change as a patch on a mailing list or bug. Please fix a real bug
-reported in Bugzilla to show that you can use the tools to make a meaningful
-change; your mentor can help you identify a good one. Your contact in Gentoo
-can help you determine which SCM and repository you should use for this. If
-your idea doesn't have a contact, please get in touch with us on the
-gentoo-soc mailing list or in real-time on IRC at Freenode/#gentoo-soc. Once
-you've made your change, link to it from your application.
+one of our <uri link="http://anoncvs.gentoo.org/">repositories</uri> (<uri
+link="http://git.overlays.gentoo.org/gitweb/">more repositories</uri>), make a
+change to it, and post that change as a <uri
+link="http://www.network-theory.co.uk/articles/patchintro.html">patch</uri> on
+a mailing list or <uri link="http://bugs.gentoo.org/">bug</uri>. Please fix a
+real bug reported in <uri link="http://bugs.gentoo.org/">Bugzilla</uri> to
+show that you can use the tools to make a meaningful change; your mentor can
+help you identify a good one. Your contact in Gentoo can help you determine
+which SCM and repository you should use for this. If your idea doesn't have a
+contact, please get in touch with us on the gentoo-soc mailing list or in
+real-time on IRC at Freenode/#gentoo-soc. Once you've made your change, link
+to it from your application.
</li>
<li>
<b>Participate in our development community.</b> Please make a post to one of
-our mailing lists and link to it from your application (archives.gentoo.org
-holds past postings). The gentoo-soc list would be a good starting point, if
-you aren't subscribed to any others already. The best posts would be an
-introduction of the project you're applying for and a little background about
-you, to introduce yourself to the community and get some broader input about
-your project.
+our <uri link="http://www.gentoo.org/main/en/lists.xml">mailing lists</uri>
+and link to it from your application (archives.gentoo.org holds past
+postings). The gentoo-soc list would be a good starting point, if you aren't
+subscribed to any others already. The best posts would be an introduction of
+the project you're applying for and a little background about you, to
+introduce yourself to the community and get some broader input about your
+project.
</li>
<li>
<b>Give us your contact info and working hours.</b> Please provide your email
@@ -79,7 +85,12 @@
</ul>
<p>
-These actions are things you will do extremely commonly as an open-source developer, and they really aren't that hard, so don't let them hold you back! The remainder of the application is free-form. Please read our application guidelines and Google's FAQ to complete it. Good luck!
+These actions are things you will do extremely commonly as an open-source
+developer, and they really aren't that hard, so don't let them hold you back!
+The remainder of the application is free-form. Please read our <uri
+link="applying.xml">application guidelines</uri> and <uri
+link="http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/faqs">Google's
+FAQ</uri> to complete it. Good luck!
</p>
</body>
</section>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:36 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:36 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:36:25
Modified: ideas.xml
Log:
Restore intro ideas text.
Revision Changes Path
1.7 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.7&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.7&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.6&r2=1.7
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ideas.xml 20 Mar 2011 06:34:53 -0000 1.6
+++ ideas.xml 20 Mar 2011 06:36:25 -0000 1.7
@@ -101,6 +101,12 @@
<section>
<body>
<p>
+<b>NOTE: Discussions about these ideas should take place on the gentoo-soc
+mailing list</b> (CC the contacts if required). Please go through the existing
+discussions about your idea in the mailing list archives before posting.
+</p>
+
+<p>
Our suggestions for project ideas are below. Please feel free to propose your
own ideas; those are often among our favorites! You can find an easily
browseable ideas listing in the Content dropdown at the top of the page.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:36 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:36 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:36:42
Modified: ideas.xml
Log:
Restore one last link.
Revision Changes Path
1.8 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.8&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.8&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.7&r2=1.8
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ideas.xml 20 Mar 2011 06:36:25 -0000 1.7
+++ ideas.xml 20 Mar 2011 06:36:42 -0000 1.8
@@ -103,7 +103,9 @@
<p>
<b>NOTE: Discussions about these ideas should take place on the gentoo-soc
mailing list</b> (CC the contacts if required). Please go through the existing
-discussions about your idea in the mailing list archives before posting.
+discussions about your idea in the <uri
+link="http://archives.gentoo.org/gentoo-soc/">mailing list archives</uri>
+before posting.
</p>
<p>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 6:43 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 6:43 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 06:43:11
Modified: ideas.xml
Log:
More tweaks related to <note>.
Revision Changes Path
1.9 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.9&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.9&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.8&r2=1.9
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- ideas.xml 20 Mar 2011 06:36:42 -0000 1.8
+++ ideas.xml 20 Mar 2011 06:43:11 -0000 1.9
@@ -347,7 +347,7 @@
<section>
<body>
<p>Gentoo package names are ugly, not suited for shiny Graphical User Interfaces. It would be good enough to add a new field to metadata.xml that exposes a more user friendly "application name". For example, media-sound/amarok could get in metadata.xml an application name like "Amarok, the music player". Moreover, this "mnemonic name" should be used in repository queries matching.
-</p><note>Note: This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.</note>
+</p><note>This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.</note>
<p><b>Skills</b>:
</p>
<ul><li>Portage, Python, XML
@@ -372,7 +372,7 @@
</li><li>asynchronous kernel function calling (in 2.6.29)
</li><li>speeding up loading of the desktop environment (early GDM start, profiling etc)
</li></ol>
-<note>: There have been a large number of applicants for this idea, and a lot of discussions about this on the <uri link="http://archives.gentoo.org/gentoo-soc/">mailing list archives</uri>. Because of this, we have decided to <b>raise the bar for this idea</b>. Applicants expecting to get selected should show us their capability by plucking some of the low-hanging fruit (aka, easy fixes) in the boot process. Show us the code.</note>
+<note>There have been a large number of applicants for this idea, and a lot of discussions about this on the <uri link="http://archives.gentoo.org/gentoo-soc/">mailing list archives</uri>. Because of this, we have decided to <b>raise the bar for this idea</b>. Applicants expecting to get selected should show us their capability by plucking some of the low-hanging fruit (aka, easy fixes) in the boot process. Show us the code.</note>
<p><b>Skills</b>:
</p>
<ul><li>Shell scripting, C
@@ -438,7 +438,7 @@
<ul><li> Compilation related messages are thrown to user when installing a binary package. This <b>should be avoided</b> somehow. Bad developers habit.
</li><li> It would be nice to have elog output stored in /var/db for later consumption and perhaps, have it embedded in xpak metadata. This would improve PackageKit support, which doesn't allow any output from package phases during install.
</li></ul>
-<note>: base binary kernel ebuilds and eclasses are available in the "sabayon" overlay and its maintainer would like to apply to this part of the task.</note>
+<note>Base binary kernel ebuilds and eclasses are available in the "sabayon" overlay, and its maintainer would like to apply to this part of the task.</note>
<p><b>Skills</b>:
</p>
<ul><li>Python, shell scripting
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-20 18:40 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-20 18:40 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/20 18:40:27
Modified: ideas.xml
Log:
Fix typo intimated -> intimidated that was pulled in from the wiki (Brian Dolbec).
Revision Changes Path
1.10 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.10&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.10&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.9&r2=1.10
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- ideas.xml 20 Mar 2011 06:43:11 -0000 1.9
+++ ideas.xml 20 Mar 2011 18:40:27 -0000 1.10
@@ -607,8 +607,10 @@
<title>Web interface for submitting Documentation changes</title>
<section>
<body>
-<p>People are often intimated by XML, and finding the "source code" to the documentation can be painful for people. So having a user interface to our documentation would help out a lot with contributions.
-</p><p>Workflow would be something like:
+<p>People are often intimidated by XML, and finding the "source code" to the
+documentation can be painful for people. So having a user interface to our
+documentation would help out a lot with contributions. </p><p>Workflow would
+be something like:
</p>
<ul><li> person visits documentation page
</li><li> person notices a mistake
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-21 10:04 Alec Warner (antarus)
0 siblings, 0 replies; 13+ messages in thread
From: Alec Warner (antarus) @ 2011-03-21 10:04 UTC (permalink / raw
To: gentoo-commits
antarus 11/03/21 10:04:46
Modified: ideas.xml
Log:
add me as a mentor for gstats.
Revision Changes Path
1.11 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.11&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.11&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.10&r2=1.11
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- ideas.xml 20 Mar 2011 18:40:27 -0000 1.10
+++ ideas.xml 21 Mar 2011 10:04:46 -0000 1.11
@@ -204,7 +204,7 @@
<p><b>Contacts</b>:
</p>
<ul><li><mail link="chris@basementcode.com">Christopher Harvey</mail>
-</li></ul>
+</li><li><mail link="antarus@gentoo.org"></mail></li></ul>
</body>
</section>
</chapter>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-22 3:29 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-22 3:29 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/22 03:29:07
Modified: ideas.xml
Log:
Use faqindex for ideas page instead of telling people to use the contents dropdown to see all the ideas. Thanks, swift, for telling me about this.
Revision Changes Path
1.12 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.12&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.12&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.11&r2=1.12
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- ideas.xml 21 Mar 2011 10:04:46 -0000 1.11
+++ ideas.xml 22 Mar 2011 03:29:07 -0000 1.12
@@ -10,9 +10,10 @@
need not be Gentoo developers; anyone who meets the eligibility requirements of
Google is encouraged to apply.
</abstract>
-<version>1.0</version>
-<date>2011-03-19</date>
-<chapter>
+<version>1.1</version>
+<date>2011-03-22</date>
+
+<faqindex>
<title>Read this first</title>
<section>
<body>
@@ -92,14 +93,7 @@
link="http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/faqs">Google's
FAQ</uri> to complete it. Good luck!
</p>
-</body>
-</section>
-</chapter>
-<chapter>
-<title>Ideas</title>
-<section>
-<body>
<p>
<b>NOTE: Discussions about these ideas should take place on the gentoo-soc
mailing list</b> (CC the contacts if required). Please go through the existing
@@ -110,12 +104,11 @@
<p>
Our suggestions for project ideas are below. Please feel free to propose your
-own ideas; those are often among our favorites! You can find an easily
-browseable ideas listing in the Content dropdown at the top of the page.
+own ideas; those are often among our favorites!
</p>
</body>
</section>
-</chapter>
+</faqindex>
<chapter>
<title>libbash runtime</title>
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-22 3:51 Donnie Berkholz (dberkholz)
0 siblings, 0 replies; 13+ messages in thread
From: Donnie Berkholz (dberkholz) @ 2011-03-22 3:51 UTC (permalink / raw
To: gentoo-commits
dberkholz 11/03/22 03:51:57
Modified: ideas.xml
Log:
Reformat chapters to sections for faqindex.
Revision Changes Path
1.13 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.13&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.13&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.12&r2=1.13
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ideas.xml 22 Mar 2011 03:29:07 -0000 1.12
+++ ideas.xml 22 Mar 2011 03:51:57 -0000 1.13
@@ -111,8 +111,9 @@
</faqindex>
<chapter>
-<title>libbash runtime</title>
+<title>Ideas</title>
<section>
+<title>libbash runtime</title>
<body>
<p>Libbash will enable programs to use Abstract Syntax Trees to parse bash commands directly instead of using regular expressions. This will be a great benefit to programs both outside and inside Gentoo, including Portage and repoman. Also, it will be a library that allows C++ to talk to bash (using this AST).
</p>
@@ -132,11 +133,9 @@
</ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Ebuild QA checks based on libbash AST</title>
<section>
+<title>Ebuild QA checks based on libbash AST</title>
<body>
<p>From last year (see idea above) we have a working grammar to produce an AST for bash scripts, which allows us to programatically parse bash within non-bash programs (C++, Python, etc). Now that we are able to analyze bash scripts, the goal of this project is to start producing actual ebuild QA checks against the AST.
</p><p><b>Skills</b>:
@@ -150,11 +149,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Kernel Security issue handling/notifications</title>
<section>
+<title>Kernel Security issue handling/notifications</title>
<body>
<p>Kernels are not part of the normal Gentoo security advisory process because of the multitude of available kernel variants and versions.
Instead of writing advisories for a group of issues, we rather want to tag each Kernel vulnerability with the information in what kernel version or what patchset version it is fixed.
@@ -172,11 +169,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Package statistics reporting tool</title>
<section>
+<title>Package statistics reporting tool</title>
<body>
<p><b>Quick description:<br /></b>
A user end program to upload anonymous information about installed packages on a users machine to a database that package maintainers and developers have access to. <br /><br />
@@ -200,11 +195,9 @@
</li><li><mail link="antarus@gentoo.org"></mail></li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Porthole plug-ins and extensions</title>
<section>
+<title>Porthole plug-ins and extensions</title>
<body>
<p>Porthole is a GTK+-based frontend to Portage. This project would enable Porthole to improve its ability to manage remote computers, gather and report package statistics, and more. The work would encompass creating:
</p>
@@ -228,11 +221,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Support for Fortran modules/libraries with multiple compilers</title>
<section>
+<title>Support for Fortran modules/libraries with multiple compilers</title>
<body>
<p>Fortran modules and libraries are highly compiler dependent. Even minor
version change in gfortran renders them incompatible. However, we are often
@@ -256,11 +247,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Virtual Machine Builder (website or desktop client)</title>
<section>
+<title>Virtual Machine Builder (website or desktop client)</title>
<body>
<p>The idea is to implement a user interface to build a on-demand modular Virtual Machine image operating system based on Gentoo. The VM could be tuned for a number of pre-defined profiles, such as High Performance Computing modern architectures, Gentoo testing tinderboxes, desktops,... It could be based on any of existing tools such as virt-mananager.
</p><p>This could be a Web-based or desktop-based tool, depending on your analysis of the requirements while working with the mentor.
@@ -274,11 +263,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Porthole backend re-structure</title>
<section>
+<title>Porthole backend re-structure</title>
<body>
<p>Porthole is a GTK+-based frontend to Portage. This is to work at developing a new backend structure to use a new public API for Portage. With this, Porthole could run emerge processes from the imported Portage code. Once the basic restructuring is completed, begin creating a new pkgcore based backend that can be used as an alternate package manager.
</p>
@@ -292,11 +279,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>gentoo-x86 QA website</title>
<section>
+<title>gentoo-x86 QA website</title>
<body>
<p>The idea is simple enough, take the QA results from various tools and present it via a searchable website. Think <uri link="http://packages.gentoo.org/">packages.gentoo.org</uri>, just for QA results. The implementation work required would primarily be building the website itself- the user could rely upon pkgcore-checks for the initial data stream (it can output it's results as a pickle stream) leaving the candidate to focus on generating a site providing insight into the status of current architectures, current stabling, etc.
</p><p>One additional constraint would be that the underlying DB schema should be written in a fashion that allows multiple data imports to be used- while pkgcore-checks right now can provide data for a candidate to work with, the candidate should be designing a system also able to pull in other data sources (at some point repoman for example).
@@ -315,11 +300,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Add "tags" support to Portage</title>
<section>
+<title>Add "tags" support to Portage</title>
<body>
<p>Gentoo uses categories now. A package can only be in a single category, which is very limiting because generally things don't fit perfectly into one place without other possibilities. Tags could make it a lot easier to find packages they're looking for by doing Boolean searches like: kde AND mail. This project would add support for tags to Portage and would allow for backwards compatibility of categories as tags.
</p><note>This project in its current form is considered trivial and not suitable for a complete SoC project <uri link="http://archives.gentoo.org/gentoo-soc/msg_f082a4346ffc9578948ce2f987a80465.xml">[1]</uri>. If you wish to work on this, you should expand the scope of the work significantly.</note>
@@ -333,11 +316,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Add "mnemonic names" to Packages in metadata.xml</title>
<section>
+<title>Add "mnemonic names" to Packages in metadata.xml</title>
<body>
<p>Gentoo package names are ugly, not suited for shiny Graphical User Interfaces. It would be good enough to add a new field to metadata.xml that exposes a more user friendly "application name". For example, media-sound/amarok could get in metadata.xml an application name like "Amarok, the music player". Moreover, this "mnemonic name" should be used in repository queries matching.
</p><note>This project in its current form is considered trivial and not suitable for a complete SoC project. If you wish to work on this, you should expand the scope of the work significantly. There are probably many other information we could add to metadata.xml to keep Portage packages up with times. A good inspiration source is PackageKit metadata required to backends by its core library.</note>
@@ -351,11 +332,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Fastboot on Gentoo</title>
<section>
+<title>Fastboot on Gentoo</title>
<body>
<p>Recently, some kernel developers working at Intel got boot times on solid-state drives down to 5 seconds (10 on hard drive). It would be awesome to have this in Gentoo. This would require significant changes to our custom init system, OpenRC, as well as lots of profiling of the kernel boot and userspace boot processes using tools like <uri link="http://www.bootchart.org/">bootchart</uri>. <uri link="http://moblin.org/projects/fast-boot">More info about fastboot is here</uri>. Note that the work of fastboot was primarily concerned with:
</p>
@@ -376,11 +355,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Systemd/Upstart on Gentoo</title>
<section>
+<title>Systemd/Upstart on Gentoo</title>
<body>
<p>Related to the Fastboot objectives, it has been suggested that new init daemons, Systemd and/or Upstart, could be modified to support the Gentoo init.d scripts. Our init scripts already provide nearly all the same metadata required for upstart scripts. This would enable drop-in use of either init daemon on Gentoo, without rewriting any init.d scripts. It would/could be used in conjunction with OpenRC, and not be a replacement for OpenRC. This will require modifications to both OpenRC (so it can use either SystemV init or upstart/systemd) and the init daemon itself.
</p><p>Before applying for systemd, please check the status of <uri link="https://bugs.gentoo.org/show_bug.cgi?id=318365#c141">bug #318365</uri>, where much of the discussion on doing this work has occurred.
@@ -396,11 +373,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Cache sync</title>
<section>
+<title>Cache sync</title>
<body>
<p>The portage tree and all its overlays keep growing. Right now only the official portage tree occupies more than 600Mb on a regular filesystem. However the package manager does not need the whole tree of full ebuilds, patches and manifests to perform most of its work. The idea would be to sync a smaller database or a cache of only needed information for global package manager operations, then fetch the required package only when needed. It would speed considerably tree synchronization and reduce the space occupied by portage tree (see the "Repository of Self-Contained Ebuild Source Packages" idea for an alternative approach). Currently the cache system in portage is also really slow and so is the search feature. The project could be inspired by the Debian or RPM system but with the usability and choices offered by Gentoo, and would probably include:
</p>
@@ -417,11 +392,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Improved binary package support</title>
<section>
+<title>Improved binary package support</title>
<body>
<p>
Gentoo better for derived binary distros. One of them is more intelligent handling of library versions with binpkgs (and installed packages, which are a form of binpkg). For example, it's possible to build a binpkg against an old version of a library, then install it against a new version and have it be broken by default because of a shared-library version bump. It's also possible to break reverse ABI dependencies when upgrading a package, and there is currently no convenient way for package managers to detect such breakage in advance. Ideally, a package would have a way to specify its ABI dependencies in the <b>built</b> state instead of just which versions it can build against from <b>source</b>. It is possible to create an ABI dependency abstraction that is flexible enough to cover all possible kinds of ABI dependencies. Using an ABI abstraction, it will not matter whether or not there exists a specific soname to be referenced by dependencies. See <uri link="https://bugs.
gentoo.org/192319">bug #192319</uri>.
@@ -442,11 +415,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>User Generated Content for Portage packages</title>
<section>
+<title>User Generated Content for Portage packages</title>
<body>
<p>It would be nice to port the User Generated Content infrastructure used in Sabayon to Gentoo. It's actually a bunch of well-tested SQL tables a set of API that can work over a simple, perhaps Python-based, web service. A minimal effort is also required client-side, to implement the client API that could suit the Portage codebase. This could couple with <b>Package statistics reporting tool</b> listed above
</p><p><b>Example of how it works</b>: <uri link="http://packages.sabayon.org">Sabayon "Entropy Store"</uri>
@@ -460,11 +431,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Automated numerical libraries benchmark suite</title>
<section>
+<title>Automated numerical libraries benchmark suite</title>
<body>
<p>Quite a few numerical libraries are available in Gentoo (BLAS, LAPACK, FFTW,...), and some of them offered in different implementations. The work would consist on implementing a benchmark suite and an automated mechanism to test numerical libraries on Gentoo for bugs, correctness and speed. That is for any combination of compilers, compiler and USE flags, versions, and dependencies. It could rely on existing or future eselect framework.
</p><p><b>Skills</b>:
@@ -477,11 +446,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>SCM snapshot management infrastructure</title>
<section>
+<title>SCM snapshot management infrastructure</title>
<body>
<p>A growing number of projects provide binary-only releases of their packages with
the source available only as a tag in a version control system. This presents
@@ -514,11 +481,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>EBuild generator</title>
<section>
+<title>EBuild generator</title>
<body>
<p>It would be great if we had a simple tool to generate ebuilds for the most straightforward packages and build systems. For the basics, writing an ebuild could be a Python-based GUI to get stuff like dependencies and some common code blocks in there. One attempt to create such a tool was <uri link="http://abeni.sourceforge.net/">Abeni</uri>.
</p><p><b>Skills</b>:
@@ -531,11 +496,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Maven integration</title>
<section>
+<title>Maven integration</title>
<body>
<p>Be able to easily write ebuilds for projects using Maven, a popular build system for Java projects.
</p><p>The goal of this project is to be easily able to write ebuilds for
@@ -552,11 +515,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Gentoo/Java IDE integration</title>
<section>
+<title>Gentoo/Java IDE integration</title>
<body>
<p>Be able to easily work with system libraries in IDEs.
</p><p>Fix Netbeans or Eclipse so that they are easily able to find system
@@ -573,11 +534,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Rewrite java-config in C++ or python</title>
<section>
+<title>Rewrite java-config in C++ or python</title>
<body>
<p>Gentoo's tool for switching between Java versions and implementations, java-config, needs love. It could use a lot of new features and even a rewrite, as it has a lot of legacy from the generation 1 days.
</p><p>We could drop the need of python for the Gentoo/Java tools if this is written
@@ -594,11 +553,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Web interface for submitting Documentation changes</title>
<section>
+<title>Web interface for submitting Documentation changes</title>
<body>
<p>People are often intimidated by XML, and finding the "source code" to the
documentation can be painful for people. So having a user interface to our
@@ -615,11 +572,9 @@
</p>
</body>
</section>
-</chapter>
-<chapter>
-<title>Package Manager Specification (PMS) compliance test suite</title>
<section>
+<title>Package Manager Specification (PMS) compliance test suite</title>
<body>
<p>Right now there is no way to validate that a pkg manager implementation is compliant w/ what the Package Manager Specification (PMS) specifies, nor any way to track what affects a spec change may have on the various managers w/out testing each.
</p><p>The idea is simple enough; write a test suite that allows for plugging a package manager into it (whether it be portage, pkgcore, or paludis) and verifying PMS compliance. Most likely this would take the form of custom ebuild trees the package manager is told to operate on, but other approaches may exist.
@@ -635,11 +590,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Repository of self-contained ebuild source packages</title>
<section>
+<title>Repository of self-contained ebuild source packages</title>
<body>
<p>This proposal is similar in scope to the Cache sync proposal, except that it will focus on implementing support for repositories that host self-contained ebuild source packages that are analogous to source RPMs (SRPMs). The repository layout will be similar to existing PORTAGE_BINHOST repositories (like those hosted at <uri link="http://tinderbox.dev.gentoo.org/default-linux/x86/">tinderbox.dev.gentoo.org</uri>), and will include a metadata index file which is similar to <uri link="http://tinderbox.dev.gentoo.org/default-linux/x86/Packages">$PKGDIR/Packages</uri>. Each source package hosted in the repository will contain a single ebuild, its metadata, and all files it requires from the portage tree (including all inherited eclasses and any additional files such as patches from the files directory). A zip file will be a suitable container for one of these source packages.
</p><p>A synchronization script will generate source packages from a source portage tree (or overlay), and it will avoid unnecessary regeneration of a given source package in cases when no relevant files have changed timestamps or been added/removed. This script will be run as often as the repository maintainer wants to synchronize with the source tree.
@@ -655,11 +608,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Make the clustering LiveCD from a previous GSoC bootable from USB</title>
<section>
+<title>Make the clustering LiveCD from a previous GSoC bootable from USB</title>
<body>
<p>The clustering LiveCD is a bootable image that allows you to instantly turn a full room of computers into a functional cluster. You only need one CD because the rest of the nodes boot disklessly from the master node with the CD. This project would be a huge improvement to the existing version because it will allow us to use persistent, writable USB media instead of a read-only CD. That means clusters won't need to be reconfigured from scratch on every boot. That will save a lot of admin time on each boot and make it possible to do things like run a cluster in 10 different computer labs with different settings on each, as easily as inserting 1 USB stick in each lab and rebooting all the computers.
</p><p><b>Skills</b>:
@@ -672,11 +623,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>OpenBSD port of Gentoo</title>
<section>
+<title>OpenBSD port of Gentoo</title>
<body>
<p>The OpenBSD port is dead. This project would involve investigating and implementing the necessary porting work to get a Gentoo userland running on a BSD kernel and base system (the base system is also managed by Gentoo).
</p><p><b>Skills</b>:
@@ -689,11 +638,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Glendix: Create a lean distro based on Gentoo and Plan 9 (Glentoo?)</title>
<section>
+<title>Glendix: Create a lean distro based on Gentoo and Plan 9 (Glentoo?)</title>
<body>
<p><uri link="http://www.glendix.org/">Glendix</uri> is a port of the Plan 9 userspace to the Linux kernel. In its current state it is just a set of patches to the Linux kernel to make sure Plan 9 binaries are able to run unmodified. However, in order to bring the entire Plan 9 userspace experience to Linux, we need a lightweight Linux distribution that packages all of this nicely. Gentoo provides us a great base for this because of it's customizability.
</p><p>The objective of this project would be to create a LiveCD based on Gentoo and Glendix, providing the end user with a nice experience of Linux with a non-GNU (namely Plan 9) userspace.
@@ -709,11 +656,9 @@
</li></ul>
</body>
</section>
-</chapter>
-<chapter>
-<title>Provide Gentoo 11 LiveDVDs with Anaconda installer</title>
<section>
+<title>Provide Gentoo 11 LiveDVDs with Anaconda installer</title>
<body>
<p><uri link="http://www.sabayon.org/">Sabayon</uri> is maintaining an Anaconda Installer snapshot from Fedora in their git repositories. It would be nice to have it assimilated in Gentoo and provide quick-install features to our users too.
</p><p><b>Skills</b>:
^ permalink raw reply [flat|nested] 13+ messages in thread
* [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml
@ 2011-03-30 5:19 Alec Warner (antarus)
0 siblings, 0 replies; 13+ messages in thread
From: Alec Warner (antarus) @ 2011-03-30 5:19 UTC (permalink / raw
To: gentoo-commits
antarus 11/03/30 05:19:03
Modified: ideas.xml
Log:
Note that applications are now open, link to appspot.
Revision Changes Path
1.14 xml/htdocs/proj/en/userrel/soc/ideas.xml
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.14&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?rev=1.14&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml?r1=1.13&r2=1.14
Index: ideas.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/userrel/soc/ideas.xml,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- ideas.xml 22 Mar 2011 03:51:57 -0000 1.13
+++ ideas.xml 30 Mar 2011 05:19:03 -0000 1.14
@@ -35,7 +35,8 @@
</p>
<p>
-<b>Applications are not yet open</b> — the earlier the better, but don't rush
+ <b>Applications are <uri link="http://socghop.appspot.com">open</uri></b>
+ — the earlier the better, but don't rush
through it! We have a custom application template that we will ask you to fill
out. Here it is:
</p>
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-03-30 5:19 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-20 6:43 [gentoo-commits] gentoo commit in xml/htdocs/proj/en/userrel/soc: ideas.xml Donnie Berkholz (dberkholz)
-- strict thread matches above, loose matches on Subject: below --
2011-03-30 5:19 Alec Warner (antarus)
2011-03-22 3:51 Donnie Berkholz (dberkholz)
2011-03-22 3:29 Donnie Berkholz (dberkholz)
2011-03-21 10:04 Alec Warner (antarus)
2011-03-20 18:40 Donnie Berkholz (dberkholz)
2011-03-20 6:36 Donnie Berkholz (dberkholz)
2011-03-20 6:36 Donnie Berkholz (dberkholz)
2011-03-20 6:34 Donnie Berkholz (dberkholz)
2011-03-20 6:27 Donnie Berkholz (dberkholz)
2011-03-20 6:24 Donnie Berkholz (dberkholz)
2011-03-20 6:12 Donnie Berkholz (dberkholz)
2011-03-20 5:50 Donnie Berkholz (dberkholz)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox