Re: New module proposal: Clutter core
Hi! Kenneth Nielsen k.nielse...@gmail.com, Mon, 4 Oct 2010 15:45:02 +0200: 2010/10/4 Johannes Schmid j...@jsschmid.de: Hi! Clutter is still hosted on a separate server because the Clutter Project wants to be an umbrella for a set of projects, like language bindings, toolkits, and applications that may or may not be related to the GNOME Project. we're fairly liberal with giving people access to the repository, and we have infrastructure in place for user repositories for contributors. the Bugzilla instance is still in place because Clutter is used in non-GNOME projects that might need restricted access. I want to raise the point again, that the separate git server is painful for translators which is the main reason that I dislike it. (see http://mail.gnome.org/archives/gnome-i18n/2010-July/msg00075.html and follow ups) Basically the point is that if we allow core modules to be hosted elsewhere we can shut down the GNOME Translation Project as it exists now completely because our whole quality work with coordinators and reviewers will become obsolete. GNOME has a very long and good tradition of high-level and consistent translations which would get lost. The point is not that important for clutter which probably doesn't contain many user visible strings but if we they yes here it will be difficult to say no with other modules. Needless to say that I of course in general like the idea of having clutter as a core module. Regards, Johannes I agree with Johannes, especially about the quality. As an easy fix for this, couldn't we just keep the translations in a git.gnome.org module? It would not allow us to run intltool-udpate and all that, but that would probably be ok as long and the maintainers would fetch new translations and update translation files with new strings regularly. Oh, so here we go again. Thanks for raising this issue, guys. I'm, too, convinced that it's important for the future of the GTP and GNOME translation teams to decide what should we require from core GNOME modules (or however we label/define it). I'm not really sure whether it's realistic to expect any [code hosting] infrastructure movement in this case, but as Aron Xu suggested the last time this discussion came up, we could try to propose doing the clutter l10n management the system-tools-backends way, i.e. maintaining a Git clone on git.gnome.org. Certainly, clutter is a fairly different piece of software, and this cloning workflow may have some clear shortcomings. E.g. maintenance burden for developers, depending on developers' time, no guarantee of up-to-date POT files, as our translators are used to and expect it esp. when dealing with tight deadlines, that is every six months. If nothing more, we could at least persuade developers to stick to the more closely managed module l10n community (if such a word is appropriate here), so to not allow anyone on the net to submit translation work with, from the GTP perspective, varying quality. Moving this discussion back to desktop-devel-list where it should have stayed with a CC'd gnome-i18n. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: splitting up gnome-games
Le lundi 04 octobre 2010 à 16:39 -0400, Colin Walters a écrit : On Mon, Oct 4, 2010 at 12:56 PM, Emilio Pozuelo Monfort po...@ubuntu.com wrote: Can't you just create several binary packages out of one source package? Of course. But it's a maintenance pain to do so and helps perpetuate downstream forking of the build system. Sorry but I don’t follow you. It’s not harder to make 10 binary packages out of 1 source package than to package 10 source packages - it’s usually easier. And there’s no need to fork the build system for that. Cheers, -- .''`. : :' : “You would need to ask a lawyer if you don't know `. `' that a handshake of course makes a valid contract.” `--- J???rg Schilling ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: Clutter core
On Tue, 2010-10-05 at 10:25 +0200, Johannes Schmid wrote: I want to raise the point again, that the separate git server is painful for translators which is the main reason that I dislike it. (see http://mail.gnome.org/archives/gnome-i18n/2010-July/msg00075.html and follow ups) I agree with Johannes, especially about the quality. As an easy fix for this, couldn't we just keep the translations in a git.gnome.org module? It would not allow us to run intltool-udpate and all that, but that would probably be ok as long and the maintainers would fetch new translations and update translation files with new strings regularly. Oh, so here we go again. Thanks for raising this issue, guys. I'm, too, convinced that it's important for the future of the GTP and GNOME translation teams to decide what should we require from core GNOME modules (or however we label/define it). Moving this discussion back to desktop-devel-list where it should have stayed with a CC'd gnome-i18n. thanks for the feedback. I'm not even going to try and convince the i18n teams - mostly because I agree: the GNOME i18n teams should be using a single infrastructure and not 20 different ones. now, how do we go from here to there is probably worth discussing. I cannot move Clutter to gnome.org; it's simply unfeasible for various reasons, one of which is that the Clutter Project is not just used by GNOME. this is similar to GStreamer, or Cairo, which are hosted on freedesktop.org. another thing to consider is that translating Clutter is probably never going to be a priority: the messages are mostly going to be errors; there are no widgets, complex or otherwise composed by user-facing text; and the only other translatable, user-facing strings are property nicks and blurbs that can only be visible if a UI builder tool is introspecting them to create a UI. currently, Clutter uses Transifex in a fairly passive way: I get emails for new PO files, I copy them into the repo and commit them. I checked if Transifex has a way to handle custom repositories, so that I could allow direct commit access to a branch, and then periodically merge the branch back into master; it doesn't seem to be possible without getting the Transifex admins to handle custom repositories - and, honestly, right now the burden is not at all high. I'm pretty sure the GNOME infrastructure could do the same thing: get the POT file from git.clutter-project.org (it's generated by gettext and stored in the repository anyway); send me an email with the PO file once the coordinator has reviewed the contribution. I could even allow commit access to a branch, or a user repository that I can pull from. alternatively, GNOME could have a private Clutter core repository for i18n purposes alone - after all, we're using Git. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: Clutter core
Hi! I'm pretty sure the GNOME infrastructure could do the same thing: get the POT file from git.clutter-project.org (it's generated by gettext and stored in the repository anyway); send me an email with the PO file once the coordinator has reviewed the contribution. I could even allow commit access to a branch, or a user repository that I can pull from. That would work (in might be a good idea to implement for git repositories in general). We didn't manage to commit to GNOME git yet though and I doubt it would be easier on other repositories. It's something that could be considered in long-term, also for some freedesktop modules. alternatively, GNOME could have a private Clutter core repository for i18n purposes alone - after all, we're using Git. We do that for some other modules and it works OK. Note: As stated before I am not so much concerned about clutter itself but about our general policy on handling external repositories. For git it might kind of work but for other things like launchpad it could become worse. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
2.91.0 status
While I am watching my candidate moduleset build in jhbuild, here is a quick status update on where we stand with 2.91. Most of this information was extracted from the moduleset, which is based on tarballs, so it is possible some things are fixed in git already. If that is the case, don't hesitate to roll a late 2.91 tarball, I'll gladly take it. Matthias Stuff thats not building against current GTK+: avahi (fixed in yesterdays 2.6.28 release, will include that) gst-plugins-base (fixed in git, workaround is to use --disable-examples) gtk3-engines (will get a new release tonight) ... Stuff that hasn't been ported to GTK3: metacity gdm cheese gnome-games gnome-user-share mousetweaks gnome-netstatus gnome-system-monitor gnome-utils seahorse seahorse-plugins vino sabayon anjuta gst-plugins-base gnome-system-tools deskbar-applet ekiga Stuff thats not updated from 2.32: gtk-engines:2.90.3.1 libgnomekbd:2.32.0 gnome-media:2.32.0 alacarte:0.13.2 bug-buddy:2.32.0 caribou:0.1.5 dasher:4.11 dconf:0.5.1 deskbar-applet:2.32.0 ekiga:3.2.7 epiphany:2.31.5 evolution-webcal:2.32.0 gcalctool:5.32.0 gconf-editor:2.32.0 gdm:2.32.0 gnome-applets:2.32.0 gnome-disk-utility:2.32.0 gnome-games:2.32.0 gnome-mag:0.16.2 gnome-menus:2.30.4 gnome-netstatus:2.28.2 gnome-nettool:2.32.0 gnome-panel:2.32.0.2 gnome-screensaver:2.30.2 gnome-system-monitor:2.28.2 gnome-system-tools:2.32.0 gnome-themes:2.32.0 gnome-user-docs:2.32.0 gnome-user-share:2.30.1 gnome-utils:2.32.0 hamster-applet:2.32.0 libgail-gnome:1.20.3 libgnome-keyring:2.32.0 libgnomeprint:2.18.8 libgnomeprintui:2.18.6 libgtop:2.28.2 liboobs:2.32.0 librsvg:2.32.0 libsoup:2.32.0 libwnck:2.30.5 metacity:2.30.3 mousetweaks:2.32.0 nautilus-sendto:2.90.0 pygtksourceview:2.10.1 seahorse-plugins:2.30.1 sound-juicer:2.32.0 swfdec-gnome:2.30.1 tomboy:1.5.0 totem:2.90.5 totem-pl-parser:2.32.0 vinagre:2.31.5 vino:2.32.0 yelp:2.31.7 yelp-xsl:2.31.5 zenity:2.32.0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
On Tue, Oct 5, 2010 at 10:49 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Stuff thats not updated from 2.32: ... tomboy:1.5.0 I'm not sure I understand. Tomboy 1.5.0 is our new development release corresponding with 2.29.0 1.4.x is the stable series corresponding with GNOME 2.32.x. Are we good or am I missing something? Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
Hi! anjuta Sorry, I am working on it but not for this unstable release (well that's why there was no release). Currently focusing on GSettings and afterwards on gtk+-3.0. But I hope to have everything going for the next unstable release. Also, gdl might not currently build due to GdkPixmap - cairo changes. Regards, Johannes signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
On Tue, Oct 5, 2010 at 1:55 PM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: On Tue, Oct 5, 2010 at 10:49 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Stuff thats not updated from 2.32: ... tomboy:1.5.0 I'm not sure I understand. Tomboy 1.5.0 is our new development release corresponding with 2.29.0 1.4.x is the stable series corresponding with GNOME 2.32.x. Are we good or am I missing something? We are good. I just wasn't very careful when editing that list. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
Am Dienstag, den 05.10.2010, 10:55 -0700 schrieb Sandy Armstrong: On Tue, Oct 5, 2010 at 10:49 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Stuff thats not updated from 2.32: ... tomboy:1.5.0 I'm not sure I understand. Tomboy 1.5.0 is our new development release corresponding with 2.29.0 2.29 of what? If it's GNOME you'd need a time machine. ;-) andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: splitting up gnome-games
On Tue, 5 Oct 2010, Josselin Mouette wrote: Le lundi 04 octobre 2010 à 16:39 -0400, Colin Walters a écrit : On Mon, Oct 4, 2010 at 12:56 PM, Emilio Pozuelo Monfort po...@ubuntu.com wrote: Can't you just create several binary packages out of one source package? Of course. But it's a maintenance pain to do so and helps perpetuate downstream forking of the build system. Sorry but I don’t follow you. It’s not harder to make 10 binary packages out of 1 source package than to package 10 source packages - it’s usually easier. And there’s no need to fork the build system for that. Hi! I would just like to mention some of the many advantages of keeping gnome-games in a single distribution of gnome-games: - One distribution allows the translators and documentation project teams to work in a single location. This means less duplicated work, because many of the games share a lot of translatable strings, and this makes it easier to translate gnome-games. - A lot of code, sounds and image files are shared across all the games. Maintainging these in a single location means that less duplicated work will have to be done. Regards, Andreas R.___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.10.2010 19:49, schrieb Matthias Clasen: Stuff that hasn't been ported to GTK3: deskbar-applet Stuff thats not updated from 2.32: deskbar-applet:2.32.0 You can remove deskbar-applet from the GNOME 3.0 moduleset, because gnome-shell basically makes it obsolete. - -- Greetings, Sebastian Pölsterl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyrZn8ACgkQ1ygZeJ3lLIfRDACfRVhHHnk4tdaBudsCNzl5biRg 4gIAnix3UXAqLZWS5j9poFeOmxX2QXRj =hEvq -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.0 status
On Tue, Oct 5, 2010 at 11:09 AM, Andre Klapper ak...@gmx.net wrote: Am Dienstag, den 05.10.2010, 10:55 -0700 schrieb Sandy Armstrong: On Tue, Oct 5, 2010 at 10:49 AM, Matthias Clasen matthias.cla...@gmail.com wrote: Stuff thats not updated from 2.32: ... tomboy:1.5.0 I'm not sure I understand. Tomboy 1.5.0 is our new development release corresponding with 2.29.0 2.29 of what? If it's GNOME you'd need a time machine. ;-) I'm pretty sure there's a 2 and a 9 and a 0, and very confident there is no 3, in the version number I meant. Sandy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: splitting up gnome-games
Hi, On Mon, Oct 4, 2010 at 11:30 AM, Colin Walters walt...@verbum.org wrote: Hi, I'd like to float the idea of splitting up gnome-games upstream into separate git modules. The main rationale is that downstream, we want separate binary packages; this is most convenient to do if upstream is separate modules. Having separate binaries would make application installation/removal saner, and avoid pulling in the large dependency set of the games as one unit. Also, if there are any other git modules that ship multiple applications (i.e. .desktop files and executables), I'd like to see that split up too. I think this makes a lot of sense. You've already mentioned a few reasons for why these meta-module constructions are problematic - but they aren't the only ones. Meta-modules like gnome-network, gnome-media, gnome-utils, and even gnome-control-center for a long time (though for GNOME 3 we've given it a new focus) were very difficult to maintain and hence very poorly maintained. There are a number of reasons for this but one big part of it is that maintainership was essentially per-submodule. That really breaks the maintainer model that we use and there was a bit of tragedy in that unowned commons space. Just promote them to full modules and break out the shared bits into libraries. It simplifies things a great deal. Code responsibilities/duties/blame, git history/branches/tags, and bug-tracking/patch-review will all be much more straightforward and clear. In GNOME 3 we will be bringing app identity into more focus too. Basically if you are creating a user facing interface you are either an application or part of the core UX. That doesn't really match up very well with the meta-module approach of a loose grouping of windows/dialogs that (incompletely and loosely) match a certain category. We're better off with a one-to-one mapping of module to application and a type of tagging system to identify the app as a game, sound or network utility, etc - either in an app store, distro, or jhbuild. There may have been valid reasons why meta-modules were convenient in pre-git days but those reasons no longer apply. If we find that we don't have a maintainer for a certain submodule that isn't a reason not to break it out of a meta-module. That is a reason to break it out and mark it as unmaintained - or drop it. As well as an opportunity for new contributors. Jon ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: Clutter core
Le mardi 05 octobre 2010 à 18:41 +0200, Johannes Schmid a écrit : Hi! I'm pretty sure the GNOME infrastructure could do the same thing: get the POT file from git.clutter-project.org (it's generated by gettext and stored in the repository anyway); send me an email with the PO file once the coordinator has reviewed the contribution. I could even allow commit access to a branch, or a user repository that I can pull from. That would work (in might be a good idea to implement for git repositories in general). We didn't manage to commit to GNOME git yet though and I doubt it would be easier on other repositories. The blocker is not technical, but more about the policy to accept commits from an application (and create security hooks). I know it's on Christer's TODO so there is some hope :-) If clutter is open to give D-L a commit access, we could try to set up something in the not so long-term... Cheers, Claude It's something that could be considered in long-term, also for some freedesktop modules. alternatively, GNOME could have a private Clutter core repository for i18n purposes alone - after all, we're using Git. We do that for some other modules and it works OK. Note: As stated before I am not so much concerned about clutter itself but about our general policy on handling external repositories. For git it might kind of work but for other things like launchpad it could become worse. Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: splitting up gnome-games
On Tue, Oct 5, 2010 at 13:44, William Jon McCann william.jon.mcc...@gmail.com wrote: difficult to maintain and hence very poorly maintained. There are a We don't have any problems maintaining GNOME Games except when the entire GTK+ rendering stack gets ripped out from under a 10 year old code base 3 weeks before tarballs are due. number of reasons for this but one big part of it is that maintainership was essentially per-submodule. That really breaks the maintainer model that we use and there was a bit of tragedy in that unowned commons space. We will meet our maintenance responsibilities or the games lacking attention will be dropped (temporarily). Just promote them to full modules and break out the shared bits into libraries. It simplifies things a great deal. It makes things 10 times more complicated for us. Code responsibilities/duties/blame, git history/branches/tags, and bug-tracking/patch-review will all be much more straightforward and clear. We don't presently have any issues with any of those. In GNOME 3 we will be bringing app identity into more focus too. App identity? Basically if you are creating a user facing interface you are either an application or part of the core UX. That doesn't really match up very well with the meta-module approach of a loose grouping of windows/dialogs that (incompletely and loosely) match a certain category. We're better off with a one-to-one mapping of module to application and a type of tagging system to identify the app as a game, sound or network utility, etc - either in an app store, distro, or jhbuild. There may have been valid reasons why meta-modules were convenient in pre-git days but those reasons no longer apply. GNOME Games will not be splitting for the valid reasons that Andreas and I have enumerated. If we find that we don't have a maintainer for a certain submodule that isn't a reason not to break it out of a meta-module. That is a reason to break it out and mark it as unmaintained - or drop it. As well as an opportunity for new contributors. That may happen if it comes down to the wire but it will be marked abandoned as there will be no way to build it without libgnome-games which will not be a separate public library. I *really* don't want to drop anything, though. We already know that the games remaining have some hard-core fans. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please ship changelogs in your tarballs
Dodji Seketeli dodji at seketeli.org writes: I personaly find ChangeLogs quite valuable for situations where people have the source packages (like a distribution DVD) but not necessarily an access to the internet and want to understand when/how something changed. I found myself in such a situation not very long ago and I was very happy to have a proper ChangeLog around. Hrm, in 90% of the cases where I need information about why changes were made, I need git blame/cvs annotate style output, and a ChangeLog cannot give me this information. (Also, the tools to filter ChangeLogs suck, or are there equivalents to git log -- $file?) So I think it would be a lot better if instead of just generating a ChangeLog, we would ship the full git history in the tarball. That way you have a history that is as useful as possible. It would also make GPL purists happy, because we'd ship it in the preferred form of making modifications, which a tarball isn't - even with a ChangeLog. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
