Criterion revision proposal: KDE default applications

[Adam Williamson]

It was clear at the Go/No-Go meeting today that KDE SIG does not
consider this release criterion applicable/desired:

"All applications that can be launched using the standard graphical
mechanism of a release-blocking desktop after a default installation of
that desktop must start successfully and withstand a basic functionality
test."

https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...

jreznik says they consider the live image their 'polished product' where
everything must work, while the DVD install is more of a grab-bag - they
install a whole bunch of stuff, and don't think it's the end of the
world if one or two bits are broken.

Given that, I propose re-wording as follows:

"All applications that can be launched using the standard graphical
mechanism of a release-blocking live image after an installation of that
image must start successfully and withstand a basic functionality test."

So, that doesn't just apply to KDE. True, but I actually think it's a
reasonable revision for GNOME as well. It makes sense to see the live
images as defining what our 'polished core desktops' consist of, and the
DVD as more of a grab-bag of packages. The lives will (should) always
contain the bits the desktop SIGs think are absolutely key pieces of the
desktop. And I think we could generally do with a bit of criteria
watering-down; we're starting to do a lot of fudges and waives, which
indicates the criteria are currently too tight for us to realistically
enforce. Things are better when we can stand solidly behind the criteria
without fudging stuff.

CCing KDE and desktop lists. If folks feel that we should restrict this
change to KDE only, please do yell, but I'm kinda liking the simple
version.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Jóhann B. Guðmundsson]

On fös 13.des 2013 02:05, Adam Williamson wrote:
>  It was clear at the Go/No-Go meeting today that KDE SIG does not
>  consider this release criterion applicable/desired:
>
>  "All applications that can be launched using the standard graphical
>  mechanism of a release-blocking desktop after a default installation of
>  that desktop must start successfully and withstand a basic functionality
>  test."
>
>
> https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...
>
>  jreznik says they consider the live image their 'polished product' where
>  everything must work, while the DVD install is more of a grab-bag - they
>  install a whole bunch of stuff, and don't think it's the end of the
>  world if one or two bits are broken.
>
>  Given that, I propose re-wording as follows: 
You are trying to fix the problem on the wrong end thus leave the 
criteria as is.

The installing should not differ ( or in other word be consistent ) 
regardless if you install from the live or from the dvd the end result 
should be the same.

You should have the same service enablement, the same desktop instalment 
and experience etc.

So get releng to get their act together and fix that for the dvd so 
matches with the live.

JBG

[Adam Williamson]

On Fri, 2013-12-13 at 05:31 +0000, "Jóhann B. Guðmundsson" wrote:
>  On fös 13.des 2013 02:05, Adam Williamson wrote:
>  > It was clear at the Go/No-Go meeting today that KDE SIG does not
>  > consider this release criterion applicable/desired:
>  >
>  > "All applications that can be launched using the standard graphical
>  > mechanism of a release-blocking desktop after a default installation of
>  > that desktop must start successfully and withstand a basic functionality
>  > test."
>  >
>  >
> https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...
>  >
>  > jreznik says they consider the live image their 'polished product' where
>  > everything must work, while the DVD install is more of a grab-bag - they
>  > install a whole bunch of stuff, and don't think it's the end of the
>  > world if one or two bits are broken.
>  >
>  > Given that, I propose re-wording as follows:
>  
>  You are trying to fix the problem on the wrong end thus leave the 
>  criteria as is.
>  
>  The installing should not differ ( or in other word be consistent ) 
>  regardless if you install from the live or from the dvd the end result 
>  should be the same.
>  
>  You should have the same service enablement, the same desktop instalment 
>  and experience etc.
>  
>  So get releng to get their act together and fix that for the dvd so 
>  matches with the live. 
Per my long reply on the other sub-thread, I'm fine with that if it
actually _happens_. But it's not releng's responsibility; it's the KDE
and desktop SIGs. They own this stuff: it's their responsibility to
choose what packages go in the lives and what packages are deployed when
you do a DVD install of their desktops.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Jóhann B. Guðmundsson]

On fös 13.des 2013 06:30, Adam Williamson wrote:
>  On Fri, 2013-12-13 at 05:31 +0000, "Jóhann B. Guðmundsson"
> wrote:
> > On fös 13.des 2013 02:05, Adam Williamson wrote:
> >> It was clear at the Go/No-Go meeting today that KDE SIG does not
> >> consider this release criterion applicable/desired:
> >>
> >> "All applications that can be launched using the standard graphical
> >> mechanism of a release-blocking desktop after a default installation of
> >> that desktop must start successfully and withstand a basic functionality
> >> test."
> >>
> >>
> https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...
> >>
> >> jreznik says they consider the live image their 'polished product' where
> >> everything must work, while the DVD install is more of a grab-bag - they
> >> install a whole bunch of stuff, and don't think it's the end of the
> >> world if one or two bits are broken.
> >>
> >> Given that, I propose re-wording as follows:
> > You are trying to fix the problem on the wrong end thus leave the
> > criteria as is.
> >
> > The installing should not differ ( or in other word be consistent )
> > regardless if you install from the live or from the dvd the end result
> > should be the same.
> >
> > You should have the same service enablement, the same desktop instalment
> > and experience etc.
> >
> > So get releng to get their act together and fix that for the dvd so
> > matches with the live.
>  Per my long reply on the other sub-thread, I'm fine with that if it
>  actually _happens_. But it's not releng's responsibility; it's the KDE
>  and desktop SIGs. They own this stuff: it's their responsibility to
>  choose what packages go in the lives and what packages are deployed when
>  you do a DVD install of their desktops. 
The DVD is releng/fesco responsibility, they dictate and decide what's 
on it and what not and how it's delivered not the sub-community's.

There are other differences then just the package selection that get 
installed for example which services are enabled etc. compared to the lives.

I argue that we should get rid of the DVD it's an era of the past and 
just provide net-install iso and lives.

Those lives should be under full control of the sub-community both in 
terms of size,partitioning, filesystem layout.filesystem type, package 
selection as well as service enablement even to the use an alternative 
installer but those sub-community should also be responsible for QA-ing 
( testing/triaging  ) as well as the necessary release engineering work 
to release their own lives..

JBG

[poma]

On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote:

>  I argue that we should get rid of the DVD it's an era of the past
> and 
>  just provide net-install iso and lives. 
Probably there are good reasons why the DVD is still here.


poma

[Gene Czarcinski]

On 12/13/2013 03:20 AM, poma wrote:
>  On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote:
>
> > >I argue that we should get rid of the DVD it's an era of the past and
> > >just provide net-install iso and lives.
>  Probably there are good reasons why the DVD is still here. 
Indeed!  There are
environments/situations where there is no network 
connectivity (at least to the Internet) and never will be.  It is this 
type of situations that will require a DVD.

Another situation is where I am installing into a qemu-kvm virtual 
system.  Yes, there will be Internet connectivity.  Yes, it is nice to 
have everything updated on install.  But, running with just the DVD 
image is a lot faster (takes much less wall-clock time).

BTW, if a live image is suppose to represent "The" set for a desktop 
such as KDE, then that should be the same on the DVD.  But, if there 
really should be more than can fit on a live cdrom image, then why not 
change that to be a live DVD image.  After all, how many computers out 
only have a cdrom drive as oppose to a dvd drive capable of handling 
both cdroms and dvds?

Gene

[Adam Williamson]

On Fri, 2013-12-13 at 05:54 -0500, Gene Czarcinski wrote:
>  On 12/13/2013 03:20 AM, poma wrote:
>  > On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote:
>  >
>  >> >I argue that we should get rid of the DVD it's an era of the past and
>  >> >just provide net-install iso and lives.
>  > Probably there are good reasons why the DVD is still here.
>  Indeed!  There are environments/situations where there is no network 
>  connectivity (at least to the Internet) and never will be.  It is this 
>  type of situations that will require a DVD.
>  
>  Another situation is where I am installing into a qemu-kvm virtual 
>  system.  Yes, there will be Internet connectivity.  Yes, it is nice to 
>  have everything updated on install.  But, running with just the DVD 
>  image is a lot faster (takes much less wall-clock time). 
Not that I necessarily agree with johann on this one, but he did say to
keep the netinst *and the lives*. Live installs work without a network
and are even faster than DVD installs in VMs.

>  BTW, if a live image is suppose to represent "The" set for
> a desktop 
>  such as KDE, then that should be the same on the DVD.  But, if there 
>  really should be more than can fit on a live cdrom image, then why not 
>  change that to be a live DVD image.  After all, how many computers out 
>  only have a cdrom drive as oppose to a dvd drive capable of handling 
>  both cdroms and dvds? 
We already gave up on CDs a couple of releases back. GNOME and KDE are
currently targeting 1GB (power-of-ten), but still have to cut stuff out
to make size. They can choose to go up to 2GB or higher if they like;
it's up to the SIGs to decide (at the start of a release cycle, of
course).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Rejy M Cyriac]

