Re: Changing version scheme for the evolution projects
On Mon, 2022-09-19 at 08:21 +0200, Milan Crha via desktop-devel-list wrote: > Maybe. Hi, just to close this thread with a conclusion: there had been multiple opinions (I received some also as private responses), and because I do not have any strong reason for the change and the most opinions were in a way "why to make any change", thus I decided to _not_ change anything and keep the versions as it is now. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving final mailman lists over to discourse
On Thu, 2022-09-29 at 16:48 +0100, Neil McGovern wrote: > For those which should close, they've had very low activity (in some > cases, zero...). Hi, I think you can safely close also the evolution-hackers list. It used to be used to announce or ask development/developer related questions/info, but it's not needed anymore. I believe the same information can go to the evolution-list. In fact, people sometimes ask user questions on the hackers list, thus the two lists could be confusing too. > > For both, the archives will be preserved, but they won't accept or > distribute any new mail after the end of October. Could you remind me, please? Will there be a general mail sent to the lists about the information and a link or inline instructions what to do and how to still receive mails from the discourse related to the list, or it's up to the current mailing list owners/admins to send the sunset announcement to their subscribers? I suppose it's the former, but I'm not sure. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Changing version scheme for the evolution projects
On Fri, 2022-09-16 at 08:41 -0500, Michael Catanzaro wrote: > I'm glad you're phasing it out, but doing something > different from the rest of GNOME is inherently confusing. Hi, I think any change is always confusing at the start. My idea behind x.y.0.90 is that the tweak number being so high suggests the release is something just before the main (stable) release. GNOME used to have .90, .91,... before too. As the scheme follows something well established in another project(s) (even not GNOME) might be helpful. Maybe. > In contrast, everyone knows how to handle alpha/beta/rc and knows > what they mean. Just use tildes instead of periods in the appstream > metadata (43~alpha, etc.) It has a little catch, when it does such a dull person like me, I always forget to change the dot into a tilde not only in the appstream data, but also when packaging. That's my problem, of course, not paying enough attention or whatever, but it's also much better to not need to pay attention, to have things done properly without recalling things. As had been said in other mails in this thread, the tilde is just a workaround for the problems the alpha/beta/rc causes to other parties. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Changing version scheme for the evolution projects
Hello, I'm thinking of changing version scheme for the evolution-data-server, evolution, evolution-ews and evolution-mapi. It still uses the "old" GNOME version scheme, meaning odd minor version (aka 3.45.x) being a development series, even minor version (aka 3.46.x) being a stable series. The current GNOME version scheme doesn't do that, as you know. I'm afraid it can be confusing for some parties, when these evolution projects are under the GNOME umbrella. I do not like the alpha/beta/rc thing, it has several bad consequences [1], version number should be a number, not a letter. My personal opinion. Anyway, what I'd like to use is similar to the gcc version scheme. That is, x.y.0 will be a development part of the x.y series. The first stable version will be x.y.1 (see the '1' being the first? GNOME's first development release also used to be x.y.1). For the next series it would be: 3.47.0.90 ... GNOME's .alpha 3.47.0.91 ... GNOME's .beta 3.47.0.92 ... GNOME's .rc ... here's a gap for urgent development releases up to .99 3.47.1... GNOME's .0, aka the first stable release Unless there's any strong objection, I'd like to do it this way since the 3.47.x, aka GNOME 44. I should think of this earlier, but I'm slow in thinking, which is a shame. You might ask why not to drop the leading '3' for the Evolution and sync with GNOME's 44 at the same time. The reason is technical. The evolution projects tightly depend on each other, evolution x.y.z requires evolution-data-server x.y.z; evolution-ews a.b.c requires evolution a.b.c and evolution-data-server a.b.c. Yes, these things can be written in the configure scripts, but I do mistakes all the time, thus having this version dependency done automatically, with no human interaction, is a valuable bit I would like not to lose. Opinions? Bye, Milan [1] https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/1378#note_1464311 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [heads-up] evolution-data-server is libsoup3 now
On Wed, 2022-06-22 at 21:36 +0200, Marcus Lundblad wrote: > Maps still depends on libsoup 2 (we get this dependency via > libchamplain, and it is unlikly to get ported…) Hi, Evolution also (optionally) depended on libchamplain and I disabled it due to this libsoup2 dependency. I know it's not an option for you. > I'm a bit concerned about being able to pull it off this late in the > cycle. I'm sorry for pushing it this late, there had been pending some other projects to be ported, and some changes on the libsoup3 side, without which the work could not happen and would be postponed for another 6 months. And the release team decided to do it now ;) > One option I think is to drop the contact address lookup in Maps (we > use e-d-s via libfolks to match searches on contacts who have > addresses). Right, it's unfortunate, but it's an option for now, as Michael said. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
[heads-up] evolution-data-server is libsoup3 now
Hello, just a quick heads-up, the evolution-data-server development version is libsoup3 now; it will be the 3.45.1 release. The port depends on libsoup3 change [1], which improves libsoup3 use in multi-threaded applications. Most people are probably aware, all apps using the evolution-data- server directly or indirectly need to use libsoup3 as well, the same their dependencies, because libsoup2 and libsoup3 cannot be loaded into the same process at the same time (doing so aborts the application with an appropriate message). One thing, the libgdata has a pending merge request for the port to the libsoup3, but it needs more testing and such. Use -DENABLE_GOOGLE=OFF CMake option until it's sorted out. The option disables the Google tasks support only. I may extract necessary bits out of the libgdata to not depend on libgdata at all, but no promises whether I'll make it on time for the 3.45.1. See [2] for some insights. Of course, Evolution itself and evolution-ews will be ported to the libsoup3 at the same time. Bye, Milan [1] https://gitlab.gnome.org/GNOME/libsoup/-/merge_requests/283 [2] https://discourse.gnome.org/t/giving-up-maintainership-of-libgdata/9983 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 40.5 released
On Thu, 2021-11-04 at 09:06 -0500, Michael Catanzaro wrote: > The list of updated modules and changes is available here: > > https://download.gnome.org/core/40/40.5/NEWS Hi, the NEWS file says the gnome-autoar had been downgraded, while there had been a new release almost a week ago. Is that a bug or it was intentional downgrade? Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Chat Evaluation Interviews
On Fri, 2021-02-05 at 11:01 +0100, Kristi Progri wrote: > I will check the poll for the final results by Sunday (7th) Hi, only checking, do you really mean to give people only ~two days to fill it, or even to notice your mail here? It feels like a short notice, from my point of view. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's improve our communication: Discourse
On Mon, 2020-09-28 at 10:26 +0200, Sam Thursfield via desktop-devel- list wrote: > It sounds like a good idea to automatically subscribe users to this > tag on discourse.gnome.org. Hi, this kind of behavior can be seen as a spam attempt, especially when it's done silently, behind people's back, despite any good intention. You do not want to fight with the people (or the governments where it's considered illegal) for sure. I believe what Michael did is a good way (or the best way) to advertise the changes. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Let's improve our communication: Discourse
On Fri, 2020-09-25 at 14:33 -0500, Michael Catanzaro wrote: > and make contributing to GNOME more attractive to newcomers. Hi, do you think the newcomers do not know how the mail works? Or it's used as an excuse to replace something working for years with something new, with new bugs, its maintenance requests and such? Just wondering. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC
Hi, On Thu, 2020-05-28 at 19:46 +0100, Zander Brown wrote: > I think it's clear it was supposed to be humorous Right, right, I didn't mean to offend anyone. If I did, I apologize for that. I guess Fridays are also not the best days for maintenance, unless admins are ready to deal with issues over the weekend. It's only my humble opinion, of course. I've no idea of usual admin workflow. I definitely appreciate admin's work, that's not a toy to keep the infrastructure running, with all its services. Thanks for it. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab Container Registry scheduled maintenance, Friday May 29, 10 UTC
On Thu, 2020-05-28 at 17:13 +0200, Bartłomiej Piotrowski wrote: > We're sorry for this inconvenience and at your disposal in case of > your questions. Hi, this is the second time you plan something bigger, some server maintenance, at the days when the releases are supposed to happen. Is there a pattern? To make life more interesting to the maintainers? I've no idea what this particular work can influence and how it'll work with the release process, but still... Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab migration: Thursday, March 26, starting 23 CET
On Thu, 2020-03-26 at 08:37 -0500, Michael Catanzaro wrote: > Tarballs are always due on Saturday. We don't have Monday deadlines > anymore. Hi, yes, I know. That's the reason why I moved to Friday releases. > there should still be plenty of time to do so afterwards on Friday > or Saturday if everything goes as planned. It depends which part of the globe you reside, aka the time zone, how your day is scheduled and so on. Let's see how the things will go. Maybe I'm too "proactive" here. By the way, the schedule for 3.38 is still open. I noticed your thread on the release-team, dated like two weeks ago. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab migration: Thursday, March 26, starting 23 CET
On Thu, 2020-03-26 at 09:14 +0100, Bartłomiej Piotrowski wrote: > gitlab.gnome.org will be down during migration to the new data center > starting today at 23 CET. Unfortunately due to the amount of data it is > not feasible to migrate without downtime. As transferring the data will > take about 6 hours, we estimate it will be operational again between 9 > and 12 CET on Friday, March 27. The code will be still accessible from > GitHub mirrors. Hi, it seems it clashes with 3.36.1 release schedule (to be done till 28th this week), thus if anything goes wrong... I also moved to release on Friday, instead of Monday (weekend is out of question here), thus having git/gitlab.gnome.org unreachable for the whole morning makes it difficult here. Or is it only about gitlab.gnome.org, thus git.gnome.org will left unaffected? If so, then it's fine. If not, I guess it's too late to postpone the migration and do it after the release time, is it not? Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Too hard to get org.gnome.Sdk.Debug from flathub
On Thu, 2020-03-19 at 10:00 -0500, Michael Catanzaro wrote: > It's a lost battle. The flathub infrastructure is clearly broken and > has been for a very long time. It's reasonable to refuse to debug > flatpak problems until this is fixed. Hi, yeah, that's okay. I worked around that by building offending part myself and installed debuginfo for it together with the project. Not an ideal solution, but it helped. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Too hard to get org.gnome.Sdk.Debug from flathub
Hello, I'm trying to debug a crash in libsecret when using 3.36 runtime on Fedora 32 Beta in Flatpak, with an application from flathub.org (that application being org.gnome.Evolution). My idea was to download the .Debug parts, to see where exactly it crashes. It was no problem for Evolution itself, but there is no such thing for org.gnome.Platform. There is something for org.gnome.Sdk, from which I guess it contains bits also for the Platform. The flatpak claims to download 3.6GB, which is a lot, my bandwidth is limited, thus it takes a lot of time. I'd run it in the background, but I never got that far, or anywhere close to the 3.6GB, which makes it impossible to download the data for me. The worst it doesn't stop at the same place, I've no idea what the condition for the failure is. The server just returns 503. This failure could be fine, if flatpak was able to continue the download, but it's not. See the transcript from the terminal for my recent attempts [1]. My question is: is there anything one can do to get to those bits, or it's just a lost battle? Maybe, could the .Debug be split into smaller parts, thus it's bearable when the download fails (due to the server error)? I think there had been some similar issue with curl or something, which caused various errors on download, but I do not recall any detail. On the other hand, this is Fedora 32 Beta, thus quite recent bits. Aka should be fixed there. Thanks and bye, Milan [1] https://people.gnome.org/~mcrha/dwnld.txt ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to manually update https://help.gnome.org/users/$PROJECT?
On Wed, 2019-10-02 at 11:58 +0200, Frederic Peters wrote: > gnome-doc-list@ would be the right place, especially as there are > plans to redo help.gnome.org. (ditto for developer.gnome.org). Hi, done, thanks. https://mail.gnome.org/archives/gnome-doc-list/2019-October/msg0.html > fwiw if someone familiar with Python wants to look at it Unfortunately I do not speak pythonish, otherwise I'd be glad to help. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
How to manually update https://help.gnome.org/users/$PROJECT?
Hi here, I'm not sure whether this is the right list for this, thus I'm sorry if it's not. Feel free to redirect me to the right place. I'd like to ask: how do I manually update content of https://help.gnome.org/users/$PROJECT , please? As (I guess) the [1] is no near to be fixed/implemented (even though basically whole GNOME is affected, due to released tarballs not containing needed files), I'd like to update it manually, if it's possible. In case of Evolution it contains the help version from 3.22.2, which had been released almost three years ago. There had been done a lot of improvements in the help during that time, involving changes not only for new or changed features, but also changes suggested by the users for some clarifications and such. It's a shame to give pointers to an outdated user documentation (yes, people do use https://help.gnome.org/users/$PROJECT/stable/. to give pointers to users whom ask questions which are covered in the user documentation). I do not care of the process, I'm even fine to do it repeatedly around the "main" (x.y.0) release. It could be a script on the master.gnome.org, similar to ftpadmin-install, to which I'd pass packed $PREFIX/share/help/ (without this path, containing only one project help pages, in generated languages) .tar.xz and it may copy it to the right place. Such script could have additional arguments, like the version the help corresponds to (like x.y), and the project name to use. As the help files do not seem to contain the $PREFIX path it should be relative simple both for project maintainers and for the admins. I hope. This would be much better than nothing. I do understand there are obstacles implementing this as an automated task during release, I do not want to blame anyone involved in [1], that's not an intention of this email. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=785522 transferred to https://gitlab.gnome.org/Infrastructure/Websites/issues/224 then to https://gitlab.gnome.org/Infrastructure/library-web/issues/50 ___ 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 Wed, 2019-09-11 at 14:09 +0200, Andre Klapper wrote: > * Stable maintenance releases over a longer period Hi, does it make sense to have 3.34.5 at the time of 3.36.1? I guess not for majority of the projects. Even if it would be a soft requirement, it happens that the stable branch doesn't get that much attention after the first half, like after 3.x.2. I do not tell it, because previous schedules ended with 3.x.2, I released up to 3.x.5, which was usually aligned with 3.x+1.90 release. I do not think forcing even soft requirement for more stable releases make any sense, if the maintainers would like to give users more fixes in the current stable version, they are already doing it. There are projects which do that, even for older stable releases, but it's a real minority. 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. Just my opinion and experience from the past years. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: earlier tarball deadlines
On Wed, 2019-08-14 at 13:04 -0500, mcatanz...@gnome.org wrote: > I'd like to propose moving tarball deadlines for the 3.36 cycle one > business day earlier, from Mondays to Fridays, while leaving the > overall release deadline on Wednesday. Hi, my personal preference is on Monday, thinking that (community) translators have time over the weekend to finish their translations before the release. I do not have any statistical data whether any/many really do that, though I believe it would make sense to give them more time at least later in the release cycle (moving the release to Friday just before x.y.0, where only translations are allowed (without approval) doesn't make much sense to me, because there are not expected any code breakages when no code changed). In other words, I suggest to not move all tarball releases before the weekend. I'm afraid moving the deadline will not help to get all releases on time. People are free to release sooner, still only a few of them do that. That's only my opinion/observation though. Otherwise I've no strong opinion, if you'd like to move the tarball release date in order to help the release team, then I'm fine with it. Being it Friday or Saturday doesn't play any role here, I'd probably do it on Friday in both cases (because I can release earlier ;) ). Bye, Milan ___ 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 10:13 -0300, Isaque Galdino via desktop-devel- list wrote: > Notes is failing due to EDS. Once EDS changes to gettext, Notes > should be fine. Hi, from what the Goal page references: https://gitlab.gnome.org/GNOME/evolution-data-server/issues/77 Long story short: This won't happen (any time soon). If you have any flatpak/CI/whatever, which depends on evolution-data-server to be built too, then include intltool in the Flatpak manifest for it. I'm sorry. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System-wide dark mode
On Wed, 2019-06-05 at 23:14 +0500, Alexander via desktop-devel-list wrote: > Since WebKit supports Apple's dark mode now, I wonder if mail > clients (and also Devhelp/Builder) will be able to provide styles for > dark mode with that. Hi, from one of the mail application point of view (being it Evolution here), the problem with HTML mails is that some clients did/do generate HTML where they declare only text color, but no background color, and bet the text color is black. Black text color on a dark theme background is not ideal for reading, thus the HTML mails are set to use white background by default. When you count all the (not only) CSS tricks and various elements it's not that easy to change the color of the text in an HTML code generated by "random" mail client. I know it's awful and bad for eyes in the dark theme, but there was not found anything better. Plain text messages are different, there's no formatting, thus the user's theme is respected with them. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.33.2 released!
On Sat, 2019-05-25 at 23:04 +0100, Abderrahim Kitouni wrote: > I had to disable gnome-contacts, gnome-calendar and gnome-maps > because of the not-very-well coordinated evolution-data-server > transition. Hi, if I read the dependencies correctly, then gnome-contacts and gnome-maps depend on folks, whose related change landed at the same time (+/- minutes) as the evolution-data-server, but I cannot find a release of folks, thus maybe that's the reason. Similarly with gnome-calendar, the related change is in the sources, but no tarball release of it had been done yet. Bye, Milan ___ 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 Thu, 2019-05-16 at 18:59 +0200, Milan Crha via desktop-devel-list wrote: > All the project references can be found here: > https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 > > I'll send another email when the main parts (and those I received a > green for) are committed. Hi, as promised, the evolution-data-server changes landed few minutes ago and will be part of the 3.33.2 release. If anything arises, please, let me know, either here in this thread, or with a private message or in the above issue. Thanks and bye, Milan ___ 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 Thu, 2019-04-18 at 13:52 -0500, mcatanz...@gnome.org wrote: > Please commit all the changes to folks, gnome-calendar, and gnome- > shell at the same time as evolution-data-server to avoid breaking > gnome-build-meta. Hello, I'd like to let know that with the just released libical 3.0.5 I'll be pushing the changes into the GNOME repositories tomorrow. Unfortunately before the weekend, the timing is not ideal, but it is how it is. I'll check this list on the evenings in case any fire will happen. Or write to me directly, if anything arises during the weekend. I'll fix the things on Monday the latest. The GNOME projects have merge requests prepared, though they need some polishing (like with the version number requirement on evolution-data- server). Otherwise they should just work, in case the master branch changes of the respective project didn't "break" them. This is also to know the maintainers about these changes, thus they can release on Monday with patched sources. All the project references can be found here: https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 I'll send another email when the main parts (and those I received a green for) are committed. Bye, Milan ___ 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: > I found these hosted on GNOME: Hi, I've a little update on the dependencies and the porting preparation progress. Those prepared are: almanah https://gitlab.gnome.org/GNOME/almanah/merge_requests/3 bijiben alias gnome-notes https://gitlab.gnome.org/GNOME/gnome-notes/merge_requests/22 folks https://gitlab.gnome.org/GNOME/folks/merge_requests/10 gnome-calendar https://gitlab.gnome.org/GNOME/gnome-calendar/merge_requests/70 gnome-shell https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/501 Partially prepared is gnome-todo, because I've some trouble to build the master branch of it, thus I prepared the changes for the gnome-3-28 branch. More is written here: https://gitlab.gnome.org/GNOME/gnome-todo/merge_requests/89 Some didn't need any change, they were: ekiga (uses the old deprecated EBook, not EBookClient API) glabels gnome-contacts As Bastien reminded in the other subtread, gnome-phone-manager is archived, thus I'm skipping it for now. I may attach a patch for it and other not-hosted-on-GNOME project at the eds report, thus they are easily findable: https://gitlab.gnome.org/GNOME/evolution-data-server/issues/33 These hosted on GNOME, which are still to be done: california - that's just Vala, but I do not speak Vala, thus any help would be appreciated. It seems the project is currently unmaintained. evolution-activesync - this will be fun, but it's not a critical component for the GNOME, thus I'll keep it for now, similarly as all the other dependencies (not hosted on GNOME). The libical 3.0.5 release is planned by the end of this April, +/-, after which it might be possible to move things forward, from my point of view. Depending on the actual date of the libical release, I'd commit the eds changes a week after it. It's not much time, I agree, but it could be around May 7th, which is ~2 weeks after the 3.33.1 release and a bit less than 3 weeks before the 3.33.2 release, which sounds good, I hope. Thus, unless there is any objection, I'd stick with this plan. I'll continue preparing other projects, to have them ready on time and make the transition as smooth as possible. One thing, with the prepared merge requests [which will need changes in the version reference (they reference libecal-2.0 as 3.33.1, while it'll be a different version)], should I contact respective maintainers anyhow specifically, other than through the gitlab and this mailing list, thus they know about the change? And once the eds changes are committed, should I still wait for them for an approval, or should I just commit, at least for those projects which are related to GNOME Continuous and other services, which will break once the evolution- data-server changes are committed? I do not want to touch their code without them knowing about it, I do not like it myself, thus I'm looking for some advice how to make it smooth and coordinated. There's plenty of time, probably 3 weeks, and the merge requests are quite fresh, I didn't expect any quick reaction on them (even I did receive one, which was impressing), but I like to be prepared and behave like a good citizen. Thanks and bye, Milan ___ 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 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). Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Upcoming evolution-data-server API changes (libical-glib + more)
Hello, this is kind of heads-up e-mail about upcoming API changes in evolution-data-server. I also do not like them, but they are sometimes necessary. The first part is about porting the calendar to use libical-glib [1], instead of libical, in order to finally provide introspection for it. The change was so huge that it deserved an API bump from 1.2 to 2.0 (libecal-1.2 and libedata-cal-1.2 will become libecal-2.0 and libedata-cal-2.0). The API around ECalComponent and its structures had been made introspection friendly too. I took the opportunity and removed all the deprecated and obsolete stuff from libecal and libedata-cal. This work depends on the unreleased libical git master, but there's planned a 3.0.5 release of it with the necessary changes. The second part was about preparation for passing flags from the client towards the backend to influence behavior. It was initially meant for this issue [2], but I extended it to pass also information about conflict resolution for write operations. This change touched all the APIs - the client side API, the server side API and the D-Bus API. The last is probably the most disturbing, at least in case of the Flatpak applications, which build against some version of the evolution-data- server, but rely on the host system evolution-data-server (it's possibly broken on both sides, aka building with new eds, but run with old, or build with old eds, but run with new). I'd say the best option for such applications is to run the eds services inside the Flatpak sandbox, which has the advantage that also the server side fixes are included in the application, not only the client side fixes. It has a downside, the downloaded data and configurations are not shared with the system. I guess it's a downside of Flatpak in general, but that's only my opinion. I made the same changes (for the [2]) for libebook, libebook-contacts and libedata-book, where I also changed some defines (added E_ prefix) and dropped EDataBookStatus error enum, which had not been really needed (similarly as I dropped EDataCalCallStatus). It could be replaced with EClientError and EBookClientError. As with the calendar, this touched the D-Bus API too. These book changes are quite straightforward. All the changes are prepared in this side branch: https://gitlab.gnome.org/GNOME/evolution-data-server/tree/wip/mcrha/libical-glib The 'make check' passes without errors. I already have prepared evolution, evolution-ews and evolution-mapi, though only as a buildable. The testing is to-be -done, I only didn't want to block this due to these three projects. 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 plan to create 'wip/mcrha/eds-libical-glib' branches in each and help with porting as much as I can. The idea is that the maintainers will just merge the branch changes and it'll be all (from the coding point of view). I know the branch name is inaccurate for the book changes, but I decided to keep all these things in one branch for simplicity. I believe it's better to break the API in a single release, instead of doing that within multiple releases. It will make it easier for the maintainers of the applications - the porting effort will be done only once, not multiple times. I have in my list these additional projects (to be verified whether any changes are needed there and help with them if yes): elementary-calendar ffgtk libopensync-plugin-evolution2 libreoffice pidgin-chime sflphone syncevolution wingpanel-indicator-datetime If you know more, then feel free to let me know. I'll be happy to help with the porting. With respect of timing, my plan was to have the things prepared for 3.35.1, I expected that the changes will take longer, but it went quite smoothly (well, actual testing will take some more time). I definitely want to wait for an official release of libical 3.0.5 with the necessary changes in its libical-glib part. Then we can decide, depending in what state respective projects will be. Maybe it'll be possible for 3.33.2 or shortly after it. I definitely do not want to push this close to the end of the development phase, I'd rather do this in the beginning of it, thus any third-party projects have enough time for porting. That's another reason why I chose 3.35.1 initially. I know this change will break some GNOME infrastructure, like the GNOME Continuous effort, thus it's understandable to have the critical projects prepared/ported first and commit the things (almost) at the same time. This would need some coordination, which is another reason for this e-mail. I do not foresee any additional API changes currently, definitely not on the D-Bus side, thus once this is done, the API should stay stable for the next several years, I believe. Of course, everything depends
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: > - evolution-data-server > https://gitlab.gnome.org/GNOME/evolution-data-server/issues/77 Hi, the same applies for evolution, evolution-ews and evolution-mapi. The above issue is closed, because there is a lack of manpower (and knowledge, I'm sorry) to convince gettext to easily work with all the data files (ini-like, xml-like and glade-like) used in the evolution. The issue doesn't contain any proposed patches, it's just filled (and closed, as mentioned above). A good news is that covering the change in one product will cover it in those other, because the cmake/modules/FindIntltool.cmake is copied between the four. The convenience the intltool provides, with the things working out of the box, with no code duplication between projects, had been probably the main argument to stay with it for me. I understand "a code stability" and "an unmaintained project" terms as a very different, but maybe it's just that the use case for the evolution products doesn't touch those broken parts of the intltool (yes, intltool has some bugs, I know, and I'm aware of one for which a "workaround" exists in the evolution products). That doesn't mean I'm not willing to move away from the intltool, I do not care that much, as long as I can invoke `intltool -m` as I use to do (or have an equivalent for it), but I need a help from someone whom knows what to do in the gettext to produce the same result both when generating the .po files and when updating the data files, because I simply do not know and I'm currently buried in some other work. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What is the status of developer.gnome.org and help.gnome.org?
On Fri, 2019-02-15 at 20:19 +, Emmanuele Bassi via desktop-devel- list wrote: > the switch to Meson for various libraries broke the expectations of > library-web Hi, not only Meson, but also CMake (and eventually anything what doesn't include developer documentation in the release tarballs anymore), as stated here: https://bugzilla.gnome.org/show_bug.cgi?id=785522 which leads to https://gitlab.gnome.org/Infrastructure/Websites/issues/224 I'm mentioning it here just to not fill duplicates of it. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab mirror considered harmful
On Mon, 2019-02-04 at 14:36 +, Alberto Ruiz wrote: > Maybe opening an issue in GitLab that points to the original PR so > that the maintainer can persuade the original PR author? Is this > something maintainers would find acceptable? Hi, apart of duplicated space and work, that won't work for those whom do not have an account on GitHub. Why would not contributors accept the fact that GNOME hosts its sources, bug tracker, ... in its own infrastructure? Do you think contributors won't find the sources and so on, when they are only under gnome.org umbrella? If I'd need to contribute to some project, I simply accept code-of-conduct and the way the project does those things, instead of trying to work on some mirror (where different rules can apply). Bye, Milan ___ 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: > 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. Hi, I guess, in that case, you can safely drop also the Microsoft Exchange accounts from GOA. The main consumer, as far as I know, is evolution-data-server, through evolution-ews. While the mail accounts configured with evolution-ews can work without Evolution, evolution-ews depends on Evolution, thus it brings it in. The evolution-ews also runs on the background evolution-data-server processes (factories and the source registry). You can access calendars/contacts/tasks/memos without using the mail part, but the main advantage of the Microsoft Exchange is the integration of all those 5 parts (something which is against GNOME design and the way it is led in the last years, I know). I mean, hiding the Mail switch from GOA for Microsoft Exchange accounts doesn't make sense. It may even confuse the users. It also seems like using GOA by core apps (is evolution-data-server considered an app, maybe it's just 'core') is meant only from GNOME desktop. At least according to gnome-control-central behavior, which rejects to access GOA when not running under GNOME for couple releases now [1]. It got better, because it's crashing in 3.30.2, while it opened an empty tab before. This is probably unrelated, unless it's an intention, similar to drop documents support from GOA. Bye, Milan [1] Evolution adds "Open Settings" button for GOA accounts, to make life easier to the users. It calls: gnome-control-central online-accounts which did work several releases ago, regardless which desktop environment the user used. https://gitlab.gnome.org/GNOME/gnome-control-center/issues/66 Maybe if GOA settings could be called out of the gnome-control-central? Users do need to go there from time to time. On the other hand, with flatpak and its inaccessibility of the system gnome-control-central it doesn't matter as that much. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab postmortem
On Wed, 2018-12-19 at 14:37 +, Philip Withnall wrote: > 3. I’d like to see continued movement towards disallowing direct > pushes to git, and requiring all commits to go through MRs (and CI). Hi, I hope this won't go through without a good research and reasoning. Any such requirement would be kind of showstopper for me personally. It would be just double work for me when coding (issue is not merge request), causing awful commit history, resulting in unbelievably harder effort required to produce NEWS file content (yes, I do use commit messages to fill the NEWS files in a semi-automated way saving my time, which I can spend on more productive things). To name a few major obstacles at least. I also cannot imagine any such thing enabled for 'work-in-progress' branches. That would be awful for any porting/cleanup/larger efforts. So while any such thing would make perfect sense to anyone else, it doesn't fit to everyone. On the other hand, if I'm the only one... Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please check if you actually depend on intltool
Hi, On Mon, 2018-12-03 at 23:33 +, Javier Jardón wrote: > (and gettext has been improved to implement functionality only > intltool provided before) right, I plan to re-evaluate and see how much they improved, though it might be some time next year, probably. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please check if you actually depend on intltool
On Mon, 2018-12-03 at 18:15 +, Javier Jardón wrote: > As you probably know, for some years we have been trying to move to > upstream gettext [1] Hi, I know intltool has some issues, the projects I work on faced some of them, but it also provides very useful tools and makes life easier to the developers, thus I rather do not understand the need of the move to plain gettext. Consider also code (or rather script) duplication (scripts to extract translatable strings from .desktop and various .xml files). I do not have those scripts, neither I'm sure where to get them or how to create them on my own. Changes like [4] are kind of funny, especially those where # TRANSLATORS: Don't translate this text (this is icon name) had been added. It was not needed before. Thus intltool can help to the translators as well (and the .po files did have less bogus strings). The [1] also doesn't mention a replacement to 'intltool-update -m', which I use quite often. > open MR's to reflect the real dependencies of your module, that would > be great I'm sorry, I never understood such requests, but it can be just me. Consider simple "dependencies changed: dropped dependency on , added dependency on " comment, which someone knowledgeable of the internal things would use to make things right on the first shot, with something like: "clone some repo, learn where things are stored, what format is used, ideally also what implications some changes have, learn how to test whether the change won't break anything obvious (like compile it somehow locally at least), then open a pull request and add it somehow in a fork of the project probably...". That's much more complicated and discouraging for someone whom has no single idea of the "target" project. I know, you said "would be great", I understand it, but I also see an increasing demand of creating pull requests while one suggests a one- liner change easily achievable by the maintainer in a fraction of time with compare of all the tasks a person not working with the project at all would do. I'm not talking about real "code" changes here, there's a difference when someone wants to suggest a change into the project on his/her own, which he/she also wants to test in action. Just my opinion. Bye, Milan [4] https://gitlab.gnome.org/GNOME/gnome-menus/merge_requests/1.patch ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.30 flatpak runtimes available on flathub
On Mon, 2018-10-01 at 17:15 +0100, Abderrahim Kitouni wrote: > If you find any problem, please file an issue at > https://gitlab.gnome.org/GNOME/gnome-build-meta/issues Hi, is there any list of intentional changes from 3.28 runtime, please? I'm not talking about updated libraries (like the switch from enchant1 to enchant2), but about things like empty /usr/share/zoneinfo [1] or a wrong CMake install libdir (for some libraries?) [2], which breaks building. The former is harder to find and it's kind of regression from the 3.28 runtime/SDK. Thanks and bye, Milan [1] https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/93 [2] https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/77 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Renaming gitg project file to GNOME Commits
On Wed, 2018-10-10 at 08:34 +0200, Alberto Fanjul Alonso wrote: > On gitg we are considering to adopt GNOME Commits as project name. Hi, I'm used to gitk (which uses Qt, if I'm not mistaken). The gitg always meant to me a gtk+ variant "of the same". I never looked for the real reasoning behind the name (which you gave earlier). Can it work with anything else than git? I do commit to svn, I used to commit to cvs as well. There are several other version systems where users can "commit" their changes. I mean, "GNOME Commits" is too generic, too vague. "GNOME git viewer" might be more accurate, but not that fancy. I surely would not get rid of the 'git' word, especially when it's the only version system it can work with. When searching for 'git' in repositories, it would be nice to have git itself and "the viewer" shown together. Just my opinion. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal proposal: app menu retirement
On Fri, 2018-06-29 at 16:39 +0100, Allan Day wrote: > Those of us on the design side are interested to hear what people > think of this, particularly if there are any apps out there that > might have issues following the guidelines. Hi, this seems to be aimed to applications which use header bar in the title bar. I suppose this doesn't cover the applications which do not use anything like that, does it? By the way, App menu, Primary menu, Secondary menu, for someone not following the terminology closely it looks confusing. Maybe if the page has also screenshot of "before", not only "after", thus one less educated could compare, would be a plus. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
