On Mon, Oct 24, 2011 at 11:24 AM, Tom Gundersen wrote: <snip>

Maybe this requirement should be communicated more clearly (e.g. a comment in the standard pacman.conf)?

Great idea. I mean, as a non-[testing] user I get that guinea pig feeling which comes naturally with linux often enough. Don't miss to express that [testing] here is far from what other distros label with "testing" and will hopefully break your system (because we want to know). <snip>

[0]: a lot of the non-trivial bugs against my packages are discovered after they move to core, probably because the people with the right hardware/use-cases are not using testing.

Looks really like I keep missing all the fun. What the hell, I'll add [testing] to my pacman.conf tonight... cheers! mar77i

On Mon, Oct 24, 2011 at 06:53, Tom Gundersen wrote:

On Mon, Oct 24, 2011 at 1:40 PM, Martti Kühne wrote:

...

On Mon, Oct 24, 2011 at 11:24 AM, Tom Gundersen wrote: <snip>

...

Maybe this requirement should be communicated more clearly (e.g. a comment in the standard pacman.conf)?

Great idea. I mean, as a non-[testing] user I get that guinea pig feeling which comes naturally with linux often enough. Don't miss to express that [testing] here is far from what other distros label with "testing" and will hopefully break your system (because we want to know).

Depends on who you compare to, unlike certain other distro's who shall not be named, we actually compile, install and test our packages before pushing to testing. We really don't want any packages in testing to break anyone's system as that will lead to fewer people using it. However, there will obviously be problems from time to time.

Personally, I use testing on all my five machines (including for work), and never experienced a big problem (such as loss of data or a failed boot), but your mileage may vary ;-)

Cheers,

Tom

IMHO, one that doesn't count for much, I have to agree with Tom. I also have to agree with those making the point for watching the Arch Dev Public mailing list and reading the news announcements. I moved to Arch because it forces me to learn how to maintain my machines. It also allows me to compile my base and core packages to my machines architecture not a generic configuration. This is my system: Linux gandalf 3.0-pf #1 SMP PREEMPT Mon Oct 24 00:05:45 CDT 2011 x86_64 AMD Phenom(tm) 8450 Triple-Core Processor AuthenticAMD GNU/Linux This is my makepkg configuration: CFLAGS="-march=amdfam10 -m64 -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" CXXFLAGS="-march=amdfam10 -m64 -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2" This may not be an extreme, or even close to an edge case, but it might find something that a generic compile doesn't find. I've also discovered whether it boots or not, I can fix it. I will admit, as someone who has already responded on this thread can attest, I can ocassionally as a "I really should have known that" type of question. However, everyone screws up every once in a while, except me I'm perfect. The rest of this may be considered noise/off topic/thread high jacking but I'll try to make a point. Until I became disabled and had to retire in 2009 I was considered one of the best at what I did. I routinely trained people and wrote training manuals. It tooks years of having someone point out to me that I had the same response when training people that some experienced linux users have. If I had to tell someone more than once how to do it they got dressed down, after the third time I had no use for them. That was a hard lesson to learn. My son was an expert, definition of an expert -- a has been little drip, with Windows and worked as a support tech. He had the same opionion when training people, after the third how to do the same thing he had no use for them. The same son who was quick to point out how badly I treated people when trying to train them. I know answering the same questions over and over can be a pain and no one wants to invite "help vampires" but simply saying "don't use testing" just doesn't seem to be the right way to go. I've read the thread linked in the first email and I agree with the point made if, and I point out if and only if, it's done graciously. To many people, no names etc just generic people, jump in when the original poster doesn't get it and start slicing and dicing. Keep the commentary civil. Myra -- Life's fun when your sick and psychotic!

On Mon, Oct 24, 2011 at 5:52 PM, Leonid Isaev wrote:

Besides, one really doesn't have to enable testing in pacman.conf -- individual pacman -U will do, imho.

I've read that [testing] is all or nothing and you shouldn't cherrypick packages because you might break something. Somewhat relevant https://bbs.archlinux.org/viewtopic.php?id=127144