On 12/13/2013 12:55 PM, "Jóhann B. Guðmundsson" wrote:
>  
>  On fös 13.des 2013 06:30, Adam Williamson wrote:
> > On Fri, 2013-12-13 at 05:31 +0000, "Jóhann B. Guðmundsson" wrote:
> >> On fös 13.des 2013 02:05, Adam Williamson wrote:
> >>> It was clear at the Go/No-Go meeting today that KDE SIG does not
> >>> consider this release criterion applicable/desired:
> >>>
> >>> "All applications that can be launched using the standard graphical
> >>> mechanism of a release-blocking desktop after a default installation of
> >>> that desktop must start successfully and withstand a basic
> >>> functionality
> >>> test."
> >>>
> >>>
> https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...
> >>>
> >>>
> >>> jreznik says they consider the live image their 'polished product'
> >>> where
> >>> everything must work, while the DVD install is more of a grab-bag -
> >>> they
> >>> install a whole bunch of stuff, and don't think it's the end of the
> >>> world if one or two bits are broken.
> >>>
> >>> Given that, I propose re-wording as follows:
> >> You are trying to fix the problem on the wrong end thus leave the
> >> criteria as is.
> >>
> >> The installing should not differ ( or in other word be consistent )
> >> regardless if you install from the live or from the dvd the end result
> >> should be the same.
> >>
> >> You should have the same service enablement, the same desktop instalment
> >> and experience etc.
> >>
> >> So get releng to get their act together and fix that for the dvd so
> >> matches with the live.
> > Per my long reply on the other sub-thread, I'm fine with that if it
> > actually _happens_. But it's not releng's responsibility; it's the KDE
> > and desktop SIGs. They own this stuff: it's their responsibility to
> > choose what packages go in the lives and what packages are deployed when
> > you do a DVD install of their desktops.
>  
>  The DVD is releng/fesco responsibility, they dictate and decide what's
>  on it and what not and how it's delivered not the sub-community's.
>  
>  There are other differences then just the package selection that get
>  installed for example which services are enabled etc. compared to the
>  lives.
>  
>  I argue that we should get rid of the DVD it's an era of the past and
>  just provide net-install iso and lives.
>   
I differ with you on this point. There are still so many places in the
world with limited/expensive/slow, or even no network connectivity at
all. In fact, it is only in the developed countries that broadband is
prevalent like water, and in the rest of the world, just like water, it
is a limited resource.

On a related note, folks in the developed world might be surprised to
know that 32-bit processors are still very much in use.

I work with the Free Media project of Fedora, and I know of so many
instances where providing the Fedora DVD (32 and 64 bit) has empowered
the lives of people and small organisations.

>  Those lives should be under full control of the sub-community both
> in
>  terms of size,partitioning, filesystem layout.filesystem type, package
>  selection as well as service enablement even to the use an alternative
>  installer but those sub-community should also be responsible for QA-ing
>  ( testing/triaging  ) as well as the necessary release engineering work
>  to release their own lives..
>  
>  JBG 

-- 
Regards,

Rejy M Cyriac (rmc)

[Rejy M Cyriac]

On 12/13/2013 04:24 PM, Gene Czarcinski wrote:
>  On 12/13/2013 03:20 AM, poma wrote:
> > On 13.12.2013 08:25, "Jóhann B. Guðmundsson" wrote:
> >
> >> >I argue that we should get rid of the DVD it's an era of the past and
> >> >just provide net-install iso and lives.
> > Probably there are good reasons why the DVD is still here.
>  Indeed!  There are environments/situations where there is no network
>  connectivity (at least to the Internet) and never will be.  It is this
>  type of situations that will require a DVD.
>  
>  Another situation is where I am installing into a qemu-kvm virtual
>  system.  Yes, there will be Internet connectivity.  Yes, it is nice to
>  have everything updated on install.  But, running with just the DVD
>  image is a lot faster (takes much less wall-clock time).
>  
>  BTW, if a live image is suppose to represent "The" set for a desktop
>  such as KDE, then that should be the same on the DVD.  But, if there
>  really should be more than can fit on a live cdrom image, then why not
>  change that to be a live DVD image.  After all, how many computers out
>  only have a cdrom drive as oppose to a dvd drive capable of handling
>  both cdroms and dvds?
>   
The Fedora Gnome and KDE images are currently too big for a CD, we
actually have transitioned to live DVD. Only the XFCE, LXDE, and
MATE-Compiz Live Spins can be accommodated on a CD.

>  Gene 

-- 
Regards,

Rejy M Cyriac (rmc)

[Bill Nottingham]

"Jóhann B. Guðmundsson" (johannbg(a)gmail.com) said: 
>  The DVD is releng/fesco responsibility, they dictate and decide
>  what's on it and what not and how it's delivered not the
>  sub-community's. 
Really? 

The KDE SIG has full access to change what gets installed when you 
install from the DVD. If you're saying it's releng and FESCo's
responsibility to fix that, then as a releng and FESCo member, I'll fix it...

commit f349ff05510a1f60cb43470cb544d55136c837c3 (HEAD, f20)
Author: Bill Nottingham <notting(a)redhat.com&gt;
Date:   Fri Dec 13 12:22:39 2013 -0500

    Drop KDE from the DVD, to avoid blocker bugs due to installed package set.

diff --git a/fedora-install-fedora.ks b/fedora-install-fedora.ks
index f1a767f..fd9f4e9 100644
--- a/fedora-install-fedora.ks
+++ b/fedora-install-fedora.ks
@@ -73,13 +73,6 @@ dracut-*
 @libreoffice
 @gnome-games
 
-## KDE
-@kde-desktop
-@kde-apps
-@kde-education
-@kde-media
-@kde-office
-
 ## XFCE
 @xfce-desktop
 @xfce-apps
@@ -111,7 +104,6 @@ dracut-*
 @rpm-development-tools
 @fedora-packager
 @gnome-software-development
-@kde-software-development
 @x-software-development
 @virtualization
 @web-server
@@ -139,8 +131,6 @@ autocorr-*
 eclipse-nls-*
 hunspell-*
 hyphen-*
-calligra-l10n-*
-kde-l10n-*
 libreoffice-langpack-*
 man-pages-*
 mythes-*

commit 833fdfaf7ec6a9588b1d51a11b9a2a9d956ab873 (HEAD, master)
Author: Bill Nottingham <notting(a)redhat.com&gt;
Date:   Fri Dec 13 12:25:13 2013 -0500

    Drop KDE environment as an installation choice. Live media is the SIG-supported
install method.

diff --git a/comps-f21.xml.in b/comps-f21.xml.in
index 66ff5c5..f462e58 100644
--- a/comps-f21.xml.in
+++ b/comps-f21.xml.in
@@ -6200,34 +6200,6 @@
     </optionlist>
   </environment>
   <environment>
-    <id>kde-desktop-environment</id>
-    <_name>KDE Plasma Workspaces</_name>
-    <_description>The KDE Plasma Workspaces, a highly-configurable graphical user
interface which includes a panel, desktop, system icons and desktop widgets, and many
powerful KDE applications.</_description>
-    <display_order>10</display_order>
-    <grouplist>
-      <groupid>base-x</groupid>
-      <groupid>standard</groupid>
-      <groupid>core</groupid>
-      <groupid>admin-tools</groupid>
-      <groupid>dial-up</groupid>
-      <groupid>fonts</groupid>
-      <groupid>input-methods</groupid>
-      <groupid>multimedia</groupid>
-      <groupid>hardware-support</groupid>
-      <groupid>printing</groupid>
-      <groupid>guest-desktop-agents</groupid>
-      <groupid>kde-desktop</groupid>
-    </grouplist>
-    <optionlist>
-      <groupid>kde-apps</groupid>
-      <groupid>kde-education</groupid>
-      <groupid>kde-media</groupid>
-      <groupid>kde-office</groupid>
-      <groupid>kde-telepathy</groupid>
-      <groupid>3d-printing</groupid>
-    </optionlist>
-  </environment>
-  <environment>
     <id>xfce-desktop-environment</id>
     <_name>Xfce Desktop</_name>
     <_description>A lightweight desktop environment that works well on low end
machines.</_description>

Ready to push whenever.

Now, I'm ASSuming they don't actually want that. But, to be clear: the
installation choices of the assorted desktops on the DVD/netinstall are the
provence of those SIGs. If they don't want to maintain them, we can absolutely
remove them, just as we'd do for any Spin that was not maintained or tested.

Bill

[drago01]

On Fri, Dec 13, 2013 at 3:05 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  It was clear at the Go/No-Go meeting today that KDE SIG does not
>  consider this release criterion applicable/desired:
>
>  "All applications that can be launched using the standard graphical
>  mechanism of a release-blocking desktop after a default installation of
>  that desktop must start successfully and withstand a basic functionality
>  test."
>
>
> https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...
>
>  jreznik says they consider the live image their 'polished product' where
>  everything must work, while the DVD install is more of a grab-bag - they
>  install a whole bunch of stuff, and don't think it's the end of the
>  world if one or two bits are broken.
>
>  Given that, I propose re-wording as follows:
>
>  "All applications that can be launched using the standard graphical
>  mechanism of a release-blocking live image after an installation of that
>  image must start successfully and withstand a basic functionality test."
>
>  So, that doesn't just apply to KDE. True, but I actually think it's a
>  reasonable revision for GNOME as well. It makes sense to see the live
>  images as defining what our 'polished core desktops' consist of, and the
>  DVD as more of a grab-bag of packages. 
No that makes zero sense. You solution is not a solution at all "we
found out that we ship random crap on the DVD that does not even start
up ... so lets pretend we don't know about it" ... the proper solution
(as others said) is to simply to *NOT* install random stuff by default
just because there is space on the media.

We should improve the software installation experience so that people
can easily find and install software they need (that's what we have
started to do in F20 which is a way better approach then "just install
tons of stuff by default").

[Adam Williamson]

On Fri, 2013-12-13 at 21:36 +0100, drago01 wrote:
>  On Fri, Dec 13, 2013 at 3:05 AM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > It was clear at the Go/No-Go meeting today that KDE SIG does not
>  > consider this release criterion applicable/desired:
>  >
>  > "All applications that can be launched using the standard graphical
>  > mechanism of a release-blocking desktop after a default installation of
>  > that desktop must start successfully and withstand a basic functionality
>  > test."
>  >
>  >
> https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_a...
>  >
>  > jreznik says they consider the live image their 'polished product' where
>  > everything must work, while the DVD install is more of a grab-bag - they
>  > install a whole bunch of stuff, and don't think it's the end of the
>  > world if one or two bits are broken.
>  >
>  > Given that, I propose re-wording as follows:
>  >
>  > "All applications that can be launched using the standard graphical
>  > mechanism of a release-blocking live image after an installation of that
>  > image must start successfully and withstand a basic functionality test."
>  >
>  > So, that doesn't just apply to KDE. True, but I actually think it's a
>  > reasonable revision for GNOME as well. It makes sense to see the live
>  > images as defining what our 'polished core desktops' consist of, and the
>  > DVD as more of a grab-bag of packages.
>  
>  No that makes zero sense. You solution is not a solution at all "we
>  found out that we ship random crap on the DVD that does not even start
>  up ... so lets pretend we don't know about it" ... the proper solution
>  (as others said) is to simply to *NOT* install random stuff by default
>  just because there is space on the media. 
As I've said, if people are willing to actually go out and do that, then
fine. Does desktop team actively curate the DVD-installed package set?
And to play the counter-factual game: imagine there had been a bug
analogous to https://bugzilla.redhat.com/show_bug.cgi?id=1040922 in
GNOME on the day of Go/No-Go meeting. Is the desktop SIG willing to take
a stand and say 'yes, we should delay the release multiple weeks over
Christmas if such a bug is discovered'?

If so, then we can continue with the current criteria, though it would
be ideal if desktop and KDE sigs could commit to helping with the
testing.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Matthias Clasen]

