Re: GNOME Goals
On 23/09/14 15:46, Michael Catanzaro wrote: On Tue, 2014-09-23 at 16:08 +0200, Sébastien Wilmet wrote: As a related matter, it seems that the GNOME Goals don't have a lot of success. Related, but separate. The problem is not so much slow adoption of old goals, but lack of approval for new ones. Header bars are still an unapproved goal that should not yet be implemented? I don't think so I took a look at the GNOME goals just to see where Tracker was with them, we're actually implementing most of the new unproposed goals already and I had no idea. I was hoping there would be some newer ones we could work on too - it would be good to have some more goals in there. Maybe the problem is that developers are not aware of the goals, so they fix their own modules unconsciusly (based on their own criteria) but do not change the module's status in the wiki. It's partly that, more awareness is always a good thing. -- Regards, Martyn Founder Director @ Lanedo GmbH. http://www.linkedin.com/in/martynrussell ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Improving Quality
The high contrast goal may be my fail, since I've been trying to complete it, but I missed the new modules in the list. The main question now is: how can we avoid this situations? It should be easy to check that a new module fits the proposed goals, but the problem I see is that new modules (at least the not-core ones) are not announced anywhere. Sometimes, I notice there are new modules in Git because I see them in DL with 0% strings translated... I could help with this task, opening bugs in case that any goal is not applied, but we should had some acting rules about it. 2014-09-24 0:42 GMT+02:00 Michael Catanzaro mcatanz...@gnome.org: On Tue, 2014-09-23 at 20:24 +0200, Daniel Mustieles García wrote: About this, I have a question... existing modules are easily tracked, and can check if they fit the goals but, what happens with new modules? When a developer creates a new module, is he/she advised to review and apply the goals? No, they slip under the cracks. This is why someone announced the high contrast goal was nearly complete, when in fact there are many new apps without high contrast icons. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Improving Quality
On 09/24/2014 11:04 AM, Daniel Mustieles García wrote: The high contrast goal may be my fail, since I've been trying to complete it, but I missed the new modules in the list. I think we did great progress regardless of not reaching the goal fully. I now know it's an issue, so I try to keep an eye on new apps and will create new icons for these. Ideally we will have e full coverage for 3.16. - Andreas ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Improving Quality
2014-09-24 11:23 GMT+02:00 Andreas Nilsson li...@andreasn.se: On 09/24/2014 11:04 AM, Daniel Mustieles García wrote: The high contrast goal may be my fail, since I've been trying to complete it, but I missed the new modules in the list. I think we did great progress regardless of not reaching the goal fully. Sure! And I'm very grateful for your help with it. We just forget to include the new modules, but we can do it for the next release. I now know it's an issue, so I try to keep an eye on new apps and will create new icons for these. Ideally we will have e full coverage for 3.16. - Andreas ___ 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: Improving Quality
Matthias Clasen matthias.cla...@gmail.com wrote: ... I think this is a great idea. When we discussed this at Guadec, I got the impression that we should use this to draw attention to longstanding UX annoyances, early enough in the cycle to address them. Here is a short list of (my personal) candidates for this category: 728496 evolution-data-server - Gnome shell keeps poping modal dialog for gmail password 710848 polari - private messages vs shell chat 705177 gnome-shell - Full-screen apps disappear on Alt+Tab We'll need some guidelines for which bugs we include, and for what the list should look like as a whole. My idea for this would be something like: * Bugs should affect user experience quality - commonly experienced papercuts, lack of polish, or enhancements that would make a positive difference. * Only bugs from core applications and modules should be included. Priority should be given to the most generally visible issues. * Bugs shouldn't be allowed to linger on the list without an identifiable solution. * The vast majority of the bugs should be in a fixable state. * At any one time, the list shouldn't be longer than 40 [?] issues. * The list should contain a mix of issue types, ideally including a combination of easy polish fixes and more difficult tasks. There are possibilities to be systematic about which issues we prioritise. I'd really like to have scheduled walkthroughs during the development cycle, for example - and we could use those to populate the list. Likewise, user testing results or results from QA testing could be fed in. Of course, if we do that, the list could get quite long - so that would require some thought. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goals
On 24 September 2014 09:31, Martyn Russell mar...@lanedo.com wrote: I took a look at the GNOME goals just to see where Tracker was with them, we're actually implementing most of the new unproposed goals already and I had no idea. Much the same as my modules; the burden of keeping the wiki up to date is kinda high. It would be great if we could auto-generate the GNOME goal status table so that it stays up to date. Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Improving Quality
An end-user experience. I am testing Fedora21. Between Fedora20 and Fedora21, at this point in time, execution efficiency for the interface lies with Fedora20. Perhaps in the Fedora Alpha-rc1, there is much extra code for debugging and assert macro calls and this will disappear at time of Go Live. With testing, I found I could not load some existing (Web) Gnome Extensions. Is someone looking at these Web extensions, since Vanilla Gnome (Fedora21), is not enough useful to leave Fedora20 for version 21, given the tweaks that make Gnome more usable. Off Topic. With the ALL display, next to each glob (DOT), could Gnome include the first character of the corresponding icon that would be displayed at location (1,1) on the screen. Justification. If I am searching for a program beginning with M, Within the All display, I can, with one click, arrive at the beginning of the M s. Regards Leslie Mr. Leslie Satenstein SENT FROM MY OPEN SOURCE LINUX SYSTEM. From: Allan Day allanp...@gmail.com To: Matthias Clasen matthias.cla...@gmail.com Cc: desktop-devel-list desktop-devel-list@gnome.org Sent: Wednesday, September 24, 2014 5:45 AM Subject: Re: Improving Quality Matthias Clasen matthias.cla...@gmail.com wrote: ... I think this is a great idea. When we discussed this at Guadec, I got the impression that we should use this to draw attention to longstanding UX annoyances, early enough in the cycle to address them. Here is a short list of (my personal) candidates for this category: 728496 evolution-data-server - Gnome shell keeps poping modal dialog for gmail password 710848 polari - private messages vs shell chat 705177 gnome-shell - Full-screen apps disappear on Alt+Tab We'll need some guidelines for which bugs we include, and for what the list should look like as a whole. My idea for this would be something like: * Bugs should affect user experience quality - commonly experienced papercuts, lack of polish, or enhancements that would make a positive difference. * Only bugs from core applications and modules should be included. Priority should be given to the most generally visible issues. * Bugs shouldn't be allowed to linger on the list without an identifiable solution. * The vast majority of the bugs should be in a fixable state. * At any one time, the list shouldn't be longer than 40 [?] issues. * The list should contain a mix of issue types, ideally including a combination of easy polish fixes and more difficult tasks. There are possibilities to be systematic about which issues we prioritise. I'd really like to have scheduled walkthroughs during the development cycle, for example - and we could use those to populate the list. Likewise, user testing results or results from QA testing could be fed in. Of course, if we do that, the list could get quite long - so that would require some thought. Allan ___ 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
New list for Continuous (and celebrating 17,296 trees to date)
We have a new dedicated list for the GNOME Continuous project: https://mail.gnome.org/mailman/listinfo/gnome-continuous-list Background on Continuous: https://wiki.gnome.org/Projects/GnomeContinuous I believe GNOME Continuous is still presently the fastest of its scale[1] public automated continuous delivery[2] (not just CI, and not manual packaging) of an operating system. Let's look at the repository statistics as of today: $ ostree --repo=repo log gnome-continuous/buildmaster/x86_64-devel-debug | grep commit | wc -l 17296 Each tree is a result of one or more git commits to one of the 300 git repositories actively tracked by Continuous, from NetworkManager, systemd, the Linux kernel, X.org, and of course the many, many git repositories that make up GNOME core and many applications. $ ostree --repo=repo log gnome-continuous/buildmaster/x86_64-devel-debug | tail -5 commit 0143dd0e484ee81637cf530611fb048012fc614c1369314fc631696377e043b5 Date: 2013-09-12 05:09:03 + Compose That was the first commit in the current repository; then over ~377 days, that's an average of ~45 releases a day, with very little in the way of human intervention. Each release is booted, tested, and screeenshots taken. All of these builds presently occupy 153G: $ du -shc repo/objects 153Grepo/objects One of the reasons I believe Continuous is so successful in fulfilling its design goal is by default it updates without human intervention, but we have the ability to *undo* - to un-ship when things break. This is radically different from the traditional model of distributions which update manually. At any point, if there's a bad commit to one of the input git repositories, it's very easy for a build administrator to just revert to a previous commit, and tell the upstream author. When it's fixed, we can untag. At the moment for example, both systemd and NetworkManager have been tagged pending resolution of issues: https://git.gnome.org/browse/gnome-continuous/commit/?id=108653bc9f8e66bd19228f5bd8f2505b51263fe5 https://git.gnome.org/browse/gnome-continuous/commit/?id=7f06173d7ce6085b2732a7190bf1fb7f64ff77e0 If you're interested in the system as a user or developer, please feel free to join the new list! [1] If you know of something that approaches the scale and speed and is delivering an OS (e.g. kernel + userspace with update system, let me know) [2] http://en.wikipedia.org/wiki/Continuous_delivery ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
