Proposed generic release criterion: service manipulation
by Adam Williamson
Still working on Fedora 21 release criteria. It seems to me that there's
one area currently lacking in the criteria which all the Products would
probably like us to have, hence I'm proposing it as a new 'generic'
criterion, not Product-specific. We still haven't figured out exactly
how to present the criteria, so for now I'm proposing this one be added
as a new Fedora 21 Alpha criterion, i.e. it goes to
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria (under
"Post-install requirements"). Here's the proposed criterion:
System service manipulation
It must be possible to start, stop, enable and disable system services
using the initialization framework's standard commands.
I don't think it needs any footnotes beyond standard 'References'.
Does this seem reasonable to everyone? Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 8 months
Re: 2014-07-09 @ **17:00 UTC** - F21 Blocker Review #1
by Bruno Wolff III
On Wed, Jul 09, 2014 at 23:07:12 +0400,
Igor Gnatenko <ignatenkobrain(a)fedoraproject.org> wrote:
>Hi,
>On Wed, Jul 9, 2014 at 4:20 AM, Mike Ruckman <roshi(a)fedoraproject.org> wrote:
>> # F21 Blocker Review meeting #1
>> # Date: 2014-07-09
>> # Time: 17:00 UTC (13:00 EST, 10:00 PST)
>> # Location: #fedora-blocker-review on irc.freenode.neteria
>> ...
>> ==
>> // Mike
>> Fedora QA
>> irc: roshi | twitter: roshi_fedora
>> blog: roshi.fedorapeople.org
>Why this msg not going to the test-announce@? :P
I don't think the meeting log needs to go to test-announce. If the complaint
is really about the meeting notice, then that is arguably a reasonable
suggestion.
9 years, 8 months
Workstation status and TODOs
by Josh Boyer
Hi All,
We have just less than 3 months before the F21 Alpha change deadline
comes. That means that now is the time to get going in earnest on
making sure we have all the things we want lined up for the initial
release of Workstation done. Matthias and Christian have done a great
job of getting us started, and have gotten some major Changes
approved. The GNOME 3.12 rebase was accepted, and the enabling of
SCLs should go over fairly well once the questions are addressed.
So what is left? Off the top of my head I can think of:
1) Getting the kickstart for Workstation cleaned up with the
appropriate package lists (I'd be willing to get this rolling)
2) Integrating KDE into the above in whatever form we work out with the KDE team
3) KDE variant of Adwaita theme
4) Firewall/firewalld integration issues
5) Installation and compose methods work with rel-eng (live image
default, but install tree necessary for compose. PXE/netboot iso?
etc)
I'm sure I'm missing a few things here. Please chime in with what I'm
forgetting. In short, there's more than enough work to go around.
Lastly, we've been rather quiet as a WG as of late. The Cloud WG is
going through a confirmation process with their members to make sure
people are still interested and willing to do work. That's not a bad
idea for ourselves. WG members, please take the time to reply with
whether or not you wish to remain a WG member.
As an aside, much of the "heavy lifting" in terms of process is done
for this release. The PRD and Tech Specs have been approved, and the
initial round of Changes are submitted. Not being overly familiar
with the underlying code in much of the DE stacks, my participation
has been limited mostly to those kinds of process things. I think we
still have some discussions to have on process and interactions with
other groups, but I thought I would double check that the WG feels I'm
doing a decent job representing them in this capacity. I'm happy to
continue to pitch in where I can, but if the WG feels they'd be better
served by someone else as the FESCo liaison, please speak up.
josh
9 years, 8 months
Draft combined Alpha release criteria for F21
by Adam Williamson
Hi, folks. So I've just slapped together the existing release criteria
drafts into a draft combined Fedora 21 Alpha release criteria page:
https://fedoraproject.org/wiki/User:Adamwill/Draft_F21_Alpha_criteria
product-specific notes:
Cloud - AFAICS the Cloud-specific draft Roshi did only took things away,
it didn't add any, so there is basically no change as far as Cloud is
concerned. The wirding should exempt Cloud from all inappropriate
criteria - please point out anywhere this is not the case.
Workstation - none of the proposed new criteria are Alpha criteria. The
Alpha proposals for a separate Workstation criteria page were
simplifications of the more 'generic' criteria that apply to multiple
desktops.
There appears to be considerable confusion over an important desktop-ish
question for F21, namely:
"Are network installs of GNOME/Workstation and/or KDE considered to be
release-blocking?"
That is, do we only block on the Workstation (product) and KDE (spin)
live images, or are we also going to block on network installation of
either or both?
As this has not been established, I have mostly left the desktop-y
criteria and preamble wording as-is, with the intent that we can fudge
it in the interpretation. If we decide that we do not block on desktop
network installs, we can refine and focus the wording somewhat; if we
decide to block on them, I'll have to insert something into the preamble
and possibly fiddling with the 'release-blocking desktop' wording a bit
to clarify precisely what we're talking about. This particularly affects
the desktop criteria (obviously) and the "Package sets" criterion, which
looks distinctly wobbly and would be a complete dead letter if we only
care about the live images.
I also just remembered that Workstation apparently wants to make it
possible to install KDE as an alternative desktop post-install, which
is...another fun thing to think about? Goddamnit, this is becoming a
real PITA.
Server - I plucked out the criteria that seemed most Alpha-y and
inserted them into this draft in appropriate places, basically. You'll
note that Server alone has a Product-specific section, down the bottom.
A couple of the criteria proposed for Server and/or Workstation actually
work okay as 'generic' criteria, so I added those into the generic
section: those would be "SELinux configuration" (SELinux must be
enforcing after installation - all Products want this, I believe) and
"Scripted user creation" (which is primarily for Server, but since
there's only one installer, it's probably fine for it to go in the
generic installer criteria).
I tweaked the "DVD package source" criterion to not refer to a
now-obsolete deliverable - it talks more generically about a "dedicated
installer image that contains packages". As things stand, I believe the
only such release-blocking medium will be the Server image that contains
server role packages (once we actually, you know, make that, but it's
listed in the Server tech spec).
I included the latest draft of my proposed "system service manipulation"
criterion, since this is still a draft and it seemed best to get all the
proposals in one place together.
I updated the definition of 'release-blocking images' in the preamble to
be appropriate for Fedora.next:
"The current set of release-blocking images includes the images defined
by the three primary Products - Server, Workstation and Cloud - in their
product requirement documents and/or technical specifications, and the
KDE live image."
(I could make that a lot damn cleaner if all the Products defined their
deliverables in the same document, btw :> some do it in PRD, some in
tech spec. Actually, we *still* ought to have a deliverables policy.
That's been on my todo list for, er, three years? Patches welcome. It's
not actually a QA job.)
There are probably still some corners of this that don't entirely make
sense any more, please point out any logic fails etc. But I think it's
probably at least better than the current page -
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria , which
is completely un-Next-ified - as a basis for Alpha testing, which I once
again remind folks, is supposed to start tomorrow :) So I'd like to get
this into 'production' before Alpha TC1 drops.
Next steps are going to be to write a couple more missing test cases,
and come up with a vaguely plausible set of test matrices. I'll try and
get that done this afternoon.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 8 months
Re: Proposed generic release criterion: service manipulation
by Adam Williamson
On Mon, 2014-07-07 at 11:50 -0400, Richard Ryniker wrote:
> > It must be possible to start, stop, enable and disable system
> > services using the initialization framework's standard commands.
>
> This sounds like any service that fails (will not start, will not
> stop...) will block a release.
You're the second person to read it that way, so clearly I wrote it
wrong, but no, that is not the intention at all.
> Should there be a distinction between "critical" services that must work
> or block release, and lesser services that may fail and not block
> release? For example, journald might be deemed critical, while sheepdog
> is not.
The intention is that the *mechanism* for manipulating services - that
is, at present, systemd - works to the extent specified. The criterion
assumes the notional service being manipulated is functional. In my
head, if I'd actually been writing the criterion you thought I was, I'd
have written something like "all system services in Fedora packages" or
"all system services on the release-blocking media" or something like
that - tied it to a *concrete* set of service scripts, not the entirely
abstract notion of "system services" that's in the current language.
Anyway, as I said, when two people read something wrong, I generally
figure I wrote it wrong, so - can anyone suggest wording that would make
this clearer?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 8 months
Re: Proposed generic release criterion: service manipulation
by Adam Williamson
On Mon, 2014-07-07 at 10:45 -0400, Miloslav Trmač wrote:
> ----- Original Message -----
> > On 07/04/2014 03:22 PM, Adam Williamson wrote:
> > > System service manipulation
> > >
> > > It must be possible to start, stop, enable and disable system
> > > services using the initialization framework's standard commands.
> > >
> > > I don't think it needs any footnotes beyond standard 'References'.
> > >
> > > Does this seem reasonable to everyone? Thanks!
> >
> > Is this another way of saying "All services must provide a systemd
> > unit file"?
No.
> Same question here. I’ve never heard of an “initialization framework”
> before, I'd guess that’s the piece of code and conventions to
> run .ctors. Just saying systemd would simplify things (though,
> perhaps s/must provide/must be controlled by/ ?)
As mitr (I think) understands, the criterion is intended to test
systemd. I said "initialization framework" because I have a pathological
attachment to generics, I guess. :P I meant it to be read as a generic
term for 'sysvinit, or systemd, or whatever we invent in five years to
replace systemd', so I don't have to rewrite the release criterion then.
If someone can think of a more commonly understood generic term, I'm
happy to substitute that. We *could* just say systemd, if everyone
promises to let me say "I told you so!" when someone notices in five
years it still says 'systemd' even though we all switched to openrc or
something. (har, har.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 8 months
Re: Default application handling external USB devices changed to "Disk analyser"?
by Philip Whitehouse
This seems to suggest both options are available, at least in a previous version of Gnome 3.
http://unix.stackexchange.com/questions/17660/default-applications-gnome-3
As to why its changed, I assume the RPM upgrade script for Disk Analyser did this. It probably shouldn't.
When I upgrade to Gnome 13 this evening I'll see if I can reproduce this issue.
Sent from my HTC
----- Reply message -----
From: "Ankur Sinha" <sanjay.ankur(a)gmail.com>
To: "Discussions about development for the Fedora desktop" <desktop(a)lists.fedoraproject.org>
Subject: Default application handling external USB devices changed to "Disk analyser"?
Date: Thu, Jul 3, 2014 08:32
Hi,
Has the default application that handles USB pluggable devices been
changed to "Disk analyser"? It used to be nautilus iirc. When I used to
plug my devices in, I used to generally get a "Open with Files"
notification. Now I get "Open with Disk Analyser." I'm not sure why I'd
like to open my device with "Disk Analyser" by default - I'd like to use
the device, not see its properties, most of the time.
Another thing - is it possible to choose an application from the
notification, or can one just use the application that is being
suggested?
--
Thanks,
Warm regards,
Ankur (FranciscoD)
http://fedoraproject.org/wiki/User:Ankursinha
Join Fedora! Come talk to us!
http://fedoraproject.org/wiki/Fedora_Join_SIG
9 years, 9 months