Remaining issues for the multi desktop DVD (was: Re: Dear Fedora board, please open your trac)

Stephen John Smoogen smooge at gmail.com
Wed Jan 12 02:10:11 UTC 2011


On Tue, Jan 11, 2011 at 18:06, Christoph Wickert
<christoph.wickert at googlemail.com> wrote:
> Am Dienstag, den 11.01.2011, 17:12 -0700 schrieb Stephen John Smoogen:
>
>> These are my questions at the moment:
>
> Hi Stephen,
>
> thank you very much for your questions. I wonder why you or the board
> didn't come up with these question back in October. Well, some of the
> questions were already raised, but I'm going to answer them once again.

I will give you a hint for future English as 2nd language
translations. The above comes across as snide, passive aggressive and
basically starting the reader off in a foul mood. You may be in a foul
mood but you did ask what the questions were, and I am asking the ones
that are mine. Other board members may have them but I am not a
collective brain who can ask for them.

>> 1) How is it going to be built within RH releng environment.
>
> With https://fedorahosted.org/multiboot-media-creator
> Does that answer your question?

It is a start. Infrastructure will need rpms to install on the spin
systems. Release engineering will need documentation. Once the project
is out of "total disarray" we can move forward.


>> 2) How is it going to be tested. I have yet to get dual layer DVDs to
>> burn with my laptop. (though I have not tried a blueray yet).
>
> The individual spins already have their test cases and were tested in
> great depth. We are only using the already tested ISOs, so the only
> remaining thing to test is if it actually boots and - perhaps - if it
> installs. So far it this has been tested by at least 3 different people
> and none of them found any problems. Please refer to ambassadors list
> for details. You can test this any virtualization that can boot of an
> ISO if you don't have a dual layer DVD recorder.

I am not an ambassador so can not look at the lists. Having done
various hardware testing in the past I have run into too many issues
where stuff works in X environment but not in actual Y environment.

> If your question is targeted at the physical media: We can never test
> them. We can give an ISO to the media production company, they make 3000
> disc of them and then it turns out they don't boot due to a production
> failure. This is something we can never test in advance, can we?

When we did this for a living, the steps were usually:

a) get a test run of 10-20 from manufacturers
b) get from manufacturer what their production error rate was so that
you can allocate extra orders to cover duds.
c) have the 10-20 run through several systems so that you can say
"boots on X system", "does not boot on Y system", "512MB systems can't
get to LXDE image for some reason" etc.
d) you then order your large batch and do a random quality test of 10
taken from the box to see how they work in your systems.

I am not sure how much that would work for EMEA but it is in general
how it used to be done in the day of boxed sets.

>> 3) Who is going to implement items into releng and testing
>
> I think the testing part was already covered and for the rel-eng side,
> I'd like to ask you to elaborate your question. What items do you have
> in mind exactly? Somebody needs to needs to run 'multiboot-media-creator
> foo bar baz' and then upload the result to alt.fedoraproject.org.

Ok any tool has to be built and working on the spins systems. So rpms
will be needed Then a guide and scripts needs to be written that
releng can follow.. as in.

1) Daily build spins for X,Y...Z
2) Run multiboot-media-creator X Y Z -o A
3) Copy over to mirrors system.
4) Expect it to take X time, and what to do when it craps out.

Also how much disk space and how a daily test can be done so that
after an image is built it can be shown to actually be a useful set.

Then there needs to be a stronger spins group. Personally having seen
the amount of "ah crap" work that Kevin Fenzi and Bruno did to keep
daily spins going says its not something that is working well (or been
working well). I would just say drop spins altogether for all the
technical and political problems they keep causing but know that would
be me cutting off the nose to spite the face.

>> 4) What logos are going to be used outside of the preinstalled images,
>> where and how.
>
> None, nowhere.

So no fedora logo on the DVDs nor anything on the top level menu that
boots into the multiple isos? Maybe a better question from me should
be What will the DVD's look like? And what will the initial boot menu
look like?

>> Those are the items I can think of outside of the proposed spin guidelines.
>
> I have no idea why you come up with the spin guidelines here. By
> definition the media nether a spin nor a remix. It's just a collection
> of spins, that were already approved, so they obviously must follow the
> spins guidelines anyway.

They each may separately do so, but the aggregate is considered a
different work... they also have to be shown to be build-able and
workable. I have dealt with too many iso within iso issues where you
can boot N of the Y images but the BIOS wont work on Y-N ones.. Or
where the install will boot up partially so it looks like its working
but can't because the BIOS got confused. [Most of this has been on
mainstream systems like Dell, HP and IBM.. ] And while it will work
every time on a virtual or even a USB key it won't as a DVD (or vice
versa).

[To allay the above concerns does not mean you have to test against
every hardware.. but more than 3. 10-20 systems can give you a good
guess on what it will work on and what it won't.]

> Regards,
> Christoph
>
> _______________________________________________
> advisory-board mailing list
> advisory-board at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/advisory-board
>



-- 
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren


More information about the advisory-board mailing list