[Gtk-sharp-list] Please release gtk-sharp 2.99.4
Tomi Valkeinen
tomi.valkeinen at iki.fi
Tue Mar 3 10:25:13 UTC 2015
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
On 25/02/15 23:44, Bertrand Lorentz wrote:
> Hello,
>
> 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.
>
>
> Regarding the strategy for newer GTK+ API and Gtk# releases:
> 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
> example:
> https://github.com/mono/gtk-sharp/blob/gtk-sharp-2-12-branch/bootstrap-2.12
>
> This was removed in the early days of porting to GTK+ 3, see:
> 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
>
> On Sun, Feb 22, 2015 at 1:23 PM, Antonius Riha <antoniusriha at gmail.com
> <mailto:antoniusriha at gmail.com>> wrote:
>
> 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#
> versions. I think, in addition to the current plan there are 2
> alternatives:
> 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
>
> On 2015-02-21 08:33, Tomi Valkeinen wrote:
> > Hi,
> >
> > 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
> > the 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
> > time to spend on gtk-sharp, but if so, would it be better to just
> merge
> > some 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
> >
> >
> >
> > _______________________________________________
> > Gtk-sharp-list maillist - Gtk-sharp-list at lists.ximian.com
> <mailto:Gtk-sharp-list at lists.ximian.com>
> > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
> >
> _______________________________________________
> Gtk-sharp-list maillist - Gtk-sharp-list at lists.ximian.com
> <mailto:Gtk-sharp-list at lists.ximian.com>
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>
>
>
>
> _______________________________________________
> Gtk-sharp-list maillist - Gtk-sharp-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ximian.com/pipermail/gtk-sharp-list/attachments/20150303/3619479a/attachment.pgp>
More information about the Gtk-sharp-list
mailing list