3:16 p.m.
Hey, all. I'm currently poking at the release criteria to try and
address a few issues that have come up during blocker meetings. I have
drafts of revised versions of all three pages up:
https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_criteria_revision
https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_criteria_revision
https://fedoraproject.org/wiki/User:Adamwill/Draft_Final_criteria_revision
The biggest change is to add this paragraph to the preamble of all three
pages:
"There may be times where a requirement is unmet only in a particular
configuration, such as with some keyboard layouts but not others, or if
a particular character is used in a username, password or passphrase. In
such cases, the release team should use their judgment and refer to
precedent to determine whether or not the issue should be considered to
block the release. They should consider the number of users likely to be
affected by the issue, the severity of the case when the issue is
encountered, and the ease or otherwise with which the issue can be
avoided by both informed and uninformed users. "
This is the best approach I could come up with for dealing with the
various cases that have come up where login or encrypted partitions or
something is broken with certain keymaps or characters; it didn't seem
to quite work to add a specific criterion for 'all non-US keymaps' or
something, it seems rather better to address it as a general principle.
Comments on this approach welcome!
The other changes:
Alpha: Actually account for firstboot, which we completely ignored until
now. The criterion about 'booting to a working desktop' was split into
two and now covers firstboot. I also explicitly called out encryption
here, and tweaked the language about 'user intervention' to 'unintended
user intervention'.
Beta: Significantly, add a criterion requiring that install methods
supposed to be unattended must actually run unattended: they shouldn't
prompt for anything. Aside from that, same change as for Alpha regarding
'user intervention', tweak the criterion regarding panel elements to
also disallow them being completely non-functional (this lines up better
with the actual test), and add a (if any) disclaimer to the bit about
options for shutting down and restarting the system (since Shell doesn't
have all of those).
Final: tweak the Applications stuff a bit for shell, and clarify #12 a
little. Improve the wording of #14 slightly.
Can everyone let me know what they think of these changes? Thanks!
There may be a few more coming later as I go through the blocker meeting
logs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:35 p.m.
Adam Williamson <awilliam <at> redhat.com> writes:
Hey, all. I'm currently poking at the release criteria to try
and
address a few issues that have come up during blocker meetings. I have
drafts of revised versions of all three pages up:
https://fedoraproject.org/wiki/User:Adamwill/Draft_Alpha_criteria_revision
https://fedoraproject.org/wiki/User:Adamwill/Draft_Beta_criteria_revision
https://fedoraproject.org/wiki/User:Adamwill/Draft_Final_criteria_revision
<snip>
Can everyone let me know what they think of these changes? Thanks!
Should there be an explicit requirement for Final at least, that the image
itself have a working mediacheck?
https://bugzilla.redhat.com/show_bug.cgi?id=676551
Although an external check is always possible, and necessary to verify that the
image isn't evil, most casual users probably don't know how to do it, which
could lead to a lot of wasted time with spurious bug reports.
4:33 p.m.
On Thu, 2011-03-17 at 20:35 +0000, Andre Robatino wrote:
Should there be an explicit requirement for Final at least, that the
image
itself have a working mediacheck?
https://bugzilla.redhat.com/show_bug.cgi?id=676551
Although an external check is always possible, and necessary to verify that the
image isn't evil, most casual users probably don't know how to do it, which
could lead to a lot of wasted time with spurious bug reports.
It's a good proposal, I would support it...anyone else have an opinion?
We should check with anaconda team too.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:46 a.m.
On Thu, 2011-03-17 at 14:33 -0700, Adam Williamson wrote:
On Thu, 2011-03-17 at 20:35 +0000, Andre Robatino wrote:
> Should there be an explicit requirement for Final at least, that the image
> itself have a working mediacheck?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=676551
>
> Although an external check is always possible, and necessary to verify that the
> image isn't evil, most casual users probably don't know how to do it, which
> could lead to a lot of wasted time with spurious bug reports.
It's a good proposal, I would support it...anyone else have an opinion?
We should check with anaconda team too.
Oh, good point, I like this idea. My only caution is if it might be too
coupled with a specific implementation. I could see the criteria being
loosely coupled when worded such as, "the provided media verification
procedures operate as intended". However, having criteria more tightly
coupled with an implementation, such as "The user must be prompted for
media verification whenever booting the installer using ISO media from
an optical drive" seems to define policy that the installer should
always prompt for mediacheck. I like it, just not sure if this is the
right place to require that? Thoughts/ideas?
Side-topic ... perhaps a dumb question ... but does mediacheck still
catch valid errors? I seem to recall times when mediacheck passes, but
the media can still be bad.
Thanks,
James
5:58 a.m.
On 03/17/2011 08:16 PM, Adam Williamson wrote:
Alpha: Actually account for firstboot, which we completely ignored
until
now. The criterion about 'booting to a working desktop' was split into
two and now covers firstboot. I also explicitly called out encryption
here, and tweaked the language about 'user intervention' to 'unintended
user intervention'.
I think we should continue to ignore it along with not depending alpha
on a working graphical desktop or in more current terms graphical.target
of any kind
Alpha criteria should only be built around...
Install ( Criteria that matches Anaconda or any other installer we might
have )
boot into multiuser.target
Working network.target ( criteria that can fit any network application )
1 working language ( US UTF-8 ) with sane password support ( not
supporting some password craziness like triple tab entry's and what not.
We seem to be more and more starting migrating Alpha into Beta criteria
Alpha != Beta
Reporters should expect various things not working in alpha such is the
nature of the rawhide beast..
Just my 2 cents
JBG
9:14 a.m.
On Fri, Mar 18, 2011 at 10:58:26 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
On 03/17/2011 08:16 PM, Adam Williamson wrote:
> Alpha: Actually account for firstboot, which we completely ignored until
> now. The criterion about 'booting to a working desktop' was split into
> two and now covers firstboot. I also explicitly called out encryption
> here, and tweaked the language about 'user intervention' to 'unintended
> user intervention'.
I think we should continue to ignore it along with not depending alpha
on a working graphical desktop or in more current terms graphical.target
of any kind
I disagree with this. A lot of what we want tested needs a graphical desktop.
If we were to ship an Alpha without a working desktop, we wouldn't get much
feedback (other than that the desktop doesn't work).
9:27 a.m.
On Fri, 2011-03-18 at 09:14 -0500, Bruno Wolff III wrote:
On Fri, Mar 18, 2011 at 10:58:26 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
> On 03/17/2011 08:16 PM, Adam Williamson wrote:
> > Alpha: Actually account for firstboot, which we completely ignored until
> > now. The criterion about 'booting to a working desktop' was split into
> > two and now covers firstboot. I also explicitly called out encryption
> > here, and tweaked the language about 'user intervention' to
'unintended
> > user intervention'.
>
> I think we should continue to ignore it along with not depending alpha
> on a working graphical desktop or in more current terms graphical.target
> of any kind
I disagree with this. A lot of what we want tested needs a graphical desktop.
If we were to ship an Alpha without a working desktop, we wouldn't get much
feedback (other than that the desktop doesn't work).
I agree with Bruno. The suggestion conflicts with one of the stated
objectives of the Alpha, "Test accepted features of Fedora 15" as this
would prevent testing of any desktop-related features.
That said, if we ever have SIG-specific criteria, the proposed change
would be perfectly suitable criteria for the Server-SIG.
Thanks,
James
10:14 a.m.
On 03/18/2011 02:27 PM, James Laska wrote:
> I disagree with this. A lot of what we want tested needs a
graphical desktop.
> > If we were to ship an Alpha without a working desktop, we wouldn't get
much
> > feedback (other than that the desktop doesn't work).
That's mostly cause we are working on outdated thoughts and dreams of
the project which the project and the community has outgrown long time
ago by shipping an "Default" in any shape or form .( From my perspective )
So I can get a bit on the page what is the feedback you general expect
surrounding alpha and from whom?
( Rawhide users/reporters should know it's broken in the first place and
provide feedback )
Shipping "Alpha/Beta" is only a marketing gimmick anyway and it outdated
the day we finally ship that stuff..
I agree with Bruno. The suggestion conflicts with one of the stated
objectives of the Alpha, "Test accepted features of Fedora 15" as this
would prevent testing of any desktop-related features.
If I'm not mistaken the the feature process entirely optional so tying
the "testing" of features into our release cycle so closely does not
make any sense to be perhaps someone is willing to refresh my memory by
explaining it to me why we did that in the first place?
That said, if we ever have SIG-specific criteria, the proposed
change
would be perfectly suitable criteria for the Server-SIG.
It is time for us ( QA ) to get more in times with the evolution of the
project and start considering SIG specific criteria or better yet a
solution more consistent with and built upon other things we have been
working like critical-path.
JBG
10:31 a.m.
On Fri, Mar 18, 2011 at 15:14:41 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
( Rawhide users/reporters should know it's broken in the first
place and
provide feedback )
By alpha we are working with 'branched' not 'rawhide'. The point remains
valid, but using the wrong name for it might cause confusion.
Shipping "Alpha/Beta" is only a marketing gimmick anyway
and it outdated
the day we finally ship that stuff..
It is a useful marketing gimmick. It helps us get more widespread testing.
If I'm not mistaken the the feature process entirely optional so
tying
the "testing" of features into our release cycle so closely does not
make any sense to be perhaps someone is willing to refresh my memory by
explaining it to me why we did that in the first place?
Optional in what sense? If they don't get completed we can drop them, but
in order for at least some of them to get completed, testing is needed.
Alpha (and in some cases test days) provides a way to get help testing.
10:48 a.m.
On Fri, 2011-03-18 at 15:14 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/18/2011 02:27 PM, James Laska wrote:
>> I disagree with this. A lot of what we want tested needs a graphical desktop.
>> > If we were to ship an Alpha without a working desktop, we wouldn't get
much
>> > feedback (other than that the desktop doesn't work).
That's mostly cause we are working on outdated thoughts and dreams of
the project which the project and the community has outgrown long time
ago by shipping an "Default" in any shape or form .( From my perspective )
So we should define criteria that apply to a project model/workflow that
doesn't exist? I'm all for having criteria that work for our project,
which I believe this thread is addressing.
So I can get a bit on the page what is the feedback you general
expect
surrounding alpha and from whom?
( Rawhide users/reporters should know it's broken in the first place and
provide feedback )
Shipping "Alpha/Beta" is only a marketing gimmick anyway and it outdated
the day we finally ship that stuff..
You forgot to add ... "in my opinion" ;)
Marketing is certainly one important angle in *any* release milestone.
I wouldn't say it's only driver. If we want to debate the merits of
release milestones, that perhaps should be a different thread.
> I agree with Bruno. The suggestion conflicts with one of the
stated
> objectives of the Alpha, "Test accepted features of Fedora 15" as this
> would prevent testing of any desktop-related features.
If I'm not mistaken the the feature process entirely optional so tying
the "testing" of features into our release cycle so closely does not
make any sense to be perhaps someone is willing to refresh my memory by
explaining it to me why we did that in the first place?
Read the lists/wiki for the history. The feature process has it's
flaws. What adjustments do you recommend?
> That said, if we ever have SIG-specific criteria, the proposed
change
> would be perfectly suitable criteria for the Server-SIG.
It is time for us ( QA ) to get more in times with the evolution of the
project and start considering SIG specific criteria or better yet a
solution more consistent with and built upon other things we have been
working like critical-path.
As I said in the previous mail, I don't disagree with the idea of
SIG-specific criteria. The beauty of this behind-the-times team is that
you can propose an idea, and if it's good+scalable+effective, it will
stick. My caution with SIG-specific criteria is that I believe there
are policy issues beyond just criteria definition. We are hijacking
Adam's thread, so perhaps this would be best started as a new topic...
describe your vision of SIG-specific criteria, what is success in that
world?
Thanks,
James
12:04 p.m.
On Fri, 2011-03-18 at 15:14 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/18/2011 02:27 PM, James Laska wrote:
>> I disagree with this. A lot of what we want tested needs a graphical desktop.
>> > If we were to ship an Alpha without a working desktop, we wouldn't get
much
>> > feedback (other than that the desktop doesn't work).
That's mostly cause we are working on outdated thoughts and
dreams of
the project which the project and the community has outgrown long time
ago by shipping an "Default" in any shape or form .( From my perspective )
As James said, that's considerably beyond the scope of both this thread
and this group. It's not QA's job to define the vision of the project,
it's our job to validate the release process and the released products
that we *do* have. If you want to change those things, the way to do it
is not through the release criteria.
This also applies to the question of which spins block the release.
That's not something that is defined in the criteria, or that should be.
It's an issue for the Board and the Spins SIG, which have been
discussing it lately, including at FUDCon.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:17 p.m.
On 03/18/2011 05:04 PM, Adam Williamson wrote:
As James said, that's considerably beyond the scope of both this
thread
and this group. It's not QA's job to define the vision of the project,
it's our job to validate the release process and the released products
that we*do* have. If you want to change those things, the way to do it
is not through the release criteria.
Yes and that surrounds the so called "Default" thus no other spin should
be able to block it.
This also applies to the question of which spins block the release.
That's not something that is defined in the criteria, or that should be.
It's an issue for the Board and the Spins SIG, which have been
discussing it lately, including at FUDCon.
This is something that is not on the hands of the Board or the Spins SIG
but something that the QA community should decide.
JBG
1:28 p.m.
On Fri, 2011-03-18 at 17:17 +0000, "Jóhann B. Guðmundsson" wrote:
> This also applies to the question of which spins block the
release.
> That's not something that is defined in the criteria, or that should be.
> It's an issue for the Board and the Spins SIG, which have been
> discussing it lately, including at FUDCon.
This is something that is not on the hands of the Board or the Spins
SIG but something that the QA community should decide.
I disagree. I don't see anything in the structure of Fedora project
which gives us the power to decide which spins block release. That's a
policy issue, as I see it.
(Certainly other groups feel this is not our choice to make; when I
proposed having the LXDE and Xfce spins block the release, this
eventually didn't happen based on feedback from other groups,
particularly releng).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:11 p.m.
On 03/18/2011 06:28 PM, Adam Williamson wrote:
On Fri, 2011-03-18 at 17:17 +0000, "Jóhann B. Guðmundsson"
wrote:
>> This also applies to the question of which spins block the release.
>> That's not something that is defined in the criteria, or that should be.
>> It's an issue for the Board and the Spins SIG, which have been
>> discussing it lately, including at FUDCon.
> This is something that is not on the hands of the Board or the Spins
> SIG but something that the QA community should decide.
I disagree. I don't see anything in the structure of Fedora project
which gives us the power to decide which spins block release. That's a
policy issue, as I see it.
I would think that QA handles QA related matters after all we are
ultimately responsible if corrupted bits are pushed out in the hands
user if that happens that means something went wrong in our process.
Of course those decisions should be made in collaboration with the
various groups in the community if/when needed.
(Certainly other groups feel this is not our choice to make; when I
proposed having the LXDE and Xfce spins block the release, this
eventually didn't happen based on feedback from other groups,
particularly releng).
Given that those groups decide whether or not those two spins ( and most
likely any other ) could block a release or not they must have already a
well defined criteria for what is considered for a spin to block a
release did they happen to mention point to a wikipage for that ( saves
the trouble of us coming up with one. )
JBG
8:15 a.m.
On Thu, 2011-03-17 at 13:16 -0700, Adam Williamson wrote:
Can everyone let me know what they think of these changes? Thanks!
There may be a few more coming later as I go through the blocker meeting
logs.
I hope you don't mind ... but my brain+eyes needed to see a patch
(available at http://fpaste.org/PX5u/).
--- Fedora_15_Alpha_Release_Criteria.wiki 2011-03-18
08:36:31.976770141 -0400
+++ Draft_Alpha_criteria_revision.wiki 2011-03-18 08:36:31.511803151 -0400
@@ -8,6 +8,8 @@
== Alpha Release Requirements ==
In order to be the released to the general public, the Alpha Candidate (RC) must meet
'''all''' of the following criteria. This is intended to make the
decision process as clear and straightforward as possible. ''Mostly met''
items are ''incomplete'' until they are ''met.'' Optional
and ''nice to have'' items should not be included in this list.
+There may be times where a requirement is unmet only in a particular configuration, such
as with some keyboard layouts but not others, or if a particular character is used in a
username, password or passphrase. In such cases, the release team should use their
judgment and refer to precedent to determine whether or not the issue should be considered
to block the release. They should consider the number of users likely to be affected by
the issue, the severity of the case when the issue is encountered, and the ease or
otherwise with which the issue can be avoided by both informed and uninformed users.
For me, this nicely captures the additional criteria we need to consider
when faced with sometimes fuzzy issues. I tend to be a list person, so
I'd probably split the tail-end of this into a list, certainly not
required though.
# All bugs blocking the
[https://bugzilla.redhat.com/showdependencytree.cgi?id=f15alpha&hide_r... Alpha
tracker] must be [[BugZappers/BugStatusWorkFlow#CLOSED|CLOSED]]
# There must be no file conflicts (cases where the files in some packages conflict but
the packages have explicit Conflicts: tags are acceptable) or unresolved package
dependencies during a media-based (CD/DVD) install
# All dedicated installer images must boot to the graphical boot menu and allow the user
to select install options. If no option is selected, the installer should load after a
reasonable timeout
@@ -21,7 +23,8 @@
# The installer must be able to complete an installation using the entire disk, existing
free space, or existing Linux partitions methods, with or without encryption enabled
# The rescue mode of the installer must start successfully and be able to detect and
mount an existing default installation
# The installer must be able to report failures to Bugzilla, with appropriate
information included
-# In most cases, the installed system must boot to a functional graphical environment
without user intervention (see
[[Blocker_Bug_FAQ#Hardware_and_local_configuration_dependent_issues|Blocker_Bug_FAQ]])
+# In most cases (see
[[Blocker_Bug_FAQ#Hardware_and_local_configuration_dependent_issues|Blocker_Bug_FAQ]]), a
system installed according to any of the above criteria (or the appropriate Beta or Final
criteria, when applying this criterion to those releases) must boot to the
'firstboot' utility on the first boot after installation, without unintended user
intervention. This includes correctly accessing any encrypted partitions when the correct
passphrase is supplied. The firstboot utility must be able to create a working user
account
+# Following on from the previous criterion, after firstboot is completed and on
subsequent boots, a system installed according to any of the above criteria (or the
appropriate Beta or Final criteria, when applying this criterion to those releases) must
boot to a working graphical environment without unintended user intervention. This
includes correctly accessing any encrypted partitions when the correct passphrase is
supplied
What does "without unintended user intervention" mean? Is that
distinguishing between manual installs, and unattended installations
where firstboot --disabled?
Why is "This includes correctly accessing any encrypted partitions when
the correct passphrase is supplied." included in both the firstboot and
the graphical login criteria? Will it cover the same situations if that
statement is listed only in the second criteria addition (the must boot
to graphical criteria)?
# When booting a system installed without a graphical environment,
or when using a correct configuration setting to cause an installed system to boot in
non-graphical mode, the system should boot to a state where it is possible to log in
through at least one of the default virtual consoles
# It must be possible to run the default web browser and a terminal application from the
default desktop environment. The web browser must be able to download files, load
extensions, and log into [https://admin.fedoraproject.org/accounts/ FAS]
# The installed system must be able to download and install updates with yum and
PackageKit
--- Fedora_15_Beta_Release_Criteria.wiki 2011-03-18 08:36:33.307675652 -0400
+++ Draft_Beta_criteria_revision.wiki 2011-03-18 08:36:32.797711857 -0400
@@ -7,6 +7,8 @@
== Beta Release Requirements ==
In order to be the released to the general public, the Beta Candidate (RC) must meet
'''all''' of the following criteria. This is intended to make the
decision process as clear and straightforward as possible. ''Mostly met''
items are ''incomplete'' until they are ''met.'' Optional
and ''nice to have'' items should not be included in this list.
+There may be times where a requirement is unmet only in a particular configuration, such
as with some keyboard layouts but not others, or if a particular character is used in a
username, password or passphrase. In such cases, the release team should use their
judgment and refer to precedent to determine whether or not the issue should be considered
to block the release. They should consider the number of users likely to be affected by
the issue, the severity of the case when the issue is encountered, and the ease or
otherwise with which the issue can be avoided by both informed and uninformed users.
+
Release Requirements:
# All [[Fedora 15 Alpha Release Criteria]] must be met
# All bugs blocking the
[https://bugzilla.redhat.com/showdependencytree.cgi?id=f15beta&hide_re... Beta
tracker] must be [[BugZappers/BugStatusWorkFlow#CLOSED|CLOSED]]
@@ -18,16 +20,17 @@
# The installer must be able to use all kickstart delivery methods
# The installer must be able to create and install to software, hardware or BIOS RAID-0,
RAID-1 or RAID-5 partitions for anything except /boot
# The installer must be able to successfully complete an upgrade installation from a
clean, fully updated default installation of the previous stable Fedora release, either
via preupgrade or by booting to the installer manually
+# Any installation method or process designed to run unattended must do so (there should
be no prompts requiring user intervention)
Thanks for taking a stab at this ... this has languished on my TODO list
for too long. We've discussed this one several times, and I can't think
of any clever wording to avoid pulling in *every* obscure kickstart
scenario.
"Any installation method or process" ... we capture installation methods
elsewhere in the Alpha, Beta and Final criteria. Howabout we leave
installation method out of these additions, and keep it focused on "Any
installation designed to run unattended..."? Does that lose specific
scenarios you were wanting to include?
As worded, "designed to run unattended", includes any traceback
encountered during an unattended install, regardless of whether the
kickstart file is formatted correctly, or doing sane things? How can we
distinguish between anaconda failures (captured by *many* other
criteria), vs unattended install failures. Hopefully, I'm making sense
here. :)
This isn't great, but what about: "The installer must correctly honor
any properly formatted unattended installation configuration and, if
directed, install the system with no user intervention."
# The rescue mode of the installer must be able to detect and mount
(read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software)
installations
-# When booting a system installed without a graphical environment, or when using a
correct configuration setting to cause an installed system to boot in non-graphical mode,
the system should provide a working login prompt without any user intervention (aside from
the firstboot utility) when boot is complete, and all virtual consoles intended to provide
a working login prompt should do so
+# When booting a system installed without a graphical environment, or when using a
correct configuration setting to cause an installed system to boot in non-graphical mode,
the system should provide a working login prompt without any unintended user intervention
when boot is complete, and all virtual consoles intended to provide a working login prompt
should do so
Same clarification as stated earlier around the scenarios included by
the statement, "without any unintended user intervention".
# The release must boot successfully as a virtual guest in a
situation where the virtual host is running the same release (using Fedora's current
preferred virtualization technology)
# The release must boot successfully as a virtual guest in a situation where the virtual
host is running the previous stable Fedora release (using Fedora's current preferred
virtualization technology)
# The release must boot successfully as a virtual guest in a situation where the virtual
host is running a supported Xen implementation
# In most cases, the installed system must be able to play back sound with
gstreamer-based applications (see
[[Blocker_Bug_FAQ#Hardware_and_local_configuration_dependent_issues|Blocker_Bug_FAQ]])
-# No part of the default desktop's panel (or equivalent) configuration should crash
on boot of the installed system using default installation choices
+# No part of the default desktop's panel (or equivalent) configuration should crash
or be entirely non-functional on boot of the installed system using default installation
choices
Ack
# Automatic mounting on insertion of removable media must work in
the default desktop environment
# The desktop default update manager must not periodically check for updates when the
system is booted live, but must periodically check for updates when running on an
installed system
-# The desktop's offered mechanisms for shutting down, logging out and rebooting must
work
+# The desktop's offered mechanisms (if any) for shutting down, logging out and
rebooting must work
Ack
<!--
IF we need this ... we fail
# The QA team has an installable testable Release Candidate for at least two full days
(48 hours).
--- Fedora_15_Final_Release_Criteria.wiki 2011-03-18 08:36:34.296605443 -0400
+++ Draft_Final_criteria_revision.wiki 2011-03-18 08:36:33.837638029 -0400
@@ -5,6 +5,8 @@
== Final Release Requirements ==
In order to be the released to the general public, the Final Candidate (RC) must meet
'''all''' of the following criteria. This is intended to make the
decision process as clear and straightforward as possible. ''Mostly met''
items are ''incomplete'' until they are ''met.'' Optional
and ''nice to have'' items should not be included in this list.
+There may be times where a requirement is unmet only in a particular configuration, such
as with some keyboard layouts but not others, or if a particular character is used in a
username, password or passphrase. In such cases, the release team should use their
judgment and refer to precedent to determine whether or not the issue should be considered
to block the release. They should consider the number of users likely to be affected by
the issue, the severity of the case when the issue is encountered, and the ease or
otherwise with which the issue can be avoided by both informed and uninformed users.
+
Release Requirements:
# All [[Fedora 15 Beta Release Criteria]] must be met
# All bugs blocking the
[https://bugzilla.redhat.com/showdependencytree.cgi?id=f15blocker&hide...
F15Blocker tracker] must be [[BugZappers/BugStatusWorkFlow#CLOSED|CLOSED]]
@@ -18,13 +20,13 @@
# The installed system must run normally if the user chooses to install without SELinux
# Menu sanity - the following criteria refer to both a live image and default installed
system
#* All ''Applications'' listed in the desktop menus must have icons
which have a consistent appearance and sufficiently high resolution to avoid appearing
blurry
-#* All applications listed under the ''Applications'' menu must start
successfully
-#* All applications listed under the ''Applications'' menu must
withstand a basic functionality test and not crash after a few minutes of normal use.
They must also have working ''Help'' and ''Help ->
About'' menu items
-#* There must be no ''Other'' menu
+#* All applications listed under the ''Applications'' menu or category
must start successfully
+#* All applications listed under the ''Applications'' menu or category
must withstand a basic functionality test and not crash after a few minutes of normal use.
They must also have working ''Help'' and ''Help ->
About'' menu items
+#* There must be no ''Other'' menu or category
Good catch, ack.
#* No application may unintentionally appear twice in the menus. In
particular, items under ''System'' must not appear under
''Applications''
-# All elements of the default panel configuration must be functional
+# All elements of the default panel (or equivalent) configuration must function
correctly in common use
I was confused this might be a DUP of the beta criteria at first. But I
recall now that this captures *all* Desktop Environments, not just the
default.
# Saving passwords in the desktop default keyring (if the desktop
implements one), and retrieving passwords from the keyring, must work
-# The proposed final Fedora artwork is included and enabled by default for the
installer, graphical boot, firstboot, graphical login and desktop background. All Fedora
artwork must be consistent with the proposed final theme, and if any artwork contains a
graphical version number, the version number used must match the Fedora release number.
Generic release artwork (e.g. Alpha, Beta, Development) must not be used for the final
release.
+# The proposed final Fedora artwork must be included and enabled by default for the
installer, graphical boot, firstboot, graphical login and desktop background. All Fedora
artwork must be consistent with the proposed final theme, and if any artwork contains a
graphical version number, the version number used must match the Fedora release number.
Generic release artwork (e.g. Alpha, Beta, Development) must not be used for the final
release
Ack
== Final Blocker Bugs ==
A bug is considered a
[https://bugzilla.redhat.com/showdependencytree.cgi?id=f15blocker&hide...
Final Blocker Bug] if '''any''' of the following criteria are met:
Thanks,
James
9:11 a.m.
<snip>
Given that we are revisting the release criteria I propose that we
update ourselves to more recent times to reflect the project more
accurately.
Due to historical reasons the readiness of the KDE spin has had the
ability to block the final release of the "Default" spin hence I
propose that no spin can block the release of the "Default" what ever
that may be or "All" spin need to meet the release criteria or we slip.
Thoughts?
JBG
10:52 a.m.
On Fri, Mar 18, 2011 at 14:11:59 +0000,
"\"Jóhann B. Guðmundsson\"" <johannbg(a)gmail.com> wrote:
Due to historical reasons the readiness of the KDE spin has had the
ability to block the final release of the "Default" spin hence I
propose that no spin can block the release of the "Default" what ever
that may be or "All" spin need to meet the release criteria or we slip.
Thoughts?
I'd like to see some spelled out criteria for determining which spins can block
a release, I don't think all spins being able to block a release is a good
idea, with the way spins are handled now. Personally I'd like to see criteria
that allows KDE to block releases. But beyond that, I think the other spins
impact is low enough, that other options are better than blocking a release.
12:09 p.m.
On 03/18/2011 03:52 PM, Bruno Wolff III wrote:
I'd like to see some spelled out criteria for determining which
spins can block
a release, I don't think all spins being able to block a release is a good
idea, with the way spins are handled now. Personally I'd like to see criteria
that allows KDE to block releases. But beyond that, I think the other spins
impact is low enough, that other options are better than blocking a release.
KDE only is allowed to block a release due to historical reasons and it
would be intersting to see by which criteria you are going to implement
to determine which spin gets to block a release and which not.
Personally I feel that everything should get an equal treatment within
the community hence we should have a process that treats each spin
equally thus we should either focus on what ever is currently
implemented as an "Default" or all spins need to meet the release
criteria before a final release.
JBG
12:37 p.m.
On 03/18/2011 10:39 PM, "Jóhann B. Guðmundsson" wrote:
Personally I feel that everything should get an equal treatment
within
the community hence we should have a process that treats each spin
equally thus we should either focus on what ever is currently
implemented as an "Default" or all spins need to meet the release
criteria before a final release.
Do you have to insist on repeating this view point on every possible
occasion? That is a board/fesco mandate and outside the scope of
release criteria.
Rahul
5:32 p.m.
On Thu, 2011-03-17 at 13:16 -0700, Adam Williamson wrote:
Hey, all. I'm currently poking at the release criteria to try
and
address a few issues that have come up during blocker meetings. I have
drafts of revised versions of all three pages up:
So aside from the long sidetrack, I didn't get any negative feedback on
these, so I plan to push them soon.
I'd like to propose one additional change. I'd like to extend this Beta
criterion:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation of the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually "
To read:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation of the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually. The upgraded system must meet all release
criteria"
to make it clear that we want upgraded systems to work to the same level
as new installs, we don't just want the upgrade process to succeed.
Sound okay? thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5:41 p.m.
On 03/28/2011 10:32 PM, Adam Williamson wrote:
I'd like to propose one additional change. I'd like to extend
this Beta
criterion:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation of the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually "
To read:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation of the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually. The upgraded system must meet all release
criteria"
to make it clear that we want upgraded systems to work to the same level
as new installs, we don't just want the upgrade process to succeed.
Sound okay? thanks!
It would be good if you would include all the live media atleast the
handout media.
So we would cover all the *DE and what else we hand out at various events.
JBG
5:51 p.m.
On Mon, 2011-03-28 at 22:41 +0000, "Jóhann B. Guðmundsson" wrote:
It would be good if you would include all the live media atleast the
handout media.
So we would cover all the *DE and what else we hand out at various events.
Can you *please* stop derailing these threads? I was asking for feedback
on the specific proposed changes, not any old random ideas anyone has
for changes to the criteria. If you want to propose some changes that
are different from mine, please draft them up and start a new thread.
It's really disruptive when you just throw a grenade into a different
thread like that; you already completely derailed my first attempt to
get some feedback on these changes, please don't do it again.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:02 p.m.
On 03/28/2011 10:51 PM, Adam Williamson wrote:
Can you*please* stop derailing these threads? I was asking for
feedback
on the specific proposed changes, not any old random ideas anyone has
for changes to the criteria. If you want to propose some changes that
are different from mine, please draft them up and start a new thread.
It's really disruptive when you just throw a grenade into a different
thread like that; you already completely derailed my first attempt to
get some feedback on these changes, please don't do it again.
Yes and I was proposing that you would instead of only include the
default install that we would include all the *DE spins and any other
hand out media that get handed out on events so we would cover the
upgrade path on those as well?
So what is the right thing to do here?
Do you want first to draft your whole proposal than others will review
that and come up with a different proposal and then we hold a vote on QA
meeting which proposal will make the change?
JBG
6:12 p.m.
On Mon, 2011-03-28 at 23:02 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/28/2011 10:51 PM, Adam Williamson wrote:
> Can you *please* stop derailing these threads? I was asking for feedback
> on the specific proposed changes, not any old random ideas anyone has
> for changes to the criteria. If you want to propose some changes that
> are different from mine, please draft them up and start a new thread.
> It's really disruptive when you just throw a grenade into a different
> thread like that; you already completely derailed my first attempt to
> get some feedback on these changes, please don't do it again.
Yes and I was proposing that you would instead of only include the
default install that we would include all the *DE spins and any other
hand out media that get handed out on events so we would cover the
upgrade path on those as well?
What desktops are considered to block the release is, as I explained the
last time you tried to derail the thread, a bigger issue and not
something we can just unilaterally declare by rewriting a release
criterion. I do _not_ want to get dragged into that tarpit when I'm just
trying to tighten up the existing criteria in a non-controversial way.
Do you want first to draft your whole proposal than others will
review
that and come up with a different proposal and then we hold a vote on
QA meeting which proposal will make the change?
If you actually think there's something about my proposed changes that
should be revised, please state specifically what it is and give your
alternative text - not vague stuff but direct quote and an actual
alternative text. Then we can all discuss which is better. If you just
want to propose something different, please start a new thread, and
again, provide a concrete text proposal.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:41 p.m.
On 03/28/2011 11:12 PM, Adam Williamson wrote:
If you actually think there's something about my proposed changes
that
should be revised, please state specifically what it is and give your
alternative text
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated installation of Gnome and KDE the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually. The upgraded system must meet all release
criteria"
Added KDE there since it can currently block the release and is
presented as an alternative installation option on the DVD.
you probably want include there as well upgrade path from the relevant
live media counterpart if default installation extends to live media as
well.
JBG
6:47 p.m.
On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/28/2011 11:12 PM, Adam Williamson wrote:
> If you actually think there's something about my proposed changes that
> should be revised, please state specifically what it is and give your
> alternative text
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated installation of Gnome and KDE the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually. The upgraded system must meet all release
criteria"
Added KDE there since it can currently block the release and is
presented as an alternative installation option on the DVD.
you probably want include there as well upgrade path from the relevant
live media counterpart if default installation extends to live media as
well.
I don't think there's any need to call out the specific currently
supported desktops in the criterion. The criteria are supposed to be
generic and adapt well to change; this criterion would need to be
re-written any time we changed policy on supported desktops.
It may be worth explicitly stating that any kind of supported install
should be upgradeable, how about:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation (from any
official install medium) of the previous stable Fedora release, either
via preupgrade or by booting to the installer manually. The upgraded
system must meet all release criteria"
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7 p.m.
On 03/28/2011 11:47 PM, Adam Williamson wrote:
It may be worth explicitly stating that any kind of supported
install
should be upgradeable, how about:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation (from any
official install medium) of the previous stable Fedora release, either
via preupgrade or by booting to the installer manually. The upgraded
system must meet all release criteria"
I think this covers it well.
Ack.
2:27 p.m.
On Mon, 2011-03-28 at 16:47 -0700, Adam Williamson wrote:
On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 03/28/2011 11:12 PM, Adam Williamson wrote:
> > If you actually think there's something about my proposed changes that
> > should be revised, please state specifically what it is and give your
> > alternative text
>
> "The installer must be able to successfully complete an upgrade
> installation from a clean, fully updated installation of Gnome and KDE the
> previous stable Fedora release, either via preupgrade or by booting to
> the installer manually. The upgraded system must meet all release
> criteria"
>
> Added KDE there since it can currently block the release and is
> presented as an alternative installation option on the DVD.
>
> you probably want include there as well upgrade path from the relevant
> live media counterpart if default installation extends to live media as
> well.
I don't think there's any need to call out the specific currently
supported desktops in the criterion. The criteria are supposed to be
generic and adapt well to change; this criterion would need to be
re-written any time we changed policy on supported desktops.
It may be worth explicitly stating that any kind of supported install
should be upgradeable, how about:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation (from any
official install medium) of the previous stable Fedora release, either
via preupgrade or by booting to the installer manually. The upgraded
system must meet all release criteria"
Does it make sense to phase this criteria in? Meaning, it would be
nice-to-have this release, and blocker material next release? I'd have
to see what testing results, and want to see if the desktop@ team also
agrees, since they'll be responsible for resolving these issues.
Thanks,
James
2:34 p.m.
On Tue, 2011-03-29 at 15:27 -0400, James Laska wrote:
> "The installer must be able to successfully complete an
upgrade
> installation from a clean, fully updated default installation (from any
> official install medium) of the previous stable Fedora release, either
> via preupgrade or by booting to the installer manually. The upgraded
> system must meet all release criteria"
Does it make sense to phase this criteria in? Meaning, it would be
nice-to-have this release, and blocker material next release? I'd have
to see what testing results, and want to see if the desktop@ team also
agrees, since they'll be responsible for resolving these issues.
I didn't really see it as a change, more a clarification. In practice
we've always treated it as 'upgrades have to work' in the sense that the
upgraded system must actually run, not just 'the upgrade process must
complete'. So I'm not sure it's necessary.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:46 p.m.
On Tue, 2011-03-29 at 12:34 -0700, Adam Williamson wrote:
On Tue, 2011-03-29 at 15:27 -0400, James Laska wrote:
> > "The installer must be able to successfully complete an upgrade
> > installation from a clean, fully updated default installation (from any
> > official install medium) of the previous stable Fedora release, either
> > via preupgrade or by booting to the installer manually. The upgraded
> > system must meet all release criteria"
>
> Does it make sense to phase this criteria in? Meaning, it would be
> nice-to-have this release, and blocker material next release? I'd have
> to see what testing results, and want to see if the desktop@ team also
> agrees, since they'll be responsible for resolving these issues.
I didn't really see it as a change, more a clarification. In practice
we've always treated it as 'upgrades have to work' in the sense that the
upgraded system must actually run, not just 'the upgrade process must
complete'. So I'm not sure it's necessary.
True true, I was thinking more about some of the nuances with applets,
icons and all applications run without error on the upgraded system.
But you clearly limited this to a @default installation, so I think that
covers my concerns about this covering *too* many failures we (Fedora)
couldn't possibly respond to in a timely manner.
Thanks,
James
3:03 p.m.
On Tue, 2011-03-29 at 15:46 -0400, James Laska wrote:
On Tue, 2011-03-29 at 12:34 -0700, Adam Williamson wrote:
> On Tue, 2011-03-29 at 15:27 -0400, James Laska wrote:
>
> > > "The installer must be able to successfully complete an upgrade
> > > installation from a clean, fully updated default installation (from any
> > > official install medium) of the previous stable Fedora release, either
> > > via preupgrade or by booting to the installer manually. The upgraded
> > > system must meet all release criteria"
> >
> > Does it make sense to phase this criteria in? Meaning, it would be
> > nice-to-have this release, and blocker material next release? I'd have
> > to see what testing results, and want to see if the desktop@ team also
> > agrees, since they'll be responsible for resolving these issues.
>
> I didn't really see it as a change, more a clarification. In practice
> we've always treated it as 'upgrades have to work' in the sense that
the
> upgraded system must actually run, not just 'the upgrade process must
> complete'. So I'm not sure it's necessary.
True true, I was thinking more about some of the nuances with applets,
icons and all applications run without error on the upgraded system.
But you clearly limited this to a @default installation, so I think that
covers my concerns about this covering *too* many failures we (Fedora)
couldn't possibly respond to in a timely manner.
yeah, it doesn't mean that we should block the release if any
non-default bit of anyone's random upgrade test fails.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:28 p.m.
On Mon, 2011-03-28 at 16:47 -0700, Adam Williamson wrote:
On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson"
wrote:
> On 03/28/2011 11:12 PM, Adam Williamson wrote:
> > If you actually think there's something about my proposed changes that
> > should be revised, please state specifically what it is and give your
> > alternative text
>
> "The installer must be able to successfully complete an upgrade
> installation from a clean, fully updated installation of Gnome and KDE the
> previous stable Fedora release, either via preupgrade or by booting to
> the installer manually. The upgraded system must meet all release
> criteria"
>
> Added KDE there since it can currently block the release and is
> presented as an alternative installation option on the DVD.
>
> you probably want include there as well upgrade path from the relevant
> live media counterpart if default installation extends to live media as
> well.
I don't think there's any need to call out the specific currently
supported desktops in the criterion. The criteria are supposed to be
generic and adapt well to change; this criterion would need to be
re-written any time we changed policy on supported desktops.
It may be worth explicitly stating that any kind of supported install
should be upgradeable, how about:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation (from any
official install medium) of the previous stable Fedora release, either
via preupgrade or by booting to the installer manually. The upgraded
system must meet all release criteria"
Okay - I have now put into production all the revisions discussed up to
this point in the thread, including my initial proposals, plus this
revision to the upgrade criteria. I'm still thinking about the
'supported desktops' thing, so haven't changed that yet - I'll send a
new proposal out later. Thanks to all for input.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:07 p.m.
On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson" wrote:
Added KDE there since it can currently block the release and is
presented as an alternative installation option on the DVD.
So, here's my thinking on this. For all desktop criteria, change the
wording 'desktop' or 'default desktop' to 'supported desktop(s)',
and
make it a link to a page or section of another page which defines the
currently supported desktops - which are GNOME and KDE.
thoughts?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:56 p.m.
On Mon, Mar 28, 2011 at 18:07:24 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson"
wrote:
> Added KDE there since it can currently block the release and is
> presented as an alternative installation option on the DVD.
So, here's my thinking on this. For all desktop criteria, change the
wording 'desktop' or 'default desktop' to 'supported desktop(s)',
and
make it a link to a page or section of another page which defines the
currently supported desktops - which are GNOME and KDE.
thoughts?
That sounds fairly future proof.
10:01 p.m.
On 03/29/2011 08:26 AM, Bruno Wolff III wrote:
On Mon, Mar 28, 2011 at 18:07:24 -0700,
Adam Williamson<awilliam(a)redhat.com> wrote:
> On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson" wrote:
>
>> Added KDE there since it can currently block the release and is
>> presented as an alternative installation option on the DVD.
>
> So, here's my thinking on this. For all desktop criteria, change the
> wording 'desktop' or 'default desktop' to 'supported
desktop(s)', and
> make it a link to a page or section of another page which defines the
> currently supported desktops - which are GNOME and KDE.
>
> thoughts?
That sounds fairly future proof.
To really make it future proof a lightweight desktop e.g. LXDE (not just
a spin) must be included as fully supported and as default desktop
alongside the heavy weights.
Notebooks and tablets is the future.
with Regards,
ASHWIN
10:08 p.m.
On Tue, 2011-03-29 at 08:31 +0530, Ashwin Mansinghka wrote:
To really make it future proof a lightweight desktop e.g. LXDE (not
just
a spin) must be included as fully supported and as default desktop
alongside the heavy weights.
Notebooks and tablets is the future.
For the third time: that's not our decision to make. We do not decide
which desktops are supported. Please don't derail the thread.
(also...have you ever actually tried to use LXDE on a tablet?!)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:08 p.m.
On 03/29/2011 01:07 AM, Adam Williamson wrote:
On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson"
wrote:
> Added KDE there since it can currently block the release and is
> presented as an alternative installation option on the DVD.
So, here's my thinking on this. For all desktop criteria, change the
wording 'desktop' or 'default desktop' to 'supported desktop(s)',
and
make it a link to a page or section of another page which defines the
currently supported desktops - which are GNOME and KDE.
thoughts?
Great futureproof and flexible suggestion.
I however think it would be better to skip the word "supported" and just
have "desktop(s)" and the wiki page. ( we can start by listing one or
two desktops and add more later )
As I see it the only support you get is community support ( support
might indicate to some people something more than community support )
and we are a community project and the support does seem to be pretty
even amongst the *DE and the community in general so it comes a bit odd
to me that not all current desktop we have would be listed there and as
they come and go they can be added/removed from that page.
I would not be too surpriced in not to distant future that the dvd
release in it's current form will be depracted and (some) *DE start
releasing their own spesific larger iso images that contain both a live
image with all the bells and whistle they have to offer along with an
installer which you would just choose between at bootup as in boot into
live image or boot into installer or some other solution into that
direction.
I give my ack on the change without the word "support" in it.
JBG
2:40 a.m.
On Tue, 2011-03-29 at 04:08 +0000, "Jóhann B. Guðmundsson" wrote:
On 03/29/2011 01:07 AM, Adam Williamson wrote:
> On Mon, 2011-03-28 at 23:41 +0000, "Jóhann B. Guðmundsson" wrote:
>
>> Added KDE there since it can currently block the release and is
>> presented as an alternative installation option on the DVD.
> So, here's my thinking on this. For all desktop criteria, change the
> wording 'desktop' or 'default desktop' to 'supported
desktop(s)', and
> make it a link to a page or section of another page which defines the
> currently supported desktops - which are GNOME and KDE.
>
> thoughts?
Great futureproof and flexible suggestion.
I however think it would be better to skip the word "supported" and just
have "desktop(s)" and the wiki page. ( we can start by listing one or
two desktops and add more later )
As I see it the only support you get is community support ( support
might indicate to some people something more than community support )
and we are a community project and the support does seem to be pretty
even amongst the *DE and the community in general so it comes a bit odd
to me that not all current desktop we have would be listed there and as
they come and go they can be added/removed from that page.
I would not be too surpriced in not to distant future that the dvd
release in it's current form will be depracted and (some) *DE start
releasing their own spesific larger iso images that contain both a live
image with all the bells and whistle they have to offer along with an
installer which you would just choose between at bootup as in boot into
live image or boot into installer or some other solution into that
direction.
I give my ack on the change without the word "support" in it.
I agree 'supported' isn't quite the right word, but I think we need some
kind of adjective there. I'll try and think of something better.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:41 a.m.
On Tue, Mar 29, 2011 at 00:40:07 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
I agree 'supported' isn't quite the right word, but I think we need some
kind of adjective there. I'll try and think of something better.
Something needs to be said there, as otherwise people will wonder why only
some of the desktop spins are listed. "Supported" is close to what we mean,
but the intended nuance might be confusing given what people may assume
about the what kind of support is implied. But nothing else specific comes
to mind as a better word.
8:43 a.m.
On Tue, 2011-03-29 at 08:41 -0500, Bruno Wolff III wrote:
On Tue, Mar 29, 2011 at 00:40:07 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
>
> I agree 'supported' isn't quite the right word, but I think we need
some
> kind of adjective there. I'll try and think of something better.
Something needs to be said there, as otherwise people will wonder why only
some of the desktop spins are listed. "Supported" is close to what we mean,
but the intended nuance might be confusing given what people may assume
about the what kind of support is implied. But nothing else specific comes
to mind as a better word.
Provided?
poc
12:10 p.m.
On Tue, 2011-03-29 at 09:13 -0430, Patrick O'Callaghan wrote:
On Tue, 2011-03-29 at 08:41 -0500, Bruno Wolff III wrote:
> On Tue, Mar 29, 2011 at 00:40:07 -0700,
> Adam Williamson <awilliam(a)redhat.com> wrote:
> >
> > I agree 'supported' isn't quite the right word, but I think we need
some
> > kind of adjective there. I'll try and think of something better.
>
> Something needs to be said there, as otherwise people will wonder why only
> some of the desktop spins are listed. "Supported" is close to what we
mean,
> but the intended nuance might be confusing given what people may assume
> about the what kind of support is implied. But nothing else specific comes
> to mind as a better word.
Provided?
No, because we 'provide' many more desktops than just GNOME and KDE. The
point is that _only_ those two can currently block releases.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:25 p.m.
On Tue, 2011-03-29 at 10:10 -0700, Adam Williamson wrote:
On Tue, 2011-03-29 at 09:13 -0430, Patrick O'Callaghan wrote:
> On Tue, 2011-03-29 at 08:41 -0500, Bruno Wolff III wrote:
> > On Tue, Mar 29, 2011 at 00:40:07 -0700,
> > Adam Williamson <awilliam(a)redhat.com> wrote:
> > >
> > > I agree 'supported' isn't quite the right word, but I think we
need some
> > > kind of adjective there. I'll try and think of something better.
> >
> > Something needs to be said there, as otherwise people will wonder why only
> > some of the desktop spins are listed. "Supported" is close to what we
mean,
> > but the intended nuance might be confusing given what people may assume
> > about the what kind of support is implied. But nothing else specific comes
> > to mind as a better word.
>
> Provided?
No, because we 'provide' many more desktops than just GNOME and KDE. The
point is that _only_ those two can currently block releases.
I love the idea, but caution that we are defining, not supporting
policy.
I know we aren't defining this, since it's a generally understood
concept. But I worry if no page already exists that defines
"supported", this will be perceived as QA defining what a supported DE
is. Possibly overly sensative.
Should we pitch the proposal+draft to FESCO for comments?
I've always liked the layout of the Architectures page [1]. Can we
borrow the "Secondary" term from that page?
Thanks,
James
[1] https://fedoraproject.org/wiki/Architectures#Secondary_Architectures
2:19 p.m.
On Mon, 2011-03-28 at 15:32 -0700, Adam Williamson wrote:
On Thu, 2011-03-17 at 13:16 -0700, Adam Williamson wrote:
> Hey, all. I'm currently poking at the release criteria to try and
> address a few issues that have come up during blocker meetings. I have
> drafts of revised versions of all three pages up:
So aside from the long sidetrack, I didn't get any negative feedback on
these, so I plan to push them soon.
I'd like to propose one additional change. I'd like to extend this Beta
criterion:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation of the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually "
To read:
"The installer must be able to successfully complete an upgrade
installation from a clean, fully updated default installation of the
previous stable Fedora release, either via preupgrade or by booting to
the installer manually. The upgraded system must meet all release
criteria"
to make it clear that we want upgraded systems to work to the same level
as new installs, we don't just want the upgrade process to succeed.
Sound okay? thanks!
This sounds great ... and I believe lines up with the tests that Hurry
and others have been running on upgraded systems.
ACK!
Thanks,
James
4788
days inactive
4800
days old
42 comments
8 participants
participants (8)
-
Adam Williamson -
Andre Robatino -
Ashwin Mansinghka -
Bruno Wolff III -
James Laska -
Jóhann B. Guðmundsson -
Patrick O'Callaghan -
Rahul Sundaram