2007/5/10, Andreas Radke <a.radke@arcor.de>:
after beeing an official port as a 100% i686 clone with a common cvs we have seen that we can handle the workload with only 2 man in not a bad way but with tons of hours of rebuilding and uploading the packages. but we don't want that anymore. it's simply too much workload and a task we are tired to do. bringing on new packagers is harder than expected. repo cleanups and a possible not to far away start of pacbuild/repoman will not drop down the workload we would need. i686 devs are not able to handle 32bit stuff very well so i don't count on crossbuilds anymore. that's one reason.
the other one is beeing an i686 clone depending on its (not well defined) goals makes me sick. i miss any freedom in my work. at least the poor i686 testing procedure is something i don't want to follow anymore. i got more and more afraid how chaotic the developement is going on whithout the possebility to change it. now i see things start changing what is very good. but it seems most devs want to keep i686 the compromise of beeing bleading edge + at least some stability.
i haved proved to build a system almost from scratch to the quality we now have. we are no more behind i686. a big part of that goes to the i686 devs and their most times simple and working packages and the easiness to port them. the Arch tools are great.
but my personal goals have changed. together with Daniel we have found a few people that would support us if can go our own way. We have worked out some initial goals:
- we want Arch x86_64 the more conservative sister distribution of Arch - less bleading edge - still a rolling system with up to date packages - strict rules how packages go through a testing cycle - we expect a significant lower workload due to longer update cycles and less post-release-fixing of broken stuff - only provide a basic core repo by the devs - setup some basic addon repos - open the addon repos to be maintained by the community and reviewed/released by the developers untill community members have proved to do it the same way. that's something where we are not sure where i686 wants to go and if we will adopt it.
- it would not be prepared to have an x86 port. but only one x86(i586?) dev would be enough to rebuild that distro with some help by an automated build system.
All in all it would be nothing significant different from the port we now have but packages would be more selected and hit the repos later to ensure the improved stability.
we want to do this all together with the ArchLinux developers and community. we want to keep using all the great tools and resources Arch already offers.
the first step that would need to be done is to splitout our scm. i cannot image to keep working with a common scm. that's what now makes it the clone we don't want to have any longer.
if you agree to give us that freedom back, i already have one good candidate for becoming a new x86_64 developer and several community members promised to help out. they all like our goals. at least that we will have some.
Few questions: What x86_64 users should do with those current/extra packages that won't go in your repo? What will be the status of AUR? Example: when there is package foobar-5.0 in AUR that depends on libabc-2.1 in our current/extra, but your arch64 repo will have only libabc-2.0 (which has incompatable API) - user will have to downgrade foobar PKGBUILD to 4.0 that compiles with libabc-2.0 (sorry if my explanation is confusing) Do x86_64 TUs agree to maintain separate set of PKGBUILDs compiled against your "stable" versions? And where to put those packages that are not in your current/extra, but are in ours, so they cannot go to Community? -- Roman Kyrylych (Роман Кирилич)