On Fri, 2013-12-13 at 12:44 -0800, Adam Williamson wrote:

>  As I've said, if people are willing to actually go out and do
> that, then
>  fine. Does desktop team actively curate the DVD-installed package set?
>  And to play the counter-factual game: imagine there had been a bug
>  analogous to https://bugzilla.redhat.com/show_bug.cgi?id=1040922 in
>  GNOME on the day of Go/No-Go meeting. Is the desktop SIG willing to take
>  a stand and say 'yes, we should delay the release multiple weeks over
>  Christmas if such a bug is discovered'?
>  
>  If so, then we can continue with the current criteria, though it would
>  be ideal if desktop and KDE sigs could commit to helping with the
>  testing. 
No, I take pretty much the same stance wrt. to the DVD: I pay attention
to the live image, and make sure it works. I don't think I've ever
downloaded or tried the DVD. I always found it very odd and awkward that
we hand out something at conferences and shows that nobody really pays
attention to.

[Adam Williamson]

On Fri, 2013-12-13 at 16:42 -0500, Matthias Clasen wrote:
>  On Fri, 2013-12-13 at 12:44 -0800, Adam Williamson wrote:
>  
>  > As I've said, if people are willing to actually go out and do that, then
>  > fine. Does desktop team actively curate the DVD-installed package set?
>  > And to play the counter-factual game: imagine there had been a bug
>  > analogous to https://bugzilla.redhat.com/show_bug.cgi?id=1040922 in
>  > GNOME on the day of Go/No-Go meeting. Is the desktop SIG willing to take
>  > a stand and say 'yes, we should delay the release multiple weeks over
>  > Christmas if such a bug is discovered'?
>  > 
>  > If so, then we can continue with the current criteria, though it would
>  > be ideal if desktop and KDE sigs could commit to helping with the
>  > testing.
>  
>  No, I take pretty much the same stance wrt. to the DVD: I pay attention
>  to the live image, and make sure it works. I don't think I've ever
>  downloaded or tried the DVD. I always found it very odd and awkward that
>  we hand out something at conferences and shows that nobody really pays
>  attention to. 
Well, then there's the problem. We can't have release criteria that say
"we really stand behind the package sets installed from the DVD" if we
don't.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Rahul Sundaram]

Hi


On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson  wrote:

>  Well, then there's the problem. We can't have release criteria that say
>  "we really stand behind the package sets installed from the DVD" if we
>  don't.
>  
That is true however the solution is not to weaken the release criteria but
decide  a) do we need the DVD anymore  b) if we need it, whether there is
anything against trimming down the default package sets to be consistent
with what is included in the live images.  With the new model, I think the
right answer is to drop the DVD image entirely but b) is the minimum we
should do.

Rahul

[Adam Williamson]

On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote:
>  Hi
>  
>  
>  On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson  wrote:
>          
>          
>          
>          Well, then there's the problem. We can't have release criteria
>          that say
>          "we really stand behind the package sets installed from the
>          DVD" if we
>          don't.
>  
>  
>  That is true however the solution is not to weaken the release
>  criteria but decide  a) do we need the DVD anymore  b) if we need it,
>  whether there is anything against trimming down the default package
>  sets to be consistent with what is included in the live images.  With
>  the new model, I think the right answer is to drop the DVD image
>  entirely but b) is the minimum we should do.  
That requires will on the part of the desktop SIGs, though. QA is not
going to be responsible for this. My position is either the desktop SIGs
fix their stuff, or we will have to change the criteria as I proposed,
because what other choice do we have?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Gavin Flower]

On 14/12/13 12:49, Rahul Sundaram wrote:
>  Hi
>
>
>  On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson wrote:
>
>
>
>      Well, then there's the problem. We can't have release criteria
>      that say
>      "we really stand behind the package sets installed from the DVD" if we
>      don't.
>
>
>  That is true however the solution is not to weaken the release 
>  criteria but decide  a) do we need the DVD anymore  b) if we need it, 
>  whether there is anything against trimming down the default package 
>  sets to be consistent with what is included in the live images. With 
>  the new model, I think the right answer is to drop the DVD image 
>  entirely but b) is the minimum we should do.
>
>  Rahul
>
>  
I use use DVD's to initially load the system, sometimes I've given 
copies to others.

Possibly I should again try a net install?


Cheers,
Gavin

[drago01]

On Sat, Dec 14, 2013 at 1:54 AM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote:
> > Hi
> >
> >
> > On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson  wrote:
> >
> >
> >
> >         Well, then there's the problem. We can't have release criteria
> >         that say
> >         "we really stand behind the package sets installed from the
> >         DVD" if we
> >         don't.
> >
> >
> > That is true however the solution is not to weaken the release
> > criteria but decide  a) do we need the DVD anymore  b) if we need it,
> > whether there is anything against trimming down the default package
> > sets to be consistent with what is included in the live images.  With
> > the new model, I think the right answer is to drop the DVD image
> > entirely but b) is the minimum we should do.
>
>  That requires will on the part of the desktop SIGs, though. QA is not
>  going to be responsible for this. My position is either the desktop SIGs
>  fix their stuff, or we will have to change the criteria as I proposed,
>  because what other choice do we have? 
Talk to FESCo ? Ask for them to remove the offending crap once we hit it?
Or "if the app does not start and is not part of live kick it out".
Its a one line change.

[Adam Williamson]

On Sat, 2013-12-14 at 07:31 +0100, drago01 wrote:
>  On Sat, Dec 14, 2013 at 1:54 AM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > On Fri, 2013-12-13 at 18:49 -0500, Rahul Sundaram wrote:
>  >> Hi
>  >>
>  >>
>  >> On Fri, Dec 13, 2013 at 4:58 PM, Adam Williamson  wrote:
>  >>
>  >>
>  >>
>  >>         Well, then there's the problem. We can't have release criteria
>  >>         that say
>  >>         "we really stand behind the package sets installed from the
>  >>         DVD" if we
>  >>         don't.
>  >>
>  >>
>  >> That is true however the solution is not to weaken the release
>  >> criteria but decide  a) do we need the DVD anymore  b) if we need it,
>  >> whether there is anything against trimming down the default package
>  >> sets to be consistent with what is included in the live images.  With
>  >> the new model, I think the right answer is to drop the DVD image
>  >> entirely but b) is the minimum we should do.
>  >
>  > That requires will on the part of the desktop SIGs, though. QA is not
>  > going to be responsible for this. My position is either the desktop SIGs
>  > fix their stuff, or we will have to change the criteria as I proposed,
>  > because what other choice do we have?
>  
>  Talk to FESCo ? Ask for them to remove the offending crap once we hit it?
>  Or "if the app does not start and is not part of live kick it out".
>  Its a one line change. 
It still means we have to find time to actually test them all at some
point, which we don't have a great record of doing lately. See my notes
on the status of the KDE desktop_menus test case in F20.

It seems a bit bizarre to me that we'd wind up in a state which could be
described as "we'll install stuff from the DVD that we don't really care
about and have no idea if it works properly, until QA runs it and clicks
a button and it crashes. At that point we'll take it out." What?

Can we go back to my suggestion of increasing the size target for the
desktop lives, deciding what packages you actually _do_ want to have in
a default install of your desktops, and making the lives and DVDs both
install precisely that package set? It'd be good to know the desktop
team's take on that.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Jóhann B. Guðmundsson]

On lau 14.des 2013 00:54, Adam Williamson wrote:
>  That requires will on the part of the desktop SIGs, though. QA is
> not
>  going to be responsible for this. My position is either the desktop SIGs
>  fix their stuff, or we will have to change the criteria as I proposed,
>  because what other choice do we have? 
We will remove everything non core/base related out of our criteria and 
assist the communities surrounding those products to come up with 
criteria ( as well as test cases maybe ) specifically tailored for those 
products but that's where our ( QA communities ) involvement with the 
output from WG's ends period.

JBG

[Richard Ryniker]

The defining characteristic of the Live images is that they run
without installation on a user's disks.  Beyond that, they have the
capability to install a minimal Fedora system to a local disk.  Once
the size limit for a live image is increased beyond the capacity of a
CD (or other common media), there seems no reason to limit the live
image size to 1 GB, or any arbitrary value.

Rather than struggle to find what can be be discarded from a live
image in order to achieve a particular size, why not build the DVD
product as a live system, or expand the existing live recipe to
include more of the frequently used packages and not build the DVD?
The DVD installer program has much more flexibility, but this is due
to that arbitrary size limit, I expect: there just is not space for
the full Fedora installation program (plus local repository) in
today's live images.

Others have stated the need for something like the DVD collection of
packages.  Without this, those who need something like it will have to
build their own, obtain it from a third party, or look at another
distribution.  For this reason, to simplify the Fedora products to (1)
network installation and (2) stand-alone installation, I submit the
installation DVD could be built as a live image.