On Tue, Oct 25, 2011 at 12:19 AM, Leonid Isaev wrote:

On (10/24/11 18:00), Karol Blazewicz wrote: -~> On Mon, Oct 24, 2011 at 5:52 PM, Leonid Isaev wrote: -~> > Besides, one really doesn't have to enable testing in pacman.conf -- individual -~> > pacman -U will do, imho. -~> -~> I've read that [testing] is all or nothing and you shouldn't -~> cherrypick packages because you might break something. -~> Somewhat relevant https://bbs.archlinux.org/viewtopic.php?id=127144

That's where brain comes in handy :)

Yes, its a REALLY good idea to state that its okay to pacman -U individual [testing] packages on a public mailing list with at least some users who really don't know any better than to do just that.

On Mon, Oct 24, 2011 at 19:38, Oon-Ee Ng wrote: -~> > On Tue, Oct 25, 2011 at 12:19 AM, Leonid Isaev wrote: -~> >> On (10/24/11 18:00), Karol Blazewicz wrote: -~> >> -~> On Mon, Oct 24, 2011 at 5:52 PM, Leonid Isaev wrote: -~> >> -~> > Besides, one really doesn't have to enable testing in pacman.conf -- individual -~> >> -~> > pacman -U will do, imho. -~> >> -~> -~> >> -~> I've read that [testing] is all or nothing and you shouldn't -~> >> -~> cherrypick packages because you might break something. -~> >> -~> Somewhat relevant https://bbs.archlinux.org/viewtopic.php?id=127144 -~> >> -~> >> That's where brain comes in handy :) -~> >> -~> > Yes, its a REALLY good idea to state that its okay to pacman -U -~> > individual [testing] packages on a public mailing list with at least -~> > some users who really don't know any better than to do just that. -~> > Say I want to try package X, but instead I download pkgs X, Y and Z from testing. Now my scripts which rely on /proc/.../BAT0/* fail because pkg Y is a new kernel, /dev/cdrom is gone since pkg Z is udev. And all I wanted is to try out new qemu-kvm... IMHO saying that testing is for experienced people is misleading since "experienced" is a vague term; such statements only repell users. A useful guideline would be "think three times before you type and understand how package management works". -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

On Tue, Oct 25, 2011 at 10:56, Tom Gundersen wrote:

On Tue, Oct 25, 2011 at 4:58 PM, Leonid Isaev wrote:

...

Say I want to try package X, but instead I download pkgs X, Y and Z from testing. Now my scripts which rely on /proc/.../BAT0/* fail because pkg Y is a new kernel, /dev/cdrom is gone since pkg Z is udev. And all I wanted is to try out new qemu-kvm...

IMHO saying that testing is for experienced people is misleading since "experienced" is a vague term; such statements only repell users. A useful guideline would be "think three times before you type and understand how package management works".

Cherry-picking might work, but we are not even trying to make sure it does, so it would be by coincidence.

-t

To All: To clarify what I do, I build my base and core packages from testing compiled to my architecture. If anything else is broken I have to find the error and fix it, wait for the broken package to be updated, or find an alternative that does work. The working alternative is sometimes better than the original. By that I mean a lighter weight app, one that forces the user to think about what they're doing, or actually works better just doens't have all the bells and whistles. That's my version of knowing how to use and take care of a computer. That's one reason I like Linux. I don't think it's for everyone, but neither do I think a blanket statement about users that don't know any better might just hinder the learning process. I once had a manager, who after I'd made a fairly serious and costly error to the tune of about $60000 circa 1978, made the statement "If you never screw up your not out there doing anything." I agree with Tom about not cherry picking just for the sake of doing so, but don't turn people off to using testing. IMHO it helps find edge cases and bugs that might not be found for years. This is turning into a rant from me about knowing how to use a computer besides turning it on and clicking the mouse. Seems like I'm highjacking an earnest discussion but can't seem to see the side that says don't do that. Maybe I should put my money where my mouth is and try to write a wiki article on the plusses and minuses of using testing and let people critique that. Myra -- Life's fun when your sick and psychotic!