We're not suggesting anything of the sort. We're saying that PyGTK+ hasn't been touched in two years. If this patch lands today, can we ensure that a new release of PyGTK+ is sent to distributions? Will you take the responsibility to make a new release, a new tarball, etc?
If it simply lands in git and that's it, why do it at all? On Thu, Apr 4, 2013 at 10:58 AM, Ma Xiaojun <[email protected]> wrote: > On Thu, Apr 4, 2013 at 10:27 PM, Andre Klapper <[email protected]> wrote: > > Likely a long time for an unmaintained module that has not seen any code > > activity for years: https://git.gnome.org/browse/pygtk/log/ > > > > Maybe you have some luck to find a developer on > > https://mail.gnome.org/mailman/listinfo/python-hackers-list . > > However I don't expect anybody to create a new tarball of pygtk that > > distros would pick up and ship, so not sure how much sense this makes. > > > > This touches a general unsolved issue: Sharing the maintenance burden of > > deprecated modules across distributors who ship enterprise / long-term > > support versions. Same problem e.g. for gnome-vfs, libgnome, ... > > I guess if somebody offered maintainership, nobody would refuse. > > It's all logistics issues on your side; I don't care about the > community dynamics. > I just care how GNOME community as a whole treat third-party developers. > > It boils down simply to a trivial reference counting issue. "People > urge to have this bug fixed " has nothing to do with "people want to > take over PyGTK". > _______________________________________________ > desktop-devel-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > -- Jasper
_______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
