On Fri, 2013-06-21 at 06:16 -0400, Kamil Paral wrote: > > On Thu, 2013-06-20 at 09:19 -0400, Kamil Paral wrote: > > > Based on Josef's script, this is the list of test cases that really need > > > testing (not tested at all during Final, or tested long time ago): > > > > > > QA:Testcase_USB_stick_Live_luc > > > > The fact that https://bugzilla.redhat.com/show_bug.cgi?id=976415 exists > > rather implies that pschindl has tried this, so perhaps he can file a > > result for the test? > > Yeah, he tried it because I asked him to do so, after I sent out this email :-) > > As a heads up: I'm very disappointed from the state LiveUSB creator is > in. Yesterday it wasn't able to detect a flash drive for me. I'll try > today again and report bug if I can reproduce. Generally LiveUSB > creator is very picky on the medium partitioning and every time I use > it, my feelings are "That bloody tool never works correctly, why do we > even use it?". I pretty much agree, but the reason's fairly simple: it really is the only remotely 'friendly' tool for Windows users. There are Windows dd-alikes out there and we mention them in the documentation, but they're kind of a pain. > Once F19 is out, I'd like to start a discussion how we can do better. > I'd love to see us participating on some upstream project rather than > developing our own project instead. For heaven's sake, 90% of that > code is the same for any distributions out there, there is no need to > nurture a NIH syndrome here. I wouldn't mind that in theory, but we definitely have a much tighter loop in updating our own official tools than updating a third party project. We could carry patches if we really needed to, though, I suppose. unetbootin would be the obvious third-party project to support. > > Also, it would be nice if we could trim down the number of "officially > supported" ISO->USB conversion methods. Unfortunately they each have a clear use case: dd is by far the simplest and actually most likely to work at any given time these days, but it is limited in capability (no data preservation, no persistent storage) and not a great fit for Windows. litd is the most capable and more reliable than luc (though slightly less than dd), but not available on Windows or reliably available on non-Fedora distributions. And luc is the least worst choice for Windows and necessary on non-Fedora distros if you want to do something dd can't do. If there's a way to square that circle I agree it'd be nice, though. Perhaps combine luc and litd into a single tool with a unified backend and GUI/TUI front ends? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
