Am Wed, 9 May 2007 13:18:01 +0000 schrieb "Noah Lorenzen" :

So does this mean the end of Arch64 as we know it? :(

probably yes. there's only a small chance to achive my personal goals together with i686 ArchLinux developers from now on. huge changes would have to be done very soon. and no more promises. but expect any other x86_64 project/fork/distribution i would start not beeing worse than Arch64 :P AndyRTR

2007/5/9, Alessandro Calorì :

2007/5/9, Andreas Radke :

...

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.

I didn't imagine you were just two guys keeping up this work. How could you manage all that work (and in such a good way)?

While speaking about man-power: are there some capable users willing to maintain x86_64 packages? Andy, if you know such people that are willing to become devs - please bring them on. I'm sure devs will vote for them. Also, will JGC be maintaining x86_64 of Gnome now? What's the status of pacbuild? That would help much too.

...

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.

That's a hard task to achieve because becoming a TU is really hard (Arch user from three months, keeping up packages on AUR for a long time...).

Is it? AFAIR there were no candidate voted down. To become TU you need only to post short introduction message to tur-users ML. The procedure of becoming a TU is not that hard, really (though, I must confess I was a bit scary to write my introduction :-) ) BTW, what's your AUR login?

...

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.

This would not respect the "Arch way" to be a bleeding edge distro...

That could be also archieved by offloading many uncommon packages to Community repo. Yeah, that will require more TUs, but they are easier to find, especially when we will do a good announcement (so to reduce the fear to be rejected). On the other hand it would be very good if some existent TUs become devs (and give out their packages and switched to maintaining official repos only, to reduce workload).

...

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.

In this case the differences from the i686 distro would increase, making the development more "chaotic"...

...

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.

That's exactly what we have right now!

The stable and extra repositories should contain only "stable" packages but in Arch the term "stable" assume a custom meaning: packages that compile, don't block and don't give major troubles using them. An example: GNOME and Esound daemon, considered "stable" either for i686 or x86-64, don't work togheter because ESD locks up gnome-panel during start-up (you need to manually restart the service to unlock it); in many other distros this is not considerable "stable".

Agree. (even though ESD + Gnome always worked fine to me)

...

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 agree.

...

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.

I would like to help (again) either in Arch project or out of it. If you need, just tell me where and when! ;)

I didn't understand what you meant here, Andy (about distro). -- Roman Kyrylych (Роман Кирилич)

2007/5/9, Calorì Alessandro :

Il giorno Wed, 9 May 2007 17:08:24 +0300 "Roman Kyrylych" ha scritto:

...

To become TU you need only to post short introduction message to tur-users ML. The procedure of becoming a TU is not that hard, really (though, I must confess I was a bit scary to write my introduction :-) ) BTW, what's your AUR login?

I'm an Arch user from just about 1 month and an Arch64 user from two weeks but I'm a linux user since 2004... my nick in AUR is "axelgenus".

However, I read the "requisites" to be a TU and they are somewhat discouraging... I mean:

1) maintain packages on community repo, yes of course but what packages? The best and more useful packages are owned by TUs... Now I'm writing a PKGBUILD for Neverwinter Nights' linux client but how many people will find it useful? It needs to download about 1GB from the bioware server (client + game resources).

2) be well regarded by the comunity... ok, that's obvious but how can I achieve this? I've been a Gentoo user for 2 years and I can't remember just one nick of the people who helped me on the forums... I hope italian users like me find the translations I'm going to do on the wiki useful.

3) be prepared to stay six months in the TU position... I've never made such long-term programs! If I become a TU is because I wanted to... why should I be forced to stay in TU position?

Hmm, I cannot find such text anywhere. Where did you read this? In fact, in order to become a TU nothing of the above is required. TUs should just know that you have enough skills for package building, porting and fixing (applying x86_64 specific patches etc.) and to vote "yes" for you. Having some packages is not _required_, there are other ways to show your skills. You can find a sponsor before or after the introductory message to tur-users ML (usually someone volunteers to sponsor a candidate). If at least one TU (your sponsor) finds you a good candidate, the discussion period and voting procedure begins.

...

That could be also archieved by offloading many uncommon packages to Community repo.

That's a great idea but I would like the package in community repo to be assigned both to the maintainer and the contributor. Example: I write the PKGBUILD for the program "foo"; if it's moved to community I can't continue to maintain the package because I'm not a TU. This only adds more work to TUs! That's about CVS/SVN/whatever access rights. Also, often a package in unsupported has many contributors over time, because people orphan and readopt it. You can send updated PKGBUILDs to maintainer directly or post in comments. Posting PKGBUILD as a comment (after TU adopted it) doesn't differ much from uploading new version to unsupported (before adoption).

...

On the other hand it would be very good if some existent TUs become devs (and give out their packages and switched to maintaining official repos only, to reduce workload).

I don't actually know how are devs and TU organized yet but I can suggest you one thing: as I said before it would be very useful if a contributor can maintain a package after it's added to the community repo. The maintainer should only watch over some contributors revising their work.

See above. BTW, there are cases where non-devs/non-TUs send updated patches that devs/TUs just review and commit to CVS.

However: why packages are builded manually? Can't they be builded automatically on some dedicated servers (at least one for each arch).

Pacbuild is on the way. -- Roman Kyrylych (Роман Кирилич)

2007/5/10, Calorì Alessandro :

...

You can send updated PKGBUILDs to maintainer directly or post in comments. Posting PKGBUILD as a comment (after TU adopted it) doesn't differ much from uploading new version to unsupported (before adoption).

I've already done this for a package in AUR (Transmission): I rewrote the PKGBUILD, I sent it as a comment and then... nothing. I emailed the new PKGBUILD to the maintainer... still nothing. When I wrote on the forum, another TU asked me to send the package to mOlOk because the maintainer wanted to drop it! Then he reviewed and replaced the old package with mine ( plus some diffs :p ).

Ah, so that was you. :-) -- Roman Kyrylych (Роман Кирилич)