Validation tests not yet run against Final

[Adam Williamson]

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