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: http://archlinux.org/news/368/ * 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": http://www.archlinux.org/pipermail/arch-dev-public/2007-November/003130.html 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 here? * 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 appreciated. 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 initiative. * 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. https://archlinux.org/todo/43/ * ABS Redux This task has been partially done/discussed around the water cooler. http://archlinux.org/pipermail/arch-dev-public/2007-November/003224.html 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 reasons: * 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. http://bugs.archlinux.org/task/8374 * 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: http://archlinux.org/pipermail/pacman-dev/2007-November/009825.html Pending bugs for the release are listed here: http://bugs.archlinux.org/task/8109 * 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: http://bugs.archlinux.org/task/8555 * ArchCon 2009: Big Baaad Idea More details. Tom has suggested some dates for this. What do you guys think? http://archlinux.org/pipermail/arch-dev-public/2007-November/003310.html 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 (hah!).