congratulation. we have won! our gcc-gcj is broken due to a major feature addon the developer made right before he orphaned it. we (Hussam who does i686 rc packages and me) are no more able to build OpenOffice.org standing a few days before the 2.2.1 release candidate. this is not to blaim that developer but for any other developer and all users not using the testing repo. but this is only the peak of all the chaotic "development" as we call it. untill now we used have one ArchLinux tree now having two architectures officially supported (i686+x86_64) based on simplicity and pacman repo manager as its basic parts. Having the latest stable package version was the goal. we have put more and more packages into the current+extra repos. important packages we want to test for a while in our "testing" repos. sadly it's not worth the name. almost nobody uses it. even not all developers as highly recommended. continously we put packages with major issues into the stable repos. we from the x86_64 port are only 2 guys rebuilding and maintaining ~2500 packages. we have not the power and possebility to change anything important. from my point of view we have passed a point where this concept won't work anymore. we have a poor developement infrastructure compared to other distributions. we slow down our package release process due to many developers beeing busy with other things (real life and more). but then we force us to push things very quickly into the repos to satisfy our own old goals. well. not more with me beeing responsible for the Arch x86_64 port. some ways are possible: 1) improve the infrastructure and increase the manpower of developers and packagers for all supported dramatically. we are trying that for over a year now without any noticable real success. 2) dramatically lower the work(=less binary packages) for the devs to give them time for making packages of a better quality. doubt came up as Arch should remain a supported binary distribution in most parts. 3) new goals for ArchLinux: accept to have not well tested packages when we want to keep the update speed or accept a lower speed on update to get new packages better tested. 4) split the goals we have! let's have one more conservative stable rolling rellease tree for higher quality and one on the bleading edge front accepting it might break sometime. I've brought it up several times: i'm no more willing to be the dump rebuild monkey. wha i suggest is a mix of 3) and 4). there is only one working other distribution based on pacman out claiming having a stable tree. I've talked to several devs and users and they can imagine that a stable distribution by ArchLinux can become a successor. I'm going to start a new project based on what we now call ArchLinux for a new more stable but easy to maintain distribution. I would like to do this for ArchLinux. But I have also no problem if you totally dislike that and say it's a NoGo under the name of ArchLinux. Everybody who wants to help out or has something to say may post here or contact me on one of my instant messenger accounts you find in the forum. AndyRTR