On Fri, 2009-02-27 at 15:28 -0800, Jesse Keating wrote: > On Fri, 2009-02-27 at 14:32 -0800, Adam Williamson wrote: > > Email breaking is rather unlikely. I don't think there's many people > > left who keep all their actual email in a single client and cross their > > fingers that it won't break. Everyone uses some kind of remote server - > > mostly, let's face it, GMail these days (though die-hards like me are > > still running their own IMAP server, or using their ISP's, or > > something). In that case you can usually use any one of several dozen > > client apps to access your email, or the web interface. > > The mail may still be accessible, but all the flagged mail and the > search folders and such that help me do my job are lost when Evolution > stops working (which is often). That makes a serious dent in my ability > to get stuff done. Same when my calendar can't be brought up. I miss > appointments etc... Flags should be stored by IMAP, but OK for the other stuff. I'd like an easy personal calendaring server system. That'd be nice. You can sorta use Google Calendar, but then you're back to relying on Google to stay up and not be evil, which I don't rely on at all...le sigh. > > > > How often does Rawhide really fail to boot? I mean, really? So bad that > > you can't fix it with a single kernel parameter or booting last week's > > kernel or something? This is part of the reputation inflation thing I'm > > wondering about. It just doesn't match my experience of dev branches. > > Multiple times a release cycle. Particularly if we're going to be > working on things like new initrd creation systems and new init systems. See above - you can always boot last week's kernel. Breaking the initrd generation can only screw up kernels that get installed *after* the breakage. So just boot a kernel from before stuff got broken, then generate a working initrd for the newer kernel manually. > In previous rawhide cycles wireless has frequently broken, both driver > and software to manage it. There were also days when the vpn software > didn't work for various reasons. Ok, then. But then, that's the sort of thing that having more people using Rawhide should lead to happening less often. I don't think there's really any intrinsic reason wireless drivers have to break very often in a dev branch. (And again, you usually have the option of booting a known-good kernel in this case). > I don't disagree with that. I'm just not going to paint a picture where > using rawhide as your main system won't lead to downtime and lost > productivity. And as many people state, we're not going to find those > important bugs until somebody does use it as their main system, either > rawhide, a snapshot, or the final release. > > I'm more convinced that we'll get far faster/better results by investing > more time/effort/code into the automated testing system. I think they're complementary. Automated testing is great, but it can never catch everything, it's probably not really going to get close. And automated testing should make Rawhide more reliable and hence help out with this side of things (having more real fleshy people use it and yell when stuff breaks). And there are people who can get involved in one side but not the other (as you can see I have a great talent for poking at difficult areas, but I couldn't write an automated test for *anything*...) I don't see why there needs to be an opposition, really. And this whole idea about having more people run Rawhide doesn't involve any 'extra' coding. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
