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
2007/5/9, Andreas Radke a.radke@arcor.de:
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)?
- 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...).
- 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...
- 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"...
- 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".
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! ;)
AndyRTR
Bye, Alessandro.
So does this mean the end of Arch64 as we know it? :(
On 5/9/07, Alessandro Calorì axelgenus@gmail.com wrote:
2007/5/9, Andreas Radke a.radke@arcor.de:
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)?
- 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...).
- 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...
- 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"...
- 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".
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! ;)
AndyRTR
Bye, Alessandro.
arch-ports mailing list arch-ports@archlinux.org http://archlinux.org/mailman/listinfo/arch-ports
Am Wed, 9 May 2007 13:18:01 +0000 schrieb "Noah Lorenzen" noahlorenzen@gmail.com:
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
So if you make a new fork/distro, how similar to Arch will it be? Do you plan on making it very different than how Arch currently is? I would be very interested in helping the project, but I don't know how to program... I'll try to do what I can.
On 5/9/07, Andreas Radke a.radke@arcor.de wrote:
Am Wed, 9 May 2007 13:18:01 +0000 schrieb "Noah Lorenzen" noahlorenzen@gmail.com:
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
arch-ports mailing list arch-ports@archlinux.org http://archlinux.org/mailman/listinfo/arch-ports
2007/5/9, Alessandro Calorì axelgenus@gmail.com:
2007/5/9, Andreas Radke a.radke@arcor.de:
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.
- 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?
- 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).
- 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"...
- 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).
Il giorno Wed, 9 May 2007 17:08:24 +0300 "Roman Kyrylych" roman.kyrylych@gmail.com 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?
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!
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.
However: why packages are builded manually? Can't they be builded automatically on some dedicated servers (at least one for each arch).
ESD + Gnome always worked fine to me
Lucky man!
I didn't understand what you meant here, Andy (about distro).
I guess he want to split Arch64 from Arch to another separate distro.
Bye, Alessandro.
2007/5/9, Calorì Alessandro axelgenus@gmail.com:
Il giorno Wed, 9 May 2007 17:08:24 +0300 "Roman Kyrylych" roman.kyrylych@gmail.com 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:
- 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).
- 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.
- 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.
Il giorno Wed, 9 May 2007 20:34:50 +0300 "Roman Kyrylych" roman.kyrylych@gmail.com ha scritto:
Hmm, I cannot find such text anywhere. Where did you read this?
http://wiki.archlinux.org/index.php/TU_Person_Specification
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.
Ah, I see... so if I want to become a TU I have to introduce myself to the TUs mailing list and to prove my skills... uhm... my mail is on the road! ^___^
(I'm going to write the introduction mail to TU ML after I'll come back home from work...).
That's about CVS/SVN/whatever access rights.
Yes I know... I'm a developer and I worked with Subversion before but I guess it's possible to implement a kind of "queue" in AUR that maintainers can watch.
Also, often a package in unsupported has many contributors over time, because people orphan and readopt it.
Well, that's not a problem... when an AUR user want to adopt a package I guess it's registered in a database. A script could give temporary access to the particular CVS/SVN directory of the package to the contributor (yes, I know it's not that simple but this really needs to be semplified).
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 ).
Pacbuild is on the way.
That's will lightify the work of TUs but packages still need to be patched and then WELL tested...
Bye, Alessandro.
2007/5/10, Calorì Alessandro axelgenus@gmail.com:
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. :-)
arch-ports@lists.archlinux.org