Proposal: Abandon v8 package
by Tom Callaway
Background:
I made the original v8 Fedora package many moons ago, when I was more
optimistic about the possibility of separating the useful components
inside of chromium. Since that point, it has become clear that while v8
is useful software, the following facts are also true:
1. The v8 upstream is entirely disinterested in the concept of
maintaining any sort of ABI/API consistency between releases.
2. The v8 that is used in chromium is not necessarily compatible with
the upstream v8, as they have a history of picking and choosing code
changes (and even applying chromium specific changes locally).
3. Virtually all consumers of v8 (including chromium) take a git
checkout (not a specific one, just whatever they decided to code to) and
use that revision, often creating a local fork of v8 from that revision,
as they are either unwilling or unable to track v8 upstream.
4. Since v8 has no concept of a "stable" release that I can see, they
simply do security fixes to the master branch, which, combined with the
code changing violently, makes it very difficult to backport security fixes.
This means that other than plv8 (which is currently unable to build
against the current v8 package in Fedora), I do not see any consumers of
the Fedora v8 package (chromium has long since abandoned any possibility
of using it). It does contain a "d8" binary, which is a javascript CLI
debugger, but it is not clear to me that this is widely used, or that
the benefit of its inclusion in Fedora outweighs the pain of maintaining
this package.
Thus, I propose that the v8 package be abandoned/orphaned/taken to the
farm upstate to run and play with the other dogs.
If you disagree, or are crazy enough to want to take it over, speak now.
~tom
P.S. I'll still maintain v8-314 as best I can, since there are actually
users of that. The irony of that really ancient version being considered
stable (and thus, used by other software) as a result of Fedora sticking
on that version of v8 for so many releases is not lost on me.
4 hours, 26 minutes
Orphan/retire gogoc
by J. Randall Owens
Hello,
gogoc is dead to the world upstream (the gogo6.com site is now a
nutritional supplement pusher!), and without gogo6's servers, gogoc is
fairly useless. It's still possible it could be used to TSP tunnel
through one's own servers to get IPv6, but as far as I know, there
aren't any more tunnel services out there that use it.
So, if someone would find it worthwhile to keep it around for their own
tunnelling needs, feel free to pick it up. Otherwise, I'll retire it in
two weeks.
--
J. Randall Owens | http://www.GhiaPet.net/
21 hours, 36 minutes
Fedora 30 System-Wide Change proposal: Mass Python 2 Package Removal
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
== Summary ==
(Sub-)packages only providing python2 importable modules without
additional functionality will be removed from Fedora unless some other
package(s) depends on them.
Python 2 will be deprecated in Fedora. Packagers can mark any other
Python 2 packages as deprecated as well.
== Owner ==
* Miro Hrončok (Churchyard)
* Petr Viktorin (Pviktori)
* Charalampos Stratakis (Cstratak)
* Zbigniew Jędrzejewski-Szmek (Zbyszek)
* Igor Gantenko (Ignatenkobrain)
* Neal Gompa (Ngompa)
== Detailed Description ==
Python 2 reaches End of Life on 2020-01-01. Its current maintainers
would like to orphan it before that date, and so far no one else has
stepped up to maintain Python 2 (with the full ecosystem) past 2020.
Since thousands of packages still depend on python2, we need a more
careful approach than normal orphaning.
Some of those packages are abandoned and/or the Python 2 version is
unnecessary. Others are useful and just need more time to port to
Python 3.
Hence we set up criteria for python2 packages that can remain in the
distribution and we remove everything else. This should allow us to
keep python2 for limited use, not break everything, but should also
send a strong message that it is no longer a first class citizen, and
filter packages we need to focus Python 3 porting efforts on.
(Sub-)packages that only provide a python2 importable module, and are
not required for other packages, will be removed.
Examples of situations where a (sub-)package does not provide only the
importable module:
* A package also provides an application, mostly likely in /usr/bin,
/usr/libexec...
** (Note that according to current guidelines, if the Python 3 version
of a package provides the same functionality, the Python 3 package
should provide the application.)
** (In certain situations the provided application is only useful to
boostrap or manage projects using the module. Such applications don't
count.)
* A package provides a plugin for another application, most likely
trough a setuptools entrypoint interface or some custom location on
disk.
Our process will be:
* File bugs for all packages that look like they only provide a Python
2 importable module. (This includes those needed by other packages we
plan to remove.)
* Leave at least a week for packagers to respond to the bugs.
* If the packager approves or there is no response for a week, we will
remove the package.
There are currently ~3000 source packages that generate python2 dependent RPMs.
Automation is being created to be able to provide us a rough list of
packages to remove.
=== Packages to remove ===
The list is at https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal/List
not to disturb the reading experience of this page.
Packagers can block some packages from removal by responding on
Bugzilla and providing reasons. If no general consensus is reached,
FESCo will decide (as Python SIG does not have a formal process for
such decisions).
We'll also actively try to remove unused or optional dependencies to
reduce the number of packages that need to be kept because other
packages depend on them.
As dependencies evolve over time, we will regularly repeat this proces
on rawhide from now on even on future releases.
Packagers are strongly encouraged to help port their applications to
Python 3. Removing old Python 2 only applications from Fedora is also
encouraged, especially if the upstream is dead. Python SIG is
available to help with porting.
Packaging guidelines will be updated to reflect that packaging for
Python 3 only is the default. Instructions for Python 2 and
dual-support will be moved to the Appendix.
Python 2 will be marked deprecated (see
https://fedoraproject.org/wiki/Packaging:Deprecating_Packages).
Any package that only provides a Python 2 importable module may be
marked as deprecated as well if the maintainer(s) want to.
== Benefit to Fedora ==
A giant pile of unneeded software running on a legacy interperter will
be removed from Fedora before the interpreter stops being supported
upstream.
While we would very much like to remove Python 2 entirely, this way we
are not breaking Fedora, and we can accomodate some exceptions.
== Scope ==
* Proposal owners:
** Provide a list of packages to remove
** Collect feedback from affected packagers
** Retire the python2 only packages
** Remove python2 subpackages from dual-python packages
* Other developers:
** Ask for packages to be removed from the list if needed (with reasons).
** Remove python2 subpackages from dual-python packages (not needed,
but helpful)
** Optionaly mark remainign python2 packages deprecated
* Policies and guidelines:
** Python packaging guidelines will be changed to only describe Python 3
** Python 2 and dual-support packaging will be moved to the appendix
** Only packages providing additional features different than
importable modules will be allowed to be added in Fedora (with
exception for dependenecies of other packages)
** Python 2 will be marked deprecated
https://fedoraproject.org/wiki/Packaging:Deprecating_Packages
* Trademark approval: not needed for this Change
== Upgrade/compatibility impact ==
Packages removed form Fedora repos will remain on the installed OS
until explicitly removed by the user or obsoleted by the packagers.
We'll only obsolete packages that would break upgrade (from
fedora-obsolete-packages).
== How To Test ==
Any program written in Python and any program that has Python plugins
could potentially be influenced by this change. Testing is different
for software that is still using Python 2 and for software that has
been switched to Python 3.
For any ''python2'' programs, make sure those programs are still
functional after the package removal. Since various packages that are
no longer built will not be removed from an existing system, just
upgrading and checking packages is not enough. Either a new
installation should be used, or after a branching point, any packages
which haven't been rebuilt for F30, so any packages with .fc29 or
lower release suffix should be removed from the system before testing.
For the ''python3'' programs, install all upgrades and check if the
software works.
Upgrade failures because of missing dependencies should be treated as
bugs. Any removed python2 subpackages which break upgrades need to be
added to Obsoletes in fedora-obsolete-packages.
== User Experience ==
There will be less Python 2 RPMs in Fedora repos. Users are encouraged
to switch to Python 3 and/or use Python 2 virtual environments and pip
for development.
== Dependencies ==
Ideally, all programs that use python2 would be switched to use
python3. Although we don't expect everything to be switched over, as
much as possible should be, so that the set of remaining python2
subpackages is as small as possible.
== Contingency Plan ==
* Contingency mechanism:
** If for some reason not everything is removed, nothing happens, it
can be removed later. If for some reason something breaks, some
packages can be unretired or restored.
** If someone steps up to maintain Python 2 (including the full
ecosystem of packages now in Fedora), they can decide to discontinue
removing packages, revert the Change, or come up with another plan.
(Note that in this case, current maintainers will most likely orphan
many fundamental python2 packages.)
== Documentation ==
This page is the main documentation.
Also see: https://pythonclock.org/
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
23 hours, 39 minutes
Non-responsive maintainer - Mosaab Alzoubi
by Vitaly Zaitsev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello!
According Non-responsive Maintainer Policy I'm asking the maintainer
to respond second time and resolve issues with package goldendict.
RHBZ tickets: https://bugzilla.redhat.com/show_bug.cgi?id=1667084 and
https://bugzilla.redhat.com/show_bug.cgi?id=1594569
Proposed PR with fix:
https://src.fedoraproject.org/rpms/goldendict/pull-request/1
- --
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEGFSlHDlYR1Xq8pxov5n8bdRauQoFAlxEPjsACgkQv5n8bdRa
uQpOLhAAlqcuEaRpsKkdO27Qi3XIq6BH2cmUzshQKqW98uYoP3QxepI2X1jaZ5sJ
IbbROzvu2ZyOQYlWAecV1LSNgO9zDuHSC2SKhOThGa5HguGZJRtrCyILLU0w3IeD
cCOpRaTy1Zg1MfaqsEqb9bZe/Fz7dzOpuVTE2HQ/YDDlwe6iA1iqAIpD1CBK2yNT
qcghrpQQtZweFb72fbPbSgnE8k4GBvzYaTtbxxP1ZaXoiZqKTgwUFrFVecT9+CuR
/5ffcFh38o4mb1pP8c0VjJCioSv9qf7achY0IlaZhQsC7XB+VkUH11hdoKlUC1az
9Ws8g+DFHB0Z8roUBrSQWM2hX8m+jPQqTAjE5QtGgdveggdUvII7dMIIbSLjr3hw
/SrfKin6ALNvanumma02eZw93tv+YXR+uvT1HzMC/iaFwoclbFMsbUYn5gbr4viR
ukJLJgN/L1w/NNI63BU3JYsuH9LC9GOY/bmyeK4w1L7zkIdL3atCyUv2QrJ+JI4e
IXvmO6eIwJOENLcT9D8YUA6GSftE4nUeiWU7QT02/51vm6BLJSu53KiW8BMtD0Ij
W5+oltdb6X0PRm+mzDfkgweh1kn26bHCMTM/SZUVtKxPHVHW6VYKombXDtJgwbDt
BLTdGcGKBhCpcdr41EWt8BzzzcnQMnJIXNQwCThccYtXyAJn9zA=
=fkRA
-----END PGP SIGNATURE-----
3 days, 17 hours
MBI (Playground 2.0)
by Igor Gnatenko
MayBe I …(can do something useful)?
Hello,
We've been discussing some (hopefully) nice idea with Mikolaj, Neal and
Jakub how we could improve packager (and user) experience and we have some
proposal which will be described below.
We would like to ask you to read it, understand it and ask us any questions
you have. From the Fedora Infrastructure we would like to ask for some
machines to implement this idea (you can find some more information in
"Implementation details" part).
I would like to apologize for HTML email, but it is much easier to have it
that way to have better visibility and reading easiness.
Feel free to reply to this email or comment in google doc (there is a link
on the bottom).
Proposal Owners
-
Mikolaj Izdebski (mizdebsk) <mizdebsk(a)redhat.com> - Java SIG, Fedora
infrastructure
-
Igor Gnatenko (ignatenkobrain) <ignatenkobrain(a)fedoraproject.org> - Rust
SIG, Golang SIG, Neuro SIG, RPM and libsolv contributor
-
Neal Gompa (ngompa) <ngompa13(a)gmail.com> - Rust SIG, Golang SIG, RPM
contributor
-
Jakub Čajka (jcajka) <jcajka(a)fedoraproject.org> - Golang SIG, Container
SIG
This proposal aligns with the objective of improving the packager experience
<https://fedoraproject.org/wiki/Objectives/Packager_Experience> by
developing a platform whereby the proposal owners and others can experiment
with improvements that can be funneled back into the official production
infrastructure.
ProblemsProblem №1: Build-only packages
Some ecosystems have many build-only packages (packages which are used to
build other packages, without having them installed on end-user systems).
Those ecosystems include Java, Rust and Go.
It is extremely hard to keep up maintaining them due to lack of
time/people. Upstreams are usually changing quickly (sometimes when you
update just one such package, you’d need to update tens of the
dependencies). Few facts about such packages:
-
They are almost always outdated in released versions of distribution;
-
They are often FTBFS (e.g. because there was compiler update but not
package update, broken deps, broken APIs due to deps rebases, …).
In Rust ecosystem, we abuse Rawhide to build and store such packages there
and then generate end-user application (e.g. ripgrep) which uses some of
those packages and produces binary for all supported releases. Those
applications have high quality and are supported.
Rawhide gating makes this much more complicated because builds appear in
buildroot slower, updating group of packages would need side tags and it’s
just painful to work with.
https://pagure.io/fesco/issue/2068
And, after all, those packages shouldn’t be shipped to users.
Problem №2: Testing of new rpm/koji/mock features/configuration
When developing new features in RPM (e.g. rich dependencies) or testing
different Koji configuration (e.g. removing gcc/gcc-c++ from the
buildroot), it is required to make custom configuration and try building
things.
Problem №3: Developing modules
Modules are built in MBS as a single unit. It is hard to develop big
modules by progressively improving individual packages or small package
groups. Scratch builds for modules are not implemented. Local builds work
differently from official module builds, they don’t scale and don’t allow
groups of people to work collaboratively. All these problems can be solved
by first developing a flat repository of packages in a shared environment
and then generating modulemd from such package set.
Problem №4: Testing things before push
Primary Fedora Koji and dist-git are not suited for packaging
experimentation. Packagers are expected to experiment on their own systems
and push changes of successful experiments only. But this approach doesn’t
scale with number of maintained packages. Often you can find commits like
“d’oh, forgot to upload sources” or “let’s try with this settings”. People
need to build things somewhere quickly, do development and testing. And
only after that, they should push commit(s) to Fedora.
Solution
-
Separate Koji + Koschei deployed in Fedora infrastructure cloud;
-
Builders are optimized for the best performance (see below
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
);
-
People can have their own targets where they can break things as they
wish without affecting others;
-
Package changes are eventually contributed to Fedora proper by merging
changes to Fedora dist-git and rebuilding packages in official Fedora Koji;
-
All improvements can eventually be contributed back to official Fedora
infra.
Ideas
All ideas which you’ll find below are just an ideas and do not have to be
implemented.
Idea №1: Automated legal review
openSUSE released their review app called Cavil
<https://github.com/openSUSE/cavil> which we could try running in automated
way.
Idea №2: Automated package review
Currently review process is burden and we could run automated legal review,
create a repo, run set of checks and notify person. Somewhat similar to
fresque <https://github.com/fedora-infra/fresque>. In future might be
integrated with approval process and auto-imported into Fedora.
Idea №3: Building packages for multiple distributions
In Rust ecosystem, we managed to get have same packaging guidelines in
openSUSE, Mageia and Fedora. We could automatically build some packages on
multiple distributions and be kinda upstream.
Idea №4: Building custom images with user content
Deploy (or build) a tool(s) to enable user-built install, appliance and
container images with their content (modulo restrictions similar to COPR)
on top of Fedora.
Implementation details
-
Koji and Koschei deployed in fedorainfracloud.org
-
A few builders constantly running, with a possibility to add more
builders as needed and as available cloud resources allow
-
Deployed and maintained by proposal owners - not supported by Fedora
infrastructure
-
Other contributors can have access granted by proposal owners (for the
time being only users in “packagers” group will be eligible to get access)
-
Possibility to have some builders running outsides of Fedora
infrastructure - contributed by proposal owners
-
Koji builds can be done from SCM (src.fp.o, pagure.io, github, …) or
from SRPM upload
FAQWhy not COPR?
-
COPR has been starved of resources for years, which has impaired its
ability to provide reliable service at scale. Fedora Infrastructure refuses
to consider supporting it officially and Fedora Release Engineering seems
to have some undefined issues with COPR.
-
It is not official build system of Fedora which is not helping with Problem
№2: Testing of new rpm/koji/mock features/configuration
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
.
-
COPR is not extensible enough, more specifically:
-
No query API (e.g. it is not possible to find out from which SCM
commit the package has been built)
-
Builds always have access to all previous builds in a repository
(i.e. not possible to control when/how repo is created)
-
GC doesn’t exist
-
No scratch builds
Why not staging Koji?
-
Staging Koji is meant for testing Koji itself and not for package
development.
-
Staging Koji is often in broken state where it is not possible to build
anything.
-
No one can touch staging Koji, so it’s pointless for offering a useful
service.
How can you make Koji builds faster?
-
By tuning Koji for performance, not correctness and reliability.
-
By building only on a single, fast architecture.
-
By extensive caching. Files like RPM packages, repodata and files in
lookaside cache don’t change after they are initially stored, so builders
can cache them aggressively.
-
By keeping build repositories small. Some package sets don’t need to be
built against full Fedora, but can use a minimal subset of Fedora. Such
repositories can be generated by Koji in seconds, not minutes.
Why not the Open Build Service (OBS)?
-
OBS is not yet packaged for Fedora officially. The upstream code lacks
adaptations necessary to deploy and run on Fedora and in Fedora
Infrastructure.
-
OBS is not official build system of Fedora, which does not help with Problem
№2: Testing of new rpm/koji/mock features/configuration
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
.
What does MBI stand for?
-
M for middlestream, module, mizdebsk, …
-
B for build, bootstrap, …
-
I for infrastructure, initiative, ignatenkobrain, …
-
MBI might be pronounced as “maybe I …(can make something cool)?”
-
MBI is also initials of mizdebsk (Mikolaj Bozydar Izdebski)
-
MBI is also IBM spelled backwards :)
Is it somehow related to Fedora Playground
<https://fedoraproject.org/wiki/Playground>?
Yes, it is. Although it is more developer-focused. Users could enrol for
some specific things like experimental Java/Rust packages.
MBI (Playground 2.0)
<https://docs.google.com/document/d/1DtNTCa-gXc0ILDDHPyAcAca2GGGlENavfgPwG...>
3 days, 18 hours
F30 Self-Contained Change proposal: Retire YUM 3
by Ben Cotton
(Note this change was previously submitted for Fedora 29:
https://pagure.io/fesco/issue/2064)
https://fedoraproject.org/wiki/Changes/Retire_YUM_3
== Summary ==
Remove yum (v3) and all related packages from Fedora.
== Owner ==
* Name: [[User:mdomonko|Michal Domonkos]]
* Email: mdomonko(a)redhat.com
== Detailed Description ==
Remove packages from the distribution:
* createrepo
* yum
* yum-langpacks
* yum-utils
* yum-metadata-parser
* yum-updatesd
* python-urlgrabber
All these packages should no longer be used and all software using
them should be migrated to DNF.
Compatibility:
* Important packages such as yum, createrepo or yum-utils will be
provided/obsoleted by relevant packages from the dnf stack
* Important executables such yum, repoquery, createrepo, etc. will be
provided either as new executables or via symlinks
== Benefit to Fedora ==
Drop an old package manager that has no active upstream development.
Move existing users to DNF which that has active development.
Secondary benefit is reducing number of packages in Fedora that still
depend on Python 2.
== Scope ==
* Proposal owners: Remove packages from the distribution: createrepo,
yum, yum-langpacks, yum-utils, yum-metadata-parser, yum-updatesd,
python-urlgrabber
* Other developers: Either remove packages from the distribution or
switch them to DNF
* Release engineering: [https://pagure.io/releng/issue/7588 #7588]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Any tool based on YUM 3 Python API will stop working. This applies on
any 3rd party software which won't be changed in Fedora as part of
this change.
CLI compatibility will be provided by DNF.
== How To Test ==
Repoclosure passes after dropping the packages.
== User Experience ==
There shouldn't be any impact on YUM users because the functionality
is provided by DNF already.
Users of tools listed in the Dependencies section shouldn't see any
difference if the migration to DNF is done properly.
== Dependencies ==
The list of source packages (SRPMs) that still depend on some of the
yum-related packages to be removed:
(see wiki page)
== Contingency Plan ==
* Contingency mechanism: Do not remove the packages in the current release.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
N/A
== Release Notes ==
Inform end-users about removing the YUM 3 stack and definitive migration to DNF.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
4 days, 16 hours
F30 Self-Contained Change proposal: SWID tag enablement
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SWID_Tag_Enablement
== Summary ==
Provide tools to allow users and developers to create Software
Identity (SWID) tags for Fedora installs and repositories.
== Owner ==
* Name: [[User:adelton|Jan Pazdziora]]
* Email: jpazdziora(a)redhat.com
== Detailed Description ==
SWID (ISO/IEC 19770:2-2015) is a portable standard for identifying
software installed on a system. We already have SWID tags in
fedora-release to identify the overall release+edition of Fedora. We
will add tools to allow users to
* list installed tags
* create and install individual tags identifying RPMs
* add pre-built tags to repositories
* automatically update local tags as packages are installed, updated and removed
This will involve standalone tools to query and build SWID tags and to
add prebuilt tags to dnf repositories, and plugins for dnf/libdnf to
build and download tags.
== Benefit to Fedora ==
Fedora will be usable to users and developers interested in the SWID
functionality being added to relevant other tools, such as
OpenSCAP-1.3.
== Scope ==
* Proposal owners:
** Add python SWID tools (swidq, rpm2swidtag)
** add SWID metadata awareness to createrepo (but this will not be
used in Fedora, only enabled for user use), agreeing metadata format
with dnf team
** add dnf and libdnf plugins (no core dnf/libdnf changes expected)
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No change unless users choose to enable SWID tags.
If requested, SWID tags will be either built automatically on demand
for installed RPMs, or downloaded from a repository that the user has
added SWID tags to, at the user’s choice. swidq will allow the user
to see all installed tags and their relationships.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No
* Blocks product? No
== Release Notes ==
Inform users of new capabilities and how they can be used with the
existing tags in fedora-release-*
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
4 days, 20 hours
Blocking criteria proposal for F30+: Printing
by Stephen Gallagher
There was a bug[1] filed recently that indicated that printing was
broken on certain printers. As a result of that discussion, it became
apparent that there was no criteria for printing to work at all, which
seems like an oversight.
I discussed this briefly with Matthias Clasen this morning and he
agreed that this should be treated as blocking for Workstation.
I'd like to propose that we add the following criteria to Beta for Fedora 30+:
* Printing must work on at least one printer available to Fedora QA.
"Work" is defined as the output from the device matching a preview
shown on the GNOME print preview display. (Note that differences in
color reproduction are not considered "non-working".)
and this to Final for Fedora 30+:
* Printing must work on at least one printer using each of the
following drivers:
(I don't know which ones to specify here, but we ought to try to
figure out a cross-section that covers a large swath of our expected
user base).
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1628255
5 days, 16 hours
F30 Self-Contained Change proposal: Ibus-typing-booster default for
Indian languages
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ibus_typing_booster_default_for_in...
== Summary ==
Make ibus-typing-booster the default input method for Indian languages.
== Owner ==
* Name: [[User:Mfabian|Mike Fabian]]
* Email: <mfabian(a)redhat.com>
== Detailed Description ==
Currently, ibus-m17n is the default input method for Indian languages
in Fedora. ibus-typing-booster uses the same libm17n used by
ibus-m17n to support input for Indian languages and thus it can do
everything ibus-m17n can do. But on top of that, ibus-typing-booster
supports predictive input by remembering user input and by using words
from dictionaries. Therefore, ibus-typing-booster is a more useful input method
for these languages.
== Benefit to Fedora ==
A better input experience for users of Indian languages.
== Scope ==
* Proposal owners:
The langtable package has data about default input methods. Change this data.
But the data in langtable is currently apparently not used by
gnome-initial setup.
The list of default input methods used by gnome-initial-setup us stored in
<pre>
libgnome-desktop/default-input-sources.h
</pre>
Currently there are the following default input methods for the Indian locales:
<pre>
static DefaultInputSource default_input_sources[] =
{
...
{ "as_IN", "ibus", "m17n:as:phonetic" },
...
{ "bn_IN", "ibus", "m17n:bn:inscript" },
...
{ "gu_IN", "ibus", "m17n:gu:inscript" },
...
{ "hi_IN", "ibus", "m17n:hi:inscript" },
...
{ "kn_IN", "ibus", "m17n:kn:kgp" },
...
{ "mai_IN", "ibus", "m17n:mai:inscript" },
...
{ "ml_IN", "ibus", "m17n:ml:inscript" },
...
{ "mr_IN", "ibus", "m17n:mr:inscript" },
...
{ "or_IN", "ibus", "m17n:or:inscript" },
...
{ "pa_IN", "ibus", "m17n:pa:inscript" },
...
{ "sd_IN", "ibus", "m17n:sd:inscript" },
...
{ "ta_IN", "ibus", "m17n:ta:tamil99" },
...
{ "te_IN", "ibus", "m17n:te:inscript" },
...
{ "ur_IN", "ibus", "m17n:ur:phonetic" },
...
</pre>
Here, "m17n:as:phonetic" would need to be replaced with "typing-booster".
And similar for the other Indian languages.
ibus-typing-booster selects the default input method to use
from the locale when it is first started. For the above Indian
locales ibus-typing-booster >= 2.4.2 has the same default
m17n input methods as libgnome-desktop/default-input-sources.h,
except that it always uses inscript2 instead of inscript by default.
* Other developers: N/A (not a System Wide Change)
* Policies and guidelines: N/A (not a System Wide Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Nothing should happen when upgrading from a previous version of Fedora.
If a user used ibus-m17n before the upgrade, he will still use it
after the upgrade.
This change proposal only changes the default input method for an
Indian language
for new installs or new user accounts.
== How To Test ==
Do a new installation of Fedora 30 in an Indian language. Log into Gnome.
See what input method is suggested by default by gnome-initial-setup.
== User Experience ==
Easier input of Indian language because of predictive input.
== Dependencies ==
gnome-initial-setup
== Contingency Plan ==
* Contingency mechanism: Leave the default input methods as they are
now and move the change to Fedora 31
* Contingency deadline: Fedora 30 Beta release
* Blocks release? No.
* Blocks product? No.
--
Ben Cotton
Fedora Program Manager
TZ=America/Indiana/Indianapolis
5 days, 22 hours
