Fwd: gnome-shell.main.pot is incorrect
Forwarding this call for help to d-d-l which probably has a larger pool of people with the necessary skills. -- Forwarded message - From: Claude Paroz Date: Sat, Apr 23, 2022 at 10:58 AM Subject: Re: gnome-shell.main.pot is incorrect To: Le 18.04.22 à 18:51, Alex Melman via gnome-i18n a écrit : > The .pot file is missing some strings of translation. Read more at > https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/5126 We badly need to solve https://gitlab.gnome.org/Infrastructure/Websites/-/issues/282, which is to install a more recent version of gettext in the OpenShift virtual machine created for l10n.gnome.org. If someone is familiar with Docker and CentOS-like distros, please help! (work is happening in https://gitlab.gnome.org/Infrastructure/damned-lies/-/tree/oscp) Claude ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Wrapping up Bugzilla migration
Hi, On Wed, May 19, 2021 at 2:49 PM Andre Klapper via desktop-devel-list < desktop-devel-list@gnome.org> wrote: > before turning Bugzilla read-only > and then converting it to static HTML. Happy to help with that. > Does such a static HTML version still provide search? -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.34.4
On Thu, Feb 20, 2020 at 11:30 AM Jordan Petridis via desktop-devel-list wrote: > There will be both 3.36.x and 3.34.x release scheduled throughout the year. I > think we are aiming for either 9 or 12 (+1) months of releases/support for > 3.34. Once you reach a decision on that term, can you please explain the change on the i18n list so that coordinators know what branches are worth working on? -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 10:53 PM Michael Catanzaro wrote: > So it seems we have two GNOME clients for Matrix Since I know some of the people who keep using IRC are actually using something like irssi (maybe with tmux/screen) or weechat and care more about a terminal option than a GNOME one, let’s mention there are several terminal clients available too, including a weechat script. Granted, if the motivation for that method is to “always be connected” then a GNOME client would do the job as well for Matrix. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 10:43 PM Michael Catanzaro wrote: > The problem there is simply that you can never log off once you join the IRC > bridge Ha! So that must be what Georges was talking about! I didn’t get that it was about *IRC* servers. > (or, if such a way exists, it's so hard to discover that the GNOME > community is not using it). There actually is a way. Once more it involves the GIMPNet IRC Bridge status conversation. People can start a new conversation with @gimpnet-irc:gnome.org by the way if they don’t have it anymore. The bot has a !quit command and its help says: `!quit : Leave all bridged channels, on all networks, and remove your connections to all networks.` > So if you try the IRC bridge once just to > see what it's like, you're forever left with a ghost user account that > people will send private messages to without realizing you can't read > them (or even public messages, if your real account is offline). Removing inactive account is kind of a hard problem (would you be happy to find out you lost your nick and history if for some reason you came back a long while after your last use?) but I *think* matrix.org actually has a policy to clean them up after several months, which would reduce that issue. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 8:46 PM Jan Alexander Steffens wrote: > We currently have loads of garbage IRC users in the channels after the bridge > hosted at matrix.org was replaced with one hosted at the gnome.org > homeserver. The old bridge left its Matrix users in the rooms and the new > bridge dutifully bridges them over to IRC. Maybe they tried to contact one of > these users. Ok, I’ll investigate that issue. Thanks for letting me know about it. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 8:23 PM Georges Basile Stavracas Neto via desktop-devel-list wrote: > It doesn't allow me to log out of the servers. > I’m not sure what you mean by that. What would that action achieve as a result? > Matrix apparently > doesn't allow turning off federation, and to me that's a no-go aspect of > it. > It does. Plenty of deployments are internal and not federated. I disagree that we should not federate, just as I don’t think we should block any non gnome.org email address to sent email to gnome.org email addresses, but it can be done and it’s trivial. > At last, I have a strong impression that Matrix suffers from feature bloat. > I’m sure you would get angry at a user for saying the same thing about GNOME. You can probably do better than that. > Rocket.Chat has been apparently more responsive to out contact, > Quite the unbacked statement when Matthew has been actively participating in Matrix related discussions on our lists (and I don’t recall ever seeing any such discussions for Rocket.chat here). > and even accepted a few pull requests from us. > I have no idea what this is about, but the Fractal team is in constant contact with the rest of the Matrix ecosystem. Some of our contributors have contributed to Matrix, some Matrix contributors have contributed to Fractal… -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 8:20 PM Link Dupont wrote: > On Wed, 2020-02-12 at 20:16 +0100, Alexandre Franke wrote: > > The Matrix folks offered to host our instance on > > [Modular](https://modular.im/) just like they already do for KDE and > > now Mozilla too[1], so sysadmin time is not a problem, is it? > > > > [1] they just switched, details at > > https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620 > > https://gnome.modular.im already exists. Do we know who created it or > who at Modular.im can clue us in? Yes, Matthew. I’m sure he’ll jump in here at some point. He’s probably not reading d-d-l as closely as we are, so give him a bit of time. ☺ I’ll poke him if we have a specific question that needs his immediate attention. In the meantime, I guess the ball is the GNOME court. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 8:07 PM Zander Brown wrote: > I've used the matrix bridge for years now (I'm generally only on irc "for > real" > to fix things after the bridge does crazy things like de-op me or change my > nick without warning...) > > Matrix isn't perfect. matrix.org, the main "homeserver", regularly has > high > latency further exacerbated by the bridge. Hopefully hosting our own would > avoid that > Yes, it would help a lot both ways: * we wouldn’t be hurt by performance issues on the matrix.org HS (apart from federation issue for people “from there”) * we would reduce the load on the matrix.org HS My concern would be the "federal" nature of matrix where people don't need a > gnome.org specific chat account to join a room. Whilst there are a lot of > arguments for this I'm increasingly convinced it's an anti-feature > especially > if we want to enforce CoC (which, of course, we do) > That was a concern for Mozilla too. I don’t know the details, but they have a solution for that it seems. See e.g. the Community safety section in the [annoucement]( https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620 ). -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix IRC bridge considered harmful
On Wed, Feb 12, 2020 at 7:31 PM Michael Catanzaro wrote: > Hi, Hi, > I just got an email from a new-ish contributor: "I sent you some PMs > about a week ago but I think you weren't online when I sent them so I'm > assuming you didn't receive anything." Problem is the Matrix IRC bridge > presents all IRC users as online, even when they're not. Not immediately relevant to the issue but would help me as I’m a bit confused: weren’t *you* on Matrix rather than IRC? > If an IRC user > is offline, it lets you send private messages, but they get *silently > dropped*. From Matrix, it appears as if the message was successfully > delivered, but it was never actually sent to IRC. I’m pretty sure one gets at least a notification in the GIMPNet IRC Bridge status conversation that goes along the lines of: Received an error on irc.gimp.org: err_nosuchnick ["AlexandreFranke","someircnick","No such nick/channel"] At least I did a couple weeks ago when I tried to send a message to an IRC user. I would then agree that it is far from ideal, but it would also clearly not as dramatic as you paint it. > Personally, I think native Matrix would be a *lot* nicer than IRC, if > we have sysadmin time to get it set up, but I'm not going to be picky > here. I'd just like us to be able to trust that we're not missing > important messages. The Matrix folks offered to host our instance on [Modular](https://modular.im/) just like they already do for KDE and now Mozilla too[1], so sysadmin time is not a problem, is it? [1] they just switched, details at https://discourse.mozilla.org/t/synchronous-messaging-at-mozilla-the-decision/50620 -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: earlier tarball deadlines
On Fri, Aug 16, 2019 at 9:12 PM Bastien Nocera wrote: > On Fri, 2019-08-16 at 13:49 -0500, mcatanz...@gnome.org wrote: > > I'm a bit confused by this argument, because Monday is only the > > deadline, the last-possible day to release, not a recommended day. > > It's the "last-possible day" *therefore* it is the day that most > tarballs will be released. Indeed. Moreover, in my experience, many maintainers consciously leave that time for translators and check the status of their module on Damned lies to see if there’s any team currently working on it and whether they need to wait just a tiny bit longer for that language to land in time. Kudos to all of those who do that, it is greatly appreciated. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: earlier tarball deadlines
On Wed, Aug 14, 2019 at 8:04 PM wrote: > Hi, Hi, > I'd like to propose moving tarball deadlines for the 3.36 cycle one > business day earlier, from Mondays to Fridays, while leaving the > overall release deadline on Wednesday. That way, we can have the > weekend for trying to build the release. This will allow release team > more time to resolve build failures, hopefully making the job less > stressful for us. It should also help us avoid late releases. Currently > we're not able to begin building the release before Monday night > (American timezones) or Tuesday morning (European timezones), which has > led to several late releases on Thursday, Friday, and occasionally even > later. Managing a release is usually a full-day task at least, and > doing this on business days is very difficult for some of us. There's > some more motivation for this discussed at [1]. > > An alternative proposal would be to use Saturday instead of Friday as > the tarball deadline, which might be nicer for maintainers who prefer > to release over the weekend. That would still allow release team to > build the release on Sunday. > > Please, if you have any concerns, let us know. Also let us know if you > have a preference between Friday and Saturday. Remember that the > deadline still occurs at 23:59 UTC on the day specified. Weekends are usually the time when most translations get done. If you remove this opportunity, I guess we should consider freezing earlier too so that translators basically get the same amount of time to do their job. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: I believe we should reconsider our sys-tray removal
On Sat, Mar 23, 2019 at 7:07 PM Britt Yazel wrote: > I want to re-poen an old argument now that we have seen the effects of > removing the sys-tray/app-indicator tray for well over a year. In short, the > users are not happy. *Some* users. Please refrain from making such dubious claims when there is no data to support it. Even “most people I talk to” is unreliable, as for every person that complains about it there are 9.7 users who don’t. I am a user and I am happy about the change. > I believe our goals of putting pressure on application > developers to ditch the antiquated app-indicator model fell mostly on deaf > ears, and not having the sys-tray icons is mostly a nuisance for people, and > big pain point for many. None of the apps I use seem to have a problem with the lack of systray, and it’s clear that 15 years ago some of them would have had an icon there (e.g. Music, Fractal). This has had a positive impact on my daily experience and I am thankful for GNOME to be behind this push. > Our users (myself included) and our software partners (Ubuntu, System76, > Purism) have reverted to using extensions to return this behavior. Again, *some* users. Count me as one of those who don’t. > we have forced our users to fragment themselves between many solutions, I don’t feel forced. > An example of this biting us in the arse is that with 3.32 > TopIcons is causing the CPU usage to run through the roof, and people are > blaming the Shell for the CPU usage, not the extension, leaving our users > with a bad taste in their mouths. That is indeed an issue, I acknowledge this. It doesn’t mean the premise of this email is correct. > So to sum up, most users who I talk to on social media and in person are > using many different 3rd party solutions for sys-tray icons, and this > fragmented approach is hurting our image, annoying our users, and is > fragmenting our user experience to the point of actual detriment. I think we > need to re-evaluate a solution for 3.34, and that this should be a focus this > cycle. I believe that there is an elegant solution to handling sys-tray icons > without sacrificing our core goals, one idea being to incorporate it into the > Dash. However, I don't think we should go forward into 3.34+ without a 1st > party solutions in place for how to treat sys-tray icons, because (sadly) > they're not going anywhere. Please consider how unnecessarily pushy this sounds. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarifications regarding GNOME Online Accounts
Hi, On Mon, Feb 11, 2019 at 4:46 PM Allan Day wrote: > The “documents” source type is primarily used by GNOME Documents to > access Google Drive. […] > GNOME Documents is able to use the “files” source type as an > alternative to the documents type, and can be converted so that it can > continue to access Google Drive > > The “documents” source type is also used by GNOME Documents to access > Microsoft OneDrive, and there is no replacement planned for this. The "documents" source type is also used by GNOME Documents to access NextCloud, isn’t it? What is the future of that? -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.31.90 released
Hi, On Thu, Feb 7, 2019 at 1:26 AM wrote: > we have entered feature freeze, UI freeze, and API freeze The i18n team would also like to remind you that we have also entered String change announcement period. That means you should send us an email if you make any changes that introduces new untranslated or fuzzy strings. This is not a freeze yet, you do not need approval from us. We would also appreciate if you could try your best to make any such changes *before* string freeze (in two weeks). Cheers, -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab mirror considered harmful
On Mon, Feb 4, 2019 at 5:58 PM Philip Chimento wrote: > Could we take it all the way and just push the PR branch to > "$github_user_name/$branch_name" > in the main repository on GitLab, and open a merge request automatically, > then instruct the > auto-close bot to direct the person to GitLab, possibly telling them how to > create an account > as well? Maybe even one step further: find out whether the contributor has an account on our gitlab (same email? Used their github account for authentication?) and fork the repo for them, then copy their github branch to this fork and open the MR. > Also tag the maintainer's GitHub account (if they have one) in the auto-close > message, > so they get a notification? Isn’t a mention on our gitlab instance enough in that case? -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Mastodon Instance?
On Wed, Oct 31, 2018 at 12:16 PM Emmanuele Bassi wrote: > For a less trivial case: let's say that a "GNOME haters" group sets up a > Mastodon > instance, and starts spamming @mastodon.gnome.org users; administrators of the > mastodon.gnome.org instance would need to block the whole "gnomehaters" > instance. Right. This is the case I had in mind. So if such an instance appears and gets blocked, there would be no way for e.g. someone from the engagement team to follow a user from that instance who would happen to make constructive negative feedback or be a good entry point to make damage control. That is a bit sad but not a blocker issue. It’s worth knowing. Thanks for the additional details. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Mastodon Instance?
On Mon, Oct 15, 2018 at 3:20 PM Emmanuele Bassi via desktop-devel-list wrote: > Just to be clearer: once the GNOME Mastodon instance gets into a federation, > it'll need somebody to moderate > the graph to block instances and users from other instances in the fediverse. > I'm not (overly) worried about people > with an @gnome.org address on the GNOME instance, and for those we do have > the Code of Conduct committee > (and, hopefully soon, a new code of conduct). Thanks for the clarification, I was indeed puzzled by your first reply. Can you expand a bit on what that instance blocking would entail? Would e.g. a Foundation member still be able to follow someone from a blocked instance? -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Renaming gitg project file to GNOME Commits
On Wed, Oct 10, 2018 at 11:26 PM Milan Crha via desktop-devel-list wrote: > I'm used to gitk (which uses Qt, if I'm not mistaken). gitk uses tk (as in Tcl/Tk). qgit uses Qt. > Can it work with anything else than git? No. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Retiring app menus - planning for 3.32.0
On Fri, Sep 21, 2018 at 9:47 PM Bastien Nocera wrote: > On Fri, 2018-09-21 at 21:08 +0200, Tomasz Torcz wrote: > > > Going extra mile to “find” shortcut is never gonna fly. Years ago, > > we > > had a perfect solution for discovering shortcuts – relevant letters > > were underlined in the menus. In some cases underlining appeared > > only > > after Alt was pressed, which was less discoverable, but still many > > times more easy to find than shortcuts popup easter egg. > > Please bring back underlined menu items. > > Those are not keyboard shortcuts, they're mnemonics, used for > navigating menus using the keyboard, not launching keyboard shortcuts > without opening the menu. > > Feel free to start a new discussion about those, but they're really not > the topic. And also they are actually not gone, so there is no discussion to even have. Open Nautilus, press F10 for the menu to open, press Alt, mnemonics are underlined as expected. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Retiring app menus - planning for 3.32.0
On Fri, Sep 21, 2018 at 1:25 PM Allan Day wrote: > Bastien Nocera wrote: > > It's faster to access for users, has terser explanations (no need to > > create sentences to describe actions) and > > To be clear, I'm still thinking this through but, if you had a page in > the user docs which was a simple table of keyboard shortcuts, which > was one click away in the user docs, there wouldn't be all that much > to separate it from the keyboard shortcuts windows. And the advantage > would be more integrated user documentation (I think that's > essentially what the keyboard shortcut windows are). This would reduce > the number of menu items, allows cross-linking, and so on. The integrated search that filters relevant shortcuts is probably not something that could be achieved easily in docs. Try it in totem: open the shortcut window (hit ctrl+shift+?) and start typing "forward". That kind of workflow is selling it for me. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Gravatar vs libravatar
On Thu, Sep 20, 2018 at 3:52 PM Carlos Soriano wrote: > Right we read that too, although it doesn't give very high hopes. How so? The maintainer was alone and wanted to stop so he announced the stop with a few months notice, but many people stepped up and have formed a team. One can read their coordination effort in public meeting minutes on their wiki. So instead of the alarming “the service is shutting down” you reported here, it actually is getting stronger maintainership. If that is not hopeful news, I don’t know what will do it for you. > The main problem is the second point, it just redirects stuff to Gravatar, so > not much point (and quite shady imho) That part is indeed concerning and requires clarification. > If someone wants to help with that and contact libravatar developers feel > free to do so. Sure, I’ll get in touch with them to find out what that means. Now here’s a question because what happens is not clear to me: did the libravatar call all redirect to gravatar, or just some of them? In the latter case, maybe reverting was a hasty decision as reducing the number of calls, while not as perfect as we expected, is still progress. Cheers, -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Retiring app menus - planning for 3.32.0
Hi, On Thu, Sep 20, 2018 at 12:52 PM Allan Day wrote: > To be honest, I'm not sure how successful the keyboard shortcut windows > have been and I suspect that they're not being used a great deal. What are you basing this on? Did you get specific feedback about that, or was there a user testing session that showed this? I have the exact opposite feeling, solely based on my own experience: I do use the shortcut window often and I find it very valuable. Cheers, -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Gravatar vs libravatar
On Mon, Sep 3, 2018 at 8:13 PM Carlos Soriano wrote: > Hello all, > Hi, > If you have any other comment, feel free to provide it here or in the > issue. > For those who may not know it yet, libravatar is decentralized and federated alternative to gravatar. It has a few free software implementations (including the one used on the main public instance) and one can host their own instance or use a public one. We should encourage the use of such services rather than centralized ones based on non free software. It’s worth noting that Damned lies already supports libravatar. -- Alexandre Franke GNOME Hacker ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documentation - language default
On Thu, Apr 5, 2018 at 10:50 PM, Sriram Ramkrishna <s...@ramkrishna.me> wrote: > On Thu, Apr 5, 2018 at 2:18 PM Jeremy Bicha <jbi...@ubuntu.com> wrote: >> Let me confirm and restate: GNOME has a Docs team. It would be cool if >> you would work with the existing Docs Team when doing big Docs stuff. >> > > I talked to Petr (on a bugzilla ticket) and they have given their ok on > going forward as long as we keep them in the loop because they are > responsible for the developer.gnome.org site. I also promised to be a > liaison between the two teams. If discussions happened in the docs channel, there wouldn’t be a need for liaison, would there? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Fri, Mar 23, 2018 at 11:56 AM, Carlos Soriano <csori...@gnome.org> wrote: > Proper formatting from users is what issue templates are for. Many users don’t provide traces at first though and they only come in a later comment. Can templates be used for comments too or are they just for the issue description? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Wed, Mar 21, 2018 at 10:37 PM, Shaun McCance <sha...@gnome.org> wrote: > And in constructing this example for this email, I discovered that this > redirect ALREADY WORKS. Nevermind me. Carry on being awesome. And https://git.gnome.org/browse/nautilus/commit/?id=99fa9e298b289b643aab14286479676ec85dfd24 redirects to https://gitlab.gnome.org/GNOME/nautilus/commit/99fa9e298b289b643aab14286479676ec85dfd24 which is even more awesome. ☺ -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Wed, Mar 21, 2018 at 11:28 AM, Carlos Soriano <csori...@gnome.org> wrote: > Could you create an issue for those you know so I can evaluate them one by > one? > Ideally with a way to contact their maintainers. I don’t know of other projects from the top of my head and reviewing the list at https://bugzilla.gnome.org/page.cgi?id=browse.html=__all is probably the only way, but that would require quite an investment of time. I can’t take on that task right now and would appreciate anyone volunteering to do it. This could be split amongst several people. Should issues be filed against Infrastructure/GitLab? > In general I think these projects should decide themselves where they want > to live, and move either to one place or the other altogether. Sure, but they are unlikely to read d-d-l and similar lists as they have little interaction with our community, which Andre already raised. His proposal to send the announcement (amended with a note for non-GNOME project that they can elect to migrate outside of the GNOME infrastructure) sounds like a great idea. >> Any chance of getting https://gitlab.gnome.org/Incubator/bztogl/issues/7 >> fixed before then? > > Not sure, I think impersonating is still something some people don't agree > with. With the kinds of power admins already have, I really don’t think it is a big deal, especially if this is publicly announced. Did you actually have people express concerns or are you just assuming like you were in the first place? You already got positive feedback when that was discussed last time. The legibility gain on the other hand *is* a big deal. >> Can we make a pass of archiving before that? > > That was my desire too, but the agreement seems to be on the opposite and > have all the projects even for historical reasons. We could have a subgroup > for those though. Yes, a GNOME/Archives/ subgroup sounds good. > The work load for migrating git repositories is not an issue, on the other > hand migrating bugs is a big work load. Fair enough, archiving before migration and then moving them to the GNOME/Archives/ subgroup would still make it easier to find stuff once on Gitlab. Also archiving helps with translations and bugzilla. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Tue, Mar 20, 2018 at 6:01 PM, Carlos Soriano <csori...@gnome.org> wrote: > Hello community, Hi, > After a few months of manually migrating projects we have moved already over > 60, most of them were core modules to make sure the most important projects > were migrated before the mass migration happens. Congratulations on that achievement. > Proposed plan and timeline for mass migration What will happen to non-GNOME/third party products that we have on Bugzilla? The example that comes to mind is Doxygen as it’s quite visible (in the top 10 when looking at weekly reports). They use Bugzilla but not git.gnome.org. For this specific case, they could move their issues to Github where their repository already is There are probably other similar cases, I seem to remember some projects using Launchpad for code but our Bugzilla for bug reports. In any case those probably shouldn’t be moved to the GNOME group on Gitlab, right? > - Projects that want their bugs migrated will create an issue in our > infrastructure similar to this over the next two months. These project bugs > will be migrated to GitLab issues between June 1st and June 15th 2018. [0] Any chance of getting https://gitlab.gnome.org/Incubator/bztogl/issues/7 fixed before then? It was supposedly blocked because you thought people would be against the script impersonating them, but it turned out not to be an issue so I guess nothing is blocking it anymore. That would vastly improve legibility and usefulness of migrating issues. > - Projects that doesn't create an issue for bug migration will migrate only > the repository, also by June 1st 2018. Can we make a pass of archiving before that? Several repos haven’t had any activity at all (not even translations) for 2, 3, … up to 8 years. There’s not much sense migrating those. A cleanup would reduce the work load. Cheers, -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Check your default window size!
On Tue, Mar 20, 2018 at 6:35 PM, Ernestas Kulik <ernest...@gnome.org> wrote: > Hmm, we’ve actually received reports of a different issue - restoring > window *position* in multi-head environments was unreliable. I’ve fixed > it up a little, but removed that feature altogether from the > Any issues with restoring sizes are unexpected and > I’d appreciate a ticket. :) https://gitlab.gnome.org/GNOME/nautilus/issues/314 -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Check your default window size!
On Mon, Mar 19, 2018 at 10:49 PM, <mcatanz...@gnome.org> wrote: > Hi, Hi, > Sometimes it's easy for a developer to forget what a new user sees when > opening an app for the first time. Some of our apps (*cough* email clients > *cough*) have default window sizes that are waaay too small. Check yours > out! Increase the default window size if needed. At first I read the mail subject and was thinking “yes please!”, then I read the rest of your mail and was caught by surprise. While I agree that a minimum size needs to be large enough for an app to be useful, my general observation is that many apps are actually too large (or at least too wide) by default. On my 1050×1680 screen (yes, it’s narrower than it is tall, aka portrait): * Software opens with a bit that’s off screen (about the width of an app tile) but can be resized to fit so I don’t see a valid reason for the overflow. * Recipes opens narrow enough, but then if I browse my way to a screen with a sidebar (say “Indian cuisine”) it resizes and overflows too, and this time I can’t resize it to fit even if I go back to a sidebar-less screen. * Evince regularly opens a window that’s too big for my any of my screens, either in height or width. It seems Evince struggles with my “2 monitors but not in a rectangle shape” layout and there are already a few bug reports for that. It seems many apps (re)implement their own window size and position management with inconsistent behaviour. Maybe it’s time for a GNOME goal to fix this situation? Somewhat related, since not too long ago (I’d say 3.26, maybe 3.24) Nautilus randomly forgets it’s size and will open a very small window (with the sidebar displayed, the content area fits slightly less than a row in height and than 2 icons in width). P.S.: I know I should file bug reports/check for open ones and I dare say I’m generally not bad at that, I just haven’t had time to collect proper evidence for those yet so for now they’re just sticky notes on my desk. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, tips of the week and question of the week
On Wed, Jan 24, 2018 at 6:14 PM, Carlos Soriano <csori...@gnome.org> wrote: > Hello all, > Hi, > Today we hit a milestone, three of the biggest projects in GNOME has been > migrated, most of our core apps has been migrated, and with this all the > projects that were part of the deal with GitLab has been migrated. > Can you tell us more about that “deal”? I don’t remember it being mentioned before. > *Projects migrated today* > > - GNOME Shell <https://gitlab.gnome.org/GNOME/gnome-shell> > Excluding issues though. What is the plan there? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: paste.gnome.org
On Mon, Dec 4, 2017 at 8:36 PM, <mcatanz...@gnome.org> wrote: > Hi, Hi, > paste.gnome.org is great, except for: > > "You must select a language other than 'text' for this paste." > > where is the source code? Can we get rid of this? Have you tried following the link in the footer of said website? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla migration tool user accounts
On Thu, Nov 30, 2017 at 6:43 AM, <philip.chime...@gmail.com> wrote: > Bastien, do you also mean to imply that the wish to be subscribed to >2000 > issues means that receiving >2000 mails won't be a problem? It will be a problem, but not as bad as losing subscription on those issues. It would still be very much worth looking for a way to temporarily disable notifications to avoid that flood. I can also imagine that sending that many email out at once can raise some flags and make GNOME look bad in the eye of some email providers. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: All stable flatpak builds moved to flathub
e; and so on. Right. And that’s a bit of a tangent. GNOME could say they don’t support Flatpaks that don’t come from the GNOME infrastructure. Also, the parallels you draw to GNOME, Ubuntu and Debian are a bit irrelevant because in those cases we’re talking about a single entity using an infrastructure for themselves, when the issue I’m raising is *everyone* flocking to a common infrastructure. Cheers, [0] Flathub could still be one of the many hosting platforms, I just wish it addressed the problem of finding the other ones. [1] As a side note, moving GNOME apps to Flathub also means that now GNOME developers either have to interact with Github (several expressed reluctance to do so for various reasons) or wait/hope for someone else to do it for them, once again missing an opportunity. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: All stable flatpak builds moved to flathub
On Mon, Nov 13, 2017 at 11:49 AM, Alexander Larsson <al...@redhat.com> wrote: > The goal of flathub (https://flathub.org/) is to be a single location > where you can find builds of the latest stable version of linux desktop > applications, ideally maintained by the upstream author. That way the > experience for flatpak users is much nicer, just add one remote and you > can then find all apps via e.g. gnome-software. Such centralisation means a single point of failure. By supporting the addition of remotes, flatpak seemed to have potential for decentralisation. Is some kind of federation or other way to address this issue on the roadmap? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Application name strings consistency
On Mon, Sep 4, 2017 at 10:59 AM, Allan Day <a...@gnome.org> wrote: > I disagree. For some time I've argued that we should drop the "GNOME". > Reasons for this: > > 1. App names should be consistent. > 2. We generally don't expect users to know what GNOME is. > 3. There are other, better, places we can advertise the project, if that's > what we want to do. That’s for the name used in GNOME Software though, which is in the AppStream data and as such is also the name that will be picked up by other software catalog apps. Do you really want the KDE app store to show “Music” as such, which could be misleading to their users? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Application name strings consistency
Hey, Looking at the name the applications appear as both in Software and the about dialogs, I spotted inconsistencies and I thought it would be nice to fix that. Since we’re in string freeze, it’s too late to do it for this cycle. We can however start discussing it and make a decision regarding the correct way to do it. Only picking a few to illustrate: * Nautilus appears as Nautilus in Software, Files in about dialog * Weather appears as Weather both in Software and in about dialog * Terminal appears as Terminal in Software, GNOME Terminal in about dialog * Maps appears as GNOME Maps in Software, Maps in about dialog * Clocks appears as GNOME Clocks in Software, Clocks in about dialog * Music appears as GNOME Music in Software, Music in about dialog * Software appears as GNOME Software in Software, Software in about dialog There may already be a guideline for this, I haven’t taken the time to look it up. If it exists, it needs to be applied, maybe advertised as well. If it doesn’t, it should probably be created. Thoughts? Feedback? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 5:13 PM, Tomasz Torcz <to...@pipebreaker.pl> wrote: > It didn't save XMPP, why would this design results in different fate with > Matrix? https://matrix.org/docs/guides/faq.html#what-is-the-difference-between-matrix-and-xmpp -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 3:59 PM, David Woodhouse <dw...@infradead.org> wrote: > On Fri, 2017-08-25 at 15:34 +0200, Alexandre Franke wrote: >> If someone cares enough to implement support for a protocol in >> Telepathy, they could probably implement support for the protocol >> elsewhere too. > > But where is "elsewhere"? If not libpurple, where *should* I be adding > support for my new toy protocol for example? If you've just taken your > ball and gone home... Well why not libpurple? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 2:05 PM, David Woodhouse <dw...@infradead.org> wrote: > But isn't that the *point*? We have a framework with plugins for all > manner of different protocols, instead of a mess of separate protocol- > specific clients each of which can handle only *one*. When the choice is given to me between sticking to an abstraction that tries but doesn’t manage to grasp the quirks of several protocols, or switching to a protocol specific API and embrace it to make sure it is correctly and fully supported, I pick the latter. Even if I have to do it twice or more. I don’t think the *point* should be to support several protocols badly. I also don’t think we should aim at supporting all the protocols that exist. I don’t think a single client can map to the features of all of them. If someone cares enough to implement support for a protocol in Telepathy, they could probably implement support for the protocol elsewhere too. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Fri, Aug 25, 2017 at 1:46 PM, Felipe Borges <felipebor...@gnome.org> wrote: > All in all, if desirable, Matrix and GNU Ring could be connection > managers in Telepathy instead of standalone bits. > > Specific clients could be created backed by Telepathy, e.g. no need to > rely on Empathy. One of the main points of Sri’s proposal is to get rid of Telepathy. Its architecture is a burden and e.g. Polari has problems because of the extra layers that wouldn’t exist if it talked to IRC directly. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Matrix as a replacement for Telepathy
On Thu, Aug 24, 2017 at 10:40 PM, Sriram Ramkrishna <s...@ramkrishna.me> wrote: > What do people think about integrating directly with Matrix as a replacement > for Telepathy? Yes please. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updating GNOME Goals?
On Thu, Aug 24, 2017 at 9:20 AM, Daniel Mustieles García <daniel.mustie...@gmail.com> wrote: > Hi, Hi, > - /RemoveMarkupInMessages: it makes no sense to set a goal for this, because > a fixed module today might change tomorrow, introducing new strings with > markup. Maybe should be set as a guideline (and the goal moved to the > Expired section) https://wiki.gnome.org/TranslationProject/DevGuidelines/Avoid%20markup%20wherever%20possible already exists. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goals proposal: Help ID should match .desktop
Hey, On Tue, Aug 1, 2017 at 4:16 PM, Gabor Karsay <gabor.kar...@gmx.at> wrote: > Btw, the GNOME Goals wiki page recommends the gnome-love mailing list for > this, but it doesn't exist ... It is now newcomers-list, I fixed the page. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Tue, Jul 18, 2017 at 10:13 AM, Bastien Nocera <had...@hadess.net> wrote: > That's fine. The license of the compound work just has to be compatible > with the individual files' licenses, it doesn't need to be the exact > same one. > For example, you can have a project mixing GPLv2+, GPLv3+ and BSD > licensed files, and choose to have the compound work be GPLv3+. That > also tells contributors that any new files in the project should be > compatible with that overall license. I’m not claiming it doesn’t work. I’m just pointing it effectively means the files haven’t switched licenses, which is what was intended. nautilus-main.c and others still are under GPLv2+ and one can use them under GPLv2 if they so choose. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Tue, Jul 18, 2017 at 9:50 AM, Carlos Soriano <csori...@gnome.org> wrote: > Yeah maybe it's not sufficient. I can just create a custom LICENSE file that > says "license is in every file, all of them conpatible with gpl3+" or go > berseker and relicense every file to gpl3. Hmm no? What you currently have is: * a project that claims to be GPLv2+ (see notice at the top of e.g. nautilus-main.c) * with a notice that claims one should get a copy of the **GPLv2** with the project * and a copy of the **GPLv3** What you want is to change the existing notice so that it claims the proper license, and keep the new LICENSE file. > What notice do you mean? The license blurp in every file? Yes. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Relicensing Nautilus to GPLv3+
On Mon, Jul 17, 2017 at 10:23 PM, Carlos Soriano via desktop-devel-list <desktop-devel-list@gnome.org> wrote: > This is done now in > https://git.gnome.org/browse/nautilus/commit/?id=365ec7f7ac1cec51dc0248dd05b17cb78252a788 I don’t think that’s sufficient though. Putting a LICENSE file in the project directory just addresses the “You should have received a copy” provision, but doesn’t effectively place the code under that license. You could even have several license files if parts of your project are under different licenses. That license file you put in your repository also states that you should attach a notice to the program. It can take several form but the recommended one is in the header of your source. In fact, there is already such a notice and it claims that the software is GPLv2+ (https://git.gnome.org/browse/nautilus/tree/src/nautilus-main.c?id=365ec7f7ac1cec51dc0248dd05b17cb78252a788). This brings us to another point: do you intend to use GPLv3 or GPLv3+? The notice should be explicit about it (again, as suggested by the license you copied to your project). Cheers, -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 5:01 PM, Mathieu Bridon <boche...@daitauha.fr> wrote: > One-time contributions can be done entirely in the web UI, for example: One-time doesn’t necessarily mean trivial. What you describe is the workflow for a trivial change. One may still want to clone, compile, test locally even for a one-time contribution. > For one-time contributions, this is a **much** simpler workflow than > cloning the repository, making the changes, committing the change, > making a patch, then sending the patch by email/bugzilla. It even > enables non-technical people to contribute! Which is a great thing. That’s not what one-time contribution means though. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Wed, May 17, 2017 at 12:04 AM, Mattias Bengtsson <mattias.jc.bengts...@gmail.com> wrote: > At my work we keep a semi-linear git history: > - we only allow merges based on the tip of master > - we always merge with --no-ff (which is what GitLab's merge >button does) > > This gives us grouping of commits into features, while still > making sure our history is reasonably easy to follow. Do you have a public repo online to see what this looks like? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, May 16, 2017 at 3:22 PM, Allan Day <a...@gnome.org> wrote: > In recent months we have got together to examine the possibilities for > GNOME’s development infrastructure. We’ve spent a lot of time on this, > because we want the community to have faith in our conclusions. If you are > interested in this, you can read our research on the wiki [1]. Excellent. I think most will agree it’s time we implement such changes. > The outcome of this evaluation process is that we are recommending that > GNOME sets up its own GitLab instance, as a replacement for Bugzilla and > cgit. This mail mentions Gitlab as the only alternative. I know some people suggested to consider Phabricator, yet your proposal doesn’t mention it and by the looks of the wiki pages your research has been focused around Gitlab. Now I know very little about both Gitlab and Phabricator so I won’t push or block anything, but I’m a bit worried that this wasn’t given enough scrutiny. In particular, I saw that Phabricator has a tool for mockups/design (Pholio [0]) that really looked like something we’d make good use of. It would allow our designers to stop using Github, Dropbox, and such non free, not-on-our-infrastructure tools. So did you just look at Gitlab and think it’s good enough, or did you actually consider Phabricator (and maybe other alternatives) and pick Gitlab as the best fit? [0] https://www.phacility.com/phabricator/pholio/ -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)
On Tue, Mar 14, 2017 at 5:57 PM, Carlos Soriano <csori...@protonmail.com> wrote: > Oh I actually talked with Matthew today about this and opened a new bug: > > https://github.com/matrix-org/matrix-appservice-irc/issues/390 . In this > case this is for disabling the spam filter they have so any non-registered > user can talk with matrix users. The issue I was talking about in my previous email is not the same thing. I already filed a bug about it: https://github.com/matrix-org/matrix-appservice-irc/issues/382 It affects even registered users as you’ll see in the report. > Also regarding Michael advice of not talking to [m] users, that's semi true, > most of us already change the IRC handler to be our regular IRC nickname, so > for example I'm csoriano even from Matrix. Which might be an issue if we are > missing pm's Yes, getting issue #382 solved is quite urgent. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)
On Thu, Mar 2, 2017 at 8:32 PM, Matthew Hodgson <matt...@matrix.org> wrote: > We've finally set up a bridge hosted by matrix.org that links GIMPNet into > Matrix (as per the earlier bits of this thread). Heads up on a quite important issue: some private messages from IRC users to Matrix users are not delivered. The IRC user won’t get notified and so will never know the messages were lost. https://github.com/matrix-org/matrix-appservice-irc/issues/382 -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: irc.gimp.org is now available via Matrix (was: Re: Thoughs about communication)
On Thu, Mar 2, 2017 at 11:56 PM, Carlos Soriano via desktop-devel-list <desktop-devel-list@gnome.org> wrote: > I'm missing some rooms though, like #nautilus or #gnome-photos etc. Are they > on the bridge and the search is having problems to find them or are they out > for some reason? The bridge is for a whole network, not per room. The rooms that appear in the directory are just the ones for which at least one Matrix user already joined (so they are “known”). You can join any room as Matthew described with #_gimpnet_#ircchannelname:matrix.org -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughs about communication
On Fri, Feb 3, 2017 at 1:43 PM, Carlos Soriano via desktop-devel-list <desktop-devel-list@gnome.org> wrote: > Should we go ahead then? Sri, let's go with #gnome and #engagement for now? > If the bridge works out well, we can move more channels to it soon. As Matthew said: > There may be some confusion here about the dynamics of Matrix bridging. In > practice, when bridging to IRC, Matrix just acts as a big decentralised IRC > bouncer. It connects on a per-network, not a per-channel basis, and the > Matrix users who pop up on IRC look and feel like a normal IRC client > connection... because they are. It just happens to be that the client is > running on a Matrix/IRC bridge and syncing that user's history into Matrix > for them. So we don't have to/can't choose channels that are bridged. Not in a whitelist fashion. We can however mark specific channels as private (for those with sensitive discussions). Matthew, anything blocking the bridging on our side? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Summer of Code 2017 call for ideas
Hi, This is a reminder that we'd like to see potential mentors list ideas to the Untriaged section at https://wiki.gnome.org/Outreach/SummerOfCode/2017/Ideas On Tue, Jan 17, 2017 at 1:52 PM, Alexandre Franke <afra...@gnome.org> wrote: > * Discuss your ideas with designers in #gnome-design to get their > input and plan collaboration, especially if your ideas are related to > one of the core GNOME modules. If you are not sure who to speak to, > start with Allan Day (aday). > * Consider manageable ideas consisting of multiple smaller features > that share a common theme, in addition to single large feature ideas. > See the information for mentors page [3] for more on preferred project > formats and other mentoring resources. The GNOME Google Summer of Code Administrators -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughs about communication
On Fri, Jan 27, 2017 at 12:03 PM, Matthew Hodgson <matt...@matrix.org> wrote: > There may be some confusion here about the dynamics of Matrix bridging. In > practice, when bridging to IRC, Matrix just acts as a big decentralised IRC > bouncer. It connects on a per-network, not a per-channel basis, and the > Matrix users who pop up on IRC look and feel like a normal IRC client > connection... because they are. It just happens to be that the client is > running on a Matrix/IRC bridge and syncing that user's history into Matrix > for them. > > One can lock a bridge to a particular channel, but generally that's missing > the point. That raises the following concern: we have some channels which are semi-private. They are commonly used by well defined groups for sensitive conversation (that part I assume is not a problem as you could have an invitation only room or a similar protection) but from time to time people are temporarily invited to join those rooms to discuss a particular topic. In such a case, sending the guest any history is not desirable. Can Matrix handle this situation? -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughs about communication
On Thu, Jan 26, 2017 at 10:52 PM, Michael Catanzaro <mcatanz...@gnome.org> wrote: > It would be really awesome to have a GNOME Chat app based on Matrix. It would indeed. > Instead of implementing support for multiple protocols in the app, like > we did with Empathy, it would focus on doing one thing well -- Matrix, > both text and video chat (OK, two things) -- and then the quality of > the support for other protocols would depend on the quality of Matrix > bridges and would not be something the app has to worry about. Depend on the quality *and* existence. > Trying > to support 20 different protocols really took its toll on the Empathy > user experience. Requires manpower. Maybe someone will see this mail > and become interested. Maybe not. Agreed. I thought one of the arguments in favour of keeping Telepathy around was the support for some “uncommon” protocols that are not really supported elsewhere though? [0] One feature that Telepathy also brings, which I find really interesting, but which sadly hasn't really gained any traction, is tubes. Would it be interesting and feasible to extract/port that feature and ditch the rest of Telepathy? Another question your proposal raises is if, providing someone eventually volunteers to do the work, the GNOME Shell maintainers would accept patches to drop current Telepathy-tied chat integration and replace it with a Matrix-tied alternative. [0] One possible answer would maybe be that those networks don't have the critical mass required for us to spend our rare workforce on and that we expect third party (libpurple-based?) clients to take care of that market. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Summer of Code 2017 call for ideas
Dear GNOME hackers, It's that time of the year again: Google Summer of Code is approaching. We're updating our program pages [1] to have the latest information and we need your help in creating a list of great project ideas. It's essential that we have a well-prepared ideas page when GNOME applies as a mentoring organization by February 9th. So what should you do? Please visit the ideas page [2] and enter your project ideas under the "Untriaged Ideas" section. * Discuss your ideas with designers in #gnome-design to get their input and plan collaboration, especially if your ideas are related to one of the core GNOME modules. If you are not sure who to speak to, start with Allan Day (aday). * Consider manageable ideas consisting of multiple smaller features that share a common theme, in addition to single large feature ideas. See the information for mentors page [3] for more on preferred project formats and other mentoring resources. If you are interested in being a mentor this year or at any point find yourself drafted to be one, please join soc-mentors-list [4] to receive future communications about GNOME's participation in GSoC, including the information about important deadlines. The GNOME administrators for GSoC participation this year are Christophe Fergeau, Alexandre Franke, Ekaterina Gerasimova, Lasse Schuirmann, and Carlos Soriano. Cheers, The GNOME Google Summer of Code Administrators [1] https://wiki.gnome.org/Outreach/SummerOfCode [2] https://wiki.gnome.org/Outreach/SummerOfCode/2017/Ideas [3] https://wiki.gnome.org/Outreach/SummerOfCode/Mentors [4] https://mail.gnome.org/mailman/listinfo/soc-mentors-list -- Alexandre Franke GNOME Hacker & GSoC admin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughs about communication
On Fri, Jan 13, 2017 at 7:02 PM, Michael Catanzaro <mcatanz...@gnome.org> wrote: > The rest of your points are still valid, though. Sounds like they could > be resolved by improving the Matrix website (maybe needs a big "take me > to chat" button). The matrix.org homepage has two "Try Matrix Now!" links, one in the menu (second item) on top and one in the middle of the screen. The page that leads to has a selection of four clients for four platforms (command line, desktop/web, ios and Android) and only below that is there a more exhaustive list. Clicking on Riot links to a presentation page with a link to launch it directly. I think that's rather reasonable. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Maintainers & Bug Squash Month | November 2016
Hi! On Wed, Nov 2, 2016 at 8:02 PM, Alexandre Franke <afra...@gnome.org> wrote: > Your presence would be especially appreciated on the four Bug Days we > will be having [1] […] > [1] see full list of dates and read more about Bug Squash Month at > https://wiki.gnome.org/Initiatives/BugSquashMonth Just a reminder that today is one of those Bug Days. See you around on #bugs and bugzilla.gnome.org. -- Alexandre Franke GNOME Hacker & Foundation Director ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
GNOME Maintainers & Bug Squash Month | November 2016
Hi everyone, As some of you may have seen on foundation-list, we're starting a new initiative called Bug Squash Month, and it's launching now - November 2016! Alexandre (afranke) is the main organizer, so direct any questions to him. :) It would be particularly nice to get maintainers to help push Bug Squash Month. What we ask from you is that you try to give your bugtracker a special focus, even if that means writing a little less code for a month. Try to get rid of unreviewed patches. As maintainers, you're the ones who know the code base the best. Your understanding will help judge what reports are obsolete. We're sure there's a lot more you can do to get a clean slate for the coming month, so we'll leave other ideas up to you! We also invite you to help us welcome newcomers [0] and guide them. You can hang out with us at #bug and be on the lookout for questions. Your presence would be especially appreciated on the four Bug Days we will be having [1] (the first one is this Saturday, the 5th), but feel free to stay for the whole month, or even after that if you grow a special interest in clean bug trackers. ;-) Your efforts will get rewarded as you'll get new triagers who will be able to give you relief in the future. Feedback is always welcome, so email nuritzi [AT] or afranke [AT] gnome.org if you have any suggestions for improving this initiative in the future. Best, Nuritzi & Alexandre [0] newcomers here can be both people that aren't part of GNOME yet, and people who have contributed but don't know anything about bug triage yet [1] see full list of dates and read more about Bug Squash Month at https://wiki.gnome.org/Initiatives/BugSquashMonth ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Summer of Code 2016 call for ideas
Dear GNOME hackers, It's that time of the year again: Google Summer of Code is approaching. We've updated our program pages [1] to have the latest information and we need your help in creating a list of great project ideas. It's essential that we have a well-prepared ideas page when GNOME applies as a mentoring organization by next Friday, February . So what should you do? Please visit the ideas page [2] and enter your project ideas under the "Untriaged Ideas" section. * Discuss your ideas with designers in #gnome-design to get their input and plan collaboration, especially if your ideas are related to one of the core GNOME modules. If you are not sure who to speak to, start with Allan Day (aday). * Consider manageable ideas consisting of multiple smaller features that share a common theme, in addition to single large feature ideas. See the information for mentors page [3] for more on preferred project formats and other mentoring resources. If you are interested in being a mentor this year or at any point find yourself drafted to be one, please join soc-mentors-list [4] to receive future communications about GNOME's participation in GSoC, including the information about important deadlines. The GNOME administrators for GSoC participation this year are Christophe Fergeau, Alexandre Franke, Ekaterina Gerasimova, Lasse Schuirmann, and Carlos Soriano. Big thank you to Marina Zhurakhinskaya, who was an administrator for the last four years! Welcome to Carlos, a former intern and mentor! Cheers, The GNOME Google Summer of Code Administrators [1] https://wiki.gnome.org/Outreach/SummerOfCode/2016 [2] https://wiki.gnome.org/Outreach/SummerOfCode/2016/Ideas [3] https://live.gnome.org/Outreach/SummerOfCode/Mentors [4] https://mail.gnome.org/mailman/listinfo/soc-mentors-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Integrate ITS Tool with gettext and Autotools (Was: Re: Death of gnome-common)
On Sat, Oct 3, 2015 at 4:40 AM, Philip Chimento <philip.chime...@gmail.com> wrote: > For what it's worth, I break that rule for .pot files in my own projects, > because adding them to Git makes it easier for people who aren't comfortable > with the command line to contribute translations. Are you updating the pot file every time you change strings in your source code? This is not the recommended workflow for GNOME translation and you're giving bad habits to anyone you're pointing to this file. Damned lies provides an up to date pot file for all modules and ensures translations are never based on the wrong file. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changing gnome-love to newcomers
On Mon, Sep 7, 2015 at 4:25 PM, <liberfo...@freeside.fr> wrote: > "beginners" ? I prefer it over "newcommers" because you can still feel a > beginner in some areas even if you've been around for some time. That's the precise reason why we shouldn't use "beginners". If I'm a senior software engineer with 10 or 15 years of experience, but discovering Free Software or GNOME, I don't want to be called a beginner. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
On Mon, Apr 20, 2015 at 6:02 PM, Allan Day allanp...@gmail.com wrote: Sure thing - can you file a bug for that? I'm hoping to get some time for the HIG at some point this cycle. https://bugzilla.gnome.org/show_bug.cgi?id=748197 :) -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Hi, https://developer.gnome.org/hig/stable/writing-style.html.en has nothing on error messages. Can we have guidelines on what is preferred between Cannot…, Could not…, Failed to…, etc. for a bit more consistency? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus brake string freeze
On Wed, Mar 11, 2015 at 1:40 PM, Alexandre Franke alexandre.fra...@gmail.com wrote: So I guess you are now asking for a freeze exception. It would help if you gave us the actual strings and the number of strings added. 5 new strings: Action menu Open action menu Open view menu Search files View menu Given the importance for a11y, the ease for translating those and the fact that it's relatively early in the break, I give you i18n approval 1/2. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Nautilus brake string freeze
On Wed, Mar 11, 2015 at 1:07 PM, Carlos Soriano Sánchez carlos.sorian...@gmail.com wrote: Hi all, A11y people wanted https://bugzilla.gnome.org/show_bug.cgi?id=745967 fixed for 3.16, and I wanted that fix for the .90 I will do in a few hours. I fixed it, but also, I pushed without asking for string freeze break (I forgot about the string freeze). The commit is https://git.gnome.org/browse/nautilus/commit/?id=7afbac0a64f1734842ed64e333c9147de1cdbcd9 Sorry for that Hi, So I guess you are now asking for a freeze exception. It would help if you gave us the actual strings and the number of strings added. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Killing off UNCONFIRMED in Bugzilla
On Fri, Feb 13, 2015 at 4:51 PM, Olav Vitters o...@vitters.nl wrote: Action required: IF YOU WANT TO KEEP UNCONFIRMED FOR YOUR PRODUCT PLEASE SPEAK UP!! Please keep it for planner. BTW since 4.0 the new default workflow in bugzilla starts with UNCONFIRMED → CONFIRMED. This can be useful for those that keep UNCONFIRMED because sometimes reporters misinterpret NEW as not touched yet. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: OUTAGE: bugzilla.gnome.org, 09th February (09:00 CET) - 10th February (22:00 CET)
On Tue, Feb 10, 2015 at 9:29 AM, Oliver Propst oliver.pro...@gmail.com wrote: On Mon, Feb 9, 2015 at 11:50 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: I just want to thank everyone on the sysadmin team for this. This has been a long time coming and took quite amount of work due to the fact that we had a specialized bugzilla install. It's times like this is why having an expert sysadmin team is so important. We are _lucky_ to have such awesome ones. I've worked in a lot of environments, and I know what I speak of. Thanks again guys, you guys are the best! +1. Indeed. Now if we can maybe get someone to change the UI a bit on bugzilla that would be something... Yeah that would be awesome. As I already told Sri on IRC yesterday, if anything is wrong with our current bugzilla, you should start by filing bugs. Then we can start looking for solutions and someone to implement them. Otherwise we can't guess what you guys think the problem is. If it's not in bugzilla, it doesn't exist. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Commit auto-links in bugzilla comments
On Tue, Feb 10, 2015 at 9:56 AM, Olav Vitters o...@vitters.nl wrote: On Tue, Feb 10, 2015 at 08:38:39AM +0100, Milan Crha wrote: Is there a way to tell the comment parser that the commit itself belongs to another product than the one the bug is filled for? I could add support for something like: module $FOO commit $BAR Just as now you can do: comment 13 bug 163163 comment 13 First of all, I'd like to point that the bug report for this feature is still open at https://bugzilla.gnome.org/show_bug.cgi?id=559537 We started discussing the commit in another product issue there, so maybe we can continue there? I would also like to point out that pushed as abcd123, the default phrase used by git-bz, creates the same link as commit abcd123, which is also a nice feature. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: The GNOME Infrastructure is now powered by FreeIPA!
On Fri, Oct 10, 2014 at 10:57 PM, Sébastien Wilmet swil...@gnome.org wrote: On Tue, Oct 07, 2014 at 11:28:44AM +0200, Andrea Veri wrote: If you are interested in receiving or keeping using your people.gnome.org's webspace please mail accounts AT gnome DOT org stating so. Why not documenting how to access people.gnome.org on the wiki? So all people that already have a personal web space can keep using it. (I've asked for a people.gnome.org web space this monday, so of course I'm still interested in using it..). Now that we have an owncloud instance, there's an overlap. Is there still a good reason to keep using people.g.o instead of owncloud? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.14 Release Notes
On Mon, Sep 15, 2014 at 4:54 PM, Allan Day allanp...@gmail.com wrote: Sébastien Wilmet swil...@gnome.org wrote: Are there other important improvements in other libraries than GLib and GTK+? Because having a single item for GtkSourceView is not a good idea, in that case it's better to just talk about GLib and GTK+. Note that the release notes are now being translated by the localisation teams, so it's a bit difficult to make major changes. If it's just moving things around, it doesn't change anything for translators. If it's removing something, it's less work for those that haven't translated it yet (and not a real problem if it has already been translated). Also note that since technical stuff is more difficult to understand, it is usually translated last in the release notes as translators want to take the time to think about it. -- Alexandre Franke GNOME i18n coordinator ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Report (week 36)
On Fri, Sep 12, 2014 at 12:07 PM, Florian Müllner fmuell...@gnome.org wrote: On Fri, Sep 12, 2014 at 11:24 AM, Allan Day allanp...@gmail.com wrote: Some other potential blockers: https://bugzilla.gnome.org/show_bug.cgi?id=736542 - gnome-shell: Settings link missing from location submenu Trivial, but requires a string freeze break - it's fairly late for that, but I've asked anyway, let's see what happens :-) You just got our approval. :) -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String freeze break request for evolution-data-server (3.12)
On Tue, Sep 9, 2014 at 1:23 PM, David Woodhouse dw...@infradead.org wrote: I'd like to backport some fixes from Evolution master to 3.12 which fix GSSAPI HTTP authentication and error reporting¹. Previously, if we were unable to translate an error number into a string we would end up with an untranslated message of the form 'Unknown error code' or 'Unknown code %d' from libcom_err. Now the code is fixed, we end up handling the lookup failure in EDS, and report it slightly more coherently as _((Unknown GSSAPI mechanism code: %x)) So we have a new untranslated string... in place of a string which was previously not only untranslated but untranslatable. In a case that should hopefully never happen now that we're actually looking up the error codes the right way, and where the message text wasn't giving the user much information anyway (only the number might *possibly* be helpful. On the whole, I'm not going to lose sleep over it being untranslated :) 1/2 from i18n. -- Alexandre Franke ___ 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 (week 33)
Hi, I'd like to add the following bugs: https://bugzilla.gnome.org/show_bug.cgi?id=735370 https://bugzilla.gnome.org/show_bug.cgi?id=664093 -- Alexandre Franke GNOME i18n coordinator ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Screenshot automation BoF at GUADEC
On Tue, Aug 19, 2014 at 2:32 PM, Stefan Sauer enso...@hora-obscura.de wrote: FYI: I take screenshots from my test suite in buzztrax. I have some code there to also add labels to UI components, to aid references in the docs: Thanks for your input. https://plus.google.com/117815039340859210765/posts/RLm51oVWjPn This link gives me an error. :( -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Screenshot automation BoF at GUADEC
On Fri, Aug 1, 2014 at 10:10 PM, scl scl.gp...@gmail.com wrote: Hi, Hi, I develop, document and translate in GIMP and like to know more about this topic. Can you already tell me about results of your BoF session at GUADEC, please? We took notes, they are at: https://wiki.gnome.org/GUADEC/2014/BOFs/ScreenshotAutomation -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Screenshot automation BoF at GUADEC
On Wed, Jul 16, 2014 at 11:02 AM, u u...@451f.org wrote: Will there be video streams, recordings, reports from this BoF? I'd be interesting in watching/reading at least :) At a minimum there will be notes/report on the wiki page. Stream is highly unlikely. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Screenshot automation BoF at GUADEC
On Wed, Jul 16, 2014 at 10:54 AM, Vadim Rutkovsky vrutk...@redhat.com wrote: That seems to be a feasible task using existing tools we use for UI automation, I would really love to join the BoF. CC'ing folks from GNOME QA team. We'd be very happy to have you. Please add yourself to https://wiki.gnome.org/GUADEC/2014/BOFs/ScreenshotAutomation (with potential constraints such as other BOFs you have to attend, or leaving date and time if you plan on departing early). -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Screenshot automation BoF at GUADEC
Hi, It's 2014 and translators and documentation writers still have to spend a lot of time to manually create screenshots. There must be a better way. Therefore I'm planning a half-day BoF on this topic at GUADEC. This is relevant to you if you're a translator or writer, but we also hope people with experience in automated UI testing will show up to give us a hand. If you're thinking of attending, please add yourself to https://wiki.gnome.org/GUADEC/2014/BOFs/ScreenshotAutomation Cheers. -- Alexandre Franke I18n coordinator French translation team coordinator ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Development Question
On Sat, Feb 8, 2014 at 3:34 AM, Sriram Ramkrishna s...@ramkrishna.me wrote: I suggest you contact the folks at Zareason who have been also been making laptops and desktops specifically for GNU/Linux. I agree with Sri and also suggest you watch the keynote their CEO gave at GUADEC 2013: http://videos.guadec.org/2013/Keynote:%20Kathy%20Malmrose/ -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.12 feature: polari
On Fri, Oct 11, 2013 at 11:21 AM, David Woodhouse dw...@infradead.org wrote: So this would be a replacement for Empathy? Only for multi user chatrooms. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.9.91 release
On Thu, Sep 5, 2013 at 6:48 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Thu, Sep 5, 2013 at 11:10 AM, Michael Catanzaro mcatanz...@gnome.org wrote: Regarding (translatable) appdata.xml files for GNOME Software -- do we need to actually apply for a freeze exception to add these, or is notifying the lists sufficient? These are string additions, and on top of that, for strings that don't show up in the application UI. So yes, a notification to gnome-i...@gnome.org should be sufficient. I'm not sure this is correct. My understanding of the current String freeze policy is that: * marking a previously existing but not yet marked string for translation is ok and doesn't require permission (but announcing it on the i18n list is appreciated); * adding strings, such as the ones for AppData, however requires an exception and so you should get approval from the i18n team. See https://wiki.gnome.org/TranslationProject/HandlingStringFreezes It would be great if someone from i18n could clarify this. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, Aug 15, 2013 at 11:26 AM, אנטולי קרסנר fr33domlo...@mailoo.org wrote: Hello, Hi, Examples: […] SourceForge SourceForge is actually free software now. See http://en.wikipedia.org/wiki/SourceForge#Apache_relicense (Certainly the popularity of GitHub is not the reason you chose it I guess, just like the popularity of Windows doesn't make us focus on Windows support, and the popularity of Skype doesn't make us focus on As you can see in Alberto's answer, it is indeed just a question of popularity and I agree with you that this is a sad thing. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, Aug 15, 2013 at 11:49 AM, Alberto Ruiz ar...@gnome.org wrote: We should pick our fights, on the other hand, GitHub has released more open source code and tools than the gitorious community. We accept money from Google for the GSoC's every year and I see no complaints. Everything is a matter on how you look at things really. I agree that everyone should be free to pick their fights. I agree that you you are free to pick yours and have them different from mine. Do you agree that mine can be different from yours? As I mentioned before, if you want a gitorious mirror, feel free to start working on it, I fully support the idea, I'm just not interested in investing the time on it myself because I see no much value in it (on the other hand, I see the value on running our own instance). I really don't care much about my code being mirrored anywhere. At least gitorious would be ethically acceptable, so it wouldn't bother me, but I won't invest time in this. I see the value of this as a backup though, so if others want to work on this I say that's a good thing. Anyway this is really not what was the most important point to me in my previous email and you didn't answer the question I really cared about, so I'm asking again: is there a way for maintainers to opt out of the github mirroring? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, Aug 15, 2013 at 12:16 PM, Debarshi Ray rishi...@lostca.se wrote: Speaking as someone who has a Gitorious account and not a GitHub one, what will you gain by opting out? It won't stop someone from cloning your code on GitHub. This way you atleast have a canonical tree on GitHub where you can see what people are doing with your stuff. I agree that people are free to take code and copy it there. This doesn't mean that we should make it easy for them. Actually, the fact that we have to ask to opt out is an issue in itself. We shouldn't even have to. This should have been opt in from the start. People (maintainers and commiters in this case) shouldn't have to fight to get back what you have taken away from them. Basically, I don't think that choosing to opt-out is strong enough message even on ethical grounds. What you're saying is basically that if someone's fight is not worth fighting, we shouldn't let them fight it. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, Aug 15, 2013 at 12:44 PM, Emmanuele Bassi eba...@gmail.com wrote: I thought that making it easy for them to take the code and copy it was the entire point of using a distributed version control system. actually, I was pretty sure that this was the whole point of having free access to the software source code in the first place. I have nothing against free access to the source code. git.gnome.org already ensures that. As I said earlier, if someone wants to clone a module to work on it and have their clone on github because that's where they chose to host it to share their work, fine by me. This is already possible without the GNOME mirror. This doesn't mean I have to endorse it, or approve a move towards it. considering that this is a mirroring system of a distributed version control system, I'm puzzled as to what has been lost. you still have all your rights to the software you maintain and commit to, and you still have the right to push your work to more than one repository. care to elaborate a bit more on this? Frankly, I am not really motivated to elaborate more. As you can see from this thread, people disagree with this action, which has been taken in their name (as they are GNOME foundation members, GNOME module maintainers and GNOME committers). It should be possible for them not to have their name associated with it, whatever their reasons are, and without having to justify themselves. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcing GNOME's official GitHub mirror
On Thu, Aug 15, 2013 at 1:39 PM, Andre Klapper ak...@gmx.net wrote: On Thu, 2013-08-15 at 12:07 +0200, Alexandre Franke wrote: I really don't care much about my code being mirrored anywhere. If you don't care much about your code being mirrored, it probably means that Can maintainers opt out? is a theoretical question. Or even a non-existing problem (so far). Ok, I probably misphrased that since English is not my native language. What I meant is that my code being mirrored is not something I want to push for, it's not something I consider as needed. That was an explanation for the fact that I won't be contributing to a gitorious mirror. That didn't mean that having the github mirror is a non-issue to me. I hope this makes my opinion clearer. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PyGTK again (was: Apologize and to take PyGTK)
On Thu, Apr 4, 2013 at 10:02 PM, Germán Póo-Caamaño g...@gnome.org wrote: On Thu, 2013-04-04 at 15:52 -0400, Mike wrote: Hi I'm glad to see both side of you calm down . I feel that this could be a typical misunderstanding between users, package maintainers and the upstream developers. Could we do anything about this? I suggest we could setup a activity graph for each modules in the git repository. So people could see how active or inactive is a project before or after they report a bug. This could also be helpful to track inactive/dead projects for release management. Maybe you mean something like blip. http://blip.blip-monitor.com/ (or a specific view of blip). While it is a closed source web service, https://www.ohloh.net/ can come in handy too. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Use of accelerators (mnemonics) in app menus
Hi, With the GMenu transition happening during the 3.5 cycle, we have seen many applications remove their accelerators (that _ characters that allows you to select a menu item using the alt key) from the menu items that were moved to the app menu (the menu you get when clicking the application name in the top bar in GNOME Shell). The reason behind such removals seems to be that GNOME Shell doesn't display nor enable accelerators in the app menu. However, in other environments, the app menu is consolidated and displayed in the menu bar of the window as the first item. In this context, the accelerators could be very useful and losing them should be considered a regression. Is there a technical reason that pushes removal of the accelerators, such as a bad GNOME Shell behaviour when they are present? Will GNOME Shell use accelerators in app menus someday? That may be seen as an accessibility feature. Is there by the way a keyboard shortcut to open the app menu? What's even more confusing to us is that while some modules got rid of these accelerators, some others did not. We thus think that there's no technical barrier to have them and we'd like to have some consistency. Can we push module maintainers to have accelerators in their app menu? Regards. -- Alexandre Franke On behalf of the i18n team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing widgets between GNOME 3 applications
Hi, On Mon, May 7, 2012 at 3:45 PM, Debarshi Ray rishi...@lostca.se wrote: The newly designed (or redesigned) GNOME 3 applications have some common UI elements. For example, if you look at the following designs, you will notice that the main toolbar, selection toolbar, main icon view, etc. are quite similar: Sorry for being so naive but why couldn't this be part of GTK+? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Totem - Videos
On Tue, Apr 24, 2012 at 4:33 AM, Alberto Ruiz ar...@gnome.org wrote: If you ask me, I think torrents should be integrated in the browser, no other browser implements this and would make the torrent downloading experience much more transparent to the user. After that you get the same workflow as any other downloaded file. Except that for torrents you want to handle extra stuff such as upload speed limit and sharing ratio. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone using UNCONFIRMED in Bugzilla?
On Tue, Dec 27, 2011 at 3:57 PM, Olav Vitters o...@vitters.nl wrote: Are you using it yes or no? I am. Please don't kill it. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011
On Sun, Jul 31, 2011 at 6:11 PM, Felipe Contreras felipe.contre...@gmail.com wrote: === 07. Does GNOME include code or documentation by you? === (single choice) * Yes * No … or translations, or artwork… maybe even other forms of contributions I can't think of at the moment? Maybe this should be made more generic? -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: help needed for a prototype
On Mon, Aug 2, 2010 at 9:57 PM, Urs Lerch m...@ulerch.net wrote: Hi all Hi, Currently I'm thinking of a possibility to use the desktop as a reflection of my thoughts and work instead of a simple background image with bookmarks on it. Have you seen http://lucasr.org/2010/07/24/introducing-the-board/ ? Therefore I would like to display these items in a semantic network directly on my desktop. It would also function as dashboard and central control panel, where I can start applications and open files, always in the context of a project and not in a global menu or file hierarchy. The backend software I would use for this is called DeepaMehta (http://www.deepamehta.de), but that's only my personal preference as a knowledge worker. Have you also seen Zeitgeist and GNOME Activity Journal? They're not exactly what you describe but I think it's on the same track. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
