Sorry this is a bit late but I had a few thoughts on what I have read in
Is workstation being aimed at new users or developers? And is the goal the
same for Gnome? If Gnome is aiming to cater to new users, then is it the
right primary DE for fedora? There seems to be a misalignment here.
I have spent most of the last 15 years working for one of the largest
computing colleges in the country. I can guarantee you that the vast
majority of our students learned to program in a terminal. It may not be
the preferred environment once they become professionals, but it shouldn't
intimidate them by any means. So if workstation is aimed at developers,
why are we worried about them encountering the terminal when using the OS?
Instead of hiding the CLI from new users, why not simply give them the
option of avoiding it? Instead of only showing gui apps, why not show all
with packages being tagged as either cli or gui. Then the user can decide
whether or not they want to install the package.
A package manager that can show ALL packages should be installed by default
in Gnome on Fedora. This isn't a distro that only ships a single DE.
On Wed, Nov 26, 2014 at 03:13:59PM +1000, Noriko Mizumoto wrote:
> Hi Fedora developers
> Having the consensus with FESCo , we FLP (aka translation team) have
> started the process of migration to new fedora.zanata.org instance from
> Transifex . First all translators started to migrate in November 2014
> (still going on).
> Now it is time to migrate all projects. This is expected to start after
> F21 GA. For the owners of the projects, there are two options to choose
> for the migration below.
> One: Delegate us to implement migration
> If this option is chosen, partially automated migration will be
> performed by Zanata team. Once it completes, then the owner visits new
> place and confirms everything intact (Some manual adjustment may be
> Two: Manual migration
> If this option is chosen, the owner performs all the migration process
> by his/her self. Please advise the estimated completion date.
> I have attached the list of all the target projects below. If any
> package is missing and it should be added into the list, please let me know.
> Could all Fedora developers please go through the list and advise which
> option is preferred for your project, so that we will be able to
> schedule them? For option One, we need to know current
> maintainer's/owner's contact.
> Package Name Group
> Anaconda main
> Blivet main
> Firstboot main
> initial-setup main
> pykickstart main
> python-meh main
> system-config-kickstart main
These are all installer team projects. What are we required to do with the
move to Zanata?
David Cantrell <dcantrell(a)redhat.com>
Manager, Installer Engineering Team
Red Hat, Inc. | Westford, MA | EST5EDT
# First F22 Blocker Review meeting
# Date: 2015-01-07
# Time: 16:00 UTC
# Location: #fedora-blocker-review on irc.freenode.net
While it's not the usual time to start blocker reviews, after much
deliberation at today's QA meeting, it was decided to start the blocker
review process earlier than usual. With that being decided, we're going
to get started this week!
The other change to the blocker review process: we're going to start
going through all the remaining milestones for a release. The thought is
that this will keep bugs from piling up, which gives developers and QA
more time to code and test (respectively). Hopefully this will lessen
the number of really long blocker review meetings.
If we happen to have a bunch of blockers that we can't get through in
one meeting, we'll try to schedule another during the week to get
through them. Currently we have 3 Alpha, 2 Beta and 3 Final proposed
Blockers and 4 proposed Alpha Freeze Exceptions.
If you want to take a look at the proposed or accepted blockers, the full
list can be found here: https://qa.fedoraproject.org/blockerbugs/
Make sure to click through the milestones to see how many we have before
We'll be evaluating these bugs to see if they violate any of the
Release Criteria and warrant the blocking of a release if they're not
fixed. Information on the release criteria for F22 can be found on the
For more information about the Blocker and Freeze exception process,
check out these links:
And for those of you who are curious how a Blocker Review Meeting
works - or how it's supposed to go and you want to run one - check out the SOP
on the wiki:
See you Wednesday!
test-announce mailing list
RichiH, author of vcsh (one of my packages) and Debian contributor
asked my whether we could upstream Fedora packaging (more precisely
any packaging metadata). I simply showed him where the package's git
repo and we agreed I would notify him when I commit stuff. Btw, is there
a simple way to subscribe without a FAS account?
It occurred to me that we are encouraged to upstream Gnome Software
app metadata, but I don't use Gnome. Are CLI tools welcome in Gnome
I guess I could contribute a French translation, and we could take
screenshots of Gnome's terminal. Would it be relevant?
The main package used to have license:
(QPL with exceptions) and (LGPLv2+ with exceptions)
In the new 20141215 version just built for Rawhide, the LGPLv2+ with
exceptions part is now confined to the -devel subpackage, so the main
package license has changed to just:
QPL with exceptions
which isn't valid, because you can't tack "with exceptions" onto the
end of QPL. Off to talk to the licensing folks about that....
= Proposed System Wide Change: GHC 7.8 =
Change owner(s): Jens Petersen <petersen(a)redhat.com>, Ricky Elrod
<relrod(a)redhat.com>, Haskell_SIG <haskell(a)lists.fedoraproject.org>
Update the GHC Haskell compiler to the major new 7.8 release, and
update/rebuild all Haskell packages against it.
== Detailed Description ==
* The involves updating ghc from 7.6.3 to 7.8.1 (or later), and
rebuilding/updating all Fedora Haskell packages.
* The initial work will be done locally offline to make sure that it is possible
to build all our packages with ghc-7.8 and the latest updated libraries.
* This may also include building with the llvm backend to ensure that building
on ARM will work.
* Once that is completed, building will be done into Koji for rawhide and
== Scope ==
* Proposal owners:
** locally test rebuilding and updating of all packages
** update macros to subpackage static libraries
** push changes to Koji
* Other developers:
** If you own a package which contains some Haskell code built with ghc you
will need to rebuild you package to make sure it still rebuilds with ghc-7.8.
Feel free to contact the Haskell SIG if we need assistance with fixing any
build breakage, and we will try to help out.
* Release engineering: not required
* Policies and guidelines:
** There may be some lesser changes to the Haskell Packaging Guidelines needed
- they could be done after this Change.
devel-announce mailing list