Re: Is libgd still a thing?
On Tue, 2021-06-15 at 14:58 +0500, Alexander Mikhaylenko via desktop- devel-list wrote: > As far as I know, libgd is pretty much only used for tagged entries > nowadays. In GTK4 it's a lot easier to implement them in-tree than it > was in GTK3, gtk4-demo even has an example. It doesn't take very long to see that this isn't the case. tagged-entry and main-view: https://gitlab.gnome.org/GNOME/nautilus/-/blob/master/meson.build#L98-105 gd-two-lines-renderer as a cut'n'paste: https://gitlab.gnome.org/GNOME/evince/-/tree/master/cut-n-paste/libgd tagged-entry, main-view and icon-view: https://gitlab.gnome.org/GNOME/totem/-/blob/master/meson.build#L147-155 tagged-entry, main-box and icon-view: https://gitlab.gnome.org/GNOME/gnome-photos/-/blob/master/meson.build#L143-152 main-view, notification, and tagged-entry: https://gitlab.gnome.org/GNOME/gnome-books/-/blob/master/meson.build#L84-96 https://gitlab.gnome.org/GNOME/gnome-documents/-/blob/master/meson.build#L90-102 (gnome-music doesn't use libgd anymore, the version in Debian still does) The only 2 modules that just use the tagged-entry: https://gitlab.gnome.org/GNOME/gedit/-/blob/master/meson.build#L32-38 https://gitlab.gnome.org/GNOME/recipes/-/blob/master/meson.build#L13-17 > > On 15/06/2021 14:54, Allan Day wrote: > > Emmanuele Bassi via desktop-devel-list < > > desktop-devel-list@gnome.org> wrote: > > ... > > > - nautilus > > > - evince > > > - totem > > > - gnome-photos > > > - gedit > > In terms of the platform, we're working to consolidate around > > libhandy/libadwaita. That's what the new HIG documents, and is what > > we're trying to constrain ourselves to on the design side. So it > > would > > be interesting to know what these apps are using libgd for, and > > potentially track what needs to be done to migrate them away from it. > > I think that it would be beneficial to have our core apps use the > > same > > platform that we make available to 3rd parties. > > > > > > Allan > > ___ > > desktop-devel-list mailing list > > desktop-devel-list@gnome.org > > https://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is libgd still a thing?
On Tue, 2021-06-15 at 12:13 +0200, Felipe Borges wrote: > Evince bundles the whole libgd just so it can consume a two line cell > renderer for its icon view. In this case, it might be worth just > copy-pasting this specific class and drop the libgd dependency. It never bundled the whole libgd, and doesn't consume it as a subproject either: https://gitlab.gnome.org/GNOME/evince/-/tree/master/cut-n-paste/libgd ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Is libgd still a thing?
On Mon, 2021-06-14 at 18:18 +0200, Andre Klapper via desktop-devel-list
wrote:
> https://gitlab.gnome.org/GNOME/libgd/commits/master hasn't seen changes
> for 30 months. Emails to both maintainer addresses listed in the DOAP
> file ({cosimoc|malureau}@gnome.org) bounced.
Still used:
https://codesearch.debian.net/search?q=gd-main-view.h=1=1=1
> Context: Wondering whether to archive; coming from Bugzilla migration.
>
> Thanks,
> andre
> --
> Andre Klapper | ak...@gmx.net
> https://blogs.gnome.org/aklapper/
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Help needed in libgtop maintainership
Hey Robert, On Sat, 2021-03-13 at 20:52 +0200, Roth Robert via desktop-devel-list wrote: > Hi everyone, > > this mail is a bit long overdue, but better late than never: > libgtop, the library used for "system monitoring" we use in System > Monitor and Usage is in need of help. > > Due to my lack of knowledge on library development, cross-platform > support, and other related topics, which would be welcome for > development of a library like libgtop, I would like to request help in > taking over the (co-)maintainership of the libgtop module from me, as > in my hands, the library is dying, and not even seeing the regular > releases it would need. > > As for the current state, the other maintainer, even though with a lot > more knowledge on the library, is rarely available. As a result of > this, since the migration to gitlab the merge requests are piling up, > and even though I could superficially review them, but based on > previous experiences I tend to miss things which lead to bad > consequences, like build failures, needing reverts of merges. > > As for the library itself, it is pretty stable, issues reported are > usually for new features, the merge requests are usually either minor > system-specific bugfixes or completely new features implemented by > passing-by contributors, so the amount of work would not be too high to > keep the library alive (even that would be more what I feel I am able > to do at this point). Of course, if you are brave and creative enough, > there is a lot more work to be done than reviewing and releasing. > > Please let me know if you are interested, and I will do my best to help > you out starting on the journey. I'm not certain that this mail is going to have volunteers flooding your mailbox, and I'm not volunteering myself, but I can certainly give advice on some ways to easing the burden. 1) Add a CI to your project Gitlab makes it super easy to add CI to your project, and you don't even have to bother maintaining the CI runners yourself. Imagine you're running a script on a Fedora or Ubuntu machine that just got installed, install the packages you need, and run the build. This is one of the simplest CI definition example you can use to get started: https://gitlab.freedesktop.org/hadess/rio500/blob/master/.gitlab-ci.yml This should at least make sure that all the contributions folks make can build (on one system). 2) It's a library, add an ABI checker A library is really harder to maintain than an application, because you don't control all the users of that library, and when things change, you could be breaking any and all users of that library. check-abi uses abidiff to make it easier to avoid introducing unintended ABI changes in merge requests: https://gitlab.freedesktop.org/hadess/check-abi This is a short example of using it: https://gitlab.gnome.org/GNOME/totem-pl-parser/blob/master/.gitlab-ci.yml#L24-27 3) Write tests And ask contributors to do so as well. Presumably you started helping with libgtop's maintenance because you worked on something that used it, this should give you a good idea of what would be good tests to make sure that your application doesn't completely break down. If the library needs to have fake devices, you can use umockdev: https://github.com/martinpitt/umockdev either in C tests like in libgudev or Python like in gnome-settings- daemon (and plenty of others) to create those fake devices. If the library needs a D-Bus service running, you can https://github.com/martinpitt/python-dbusmock to create those services inside a sandbox. Don't forget to actually _run_ the tests in the CI file. You'd be surprised how often this happens (usually to me, and before my 3rd coffee). Hope this helps get you started on being a module shepherd. A shepherd because, in the end, you don't need to know everything, and this will actually help you ask, and have contributors answer questions like: - why are you making this change? and: - why does this functionality need to be in this library? Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Can we enforce beta release for the freeze
On Sat, 2021-02-27 at 10:26 -0800, Philip Chimento via desktop-devel- list wrote: > On Tue, Feb 23, 2021 at 5:54 AM Emmanuele Bassi via desktop-devel-list > wrote: > > The release team can do "non maintainer" releases, of course; the > > problem is, of course, that maintainers can be *very* protective of > > their fiefdoms, so the release team has to wait for either being > > explicitly asked to do a release, or for an answer from maintainers > > as to whether they'll be able to do a release. We *cannot* have it > > both ways: either the release team can take over your project for a > > specific task—do a release, keep the build running—or we have to wait > > until we get an answer from the maintainer. > > The ideas about automating releases mentioned elsewhere in the thread > sound like great time-savers, but I primarily came here to add to what > Emmanuele said: I'd be quite happy for the release team to have the > power to take over releasing my module if I forget, but I've seen some > astonishing vitriol directed at the release team on this very mailing > list when they have done similar things in the past. > > I wouldn't blame them if they didn't even want to get near this topic. > > As a community, if we weight the autonomy of maintainers so heavily > that we're willing to tolerate mailing list flames about it, then we > don't also get to complain when nobody steps in to help with > maintainers' tasks. I'm pretty sure that most of us, myself included, wouldn't mind, as long as the job was done to a standard. It's like giving your mate a key to your place so they can do laundry while you're away. You don't expect them to have flooded the place when you get back. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
On Thu, 2021-01-14 at 12:16 +0100, Jonas Ådahl wrote: > > FWIW, mutter and gnome-shell (and others too I suspect) only allow > maintainers to merge to master (due to a lack of better granularity > in > the community edition of GitLab), but that is primarily due to us > using > marge-bot, so while anynone from the release team that isn't listed > in > the doap file as a maintainer won't be able to merge, they would be > able > to assign their build fix merge requets to marge-bot to have merged. But anyone can still push directly to non-wip branches, because that's how translations are still pushed, right? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
On Thu, 2021-01-14 at 12:08 +0100, Benjamin Berg wrote: > On Thu, 2021-01-14 at 12:06 +0100, Bastien Nocera wrote: > > This is likely a migration problem, as the project was originally > > in > > Jonas' personal namespace, right? All the projects under the GNOME > > namespace should have the same settings allowing anyone in the > > project to commit anything and merge anywhere, for better or for > > worse... > > Not quite. Everyone listed in the .doap file is a "Maintainer", while > everyone else is a "Developer". So you can just change the protection > o > the master branch to only allow everyone in the "Maintainer" group to > merge. This will prevent everyone who is not listed in the .doap file > from merging. I know that screen well. I'm saying that the settings were likely in that position because the module was migrated from a personal namespace. That's not how modules are setup by default in the GNOME namespace. (Or Jonas changed them, obviously :) > But, that in turn isn't really compatible with the idea that the > Relase > Team is the one who should always be able to handle emergencies in > case > a maintainer is not available at the time. So, they kind of need to > have the Maintainer permissions in order to always be able to step > in, > even if projects have configured branch protections. There are many ways to workaround or fix this (as mentioned in my previous email) without allowing implicitly or explicitly the release team to commit directly to the main development branches, so I don't see why we would need to make an exception for that case. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
On Thu, 2021-01-14 at 11:57 +0100, Benjamin Berg wrote: > On Wed, 2021-01-13 at 15:57 -0600, Michael Catanzaro wrote: > On Wed, Jan 13, 2021 at 9:28 pm, Philip Withnall > wrote: > > Given that you’ve just committed to submitting MRs and waiting for > > CI > > to pass, rather than pushing directly to master, perhaps this rule > > should be rethought? > > Hm... as long as we have permission to merge the MR after CI has > passed, or to bypass the CI if it's broken due to a preexisting > issue, > then we should be good. However, I'm not sure GitLab allows this? > E.g. we discovered yesterday that I didn't have permission to commit > to > gnome-remote-desktop until Jonas played with the settings; there, I > had > created a MR, but only project maintainers were able to merge it. This is likely a migration problem, as the project was originally in Jonas' personal namespace, right? All the projects under the GNOME namespace should have the same settings allowing anyone in the project to commit anything and merge anywhere, for better or for worse... > I think, to do this you would effectively need to add the release > team > with Maintainer privileges to all projects (or, I suppose have a > Release Team account for this purpose). > > I suppose that should be pretty simple to hook into the .doap > synchronisation. Not sure how people people feel about having the > Release team marked as a maintainer everywhere. > > > Note that I am not really concerned about anyone merging a branch > even > if CI is failing without having a good reason to do so. > > Benjamin > > The worst-case scenario would be: need to revert a commit, CI is > already broken due to some preexisting unrelated issue that we don't > know how to fix, can't land revert via MR because it requires CI to > pass, can't change the setting to allow bypassing CI because the only > way to get permission to change the setting is to update the doap, > can't update the doap without first passing CI Or file issue, pin version of broken module in your build scripts, wait until maintainer is available to fix everything. Or create a branch (and an MR) and point your build scripts at the branch. Or ask the sysadmins to verify the module's permissions. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
On Wed, 2021-01-13 at 15:15 -0600, Michael Catanzaro wrote: > > On Wed, Jan 13, 2021 at 7:53 pm, Bastien Nocera > wrote: > > "I need to remember not to [push commits directly to the main > branch] > > for your modules, sorry" > > I was trying to be sincere, not dismissive: > > mcatanzaro: "I need to remember not to for your modules, sorry" > "Can hardly complain about people not following dependency rules when > I > can't remember simple things like this myself" > > After that discussion, I then proceeded to land a broken commit in > gnome-calendar, at which point I no longer had a leg to stand on. > That's when I said I would use MRs for all modules, not only yours: > > https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/156 > > It's a little more work, but you're right that it's a good idea and > best-practice. I had hoped that concession would deescalate this > situation. Clearly not. I don't think you quite understand just how much trust was lost when a member of the release team can't follow the goals we set ourselves as a project. You broke that trust, then bumbled into breaking it again, fixed the code, but never actually cleaned up after yourself (see below). There's no putting back together that broken trust. And I'm likely not going to be able to trust the release-team's work until there's a technical means to avoid the sort of breach of trust that just happened. There was nothing to deescalate, it was already too late. > > It was still needed. There were 8 modules that needed to have > their > > compatibility checked, for which I filed individual issues. > > > > The vapi fix wasn't going to be enough to fix the other 7 modules, > and > > waiting for those fixes to roll in could have happened in a branch > for > > gnome-build-meta, with that module's CI making sure that all the > ducks > > were in a row, and each fix actually peer-reviewed (or at least CI > > checked). > > Bastien, how could I know about any of this? You didn't need to. libgweather has NO API GUARANTEES. You should be using tarballs or specific git commits for it. > If you wanted to do a planned transition, you could have told us in > advance so we could coordinate on how to do it. We might have created > a > libgweather compatibility element with the old API version, for > example, and switched dependencies to use that ahead of time. > Instead, > you got an uncoordinated emergency response where you had no control > over the resolution. Fortunately, Calendar was the only core app that > required changes. libgweather still has no ABI/API guarantees. > > Other developers' work is blocked until GNOME is building again, You could have pinned libgweather's version, as I keep saying. > so we > can't just wait for you to come online to sort things out. You barely mentioned me on IRC during my evening. You didn't file issues, you didn't file MRs that I could have reviewed or seen. > This delayed > a WebKit update, for example. Nowadays GNOME consists of hundreds of > interconnected components, and we can't afford to have fiefdoms when > the build is broken. Maybe you should figure out what to do with libraries that have no API or ABI guarantees of any sort that core modules rely on. I tried to do my best pushing all the API and ABI breaking changes in a single release to minimise breakage, and not have to come back to modules to make changes _again_. That took 3 full days of work. I'm sorry that broke your module, but you had better options than do what we tell new contributors to not do and commit directly to the main development branch. libgweather still has no regression tests for the problem you fixed, and the build log mentioned in the commit message will likely be removed in a couple of weeks when we run out of storage. And I'm not going to spend the time cleaning up after the release-team. > This is disappointing. If you restrict commits, please let release > team > know, because we have a rule that we only build modules from git > master > if we can commit to them to fix build failures. You know we can't restrict commits to the master branch, right? Translations won't be able to be committed if we do that. In any case, there's no point in further rehashing what happened. I'm not going to work on libgweather until somebody does the work to allow blocking commits to branches without breaking our translation tool, so somebody should make sure that the work I mentioned gets done if you want weather to still work in GNOME 40. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
On Wed, 2021-01-13 at 10:06 -0600, Michael Catanzaro wrote: > Hi, > > Yesterday, after I committed the typo to Calendar, I promised to use > merge requests from now on when committing build fixes. Previously, I > had promised to do this only for your projects, but yesterday I > forgot, > and not for the first time. I understand that's frustrating. From now > on, I'll use MRs for all projects that use CI. I had already promised > this in [1] in hopes of smoothing things over with you, but I see > that > didn't work. I had also attempted to apologize via IRC. "I need to remember not to [push commits directly to the main branch] for your modules, sorry" > You are right > about the importance of MRs. > > I actually did at first temporarily switch libgweather.bst to use a > 3.36 release tarball when I didn't see any easy way to fix your vapi > file [2]. This turned out to not be needed because, with some help It was still needed. There were 8 modules that needed to have their compatibility checked, for which I filed individual issues. The vapi fix wasn't going to be enough to fix the other 7 modules, and waiting for those fixes to roll in could have happened in a branch for gnome-build-meta, with that module's CI making sure that all the ducks were in a row, and each fix actually peer-reviewed (or at least CI checked). > > I hope you'll reconsider your decision to drop libgweather over this. This isn't what made me drop libgweather. This was the last straw. What started it was this commit which you pushed directly to the main branch, and claimed that building was broken for weeks. It was broken for a couple of hours: https://gitlab.gnome.org/GNOME/grilo-plugins/-/commit/4329dda2c53f9a7bd2a3f6dd9334d4eb5207e9fd And similar behaviour over the years where you seemed to be under the impression that I was the only person in GNOME that felt that peer- reviewed patches and CI-gated merge requests were a requirement. Until the main development branch is protected and it's not possible to push directly there, I don't see myself being interested in contributing to modules where I filled the maintainer gap. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
(I tried to send this to the release-team@ alias/mailing-list, but that was shuttered last August, so seeing as it would be public on discourse anyway) On Tue, 2021-01-12 at 09:31 -0600, Michael Catanzaro wrote: > Hi developers, > > Please remember that action is required when updating your > dependencies > or build options. You need to either make sure gnome-build-meta is OK > with your changes, or ask release team to investigate on your behalf. > > We've had at least four separate breakages from four separate > projects > in the past few days. This is too much. Please be careful. Thanks! FYI, one of those breakages was a number of smaller API and ABI changes in libgweather that I tried to bundle up together to minimise breakage. I tried to my best to document all the API changes in the NEWS file when doing a release. And I filed issues against each one of the libgweather users in GNOME: https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/288 https://gitlab.gnome.org/GNOME/evolution/-/issues/1320 https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/584 https://gitlab.gnome.org/GNOME/gnome-weather/-/issues/141 https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/682 https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/170 https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/119 https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3577 https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1565 There were bugs, there usually are, and it broke gnome-build-meta. This shouldn't have been a problem because: 1) libgweather doesn't have any ABI or API guarantees, even if it tries to avoid them (GWEATHER_I_KNOW_THIS_IS_UNSTABLE) 2) it was a one-line fix in gnome-build-meta to pin libgweather to an older version until all the above bugs (or the applicable ones) were fixed. Instead we have commits bypassing the CI pipelines _and_ reviews, which lack any sort of details about the bugs and point to build logs which will vanish when storage is needed, and don't follow the commit message style of the individual applications. Cancelled pipeline runs because you realise too late that it will fail anyway: https://gitlab.gnome.org/GNOME/libgweather/-/commits/master/ Commits that weren't even compile-tested locally: https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/156 I get that there might be a thrill to being a build sheriff, but if you're going to commit directly to master without reviews or CI checks, you need to be absolutely 100% spotless. This is an example of a perfect commit, which passed the CI, followed the existing commit style, and was reviewed and merged within 20 minutes: https://gitlab.gnome.org/GNOME/libgweather/-/merge_requests/93 All that to say that I'm not going to work on libgweather anymore. Make sure to get those fixed urgently if you want weather to carry on working in GNOME 40: https://gitlab.gnome.org/GNOME/libgweather/-/issues/67 https://gitlab.gnome.org/GNOME/libgweather/-/issues/70 Bye ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reminder: action required when updating dependencies or build options
On Tue, 2021-01-12 at 16:50 +, Philip Withnall wrote: > On Tue, 2021-01-12 at 09:31 -0600, Michael Catanzaro wrote: > > Hi developers, > > > > Please remember that action is required when updating your > > dependencies > > or build options. You need to either make sure gnome-build-meta is > > OK > > with your changes, or ask release team to investigate on your > > behalf. > > > > We've had at least four separate breakages from four separate > > projects > > in the past few days. This is too much. Please be careful. Thanks! > > Sorry to have caused one of those breakages. I think this is going to > keep happening, though, since remembering to ping an external party > when dependencies change is hard. It’s something that happens > infrequently, and is not part of people’s normal > code/compile/review/merge cycle, so it’s not surprising they forget. > > Perhaps there’s scope for a CI bot which reminds developers to look > at > updating gnome-build-meta whenever a meson.build is changed. That bot > could be set up for every project which is listed in gnome-build- > meta. > > Or, if it’s appropriate, the bot could file an issue against gnome- > build-meta and assign the developer who’s touching meson.build to > that > issue. Or something. The same problems that existed in 2019 still exist: https://mail.gnome.org/archives/desktop-devel-list/2019-September/msg00014.html Developers still have no visibility over the gnome-build-meta builds. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound Juicer support and/or EoL
On Tue, 2019-12-03 at 20:48 -0500, Link Dupont wrote: > I completely agree with these sentiments. It's a valuable piece of > software that should not be abandoned. I volunteer to take on > maintainership of it. I've never been a module owner, but this > sounds > like a great opportunity to become one. The upcoming 3.38 release would be a great time to release Dave Meikle's work on removing the use of the app menu :) I've also submitted sound-juicer to be added to Flathub so let me know if you want maintainership there as well: https://github.com/flathub/flathub/pull/1806 Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME group membership expired
On Wed, 2020-07-29 at 10:56 -0500, Michael Catanzaro wrote: > Hi, this is now fixed. > > But somehow, my GitLab notification settings got reset and I've been > missing mails. Be careful! Check your notification settings for the > projects you care about. I filed: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/400 because I just can't remember all the watches I had setup. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Mon, 2019-05-06 at 21:13 +0200, Frederic Peters wrote: > Bastien Nocera wrote: > > > - How? > > > > It is possible to rename the "master" branch in git. It's also > > possible > > to add a "link" of sorts so that software that specifically > > references > > "master" can be made to work with the new name[5]. > > I checked and there is an hardcoded reference (git) master (branch) > in > library-web; while other GNOME changes did destroy much of library- > web > (meson without alternative way to get gtk-doc HTML files), it would > still be nice to have the compatibility link (or for someone to step > up and adapt library-web). > > And looking at it now, jhbuild, too, has references to the branch. This should fix one instance of it: https://gitlab.gnome.org/GNOME/jhbuild/-/merge_requests/84 I haven't looked at library-web because I have a whole bunch of work that I'd need to do with it, but not the bandwidth... > > > cheers, > Fred > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
Doing some thread grave digging. On Sat, 2019-05-04 at 15:18 +0200, Bastien Nocera wrote: > On Sat, 2019-05-04 at 12:32 +0200, drago01 via desktop-devel-list > wrote: > > https://dictionary.cambridge.org/amp/english/master > > > > Master / slave relation is just one of the possible meanings but > > not > > in the context of master copy > > > > "an original version of something from which copies can be made:" > > .. > > > > this has no connection with slavery at all. > > Reference needed. You don't know where it comes from, and you're not > even trying to find where "master copy" takes its name from. > > > Words have meanings based on context - trying to make a connection > > to slavery where is none nor any intent to do so is actually > > disrespectful to whomever named the default branch "master". > > First appearance of "master" in git is in a CVS helper script[1]: > https://github.com/git/git/commit/3e91311ae750af9bf2e3517b1e701288ac3066b9 > > Why is that branch called master? Probably because BitKeeper uses > "master" for its main branch: > http://www.bitkeeper.org/tips.html#_how_do_i_rebase_my_work_on_top_of_a_different_changeset > > But maybe this "master" isn't the same one that's in "master/slave"? > See the documentation about > master/slave repositories: > https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L223 > > But repositories and branches aren't the same! They are in BitKeeper: > https://users.bitkeeper.org/t/branching-with-bk/158/2 > > So, yes, the "git master" branch probably isn't even a "master copy" > reference, but a straight up master/slave reference. > > Did I get anything wrong there? A year later, and it turns out I was wrong, but still on the right path. The email I'm replying to has been quoted in various online discussions so I thought it would be best for me to update and correct those statements, if they were ever to be used as references. I emailed Linus Torvalds recently (the original author of git, though very quickly not the main developer), and he told me that it was unlikely that the "git master" branch name was influenced by BitKeeper, and that "master" was "fairly standard naming" for this sort of thing and "more likely to be influenced by the CVS master repository". Petr Baudis is apparently the person that came up with the use of "master" and "origin" in git, https://twitter.com/xpasky/status/1271477451756056577: " I picked the names "master" (and "origin") in the early Git tooling back in 2005. [...] I have wished many times I would have named them "main" (and "upstream") instead. " and https://twitter.com/xpasky/status/1272280760280637441: " "master" as in e.g. "master recording". Perhaps you could say the original, but viewed from the production process perspective. " I wanted to conclude that, at the end of the day, it doesn't matter where the name comes from (something that was touched upon a number of times in the thread). The fact that it has bad connotations, or inspires dread for individuals and whole communities, is reason enough to change it. It's especially the case when the term used is pretty inappropriate to describe what it is, and the software is flexible enough that we can very easily change that term without a lot of disruption. I think that we would do well as a project to make that change for all the repositories that we host, so we minimise that differences in our own project. If anyone wants some inspiration as to what they can do for their personal projects, codespell can help you follow best practices using the "usage" dictionary: https://twitter.com/hadessuk/status/1271371994672566273 which will be available as a Fedora update soon: https://bodhi.fedoraproject.org/updates/FEDORA-2020-12bd755a7c There are also tools to rename the main branch in your GitHub projects, ahead of GitHub doing that by default: https://github.com/dfm/rename-github-default-branch Cheers > [1]: And this is the commit that made it the default branch: > https://github.com/git/git/commit/cad88fdf8d1ebafb5d4d1b92eb243ff86bae740b#diff-8117edf99fe3ee201b23c8c157a64c95R41 > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Regarding behaviour of Gnome and Fedora members
On Fri, 2020-06-12 at 06:49 -0500, Ty Young via desktop-devel-list wrote: > Your reply violates the Code of Conduct, IMO, namely be respectful, > empathetic, considerate, patient and generous and friendly sections > of > the community guidelines. If you don't have anything constructive to > say > or, at the very least, can't say it in a polite way, I'd ask that > you > don't reply. Thanks. I don't think I need to be any of those things with somebody like you. Very courteously, I think you should leave this mailing-list, and this community. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes to GitLab runners configuration
On Mon, 2020-02-24 at 08:19 -0600, Michael Catanzaro wrote: > On Mon, Feb 24, 2020 at 10:11 am, Bastien Nocera > wrote: > > It uses the flatpak_ci_initiative.yml template and throws this > > error: > > bwrap: Creating new namespace failed, likely because the kernel > > does > > not support user namespaces. bwrap must be installed setuid on > > such > > systems. > > I'm seeing this randomly on Epiphany CI. Solution in my case is to > rerun the CI. Maybe one particular runner is broken? Ran it 3 separate times, on 3 different runners, to no avail. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes to GitLab runners configuration
On Wed, 2020-02-19 at 14:50 +0100, Bartłomiej Piotrowski wrote:
> Hello,
>
> For historical reasons™ all GitLab runners were running with
> privileged
> mode enabled. The happy side effect of this fact is that nothing
> special
> was ever needed to run Docker or flatpak builds. It also means we
> were
> extremely lucky that no one abused CAP_SYS_ADMIN and other elevated
> privileges for bad things.
>
> For past few days I've been working to ensure that Flatpak builds are
> still functional without additional privileges. If your project is
> using
> citemplates[1], the configuration change should be invisible to your
> pipelines and you can keep on doing awesome GNOME work. However, if
> you
> have modified default steps via 'extends' keyword (or by defining
> them
> completely manually), please make sure that:
It seems like this isn't quite working as it should. This MR is porting
sound-juicer to meson:
https://gitlab.gnome.org/GNOME/sound-juicer/-/merge_requests/6
It uses the flatpak_ci_initiative.yml template and throws this error:
bwrap: Creating new namespace failed, likely because the kernel does
not support user namespaces. bwrap must be installed setuid on such
systems.
> 1) you are using the
> registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome image or
> your
> image does not run as root,
From the template:
.flatpak:
image: 'registry.gitlab.gnome.org/gnome/gnome-runtime-images/gnome:master'
> 2) jobs using flatpak/flatpak-builder have "flatpak" tag defined,
From the template:
tags:
- flatpak
And in the pipeline output:
https://gitlab.gnome.org/GNOME/sound-juicer/-/jobs/606529
> 3) flatpak-builder invocation includes --user -disable-rofiles-fuse
> for
> building; 'flatpak-builder --run' includes --disable-rofiles-fuse.
In the template:
script:
- flatpak-builder --user --disable-rofiles-fuse --stop-at=${FLATPAK_MODULE}
flatpak_app ${MANIFEST_PATH}
(also visible in the pipeline output).
Is there anything else that needs to be done?
> If your project's pipeline is using Docker to build an image from
> Dockerfile, consider switching to podman or buildah as they should
> work
> unprivileged.
>
> The only exception from these changes are runners assigned to
> gnome-build-meta.
>
> If you encounter any problems with running CI unprivileged, please
> poke
> me on #sysadmin on irc.gnome.org or via Rocket.chat.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound Juicer support and/or EoL
On Tue, 2019-12-03 at 20:48 -0500, Link Dupont wrote: > I completely agree with these sentiments. It's a valuable piece of > software that should not be abandoned. I volunteer to take on > maintainership of it. I've never been a module owner, but this > sounds > like a great opportunity to become one. A great way to start would be to provide an MR that would generate a Flatpak through the CI. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound Juicer support and/or EoL
On Tue, 2019-12-03 at 23:14 +0100, Kevin Degeling wrote: > Hey All, > > After reporting an issue related to Sound Juicer, I discovered that > the project has been mostly abandoned. There is still a valuable pull > request open ( > https://gitlab.gnome.org/GNOME/sound-juicer/merge_requests/2) but for > the most part active maintainance has stopped. This puts the > application on a crossroads: > > - Approve pending pull requests and assign a new owner, if only for > minimal maintainance. > - End of Life the project, and inform all downstream projects > (Fedora, Ubuntu et al) te remove it from their repositories in future > releases. Option 3 would be "just leave it there". There are plenty of applications that don't need any sort of maintenance. In this case it would have been nice if the UI changes were made earlier, but it hasn't made the application unusable, even without the patches. I've reviewed the last patch. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Fri, 2019-09-13 at 10:30 +0100, Emmanuele Bassi wrote: > > If a dependency is already in the GNOME SDK then there's no real need > to notify us; unless, of course, the dependency in the SDK is pinned > to a specific version, and you require a later one. > > As I said in the original email, before this detour into whether > humans can or should be automated out of their jobs, this is > definitely more important for dependencies hosted outside of > gitlab.gnome.org. So, for applications and their direct dependencies, that'd mean a mail when the development Flatpak needs a change, but not when the change is related to a dep on gitlab.gnome.org. Which I guess means that non-gitlab.gnome.org dependencies should probably be pinned to specific versions even in our nightly/devel builds. Still, that seems somewhat automatable. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers should announce build-related changes in their modules
On Fri, 2019-09-13 at 10:12 +0100, Emmanuele Bassi via desktop-devel- list wrote: > Not every single problem we have in building a complex project like > GNOME can be solved by a script; if it were, we wouldn't need > maintainers, and y'all would have been replaced by a script already. This doesn't sound one bit nice or polite. I'd like to apologise in advance for the time that I'll also forget to send a mail to the release-team, or wondering why I need to tell the release-team when I bump a dependency that's going to be shipped with the new GNOME anyway, such as GTK or glib. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changes: GNOME 3.35/3.36 release schedule
On Thu, 2019-09-12 at 08:19 -0500, mcatanz...@gnome.org wrote: > On Thu, Sep 12, 2019 at 2:45 AM, Milan Crha via desktop-devel-list > wrote: > > As a real life example, I skipped 3.32.5 this year, because there > > was > > no code change in the stable branch with which the users could > > benefit. > > The late stables are for bug fixes, from my point of view. > > I wondered about how to best present that on the schedule. > > We don't actually expect you to release tarballs past 3.34.0 unless > you > have actual need to do so (bugfixes that need released). These are > more > informational deadlines so that you know when our runtime updates > will > occur. > > E.g. say you release 3.34.0 on time, then by some magic nobody > reports > any bugs in evolution-data-server for four months. (Wouldn't that be > nice?) We make it to February and finally you have some fixes that > you > want to release. If you release your 3.34.1 by the tarball deadline > for > 3.34.5, then your 3.34.1 will make it into the 3.34.5 runtime update > during the next week. Otherwise it might wait six weeks until the > 3.34.6 runtime update. (We'll be doing 3.34 releases until March > next > year, because the runtime will be supported for one year. This > schedule > only shows the first half of the 3.34 lifetime.) This is very important for the maintainers of libraries that live in the GNOME runtime. Do we have a full list of those? What happens if there are security issues that crop up in the meanwhile? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Epiphany memory corruption problem
On Tue, 2019-09-03 at 06:42 -0500, mcatanz...@gnome.org wrote: > On Sat, Aug 17, 2019 at 4:41 PM, mcatanz...@gnome.org wrote: > > The bug report shows valgrind crashes on startup. I've tried to get > > a > > working asan build of Tech Preview, but haven't been successful. > > If anyone is willing to help with asan, that would be great. > Unfortunately we never solved this and our 3.34 is going to be > crashy > and bad. :( The only hope I see is to deploy asan in our Tech > Preview > stream. Maybe release 3.32.x as a 3.34 instead if that's the problem? ___ 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, 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. You just need to have experience handing or being handed coursework to know how it will go. (I think making the deadline a *hard* deadline would be a better idea, and actually use the release-team's powers to do releases if needed) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Games in need of maintainers
On Tue, 2019-08-06 at 11:23 +0200, Bastien Nocera wrote: > On Mon, 2019-08-05 at 23:11 +0200, Arnaud Bonatti via desktop-devel- > list wrote: > > Hi, > > > > 2019-08-05 22:37 UTC+02:00, mcatanz...@gnome.org < > > mcatanz...@gnome.org>: > > > I'm trying to find new maintainers for the following games: > > > > > > four-in-a-row, gnome-klotski, gnome-robots, gnome-mahjongg, > > > gnome-tetravex, quadrapassel, tali > > > > > > The first three in the list used to be lightly maintained by me, > > > but I > > > don't want to keep releasing them. I'll continue to care for two > > > or > > > three other games. > > > > I’ll take care of Four-in-a-Row, I have big plans for it. And if > > really needed, I can also have a look to Klotski, Mahjongg and > > Tetravex, but that would be in low-maintainance mode. > > I'm not sure this is a good idea, seeing as you didn't follow the > correct procedures for translations, for a piece of software you > already maintain, just back in March this year: > https://mail.gnome.org/archives/gnome-i18n/2018-March/msg3.html > and then again a couple of days later: > https://mail.gnome.org/archives/gnome-i18n/2018-March/msg00034.html > > Despite being told about not doing that in 2018: > https://mail.gnome.org/archives/gnome-i18n/2018-March/msg3.html Sorry, 2019 link here: https://mail.gnome.org/archives/gnome-i18n/2019-March/msg00132.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Games in need of maintainers
On Mon, 2019-08-05 at 23:11 +0200, Arnaud Bonatti via desktop-devel- list wrote: > Hi, > > 2019-08-05 22:37 UTC+02:00, mcatanz...@gnome.org < > mcatanz...@gnome.org>: > > I'm trying to find new maintainers for the following games: > > > > four-in-a-row, gnome-klotski, gnome-robots, gnome-mahjongg, > > gnome-tetravex, quadrapassel, tali > > > > The first three in the list used to be lightly maintained by me, > > but I > > don't want to keep releasing them. I'll continue to care for two or > > three other games. > > I’ll take care of Four-in-a-Row, I have big plans for it. And if > really needed, I can also have a look to Klotski, Mahjongg and > Tetravex, but that would be in low-maintainance mode. I'm not sure this is a good idea, seeing as you didn't follow the correct procedures for translations, for a piece of software you already maintain, just back in March this year: https://mail.gnome.org/archives/gnome-i18n/2018-March/msg3.html and then again a couple of days later: https://mail.gnome.org/archives/gnome-i18n/2018-March/msg00034.html Despite being told about not doing that in 2018: https://mail.gnome.org/archives/gnome-i18n/2018-March/msg3.html Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some nigthly flatpaks are failing to build
On Thu, 2019-08-01 at 16:05 +0200, Bastien Nocera wrote: > On Thu, 2019-08-01 at 12:21 +0100, Javier Jardón wrote: > > Hi, > > > > It came to my attention [1] several of the nigthly flatpaks of our > > core apps stop building against the latest GNOME flatpak runtime > > > > Taking a look to the build failures, seems the main problems are: > > > > 1. Some of the modules depend on intltool or gnome-common; those > > are > > not in the SDK anymore. > > Solutions: > > - Check a more version of the component doesnt depend on those > > already > > (new versions of gnome-desktop doesnt depend on gettext/gnome- > > common, > > for example) > > - Port component to use gettext [2] > > - Port component to not use gnome-common [3] > > - (less preferable) Include intltool/gnome-common on your manifest, > > as > > a submodule [4] or directly in it [5] > > > > 2. Build failure with the gspell dependency; this is [6] > > Solution: > > - Try to fix [6] or, in the meantime, depend on the latest release > > tarball/tag instead master [7] > > > > Please apply those fixes asap so we can have full green for the > > next > > GNOME 3.34 release! > > gnome-books and totem have been fixed. gnome-books and totem should be really fixed now, as they build correctly locally. I had only fixed the first problem I hit in each, and expected the CI images to be up-to-date and fail. They were not and they did not. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Some nigthly flatpaks are failing to build
On Thu, 2019-08-01 at 12:21 +0100, Javier Jardón wrote: > Hi, > > It came to my attention [1] several of the nigthly flatpaks of our > core apps stop building against the latest GNOME flatpak runtime > > Taking a look to the build failures, seems the main problems are: > > 1. Some of the modules depend on intltool or gnome-common; those are > not in the SDK anymore. > Solutions: > - Check a more version of the component doesnt depend on those > already > (new versions of gnome-desktop doesnt depend on gettext/gnome-common, > for example) > - Port component to use gettext [2] > - Port component to not use gnome-common [3] > - (less preferable) Include intltool/gnome-common on your manifest, > as > a submodule [4] or directly in it [5] > > 2. Build failure with the gspell dependency; this is [6] > Solution: > - Try to fix [6] or, in the meantime, depend on the latest release > tarball/tag instead master [7] > > Please apply those fixes asap so we can have full green for the next > GNOME 3.34 release! gnome-books and totem have been fixed. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On Wed, 2019-05-08 at 16:05 +0200, jtoj...@gmail.com wrote: > It does not work very well, though: > > https://gitlab.gnome.org/GNOME/gnome-control-center/issues/1 It works as well as it possibly can. Those search terms aren't automatically pulled from the UI, or the documentation, but manually added to each desktop file's "Keywords" field. I've closed this bug as not being actionable, and asked for separate bugs to be filed. So if you think a term is missing, file a bug against the setting panel you think should be associated with it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On Tue, 2019-05-07 at 18:32 +0100, Calum Benson via desktop-devel-list wrote: > > On 2 May 2019, at 11:19, jtojnar--- via desktop-devel-list < > > desktop-devel-list@gnome.org> wrote: > > > > Something like full-text search similar to one Firefox has in its > > preferences might be nicer and allow us to merge the two > > configuration applications. > > > > https://www.ghacks.net/2017/06/16/first-look-at-firefoxs-preferences-search/ > > The macOS System Preferences still does this best, imho — you can > search for any word in any preferences panel, plus a bunch of useful > synonyms too. So if you search for "wallpaper", it'll take you to the > "Desktop & Screensaver" preferences, even though the term "wallpaper" > isn't actually used anywhere. We've had this functionality since before GNOME 3.0. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On 4 May 2019, at 17:47, drago01 wrote: > > "The term master copy has a unique meaning in art that predates the > modern term. In art, a master copy is the process of drawing or > painting a copy of a another artist's work. It is most common to copy > the work of a master artist, hence the term master copy. This is > considered an essential form of practice. In some cases, master > copies become valuable artworks such as Van Gogh's Flowering Plum > Tree (right) based on Hiroshige's Plum Park in Kameido (left)." > > Source: https://simplicable.com/new/master-copy Ha, cool, I've saved this for later reading. > Does not have a connection to slavery in that context at all. However, the rest of my email explains how this particular explanation doesn’t matter in the end, because the master in “master branch” is likely not the one from master copy. I’ve left it below. I should note though that, at the end of the day, it shouldn’t matter whether this “master” comes from the “master/slave” reference or another. The etymology is not relevant when the emotional impact of a word But it comes from “master/slave”... > > First appearance of "master" in git is in a CVS helper script[1]: > > https://github.com/git/git/commit/3e91311ae750af9bf2e3517b1e701288ac306b96 > > > > Why is that branch called master? Probably because BitKeeper uses > > "master" for its main branch: > > http://www.bitkeeper.org/tips.html#_how_do_i_rebase_my_work_on_top_of_a_different_changeset > > > > But maybe this "master" isn't the same one that's in "master/slave"? > > See the documentation about > > master/slave repositories: > > https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L223 > > > > But repositories and branches aren't the same! They are in BitKeeper: > > https://users.bitkeeper.org/t/branching-with-bk/158/2 > > > > So, yes, the "git master" branch probably isn't even a "master copy" > > reference, but a straight up master/slave reference. > > > > Did I get anything wrong there? > > > > > > > > [1]: And this is the commit that made it the default branch: > > https://github.com/git/git/commit/cad88fdf8d1ebafb5d4d1b92eb243ff86bae740b#diff-8117edf99fe3ee201b23c8c157a64c95R41 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Sat, 2019-05-04 at 12:32 +0200, drago01 via desktop-devel-list wrote: > https://dictionary.cambridge.org/amp/english/master > > Master / slave relation is just one of the possible meanings but not > in the context of master copy > > "an original version of something from which copies can be made:" .. > > this has no connection with slavery at all. Reference needed. You don't know where it comes from, and you're not even trying to find where "master copy" takes its name from. > Words have meanings based on context - trying to make a connection > to slavery where is none nor any intent to do so is actually > disrespectful to whomever named the default branch "master". First appearance of "master" in git is in a CVS helper script[1]: https://github.com/git/git/commit/3e91311ae750af9bf2e3517b1e701288ac3066b9 Why is that branch called master? Probably because BitKeeper uses "master" for its main branch: http://www.bitkeeper.org/tips.html#_how_do_i_rebase_my_work_on_top_of_a_different_changeset But maybe this "master" isn't the same one that's in "master/slave"? See the documentation about master/slave repositories: https://github.com/bitkeeper-scm/bitkeeper/blob/master/doc/HOWTO.ask#L223 But repositories and branches aren't the same! They are in BitKeeper: https://users.bitkeeper.org/t/branching-with-bk/158/2 So, yes, the "git master" branch probably isn't even a "master copy" reference, but a straight up master/slave reference. Did I get anything wrong there? [1]: And this is the commit that made it the default branch: https://github.com/git/git/commit/cad88fdf8d1ebafb5d4d1b92eb243ff86bae740b#diff-8117edf99fe3ee201b23c8c157a64c95R41 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Sat, 2019-05-04 at 01:28 +0200, Matthias Klumpp wrote: > Am Fr., 3. Mai 2019 um 15:36 Uhr schrieb Carmen Bianca Bakker > : > > Je ven, 2019-05-03 je 14:45 +0200, Bastien Nocera skribis: > > > [...] > > > If we agree that the "master" in the git branch name is the same > > > "master" that's used in "master copy" meaning "the original", > > > "the one > > > medium that other copies are made from", then it's probably a > > > "master/slave" relationship. > > > > > > There are still existing mentions of "slave copies". In short, > > > "master > > > copies" could have been called that because the copies made from > > > it > > > were "slave copies". > > > > This logic makes sense to me, thank you. That was the missing bit > > of > > logic for me. I can get on board with that. > > [...] > > Is this really true though? I never once heard of a "slave copy", so > I > just googled the word combination, yielding only 7.130 results, none > of which that I skimmed through relate to an actual "slave copy" as > in > "copied from master". All seem to deal with copying to > slave(-machines) or copies that slaves hold. > For comparison, "master copy" yields >> 542.000.000 results. So > either > the term slave copy does not exist at all, or it is very fringe and > has never been widely used or used recently. > Thinking about it, a 1:1 copy from master is still a master in its > own > right and completely identical to the pristine data it was copied > from. So there is really do dependency relationship here, as you > would > normally have in a traditional master<->slave pattern. All master > copies are equal in their "master-ness". So, having a slave copy > makes > no logical sense to me. > tl;dr: Is there some further reading on the usage of slave copy in > projects and its common etymology with master copy? I don't have a good answer for this. I didn't find an explanation one way or the other, but there are uses of "slave copies" that aren't "copied from master" in Google, but usually not in recording/publishing fields. I just don't know whether "slave copy" is implied in "master copy" or whether it's completely disconnected from the term. If it's completely disconnected, where does "mastering" come from? Let me know if you find good etymologies for the verb "master". I couldn't think of any way that it wouldn't be related to a master copy and its "slave" copies. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Fri, 2019-05-03 at 18:31 -0500, mcatanz...@gnome.org wrote: > On Fri, May 3, 2019 at 5:57 PM, Bastien Nocera > wrote: > > Seriously Michael, you’re embarrassing yourself. > > I don't feel very embarrassed. Your suggested alternative name, > "main," > is clearly considered to be offensive by at least one of the very > same > people who don't like "master," and who amazingly appears to be > sincere > about this, so does it really still seem like a good option? We're > not > going to accomplish much if we replace one apparently-offensive > branch > name with another. > > Keep trying... eventually we'll find something that is inoffensive. > I > don't think anybody has complained about "trunk" yet. At least I > don't > think elephants will be contributing to GNOME anytime soon. The person you quoted is a troll. In fact, I'm not sure there's any comments on that issue that aren't trolls (apart from the OP and the repository owner). This is the sort of comment that person made on another platform: https://dev.to/rkfg/comment/6bj4 (yes, they're so useful that they just get removed, you can see snippets of the transphobic nature of them in the full thread if you want to read) I don't think you want to align yourself with this person. The rest of your interactions in this thread and the original thread are coming out as disruptive for the sake of it. Is changing the default git branch really something you feel strongly about? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
> On 4 May 2019, at 00:29, mcatanz...@gnome.org wrote: > >> On Fri, May 3, 2019 at 5:09 AM, Bastien Nocera wrote: >> - And to what? >> A few possible names were mentioned/used. "mainline" was thought to >> have strong connections to drug use, "release" (use in the contributor >> covenant) seems to restrictive (we also do releases from other >> branches). I like "main" because it keeps 2 letters from "master" so >> diminishes the need to retrain your muscle memory. "trunk" definitely >> makes sense when talking about branches but doesn't have the "ma" >> advantage. > > "main" seems like it should be safe, yet since you linked to > https://github.com/ContributorCovenant/contributor_covenant/issues/569 it > seems fair to quote the second comment there: > >> "Main" suggests inequality, I'm against that. > > So good luck finding an inoffensive name for the, er, primary branch. (I > probably shouldn't say "primary," though, since primacy also suggests > inequality) Seriously Michael, you’re embarrassing yourself. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Fri, 2019-05-03 at 15:35 +0200, Carmen Bianca Bakker wrote: > Je ven, 2019-05-03 je 14:45 +0200, Bastien Nocera skribis: > > > > > If we agree that the "master" in the git branch name is the same > > "master" that's used in "master copy" meaning "the original", "the > > one > > medium that other copies are made from", then it's probably a > > "master/slave" relationship. > > > > There are still existing mentions of "slave copies". In short, > > "master > > copies" could have been called that because the copies made from it > > were "slave copies". > > This logic makes sense to me, thank you. That was the missing bit of > logic for me. I can get on board with that. > > Beyond just that logic, however, are there organisations who hold the > same opinion? Affected people who do? That would be immensely > valuable > as rationale for making the change, beside this somewhat semantic > argument. I've quoted a few individuals who made this change in the original mail, but I don't have more information here. > > > The shitstorm is to be expected one way or another. The only > > > difference > > > would be whether GNOME or The Linux Foundation is smeared in > > > internet > > > comments as "SJWs changing things and I don't like it". > > > > Because you think that it would be just the organisations being > > smeared? Or that they would just be smeared? Sorry, I'm not > > courageous > > (or foolish) enough to even attempt that. > > Maybe I'm misinterpreting. You said that doing this upstream would > result in people being mad. I asserted that it's going to result in > people being mad one way or another. I did not mean or imply anything > other than that, and do not see how this statement can be interpreted > otherwise. It's mostly about the size and reach of the people "being mad", and the target audience. When GNOME adopts a full code of conduct for online behaviour (our current one is only for events), I don't expect it to cause the same sort of response from the wider community as when the Linux kernel did. Or when Python removed the "master/slave" terms from its code base. > In any case, thank you, you've convinced me. I stand by most of what > I've said, but I can kind of see the connection to the practice of > slavery more clearly. > > If the change can be done transparently (i.e., nobody needs to lift a > finger, as said in the thread), I don't have any strong objections > against the change. Otherwise I'd urge to balance the gains against > the > pains. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Fri, 2019-05-03 at 14:07 +0200, Carmen Bianca Bakker wrote: > Je ven, 2019-05-03 je 12:09 +0200, Bastien Nocera skribis: > > - Why? > > > > For the same reasons we'd want to change master/slave references. > > Though it usually isn't paired up with "slave" (excluding the > > "gitslave" addon), it still has strong connotations of subjugation, > > and > > some ties with the vocabulary we're trying to change. > > Can this assertion be backed up by anything substantive? This keeps > being said, and I'm willing to believe it, but no actual arguments > are > being made as to _why_ this is. > > Specifically, this question needs an answer: > > Is the word "master"---in the context of a trunk branch---a charged > term that negatively impacts existing and/or would-be contributors? > > Or more broadly would also suffice, is the word "master" generally > tainted as a charged term referring to the practice of slavery? > > It's clear that "master"/"slave" terminology has a direct analogy to > the practice of slavery and should be abandoned, but I cannot > personally extend this line of reasoning to the word "master" in > isolation. If we agree that the "master" in the git branch name is the same "master" that's used in "master copy" meaning "the original", "the one medium that other copies are made from", then it's probably a "master/slave" relationship. There are still existing mentions of "slave copies". In short, "master copies" could have been called that because the copies made from it were "slave copies". I also linked to this: https://www.collinsdictionary.com/dictionary/english/master-copy which shows when the term started being used (eg. it doesn't predate or descend from a term from the middle ages). I couldn't find reference to why "mastering" was called "mastering", but I also could not find any hints that it wasn't connected to "master/slave". > Also: The "gitslave" project, to the best of my knowledge, is about > managing submodules, not branches. It's not really a charitable > analogy. I merely said that it existed, an exception to the rule. I didn't mention it as an analogy, and I'm not sure why you would read it as that. > > I understand that the connection is more tenuous than straight up > > "master/slave" references, which is why I want to emphasise that we > > don't need any more comments about whether the negative > > connotations of > > "master" alone don't apply in your language or culture. > > > > I'd be much more interested in folks coming forward with references > > where it is the case. > > I can appreciate this sentiment (I've been asking for the exact same > thing the entire time), but this line of reasoning doesn't really > hold: > The connection is tenuous, therefore any arguments to the contrary > should be ignored. That seems a bit silly to me. Explaining that the connection is tenuous isn't the same thing as repeatedly being told that it's invalid because it's not valid to the person sending the email. It's the latter that I mind. > I suppose what that paragraph should have said is that the opinions > of > those negatively affected are prioritised, owing to the simple fact > that they are negatively affected. That makes more sense to me. > > > - Why not in git directly? > > > > Because that's already hard enough to propose something like this > > in a > > welcoming community like GNOME's. I've already seen offline > > comments > > made to people who participated in this thread, and this would go > > down > > about as well as like Linux' adoption of a code of conduct[6]. > > I still believe that this would be a valuable endeavour if the > premise > is true. Maybe I'm naive, but if the premise is true and the word > "master" negatively affects people, then doing this upstream would > beneficially impact more people than if this were done just in GNOME. > > It would also reduce the pain of breaking a default. > > The shitstorm is to be expected one way or another. The only > difference > would be whether GNOME or The Linux Foundation is smeared in internet > comments as "SJWs changing things and I don't like it". Because you think that it would be just the organisations being smeared? Or that they would just be smeared? Sorry, I'm not courageous (or foolish) enough to even attempt that. Think of what this process is as inspiration to others. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Fri, 2019-05-03 at 08:36 +0200, Daniel Mustieles García via desktop- devel-list wrote: > The problem is that he is not only writting a summary. He has renamed > master branch in GitLab, he has noticed people in Ubuntu about this > change, he has ignored us when we have said his arguments about > Python, Django, etc were not valid, he has ignored what most of the > people in this thread has said... that's not just a summary and > that's not just a proposal. The change was done before opening this > thread. The thread is about "GNOME modules" in general, not about Geary. Whatever happened with Geary is a different matter, and there are threads related to that which you can probably reply to. He also hasn't ignored you, or others, he's trying to figure out how to respond to walls of text and dubious pushback, which I'm helping with. Also, is there still a problem translating Geary using Damned Lies now? If there is, reply to the original thread, or file a sysadmin bug. It will be interesting as a test case for mass migration. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Wed, 2019-05-01 at 12:48 +0100, Richard Hughes via desktop-devel- list wrote: > On Wed, 1 May 2019 at 12:38, Michael Gratton wrote: > > They have also been successful in getting other projects to use > > more > > inclusive language. For example, MongoDB initially refused to stop > > using the term "master", but then relented after Python did so. > > That's misrepresenting it *AGAIN*. Both stopped using master along > with slave. The main developer branch is still called master in both > projects. This thread isn't just about git branches. Here's the original mail for reference: https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00049.html In particular: " The scope would be to replace occurrences of the terms appearing in the user interface, web sites, documentation, APIs (except as deprecated symbols), and git repositories - essentially wherever a person using or developing software for GNOME may reasonably encounter them. " ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Thu, 2019-04-25 at 11:46 +1000, Michael Gratton wrote: > Hi all, > > I'd like to formally propose as a GNOME Goal that GNOME modules > replace references to the terms "master" and "slave". [...] The scope > would be to replace occurrences of the terms appearing [...] git > repositories I don't think it makes sense to carry on the unfocused discussion in the original thread to talk about: Replacing "master" reference in git branches as the subject line says. - Why? For the same reasons we'd want to change master/slave references. Though it usually isn't paired up with "slave" (excluding the "gitslave" addon), it still has strong connotations of subjugation, and some ties with the vocabulary we're trying to change. Is "master" as in "master copy" as tainted? Given that "master copy" is a recent term[3], it came to be in a world where the end of slavery[4] was still in living memory, I don't think the answer is as clear cut as some of the threads made it out to be. GNOME wouldn't be the first to make this change[1][2], but probably the most significant yet. We've been the first, or amongst the first, for a number of initiatives, and shown our progressiveness. I understand that the connection is more tenuous than straight up "master/slave" references, which is why I want to emphasise that we don't need any more comments about whether the negative connotations of "master" alone don't apply in your language or culture. I'd be much more interested in folks coming forward with references where it is the case. - How? It is possible to rename the "master" branch in git. It's also possible to add a "link" of sorts so that software that specifically references "master" can be made to work with the new name[5]. If GNOME chooses to keep the compatibility name, we'll probably need to start filing bugs in some pieces of software that think the 2 branch names are separate branches (GitLab being one of them). This would help other software adopt new default branch names, and fix corner cases for everyone else. In short, you, the user, the developer, the checkouter, shouldn't need to even lift a finger. - Why not in git directly? Because that's already hard enough to propose something like this in a welcoming community like GNOME's. I've already seen offline comments made to people who participated in this thread, and this would go down about as well as like Linux' adoption of a code of conduct[6]. - And to what? A few possible names were mentioned/used. "mainline" was thought to have strong connections to drug use, "release" (use in the contributor covenant) seems to restrictive (we also do releases from other branches). I like "main" because it keeps 2 letters from "master" so diminishes the need to retrain your muscle memory. "trunk" definitely makes sense when talking about branches but doesn't have the "ma" advantage. - Next steps The GNOME community needs to decide whether this change can be done. Most of the original thread was specifically about the git branch name change, and changing lone "master" references is where most of the opposition was. I expect Michael to send a recap mail about "master/slave" references in the original thread shortly. Cheers [1]: https://github.com/ContributorCovenant/contributor_covenant/issues/569#issuecomment-424896149 [2]: https://miklb.com/blog/2017/08/29/deprecating-the-term-git-master/ [3]: See the "Trends" section at https://www.collinsdictionary.com/dictionary/english/master-copy [4]: "the abolition of slavery in the western world", it's hard to be concise yet precise in cases like this [5]: https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00113.html [6]: I wouldn't read this if I were you: https://github.com/torvalds/linux/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+coc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Fri, 2019-05-03 at 08:47 +0200, Daniel Mustieles García via desktop- devel-list wrote: > > > El mié., 1 may. 2019 a las 14:39, Michael Gratton () > escribió: > > On Wed, May 1, 2019 at 14:30, Carmen Bianca Bakker > > wrote: > > > > > > I think the problem is that, when prompted why we should make > > this > > > change, you said that we need only look at Python to see why this > > > change is good. But Python did NOT change the name of their > > master > > > branch, so it's a disingenuous example. > > > > I never claimed that, so I'm actually the one being mis- > > represented > > here. :) > > YOU DID. You've argued we should change master branch name because > Python, Django, Rust did it. You've mixed two concepts: the use of > master/slave terms in source code and the name of the master branch. > Please don't fall in victimism, you have done wrong and you should > fix it. > > You are completely free to change every "master" appearance in your > source code if you want so, but you shouldn't change master branch's > name, we have explained why several times. > > > I did however point out that Python has replaced uses of the term > > "master", and we should do the same. This thread isn't just about git branches, that's just what you used to derail the thread and yell at Michael early on. Here's the original mail for reference: https://mail.gnome.org/archives/desktop-devel-list/2019-April/msg00049.html In particular: " The scope would be to replace occurrences of the terms appearing in the user interface, web sites, documentation, APIs (except as deprecated symbols), and git repositories - essentially wherever a person using or developing software for GNOME may reasonably encounter them. " ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Replacing "master" reference in git branch names (was Re: Proposal: Replace all references to master/slave in GNOME modules)
On Wed, 2019-05-01 at 10:08 -0500, mcatanz...@gnome.org wrote: > On Wed, May 1, 2019 at 6:08 AM, Michael Gratton wrote: > > This has already been covered in the original proposal under > > objection (1) "It doesn't matter". As has already been discussed, > > what actually doesn't matter is what you or I think, it is the > > people > > who have been affected by the language we use that matter. These > > are > > the people who won't contribute to GNOME because of these terms, > > and > > it is the project that loses out in the end. > > You've yet to provide any evidence for this. We're asking for > evidence > because it is *extremely* difficult to believe. You're losing us > here. > > > To address some of your points directly however, this censorship > > in > > as much as the CoC is censorship, and as much as you already > > self-censor when choosing names for things in projects you > > participate in. That is to say, not actually censorship at all. In > > fact, you can see this proposal as simply aiming to extend the CoC > > to > > our documentation, API, and development infrastructure. > > Michael, the events CoC is a reasonable CoC written by reasonable > people designed to ensure we treat each other reasonably well. It > has > broad support -- perhaps not universal, but at least pretty broad -- > from the GNOME community because we mostly all agree it is > reasonable. Our code of conduct isn't a direct descendant of the contributor covenant, but it's still widely used in our community, including the Linux kernel: https://github.com/ContributorCovenant/contributor_covenant/blob/release/static/adopters.csv and its master branch name was changed: https://github.com/ContributorCovenant/contributor_covenant/issues/569#issuecomment-424896149 I quote so you don't have to read the issue that's of similar tone to this thread: " The main branch is now called 'release'. Thank you for pointing this out. (And I wish that GIthub would make something like this the default.) " > What you're proposing is not reasonable. It's really not. There's no > way you're going to convince the community that we should avoid > commonly-used words that are generally considered inoffensive, just > because a small minority might feel otherwise Re-read this sentence a bunch of times, it's pretty much the opposite of what our community stands for. Offensiveness isn't a popularity contest. > (which, in this case, is > hard to believe, but I suppose people are not always reasonable). This is uncalled for. > If you want to help make the GNOME community more inclusive in a > more > productive way, you could, for example, work on generalizing the > events > CoC to apply to all GNOME community interactions, like this mailing > list, rather than just specific in-person events. I would suspect > that > would have broad support. That's already being worked though, isn't it? I don't see why we can't work on both. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Good read from a new GNOME user
On Thu, 2019-05-02 at 11:26 +0200, Carmen Bianca Bakker wrote: > > 2b. No battery percentage on status bar. > > Slight agree on all, but do not know how to fix this. I implemented this: $ gsettings set org.gnome.desktop.interface show-battery-percentage true but it doesn't have a UI: https://gitlab.gnome.org/GNOME/gnome-control-center/issues/481 Feel free to thumbs up the original report or my reply. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Tue, 2019-04-30 at 17:53 +0200, Daniel Mustieles García wrote: > What has happened with this? We have a repo with a non-standard > branch name and no consensus for a global change, do we? The repository in question, Geary, has had a git configuration change applied so that the old branch name can still be used. Think of it as a test ground. I don't expect changes to happen in the very short term, but there should be more information available soon. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Sat, 2019-04-27 at 14:13 +0200, Ask Hjorth Larsen via desktop-devel- list wrote: > > This sounds beautiful, but mindless prescriptivism like this won't > help any of the peoples you mention. Want to help? Donate money > where it matters. Vote for someone good. Avoid buying smartphones > produced in sweatshops - that actually reduces real-life > slavery. You > know, /real/ things. What tells you that this isn't what Michael or anybody else already does, and why would it matter? In this community, you don't really get a say in what people think is important, or how they spend their time, as responsibilities are volunteered. Michael mentioned that the change is only likely to happen once it's possible to make it seamless, so this wouldn't take anyone's time, so contributors can focus on what's important to them. As mentioned *many* times on this list, we're talking about one thing, and one thing only. Bringing up other cases where changes might be needed is probably best done separately, in their own thread, and in their own time. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Thu, 2019-04-25 at 12:41 +0200, David Woodhouse wrote: > On Thu, 2019-04-25 at 12:12 +0200, Bastien Nocera wrote: > > It's easier to completely remove "master" to remove mentions of > > "master/slave" and to remove the non-gender neutral "master" than > > it > > would be to do half of that. Two birds, one stone. > > Haha. I see what you did there. But no, we're not talking about > removing the "non-gender neutral master" either. I think you're trying to argue that the "master" in "master git branch" is not a "master" that's derived from the "master" person. I don't think that holds. See link below. > Yes, there is a gender-specific word "master" which is also a homonym > of the one in "master/slave". > > No, that isn't the one which is used when we say "the master copy" or > "the master branch". They all come from the same word with the same connotations: https://en.wiktionary.org/wiki/master FWIW, "master copy" has quite a lot of synonyms that are used in other languages and can be reused here, such as "copy zero", "original (copy)", or in some uses "standard copy". > Besides, we can't use "mainline" anyway, as that is a reference to > intravenous drug taking and since we can't be expected tell homonyms > apart or pass basic primary school comprehension exercises by > applying > our knowledge of context to the words we see, we'll *obviously* > interpret all instances of the word "mainline" as references to > drugs... right? This is a "slippery slope" logical fallacy. Are you going to argue that we can't use "trunk" either because of its link to deforestation? ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Thu, 2019-04-25 at 11:33 +0100, Richard Hughes via desktop-devel- list wrote: > On Thu, 25 Apr 2019 at 06:21, wrote: > > This should go without saying, but master branches are not a > > reference > > to slavery, rather to canonicity. The master branch is the > > canonical > > branch, the primary copy. > > This is very much my thinking too. I'd agree with this proposal if > every branch forked from master was called slave/hughsie/whatever but > in this case the master is clearly referring to the canonical version > that the others are derived from. The word "master" isn't a bad word, > and doesn't always mean the opposite of slave. It's non-gender neutral, which was mentioned earlier in the thread. See the master/maiden section of: https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Thu, 2019-04-25 at 11:58 +0200, David Woodhouse wrote: > On Thu, 2019-04-25 at 11:45 +0200, Bastien Nocera wrote: > > You also don't get to call reasoning you don't agree with "bizarre > > and > > illogical" without justifying it. The reason behind this possible > > change was already mentioned in the original mail. The mail's hard > > to > > read, but fairly short, and clearly shows that this isn't about > > twisting words. > > I read the email. It said it was about removing references to the > terms > "master" and "slave". Yes, both separately. It then mentions "social inclusiveness" and not just slavery as the topic, and links to a set of guidelines for which the URL makes it clear that it's not about slavery either: https://www.cs.cmu.edu/~mjw/Language/NonSexist/vuw.non-sexist-language-guidelines.txt > But then went on to advocate removing a different word which just > happens to be a homonym for one of the above. Which is why I called > it > bizarre and illogical. > > Even if we accept the initial premise that history can be fixed by > whitewashing it and never speaking of it again and never even using > terms that can accidentally *remind* people of it... extending it to > homonyms makes no sense at all. It's easier to completely remove "master" to remove mentions of "master/slave" and to remove the non-gender neutral "master" than it would be to do half of that. Two birds, one stone. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Thu, 2019-04-25 at 10:30 +0200, David Woodhouse wrote: > On Thu, 2019-04-25 at 18:13 +1000, Michael Gratton wrote: > > On Thu, Apr 25, 2019 at 00:20, mcatanz...@gnome.org wrote: > > > We should go to reasonable lengths to avoid offending reasonable > > > people, but if someone is offended by innocuous phrases like > > > Master's > > > degree, master plumber, Masterpiece Theater, or the word > > > "masterful," > > > then I'd suggest rethink why and consider that it's probably not > > > reasonable. > > > > This is objection 1) from the original proposal. Sadly, neither > > you, > > nor I, nor dictionaries get to choose what terms carry current or > > historical significance, positive or negative. > > But we do. When faced with the deterioration of language, with people > bizarrely choosing to interpret a given word using one meaning of it, > when that is clearly not the meaning that was actually intended... we > have a choice. > > We can capitulate, and say "oh, well if you're *offended* then you > must > be right, however bizarre and illogical your assumptions are". Or we > can stand up and say "no, stop being silly." > > People in this case seem to be doing the latter. > > I can't say that I disagree with them. "Capitulate"? This isn't a war... You also don't get to call reasoning you don't agree with "bizarre and illogical" without justifying it. The reason behind this possible change was already mentioned in the original mail. The mail's hard to read, but fairly short, and clearly shows that this isn't about twisting words. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: Replace all references to master/slave in GNOME modules
On Thu, 2019-04-25 at 11:46 +1000, Michael Gratton wrote: > Hi all, > > I'd like to formally propose as a GNOME Goal that GNOME modules > replace > references to the terms "master" and "slave". This is a worthwhile > thing to do for social inclusiveness[0]. Many FOSS and non-FOSS > projects, including Django[1], Python[2], and Rust[3] and the > ISC[4]) > have already implemented similar programmes and it would be good for > GNOME to do so also. The scope would be to replace occurrences of > the > terms appearing in the user interface, web sites, documentation, > APIs > (except as deprecated symbols), and git repositories - essentially > wherever a person using or developing software for GNOME may > reasonably > encounter them. > > By way of background, I recently did just this for Geary[5] after a > request via private communication. The work was essentially trivial, > and it has been a relatively painless transition. A number of people > have positively commented on the change, and no one has objected to > the > UI or API changes, however some feedback has been received about > renaming the mainline branch, broadly falling into essentially three > categories: 1) It doesn't matter, 2) it's inconvenient, and 3) it > should be done project-wide, not piecemeal. > > To respond to that feedback, which I imagine will also be raised for > this proposal, I'd suggest that (1) is clearly not the case - yes it > doesn't matter to many people, but it does matter to some, and > that's > the whole point of making a project more socially inclusive - to > make > it better for everyone. The issue raised by (2) is not a new problem > - > we already have to remember project names, branch names, file names, > symbol names, and so on. To make that easier we have tooling support > (auto-completion in both GUIs and TUIs, the ability to set things as > defaults, code symbol lookup, etc.). Further, disruption can be > minimised by carefully choosing replacement names. I deliberately > chose > "mainline" for Geary's mainline branch name because it has the same > auto-complete prefix as "master", for example. Want to check out the > mainline branch? Just type "git co m", just like you always > have. > Lastly, if adopted project-wide, then we'd all get used to the new > names rather quicky. Finally, to respond to (3) I am proposing it > project-wide now. > > To summarise, let's replace the use of these deprecated terms in our > project as a step towards making GNOME a project that everyone wants > to > use and develop for. Who's in? This email was really difficult to read because of the layout of the proposal, and how the response to feedback was formatted. I had to scan it 3 times to find what you wanted to rename the main git branches. +1 on the sysadmins doing the git changes project-wide +1 on tracking master/slave usage project-wide and removing it What your proposal doesn't touch on is what to do when the master/slave usage is out of our control, and legacy, especially when it comes to hardware. I feel that it would be better to not touch those, and come up with a statement that could be used in documentation to explain their usage. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Upcoming evolution-data-server API changes (libical-glib + more)
On Mon, 2019-04-15 at 08:50 +0200, Milan Crha via desktop-devel-list wrote: > On Fri, 2019-04-12 at 14:48 +0200, Bastien Nocera wrote: > > I'm guessing you looked at tarballs rather than git modules. > > Hi, > yeah, sort of, I used Fedora repoquery to check for dependencies. > > > "phonemgr", the module name for gnome-phone-manager is archived and > > hasn't seen a release for 6 years, so I guess it could be removed > > from your list: > > https://gitlab.gnome.org/Archive/phonemgr > > I see. It's still available in Fedora (possibly in other > distributions > as well) and I do not feel like being the reason to drop it. I've no > idea about the users of it, similarly with the other dependencies. > I'd > like to keep alive as many projects as I can. I mean, unless the > Archive forbids me to create the branch I'll do it anyway, to be > available for anyone still using or packaging the project(s). Archived sources can't be modified, you'll have to put that through the distributions. Cheers > Bye, > Milan > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Upcoming evolution-data-server API changes (libical-glib + more)
On Fri, 2019-04-12 at 08:47 +0200, Milan Crha via desktop-devel-list wrote: > Looking into the > other > API users, I found these hosted on GNOME: > >almanah >bijiben >california >ekiga >evolution-activesync >folks >glabels >gnome-calendar >gnome-contacts >gnome-phone-manager >gnome-shell >gnome-todo I'm guessing you looked at tarballs rather than git modules. "phonemgr", the module name for gnome-phone-manager is archived and hasn't seen a release for 6 years, so I guess it could be removed from your list: https://gitlab.gnome.org/Archive/phonemgr Cheers` ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please check your module is not using deprecated python2, gnome-common, intltool
> On 7 Apr 2019, at 20:50, Christian Hergert wrote: > >> On 04/07/2019 04:42 AM, Bastien Nocera wrote: >> That's going to be a tough ask given the discussion in: >> https://gitlab.gnome.org/GNOME/libpeas/merge_requests/5 >> TL;DR: The maintainer is AWOL but doesn't want help. Would be >> interesting for the release team to step in. > > This is not true. > > There are details involved here, that you may not be privy to. They were mentioned in public issues on the libpeas bug tracker, but are not particularly relevant to the problem at hand. Read the issue I linked to, and the merge requests I filed that were summarily closed without as much as an explanation. > > -- Christian > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please check your module is not using deprecated python2, gnome-common, intltool
On Sat, 2019-04-06 at 17:54 -0700, Javier Jardón wrote: > - libpeas https://gitlab.gnome.org/GNOME/libpeas/merge_requests/4 That's going to be a tough ask given the discussion in: https://gitlab.gnome.org/GNOME/libpeas/merge_requests/5 TL;DR: The maintainer is AWOL but doesn't want help. Would be interesting for the release team to step in. Cheers ___ 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, 2019-03-23 at 11:06 -0700, Britt Yazel wrote: > Ladies and Gentlemen, > > Congrats on an excellent 3.32 release! As the one handling the front > facing side of our social media accounts, I can safely say that the > users are EXTREMELY happy with the changes, both features and > performance, so give yourselves a nice pat on the back :-) > > 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. 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. > > 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. The status icons were removed for technical and design reasons. The design reasons haven't changed: https://wiki.gnome.org/Initiatives/StatusIconMigration And the technical reasons haven't either, as those status icons are X11 only and will stop working as more more apps are ported to Wayland. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update your libhandy submodules (and packages)
On Fri, 2019-03-01 at 07:12 -0600, mcatanz...@gnome.org wrote: > Yeah, a new libhandy release ASAP would be appreciated. > > Affected applications: > > epiphany > gnome-bluetooth It's not affected. The only widget is a copy/paste. > gnome-contacts > gnome-control-center > gnome-games > > I think libhandy has reached the point that it's time to start > thinking > about making it a system dependency so we don't have to enter panic > mode to update a bunch of different places whenever there's a bug > like > this. (There will be more bugs.) I'd really rather libraries that sit in between GLib/GTK and the app to live on GNOME servers. And this particular bug still needs a release to fix it. > On Fri, Mar 1, 2019 at 4:06 AM, Bastien Nocera > wrote: > > For the release-team: > > Did the definition and acceptance criteria change for external > > dependencies? libhandy is a library hosted on a 3rd-party server > > which > > some core applications have a dependency on. > > We don't really have any formal rules for external dependencies, I > think not since the GNOME 2 days. I'll bear that in mind next time I get a complaint about the required version of meson being too new *cough* ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Update your libhandy submodules (and packages)
libhandy broke translation for all applications that used it because of a call to textdomain()[1]. Make sure your submodule contains at least the commit labelled: Fix broken translations in all libhandy applications Would be useful for the libhandy developers to release a new version ASAP. For the release-team: Did the definition and acceptance criteria change for external dependencies? libhandy is a library hosted on a 3rd-party server which some core applications have a dependency on. [1]: Easy mistake to make, right? :) https://gitlab.gnome.org/Archive/gnome-vfs-extras/commit/567b7c24513c228d3f5c0f6fe3552ef38bb4fa7c ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Anyone who could share their Perl knowledge (to make Bugzilla display a product overview page when new bug entry is disabled)?
On Wed, 2019-02-27 at 14:34 +0100, Andre Klapper wrote: > On Tue, 2019-02-26 at 08:19 +0100, Andre Klapper wrote: > > Currently GNOME Bugzilla does not show the "Browse" product page > > when a > > product has been disabled for new bug entry > > Fixed now thanks to the help of Carlos and Olav. Pages like > https://bugzilla.gnome.org/page.cgi?id=browse.html=gnome-shell > work again so you can see all your old boogs and triage them! Right? > > If you want your project's (open) Bugzilla tasks to get copied to > Gitlab one day in the future: A ticket at > https://gitlab.gnome.org/Infrastructure/GitLab/issues/ > is welcome to sort out things. Is there a timeline for migration? I've filed a few of those, and haven't had any feedback: https://gitlab.gnome.org/Infrastructure/GitLab/issues/?scope=all=%E2%9C%93=opened_username=hadess=migrate (the majority of them I only just opened, the first 3 are getting old though) > We still have 22015 open tickets in 190 Bugzilla products... It would have been easier if closing the products for new bugs didn't remove those products from the "watched products" section in the drop- down, probably on purpose. Instead, you'll need to go to the email preferences: https://bugzilla.gnome.org/userprefs.cgi?tab=email and enter the watched products one by one. It seems that the bugzilla migration script might not know how to migrate private, or security bugs. This evince bug for example, is still opened because the reporter ticked the "only Evince developers can see this": https://bugzilla.gnome.org/show_bug.cgi?id=784704 What about the rest of the security bugs? I found left-over security bugs in gdk-pixbuf and gvfs for example. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Deprecating nautilus-sendto
Hey, 15 years ago, in another age, nautilus-sendto was created so that one could easily send files from nautilus via email. Then via email and Gaim. Via email, Gaim and Bluetooth. And Gajim. And now Pidgin not Gaim. And then Empathy and UPnP servers. And then just email again, because the UI was quite frankly absolutely awful. But nautilus-sendto doesn't work in a sandbox. And there's pretty similar but more capable code that can be run in xdg-desktop-portal- gtk, the gnome-ish Flatpak/Snap portal. So I would recommend that applications that use nautilus-sendto right now, start using the portal D-Bus API directly instead: https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.impl.portal.Email.xml This is an example of using said API: https://github.com/flatpak/flatpak-xdg-utils/blob/master/src/xdg-email.c You could but I would not recommend using xdg-email if your application will be used outside of a Flatpak because it will end up running this code: https://gitlab.freedesktop.org/xdg/xdg-utils/blob/master/scripts/xdg-email.in which might, or might not work. It's brittle and ugly. Note the regressions though: - Some email clients are not as well supported in xdg-desktop-portal-gtk: https://github.com/flatpak/xdg-desktop-portal-gtk/issues/187 https://github.com/flatpak/xdg-desktop-portal-gtk/issues/188 https://github.com/flatpak/xdg-desktop-portal-gtk/issues/189 - There is no support for zipping files up before sending them. This was only used by nautilus, and nautilus can replace/enhance this by using its native archive support. Here are a number of issues I filed against applications that use nautilus-sendto: https://gitlab.gnome.org/GNOME/shotwell/issues/111 https://gitlab.gnome.org/GNOME/evince/issues/1091 https://gitlab.gnome.org/GNOME/rhythmbox/issues/1695 https://gitlab.gnome.org/GNOME/nautilus/issues/928 https://gitlab.gnome.org/GNOME/yelp/issues/141 https://gitlab.gnome.org/GNOME/gnome-commander/issues/83 I'll have the code moved to the archives after the 3.32 release, at the start of the new development cycle: https://gitlab.gnome.org/Infrastructure/GitLab/issues/380 Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sharing locations in Maps
On Mon, 2019-02-25 at 21:50 +0100, Marcus Lundblad wrote: > Hi all! > > I wanted to discuss some things around sharing. Currently in Maps we > have a dialog to share locations with a fixed set of apps, Weather, > Clocks, and the default browser. There are a couple of problems with > this. First, detecting if Weather and Clocks are available currently > not possible in Flatpaks (maybe there is a "portal" to detect such > things, and also launch apps). Secondly these interact kinda poorly. > For example sharing a location with Clocks will permanently add that > location in Clocks with the name of the place (such as the name of a > shop). The option for the browser (which opens the location on the > openstreetmap.org site is somewhat more useful. > > I recall there being some discussions before about a "sharing portal" > (sharing a location might then share that as the object's URL on > OSM). > Is something like this already in place? (allowing sharing links with > i.e. e-mail clients). > > A sorta "stop-gap" solution I was thinking about might be to have a > dialog with read-only text entry filled with the URL allowing to > copy- > paste this (I think Google Maps have something similar, using a > shortened URL). > > A companion feature for this could be to allow opening such URLs (and > add Maps as a handler for HTTP(S) URIs). But maybe that would be > considered bad praxis (not sure if it's possible to ensure that it > would always have lower priority that any proper browsers). Ideally > it > would have cool to be able to add URI handlers for certain URL > patterns. I brought up this at some point on IRC. But this would > probably need quite some changes in how mime-handling is done. > > For the Clocks and Weather sharing, one option might be to show local > time, or time difference and local weather (this would probably need > an > on/off switch for privacy reasons) directly in the "place bubbles". > Or > maybe skip this, assuming the user could just look up these things > manually in the respective apps if wanted. Maps is probably a good application to start implementing "Sharing" from, as it only really needs to be able to pass URLs, not actual data. I would start with implementing separate "Sharing" buttons/menu items for sending: - a http(s) URL, for example, one labelled "Browser", using the g_app_info_launch_default_for_uri()[1] - a mail, with the name of the place in the subject line, URL in the body, using xdg-email[2], labelled "Mail" - a geo URI, which Clocks and Weather would be modified to handle In the future, we would want to implement this better in the portal API where the application developer would pass all three of the data above: "This is for x-scheme-handler/https applications, this for x-scheme- handle/mailto applications, this is for x-scheme-handler/geo applications" and the portal would show an interface with all the items in one dialogue. And then it could be extended again to allow passing more than simply URLs, with the data passed to other application being created on demand. HTH [1]: See http://docs.flatpak.org/en/latest/portals-gtk.html [2]: xdg-email outside the sandbox is dreadful, hopefully we can replace that somehow ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
gnome-books has been split off from gnome-documents
Hey, Looks like I mentioned my intent to do it, but didn't actually announce when it was done. gnome-books has been split off: https://mail.gnome.org/archives/distributor-list/2019-February/msg0.html This version is also available on Flathub, with WebP support, and many fixes. Cheers ___ 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
> On 17 Feb 2019, at 04:04, mcatanz...@gnome.org wrote: > >> On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list >> wrote: >> A solution would be for distribution package maintainers to use the >> binary tarball as a base instead of sources - this way the build can be >> done with secrets (ie. using GitLab CI and environment variable >> secrets) and sent to distributions for packaging. This certainly puts >> GNOME in a unique position in the landscape, though it allows for GNOME >> to control the build process in such a way that build secrets become >> possible. >> Though if this is the way it goes, be sure to be prepared for all the >> "GNOME forbids people to build their software stack" headlines, >> followed by a "actually the reason is that they needed to handle >> secrets in their builds in order to support client keys for the various >> integrations in the software" in the third paragraph. > > Well yeah... but distros will never allow that. It’s also against the GPL (and the LGPL, depending on where the secrets gets stored) > > Michael > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Clarifications regarding GNOME Online Accounts
> On 17 Feb 2019, at 18:18, Alexandre Franke wrote: > > 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? The same as for the Google accounts, as written in the gnome-documents issue in the original mail: https://gitlab.gnome.org/GNOME/gnome-documents/issues/34 > > -- > Alexandre Franke > GNOME Hacker > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: preparing for a new gtk-doc release
On Thu, 2019-02-14 at 21:15 +0100, Stefan Sauer wrote:
> On 02/13/2019 10:31 PM, Bastien Nocera wrote:
> > On Wed, 2019-02-13 at 21:58 +0100, Stefan Sauer wrote:
> > > hi,
> > >
> > > did anyone try the new 'no-xslt' toolchain yet? In configure.ac
> > > all
> > > you need to do is:
> > >
> > > -GTK_DOC_CHECK([1.14])
> > > +GTK_DOC_CHECK([1.29],[--flavour no-xslt])
> > The m4 file shows the macro only taking one argument:
> > https://gitlab.gnome.org/GNOME/gtk-doc/blob/master/buildsystems/autotools/gtk-doc.m4#L31
> >
> > GTK_DOC_CHECK([minimum-gtk-doc-version])
> >
> > Or is this not the canonical version of the m4 macro?
>
> It is actually gtkdocize that grabs the extra arg.
> https://gitlab.gnome.org/GNOME/gtk-doc/blob/master/buildsystems/autotools/gtkdocize.in
>
> this is indeed not beautiful.
> > > for meson/cmake I have no idea and would gladly take patches. The
> > Which one of the tools does this "--flavour" argument end up being
> > passed to?
> >
> > Which arguments get passed to which tool, for meson, is documented
> > here:
> > http://mesonbuild.com/Gnome-module.html#gnomegtkdoc
> It not new args, we're calling different tools instead.
>
> meld buildsystems/autotools/gtk-doc.{,no-xslt.}make
>
> Sounds like this needs changes in meson itself? Would be awesome if
> someone could take case of this - the diff of the makefile should be
> straight forward. This would give me more time to work on gtkdoc
> itself.
I filed this meson bug:
https://github.com/mesonbuild/meson/issues/4932
Cheers
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: preparing for a new gtk-doc release
On Wed, 2019-02-13 at 21:58 +0100, Stefan Sauer wrote: > hi, > > did anyone try the new 'no-xslt' toolchain yet? In configure.ac all > you need to do is: > > -GTK_DOC_CHECK([1.14]) > +GTK_DOC_CHECK([1.29],[--flavour no-xslt]) The m4 file shows the macro only taking one argument: https://gitlab.gnome.org/GNOME/gtk-doc/blob/master/buildsystems/autotools/gtk-doc.m4#L31 GTK_DOC_CHECK([minimum-gtk-doc-version]) Or is this not the canonical version of the m4 macro? > for meson/cmake I have no idea and would gladly take patches. The Which one of the tools does this "--flavour" argument end up being passed to? Which arguments get passed to which tool, for meson, is documented here: http://mesonbuild.com/Gnome-module.html#gnomegtkdoc > advantage of the new toolchain is that you won't need xsltproc + > docbook-stylesheets and that it is much faster, but instead a few > more > python modules - see README: > > https://gitlab.gnome.org/GNOME/gtk-doc/blob/master/README > > If you try it out, you might see some warnings of not yet supported > docbook tags. If you encounter stuff that is not easy to get rid of, > please let me know (eg file a bug report). > > I also look forward to get before after numbers. > > If I don't get any bug reports in the coming week, I'll cut a 1.30 > release. > Stefan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.32 milestone review
On Wed, 2019-01-30 at 10:38 +, Allan Day wrote: > Bastien Nocera wrote: > ... > > > Regarding the app menu retirement initiative, the lack of > > > progress on > > > Totem [1] is also a concern. > > > > I already said this was on my todo list though. > > Ah great, I hadn't realised. Thanks Bastien! And I told that to Carlos, not to you, so it's no wonder you wouldn't have known. Sorry! :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.32 milestone review
On Wed, 2019-01-30 at 09:23 +0100, Carlos Soriano wrote: > Hi all, > > We are quite close to 3.32 freezes! I thought it would be helpful for > some maintainers and projects to summarize their 3.32 pressing issues > that they could do with some help and see if someone in ddl would > like to give a hand. > > I basically went through the 3.32 milestone at GitLab, chatted with > their maintainers and ordered these issues from top to bottom based > on importance (loosely defined :-)). > > Evince new icon and Meson - Part of the GNOME initiative for new > icons. It's the last core app missing it. The maintainer would > appreciate help figuring out how to include the svg icon with Meson. > Deadline 4th February, UI freeze. Code looks fine to me, I've added a link to the generated Flatpak if somebody wants to test it. > gnome-calculator, don't connect to internet on startup - Calculator > connects to internet on startup, which is not welcome by privacy- > aware users. The maintainer would appreciate some help working on a > solution. Deadline 11th March, code freeze. I don't think it's solely a code solution, and this could do with some design input. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.32 milestone review
On Wed, 2019-01-30 at 09:19 +, Allan Day via desktop-devel-list wrote: > Great initiative, Carlos! > > Carlos Soriano wrote: > ... > > gnome-screenshot, retire app menu - Part of the GNOME initiative to > > remove app menus. There is a MR, needs some review. Deadline 4th > > February, UI freeze. > > The thing we're missing here is participation from a maintainer. Is > gnome-screenshot actually maintained nowadays? If not, can assign a > new maintainer? > > Regarding the app menu retirement initiative, the lack of progress on > Totem [1] is also a concern. I already said this was on my todo list though. For what it's worth, I don't think that the way it's going to get fixed is the way that I would have wanted to ultimately do it. > [1] https://gitlab.gnome.org/GNOME/totem/issues/265 > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 20:10 +, Debarshi Ray wrote: > On Wed, Jan 23, 2019 at 08:02:16PM +0100, Bastien Nocera wrote: > > On Wed, 2019-01-23 at 18:52 +, Debarshi Ray wrote: > > > Grep for "Future of Pocket in GNOME" from 24th August 2018 in > > > your > > > inbox. > > > > Which solves what? You're removing the Documents and Mail > > categories, > > you're removing Pocket support. > > Two things. > > First, we are talking about GNOME Documents, GNOME Online Accounts, > GNOME ..., etc.. We are talking about GNOME. > > If you are not going to respond to a thread that has run for six > months, on a topic that you care about, then I am sorry, I can't > assume good faith. Those who participated agreed that they don't have > time to work on Pocket, nor is the current state of affairs very > good. That's how we decided to drop it. Having to constantly repeat that, yes, this was of interest to me was soul-sapping. > > Reading that mail you mentioned won't bring those features back. > > It's > > far from the first time you've wanted to remove Pocket support from > > GOA, as if it was a time sink, and a maintenance pain. > > > > I just don't understand the strategy of disabling/removing features > > and > > services, breaking apps on newer hosts. > > We have always, since the very first days when David Zeuthen was > around, pushed back against adding random accounts to GOA. We have > always said that the integration should be meaningful to a good cross > section of users, that there should be a default application or OS > component, etc.. > > This is nothing new. We eventually wrote it down as > https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals > > The Pocket integration doesn't do much. You yourself said that you > seldom use it. Mostly because the various integration points didn't exist. We (GNOME) were pining for a sharing interface which didn't, and still doesn't, exist, and epiphany maintainers didn't want to integrate the patch that was already written. > We regularly refuse requests to add random accounts to GOA. Just look > at the enhancement requests left open on Bugzilla. There are lots > more > that I have dealt with from other channels. It isn't fair that we > turn > down other requests, but keep Pocket in. I don't think that feature requests should be treated on the same level as existing, merged, features, and I don't see any merge requests for new account types, or providers. > It certainly is a maintenance burden. It's a burden when one has to > port away from deprecated GLib and WebKit APIs, it's a burden > when someone has to tweak the base-classes to accommodate yet > another quirky service provider or to just repay some technical debt > and clean things up. I wish that was brought forward earlier in the thread. Seeing as it's a maintenance burden, and it's impossible to write an application with some reasonable degree of expectation that Pocket support will be present in the host gnome-online-accounts framework, I think it best for it to be removed completely, so that applications don't try to use it in lieu of in-application independent support: https://gitlab.gnome.org/GNOME/gnome-online-accounts/merge_requests/18 > But it's a burden we can carry as long as we have someone committed > to > push it forward towards a better future. That future need not be in > two months time, but it has to be something that's more realistic > than > unicorns. Sorry, I don't understand what unicorns have to do with this discussion. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 19:47 +, Debarshi Ray wrote: > On Wed, Jan 23, 2019 at 05:39:44PM +0100, Bastien Nocera wrote: > > As Emmanuele mentioned, the problem isn't so much that services > > will > > disappear from under the applications (but it's a problem > > nonetheless), > > it's that there was no communication explaining that applications > > shouldn't have relied on GNOME Online Accounts in the first place, > > as > > the functionality could disappear for reasons not caused by those > > services, or applications. > > You are talking as if the application maintainer and the GNOME Online > Account maintainer are two disjoint entities. As if an active > community of contributors have been jeopardized by the arbitrary will > of the mythical GOA maintainer. > > That's false. You dropped maintainership of gnome-documents, we're now dropping it from core GNOME, and by removing the Documents integration from GOA, you're crippling the application, whoever the new maintainer ends up being. > [rishi@kolache gnome-documents]$ git shortlog -ns | head > 1036 Cosimo Cecchi >357 Debarshi Ray > 78 Alessandro Bono > 76 Daniel Mustieles > 68 Piotr Drag > 59 Bastien Nocera > 52 Kjartan Maraas > 39 Marek Cernocky > 36 Matej Urbancic > 36 William Jon McCann > > Since everybody is concerned about the Online Accounts integration, > let's look at gnome-online-miners.git. That's where the said > integration lives. > > [rishi@kolache gnome-online-miners]$ git shortlog -ns | head >101 Debarshi Ray > 6 Pranav Kant > > And I am just not going to bother digging up review statistics from > Bugzilla. ;) > > I was also the only maintainer at least pretending to keep up with > the > GNOME schedule. > > > There wasn't any active community. > > We regularly released with glaring bugs that some of our downstreams > would consider blockers. Fedora releases would have blocked, had > those bugs been known. They weren't known because very few people, if > any, ever used the application, so nobody ever reported them. > > RHEL 7.x releases actually did block on those bugs. That's how those > eventually got noticed, fixed and backported. > > Boy, did I spend hours diligently backporting all those fixes, > spinning tarballs, doing downstream builds. Sometimes the backports > went across three or four stable branches - that's how glaring and > old > some of the bugs were. Not a soul cared. > > These bugs were regressions introduced by the occasional patch that > would get merged, or by changes in our JavaScript stack, or something > else. The upshot being that the reviewers themselves weren't using > the > application much, or didn't have enough time to diligently review the > patches; nor did it have any users in the wider GNOME community and > beyond. > > It was also clear that the GNOME designers weren't that excited about > GNOME Documents any more. > > > Yes, I could have started by listing all the reasons behind why > Documents is considered a dead-end. I didn't do that, so I am very > sorry about that. Right, this is it. Thanks. > However, I did give a brief background in my very next email to this > thread. Cosimo, Michael, Jakub and Allan were all part of the > discussions about it's future. > > But then, I haven't yet found anybody honestly asking why we gave up > on it. Instead people went ahead and drew whatever conclusions they > wanted to draw. I find that odd. > > It's not like this is the first time we have dropped things from > GNOME > Online Accounts. Back in 2017 [1] we had dropped Telepathy. I had > written a wall of text explaining that decision. Guess how many > replies that thread got. Surely, Telepathy has had a lot more users > in its time than Documents. > > So, I do find it strange that people are suddenly coming out of the > woodwork passionately fighting for the survival of GNOME Documents. It's not Documents. It's Documents, and Pocket, and email integration, which brings about the viability of applications ever integrating with gnome-online-accounts, lest they be crippled. > > [1] > https://mail.gnome.org/archives/desktop-devel-list/2017-October/msg00040.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 11:54 -0600, mcatanz...@gnome.org wrote: > On Wed, Jan 23, 2019 at 9:03 AM, Bastien Nocera > wrote: > > It is what is happening in GNOME Online Accounts in general. Pocket > > is > > disabled in Fedora 29, and there's a good chance that the mail > > configuration bits will be disabled in Fedora 30. > > > > I don't know whether those changes will also be done upstream, but > > the > > result will be the same, it won't be possible for applications > > shipped > > through Flatpak to know that certain configuration options will be > > available in GNOME Online Accounts. > > Thing is, we don't have any email apps in core. It just doesn't make > sense to have email settings in gnome-online-accounts when none of > the > core apps (the apps installed by default) actually use those > settings. > It's just going to confuse users with settings that don't do > anything. And those upgrading will lose those mail accounts, right? > I don't really have strong opinions on the future of > gnome-online-accounts, but unless there are major design changes > along > the lines that have been suggested in this thread, then yes, I would > certainly advise against using it outside of the core apps. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 18:52 +, Debarshi Ray wrote: > On Wed, Jan 23, 2019 at 04:03:41PM +0100, Bastien Nocera wrote: > > On Wed, 2019-01-23 at 14:33 +, Allan Day wrote: > > > That's not what's happening here. Until very recently, Debarshi > > > was > > > the Documents maintainer, and he's obviously been fully involved. > > > > It is what is happening in GNOME Online Accounts in general. Pocket > > is > > disabled in Fedora 29, and there's a good chance that the mail > > configuration bits will be disabled in Fedora 30. > > Grep for "Future of Pocket in GNOME" from 24th August 2018 in your > inbox. Which solves what? You're removing the Documents and Mail categories, you're removing Pocket support. I'm more than annoyed because I didn't think that you'd disable and/or remove support for things that were already supported if they weren't broken, and I've spent a long while adding GOA support to grilo Lua sources so we could have Last.fm covers in Music, and watch Pocket'ed videos. I use GNOME Documents with Google Docs, I have a GMail mail account setup with GNOME Online Accounts, and I (seldom) watch Pocket'ed videos. Reading that mail you mentioned won't bring those features back. It's far from the first time you've wanted to remove Pocket support from GOA, as if it was a time sink, and a maintenance pain. I just don't understand the strategy of disabling/removing features and services, breaking apps on newer hosts. Please explicitely, "don't use GNOME Online Accounts if you're not a core app that's part of the system", if that's what it's going to be. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 10:27 -0500, Matthias Clasen wrote: > > > On Wed, Jan 23, 2019 at 10:03 AM Bastien Nocera > wrote: > > On Wed, 2019-01-23 at 14:33 +, Allan Day wrote: > > > Bastien Nocera wrote: > > > > > > > Flip it on its head and please suggest why, nowadays, any > > > > application > > > > developer, whether for a GNOME application or a third-party, > > would > > > > spend time integrating services into gnome-online-accounts, or > > > > using > > > > gnome-online-accounts for functionality that's somewhat core to > > the > > > > application experience, when the rug can be pulled from under > > your > > > > app > > > > at any point? > > > > > > That's not what's happening here. Until very recently, Debarshi > > was > > > the Documents maintainer, and he's obviously been fully involved. > > > > It is what is happening in GNOME Online Accounts in general. Pocket > > is > > disabled in Fedora 29, and there's a good chance that the mail > > configuration bits will be disabled in Fedora 30. > > > > I don't know whether those changes will also be done upstream, but > > the > > result will be the same, it won't be possible for applications > > shipped > > through Flatpak to know that certain configuration options will be > > available in GNOME Online Accounts. > > > > I believe in the larger picture, this is a logical consequence of > taking the boundary between desktop and apps seriously. Right, and a functional regression for applications (core or not) that relied on GNOME Online Accounts to enumerate services the user had setup and authenticate with them. As Emmanuele mentioned, the problem isn't so much that services will disappear from under the applications (but it's a problem nonetheless), it's that there was no communication explaining that applications shouldn't have relied on GNOME Online Accounts in the first place, as the functionality could disappear for reasons not caused by those services, or applications. > It is just not right to give all 3rd party apps that show up in a > flatpak access to the GNOME api keys and identity. > They need to use their own keys. Offering a centralized service for > storing such keys, as Emmanuele suggests, > might still be useful. With a per-app key usage, you end up losing the single sign-on, for example if you had 2 separate contacts applications, you'd need to login twice to authorise 2 contacts applications separately. The only thing you'd gain from this is that the application wouldn't need to reimplement the authentication. It would greatly reduce GNOME Online Account's "system" integration, turning it into a library to help with authentication. My own take away from this thread is that, as an application developer, I shouldn't count on GNOME Online Accounts at all for my app's core experience. Is that a fair assessment? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 14:33 +, Allan Day wrote: > Bastien Nocera wrote: > > > Flip it on its head and please suggest why, nowadays, any > > application > > developer, whether for a GNOME application or a third-party, would > > spend time integrating services into gnome-online-accounts, or > > using > > gnome-online-accounts for functionality that's somewhat core to the > > application experience, when the rug can be pulled from under your > > app > > at any point? > > That's not what's happening here. Until very recently, Debarshi was > the Documents maintainer, and he's obviously been fully involved. It is what is happening in GNOME Online Accounts in general. Pocket is disabled in Fedora 29, and there's a good chance that the mail configuration bits will be disabled in Fedora 30. I don't know whether those changes will also be done upstream, but the result will be the same, it won't be possible for applications shipped through Flatpak to know that certain configuration options will be available in GNOME Online Accounts. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 12:25 +, Allan Day wrote: > Emmanuele Bassi wrote: > ... > > > This approach isn't new, and you can read more detail here: > > > https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals > > > > > > > I know the rationale. I never particularly agreed with it, because > > it felt like an ex post rationalisation about not having third > > party modules, and getting people to commit functionality upstream. > > ... > > I don't think that was the reason. At least, it's not what's been on > my mind, and I don't remember others putting that view forward. > > The main factor has always been about how we handle identity. If we > give online accounts access to 3rd party apps, we're giving them > access to the GNOME keys. They appear as "GNOME" to online providers > and their access is bundled up with our own. As a result, we lose the > ability to ensure that the GNOME keys are being used in accordance > with providers' terms and conditions. > > From a design perspective that's never been something we've wanted to > do, both from a branding and identity perspective, as well as from a > "oh shit we can't access Google any more, because some random app did > something they didn't like". GNOME apps are not, and were never the only consumers of the gnome- online-accounts capabilities, and, correct me if I'm wrong, but the only problems we had with applications doing something that wasn't liked in the past were in *platform* components, not even in core applications. > > What I'm objecting to is the wishy-washy approach of telling > > people: "Sure, you can keep working on Documents, it's just not > > going to be installed any more" without telling the whole story. > > > > If Documents is removed, then all the Documents integration within > > GNOME is also removed, which means that the project *in its current > > incarnation* should just be archived. People should be encouraged > > to fork it, if they find it useful, and implement that integration > > inside Documents itself. This gives the proper context and > > communicates the proper expectations to people willing to maintain > > the Documents code base. > > If you think something can be done better, just suggest how it can be > done better. Flip it on its head and please suggest why, nowadays, any application developer, whether for a GNOME application or a third-party, would spend time integrating services into gnome-online-accounts, or using gnome-online-accounts for functionality that's somewhat core to the application experience, when the rug can be pulled from under your app at any point? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 10:48 +, Allan Day wrote: > Bastien Nocera wrote: > ... > > Removing GNOME Documents from the release is fine. The problem is > > that > > as it is removed from the release, it's an excuse for GNOME Online > > Accounts to remove the "Documents" category. > > My perspective: it's not great for our users if we have a Documents > switch in the settings, which from their perspective doesn't do > anything. I don't think we want people scratching their heads trying > to figure out what the controls do. The amount of resources needed to reimplement Documents support inside GNOME Documents for the 3 services that implemented it (Google, Windows Live and OwnCloud) would be higher than the amount of work needed to maintain that one toggle in GNOME Online Accounts and maintain GNOME Documents on top of that. Finding a way to have the Documents toggle be available to applications but not visible to users "browsing" the Online Accounts section of the Settings (or the equivalent page in the initial setup) would help a lot, rather than removing integration points that are much harder for applications to reimplement. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 10:39 +, Allan Day wrote: > Emmanuele Bassi via desktop-devel-list > wrote: > ... > > > We have a rule though: the account types exposed in > > > gnome-online-accounts must be used by at least one core > > > application. > > > It's a good rule because it doesn't make sense to have settings > > > in > > > control-center for apps that aren't installed by default. > > From a UX perspective I think this makes sense. It's a bit strange if > we have an out of the box experience where the switches in the online > accounts settings don't do anything. > > This approach isn't new, and you can read more detail here: > https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals > > > > So unless we > > > reverse course and add gnome-documents back to core, the > > > documents > > > account configuration settings should move from control-center to > > > gnome-documents itself. > > > > So you're asking that an application with known resource problems > > re-implements functionality that was offloaded to a GNOME component > > in the first place. This work, by the way, may or may not be > > dropped in case we change our minds, and find a use case for > > Documents to be in the core apps in the future. > > > > At this point it would be much more honest to come forward and say: > > "GNOME Documents is no more. If you want to work on it, fork it and > > call it whatever". > > I don't think it's fair to make accusations of dishonesty. Michael > and > Debarshi have been open about what's happening and the consequences, > and I think that's to be commended. > > My impression is that Documents isn't getting used very much, and we > don't seem to have a compelling story for it. It therefore seems > reasonable to stop integrating it into the core experience, unless > you > have a better idea? Removing GNOME Documents from the release is fine. The problem is that as it is removed from the release, it's an excuse for GNOME Online Accounts to remove the "Documents" category. You thought GNOME Documents wasn't useful? Wait until it can't access your online documents anymore! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Wed, 2019-01-23 at 10:17 +, Emmanuele Bassi via desktop-devel- list wrote: > On Mon, 21 Jan 2019 at 16:32, wrote: > > > We have a rule though: the account types exposed in > > gnome-online-accounts must be used by at least one core > > application. > > It's a good rule because it doesn't make sense to have settings in > > control-center for apps that aren't installed by default. So unless > > we > > reverse course and add gnome-documents back to core, the documents > > account configuration settings should move from control-center to > > gnome-documents itself. > > > > So you're asking that an application with known resource problems re- > implements functionality that was offloaded to a GNOME component in > the first place. This work, by the way, may or may not be dropped in > case we change our minds, and find a use case for Documents to be in > the core apps in the future. > > At this point it would be much more honest to come forward and say: > "GNOME Documents is no more. If you want to work on it, fork it and > call it whatever". The Pocket provider (used by FeedReader, and GNOME Videos) was also disabled from Fedora, and is apparently targeted to be removed. And the "Mail" category is also targeted to be removed in Fedora[1], already setup mail accounts be damned. I don't understand the need to remove those when they are still used (albeit not as much as it could be), when they don't seem to cause maintenance problems (compared to, say, Kerberos...). [1]: https://pagure.io/fedora-workstation/issue/67 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Mon, 2019-01-21 at 10:32 -0600, mcatanz...@gnome.org wrote: > On Mon, Jan 21, 2019 at 9:14 AM, Christopher Davis via > desktop-devel-list wrote: > > Hi Rishi, > > > > Cloud documents is an important part of where I want to move > > forward > > with the application, > > so Online Accounts integration would still be critical. > > > > A file previewer is definitely a priority, and an editor could be > > considered. > > > > Regards, > > Chris > > We have a rule though: the account types exposed in > gnome-online-accounts must be used by at least one core application. > It's a good rule because it doesn't make sense to have settings in > control-center for apps that aren't installed by default. So unless > we > reverse course and add gnome-documents back to core, the documents > account configuration settings should move from control-center to > gnome-documents itself. That would mean making the application not able to use a single facet of an account that's otherwise already setup (because there are 6 other toggles for Google accounts for example), and require the application to reimplement all the login procedure, re-authentication, etc. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documents and core apps
On Thu, 2019-01-17 at 12:07 -0500, Christopher Davis via desktop-devel- list wrote: > > Maybe if a new maintainer takes over and can find answers to those > > questions > > There is a current maintainer, but unfortunately they have not merged > anything in a few months. Despite what files in the repository there might say, no, there aren't any. > I am interested in taking > over maintainership and have sent out an email to a current > maintainer. Looks like you're our new maintainer then! Congratulations :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Documents and core apps
On Thu, 2019-01-17 at 17:04 +, Emmanuele Bassi via desktop-devel- list wrote: > On Thu, 17 Jan 2019 at 16:59, wrote: > > > Release and design teams also don't want redundant apps in core, > > and > > there is interest in somewhat reducing the number of apps in core. > > We > > had been planning for several years to remove eog (obsoleted by > > gnome-photos and to remove evince with gnome-documents. Now it > > looks > > like gnome-photos and evince will be the winners instead. (eog is > > a > > very nice app, but once gnome-photos gains the ability to handle > > images, it becomes kinda redundant, right? I only hesitate due to > > nomenclature: not all images are photos. Maybe gnome-photos needs > > a > > rename.) > > Removing Evince would have been slightly complicated even if > Documents were developed more heavily than it is because Evince is > used for the print preview in every GTK application, and nobody ever > considered writing the equivalent functionality for Documents in the > first place. Nobody added the ability for gnome-documents to open files... I'll probably split off Books at some point in the future. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts 3.34 won't have documents support
On Thu, 2019-01-17 at 15:17 +, Debarshi Ray wrote: > Hello everybody, > > It's been a month since GNOME Documents was removed from the set of > core utilities by the release team. See: > https://gitlab.gnome.org/GNOME/gnome-build-meta/merge_requests/157 > > We are currently in the 3.31.x / 3.32 development cycle. Once the > GNOME 3.32 release is done, starting from 3.33.1, I will be removing > the GNOME Documents specific integration points from GNOME Online > Accounts because we no longer encourage distributors to ship this > application as part of the default set. > > Have a nice day & happy hacking, That also means that GNOME Documents is as good as dead if you do this, because the main use for it was to have a single point of entry for Cloud and local documents. I think the release team is wrong in the first place. Lack of maintainership and bugs don't equate to removal. Otherwise there would be plenty more applications to remove there... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 2019-01-15 at 10:58 +0100, Emilio Pozuelo Monfort wrote: > On 15/01/2019 10:48, Bastien Nocera wrote: > > On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > > > Hey, > > > > > > It has been a few months since we moved to GitLab. Apart of > > > spurious > > > issues, specific annoyances and frustrations, seems it has been > > > generally good. I would like to gather some general feeling about > > > it. > > > Things that really made a constant impact to you and your work, > > > both > > > bad or good. Feel free to provide feedback about the transition > > > or > > > the administration of GitLab instance too. Free form. > > > > > > Please keep the mail chain one way from you towards the world, so > > > we > > > don't get trapped on specifics, we can address stuff raised here > > > individually out of list. Personally, I'll ping you on IRC or so > > > if I > > > can do something to help. > > > > > > Of course, feel free to msg me directly on IRC/email too. > > > > My main problem is/was that contributing by pushing a branch is > > super- > > easy, but you can't contribute by pushing a branch if you're not > > allowed to push a branch. So this isn't a problem when you're in > > @GNOME, and the project is as well, but I've not bothered pushing > > small > > fixes to non-GNOME group modules. > > It should still be easy to fork the project, push a branch to your > namespace, > and then submit a MR. Or did I misunderstand? Too many trips to the web browser, too many re-clones of the repo (or esoteric git command-lines), and too many left-over repos in your own namespace. It's a problem I have with github as well, it's the same workflow. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Tue, 2018-12-11 at 14:22 +0100, Carlos Soriano wrote: > Hey, > > It has been a few months since we moved to GitLab. Apart of spurious > issues, specific annoyances and frustrations, seems it has been > generally good. I would like to gather some general feeling about it. > Things that really made a constant impact to you and your work, both > bad or good. Feel free to provide feedback about the transition or > the administration of GitLab instance too. Free form. > > Please keep the mail chain one way from you towards the world, so we > don't get trapped on specifics, we can address stuff raised here > individually out of list. Personally, I'll ping you on IRC or so if I > can do something to help. > > Of course, feel free to msg me directly on IRC/email too. My main problem is/was that contributing by pushing a branch is super- easy, but you can't contribute by pushing a branch if you're not allowed to push a branch. So this isn't a problem when you're in @GNOME, and the project is as well, but I've not bothered pushing small fixes to non-GNOME group modules. Per-commit reviews are absolutely head-against-the-desk because the UI is really bad, and the diff tool is sluggish. I miss splinter if I have more than one commit to review. All-in-all, it's still a better, and known, workflow for people who didn't want to, or couldn't learn about git-bz, and having a CI available is awesome. Don't even need to spend a second reviewing patches that don't build ;) Good job :) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: App menu retirement: outstanding MRs
On Thu, 2019-01-10 at 12:37 +, Allan Day wrote: > Hi all, > > With a little over three weeks until UI freeze, I wanted to share a > summary of the outstanding tasks for the app menu retirement > initiative [1]. > > Every one of the target apps now has an MR to retire the app menu > (great work everyone!) The challenge now is to get them all merged in > time. The outstanding MRs are: > Cheese > Dictionary > Disks > Documents > Help > Photos > Polari > Rythmbox (this is an outstanding X11/Wayland bug) > Screenshot > Videos > Help getting these merged would be most appreciated. > > Also, the screenshot change seems to have evolved into a more general > redesign. Who do I speak to about that? The Videos change would also require a great deal of work, with no definite target design actually selected. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GUI automation framework
On Wed, 2019-01-09 at 09:57 -0500, Michael Terry wrote: > Does GNOME have a currently recommended automation framework for > tests? > > I know dogtail, ldtp, and such were used in past. But I haven’t seen > much talk in recent years about this part of the stack nor was I able > to find any recent wiki pages about it. > > Is dogtail still the state of the art? Still dogtail, and there's a bridge to use it under Wayland: https://gitlab.gnome.org/ofourdan/gnome-ponytail-daemon Fedora packages: https://copr.devel.redhat.com/coprs/ofourdan/ponytail/ Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtkdoc help wanted tickets
On Fri, 2018-11-30 at 13:08 +0100, Stefan Sauer wrote: > hi, > > for the near future I won't be able to work on gtk-doc feature requests. > I am cleaning up the code to make it testable and converting the silly > integrations tests into unit tests. This will help to get pasring > issues/bugs under control with less chance of causing regressions. > > Here are the current feature requests, if someone would like to help: > > https://gitlab.gnome.org/GNOME/gtk-doc/issues?scope=all=%E2%9C%93=opened_name[]=4.%20Help%20Wanted_name[]=4.%20Newcomers > > Remember, it is now python, so no perl knowledge needed anymore. > > > Also is there someone who could help to turn gtkdoc into something that > can be published on pypy, so that people can pull the latest with pip? Having filed a bunch of feature requests and bugs against gtk-doc recently, I ran into the problem that, in addition to my Python only being slightly better than my Perl, I had trouble finding what parts of the code generated the code that I wanted, and how to create small test cases for the problems I was filing bugs about. Some guidance on the bugs, like which function should be modified, or where to start prodding, would definitely be useful, at least until the internals themselves are better documented. (as for PyPi support, I personally build gtk-doc in jhbuild, and build my modules that use gtk-doc in jhbuild as well, so I always have the latest gtk-doc to generate docs, contributors would probably want to use gtk-doc from git in any case) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: This video is dedicated to all of you
On Wed, 2018-10-17 at 21:52 +, Olav Vitters wrote: > On Wed, Oct 17, 2018 at 06:32:44PM +0100, Emmanuele Bassi via > desktop-devel-list wrote: > > On Wed, 17 Oct 2018 at 18:30, Bastien Nocera > > wrote: > > > > > On Wed, 2018-10-17 at 19:24 +0200, Alberto Salvia Novella via > > > desktop- > > > devel-list wrote: > > > > https://youtu.be/ > > > > > > How is this person still allowed to post on d-d-l? > > > > > > > Yes, can we please enable some moderation? Not only this stuff is > > obnoxious > > trolling, but people are replying to it. I dontyreally want this > > stuff in > > my inbox. > > Mailing lists suck IMO, especially mailman2 where you need to > remember a > password and in case you forgot you'll need to ask a sysadmin to make > a > new password for every moderator. Mailman3 would fix this, but super > slow development pace last time I checked. Ideally it would be a more > free for all. > > I didn't see the previous emails from Mr. Novella. He sent something > many months ago. I find d-d-l rather quiet. This email I would even > have > opened based upon the subject as it is pretty spammy. > > I've set the moderation bit on Mr. Novella but do think asking for > moderation is overlooking that if you follow various other GNOME > discussion methods you'll find a way lower signal to noise ratio > (many useless comments per hour). What does this have to do with the fact that the mailing-list needs to be moderated? It's just whataboutism. If keeping track of the mailing-list admin password is too complicated, I'd be happy to help moderate it. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: This video is dedicated to all of you
On Wed, 2018-10-17 at 19:24 +0200, Alberto Salvia Novella via desktop- devel-list wrote: > https://youtu.be/ How is this person still allowed to post on d-d-l? ___ 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, 2018-09-28 at 16:53 +0100, Alberto Ruiz wrote: > > > 2018-09-28 15:32 GMT+01:00 Allan Day : > > Florian Müllner wrote: > > > > > > With regard to dropping the 'quit' action, is there any guidance > > for > > > background applications? That is, apps where closing all windows > > does > > > *not* exit the application, but the explicit 'quit' action does. > > > > FWIW, the app menu "Quit" does not quit Telegam, so this is worth > exploring though a bit orthogonal to the question of removing the > menu. Probably because it doesn't actually have an app menu, so gnome-shell adds one with a single entry, which would do the same thing as closing (all of?) the app's windows. ___ 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, 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. ___ 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, 2018-09-21 at 12:24 +0100, Allan Day wrote: > Bastien Nocera wrote: > ... > > > Putting aside the issue of outdated user docs, > > > > Well, it's a pretty big factor here. > > Can't we just remove out of date user docs? We certainly can, though that means there's no place to put the keyboard shortcuts then ;) > I realise that my line of reasoning is somewhat hypothetical here, > but > if there are issues with the user docs, we ought to fix them. > > > > do you experience any > > > advantages having keyboard shortcuts in the shortcuts window, as > > > opposed to the help? > > > > 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. The docs would still show up in a separate application, and you'd be mixing writing styles. The user docs are usually more verbose, and the keyboard shortcuts are terse. Their terseness and searchability make them pretty good to discover application features, compared to menu item searching for example. > 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. Obviously, cross-linking would be useful, but I wonder how much there is to gain having "Pressing the Play button will start playback" in the docs. I guess whether saving space is useful might depend on the application's menus, I don't think that's a major problem for Videos, maybe it's a different problem for apps like Web. > > it's usually better updated > > as it lives in the code, as opposed to being separate in the docs. > > I can see how that's an advantage, but it also feels like a bit of a > workaround, if we assume that we need up-to-date user docs one way or > another... ___ 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, 2018-09-21 at 14:26 +0100, Allan Day wrote: > On Fri, 21 Sep 2018 at 12:54, wrote: > > > > On Fri, Sep 21, 2018 at 5:36 AM, Bastien Nocera > > wrote: > > > It's faster to access for users, has terser explanations (no need > > > to > > > create sentences to describe actions) and it's usually better > > > updated > > > as it lives in the code, as opposed to being separate in the > > > docs. > > > > It's also larger, well-designed, easier to read and use. > > But what if the docs were similar...? This is a hypothetical future, > not what we have today. Still takes you out of the application itself. ___ 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, 2018-09-21 at 11:05 +0100, Allan Day wrote: > Bastien Nocera wrote: > ... > > ... The keyboard shortcuts dialogue in Videos is invaluable. > > > > Its contents used to be in the README file, which users wouldn't > > see, > > the user documentation still shows the old interface (from 4 years > > ago), and I'd rather not rely on user docs if I can help it. > > Putting aside the issue of outdated user docs, Well, it's a pretty big factor here. > do you experience any > advantages having keyboard shortcuts in the shortcuts window, as > opposed to the help? It's faster to access for users, has terser explanations (no need to create sentences to describe actions) and it's usually better updated as it lives in the code, as opposed to being separate in the docs. > I can see the advantage for a large and complex app, where you might > want to regularly check shortcuts, as a quick reference. In the case > of a simple app, it's less clear to me what the advantage is over > having shortcuts in the docs. Having a quick access to searchable shortcuts is a good way to learn those shortcuts little by little, or get to know about specific shortcuts without taking you out of your task. Opening a separate, more verbose, documentation breaks that immersion. ___ 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 Thu, 2018-09-20 at 15:07 +0200, Alexandre Franke wrote: > 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. I also think that the least amount of user documentation is necessary, the better. The keyboard shortcuts dialogue in Videos is invaluable. Its contents used to be in the README file, which users wouldn't see, the user documentation still shows the old interface (from 4 years ago), and I'd rather not rely on user docs if I can help it. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk-Doc Manual in DevHelp
On Fri, 2018-08-03 at 09:03 +0200, Sebastian Geiger (Lanoxx) wrote: > Hi all, > > I have tested my patch and I can view the GTK-Doc Manual in DevHelp. > I > would be very happy if this change could be merged into Gtk-Doc. Sorry, but I don't quite understand what you're asking of the wider community. The patch was merged in this MR: https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/3 Was there anything else that needed happen? > [1]: https://developer.gnome.org/gtk-doc-manual/ > > [2]: https://gitlab.gnome.org/GNOME/gtk-doc/commit/ffd5f97ed73a670f1b > 7687d9a39e80f5f7941332 > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Wed, 2018-03-21 at 17:37 -0400, Shaun McCance wrote: > Hi Carlos, > > I think we might be talking about two different things. I was just > referring to CGit links, not anything with bugs/issues and users. For > example, redirecting this: > > https://git.gnome.org/browse/nautilus/tree/README.md > > to this: > > https://gitlab.gnome.org/GNOME/nautilus/blob/master/README.md > > And in constructing this example for this email, I discovered that > this > redirect ALREADY WORKS. Nevermind me. Carry on being awesome. It only works partially. Fragments can't be redirected, and GitLab doesn't seem to be willing to add the one-liner to the code: https://gitlab.gnome.org/Infrastructure/GitLab/issues/126 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's kill gnome-common!
On Tue, 2018-02-13 at 15:13 +0100, Frederic Peters wrote: > > On Tue, 2018-02-13 at 11:19 +, Emmanuele Bassi wrote: > > > Work is in progress to let maintainers upload tarballs with the > > > generate API reference for developer.gnome.org > > > > Hi, > > okay, how is that supposed to work in general? As Meson builds out > > of > > the source tree, is that "work in progress" meant to be Meson > > specific? > > Developer.gnome.org still looks for "markers" in source tarballs > (like > include gtk-doc.make in Makefile.am) and use those to extract the > documentation module name (ex: for gtk+ it would extract three doc > modules, gtk4, gdk4, gsk4). > > What's new and in progress is the possibility to map those modules to > external documentation tarballs that will contain the generated HTML > files. > > Some parts of the process are in place already, from manually > generated documentation tarballs for GTK+, published at: > https://download.gnome.org/docs/gtk+/3.93/ > we can now create https://developer.gnome.org/gtk4/3.93/ > > (this is very fresh, literally two days ago) > > Now no maintainer would want the burden to generate those additional > tarballs and they should be automatically created and published by a > CI system (gnome continuous or buildstream or whatever). > > Wrt evolution developer.gnome.org still lacks the code to find the > gtk-doc markers in CMakeLits.txt files. (some experimental code was > added for meson as used in GTK+) I have a few platform-level daemons that could do with having their gtk-doc on developer.gnome.org. Is there an example of what commands would need to be run to create and package the docs, and how to get them installed on gnome.org? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
