[arch-dev-public] Status Report: 2007-12-11

Aaron Griffin aaronmgriffin at gmail.com
Tue Dec 11 23:56:48 EST 2007

ArchLinux Status Report, 2007-12-11
Aaron Griffin

I apologize for the delay here - yesterday was a long day for me, and I didn't
have the time to sit down and write this out (it is a tad time
consuming, as you can
probably tell).

== Newsworthy Items ==

* TLLTS Interview

I hate self-promotion as much as the next guy, but TLLTS wants to do an
interview about me tomorrow at 20:30 EST. Some of you may be interested. It'll
be freeform, so I don't know what we'll talk about, but it will probably be
related to where we're going in the near future.

More here: http://www.tllts.org/

== Completed Tasks ==

* Developer signoff clarification

When I originally initiated the "signoff" buffer for core packages, I had
intended that the developer requesting the signoff count as one of the "two
required" signoffs per architecture, as it is assumed a given developer tested
a package before uploading and is also responsible.

To clarify: We need two developers responsible for each physical package - two
for each architecture. These two can include the original uploader. These people
are responsible for any issues caused by this release of the package. They're
also the people we have to point fingers at 8)

* Mailing list rename

We've renamed two of our most important mailing lists, just for a change in
nomenclature. There's not much to say on this topic that wasn't covered in the
front page news:


* New netcfg scripts _still_ in [testing]

I want to poke this item here. I'd like to get some yays/nays here. I dropped
the ball on including the patches into an initscripts package in [testing] which
replaces the current netcfg scripts.

It's on my list - high priority.

More details here: http://archlinux.org/news/362/

* Packages in [extra]

I attempted to get some discussion here a few times, and not much came of it. As
such, here's the criteria for what goes in extra, and what goes in community.

   * Packages in [extra] define us as a distro and should not include
packages for
     personal use. If something is personal and/or only used by small amounts of
     people, it should go to community. Not only does this help us
with our vision,
     it also helps out our mirrors (not all mirrors mirror the community repo).
   * Devs should inform everyone if they're putting a new package into extra,
     just in case another dev has an issue with it, to prevent silly
bloat from too
     many personal packages. If someone has a problem with a package going into
     extra, a simple vote should suffice (no need to discuss it to death)
   * We should be prepared to remove contentious packages at any time. If
     someone claims "package foo doesn't belong in extra" and enough developers
     agree, we should simple move it to community and maintain it there.

* Unified chroot build tools

These chroot building tools have gone through some changes, and are in
successful use on my "micro build machine":


This machine is being used to cover developers and TUs who do not have x86_64
hardware and still would like to build the packages. This way, we can help out
the x86_64 guys immensely.

Future plans involve setting up a 32bit chroot on the same machine for the
converse of the above.

== Pending Tasks, Short Term ==

* Logo contest delay

We've hit a few snags trying to figure out issues with regard to setting up a
trademark for our new logo. Suffice to say that we HAVE chosen the top 5 logos.
And ARE moving forward with this.

Travis, could you provide us with a follow up email with all the fun details

* Bug tracker cleanup

This weekend Roman is planning to do a big bug tracker overhaul and attempt to
cleanup and consolidate our open bugs. Any help from the developers would be

I'd like to especially thank Allan McRae here too - I keep seeing him suggesting
bugs be closed, and he's been helping Roman out here too. Thanks for the hard
work. I'm very grateful.

* Bug Squashing Day revamp

We used to do official Bug Squashing days near the end of every month (second to
last Sunday, or something to that effect), but these have fallen by the wayside
due to Roman's awesome work.

Even so, I'd like to get back in the swing of doing this, as it will help keep
us all on track. Roman, would you like to help organize this? I will try to keep
track of the dates and everything, but it'd be nice if you could spearhead the

* Getting rid of /opt

We officially have a todo list here. Actually, we have two:

General packages: https://archlinux.org/todo/45/ (Thanks Jeff)
Mozilla specific: https://archlinux.org/todo/44/ (Thanks Alex)

It seems we haven't done a whole lot with this, though Paul's moved Eclipse out
of /opt (yay!). It'd be nice if we can get to these at some point - they're not
very taxing to change for the most part. Anyone willing to devote a night to
knocking out the easy ones?

* License Updates

