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 <antoniusr...@gmail.com > <mailto:antoniusr...@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@lists.ximian.com > <mailto:Gtk-sharp-list@lists.ximian.com> > > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list > > > _______________________________________________ > Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com > <mailto:Gtk-sharp-list@lists.ximian.com> > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list > > > > > _______________________________________________ > Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com > http://lists.ximian.com/mailman/listinfo/gtk-sharp-list >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
