Maintenance of Gtk.jl

[tknopp]

I am opening this issue to discuss the maintenance of Gtk.jl. It seems that currently Gtk.jl has more or less no defined maintainer. Is this correct? @vtjnash has driven this project (thanks so much!!!) but is currently more involved in core Julia infrastructure if I am correct.

I think if this is the case we could communicate this somewhere so that there is no direct expectation from newcomers that issues are directly solved. Maybe even "help for maintenance" message could be communicated.

I hope this is ok to discuss this in an open issue?!

Pinging some people that contributed to this package: @vtjnash @timholy @Matt5sean3 @bjarthur @lobingera

[bjarthur]

who currently has push access to Gtk.jl? is this info publicly available through the github UI?

[tknopp]

don't know, this seems a listing:

https://github.com/JuliaGraphics/Gtk.jl/network/members

but I do not know if this is publicity available (I am currently logged in).

[lobingera]

i think only the owners have push access and only the owners of JuliaGraphics. I'm listed as contributor, but i'm sure my PR was merged by someone else and also my work on Cairo was/is pulled by someone with write access.

[tknopp]

That seems correct but I opened this issue not so much about the current status of people with commit access (all of JuliaGraphics have) but more about discussing future development. I use Gtk.jl intensively (as a user) and am pretty satisfied with it. @timholy seems to be also a power user of this package.

[tknopp]

I think people that pushed things to master in the past were primary @vtjnash, @timholy, and I have also pushed some recent things.

[timholy]

I do have push access; I am likely to get back to this package in the next month or so once I get serious about the ImageView rewrite, but I certainly don't have time to act as a maintainer now. Perhaps we need to increase the pool of folks with commit access?

[tknopp]

Hey Tim, yes, this thread is also meant as some kind of "call for maintainer/contributor" message.

[timholy]

@tknopp, sounds like you may be volunteering for the job? :smile:

[tknopp]

:-), I feared that you ask that. Partially I can do that. But there are areas within this package that I don't fully understand. And time I can spend on this is limited.

[timholy]

It would be great to have you do whatever you can!

[timholy]

You've been doing a great job, @tknopp. I can't thank you enough.

Any thoughts on tagging a new release?

[tknopp]

In general yes, I could make a release. My projects are currently on the release branch and I remember that I had some issue when using the master branch. I will have a look at that and then do the release.

Keep in mind that we have deprecated the @ syntax. So this will require some porting (to get rid of the warnings).

[tknopp]

@timholy: Ref https://github.com/JuliaLang/METADATA.jl/pull/7950#pullrequestreview-21742368

I am currently not capable of addressing @tkelman requests, especially since I am not on 0.6 since I need a stable environment.

[timholy]

I'll see what I can do, I definitely want to support your efforts in keeping Gtk working.

[tknopp]

I think we have a conceptual problem when a package cannot decide to do a release just because some code inside "might not be so nice". All tests on 0.4 and 0.5 were passing and everything was fine. If someone wants to beautify the code, PR are always welcome. (Sorry if this sounds harsh, but I think that code reviews at that point are not really fair.)

[StefanKarpinski]

@tknopp: I 100% agree; we should not be blocking merging of package updates unless they break METADATA or contain malicious code. METADATA is not a tool to force code review onto everyone's packages. Helpful suggestions are fine, but requirements are not.

[tkelman]

it's overwriting methods from Compat which isn't a good idea - it's a few lines to fix, I'll submit a PR when I get a minute

[tknopp]

@StefanKarpinski: Thats why I wrote this (hopefully not to critical) comment. It would be great if you could clarify this with Tony.

[tknopp]

(and in general I appreciate those excellent reviews from @tkelman) It is the special situation of this project making it difficult.

[bjarthur]

i too appreciate all that @tkelman has done to make julia as good as it is!

[tkelman]

wasn't intending to block the release here, but being more specific about versioning and using things from Compat instead of locally duplicating / overwriting pieces of it would be worthwhile improvements relative to the few characters or lines' worth of changes involved

[lobingera]

@tkelman imho it's not so easy to follow, what's currently in Compat or what you need to version locally (e.g. new style inner constructor?)

[tknopp]

Maybe at the time when Jameson wrote this there was no Compat solution? Maybe you have an advice what we can do about the maintenance issue?

[tkelman]

Maybe at the time when Jameson wrote this there was no Compat solution

Possible. There is now though - specifically these lines https://github.com/JuliaGraphics/Gtk.jl/blob/6ec1902fd51b919e93fab49c33aab2a463741e87/test/gui.jl#L6-L11 can be replaced with a Compat minimum version of 0.9.5 and a using Compat.String

and here https://github.com/JuliaGraphics/Gtk.jl/blob/f0f797fca096406f690408ad5871167eb5500b39/src/GLib/glist.jl#L74 it would be more accurate to use isdefined

... I'll just ssh somewhere I happen to have a clone of this and open that PR