Hi,
Well, for the immediate future, I'd be happy with tagging 2.99.4.
There's the super annoying warning "Source ID was not found when
attempting to remove it" in 2.99.3 that's been fixed in master.
I don't think there's any good solution to get things forward if no one
who can actively maintain gtk-sharp steps up.
One option that comes to my mind is some kind of ack-system, so that
people would report to pull-requests if the PR works for them. If
there's a sufficient amount of acks, then maybe it could be merged even
if it hasn't been thoroughly reviewed. Obviously it's better if people
would also do a review, but speaking of myself, I can test gtk-sharp,
but I don't know enough of glib/gtk internals to be able to properly
review most of the patches.
As for the strategy question, I have only one comment: as it's difficult
to find maintainer-time for gtk-sharp, the strategy should be that of
minimal work for the maintainer.
I might even say that that aspect is the most important one. If it's
easiest for the maintainer to break the gtk-sharp API in every 3.x
release, so be it. I think it's much much better to get API breaking 3.x
releases every now and then, than being stuck at 3.0 (or 2.99.x) for ever.
I don't care much for stable GTK# API, but I very much care about using
the gtk features that's been out there for years. If someone doesn't
want to handle the GTK# API changing, they can just use the old library
version.
Having GTK# that is stuck in years old GTK version, getting no new
features, is basically a dead project. It doesn't matter if the API is
super stable if no one uses the library.
And just to make it clear, I'm not advocating such approach as a good
one. Obviously a stable API with well tested functionality should be the
target. But we have to make do with what we have.
Tomi
Post by Bertrand LorentzHello,
Thanks for bringing up this topic.
I did the previous 2.99.x, but only because nobody else was doing it,
and someone was foolish enough to give me commit access on the GitHub repo.
I've always considered myself as the "de facto acting maintainer" of the
master branch, but not much else.
In the last 5 months, I haven't been able to do any open source stuff in
general, so nothing for Gtk# in particular. My day job has been using up
all my brain juice, and getting a new apartment has not helped either.
I'm sorry for not addressing the pending PRs.
I hope I'll be able to get back to contributing, but I can't make any
promises. I'm of course open to suggestions on how to make things
better, and also for people who want to take over maintainership.
I don't way to block cool stuff from happening.
My idea was, once git master reached a certain level of maturity, to
create a 3.0 branch, which would be API-stable and bug fixes only.
Git master could then be updated to bind the GTK+ 3.12 or 3.14 APIs,
which would then itself be branched off when it's mature.
So that's approach 2 described by Antonius.
I know that Gtk# 2.12 and before uses something like approach 1. See for
https://github.com/mono/gtk-sharp/blob/gtk-sharp-2-12-branch/bootstrap-2.12
https://github.com/mono/gtk-sharp/commit/fe2d4c311
I don't know exactly what the pros and cons of that approach were, it
was before I was involved.
But I think nowadays with git it's much easier to maintain each API in
it's own branch, and merge what is needed from one to the other. Doing
this with SVN at the time would probably have been painful.
What do you think ? How far are we from being able to delare the Gtk#
API stable for 3.0 ?
Cheers,
--
Bertrand
Hi,
I agree with Tomi that it hurts development when PRs remain unattended.
Since the current plan (release 3.0 first, higher versions after that),
prevents contributions of higher version API, I think we should discuss
alternative development plans concerning the release of newer Gtk#
1. Use conditional compilation to build different API versions. Keep
all supported versions in the master branch. (The same as mono does with
various .NET profiles.)
2. Create a branch for each Gtk# release and have unstable API in the
master branch.
Both approaches support simultaneous development of different Gtk#
versions. Both are feasible (though approach 1 would need PR #129 [1] to
be merged for working with bindinator's conditional code generation
feature).
What are your opinions on this? What are the pros and cons concerning
the alternative approaches?
- antonius
[1] https://github.com/mono/gtk-sharp/pull/129
Post by Tomi ValkeinenHi,
It's been five months since the last commits to gtk-sharp git
repository. Would someone please tag and release 2.99.4 so that
we'd get
Post by Tomi Valkeinenthe fixes into use in Linux distros?
What are the major missing things that need to be fixed before 3.0 can
be released? While I'm personally fine with 2.99.x releases, I guess
lots of people won't touch it until it's out of beta.
And while at the subject, I understand that the maintainers may
not have
Post by Tomi Valkeinentime to spend on gtk-sharp, but if so, would it be better to just
merge
Post by Tomi Valkeinensome of the merge requests like "Updated to Gtk 3.12" to keep the
development going on, than wait until maybe some day 3.0 has been
released before merging?
Tomi
_______________________________________________
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
_______________________________________________
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
_______________________________________________
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list