List of Qt/Qt5 packages for Fedora WS
by Lukáš Tinkl
Hi,
based on request of cschaller, I'm sending the proposed list of Qt/Qt5
packages to be included in Fedora Workstation:
qt
qt-x11
qt-settings
qt5-qtbase
qt5-qtimageformats
qt5-qtsvg
qt5-qtx11extras
qt5-qtxmlpatterns
qt5-qtdeclarative
qt5-qtquickcontrols
qt5-qtdoc
qt5-qtconnectivity
qt5-qtmultimedia
qt5-qtgraphicaleffects
(you can see the dep chain of qt5 packages here:
https://fedoraproject.org/wiki/KDE_updates)
--
Lukáš Tinkl <ltinkl(a)redhat.com>
Senior Software Engineer - KDE desktop team, Brno
KDE developer <lukas(a)kde.org>
Red Hat Inc. http://cz.redhat.com
9 years, 3 months
Introduction, Documenting Workstation
by Pete Travis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I'm acquainted with many of you already, but an introduction seems
fitting anyway. I've been involved with the project for a few years now,
primarily on the Docs team but also some light packaging and lately
light infrastructure things. I live in Montana, US, where the population
density is almost as low as the temperature. I work for a small
government agency doing user and systems support.
Why should you care? Well, the Docs team reached a decision this last
weekend to proactively work with the Product WGs to assess documentation
needs. I volunteered to liaison with the Workstation team. As we
approach the release cycle, I'd like everyone to keep documentation in
mind and the discussion open about not only implementation, but how to
represent that implementation to the users. An undocumented feature
isn't featured :)
I'm looking forward to working with everyone, perhaps saying hello at
the next meeting - there are meetings, right? - and developing a
presentation of the Workstation Product that shows off the capabilities
and character of your work.
- --
- -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode
- immanetize(a)fedoraproject.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTNW1PAAoJEL1wZM0+jj2Zos4H/37WaPQMRumzi766cXv6x3mb
ADJuFmZ+mZwosTynurCAKG5p8PczOHKhRrZNslf9nFNx4dczc94QJFlO7hPOq3Mr
WOzkSn6pUXppukAd6UxX7qAjtrNomYCM8kDlmyK+ArZmVbo78O2IppeSwZk4R/tJ
ILnktcYl4sXJjlOrA28X5uiZ0dvreuZPBT+UsiDZHVvFBQfaYqjUKIioW/R4wQYp
FoFvLbXe2XCn609LuHl0TcEP9DIwd2ShKROqw2fhXXSPe4jWWwkm0+FktwEKAt46
DqKBpIZeeIIZfiKXRPS6CCGNOULboepDKj+7RfqmtrjUIqdPQZ4ZP+Hdr1vSC3M=
=G3EO
-----END PGP SIGNATURE-----
9 years, 4 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, 5 months
Desktop and FirewallD
by Christian Schaller
Hi everyone,
So in response to the ongoing discussion about Firewall functionality and the desktop we had a call at the end of last week with some representatives from both
the desktop and firewall development teams, trying to figure out a good compromise and a way forward. I hope people can take the time to look over the ideas we discussed and let us know if you think it is a workable solution.
On the call was:
Thomas Woerner
Matthias Clasen
Bastien Nocera
Daniel Kopecek
Jiri Popelka
Peter Vrabec
We had a wide ranging discussion going from what is doable in the Fedora 21 timeframe to what we want from a firewall solution in the long run, what the setup is like on other operating systems, the tradeoffs between security and usability, API and adoption, ease of sharing versus unintended sharing and different corner cases where the different models might break down a bit.
We all agreed on the following core principles
* We want users to be as secure as possible
* We want users to have their privacy protected as well as possible
* We want users to have a good experience using our products
* We want users to be able to use services such as DLNA, Chromecast, Avahi and more without having to search on Google, and more often than not be told that the fix is to disable the firewall.
* We all agree that there is no perfect solutions on offer here. Just a range of different tradeoffs. A system with a running firewall isn't secure nor is a system without a firewall insecure. Instead they exist on a continium of 'more secure' and 'less secure'.
The challenges seen:
* With the current default a lot of services don't work out of the box because the firewall silently blocks them
* There doesn't seem to be any non-expensive way for the system to detect that a service is running and being blocked by the firwall.
* There is very limited use of the firewalld API for doing things like port unlocking and similar due to it being a predominately Fedora and RHEL only solution currently
* Some application developers who do look into using the current API find the API hard to use
* The current NetworkManager UI to change zones is both maybe a bit hidden away and also the Zones options listed there are not intuitive or documented in the UI.
Plans for Fedora 21
* The Desktop team will look into creating a UI that asks you when you connect to a new wireless network if you consider it trusted or not. Exact wording of the question and look of dialog etc. will need to be worked out. This setting will be remembered for that network. If user say trusted the zone used will be 'trusted', if not trusted then current default will be used. Should be simple enough to not confuse users, yet improve their security on public networks.
* Other connection types will keep the current default which sucks a bit for your home ethernet, but we don't currently have a good way to identify your ethernet connection and popping up a dialog every time you connect is
probably a worse user experience than having to google a bit.
Matthias started a prototype of this already here:
https://bugzilla.gnome.org/show_bug.cgi?id=727580
Long term plans
* Work with NetworkManager team to see if we can come up with a way to identify ethernet connections in a similar manner
* Look into proposing a new DBUS API for firewalld
* We will keep talking to see if there are more granular approaches that can be developed as we go forward. For many cases the trusted/untrusted question is a bit to simple. For instance you probably trust your work network, but that doesn't mean you want to share your beach vacation photos on the office network.
* Look into using the zones descriptions somehow in the NetworkManager Zone setting UI to make it a bit more understanable than just a list of names. FirewallD team will work on making the descriptions internationalizable.
Matthias filed two bugs related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=1091067 split off zone
configuration in subpackages
https://bugzilla.redhat.com/show_bug.cgi?id=1091068 overprotected api
9 years, 6 months
Gnome 3.12 to Fedora20?
by Greg
since i cant find anything new on this topic. im gonna ask . when is
3.12 gonna be pushed to the Fedora repo's? or is it still in
Discussion? if it is can someone point me to where i can follow the
conversation about this please.
thankyou
9 years, 6 months
Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Adam Williamson
Hi, folks. So continuing with the theme of setting up the Fedora.next QA
process, I thought before going too far with draft release criteria etc,
we could discuss a couple of important points that have come up since I
sent out the draft test plan.
There are two kind of similar issues in particular I'm thinking of.
First, at the QA meeting this week, tflink pointed out that we would
need to decide whether we will have sort of 'parallel' blocker/freeze
exception bug processes for each product. That is, do we have:
F21FinalBlocker
F21ServerFinalBlocker
F21WorkstationFinalBlocker
etc etc, and separate lists of blockers on
http://qa.fedoraproject.org/blockerbugs/current per product (and
non-Product-specific), and separate meetings? Or do we keep the
'unified' blocker nomination / review process, and just handle blocker
bugs for all Products within it?
At first blush I'd incline to keeping a single unified process, because
splitting them up seems like an awful lot of work and I'm not sure it
comes with a clear benefit. It also relies either on reporters correctly
determining what product their bug is relevant to, or on a triage step
for blocker nominations.
However, it's worth noting that if we allow the release schedules for
the Products to diverge in future, it would probably then be inevitable
that we'd need split blocker review (and release validation, for that
matter).
Second, there's a similar issue of organization with regard to the
release criteria. I haven't explicitly written this down anywhere, but
I've been sort of unconsciously expecting that we'd keep the existing
'generic' release criteria pages for criteria that are not
Product-specific, and then we'd have Product-specific release criteria
pages which would basically be *additive*: they'd add additional
criteria applicable only to that Product. They could also perhaps
'patch' the generic criteria to a limited degree, though this would get
messy if the delta got too great.
However, Mike (roshi) has produced draft release criteria for the Cloud
product as part of his work on the 'test outline' for that product -
https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Relea... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Releas... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Relea... - and used another possible approach; the criteria he has drawn up are clearly intended to be *comprehensive* with regard to the Cloud product. They would not need to be read in conjunction with the 'generic' criteria.
I'm not as sure which approach I prefer here, and to a degree the
difference between them isn't as clear cut as it appears at first
glance; however the criteria are ultimately presented, we'll likely have
several that are applicable to multiple Products. Even if these are
displayed multiple times on 'comprehensive' pages for each Product, they
might be shared at the 'source' level using mediawiki transclusion, for
instance (to prevent them diverging unintentionally). And of course we
aren't necessarily tied to mediawiki for presenting the criteria, which
is another factor to bear in mind (I know one of tflink's Grand Plans
involves a different way of maintaining and presenting the release
criteria).
Thoughts on the best approach for each of these issues would certainly
be appreciated! I thought it'd be best to take some time to think them
over before moving ahead with drafts and so on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 6 months
Re: Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Adam Williamson
On Wed, 2014-05-28 at 09:15 -0600, Mike Ruckman wrote:
> I think we might be able to strike a balance here between total
> separation and a unified blocker process (though it incurs a bit of
> overhead). Just as we currently mark bugs as blockers, we can continue
> to do that - but *also* mark them as F21<foo>FinalBlocker. This would
> allow for tracking at the product level but also keep some sanity with
> blocker meetings. Then, later down the road if the blocker process
> diverges with each product, they can simply drop the generic blocker
> tracking bug.
>
> I don't immediately see much of a downside to this - but then again,
> that doesn't mean there isn't :) At the very least it might lessen the
> learning curve as we carve a new path with Fedora.next.
I thought of something similar, but just as a whiteboard field entry, to
make it less intrusive. That should be enough metadata for searches.
I should note that I was remiss in my original email in missing one
issue with the 'combined' approach: it will likely require WG
representatives to be present at most blocker meetings. I expect we'd at
least want reps of any WG whose product is obviously affected by /
involved in a given blocker to be present at the review meeting(s) for
that blocker.
For the last few releases, blocker meetings have become almost QA-only a
lot of the time, or QA plus releng; we haven't had very good
representation from devs/packagers. A 'softly softly' approach to
improving that hasn't gone very well; I think outside of QA and releng,
people have developed this mindset where the blocker review process is
something that Just Sorta Happens in the background, and they only get
involved where it touches upon them directly (e.g. they're actually
assigned a bug that's nominated as a blocker). We're probably going to
have to change that mindset in a .next world: we would already quite
*like* the expertise and input of folks outside QA/releng to the blocker
process, but in a world with Products with more domain-specific release
criteria, we're really going to need it.
> > Second, there's a similar issue of organization with regard to the
> > release criteria. I haven't explicitly written this down anywhere, but
> > I've been sort of unconsciously expecting that we'd keep the existing
> > 'generic' release criteria pages for criteria that are not
> > Product-specific, and then we'd have Product-specific release criteria
> > pages which would basically be *additive*: they'd add additional
> > criteria applicable only to that Product. They could also perhaps
> > 'patch' the generic criteria to a limited degree, though this would
> > get messy if the delta got too great.
> >
> > However, Mike (roshi) has produced draft release criteria for the
> > Cloud product as part of his work on the 'test outline' for that
> > product -
> > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Relea... ,
> > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Releas... ,
> > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Relea...
> > - and used another possible approach; the criteria he has drawn up
> > are clearly intended to be *comprehensive* with regard to the Cloud
> > product. They would not need to be read in conjunction with the
> > 'generic' criteria.
>
> Just so we're clear here: I split out the cloud specific (from what I
> could tell) criteria out so that it was easier for me to keep track of
> in my head [0]. I wasn't intending it to be an end solution (even though
> I suppose it could be, at some point).
Sure, I understand that - but just the fact you did it this way
highlighted that it was actually one possible 'final' approach. Before I
saw your drafts I hadn't even really considered it.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 6 months
Draft Fedora 21 Test Plan
by Adam Williamson
Hi, folks! So, I quickly bashed out that draft F21 Test Plan I've been
threatening to write for the last month or so.
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan
So, what's the idea here?
Really, I'm just trying to come up with a starting point for all the
decisions we need to make and planning we need to do for Fedora 21
testing, especially release validation testing, especially as regards
Fedora.next. There's some mention of other stuff in there, but what I'm
really trying to think about is what we need to do to extend our test
processes to cover all the stuff that's coming as a part of .next.
I think the most interesting points are these:
* There are several practical implications from the test plan - just
Work We Need To Do. Most obviously, we need to draw up release criteria
and supporting test cases for the Fedora.next Products. We also will
need to adjust the
https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event SOP
to include those cases/matrices as they're created, and adjust the
https://fedoraproject.org/wiki/Release_criteria page to refer to/include
the Product-specific release criteria as *they're* created.
* Responsibilities! Particularly, in this *draft* Test Plan, I've
suggested that creating the Product-specific criteria and test cases
should be the responsibility of the relevant Working Groups, with
assistance from the QA team. They would also be jointly responsible,
along with the QA team, for conducting Product-specific testing, on the
general principle that the more Product-specific a bit of testing is
(and the more domain-specific expertise it needs), the more it's the
WG's responsibility and the less it's QA's responsibility. Note that
(again, as a suggestion in this draft) the QA team is still responsible
for Fedora 21 testing *overall* - i.e. it's the QA team's responsibility
to make sure the WGs do the stuff assigned to them in the plan. If that
makes sense. Discussion welcome!
* Feasibility. This is, of course, one I really want to nail down. It
will require, though, that the Product-specific release criteria and
test cases / matrices get written. Once we have those, we can try and
make a realistic judgement as to whether we as a project - the QA team
and the WGs - actually have the resources to complete the minimal
necessary level of testing within the scope of the F21 schedule. If we
don't think that's going to be the case, we can take that to FESCo, and
we can decide what to do about it that way. In the meantime I've
provided a *very* vague 'Required resources' section just to sort of
flag this up in a modest way.
I'd really, really appreciate feedback on this draft from all interested
parties - QA folks, WG folks, FESCo, anyone at all reading this who has
an opinion. Please, bikeshed away. It all helps.
I'll aim to kick off discussion between the WGs and QA about creating
Product-specific release criteria and test cases next week. Obviously
that's *somewhat* subject to feedback on this very draft, but I can't
really envisage a world in which we aren't going to need those two
things to happen, and whoever's job we ultimately decide it is, I don't
*think* that me just kicking off an attempt to draft them can be a bad
thing.
Thanks folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
9 years, 6 months
Fedora.next Product Branding
by Ryan Lerch
*This is sent with my Fedora Design Team hat on*
With the creation of 3 products for Fedora, the Fedora Design Team
anticipates manynewquestions aroundFedora'sbrand. As the main caretakers
of the Fedora brand, weare going to have to figure these things out
within the next few months. For example, the Design Team is starting to
think about how to answer these types of questions:
• Should each product have its own logo? or
• Can you add our product to the Fedora website? or
• Can you make our product its own website? (How should we represent
these products on the website? Should we allow products to have their
own separate websites?)
To start off the rebranding discussion, the Fedora Design Teamhas4 basic
questions for each of the 3 product-focused working groups to answer:
(1) What problem does your product solve, in one sentence?
(2) Who is the target audience for your product, in one sentence?
(3) List at least 5 products that successfully target the same target
audience you are after.
(4) List at least 5 products that try to solve the same problem.
We are reaching out to each group individually to ask that you discuss
these questions and come back to us with answers by Wednesday, December
4th2013.
cheers,
ryanlerch
9 years, 6 months
Your input is needed: Fedora workstation comps group
by Elad Alfassa
Hi all.
As you may know, we need to create a comps group for Fedora Workstation.
The comps file already has a comps group named
"developer-workstation-environment", but it contains things that we might
not want to put in the default Workstation environment.
So, should we "take over" that group and change it to fit our needs, or
create a new group? if we create a new group, what should we call it?
should the comps group be named fedora-workstation, workstation, or
something completely different?
All I need is your input regarding naming here, I'll do all the boring part
(adding it to comps and making sure we don't add any packages in the
kickstart file).
Thanks,
--
-Elad Alfassa.
9 years, 6 months