I do not like the thought that many users might decide they have to
copy an entire Fedora repository to a portable hard drive in order to
install the Fedora system they want on a machine without a good
Internet connection.

A sizable group of users may have very limited hardware resources -
no network, only a CD drive.  This group would be a reasonable target
for a "Limited Resources" spin that seeks to tailor Fedora to such an
environment.  For example, these systems may have too little memory to
support anaconda (and many of the applications in Fedora's default
configuration).  Maybe a new SIG for this target.  (Perhaps it already
exists and I, with richer hardware resources, never looked for it.)

In any case, Adam Williamson's articulate comment about the practical
limits to what Quality Assurance can achieve with a six month release
cycle and the available resources is very relevant.  The release criteria,
in part, seek to define what will be tested, but they read more like a
prescription for what "should" be tested.  Modifications to limit and
make more specific the actual test coverage can help Fedora users
better understand what they have, and reflect the reality of QA
resource limits.

To this end, it would be good to have better distinction between what
QA tests and what other groups - SIG, upstream, packager, spin
creator, architecture group, etc. - are responsible to test.  QA test
criteria is one place to document this, at least the QA view of it.

Adam, your recent work on storage tests reads like a Unit Test Plan
for anaconda: something that tries to exercise all the code paths of
the program.  Is this the proper function of Fedora QA?  If it is,
what is the proper fraction of the anaconda development budget
to be allocated to Fedora QA for this purpose?

I use this as an example to support your observation that QA clearly
does not have resources to test all it might want to test, and clearer
definition is required for what QA will test and what others have to
test.  Your storage test cases look like something anaconda developers
should run before they let a new version loose.

Throw away a package because it was not tested, failed a test, or
missed a deadline is not a solution, however vexed one might be about
what has not been done.  It is natural that many changes will occur in
Fedora's package roster.  I counted 39,500 rpm files in the F20
repository.  Lots of changes, for many reasons, are normal, but it
is not sensible to expect all these parts to work properly.  It is
not even reasonable to expect the ten percent of these files on the
DVD to all work properly.

Fedora QA, as a group, should probably take a pragmatic approach and
focus on "critical path" and installation issues that affect large
groups of users, and refer more detailed tests to others.  Do more,
certainly, if resources permit.  And try to influence others to be
more aware and effective in their test activities.

[Adam Williamson]

On Sat, 2013-12-14 at 13:47 -0500, Richard Ryniker wrote:
>  The defining characteristic of the Live images is that they run
>  without installation on a user's disks.  Beyond that, they have the
>  capability to install a minimal Fedora system to a local disk.  Once
>  the size limit for a live image is increased beyond the capacity of a
>  CD (or other common media), there seems no reason to limit the live
>  image size to 1 GB, or any arbitrary value. 
There's no reason to limit it to any arbitrary value, but none of the
values we've used or discussed is arbitrary. 1GB is the size of a 1GB
USB stick, 2GB is the size of a 2GB USB stick. 3GB for example would
make no sense as no-one makes media in that size. Obvious 'sensible'
target sizes are 650MB CD, 700MB CD, 1GB USB, 2GB USB, 4GB USB, 4GiB
(because of FAT32 filesystem issues...), single-layer DVD, 8GB USB,
dual-layer DVD, 16GB USB.

>  Rather than struggle to find what can be be discarded from a live
>  image in order to achieve a particular size, why not build the DVD
>  product as a live system, or expand the existing live recipe to
>  include more of the frequently used packages and not build the DVD?
>  The DVD installer program has much more flexibility, but this is due
>  to that arbitrary size limit, I expect: there just is not space for
>  the full Fedora installation program (plus local repository) in
>  today's live images. 
No, it isn't, really. The live installer can only install the package
set you actually get when booting live, because all it does is dump
itself to the hard disk; it doesn't actually contain or install any
packages per se. So I don't see how we can do the DVD-as-live-image
thing in any practical way; the point of the DVD is that you can install
_different_ environments from it, but there's no way you can do that
from a live image.

It's also worth noting that the installer team doesn't like installing
from a live environment. It involves rather a lot of messy hacks and can
cause breakage; the major problem they have is they cannot possibly
trust that the system is in a 'clean' state when the installer
initializes, which they can control from the 'traditional' installer
mode.

One thing they've floated as an idea is to have a separate 'installation
environment' you could boot into from the live images - so you could
either boot into 'try it out' live mode, or 'install it' installer mode,
but not run the installer from within the live mode.

>  A sizable group of users may have very limited hardware resources -
>  no network, only a CD drive.  This group would be a reasonable target
>  for a "Limited Resources" spin that seeks to tailor Fedora to such an
>  environment.  For example, these systems may have too little memory to
>  support anaconda (and many of the applications in Fedora's default
>  configuration).  Maybe a new SIG for this target.  (Perhaps it already
>  exists and I, with richer hardware resources, never looked for it.) 
I don't believe it does, no. It seems like an interesting idea, so if
you're interested in making it happen, you could certainly go ahead and
make a proposal to the relevant authorities...

>    Modifications to limit and
>  make more specific the actual test coverage can help Fedora users
>  better understand what they have, and reflect the reality of QA
>  resource limits. 
I think we've always had this as a goal, but we've just winded up
drifting slightly over the last few releases to the point where we're
really struggling to keep up with the workload.

>  To this end, it would be good to have better distinction between
> what
>  QA tests and what other groups - SIG, upstream, packager, spin
>  creator, architecture group, etc. - are responsible to test.  QA test
>  criteria is one place to document this, at least the QA view of it. 
This is something viking-ice is talking about as well, and I certainly
agree with you guys that there's some value to it. The only problem I
have is that I don't really see a lot of evidence that many other groups
test their stuff at all in any particularly organized way, though I may
well be missing something. I'd have a lot of time for a vision where we
place some responsibility on the desktop SIG for desktop testing, on the
KDE SIG for KDE testing and so on, but like I keep saying for the
specific proposal here, we have to make sure it actually *happens*. I'm
not a fan of QA just throwing our hands up and unilaterally saying
"okay, we're just going to test X and trust that someone else cares
about making sure Y and Z work", at least not until we've made some
good-faith effort to make things better in a collaborative way.

At present it feels a lot like people only test things when we (QA) draw
up the test plans and then go out and make a fairly strenuous effort to
plead with others to test them. I mean, if we just fire a TC/RC and
stick the desktop matrices up, it's only intermittently that I've seen
desktop SIG folks show up and run through the validation testing. If I
or someone else posts to their mailing list with a specific plea for
testing or goes into IRC and bugs them about it, then we get a higher
success rate, but then again QA is taking on the responsibility for the
testing, essentially...

>  Adam, your recent work on storage tests reads like a Unit Test Plan
>  for anaconda: something that tries to exercise all the code paths of
>  the program.  
Ha, oh god, not even close. That matrix would probably cause mediawiki
to explode, and would also I think have to exist in at least four and
possibly five dimensions. I mean, for a trivial example you can take the
matrix I posted and just double the entire thing, because we should run
every single test combination for both msdos and GPT disk labels...that
kind of thing. There are whole 'variables' like that which I just punted
on because they made things too impractical.

The matrix I posted - aside from the 'sanity check' tests, which are a
kind of arbitrary grab bag - is actually one of the *smaller* versions
of the several I thought about and roughly drafted. If you want me to
pull out a Wild-Ass Guess I expect those tests would only cover maybe
5%, 10% of all the possible paths through storage. I was very much
thinking 'smallest practical set of tests to cover the things we
currently claim to be blocking on', not 'test everything'. 'Test
everything', when it comes to storage, is entirely impossible.

For the theoretically-minded, I'll note two design choices in storage
which make this problem exponentially harder: the 'refresh' button,
which re-runs the disk scan from inside the custom partitioning screen,
and the fact that you can run the Installation Destination spoke
multiple times and when you do so it does not start over from scratch,
but tries to take the choices you made the previous time through into
account. Each of these things on its own effectively makes the 'problem
space' for storage testing infinite, both together mean I just pretty
much gave up on even the possibility of testing those things and just
threw in two token tests - it's kind of like, for upgrading, we only
test upgrading a very clean installation of the previous release,
because it's just utterly impractical to try and cover anything more.

I should also make explicit that along with thinking about revising the
storage test case set, I'm thinking about the storage release criteria,
because obviously those things go hand in hand. I think it's very clear
at this point that we need to tighten down the Beta criteria in a few
places, and completely toss out the utterly unworkable Final criterion
we have - "The installer must be able to create and install to any
workable partition layout using any file system and/or container format
combination offered in a default installer configuration." - and replace
it with a specific and limited list of things we decide we actually care
about and can plausibly manage to test within the 'time and resources'
calculation I posted about before, in the same style as we have put in
place for Alpha and Beta. If 18, 19 and 20 have taught us anything it's
that we cannot possibly stand behind any interpretation of that Final
criterion, from a QA or development standpoint.

So, perhaps if my proposal is just too big for us to sensibly digest, an
alternative approach would be to look at the criteria revision first -
trying to keep in mind, while we're drafting the criteria, what the
validation matrix for that criteria set would look like, and what kind
of issues we'd be 'leaving out' as non-blockers - and try to nail down
some new criteria that allow us to draw up a new test plan that is
practical for us in resource terms.

I'll throw an item for this on the agenda for Monday's meeting - it'd be
great if folks who are interested can come along to discuss it.

>   Is this the proper function of Fedora QA?  If it is,
>  what is the proper fraction of the anaconda development budget
>  to be allocated to Fedora QA for this purpose? 
Practically speaking, 0%. One of the other major problems we have in
this area is that anaconda is, I think, unarguably under-resourced. All
my observations about the sheer hugeness of the storage 'problem space'
obviously apply to developing it as well as testing it, yet for the last
year or two we have had precisely one developer working on it, dlehman.
This is utterly unsupportable. anaconda team now has a second full-time
storage developer, Anne Mulhern, but even that's not exactly an
abundance of riches.

