You are not logged in.
Pages: 1
As an Arch fan, I completely understand and agree with Arch's philosophy, happily follow the bleeding-edge current, however, there's not alway happy memory or reality is cruel. Everybody will say: sure, since it's bleeding-edge, but we should try our best to reduce the side-by effect.
I think the Arch package working flow should be changed to make sure consistent high quilty, here ia my humble thoughts:
"test" -> "current" -> "release" -> "possible roll-back repo"
"test": every package should firstly become a test package before it can be merged into current, and according previous experience, we decide how long a test package should be safe to move into current repo, say, mozilla firefox, currently mozilla org just released the preview version, but everyone has used it will admit it's really stable. Such applications could be move to current after just one week or less test life, or on the contrary gcc glibc with NPTL. What's more I don't think we need such 1t1 suffix, all file in test repo should be it (so we don't need recompile it just for suffix change). Some package like gnome should assignate more time to test but if we get it prepared when beta or RC stage (many applications specially big ones have usually a development stage, when it hits beta, we should put it into test repository so as many as possible people can test it before move them into current. For example, gnome RC version, we can compile it and put them into test repo, then people can test it. Certainly that will require much more devs but if it's only related to compilation, many in the community are willing and able to contribute it, I mean dev writes PKGBUILD, others do it. Well I mean package maintainer should be a little team instead of just one person, so we can get JGC not to complain but become one of gnome package maintain team since he/she has willing and time and skills), and as many as pssible people has tested it, we can absolutely reduce the test duration. Need any unstable repos, all of them move into 'test'.
In one word "test" should become really bleeding-edge and buffer of "current" repo.
"current": the current repo should remain only officially released application unless application or project which original devs don't release them for quite a long time but some other packages depend on.
"release": should be a simple snapshot of current like now when Judd feels it's right time to release new ArchLinux.
"possible roll-back repo":could/better not be in the ftp, but user can define it on her/his box--given path, pacman can make use of it --say a simple pacman =rb package-- when user wants, or even automatically move old packages into it, if it's against Arch's philosophy, let other little script takes it or forget it.
Everyone, Talks about yours please.
Thank you for your time.
Offline
Have you had any problems with the way it works currently? Let me rephrase: this is not much different from the way it currently works, how would this new scheme prevent problems?
Offline
this is not really the way it works. testing is underused and it is evident with the frequent posts here after big upgrades such as Xorg and some of the recent kernels. Xorg spent a mere three days in testing before it was unleashed to devistate many users.
AKA uknowme
I am not your friend
Offline
I hope you aren't under the illusion that this is a new suggestion.
Offline
this matter has been up over and over again,
it aint gonna happen is the simple answer I've been given before,
I still think that Testing should be used a little more though...
arch + gentoo + initng + python = enlisy
Offline
I still think that Testing should be used a little more though...
Yes, this ia what I mean. Still define current by default when using pacman to upgrade system, but like now, set test here in the pacman.conf, so many brave users -- I believe there are many of my type, and I think they are possibly more time and patience and skill to deal with problems since they usually meet much more problems -- could dig out the problems and iron the bugs before explosing to all users of Arch, and that will absolutely increase "user's satisfication" and good reputation of Arch. Do you still remenber an article posted in the osnews, unfortunately the writer happened to meet the bad gnome 2.6 time, anyway it's not good for Arch.
Offline
unfortunately the writer happened to meet the bad gnome 2.6 time, anyway it's not good for Arch.
And, in case you didn't notice, 2.8 is spending plenty of time in testing, and has recieved many fixes do to feedback from 'brave users'. Also, if you aren't always cleaning out your pkgs, you have a rollback repo on your PC. My suggestion is that you keep a copy of the currently installed versions of major pkgs (at least) on your PC, so as not to be affected by a major update gone wrong. Personally, having truly rediculous resources at the time, I have every pkg that I've downloaded since the installation, and don't see that stopping anytime soon.
If you develop an ear for sounds that are musical it is like developing an ego. You begin to refuse sounds that are not musical and that way cut yourself off from a good deal of experience.
- John Cage
Offline
Testing needs to be used more. Pacman needs to go in testing before being released. Pacman 2.9.1 was useless and broken.. It never went into testing... Packages used by most/all arches (xorg, pacman, firefox, thunderbird, kde, gnome) should definately, without a doubt, spend a week in testing. I am proud of how long gnome 2.8 has been in testing, but other packages need to go as well! Testing is there for a reason! Use it!
If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing. 1 Corinthians 13:2
Offline
I'd be a little worried about Arch becoming Debian if stability is taken too far. The worst part is, Debian's now an organizational nightmare, and no longer all that stable. 'current' is and should always be as up2date as possible, without risking possibly critical parts of a users system. The fact is, Arch doesn't have a certain time that we know all pkgs will work exactly as they're supposed to, and because of this, more problems are fixed by staying current than sticking with the 'release' repo, or a similar measure.
If you develop an ear for sounds that are musical it is like developing an ego. You begin to refuse sounds that are not musical and that way cut yourself off from a good deal of experience.
- John Cage
Offline
Haha, let me make my thoughts clearer:
1. All or at least most of packages go to test repo firstly.
2. Duration of test should depent on the feedback of packages from devs/ users, or previous experience.
3. Remove 1t1 suffix of test packages to normal suffix.
4. It's better we could make an Arch package following the big application own beta stage.
Offline
I'd be a little worried about Arch becoming Debian if stability is taken too far. The worst part is, Debian's now an organizational nightmare, and no longer all that stable. 'current' is and should always be as up2date as possible, without risking possibly critical parts of a users system. The fact is, Arch doesn't have a certain time that we know all pkgs will work exactly as they're supposed to, and because of this, more problems are fixed by staying current than sticking with the 'release' repo, or a similar measure.
well i doubt you would ever get a debian scenario here. first off packages are slow to move downstream there because stability to debian is stability for all the architectures it supports. ... which is alot of architectures. arch only officially has one architecture to support.
further we are not talking a matter of weeks or months I would think two weeks max would be sufficient. not to mention i don't think alot of packages would have to go through testing simply because the usership of them does not warrant it. in those cases any bugs that came up should be fixed promptly though.
to me it is unacceptable to have major packages released with major bugs. i know it is great to claim to have Xorg or KDE before any other major distro but if it is unusable and costs users then what good is it. The bugs that were in Xorg, for example, should have been caught in three days because the person who maintains it should have tested on various desktop environments and wm's. knowing that most users will tweak their desktop environment it should have been tested with a modified kde desktop. it only makes sense.
AKA uknowme
I am not your friend
Offline
How can we assure that apps are well tested if not enough people are testing it?
Probably that's the reason why the Debian community lives on "current" and forgot about "stable". People care more about testing and fixing new stuff than to manage a stable release.
Bruno
Offline
actually debian "testing" is far more stable than most people think. It is also far more "actively developed" than stable because stable is essentially frozen. testing at debian is what will become the next "release".
Lots of people use testing because it is at least somewhat "current" (meaning about four or more months behind a distro like arch package version wise) and it is far more stable than their development repo (unstable) which can often break.
as for the trust issue .... no idea there i have no clue on arch user numbers and how many of them use the testing repo. if people want a package bad enough then they WILL add testing to their pacman.conf.
AKA uknowme
I am not your friend
Offline
I came to Arch from Debian... I must say that it's been FOREVER since they've updated what's stable what's not... Arch's way is MUCH better IMHO...
I really would like to see more packages sit in testing... (I'm one of those brave Gnome 2.8 users, and have posted bugs and saw them resolved ) I think that if we make use of testing more then our problems are solved... There's no need for a stable repository as you could just go download whatever is the latest 'snapshot' release of arch the Vinet puts on the website...
If people need some CPU cycles for compiling I'd be more than happy to build some packages.. I just haven't taken the time to learn the whole ABS system... but if it comes down to all i have to type is mkpkg, wait, and then upload some files... then I'm your new volunteer.... (Shoot me a PM devs)
Yes we've had some probs with the xorg releases, and the pacman releases, and Gnome 2.8 wasn't released perfect... but hell... it was pretty damn close to perfect... I've been sitting on the testing gnome 2.8 for more than a week and after the first day bugs i haven't encountered any others....
The system as it is is 'working.' The blueprint for a great package heirarchy is there. We only need to make more use of testing.
Offline
Pages: 1