Bug 243470 - devel/mono-addins: deprecate and expire in 90 days
Summary: devel/mono-addins: deprecate and expire in 90 days
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-mono mailing list
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2020-01-20 17:36 UTC by Phillip R. Jaenke
Modified: 2020-01-22 14:30 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (mono)


Attachments
deprecate and expire (411 bytes, patch)
2020-01-20 17:36 UTC, Phillip R. Jaenke
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip R. Jaenke 2020-01-20 17:36:37 UTC
Created attachment 210897 [details]
deprecate and expire

After checking with upstream, it has been determined that mono-addins has been deprecated upstream and will no longer be maintained going forward.

I set the expiry to 90 days as there is one maintained port which added a new dependency on this on December 19, graphics/pinta. (Will be opening a separate bug for graphics/pinta.)

This is part of the mono cleanup effort to bring in Mono 6.8+.
Comment 1 OlivierW 2020-01-21 17:56:36 UTC
I have been told mono-addins isn't deprecated, there is just no active feature development ATM.

Best Regards,
Olivier
Comment 2 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-22 06:16:08 UTC
Excerpt from bug 243471 comment 6 to clarify comment 1 here:

mono-addins is receiving commits @ GitHub (Latest Nov 22, 2019): https://github.com/mono/mono-addins/commits

Conversation [1] with Marius Ungureanu (therzok, committer and Senior Software Engineer @microsoft) on Twitter:

"Hey, mono-addins is not deprecated, it's still largely used in MonoDevelop. There's no active feature development on it right now, but that's a different story"

Can you describe the nature if any, of mono-addins preventing or precluding lang/mono update?
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2020-01-22 06:16:44 UTC
(In reply to Kubilay Kocak from comment #2)

Forgot to include the twitter conversation reference [1]: https://twitter.com/Therzok/status/1219439705042956288
Comment 4 Phillip R. Jaenke 2020-01-22 14:30:30 UTC
Interesting! I talked with Alexander Koeplinger (runtime team) on Gitter about it, so it probably is just a miscommunication between teams there. Mono internally is a VERY large project.

However, a quick swing through shows that the version in ports does NOT compile with newer Mono. Which isn't entirely unexpected, as it's a 4 year old release tarball.

/usr/local/bin/mcs -out:WidgetViewer.exe -r:../../glib/glib-sharp.dll -r:../../pango/pango-sharp.dll -r:../../atk/atk-sharp.dll -r:../../gdk/gdk-sharp.dll -r:../../gtk/gtk-sharp.dll ./TestCheckButton.cs ./TestColorSelection.cs ./TestRadioButton.cs ./TestRange.cs ./TestStatusbar.cs ./TestDialog.cs ./TestFlipping.cs ./TestSizeGroup.cs ./TestCombo.cs ./TestComboBox.cs ./WidgetViewer.cs
./TestCombo.cs(17,14): warning CS0612: `Gtk.Combo' is obsolete
./TestRange.cs(35,6): error CS0104: `Range' is an ambiguous reference between `System.Range' and `Gtk.Range'
/usr/local/lib/mono/4.5/mscorlib.dll (Location of the symbol related to previous error)
./TestRange.cs(35,13): error CS0030: Cannot convert type `Gtk.HScale' to `System.Range'
./TestRange.cs(42,6): error CS0104: `Range' is an ambiguous reference between `System.Range' and `Gtk.Range'
/usr/local/lib/mono/4.5/mscorlib.dll (Location of the symbol related to previous error)
./TestRange.cs(42,13): error CS0030: Cannot convert type `Gtk.HScrollbar' to `System.Range'
./TestRange.cs(62,6): error CS0104: `Range' is an ambiguous reference between `System.Range' and `Gtk.Range'
/usr/local/lib/mono/4.5/mscorlib.dll (Location of the symbol related to previous error)
./TestRange.cs(62,13): error CS0030: Cannot convert type `Gtk.VScale' to `System.Range'
./TestCombo.cs(31,20): warning CS0612: `Gtk.Combo' is obsolete
Compilation failed: 6 error(s), 2 warnings

So there's definitely some major cleanup and overhaul needed here. Item one is probably switching to actually fetching from a GH commit instead of a 4 year old pseudo-release. There's probably over a thousand bug fix commits between the release tarball and current commit. Or having upstream do a new release tarball; either way works.
I've got no problem switching that out and updating the port correspondingly there. (Just probably won't be able to get to it today.)

However: issue two, this depends on gtk-sharp20, which is another orphan in need of serious updating. (Or optionally gtk-sharp30, same deal.) I don't know anywhere near enough about the Gnome infrastructure to know what the correct answer here is or how the gtk-sharp pieces would impact other gtk pieces at this point. Is there anyone from gnome@ who would be able to lend me a hand here?