As I mentioned in another mail, anaconda is actually working on
implementing CI and a unit test suite at present, which will be a great
thing when it's done.

>  I use this as an example to support your observation that QA clearly
>  does not have resources to test all it might want to test, and clearer
>  definition is required for what QA will test and what others have to
>  test.  Your storage test cases look like something anaconda developers
>  should run before they let a new version loose. 
Again I'd say in theory no, in practice the sets are probably quite
similar: I think the anaconda CI stuff, once it's actually done, will
wind up exercising much the same set of things I drew up, but the
starting point was quite different. I really did start out by trying to
think about what's the smallest set of things we really ought to try and
test per release. The problem is that every time I sit down and try and
think about that, even the _smallest_ set I can come up with is huge.

I really would like to see other people's proposals in this area. I'm
not at all convinced I'm going to be the person who comes up with the
best idea. I'd love to know what cmurf would suggest as an overall
approach to designing a set of Final release criteria or a storage
validation test plan, for instance.

>  Throw away a package because it was not tested, failed a test, or
>  missed a deadline is not a solution, however vexed one might be about
>  what has not been done. 
I don't think anyone's proposed 'throwing away' any packages - all of
the various proposals have instead been about the question of what
packages are installed *by default*, which is a very different thing.

>    It is natural that many changes will occur in
>  Fedora's package roster.  I counted 39,500 rpm files in the F20
>  repository.  Lots of changes, for many reasons, are normal, but it
>  is not sensible to expect all these parts to work properly.  It is
>  not even reasonable to expect the ten percent of these files on the
>  DVD to all work properly. 
We certainly don't. Our current expectation is much lower: we expect
that every package installed by default when you install KDE or GNOME
from the DVD or live, without changing the 'default' package set, should
run and pass a 'basic functionality test' (which is rather different
from 'working properly'). I'm suggesting that even that expectation is
unrealistic.

>  Fedora QA, as a group, should probably take a pragmatic approach and
>  focus on "critical path" and installation issues that affect large
>  groups of users, and refer more detailed tests to others.  Do more,
>  certainly, if resources permit.  And try to influence others to be
>  more aware and effective in their test activities. 
That already is our approach, honestly. We are nowhere even remotely
close to covering or attempting to cover 'everything'. I actually don't
think anyone would disagree with your suggestion above, but the problem
is that it's already what we're trying to do, and the problems we're
having are with defining and interpreting what is the minimal core of
'really essential' stuff that we should test...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[T.C. Hollingsworth]

On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski <gczarcinski(a)gmail.com&gt; wrote:
>  Indeed!  There are environments/situations where there is no network
>  connectivity (at least to the Internet) and never will be.  It is this type
>  of situations that will require a DVD. 
I run Fedora on a system that exists in on the side of a mountain in
the remote part of the Arizona desert that is lucky to even have
electricity and running water.  No Internet, except tethering on my
smartphone in an area that doesn't even have 3G coverage.  (Internet
access would sort of defeat the usual purpose of me venturing out
there, anyway.  That machine wouldn't even exist period if it were not
used by others; I'd just take my laptop out there or maybe not even
that. ;-)  Trying to run a `yum update` out there would probably take
longer than I usually spend there, and I'm not particularly worried
about security updates, since the only way that system could possibly
be more airgapped would be for it to exist on Mars.  :-p

Anyway, the DVD is _completely_ useless for this system.  Pretty much
every use case I have for this system requires packages from a certain
third-party repository we all know and love, and even if Fedora
contained all the packages I needed for it, they all certainly
wouldn't on the DVD.  Also, I really don't care about 95% of the
packages on the DVD; I certainly don't need six different desktops.
;-)

So instead when I refresh it from time to time, I just anaconda
install onto a USB stick, yum install everything I want to it, then
take it out there and dd it to the hard disk, manually making grub
happy if necessary.  This also allows me to configure it the way I
want before I leave, so when I get out there it only takes me a few
minutes to get it completely updated.

I guess I could craft a kickstart and use livecd-creator instead, but
that seems like more hassle than it's worth.  Plus I keep that USB
stick around so I have something that matches that system exactly at
home, so if I ever decide I want to install some more stuff on it I
can be sure I download all the RPMs necessary for a complete
transaction.  (Supposedly there's some offline download/install
support in PackageKit for that usecase too, but it doesn't seem to be
documented very well.  The only reason I even know it exists is
because hughsie asked on his blog if he could kill it.  ;-)

So if we really care about this usecase, we need to rebirth revisor or
something similar so people can actually make images for their
disconnected systems that have the stuff they want on them easily,
instead of a grab bag of packages most of which they have no use for.
For bonus points, maybe flesh out the offline update support so
there's a sane way to update/install stuff on them afterward.

Keeping the DVD around "because offline systems" is really just
ignoring these users' actual needs.  It would be nice if some
development effort were put to making this actually better, but it's
really an edge case that can already be handled by other, less elegant
solutions like mine, so I really don't blame developers for not
bothering with it.

The only other use case we really have for the install DVD is for
handing out at conferences, etc., and I think the multi-live DVD is a
much better fit for that personally.

>  Another situation is where I am installing into a qemu-kvm virtual
> system.
>  Yes, there will be Internet connectivity.  Yes, it is nice to have
>  everything updated on install.  But, running with just the DVD image is a
>  lot faster (takes much less wall-clock time). 
Nowadays we have nice qcow2 images for that use case.  Much better
than the DVD IMHO, especially since a `yum update` is the first thing
I'd do regardless...

-T.C.

[Thomas Gilliard]

On 12/14/2013 12:38 PM, T.C. Hollingsworth wrote:
>  On Fri, Dec 13, 2013 at 3:54 AM, Gene Czarcinski
> <gczarcinski(a)gmail.com&gt; wrote:
> > Indeed!  There are environments/situations where there is no network
> > connectivity (at least to the Internet) and never will be.  It is this type
> > of situations that will require a DVD.
>  I run Fedora on a system that exists in on the side of a mountain in
>  the remote part of the Arizona desert that is lucky to even have
>  electricity and running water.  No Internet, except tethering on my
>  smartphone in an area that doesn't even have 3G coverage.  (Internet
>  access would sort of defeat the usual purpose of me venturing out
>  there, anyway.  That machine wouldn't even exist period if it were not
>  used by others; I'd just take my laptop out there or maybe not even
>  that. ;-)  Trying to run a `yum update` out there would probably take
>  longer than I usually spend there, and I'm not particularly worried
>  about security updates, since the only way that system could possibly
>  be more airgapped would be for it to exist on Mars.  :-p
>
>  Anyway, the DVD is _completely_ useless for this system.  Pretty much
>  every use case I have for this system requires packages from a certain
>  third-party repository we all know and love, and even if Fedora
>  contained all the packages I needed for it, they all certainly
>  wouldn't on the DVD.  Also, I really don't care about 95% of the
>  packages on the DVD; I certainly don't need six different desktops.
>  ;-)
>
>  So instead when I refresh it from time to time, I just anaconda
>  install onto a USB stick, yum install everything I want to it, then
>  take it out there and dd it to the hard disk, manually making grub
>  happy if necessary.  This also allows me to configure it the way I
>  want before I leave, so when I get out there it only takes me a few
>  minutes to get it completely updated.
>
>  I guess I could craft a kickstart and use livecd-creator instead, but
>  that seems like more hassle than it's worth.  Plus I keep that USB
>  stick around so I have something that matches that system exactly at
>  home, so if I ever decide I want to install some more stuff on it I
>  can be sure I download all the RPMs necessary for a complete
>  transaction.  (Supposedly there's some offline download/install
>  support in PackageKit for that usecase too, but it doesn't seem to be
>  documented very well.  The only reason I even know it exists is
>  because hughsie asked on his blog if he could kill it.  ;-)
>
>  So if we really care about this usecase, we need to rebirth revisor or
>  something similar so people can actually make images for their
>  disconnected systems that have the stuff they want on them easily,
>  instead of a grab bag of packages most of which they have no use for.
>  For bonus points, maybe flesh out the offline update support so
>  there's a sane way to update/install stuff on them afterward.
>
>  Keeping the DVD around "because offline systems" is really just
>  ignoring these users' actual needs.  It would be nice if some
>  development effort were put to making this actually better, but it's
>  really an edge case that can already be handled by other, less elegant
>  solutions like mine, so I really don't blame developers for not
>  bothering with it.
>
>  The only other use case we really have for the install DVD is for
>  handing out at conferences, etc., and I think the multi-live DVD is a
>  much better fit for that personally. 
Look at
http://wiki.sugarlabs.org/go/Build_Your_Own_Remix_with_Fedora

Make an installable live CD/DVD .iso  with cutomizations
> > Another situation is where I am installing into a qemu-kvm
> virtual system.
> > Yes, there will be Internet connectivity.  Yes, it is nice to have
> > everything updated on install.  But, running with just the DVD image is a
> > lot faster (takes much less wall-clock time).
>  Nowadays we have nice qcow2 images for that use case.  Much better
>  than the DVD IMHO, especially since a `yum update` is the first thing
>  I'd do regardless...
>
>  -T.C.

[Richard Ryniker]

On Sat, 14 Dec 2013, at 11:25:40 -0800 Adam Williamson <awilliam(a)redhat.com&gt; wrote:

   One thing they've floated as an idea is to have a separate 'installation
   environment' you could boot into from the live images - so you could
   either boot into 'try it out' live mode, or 'install it' installer
mode,
   but not run the installer from within the live mode.

That is pretty much what I had in mind.  There would be no "live
installer".  The Fedora stand-alone installation medium would be large
enough to have a live system that offered "try" mode, "install" mode
(full anaconda, with local repository), and maybe "rescue" mode.  The
same system image would be used: options built into each choice would
direct which mode to execute.

