-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/19/2010 04:22 AM, Christoph Wickert wrote: > Am Dienstag, den 19.10.2010, 00:09 -0700 schrieb Jesse Keating: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/19/2010 12:01 AM, Christoph Wickert wrote: >>> Am Montag, den 18.10.2010, 20:35 -0700 schrieb Jesse Keating: >>> >>>> There is not going to be a TC2. We are moving on to RC. >>> >>> Is this process documented in the wiki somewhere? >> >> http://poelstra.fedorapeople.org/schedules/f-14/f-14-releng-tasks.html >> is probably the best place, which was linked to from >> http://fedoraproject.org/wiki/Schedule > > The list only memtions the Tc, but nether TC1 and TC2 not the fact that > TC2 does not include live media. It mentions TC because there is only one Test Compose that is scheduled. Any additional test composes would be out of the normal and unplanned for. It isn't a case that TC2 does not include live, it's a case that there is no TC2. > >>>> It is FAR too >>>> late to be introducing technology that needs to be tested and planned >>>> for at this stage in the release cycle. >>> >>> The only thing that needs testing is the boot menu. The rest is taken >>> care of by the normal spins/desktop testing we already do and did. >> >> That's still something that needs testing, needs a testing plan, needs >> coordination. Not something that can easily be slapped together in the >> less than one week since the concept became visible here. > > What is there to test for a boot menu? What would a test plan look like. > Boot all menu entries and you are done. Have you attempted doing installs from each booted system? What if somebody tries to make a USB device out of that iso? The testing might be easy, but my point is that QA has no test plan for it, nor have they allocated resources or time to execute the test plan in order to pass or fail this offering. To try and get time to validate a test plan, no matter how easy it is, and to get time allocated to produce release candidates, distribute them, and execute the test plan at this point is really asking for too much. We're under the gun to get our already planned for test execution complete on time. Adding more will not help. > >>>> I still haven't seen any plan for how to handle our source obligation. >>> >>> I cannot give you a plan if nobody outlines the obligations to me. >> >> You need to speak to Fedora legal to figure out what your obligations are. > > I have written them but no reply so far. > >>> Why is the DVD different than the other spins? >> >> All the other things the project produces are made available on the >> website in binary form, alongside the source. It is not clear to me if >> your combined media set will be made available online in any way. > > In my first email I wrote: > >>> Given that [...] >>> * we have download location for the image on Fedora >>> infrastructure >>> * we put a readme on the spin whith the download location of >>> the SRPMs > > Is there anything unclear about it? Sorry, I missed that. Fedora Infrastructure approved an additional 8~ gig iso to be hosted and mirrored? > >> It is >> not clear to me if a binary aggregate of all the spins can be satisfied >> by the sources we have online. It is not clear to me what method of >> GPLv2 source obligations you will be using when distributing these >> binary offerings. > > This sounds a little vague to me. Can you please outline your concerns a > little deeper? AFAICS they apply to the other spins too as they also > have a boot menu. > > What is the difference between shipping 8 single media and one dual > layer DVD? The only difference is the boot menu. > You are correct that there is little difference between this and others. It has been an agenda item of mine for quite some time now to revisit how we do physical media offerings under the name of Fedora. It is of my opinion that we are not doing them correctly, but I am not a lawyer, and I haven't had the time to take it up with Fedora Legal as of yet. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky9yukACgkQ4v2HLvE71NXXHQCfaEQdvfN/LxjWuvbXrJmrNNpr qPoAn2yZEsF6g+BzITPLkGXhIQFb5ZGt =N0Sc -----END PGP SIGNATURE----- _______________________________________________ advisory-board mailing list advisory-board@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/advisory-board