This one is not easy or pretty - every so often, please take a look at the items
in the list and try to correct your licenses if they are wrong.


* ABS Redux

This task has been partially done/discussed around the water cooler.


The plan? To create a static directory which we can use to rsync ABS instead of
using cvsup. Dan has already sent some patches around. I will dig them up after
I send this out.

The easiest step here is to break ABS out from the pacman package - Dan, is is
possible for us to do this as part of the 3.1 release?

After that we can make ABS changes independent of pacman (and ABS is really an
Arch specific tool, while pacman/makepkg are not)

* Getting rid of CVS

Last status report, I pointed this guy out. Roman responded with a vote for
Jason's SVN proposal.

In summary:

   * Jason has provided us with an svn solution, where sub-directories control
     the location of the package (i.e. package-name/repos/extra/PKGBUILD will
     place the package into extra)
   * Dan has provided us with a git solution that uses named branches to control
     the location (i.e. a branch named "testing" has changes to PKGBUILDs
     present only in the testing repo)

I'm going to put my weight behind Jason's SVN proposal too, for the following

   * There is no reason to manage our packages in a distributed manner
   * SVN will be an easier transition for some users and developers unfamiliar
     with the esoteric commands of git.
   * It has a real implementation
   * One can use the git-svn porcelain on top of this, to still get the full
     power if git if they so wish.

So, the next steps: Jason, can you provide us with some more details on your
implementation, or perhaps something on gerolde as a preliminary system? I'd
like to setup something side-by-side for people to use and to play with a bit.
This way we can easily flesh out the hairier details.

Paul, you did some similar work with repoman, yes? Do you have anything to add
to this topic?

== Pending Tasks, Long Term ==

* Perl policy implementation

Kevin has been taking some of these on, and helping implement the perl policy.
It's a big task, and any help from perl gurus around would be appretiated.


* Pacman 3.1 Release

We're still cranking away here. Big thanks go out to Chantry Xavier, Allan
McRae, Nagy Gabor, and Nathan Jones for all the hard work. And thanks to all the
translators too: Giovanni Scafora, Jeff Bailes, and anyone else I missed.

Dan DOES have a pacman repo here with the latest and greatest pacman-git package
for those of you wanting to live on the edge:


Pending bugs for the release are listed here:

* Official pacbuild usage

This apparently has gone farther by the wayside with the machine I put out there
for non-x86_64 devs to build packages, taking some of the load off of the guys
who were waiting for pacbuild.

I'm not even sure of the state here anymore - Simo, Jason, any news? Would you
guys like root access to the build machine so as to have a place to RUN
pacbuild? Last I checked I did install it, but it isn't configured or the most
recent version.

* Modernize our Dashboard

Eliott has broken out our public and private sites, allowing us to, in the
future, mess with our internal tools without disrupting the external site, in
addition to applying improvements with regard to caching and all that fun stuff
on the public site.

The testing site URL should, for the time being, remain private - his original
email was sent to the private ML. Please test it and give us a thumbs up/down if
you have the time. You should be able to use it for all your normal public site
access, if you'd like to give it a thorough testing.

In order to garner more interest here, I'd like to get some docs or a script
setup in the git repo that would allow one to run a quick local instance with a
small test DB. Eliott, is this doable?

* Architecture Independent Repos

We have pacman support (for the 3.1 release) done thanks to Roman. We now have
an idea of where we want the new SCM changes to go. This means some rewriting of
the DB scripts are in order here.

So, with this in mind, we should be able to create these architecture
independent repos as part of the same push. Don't you love it when things fall
into place like that?

Here's the internal (private) task for anyone interested in this:

* ArchCon 2009: Big Baaad Idea

More details. Tom has suggested some dates for this. What do you guys think?


Pierre brought up a valid idea - we plan this around another convention that we
have a presence at. Doing this at Froscon would cover our German/European
contingent well, but we also have a chunk of developers on this side of the
pond. It'd be nice if we could give an island somewhere in the middle of the
Atlantic, but without massive volcanic activity, we're stuck with one side or
the other.

How to the Europeans feel about coming over here? And vice versa? Let's assume,
for the sake of argument, that money isn't the issue here. Opinions?

What about Canada? Birthplace of Arch AND it's not as dangerous as the US

More information about the arch-dev-public mailing list