I think Ubuntu (or one of its variants) uses a scheme like this, but I
do not know if it copies the live image or offers multiple
installation variations.

It is very crude, but I looked at how many models of USB flash drive
Amazon sells directly and see:

    512MB & Under   4 
    1GB            39 
    2GB           176 
    4GB           378 
    8GB           518 
    16GB    B     407 
    32GB & Up     465 

Two thirds are models with 8GB or larger capacity.  That does not mean
this many flash drives sold have that capacity, but such capacity is
readily available.  There still are many machines that do not boot
directly from USB, but that is a condition for which GRUB and friends
are made.

I cannot quantify how much a single installer for Fedora saves over
two (live and multiple-environment).  If one installer is adequate, it
still may not be worth the disruption caused when the other is
dropped.

The single installer choice could be made either way.  The alternative
is only a live installer, which becomes the starting point for
subsequent installation by yum of the desired environment(s).

   if you're interested in making [a limited resource Fedora]
   happen...

I think one of my problems is too much hardware, not too little.
Somehow, I seem to have acquired the notion a new release of Fedora
justifies a new machine on which to run it.

   I don't really see a lot of evidence that many other groups test
   their stuff at all in any particularly organized way

There are many reasons this is so.  One may be a perception there is a
QA group that will do this, therefore little need exists to do first
what will be done again.  This is not the most important factor, I
believe, but a consequence is the more QA does, the more this attitude
grows.  You become a victim of your own success.  Greater clarity
about what QA will not test may help.

   I'll note two design choices in storage which make this problem
   exponentially harder...

Yes.  Test the untestable.  I do not think those choices are caprice;
they allow users, most of whom are no more than casually familiar with
Fedora installation, to find a more comfortable path through the
installation process, one that permits minimal rework (avoids the
"Something is wrong - start over" event) as understanding grows and
bad choices are improved.  Fedora testers, who usually have an
abundance of installation experience, likely do not appreciate the
value to less experienced users of this flexibility that makes tests
so difficult.

   for upgrading, we only test upgrading a very clean installation of
   the previous release

Upgrade is a can of worms.  Yes, I too am beguiled by how much easier
upgrade is than a new installation, and have often chosen upgrade, but
something (many somethings!) sooner or later bite.  There are just too
many initial conditions, and too many distinct ways appropriate for
different users to handle these conditions, to make possible an
accurate understanding of what results from an upgrade.  In lucid
moments, I know upgrade should be exorcised, but it just is *so*
convenient.

Has Fedora QA discussed how much effort they should or can invest in
organization and facilitation of others' test activities?  Direct
testing scales (approximately) linearly with number of people, but
education, organization, and leadership has the potential to scale at
greater multiples.

|-----------------------------------------------------------------------|
| Great opportunity!  Become a Fedora test franchisee.  We'll provide   |
| directions, training, and all the materials you need, so you too can  |
| participate in this fast-moving field.  Gain experience, recruit      |
| others, become a Test Manager and train new Testers.  With 10 or      |
| more Testers, select your own Test Managers (each of whom will direct |
| at least five Testers) and advance to the Test Director level.  With  |
| five Test Managers, become a Test Executive...                        |
|-----------------------------------------------------------------------|

[Adam Williamson]

On Sat, 2013-12-14 at 22:27 -0500, Richard Ryniker wrote:

>  Has Fedora QA discussed how much effort they should or can invest in
>  organization and facilitation of others' test activities?  Direct
>  testing scales (approximately) linearly with number of people, but
>  education, organization, and leadership has the potential to scale at
>  greater multiples.
>  
>  |-----------------------------------------------------------------------|
>  | Great opportunity!  Become a Fedora test franchisee.  We'll provide   |
>  | directions, training, and all the materials you need, so you too can  |
>  | participate in this fast-moving field.  Gain experience, recruit      |
>  | others, become a Test Manager and train new Testers.  With 10 or      |
>  | more Testers, select your own Test Managers (each of whom will direct |
>  | at least five Testers) and advance to the Test Director level.  With  |
>  | five Test Managers, become a Test Executive...                        |
>  |-----------------------------------------------------------------------| 
It's a cute idea, but I'm firmly of the opinion that stuff like this
just doesn't _work_ in a project like Fedora. It's a cliche that geeks
and engineers aren't huge fans of 'bureaucracy' and 'management', and
this is pure management - drawing up a nice little hierarchical org
chart and giving people job titles. Does the Test Executive get a corner
office and a nice chair? :) I kid, but you get the point. I don't know
of a F/OSS project which has a strict pyramid structure and cutesy job
titles like this, and that's for a reason: the whole "F/OSS is a
meritocracy / F/OSS is a do-ocracy" thing has its own problem of bias
and so on, but it is a _fairly_ accurate reflection of how F/OSS work
actually happens in one respect: it's mostly the case that the work is
done by the people who show up, and there usually isn't some kind of
obvious hierarchy like you describe. I mean, we don't have Test
Executives and Test Directors and Testers inside the QA group, so why
would we expect it to work for other groups to do it?

The general idea of trying to get other groups more involved in testing
their own stuff is obviously a good one, but I don't think that's the
right approach to achieve it :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Gavin Flower]

On 15/12/13 17:41, Adam Williamson wrote:
>  On Sat, 2013-12-14 at 22:27 -0500, Richard Ryniker wrote:
>
> > Has Fedora QA discussed how much effort they should or can invest in
> > organization and facilitation of others' test activities?  Direct
> > testing scales (approximately) linearly with number of people, but
> > education, organization, and leadership has the potential to scale at
> > greater multiples.
> >
> > |-----------------------------------------------------------------------|
> > | Great opportunity!  Become a Fedora test franchisee.  We'll provide   |
> > | directions, training, and all the materials you need, so you too can  |
> > | participate in this fast-moving field.  Gain experience, recruit      |
> > | others, become a Test Manager and train new Testers.  With 10 or      |
> > | more Testers, select your own Test Managers (each of whom will direct |
> > | at least five Testers) and advance to the Test Director level.  With  |
> > | five Test Managers, become a Test Executive...                        |
> > |-----------------------------------------------------------------------|
>  It's a cute idea, but I'm firmly of the opinion that stuff like this
>  just doesn't _work_ in a project like Fedora. It's a cliche that geeks
>  and engineers aren't huge fans of 'bureaucracy' and 'management',
> and
>  this is pure management - drawing up a nice little hierarchical org
>  chart and giving people job titles. Does the Test Executive get a corner
>  office and a nice chair? :) I kid, but you get the point. I don't know
>  of a F/OSS project which has a strict pyramid structure and cutesy job
>  titles like this, and that's for a reason: the whole "F/OSS is a
>  meritocracy / F/OSS is a do-ocracy" thing has its own problem of bias
>  and so on, but it is a _fairly_ accurate reflection of how F/OSS work
>  actually happens in one respect: it's mostly the case that the work is
>  done by the people who show up, and there usually isn't some kind of
>  obvious hierarchy like you describe. I mean, we don't have Test
>  Executives and Test Directors and Testers inside the QA group, so why
>  would we expect it to work for other groups to do it?
>
>  The general idea of trying to get other groups more involved in testing
>  their own stuff is obviously a good one, but I don't think that's the
>  right approach to achieve it :) 
I don't know...

Possibly charge a lot of money, give out fancy certificates, and ensure 
they have status and no real responsibilities!


Cheers,
Gavin

[Adam Williamson]

On Sun, 2013-12-15 at 17:47 +1300, Gavin Flower wrote:

>  I don't know...
>  
>  Possibly charge a lot of money, give out fancy certificates, and ensure 
>  they have status and no real responsibilities! 
oooooh, I like it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Ian Malone]

On 15 December 2013 03:27, Richard Ryniker <ryniker(a)alum.mit.edu&gt; wrote:

>  It is very crude, but I looked at how many models of USB flash drive
>  Amazon sells directly and see:
>
>      512MB & Under   4
>      1GB            39
>      2GB           176
>      4GB           378
>      8GB           518
>      16GB    B     407
>      32GB & Up     465
>
>  Two thirds are models with 8GB or larger capacity.  That does not mean
>  this many flash drives sold have that capacity, but such capacity is
>  readily available.  There still are many machines that do not boot
>  directly from USB, but that is a condition for which GRUB and friends
>  are made.
>  
Cautionary note (and sorry for muddying waters further, already a lot
said in this discussion so trying to keep out of it): not only does
this not (as you say) reflect the number of drives being sold, but it
also doesn't reflect the drives in existence. The larger drives
dominate that list because people aren't making the smaller ones
anymore, but I've got 2 and 4GB drives I still use. For burning DVDs
it doesn't matter so much, they're relatively cheap per unit, but for
a USB it's a bit of a stretch to expect people to buy new drives,
especially if you're worried about things like accessibility in
developing countries and environmental impact.

(On the plus side, just got a 8GB for £10 retail - probably cheaper
online, but needed it quickly - these are now getting so big that it's
practical to use them for backup and temporary storage during a
reinstall, rather than having to worry about upgrading or how you're
going to backup and restore. Long run this is probably better than
WORM.)


-- 
imalone
http://ibmalone.blogspot.co.uk

[Richard Ryniker]

> With five Test Managers, become a Test Executive... 
Sorry, Adam, just an attempt to give you opportunity to smile.

I am serious about the scalability issue, however.  As you indicated, the
typical FOSS activity does not map readily into a classic business
hierarchical organization chart.  I do not want that.  It would likely be
difficult, unproductive, and even incite antagonism.

This does not mean all strategies will fail.  I do not know any sure-fire
way to multiply the effectiveness of QA, but your efforts to document
what QA can do and what others might do seem headed in a useful
direction.

