[arch-dev-public] Arch Linux Status Report, 2009-10-05

[Aaron Griffin]

Arch Linux Status Report, 2009-10-05
===================================
Aaron Griffin

Yes, a new status report. I haven't put one of these out in some time, and a lot
has happened since the last one, so bear with me here.

There is a lot being left out from this, because there's simply to much to
cover. We've had a lot of changes - repository oopses, server reinstalls, and
things of that nature - that I simply won't be able to cover without writing a
novel.


== Newsworthy Items ==

* Bug Squashing Day

We had our first bug squashing day in a long time. Thanks to everyone who
helped, it makes everything so much easier. Andreas and Paul, many thanks for
organizing this.

More details can be found here:
http://www.deelab.org/bash/2009/10/bug-squashing-day-results/

* kernel.org Tier 1 mirror

I just now setup a mirror for kernel.org. The use geo dns re-routing, so it
should work safely and quickly for any country. Additionally, this will get us
images on boot.kernel.org eventually, which is impressive.

Additionally, they have volunteered to be a tier 1 mirror so that others can
rsync from them.


== Completed Tasks ==

* Far too many to list

As stated above, a lot has happened since I last wrote one of these. We've had
numerous package rebuild frenzies, server reinstalls, code fixes, support for
architecture independent packages, and so many more things.

So, rather than try to cover all that, I just want to give my personal thanks
out to all the developers and TUs. You guys are the ones who keep Arch going
strong, and I appreciate all the hard work. It's amazing to see how much people
actually care about a lil' ol' Linux distro like this :)


== Pending Tasks, Short Term ==

* Web Server Hiccup

Seems like we had our web domU hang on us the other night. This is the second
time it has happened, and signs seem to point to it being Xen related. I would
like anyone with knowledge or experience here to see if you can find anything.

* Mirror Tiering

Handling proper mirror tiering will give us a few benefits, the first of which
being the fact that it will help us get rid of some of the "mirror not fully
synced" issues. It will also help minimize our bandwidth.

With the addition of the kernel.org mirror, and mirror.archlinux.no offering to
be a tier 1 mirror, I think we can safely send out an email to the mirror
admins, requesting a few more tier 1 mirrors. I'd say we shoot for around 5,
just to pick a number.

With these in place, we can begin the switch over. To do this, we'll simply:

   * Email all the mirror admins a list of the tier 1 mirrors
   * Have mirror admins chose a tier 1 mirror
   * Reply to us when changes are made
   * Remove their IPs from the DB
   * After a month or so, remove all IPs still pending (and keep a list of these
     offenders)

* Replacing cron with fcron

This was brought up on the ML a bit ago. It appears that most of us are in favor
of using fcron to replace our existing dcron. I would like someone to spearhead
this move. Any volunteers?

* Ensuring Package Quality

We run into package quality issues every so often. No, I'm not pointing fingers
or anything, I'm guilty of this as well. I'd like to institute some way to
ensure that our packages are of the proper quality before they hit the repos.
Ideas are welcome. Currently, I had the following ideas in my head:

   * Add some token to the PKGINFO indicating that makechrootpkg was used
     This has the con of requiring this tool, when people may be using their own
     chroots or tools for this.
   * Make db-scripts check packages with namcap, and reject them on errors
     This has the con of making the db-scripts slower.
   * Combine the above: Add a PKGINFO token from namcap
     We should all be running namcap anyway

* Support for community <-> extra moves

I would like to get db-script support that allows developers to move packages
across svn repos. This is actually fairly involved and should _try_ to include
history.

This should require ssh connections to each machine for a little boost of added
security. Implementation details beyond this have not been thought of.

* IRC Developer Meetings

We used to have regularly monthly meetings in IRC, where we'd all get together
and discuss things. We haven't done this in a while, and some of us have begun
to feel like we don't really know each other to well.

Well, let's try to change this. I'd like to schedule a developer's meeting for
some time in October. I'd like to tentatively suggest Saturday the 24th. We'd
all join #archlinux-dev and discuss things on the current status report at that
time, and cover any other itches we have that need scratching. Please suggest
times, or alternate days if needed.


== Pending Tasks, Long Term ==

* Early-userspace in uClibc

klibc has a slow development model, and it doesn't suit us too well anymore.
Initially there was promise, but things have come to a near halt. As such,
Thomas has proposed we switch from klibc to uClibc for our early-userspace. This
is a great idea.

This change should be near seamless to the users, but will require much work and
testing on our part. I'm sure Thomas could use some help if anyone is
interested.

I believe all the packages needed are checked into the repos, but mkinitcpio
needs changing and fixing.

Thomas, would you mind pushing your changes to a branch somewhere? Or even to
master if you're satisfied with them so far? This way we can all give you a
hand.

* Project TODO lists

This was brought up a while ago, but I don't see a lot of follow through. For
all our internal projects, I'd like to see some sort of public TODO list
somewhere. If you'd like to use the bug tracker, that's fine, just add a link to
the wiki page.

In the Internal Projects wiki page located at:
   http://wiki.archlinux.org/index.php/DeveloperWiki:Internal_Projects
we have lists of all the funny little things we maintain for our daily lives.
I'd like to see, on this page, some indication of direction for these projects.
This has already begun for the developer tools list. Pacman is most likely
exempt as it is much more public and active than the other projects, unless Dan
or Xavier feels like maintaining a list there :)

It seems tedious, but this will actually give us something to point at when
people say "How Can I Help?(TM)".

* Repo symlinking

This idea was put out by Jan a while ago, and I like it. It goes like this:
When we put a package in the repos, we stick it in some master directory - we'll
call it "packages" for now. Then a symlink is created, linking the "packages"
instance of the package to an architecture specific dir. When and if this
package moves repositories, the symlink is simply moved.

What does this give us? The ability to easily move things from testing to
core/extra without overwhelming our server during mirror sync (as mirrors will
already have the packages).

I think this is a great idea, and would require two things: db-scripts patches,
and a script to convert our existing repo.