Gtk-Perl Module Deprecation Notice [1/2]: Gtk2::* and Gnome2::* Modules (Important, Long, Please Read)



Hi!

What is happening?
===============
The Gtk-Perl team is formally announcing their intention to deprecate
a specific list of Perl Gnome2::* and Gtk2::* modules.

The Gtk-Perl developers have privately in the past discussed
deprecating Gtk-Perl modules in the Gnome2::* and Gtk2::* namespaces
that are no longer being maintained upstream.  The development team is
now publicly announcing our intention to deprecate these modules, and
moving forward with the work required to deprecate them.

Once deprecation releases have been made for these modules, they will
be pushed to CPAN and indexed in their deprecated form so that CPAN
search engines should show these modules as “Deprecated” when you view
any of these modules in search results.

After we have made the final “deprecation release” for these modules,
we will be asking the GNOME SysAdmin team to archive these modules so
that it will no longer be possible to submit new issues or pull
requests for these modules, or push new changes to their Git repos.

Developers and users of these deprecated modules are more than welcome
to continue to ask about them on the Gtk-Perl mailing list, but our
priorities going forward will be maintaining Gtk-Perl modules that are
supported and maintained upstream; modules in the deprecation list
(below) are neither.


Which Gtk-Perl modules will be deprecated? (Short form list)
============================================
NOTE: the next email will contain the same list of modules that will
be deprecated will be listed, but with a lot more information (links
to each module on GitLab and links to upstream repos, upstream release
info, Perl module migration information, and deprecation merge
requests where they have been completed)

* Champlain (Already archived)
* Clutter (Already archived)
* Gnome2
* Gnome2::Canvas
* Gnome2::Dia
* Gnome2::GConf
* Gnome2::PanelApplet
* Gnome2::Print
* Gnome2::Rsvg
* Gnome2::VFS
* Gnome2::Vte
* Gnome2::Wnck
* GStreamer
* GStreamer::GConf
* GStreamer::Interfaces
* Gtk2::GLExt
* Gtk2::GladeXML
* Gtk2::Html2
* Gtk2::Recent
* Gtk2::MozEmbed
* Gtk2::SourceView
* Gtk2::SourceView2
* Gtk2::Spell
* Gtk2::TrayIcon
* Gtk2::TrayManager

For the _Gtk2_ Perl module, we do not have plans at this time to
deprecate it, but it will happen at some point (maybe within the next
year or so), so please plan accordingly.


What is the timeline of deprecation of Gnome2::* and Gtk2::* modules?
====================================================
This announcement is being sent out on October 1st, 2020.

We plan on making a “final” release (version number bumps to existing
Git repos which will contain “deprecation commits”) during the
December 2020 release window.

So far, we have prepared deprecation patches for most of the Gnome2::*
modules, these patches will be attached to the next email.  You can
also view the deprecation changes in the ‘deprecation’ branch in GNOME
GitLab for each module (module GitLab links are provided in the larger
list of modules to be deprecated at the end of this email).

As deprecation notices and outstanding patches are added to a given
module, these changes will be distributed via patches sent to the
Gtk-Perl mailing list, and also will be pushed to a ‘deprecation’
branch in the GitLab repo for that module.  We are working in a
roughly alphabetical order, so if you don’t see a patch for one of the
modules in the deprecated module list, you will in the coming weeks.

Again, for the _Gtk2_ Perl module, we do not have plans at this time
to deprecate it, but it will happen at some point (maybe within the
next year or so), so please plan accordingly.


Why is the Gtk-Perl Team deprecating Gnome2::* and Gtk2::* modules?
====================================================
Basically, it’s time to do it.  it has probably been “time” for a long time now.

Upstream developers (The Gnome Project) are no longer maintaining the
C library code related to GTK+2 and Gnome2 , and they haven’t been for
a long time (over 10 years in some cases).  Even if we found new bugs
or hit existing bugs in the upstream C libraries from their use in
Perl bindings, we most likely would not be able to get them fixed
upstream, since in most cases the upstream C libraries have been
archived (made read-only).

At this point, maintaining the existing Gtk2::* and Gnome2::* modules
mostly means fixing typos/grammar errors in the Perldoc, which takes
away resources from Gtk-Perl modules that *ARE* supported upstream
(for example, Glib/Gtk3/Glib::IO/Glib::Object::Introspection, etc.).

The GNOME Project will be releasing the next major version of the
GNOME libraries, “Gnome 40”, starting in March of 2021 [1]; this is
probably as good of a time as any to start the process of deprecating
existing Gtk2::* and Gnome2::* modules.


What if I don’t want <insert module name here> deprecated?
============================================
Since all of the deprecated modules are licensed under the LGPL v2, if
you wish, you may fork any of these modules in order to update and
maintain them going forward, however:

1. You will need to use a different name for your forked module on
CPAN, both because the Gtk-Perl project already has “ownership” of
these names on CPAN, and to make it clear that the Gtk-Perl team is
has *NO* responsibility for managing your forked module going forward
2. The Gtk-Perl team requests that you use your own resources (mailing
list, Git repos, bug trackers, etc.) to maintain your fork going
forward.


How can I keep track of which modules from the list have been deprecated?
=======================================================
We will be creating a “deprecation" branch in GNOME GitLab for each
module that will be deprecated, and then generating a "merge request"
with the changes required for module deprecation.  In that "merge
request", you can leave comments concerning the deprecation changes
for that module.

Why GitLab over RT tickets?   In one word, workflow; the deprecation
commits are held in a separate Git branch which makes the changes easy
to view in a web browser, and it's easy to make new commits to the
"deprecation" branch as needed based on feedback.


What if I have questions not covered here?
===============================
Please reply to this thread on the mailing list, or start a new email
thread on the Gtk-Perl email list.  Contacting the Gtk-Perl developers
directly via email with deprecation questions will result in a polite
request to move your question to the Gtk-Perl mailing list for further
(public) discussion.

Thanks for reading down this far!

Enjoy,

Brian


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]