Re: GNOME 3.14 Blocker Bugs
On Sat, Aug 2, 2014 at 12:22 AM, Andre Klapper ak...@gmx.net wrote: A first list of blockers and potential blockers for the upcoming release, based on data in GNOME Bugzilla. Note that there are lots of gnome-themes-standard/HighContrast tickets open. Please take a quick look at the list below, comment (on the ticket), and raise your voice if you see an important issue missing. Thanks! andre == GNOME-CONTROL-CENTER == background: thumbnails are tiny in 3.13.3 https://bugzilla.gnome.org/show_bug.cgi?id=732375 == GNOME-SHELL == desktop menu went missing https://bugzilla.gnome.org/show_bug.cgi?id=731932 Invalid backlight level at startup https://bugzilla.gnome.org/show_bug.cgi?id=727048 == GNOME-THEMES-STANDARD == HighContrast: calendar theming https://bugzilla.gnome.org/show_bug.cgi?id=732490 HighContrast: all white in gtk3-widget-factory https://bugzilla.gnome.org/show_bug.cgi?id=732482 HighContrast: flat button love https://bugzilla.gnome.org/show_bug.cgi?id=732492 HighContrast: invisible pane splitter https://bugzilla.gnome.org/show_bug.cgi?id=732485 HighContrast: expander hover state https://bugzilla.gnome.org/show_bug.cgi?id=732495 HighContrast: inconsistent toggle button unreadable https://bugzilla.gnome.org/show_bug.cgi?id=732487 HighContrast: neuter the statusbar frame https://bugzilla.gnome.org/show_bug.cgi?id=732489 HighContrast: no padding in actionbars https://bugzilla.gnome.org/show_bug.cgi?id=732491 HighContrast: vertical spin buttons look bad https://bugzilla.gnome.org/show_bug.cgi?id=732483 HighContrast: suggested/destructive-action https://bugzilla.gnome.org/show_bug.cgi?id=732493 HighContrast: broken hover for check/radio buttons https://bugzilla.gnome.org/show_bug.cgi?id=732486 HighContrast: popover background missing https://bugzilla.gnome.org/show_bug.cgi?id=732488 == GTK+ == popovers can't always track the widget https://bugzilla.gnome.org/show_bug.cgi?id=729140 gtk-demo: entry completion doesn't work https://bugzilla.gnome.org/show_bug.cgi?id=695504 treeview: column drop target visualization broken https://bugzilla.gnome.org/show_bug.cgi?id=732916 == MUTTER == [regression] Can't turn off wayland https://bugzilla.gnome.org/show_bug.cgi?id=729490 == POLARI == polari 3.13.2 has a lot of transparent text, making it almost impossible to use https://bugzilla.gnome.org/show_bug.cgi?id=734100 Should be fixed already. ===Further bugs that would be good to fix or get progress with:=== == GNOME-NIBBLES == Remove statusbar https://bugzilla.gnome.org/show_bug.cgi?id=666501 == GNOME-SHELL == Modal password boxes prevent users from looking up or generating passwords https://bugzilla.gnome.org/show_bug.cgi?id=688434 This can't be fixed without designer input. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 01/08/2014, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet swil...@gnome.org wrote: Hi, Hi, At some rare occasions, especially after the string freeze, translation commits are pushed when rolling a tarball for making a new release. Since the commit for the release should be pushed only when 'make distcheck' has succeeded, there can be a push conflict and the maintainer have to repeat the process (sometimes several times). I think it would be nice to send mails on gnome-i18n and gnome-doc-list to explain that commits should not be pushed during the release days. If a translation or documentation commit is important, the maintainers can anyway be contacted on IRC to know if the commit can be pushed. I think there is no equivalent of 'svn lock' for git, so sending a mail is a solution. Bonus point is to add a warning on l10n.gnome.org, but it is more work. What do you think? +1. Is it too rare to care about this problem? I don't think so but being a maintainer for years, you'll learn to do `git push origin master` first always. :) As someone who makes releases, I always prefer to have the latest translation in the release, but I understand that running a distcheck on some of the larger projects can take a long time. From a documentation point of view, it doesn't make sense to block pushes for a whole day, especially as some maintainers release very late. Have you considered dropping an email to gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running the distcheck? I found communicating with translators to be very effective and the docs team would prefer communication over a ban. -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Bugs
On Sat, Aug 2, 2014 at 12:22 AM, Andre Klapper ak...@gmx.net wrote: == GNOME-CONTROL-CENTER == background: thumbnails are tiny in 3.13.3 https://bugzilla.gnome.org/show_bug.cgi?id=732375 I'm pretty sure this one was already fixed by Debarshi. == GNOME-THEMES-STANDARD == HighContrast: calendar theming https://bugzilla.gnome.org/show_bug.cgi?id=732490 HighContrast: all white in gtk3-widget-factory https://bugzilla.gnome.org/show_bug.cgi?id=732482 HighContrast: flat button love https://bugzilla.gnome.org/show_bug.cgi?id=732492 HighContrast: invisible pane splitter https://bugzilla.gnome.org/show_bug.cgi?id=732485 HighContrast: expander hover state https://bugzilla.gnome.org/show_bug.cgi?id=732495 HighContrast: inconsistent toggle button unreadable https://bugzilla.gnome.org/show_bug.cgi?id=732487 HighContrast: neuter the statusbar frame https://bugzilla.gnome.org/show_bug.cgi?id=732489 HighContrast: no padding in actionbars https://bugzilla.gnome.org/show_bug.cgi?id=732491 HighContrast: vertical spin buttons look bad https://bugzilla.gnome.org/show_bug.cgi?id=732483 HighContrast: suggested/destructive-action https://bugzilla.gnome.org/show_bug.cgi?id=732493 HighContrast: broken hover for check/radio buttons https://bugzilla.gnome.org/show_bug.cgi?id=732486 HighContrast: popover background missing https://bugzilla.gnome.org/show_bug.cgi?id=732488 To explain these: I did a review of HighContrast at some point during our big theme rework, and put all that I found on the 3.14 blocker list for some reason. I think most (if not all) of these will be fixed by Jakub's sass rewrite of HighContrast. I don't know how far along that is, though. == GTK+ == popovers can't always track the widget https://bugzilla.gnome.org/show_bug.cgi?id=729140 This has a new patch, should land very soon. gtk-demo: entry completion doesn't work https://bugzilla.gnome.org/show_bug.cgi?id=695504 We discussed a short-term fix for this in the GTK+ bof. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, Aug 2, 2014 at 9:37 AM, Ekaterina Gerasimova kittykat3...@gmail.com wrote: On 01/08/2014, Zeeshan Ali (Khattak) zeesha...@gnome.org wrote: On Thu, Jul 31, 2014 at 5:24 PM, Sébastien Wilmet swil...@gnome.org wrote: Hi, Hi, At some rare occasions, especially after the string freeze, translation commits are pushed when rolling a tarball for making a new release. Since the commit for the release should be pushed only when 'make distcheck' has succeeded, there can be a push conflict and the maintainer have to repeat the process (sometimes several times). I think it would be nice to send mails on gnome-i18n and gnome-doc-list to explain that commits should not be pushed during the release days. If a translation or documentation commit is important, the maintainers can anyway be contacted on IRC to know if the commit can be pushed. I think there is no equivalent of 'svn lock' for git, so sending a mail is a solution. Bonus point is to add a warning on l10n.gnome.org, but it is more work. What do you think? +1. Is it too rare to care about this problem? I don't think so but being a maintainer for years, you'll learn to do `git push origin master` first always. :) As someone who makes releases, I always prefer to have the latest translation in the release, but I understand that running a distcheck on some of the larger projects can take a long time. From a documentation point of view, it doesn't make sense to block pushes for a whole day, especially as some maintainers release very late. Have you considered dropping an email to gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running the distcheck? I found communicating with translators to be very effective and the docs team would prefer communication over a ban. You mean send them email to not push translations? Are they all on those lists and read their inbox each time before pushing changes? If so, sure but then again the main issue (at least for me) is forgetting (to run `git push master` rather than `git push master RELEASE`) so I don't know what adding an additional manual step to remember would achieve. -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 09:37 +0200, Ekaterina Gerasimova wrote: Have you considered dropping an email to gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running the distcheck? I found communicating with translators to be very effective and the docs team would prefer communication over a ban. With an equivalent of 'svn lock', there can be a friendly message explaining that a developer is creating a release, and that the commit can be pushed later (e.g. the following day). It is anyway temporary. I wouldn't use the word ban, I prefer the word temporary lock, it is less negative. Docs and translations commits are more than welcome, you do a great job! It is just that the push conflicts can be a little annoying. But if each maintainer sends a mail to announce the distcheck to the translation and doc teams, you'll receive hundreds mails, it doesn't scale. Another mail should also be sent when the distcheck is finished. Sending such mails is not convenient for the maintainer, and it assumes that those mails are read as soon as they are sent. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On 2014-08-01 23:40, Sébastien Wilmet swil...@gnome.org wrote: On Fri, 2014-08-01 at 18:40 +0200, Kalev Lember wrote: It's not really much of a problem for me to run 'make distcheck' once more to pick up additional translation goodness. For stable releases taking the latest translations is important, but for unstable releases it's not a big deal if the translation is for the next beta. Making releases is not the funniest part of a maintainer work, even if push conflicts are rare (at least for me), the fact that I know it can happen doesn't put me in a comfortable position when rolling a tarball (it's more on the psychological side). It is not a problem for me, neither a psychological or an actual one (I cannot remember a time when a translation commit has been pushed while I ran distcheck, but conceivably it could have happened), so I would rather keep the behaviour simple, as it is now. -- http://amigadave.com/ signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Fri, 2014-08-01 at 17:22 +0200, Olav Vitters wrote: I think we could add something as equivalent to svn lock. It takes a bit of time to setup though, and damned lies (l10n.gnome.org) would have to be able to handle errors from git.gnome.org. If enough devs speak up I could maybe make something to lock a repository against pushes. Maybe with a timeout, maybe not. With SVN anyone could force a lock to be removed. Not sure of what is best. I assume a lock should at most be held for 2 hours. Would be a nice-to-have thing. I personally have a script for creating the tarball in one command (after creating the commit). It does a git clean, make, make distcheck etc. So the lock/push/unlock can easily be added to such a script, without adding more manual steps. I'd appreciate a bit of insight from some tarball creators aka maintainers :-P In gedit it has already happened to have to distcheck 3 times due to 2 translation commits pushed. So this is something that *can* happen. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Archived git modules
On Thu, 2014-07-31 at 11:21 +0200, Olav Vitters wrote: On Wed, Jul 30, 2014 at 05:12:53PM +0200, Olav Vitters wrote: The following git modules have been archived: [...] Anything can be unarchived of course. In Bugzilla, I've moved all affected products to the Deprecated classification, closed them for new bug entry, closed remaining open tickets, added a gnome[unmaintained] whiteboard entry, and added a comment explaining the reasons. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, Aug 2, 2014 at 2:24 PM, Sébastien Wilmet swil...@gnome.org wrote: On Sat, 2014-08-02 at 09:37 +0200, Ekaterina Gerasimova wrote: Have you considered dropping an email to gnome-doc-l...@gnome.org and gnome-i...@gnome.org lists before running the distcheck? I found communicating with translators to be very effective and the docs team would prefer communication over a ban. With an equivalent of 'svn lock', there can be a friendly message explaining that a developer is creating a release, and that the commit can be pushed later (e.g. the following day). It is anyway temporary. I wouldn't use the word ban, I prefer the word temporary lock, it is less negative. Docs and translations commits are more than welcome, you do a great job! It is just that the push conflicts can be a little annoying. Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Fri, Aug 1, 2014, at 07:18 PM, Sébastien Wilmet wrote: Maybe GNOME Continuous could run 'make distcheck' on (almost) every commit? To detect such errors earlier than the release day. No. I think tarballs are a waste of CPU power and human time generated solely because many popular downstream build systems predate widespread use of revision control and haven't made the leap to understanding git. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 14:14 +0200, Zeeshan Ali (Khattak) wrote: You mean send them email to not push translations? Are they all on those lists and read their inbox each time before pushing changes? If so, sure but then again the main issue (at least for me) is forgetting (to run `git push master` rather than `git push master RELEASE`) so I don't know what adding an additional manual step to remember would achieve. I like 'git push --follow-tags' If you have to 'git pull --rebase' due to a translation commit after running distcheck and tagging the commit, you can still do this: it's a bit questionable since the tag and release won't be on any branch, so I normally rerun distcheck, but it works. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution. (replying to myself after a bit more thoughts) I think it's the best compromise. I've never thought about this solution because I always do a rebase on top of master. Thanks for the tip! Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. You shouldn't need to create a branch for this. What we're talking about here is an utterly normal and everyday part of the git workflow — not specific to releases and translations. Any time you've done some work locally and it's time to push it upstream, you may find that someone else has pushed something before you. The correct thing to do when that happens is to pull, resulting in a merge commit in your tree, and then push that upstream. There's nothing to see here; this whole thread doesn't exist. There is no problem. In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution. Right. You have correctly identified the root cause of the problem. We shouldn't be advising people as a matter of course *not* to use the version control system correctly in the manner in which it was designed. This mentality of rebasing for no better reason than because we like straight lines isn't just an issue in the specific case discussed here. It also causes the loss of accurate history in other cases, which can cause problems. It's relatively rare, but it does happen that two concurrent patches can conflict with each other. I could do some work in my local tree which is entirely correct and functional, but by the time I've finished testing and I go to push it upstream, someone else has pushed something which subtly breaks my work. If I rebase, it is just human nature that I'm not going to retest every intermediate commit of the rebased version as carefully as I retested the original, and it's quite possible that I'll end up pushing a commit which in some circumstances *never* worked. If I use git correctly and push the *merge*, however, then my original work is preserved. Someone later trying to work out what happened has actually got a correct version of history to refer back to, and the problem can be correctly tracked down to the *merge* of the concurrent changes. Whereas if I rebase and rewrite history to make it look like I just committed something that *never* worked, sorting that out later is *much* harder. We really ought to abandon this idea that we prefer to have a linear git history. It might be simpler that way, but it's wrong, and in the cases that *matter* it actually makes things harder. And the cases that don't matter... don't matter. Unless you have some kind of OCD about straight lines. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, 2014-08-02 at 15:38 +0100, David Woodhouse wrote: The correct thing to do when that happens is to pull, resulting in a merge commit in your tree, and then push that upstream. Merge conflicts are probably less likely to happen in GNOME thanks to the longer development cycle. In contrast with a merge window of two weeks in Linux. So a normal merge should probably be done only when a merge conflict happens. In the other cases a rebase is better in my opinion (if we trust Git). But you're absolutely right, we're doing it wrong™. As a side note, a merge window has an advantage: it normally prevents half-finished features to be sneaked in at the last minute, with the hope that all the bugs will be identified and fixed during the feature freeze. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Bugs
On Sat, 2014-08-02 at 00:22 +0200, Andre Klapper wrote: Please take a quick look at the list below, comment (on the ticket), and raise your voice if you see an important issue missing. https://bugzilla.gnome.org/show_bug.cgi?id=728496 is getting really annoying as well. signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Translation commits pushed when rolling a tarball
On Sat, Aug 2, 2014 at 4:09 PM, Sébastien Wilmet swil...@gnome.org wrote: On Sat, 2014-08-02 at 15:55 +0200, Sébastien Wilmet wrote: On Sat, 2014-08-02 at 15:21 +0200, drago01 wrote: Well you could just create a branch do your release there so that you don't have to care about what happens on master (branches are free in git) and merge it back to master afterwards. In GNOME we generally prefer to have a linear git history, but creating a branch is indeed another solution. (replying to myself after a bit more thoughts) I think it's the best compromise. I've never thought about this solution because I always do a rebase on top of master. Thanks for the tip! Actually thats what I usually do but trouble with this approach is that I often then forget that I'm on the branch and assume everything went fine after doing a successfull `git push origin master git push origin TAG`. Later I realize that master has changed and my tag is not in its history. :( -- Regards, Zeeshan Ali (Khattak) Befriend GNOME: http://www.gnome.org/friends/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
git.gnome.org changes and new doap file requirements
[ Please reply to desktop-devel-list@gnome.org ] André Klapper suggested we should make more use of the doap files. As a result of that together with GUADEC, the following changes have been made on git.gnome.org: 1. New categories: Core, Core Apps, Apps Note: Not every module has been put into right category. If you spot errors, please let release-t...@gnome.org know. I'm planning to add some cross checks in the release team scripts to ensure everything is and stays aligned. 2. Owner field shows programming language This is taken from the programming-language field in the doap file. You can specify multiple programming languages. Piotr Drąg and André Klapper ensured that most Core/Core Apps/Apps modules have these fields. This should make it easier for someone to suggest a good up to date overview of modules to start off with. Note: Unfortunately cannot rename the Owner field into programming language ☹ 3. Stats per week/month/quarter/year https://git.gnome.org/browse/gtk+/stats/?period=qofs=10 e.g. Matthias Clasen apparently does most gtk+ commits. To ensure that the doap file can be used for more purposes, the following additional fields are now mandatory for Core/Core Apps/Apps modules: - programming-language - description DOAP files are only checked when you change them. Changes are reflected almost immediately. For the full details behind these DOAP files, see: https://wiki.gnome.org/Git/FAQ#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F Aside from above I also slightly changed the wiki.gnome.org header (e.g. shows RecentChanges+Schedule again). The Schedule is IMO quite important. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: git.gnome.org changes and new doap file requirements
Hi, thank you for your efforts. I just tried to update some DOAP files (and thought it's a quick job), but came across some questions: On 3.8.2014 at 1:33 AM Olav Vitters wrote: [ Please reply to desktop-devel-list@gnome.org ] André Klapper suggested we should make more use of the doap files. As a result of that together with GUADEC, the following changes have been made on git.gnome.org: 1. New categories: Core, Core Apps, Apps Can you please point out how they are defined? Is software that was in 'Other' or 'Productivity tools' before an App or a Core App or nothing of them now? 2. Owner field shows programming language What exactly is meant by 'Owner'? The development team of a project? How does that relate to a programming language? To me they are different shoes. The RDF spec has no field 'Owner', but only 'Programming language'. How shall we deal with markup languages? From a technical point of view they are not programming languages because they miss things like alternations, loops and sequences. From the point that a DOAP file should serve us value it would be a good idea to have them added anyway to find contributors familiar with XML, HTML etc. For the full details behind these DOAP files, see: https://wiki.gnome.org/Git/FAQ#How_do_I_add_a_description_to_the_git_web_view.3F__What_is_this_.22blah.doap.22.3F The links 'DOAP files' and 'DOAP web page' are dead, but I found this instead: https://github.com/edumbill/doap/ We have an old OMF file from 2004 with a subset of the DOAP information lying around in one of our projects. I guess OMF is superseded by DOAP now, right? Thank you in advance, Sven ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
