Projects Status
From Gentoo Linux Wiki
This article is a summary of the project status reports submitted to the gentoo-devel mailing list.
You can read the full thread at http://article.gmane.org/gmane.linux.gentoo.devel/60988
Contents |
[edit] Alpha Architecture
Homepage: http://www.gentoo.org/proj/en/base/alpha/
Author: Tobias Klausmann (klausmann)
Last Update: 11th May 2009
So where are we at with alpha currently?
Xorg-1.5
As some of you know, xorg-1.5 abandoned the "classic" way of interfacing with PCI and AGP cards in favor of using libpciaccess. That, in turn expects support from the kernel in the form of /sys/devices/<bus>/<id>/<func>/resourceN files.
Unfortunately, alpha until recently had no support for those PCI resources (which is partly due to the way alpha IO space is structured and partly due to a crucial extension not being available on old Alphas (older than EV56).
As such, we weren't able to keyword or stabilize Xorg-1.5 until recently, when 2.6.30-rc* saw support finally being added. Naturally, packages depending on >=xorg-1.5 had to be held off, too.
The -rc kernels are keyworded ~alpha so people can test. So far, -rc3 and rc4 are looking good, so we will keyword xorg and deps soon (I'm aiming for this weekend) and if all goes well, we will have it stable, soon.
Note that this will mean that people with EV4-Alphas will *not* be able to use Xorg-1.5 just now. I feel that those machines are so slow that very few will run X11 anyway, if there are Gentoo installations on those to start with.
Glibc/Toolchain
Glibc has had a bug for ages (regarding ceil() and friends, bug number 264335) which should really be fixed. Upstream is umm.. their usual selves about it. On top, a patch for fdatasync() (bug 264336) is available which upstream... well, you get it.
Workload
Currently, the alpha arch team consists of me (the nominal lead) and Raúl Porcel (armin76) who helps a lot with getting stable request answered in a timely manner.
Also, we're in the process of recruiting mattst88 as an arch tester. He's currently deep in exam-land at university, so the process is on hold for now.
Users/Community
Aside from those on the team and one or two other devs, I've had little to no direct feedback from Gentoo alpha users. I try to write about Alpha regularly on my blog (available on the planet) and I'm easily reachable as Blackb|rd on Freenode (#gentoo-alpha, naturally).
I've been toying with the idea of offering something akin to Debians popularity contest tool. Some people are rather uncomfortable with data gathering tools that send stuff to some strangers, so I don't know how well it would work. I list this idea here, since I have just about no idea what actual alpha hardware is used with Gentoo out there. Knowing which packages are actually *used* (instead of just being stabilized for the heck of it) would be nice. Added benefit of that would be that users helping with testing would reduce workload.
In essence: we're busy and I'd love to get more feedback what people (both users and devs) think we could do better, or more/less of.
[edit] Emacs
Homepage: http://www.gentoo.org/proj/en/lisp/emacs/
Author: Christian Faulhammer (Fauli)
Last Update: 11th May 2009
We are two people (Ulrich Müller (ulm) and myself), which handle the low bug load. In the last two years we revamped the tree and created some interesting things for Emacs users and eased our development work. We are mostly in maintenance-mode because our plans are done in general:
- A developer guide how to maintain GNU Emacs and packages
- Documentation of the eclasses
- Eselect module to use one of the up to four GNU Emacs versions installed in parallel
- app-emacs/gentoo-syntax for ebuild writers
- small tools (emacs-updater) to ease use of Emacs
- Push a policy on packages that is flexible and easy to use
- Create test plans for packages, so architecture teams know how to test the package (some are still missing)
- Keyword (x86 and amd64 are mandatory) and stabilisation
We still miss:
- A user-guide, where a draft from a user is available, but needs some polishing.
- ulm can tell more
[edit] XEmacs
Hans de Graaff (graaff) is the lone wolf here and because upstream development of XEmacs is not really on fire, he has not too much to do, I think. He introduced eclasses in a similar way as the GNU Emacs team.
Plans for XEmacs:
- bring tree in sync with upstream released elisp packages
- bring xemacs 21.5.x to the tree from the overlay
[edit] Eselect
Homepage: http://www.gentoo.org/proj/en/eselect/
Author: Ulrich Mueller (ulm)
Last Update: 11th May 2009
I've joined the project one month ago. Looks like it's my duty to write a status report. ;-)
eselect-1.0.12 is out since three weeks. I've fixed most bugs (a dozen or so) that were open in bugzilla. So far, no regressions have been reported, so this version will be good for stabilisation soon.
Hopefully this is also the last release from the 1.0.x branch, whose retirement is (IMHO) long overdue.
The eselect trunk has some new bells and whistles, including:
- support for OpenRC in the "rc" module
- "package-manager" library has been updated for Portage 2.1.6
- new "modules" module, for listing and querying eselect modules
- modules for EDITOR and PAGER environment variables
- "news-tng", yet another module for reading GLEP 42 news (mainly with better Portage support)
- the dysfunctional "mailer" module will be removed
- more bug fixes; some of the reports are open since 2006 :-(
There are still some things to be done before the release of version 1.1.0, but I hope that it will be ready in the second half of this month.
[edit] GCC Porting
Homepage: (None Listed)
Author: Ryan Hill (dirtyepic)
Last Update: 11th May 2009
Thanks to a load of help from darkside, loki_val, fauli, and others, GCC 4.3 is now stable on our primary archs. Thanks to a load of bug reports from Diego, the majority of the tree got fixed, including packages that haven't been seen since Clinton was in office.
Work continues for GCC 4.4, which was just added to the tree last weekish. Most of this work has happened in the gcc-porting overlay which will now be merged with the tree, and future work will be directly applied to the tree.
[edit] Java
Homepage: http://www.gentoo.org/proj/en/java/
Author: Petteri Räty (betelgeuse)
Last Update: 11th May 2009
- Too much stuff in overlays
- Beat caster with a stick
- Need more people to maintain our hundreds of packages
- Critical pkgs do have designated maintainers
- Beat all members with a stick so that they remember to show up for monthly meetings
[edit] KDE
Homepage: http://www.gentoo.org/proj/en/desktop/kde/
Author: Jorge Vicetto (jmbsvicetto)
Current:
- We have a Lead again (me). It happened on FOSDEM, so it might have been related to some "substance abuse" ;-)
- We have a strong team again full of new "blood" and are back in the game - we can take more people, but we're able to keep up with the work.
- Resumed our regular meeting schedule - 3rd Thursday of the month at 19H00 UTC on #gentoo-kde channel of the freenode IRC network.
- KDE-3.5.9 (stable) and 3.5.10 (testing) in the tree.
- KDE-4.2.3 (testing) in the tree.
- KDE-4.2 live (4.2.9999) in the kde-testing overlay.
- KDE-4.3 snapshots in the kde-testing overlay.
- KDE live (9999) in the kde-testing overlay.
Soon:
- We're in the final stages to get updated KDE3 eclasses (currently in kde-crazy overlay) into the tree. These eclasses move all misc apps under the /usr/kde/3.5 prefix (to fix the colisions with KDE4 apps and to fix prefix issues for KDE-3 apps).
- After we move the eclasses we'll ask to get KDE-3.5.10 marked stable. This means the end of the support for mono ebuilds. Anyone using them will have to switch to the split ebuilds.
- After getting this done, we can finally get KDE-4.X marked stable. We hope to get all this done in the next 2 months.
How to help:
Although we have a fully staffed team now, we can always take more help. If anyone is interested in the Gentoo KDE project and wants more info, start by checking our page and our overlays (kde and kde-crazy). We try to keep some Docs in the kde-testing overlay including some docs on how to contribute and what needs to be done. Also, we still have a *few* open bugs.
P.S. - Working with the Gentoo KDE team and getting access to the overlays is one way to get involved with Gentoo and might set you up in the road to become a Gentoo Dev - we have quite a few people around to proof it ;-)
[edit] Qt Herd
Homepage: http://www.gentoo.org/proj/en/desktop/kde/
Author: Markos Chandras (hwoarang)
Last Update: 11th May 2009
Overlay status (qting-edge):
Even though we are 2 developers and 1 contributor , we manage to keep this overlay in a pretty good shape. In this overlay we maintain 3 different qt versions:
- 4.9999 which is the master branch from nokias' git repository
- 4.5.9999[qt-copy] which is the Qt maintained by KDE developers
- 4.5.9999[-qt-copy] which is the 4.5 branch from nokias' git repository.
Plus we maintain many Qt4 live packages.
Portage tree status:
We did quite good job in pushing Qt-4.5 packages really quick. We have a stabilization process for 4.5.1 packages as well. We maintain many qt4 packages and we add more and more every day (ye, because we are quite crazy about Qt4 \o/) .
In general I can say that Ben (yngwin) and me can handle the load pretty good so far. At least this is what the number of qt bugs reveals :P
On the other hand the future doesn't look that good :(
Both of us we ll have extremely limited time after July . Ben is moving to China and I ll join the army for a year. So we really really really like to make sure that Qt4 will be in safe hands :) . However, there are 2 upcoming developers who, hopefully, will be full developers withing the next month so we can train them about qt4 split packages and qt4 eclasses.
[edit] Kernel
Homepage: http://www.gentoo.org/proj/en/kernel/
Author: Daniel Drake (dsd)
Last Updated: 13th May 2009
Continues to be a small team with desires to grow. Our processes scale well but recruitment does not. Only real task is to handle gentoo-sources, 90% of the time is handling upstream bugs reported by users (the kernel is so big and fast-moving that in order to be more effective, we have to do a certain amount of work before sending users upstream).
gentoo-sources patchset continues to shrink, we're very close to vanilla which is great from a working-with-upstream perspective.
I'm not finding much time to devote to the project due to other commitments (seems to be an ongoing curse that occurs to anyone taking the 'lead' position). Not likely to change very soon :( Happy to consider proven contributors for taking over the lead position, past present and future.
Mike Pagano continues to be a driving force, continually attacking bugs, wranging patches and making releases.
Recruited George Kadianakis and Markos Chandras who have helped a lot. Need to spend more time integrating them and delegating more from me and Mike.
Overall in good shape with 22 open bugs.
One real drain for us is dealing with crazy gentoo devs who decide to maintain packages of kernel code outside of the kernel (i.e. external kernel drivers). These break really often because these external packages use the internal kernel API which is deliberately unstable. Many maintainers are responsive, but very often we have to deal with unresponsive maintainers or packages which simply can't be fixed easily, this eats a lot of our time, slows down stabling processes, and results in a bad experience for our users. Asking for extinction of all such packages is probably unreasonable, but it would be good to see them kept out of the stable tree or something like that, and we could do a better job at communicating these maintenance difficulties to our users ("use at your own risk, this will probably break next week").
My ideas for potential goals/improvements, totally dependent on time and interest from team members:
- get bugs upstream faster
- fewer and fewer bugs
- accelerate stabling to the previous rate of 3 weeks after every major release from upstream. (quite time consuming)
- speed up regression handling, prioritise higher
- work more with bugs that we send upstream, right now they get a bit neglected by us and sometimes by upstream (probably have 30-40 bugs in this state)
- move genpatches website to independent location, automatically generated, with permanent/reliable tarball hosting
kernel-misc: Maintains various userspace packages that are tightly linked to the kernel e.g. jfsutils, module-rebuild, fuse,
also the kernel-2, linux-info and linux-mod eclasses.
Mostly neglected. Some packages have active maintainers, thanks! For the others I usually do a bug sweep every 6 months or so, taking out the easy bugs and applying patches from users.
Goals/improvements: find people to take care of this stuff..preferably people who can just step in and get on with it without me needing to find recruitment time.
[edit] Lisp
Homepage: http://www.gentoo.org/proj/en/lisp/
Author: Christian Faulhammer (Fauli)
Last Update: 11th May 2009
We are working on all our problems, but some sub-projects are a bit understaffed (e.g. Common Lisp, because pchrist is away for a year), while Scheme is in good shape but has only one active developer at the moment. We get along, but help is always needed. All our overlays are well maintained and an active playground whose changes make it into the tree eventually. Project members can tell more about their field, I guess.
[edit] .Net
Homepage: (None Listed)
Author: Peter Alfredsen (loki_val)
Last Update: 11th May 2009
Currently doing good. Nothing much to report. Everything is shiny and well-oiled. SVN ebuilds of trunk and branches were recently committed to the main tree, which will help when people report bugs. Generally trying to maintain as little distance between the main tree and the overlay as possible, so user feedback can be utilized most efficiently. ~arch is really the testing branch for Mono packages, IOW, but I try to fix bugs real quick when they're reported so most of you never notice they were there.
Cool new apps which everyone should be using:
- Tasque - for managing your everyday scheduling needs.
- Monsoon - shiny bittorrent client
- Bareftp - easy and accessible ftp client
Cool old apps which everyone should be using:
- Tomboy - notetaking application
- Banshee - the best media-player out there
- Beagle - desktop search
- Gnome-Do - LOOK! SHINY!
And of course mod_mono, for your ASP.NET needs.
What we need:
- People who care about portable.NET enough to make it great.
- People who use the ASP.NET features. I can probably debug it for you, but if there's a bug in mod_mono, I won't discover it before you do.
Notable successes:
- Bumping Mono-2.4 before Novell :-)
- Shaving bugs assigned to dotnet@gentoo.org down to a reasonable level.
- Attracting users to Gentoo through our .NET offering.
Future projects:
- revdep-rebuild support for mono!
- AOT support
- Getting Mono tests to not fail in Sandbox.
- Reducing the bus-factor. I have too much of this stuff in my head. I should write docs... Later.
[edit] Recruiters
Homepage: http://www.gentoo.org/proj/en/devrel/recruiters/
Author: Petteri Räty (betelgeuse)
Last Update: 11th May 2009
- pva and keytoaster can handle the current load
- more people doesn't hurt but no active need to recruit more
- the quizzes could use an overhaul
[edit] Ruby
Homepage: http://www.gentoo.org/proj/en/prog_lang/ruby/
Author: Hans de Graaff (graaff)
Last Update: 11th May 2009
We've had two new project members recently: a3li and gengor. In addition we also have a number of new people who help out on occasion with our overlay.
More ruby versions are now available:
- Ruby 1.9.x is in the tree. It's masked for now pending more testing and pending getting the tree more ready for it.
- Ruby Enterprise Edition is available in our overlay.
- We also have the latest ruby 1.8.6 and 1.8.7 versions in our tree.
We are in the process of cleaning up the eclasses and getting them ready to support multiple ruby versions as well.
We have a Summer of Code project which will deliver a tool to treat Ruby Gems as first-class citizens in Gentoo, including such things as patching and testing. We hope that this will improve the quality and quantity of ruby code that we can offer.
Future plans:
- Complete ruby 1.9.x migration and unmask it.
- Get Ruby Enterprise Edition ready to move to the main tree
- Add Summer of Code tool to the tree and convert majority of current ebuilds to use it.
- Recruit more people: while we are not in bad shape right now we could certainly use one or two more people to keep things moving along.
- Get our open bug count down.
[edit] Sparc Architecture
Homepage: http://www.gentoo.org/proj/en/base/sparc/
Author: Ferris McCormick (fmccor)
Last Update: 11th May 2009
We are an architecture team, so except for one developer (bluebird) who is actively working on true multilib support (64-bit userland), we are mostly reactive to bug reports for security, testing, and keywording.
Currently we have enough developers to pretty much keep up with demand. However, note the following:
1. We need arch testers. We use them to help with evaluating keyword requests and as a breeding ground for new developers. However, because of this all of our arch testers have become developers and we need to refresh the pool.
2. Although we currently are keeping up with requests, the work load is heavy enough that we face (in my opinion) a real risk of developer burnout. Thus, I would say that we are understaffed, although we have one or two candidates in process. I'd prefer to have about three more developers as well as arch testers as mentioned above.
So, short term, we are in reasonable shape. Longer term, we need to recruit.
[edit] wxWidgets
Homepage: (None Listed)
Author: Ryan Hill (dirtyepic)
Last Update: 11th May 2009
Mainly in maintenance mode, but that should be changing soon as the 2.9 development series is released. Major upcoming upstream changes will include the merging of release and debug libraries, and later on, the disappearance of separate ansi/unicode builds. Usage will become much simpler, probably to the point where we don't need the eclass/eselect/wx-config wrapper stuff any more (I hope).
2.8.10 will be in the tree as soon as wxpython makes a release.
The eclass needs some love and updating to EAPI 2, which I should have time to do sometime soon.
[edit] X11
Homepage: http://www.gentoo.org/proj/en/desktop/x/
Author: Rémi Cardona (remi)
Last Update: 11th May 2009
Short term or recently done:
- 1.5.3-r5 went stable (I'm sure y'all noticed)
- there will be another 1.5 stable server within a few weeks
- 1.6.x will go into ~arch pretty soon
- alpha is pretty much the only arch that doesn't have 1.5 keyword but thanks to frequent poking, things should change pretty soon
- 1.3 and 1.4 will get p.masked as soon as alpha and arm stabilize 1.5.3,
- 1.3 will get treecleaned during the summer, 1.4 maybe a bit later...
- the X11 overlay now has support for the nouveau driver and Gallium (thanks to a few external but essential contributors)
Medium term:
- libxcb 1.2 will be moved to portage once we figure out a sane way to handle the disappearance of libxcb-x11.so. For those who haven't heard or seen what happens during the upgrade, let's just say that the upgrade from expat 1.95 to 2.0 was a walk in the park compared to this.
- continue cleaning up useless libs and protos
Longer term:
- major Docs overhaul, what we have now is a complete mess. Any help with this is greatly appreciated. See bug 267769 for a short todo list.
- try to keep up with upstream X, even if it means upsetting some users. Actually forcing folks to upgrade to 1.5 has been very beneficial, a lot of bugs were uncovered and reported upstream.
Intel Driver Status Update:
- 2.6.3 is the current stable
- 2.7.0 is still p.masked, 2.7.1 will likely go in ~arch when it's out
- The next stable driver will probably be 2.8 once xorg-server 1.6 is in portage and deemed stable enough.
- The upcoming 2.8 branch will have a lot less code and options (no more DRI1, XAA, EXA, ...), making it easier to maintain and to use.