Test automation is useful, especially if developers can be engaged in its
creation.  Abrt and other infrastructure is productive, and can be
improved.  Documentation - how to test, how to collect and report
information about errors - is useful, especially when new testers are
sought.  Bugzilla is not all that easy or intuitive to use. Some sort of
coverage map might help: what pieces are people currently testing or
planning to test; what parts have no people active.  All depends on
cost/benefit estimation.  Direct implementation is costly; leverage from
work done by others may be key.

[Chris Murphy]

On Dec 14, 2013, at 12:25 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  
>  I really would like to see other people's proposals in this area. I'm
>  not at all convinced I'm going to be the person who comes up with the
>  best idea. I'd love to know what cmurf would suggest as an overall
>  approach to designing a set of Final release criteria or a storage
>  validation test plan, for instance. 
What do you think of moving any blocking storage related criteria and tests, from final to
beta or even alpha? Why not move as much potential for blockers to alpha and beta releases
as possible?

An example of this is moving resize test and criterion to beta (or split between alpha and
beta if that's sensible and helpful). If resize were busted, do we really only want to
find out and start dealing with it, and maybe slipping on it, during final? Seems risky,
especially if a fix depends on upstream developers. Or public beta eats OS X or Windows
for lunch.

Since alpha and beta blocking criteria are still in effect post-beta, there will still be
storage related blocking bugs after beta release. But there wouldn't be new blockers
based on additional criteria. Rather than increasing the quality of beta, the main idea is
to increase the predictability of final and reduce risk of regressions and final release
slip. 

I think guided partitioning should be fairly rock solid, and even though it's the
"simple" path, it's still a beast of a matrix. I mentioned this in a
different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We
don't need two LVM options in Guided. And if we can't get buy off on that, then
we'll have to just eat that extra testing, because I think Guided shouldn't get
people into trouble.

Custom partitioning needs to be triaged for certain use cases we really want to work, and
make those blocking if they fail. It may not be the same list for i386, x86_64/EFI, and
ARM. e.g. we supposedly block on raid5 for x86_64, but does that make sense for ARM? Other
combinations, even if there's a crash, would be non-blocking bugs, and only the
subjective FE determination applies.

Obviously the data corruption proscription is still in place, so crashes that lead to
mangled partition tables or previously working file systems, presumably would block.
However, I wonder if that criterion should be split in two: clearly not OK block worthy
cases probably ought to be an alpha or beta blocker at the latest; and those that are
suitable for FE or merely being documented could be permitted post-beta since they're
unlikely to block.



Chris Murphy

[Clyde E. Kunkel]

On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote:
>  On Dec 14, 2013, at 12:25 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > 
>  > I really would like to see other people's proposals in this area. I'm
>  > not at all convinced I'm going to be the person who comes up with the
>  > best idea. I'd love to know what cmurf would suggest as an overall
>  > approach to designing a set of Final release criteria or a storage
>  > validation test plan, for instance.
>  
>  What do you think of moving any blocking storage related criteria and tests, from final
> to beta or even alpha? Why not move as much potential for blockers to alpha and beta
> releases as possible?
>  
>  An example of this is moving resize test and criterion to beta (or split between alpha
> and beta if that's sensible and helpful). If resize were busted, do we really only
> want to find out and start dealing with it, and maybe slipping on it, during final? Seems
> risky, especially if a fix depends on upstream developers. Or public beta eats OS X or
> Windows for lunch.
>  
>  Since alpha and beta blocking criteria are still in effect post-beta, there will still be
> storage related blocking bugs after beta release. But there wouldn't be new blockers
> based on additional criteria. Rather than increasing the quality of beta, the main idea is
> to increase the predictability of final and reduce risk of regressions and final release
> slip. 
>  
>  I think guided partitioning should be fairly rock solid, and even though it's the
> "simple" path, it's still a beast of a matrix. I mentioned this in a
> different thread, but I think either LVM or LVM Thin Provisioning needs to be demoted. We
> don't need two LVM options in Guided. And if we can't get buy off on that, then
> we'll have to just eat that extra testing, because I think Guided shouldn't get
> people into trouble.
>  
>  Custom partitioning needs to be triaged for certain use cases we really want to work, and
> make those blocking if they fail. It may not be the same list for i386, x86_64/EFI, and
> ARM. e.g. we supposedly block on raid5 for x86_64, but does that make sense for ARM? Other
> combinations, even if there's a crash, would be non-blocking bugs, and only the
> subjective FE determination applies.
>  
>  Obviously the data corruption proscription is still in place, so crashes that lead to
> mangled partition tables or previously working file systems, presumably would block.
> However, I wonder if that criterion should be split in two: clearly not OK block worthy
> cases probably ought to be an alpha or beta blocker at the latest; and those that are
> suitable for FE or merely being documented could be permitted post-beta since they're
> unlikely to block.
>  
>  
>  
>  Chris Murphy 
+1.  Move as much as makes sense in the storage testing to as early as
possible.

More on storage validation strategy (was: Re: Criterion revision proposal: KDE default applications)

[Adam Williamson]

On Tue, 2013-12-17 at 09:45 -0700, Chris Murphy wrote:
>  On Dec 14, 2013, at 12:25 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > 
>  > I really would like to see other people's proposals in this area. I'm
>  > not at all convinced I'm going to be the person who comes up with the
>  > best idea. I'd love to know what cmurf would suggest as an overall
>  > approach to designing a set of Final release criteria or a storage
>  > validation test plan, for instance.
>  
>  What do you think of moving any blocking storage related criteria and
>  tests, from final to beta or even alpha? Why not move as much
>  potential for blockers to alpha and beta releases as possible?
>  
>  An example of this is moving resize test and criterion to beta (or
>  split between alpha and beta if that's sensible and helpful). If
>  resize were busted, do we really only want to find out and start
>  dealing with it, and maybe slipping on it, during final? Seems risky,
>  especially if a fix depends on upstream developers. Or public beta
>  eats OS X or Windows for lunch. 
Personally, no, I don't think that's correct. In fact we just got done
doing the opposite change (after F18, we weakened the Alpha storage
criteria quite a lot).

My take is this: the criteria define what needs to be working for us to
release. They do not define what we ought to be testing at each
milestone.

We ought to be testing everything at each milestone, ideally. If that's
not possible we need to test as much as we can. I'm not a huge fan of
the Release Level column in the matrices, because it kinda gives the
wrong impression. Even if a given test would only block Final release if
it failed, not Alpha or Beta, *that doesn't mean we should only run it
at Final*. We should run it at Alpha and Beta too, so we know if it's
broken.

I'm as guilty of taking the shortcut and punting on doing early tests as
anyone. We're all human. But conceptually, the questions of 'what needs
testing when?' and 'what do we block the release on?' are separate
questions, and it is incorrect to make modifications to the release
criteria simply to 'force' us to test stuff earlier. The correct
question to be answering when deciding "what should be in the Alpha
release criteria?" is, simply, "what needs to be working for us to ship
a product labelled Alpha?" It's that simple.

>  Since alpha and beta blocking criteria are still in effect
> post-beta,
>  there will still be storage related blocking bugs after beta release.
>  But there wouldn't be new blockers based on additional criteria. 
Just to reiterate the above, *that shouldn't be happening now anyway*
(except when the code actually breaks between Beta and Final, which does
happen). We should be doing the testing by Beta and identifying all the
Final blockers that exist by Beta. This is the goal I'm trying to work
towards with all the revisions I'm proposing and thinking about, insofar
as that's plausible with fedora.next hanging over us. We should be able
to run our entire set of validation tests at Alpha and Beta, we should
not be staging the test workload.

>   Rather than increasing the quality of beta, the main idea is to
>  increase the predictability of final and reduce risk of regressions
>  and final release slip.  
I think this is a great goal indeed.

>  I think guided partitioning should be fairly rock solid, and even
>  though it's the "simple" path, it's still a beast of a matrix. 
Yup. That's definitely one of the problems.

>   I mentioned this in a different thread, but I think either LVM or
> LVM
>  Thin Provisioning needs to be demoted. We don't need two LVM options
>  in Guided. And if we can't get buy off on that, then we'll have to
>  just eat that extra testing, because I think Guided shouldn't get
>  people into trouble. 
I broadly agree with this. If we were designing to the test cases, I'd
say we should just throw that damn dropdown out entirely. You want
something other than our default filesystem (whatever it is), you go to
custom partitioning. But the best design for testers is not necessary
the best design for users :) It's possibly worth considering, though.

As I mentioned, oldUI only let you pick LVM or ext4. newUI added btrfs,
with the 'everything's going btrfs!' plan in mind, I think. And F20
added LVM thinp. So now we have 2x what oldUI had. (And actually, I
think the 'don't use LVM' checkbox was only added to oldUI in like F15
or something).

We did have a kind of clear policy with oldUI, which is that we tested
its version of 'guided' partitioning quite extensively, and custom
partitioning got a lot less in terms of testing and criteria guarantees.
We've been pushing that boat out since F18; maybe we need to pull it
back in again. newUI guided does, I think, provide just about all the
same possibilities oldUI non-custom did, with a slightly different
approach. I think, whatever the details we come up with, the broad
direction "emphasize testing of guided, de-emphasize testing of custom"
- along with the improvements to the guided UI that Mo is currently
working on - looks productive for the future.

So, I'm thinking...just looking at my rough draft matrix...perhaps we
need something like it, or even bigger, but with a policy attached in
some way (I don't necessarily mean a literal policy document, I'm
talking in conceptual terms). The policy would be something like testing
priority goes to guided, always, and we should aim to do complete
testing of guided at each milestone, including Alpha. For custom
partitioning, I think we should look to define some kind of reasonable -
*small* - subset of its functionality that we can 'stand behind'. We
would write criteria for that, and a test plan for it, and like the
guided partitioning, aim to cover it at every milestone, with #2
priority after the guided testing. The kind of stuff that would fall in
this bucket would be the custom partitioning 'greatest hits' - things
that are reasonably common that you can't do via non-custom. 'Ghetto
upgrade of a previous default Fedora install' is an obvious one.
'Install to this fairly sane layout I pre-created' is another. We'd have
to try and think through others to go in the set, maybe together with
the anaconda folks.

Then we could have 'bonus point' matrices for much more custom
partitioning functionality, and try to do as much of that testing as we
can, and ask anaconda to treat major bugs we discover as a high
priority. But we don't block on them, and this testing always comes #3
after the guided and 'blocking custom' paths. As long as this overall
plan is sufficiently clear so they don't scare people off, we can make
the 'bonus point' matrices as huge as we like.

What do you think of that as an approach?

>  Custom partitioning needs to be triaged for certain use cases we
>  really want to work, and make those blocking if they fail. It may not
>  be the same list for i386, x86_64/EFI, and ARM. e.g. we supposedly
>  block on raid5 for x86_64, but does that make sense for ARM? Other
>  combinations, even if there's a crash, would be non-blocking bugs, and
>  only the subjective FE determination applies. 
Right.

>  Obviously the data corruption proscription is still in place, so
>  crashes that lead to mangled partition tables or previously working
>  file systems, presumably would block. However, I wonder if that
>  criterion should be split in two: clearly not OK block worthy cases
>  probably ought to be an alpha or beta blocker at the latest; and those
>  that are suitable for FE or merely being documented could be permitted
>  post-beta since they're unlikely to block. 
The wording that they must be 'fixed or documented' already has this
effect - it gives us the flexibility to make that call on an
issue-by-issue basis.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

>  Given that, I propose re-wording as follows:
>  
>  "All applications that can be launched using the standard graphical
>  mechanism of a release-blocking live image after an installation of that
>  image must start successfully and withstand a basic functionality test." 
I have read the whole thread, multiple things are discussed here. My take on this:

1. I agree with the proposed criterion. Our team is inherently best-effort driven and we
need to very carefully and cleverly prioritize. This helps us guide us in the right
direction.

2. Some people claim that DVD and Live install result should be the same. Adam's
proposal doesn't contradict that, just gives us a working solution before such state
is reached. Once relevant people implement the changes in DVD or Lives, the "live
image" part of the proposal becomes redundant and can be removed.

3. As long as DVD and Live install differ, I agree that the Live package set contains the
most important packages from the Spin's view and those should get the most testing.
Our website heavily promotes Live installs, and most of the general users do Live
installs, because they use our website (if you read this, you're not a general user).
The other packages, only available on DVD, are clearly not that important. That
doesn't mean we can't accept a proposed blocker in such a package, if it is
especially important (eat-your-computer type), just the "basic functionality"
criterion won't apply automatically to them.

4. As for DVD existence - yes, I also consider it outdated. It tries to solve bandwidth
problems in a wrong way. I imagine a world with Lives for general audience, netinst for
expert audience, and multi-Lives for marketing purposes. The bandwidth problem should be
solved by a simple program:
a. you run it on computer A (lacking bandwidth) - it gathers the list of installed
packages and exports a file
b. then you run it on computer B (good bandwidth) - feed it the file and tell what
programs you want to download, it fetches all the RPMs and makes a repository
c. then you bring the files back to computer A, and either using that file again or GNOME
Software it mounts the repository and allows you to install the programs available
The whole program is trivial (even its GUI), and it solves everything DVD attempts to
solve. You can use it any time, not just at the release date (it downloads fresh versions
of programs, DVD only contains stale ones).
With this approach, we can also make a special-purpose media for special occasions - want
to ship apps for kids in Africa? Just download the RPMs based on the package set of a
default installation, copy/burn the repo to the media and ship it together with Lives.
Since there's nothing else than a yum repo, it's trivial to check for correctness.
No QA needed.
We can make a different set of this extra offline-access media for Africa kids, for
Graphics Designers conference, for Gamers festival, for Scientific classes in universities
etc. Do you see the large possibilities that generic DVD can never help with? And hey, we
can even put the Live installer and this additional repo to the same medium as a second
partition, no need to have two media. So you stick it in, boot Live and install, and then
you reboot to a working system, stick it in and have additional software available.

[Richard Ryniker]

Kamil Paral <kparal(a)redhat.com&gt; wrote on Fri, 20 Dec 2013 05:00:24 -0500

> The bandwidth problem should be solved by a simple program:
> a. you run it on computer A (lacking bandwidth) - it gathers the list of installed
> packages and exports a file
> b. then you run it on computer B (good bandwidth) - feed it the file and tell what
> programs you want to download, it fetches all the RPMs and makes a repository
> c. then you bring the files back to computer A, and either using that
> file again or GNOME Software it mounts the repository and allows you to
> install the programs available 
Simple program, yes, but operationally complicated.  Hope you get all the
programs you want the first time, else repeat until you get it right.

Were I to perform Fedora installations without Internet connectivity, I
should be tempted instead to copy the entire Fedora repositories to a
portable disk.  That way, anything I did not know I wanted would be right
at hand.  Job done in one visit.  Other people could use my disk to
install whatever package sets they wanted.

With a world of use cases, no scheme will be best for everyone.  I like
your idea of a live system with optional repository, but where is
Anaconda in this picture?  Must everyone who wants a configuration not
possible with live install use netinstall?

Will F21 be the first Fedora release with three versions (workstation,
server, cloud)?  Will each project make independent decisions about
distribution strategy?  

> Since there's nothing else than a yum repo, it's trivial to
> check for
> correctness. 
I beg to differ.  Instead of a "frozen" image, with direct management to
limit changes, you suggest a plethora of collections that are likely to
span a larger part of Fedora's total package set.  If you mean to prepare
specialized repositories only from packages in the DVD collection, there
is no advantage: just keep the DVD.

I feel there are many chapters yet to be written in the story of Fedora's
distribution mechanism.  Partition of the problem may be appropriate.
Instead of a search for a globl distribution scheme, direct each project
and spin to make choices appropriate for their target audience.  The
cloud project will see network installation the only thing they want,
while SoaS delivers a complete system image with no need for a network.

Interesting times ahead.

Fedora-21-Standard-x86_64[i386]-DVD.iso

[poma]

On 13.12.2013 12:37, Rejy M Cyriac wrote:
...
>  I differ with you on this point. There are still so many places in
> the
>  world with limited/expensive/slow, or even no network connectivity at
>  all. In fact, it is only in the developed countries that broadband is
>  prevalent like water, and in the rest of the world, just like water, it
>  is a limited resource.
>  
>  On a related note, folks in the developed world might be surprised to
>  know that 32-bit processors are still very much in use.
>  
>  I work with the Free Media project of Fedora, and I know of so many
>  instances where providing the Fedora DVD (32 and 64 bit) has empowered
>  the lives of people and small organisations. 
http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64[i3...
Fedora-20-x86_64[i386]-DVD.iso

Fedora-21-Standard-x86_64[i386]-DVD.iso
Whence disappeared in Fedora.next!?


poma

Fedora-21-Standard-x86_64[i386]-DVD.iso

[Adam Williamson]

On Wed, 2014-09-10 at 01:12 +0200, poma wrote:
>  On 13.12.2013 12:37, Rejy M Cyriac wrote:
>  ...
>  > I differ with you on this point. There are still so many places in the
>  > world with limited/expensive/slow, or even no network connectivity at
>  > all. In fact, it is only in the developed countries that broadband is
>  > prevalent like water, and in the rest of the world, just like water, it
>  > is a limited resource.
>  > 
>  > On a related note, folks in the developed world might be surprised to
>  > know that 32-bit processors are still very much in use.
>  > 
>  > I work with the Free Media project of Fedora, and I know of so many
>  > instances where providing the Fedora DVD (32 and 64 bit) has empowered
>  > the lives of people and small organisations.
>  
>  http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64[i3...
>  Fedora-20-x86_64[i386]-DVD.iso
>  
>  Fedora-21-Standard-x86_64[i386]-DVD.iso
>  Whence disappeared in Fedora.next!? 
F21 will not have any generic DVD image. It will have a DVD-type (I'm
trying to call them 'offline' now) image for Server which contains only
the Server package groups. The question of having or not having the DVD
was kicked back and forth quite a bit, I'm not sure why you decided to
just quote one random mail from one thread about it from ten months ago.
QA can't really change that decision, it's a FESCo choice in the end.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Fedora-21-Standard-x86_64[i386]-DVD.iso

[poma]

On 10.09.2014 01:21, Adam Williamson wrote:
>  On Wed, 2014-09-10 at 01:12 +0200, poma wrote:
> > On 13.12.2013 12:37, Rejy M Cyriac wrote:
> > ...
> >> I differ with you on this point. There are still so many places in the
> >> world with limited/expensive/slow, or even no network connectivity at
> >> all. In fact, it is only in the developed countries that broadband is
> >> prevalent like water, and in the rest of the world, just like water, it
> >> is a limited resource.
> >>
> >> On a related note, folks in the developed world might be surprised to
> >> know that 32-bit processors are still very much in use.
> >>
> >> I work with the Free Media project of Fedora, and I know of so many
> >> instances where providing the Fedora DVD (32 and 64 bit) has empowered
> >> the lives of people and small organisations.
> >
> > http://dl.fedoraproject.org/pub/fedora/linux/releases/20/Fedora/x86_64[i3...
> > Fedora-20-x86_64[i386]-DVD.iso
> >
> > Fedora-21-Standard-x86_64[i386]-DVD.iso
> > Whence disappeared in Fedora.next!?
>  
>  F21 will not have any generic DVD image. It will have a DVD-type (I'm
>  trying to call them 'offline' now) image for Server which contains only
>  the Server package groups. The question of having or not having the DVD
>  was kicked back and forth quite a bit, I'm not sure why you decided to
>  just quote one random mail from one thread about it from ten months ago.
>  QA can't really change that decision, it's a FESCo choice in the end.
>   
All together should read what the man wrote till the moment of the comprehension of the
essence of the written.
Fedora is a great project, perhaps too great for those who have invented it.


poma