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
Re: evolution-data-server D-Bus service version change in 3.29.3
On Fri, 2018-06-08 at 09:42 +0100, David Woodhouse wrote: > I don't *assert* that it was unnecessary... but I kind of *hope* it > was unnecessary... Hi, you are right, it was unnecessary. I gave it a try (I really shouldn't be that lazy) and the GDBus proxy doesn't panic when some method is not available (I've been afraid that the application will not run), it only errors when the method is called with something like: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'RefreshBackend' which is perfectly fine from my point of view, thus I changed the D-Bus version back. I'm sorry for a false call. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
evolution-data-server D-Bus service version change in 3.29.3
Hello, this is a little heads-up that evolution-data-server 3.29.3 release will contain a D-Bus service version change, specifically org.gnome.evolution.dataserver.Sources5 changes to org.gnome.evolution.dataserver.Sources6 This had been done due to adding a new method to the interface for [1]. I'd not bump soname version for such API addition, but the D-Bus service is a different thing. I'm mentioning it here, because this influences at least Flatpak builds of projects using evolution-data-server, like gnome-calendar, gnome-todo and gnome-contacts, which build against the latest eds, but run backends from the host machine (thus they do not receive all the fixes). The Flatpak builds should be adapted accordingly. If you think the D-Bus service version bump was unnecessary, then I will revert it. I only thought that it was cleaner, because the C API function will not fail due to missing D-Bus interface method (to be honest, I do not know what the GDBusProxy will do when the running interface doesn't contain all the methods it expects to have). The evolution-data-server pkg-config file contains service names for couple releases already, thus one can use: $ pkg-config --variable=sourcesdbusservicename evolution-data-server-1.2 $ pkg-config --variable=addressbookdbusservicename evolution-data-server-1.2 $ pkg-config --variable=calendardbusservicename evolution-data-server-1.2 $ pkg-config --variable=userprompterdbusservicename evolution-data-server-1.2 to get the service names the evolution-data-server expects to have. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=795197 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Protected branches in GNOME's GitLab
Hello, this might be a lame question, but this time I tried to read the documentation first. I hope I didn't miss anything related to my question. If I did, then I apologize. When one wants to propose a change, aka create a merge request, in GNOME GitLab instance, then it can be done only on a writable checkout of the related project, which makes sense and is expected. It's similar as requesting the person to create a bugzilla account to send patches, thus it's fine. I also came through [1], where is written that the lowest possible member level to create merge requests is a Developer. Does it mean, that an automatically created user in GNOME's GitLab instance, basically a complete stranger, receives the Developer privilege, even when it's a Reporter (in bugzilla terms)? Which branches are marked as protected in GNOME's GitLab? The master branch is probably protected by default. Which are the other branches? I definitely do not want to see a complete stranger modify stable branches. According to [1] I can mark/unmark branches as protected when I'm at least the Master level of the project, but doing that each six months when branching for stable feels like one more thing to easily forget about, thus it would be nice to have some common "mark-as-protected gnome-X-YZ branches when created", maybe on the same hook which sends the messages to gnome-doc and such lists when the project creates the stable branch, like in case of the most recent gnome-3.28. You've it probably already there, I only do not know where to look for it, neither I think I'd have access to it. Thanks and bye, Milan [1] https://docs.gitlab.com/ce/user/permissions.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (*) No summarized news available (was: GNOME 3.29.1 released)
On Wed, 2018-04-18 at 11:31 +0200, Kalev Lember wrote: > Something that module maintainers can do here as a fix would be to > cherry pick any 3.28.x NEWS entries to the master branch before > releasing first 3.29.x release. Hi, except it's wrong, because then a) the NEWS file doesn't describe changes in the master branch, b) I commit to both master and stable when possible, thus the NEWS file would have contain certain things multiple times. The evolution products branch in time of the 3.x.0 release, then the development happens separately in both branches. Maybe you are right that others branch later, after 3.x.1 release. I think the `ftpadmin install` also claimed the latest release was 3.28.1, which supports your hypotheses. Interestingly it can distinguish between odd and even numbered releases once there is at least one done there. > That's just needed for the first 3.29.x release, after that it should > be fine to not cherry pick news entries any more. Correct, the 3.y.2+ releases work just fine. If it's really about something in the background, then, rather than trying to find some (ugly) workarounds, that thing could be fixed or improved. I hope. I'd file a bug, but I do not know where it belongs and what that 'something in the background' actually is. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
(*) No summarized news available (was: GNOME 3.29.1 released)
Hi, I'm starting a new thread here, just for an opinion on this: On Tue, 2018-04-17 at 16:31 -0500, mcatanzaro wrote: > The list of updated modules and changes is available here: > > https://download.gnome.org/core/3.29/3.29.1/NEWS I opened above URL and there's "(*) No summarized news available" side- note for two modules. In case of evolution-data-server, it corresponds to the ftp-release-list message: https://mail.gnome.org/archives/ftp-release-list/2018-April/msg00072.html But not to what had been done before the release: https://git.gnome.org/browse/evolution-data-server/commit/?id=a55f5c3dbce3f24d2462c76f555e858ef6df2ccb This usually happens with the first release of the series, but not always. Like the stable 3.28.0 has the NEWS content included: https://mail.gnome.org/archives/ftp-release-list/2018-March/msg00101.html I'm wondering, am I doing anything wrong? Why other modules, like epiphany, which also switched from 3.28.1 to 3.29.1, has its NEWS available in Michael's URL? I'd like to improve this, but I'm not sure whether it's in my hands at all. Could there be a bug in the script which extracts the NEWS changes? For example, the ChangeLog doesn't change, it simply references git log for proper branch. Does it have any influence on this? The ChangeLog file does change with the first stable release, due to the change of the branch: https://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-28=7f6c16388216840f6bbda0d98383d5c008bc8d45 Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome evolution and RFC 6186
On Tue, 2018-04-03 at 09:06 +0100, David Woodhouse wrote: > > On Tue, 2018-04-03 at 07:30 +0100, André Rodier via desktop-devel- > list wrote: > > I am setting up DNS records for email services automatic discovery > > (RFC 6186) but it seems that evolution is ignoring them. Hi, which version of Evolution we are talking about, please? The 3.28.0+ does read SRV records and other stuff. Ideally Edit->Accounts-> Add->Collection Account, which knows quite interesting things. > You might do better on the evolution mailing list (now in Cc), I'd avoid cross-posting, though you are correct that the evolution-list is better for evolution-specific questions. > It would also be useful to delegate the various protocols' > autodiscover mechanisms to the back ends, instead of having protocol- > specific knowledge for EWS, ActiveSync, IMAP and other stuff hard- > coded into Evolution itself. Already done and possible, in 3.28.0+. The "old" (and still used) autoconfig uses the information based on the domain part of the email, while this information is stored on a GNOME server. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Fri, 2018-03-23 at 11:04 +0100, Mattias Bengtsson wrote: > > https://gitlab-test.gnome.org/mcrha/test/issues/4 > > It's markdown formatted like most of GitLab. So just ask your users > to wrap > their backtraces in code blocks, like this: > > ``` > Your Backtrace > ``` Hi, I know it's a markdown, I'm just trying to learn it right now :) I did notice the "Insert code" button above the comment entry, which I though is what I've been looking for, but it added only `` and trying to write anything in between those didn't result in anything feasible. Yours triple-` works too and it looks differently than the (I added it to the above issue). It still means to either teach the users something (times it, I do not know, say by thousands) or edit their comments (which I disagree with), but it's just the price for other benefits GitLab instance can/will bring, thus no big deal as such. Definitely once I get use to it it'll be just a piece of cake. 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] IMPORTANT: Mass migration plan
On Fri, 2018-03-23 at 08:17 +, philip.chime...@gmail.com wrote: > You can test this for yourself on gitlab-test.gnome.org. Hi, I have only one login there, I cannot impersonate anyone, and I didn't feel like I could try it with other issues, but I did now. > No subscribers are auto-added. Only user E will be subscribed to > #345, because they commented there. Hmm, I've a different result. I used: https://gitlab-test.gnome.org/mcrha/test/issues/3 and https://gitlab-test.gnome.org/GNOME/test/issues/3 (oops, they both are #3, but in different "groups"). Before I did anything, my issue contained only 2 participants, 'mcrha' and 'C' and the GNOME/test contained only one participant 'Carlos'. Then I added a comment into my issue: "trying mentions behaviour with GNOME/test#3". After this the set of participants in my issue didn't change, but I've been added into the GNOME/test issue and I have enabled notifications on it. It's something I really do not want to, the less the bug squad folks (eeks, does it still exist?). Note even the new fake comment had been added into the GNOME/test issue (I had it opened in a different tab at the time I wrote the comment in my issue), the list of participants and the state of enabled notifications updated only after I refreshed the page, by clicking the issue number at the top of the page. > I find it more useful to have the "Mentioned in issue #123" item than > to not have it. The items are gray in order to be less prominent than > actual comments from users, so surely you can just ignore them? Right, there are just cases where it makes sense and where not. As it cannot be easily determined per case, then yes, I can learn to ignore them. :) > I found all this out and more, by reading the help page. You are right, my fault I didn't look on it myself first. I'm sorry. For example, I even noticed there's also a "Move issue" button in the interface, which is a shame I didn't see it earlier. One thing I didn't find in the manual, or I might just overlook it, is there an easy way to write the comment text in a preformatted mode? I know I can use in the comment like here (both with and without shown there): https://gitlab-test.gnome.org/mcrha/test/issues/4 but I'm afraid I cannot teach each single user to use it when I ask them to paste a backtrace into the comment (why should a regular user know anything about HTML tags in the first please?), that would be exhausting for all involved parties. I prefer backtraces in comments, because it's easier with respect of searching and finding (possible) duplicates. Thank you for your time and patience with me again. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] IMPORTANT: Mass migration plan
On Tue, 2018-03-20 at 18:01 +0100, Carlos Soriano wrote: > If you are a maintainer and you consider some issue in the migration > process or GitLab itself a big problem for your project... Hi, while I begun my concerns dealing directly with Carlos I've been told I should move it to public, because others may have answers and/or can help when Carlos is busy with other things. So here I am. I'd like to verify one thing, which I'm not able to test myself, but which is pretty bad from my point of view for many reasons. It is: When I write into the comment: "looks like issue #123", or "similar to #123", or such, just like comments which bug-squad used to write when triaging, then it really doesn't mean that everyone from #123 should be added into this issue, neither the #123 should be anyhow updated with "mentioned in #333" or the like (though more important is copy of the subscribers to the other issue). Those are only hints for developers and further investigation. Does GitLab really include everyone into #123 and/or from #123 into this issue? I'll be happy to help with testing, just let me know. Detailed steps would be: a) have issue #123 with subscribers A and B b) have issue #345 with subscribers C and D c) be user E, whom writes into #345 comment "looks like issue #123" Will any or both issues suddenly contain all 5 users? The whole auto-subscribe or even "Mentioned in issue #123" auto- comments doesn't really work for me. Look at: https://bugzilla.gnome.org/show_bug.cgi?id=794569#c4 I mentioned "bug #790632", in that comment twice, but I do not want to have said in that bug that I mentioned it in bug #794569. I only wrote there a reference to a related change which will help to the user, with no real connection between each other. Another thing, I think we did spoke about it, but I do not recall and I'm not sure. I've looked into [1], but description like "Move issues between modules" doesn't scale at all for a newbie with GitLab like me. I often use a bug and reference it in multiple modules. It's practical for many reasons. For example, when someone requests a change for evolution-ews, it can also mean to make changes in evolution-data- server and evolution, thus two other modules can require changes. I do not duplicate the bugs for other modules, that's waste of space and time, I rather reference the same bug in all three modules (in a way of "Bug - Summary", thus anyone can click it (cgit makes "Bug " clickable, with compare of URL in comments, which cannot be clicked) and see the history, reasons behind the change and so on, not talking that I can comment like "this caused regression/required follow up change in bug #123" in bugzilla). I cannot do this simple "closes # - Summary" in GitLab, because the # means something else in each project. How do I do this now? Will I paste full issue URL into the end of the commit message instead, and the commit message summary will be the issue Summary only, in all modules? How do I reference the commit in which the change had been done in the comment of the issue? I suppose the same as before, like here [2], right? Note of the fact that I use the behavior of bugzilla, that means I let it highlight the "commit abcd" for the module for which the bug is filled, but add full links (into cgit) for the other modules while I mangle the "commit_dcba" (see the underscore) to avoid auto-linking the commit. I sometimes have up to four modules touched within one bug report. I expect to change my work-flow, that's okay, I'm only afraid of side-effects which it can have due to auto-closing issues and such, about which I have no idea at the moment (GitLab is too new for me, with compare of cgit and bugzilla). I also read the "Track dependencies between issues" at [1] and the example link references [3], which results in "404 Not Found" page. How do I track dependencies between issues in different modules? As you can see at [2], it's filled for Evolution module, but it blocks a bug for evolution-ews module. These things are common when you work on something more complex, split into several modules. Thanks and bye, Milan [1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/GitLabWorkflows [2] https://bugzilla.gnome.org/show_bug.cgi?id=200907#c37 [3] https://gitlab.gnome.org/GNOME/nautilus/issues/30667 ___ 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 09:18 -0300, Germán Poo-Caamaño wrote: > FWIW, he can type Epiphany, and filter it, right?. It is faster. Hi, yes, he can and I do it too, but he didn't and doesn't for some reason. The set of things which can be done and which are actually used (and which are obvious) differ for different parties, even when they all use the same software for years. Bye, Milan ___ 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 11:22 +0100, Arnaud Bonatti wrote: > Do you now understand more why I want to rename? Hi, yes, sure, thanks for explaining it. The reason to rename it, because it doesn't work for DConf only, makes perfect sense. The other names do not look good to me, but I'm not a decision maker here, neither good in wording/naming myself, thus I'm afraid I cannot help here. Let's see what it'll evolve to (in the next several weeks I guess). Thanks again and bye, Milan ___ 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 07:56 +0100, Arnaud Bonatti wrote: > the future name of ‘dconf-editor’ needs discussions (‘Registry’ and > ‘Tinkerings’ are the best I came with Hi, may I ask why? What is the reasoning about changing the name of the dconf-editor? You want to rename a reversi game to reflect what it is (I had no idea what 'iagno' is until now), then you want to do something opposite for the dconf-editor? That looks odd. With 'Registry', well, it's too generic and I'd say "Hello Windows" when I see it anywhere on Linux. Does dconf-editor talk only to DConf, or it's available for any GSettings backend? If the later, then the most accurate (but maybe not the nicest) name would be "gsettings-editor". Otherwise I'd really keep the connection to DConf as obvious as it is now. The GConf editor currently identifies itself as "Configuration Editor" and the dconf-editor as "dconf Editor" in the Applications menu, both with the same icon. I do have both of them installed here. Your module rename may mean also renaming in distributions, thus it should not be done in a rush and "just because we can". At least from my point of view. You also lose some kind of mind share with the rename, because existing users know what it is called now, but will be lost when you rename the module (and the packages will be renamed, and the .desktop files will be renamed, and the application will be identified differently, and so on). I know that many application names in GNOME (and elsewhere) do not reflect what they actually do. Either one lives with what the decision makers decided at the beginning, or... A good example is Epiphany. I asked a user to test something with it recently. He installed it, but he could not find it in the Applications. It's not "Epiphany" there, it's just "Web". I know it, but for him it was a surprise and a source of confusion. Just my thoughts. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Check your default window size!
Hi, On Mon, 2018-03-19 at 16:49 -0500, mcatanz...@gnome.org wrote: > Sometimes it's easy for a developer to forget what a new user sees > when opening an app for the first time. I agree, the first impression is important. > Some of our apps (*cough* email clients *cough*) I hope you get better with that coughing soon, just do not underestimate it. > have default window sizes that are waaay too small. Check yours out! > Increase the default window size if needed. Well, in case of Evolution, there is no default window size. What it opens with is the size calculated by gtk+, just like for any other dialog, thus the minimum required size for the widgets in the window. What might look odd with high-resolution devices is pretty fine for low-resolution devices. What is the correct default value then? I guess there's none good, none which would work for all devices. Maybe "workaround" it by setting the window to open maximized by default? That's the way GNOME work flow looks like these days anyway, focus on one thing only, right? That won't work when user unmaximizes the window, but at least the first impression will be somewhat sane. How can one do that in GSettings, when the key, which is used to store the last window size, is declared as: Can the be expanded with any defaults from the linked schema? Maybe it can, but I do not know it (the documentation for relocatable schemas doesn't mention it and I do not want each key using this relocatable schema to have the same defaults (all windows maximized by default)) and I hesitate to do a change in the code to cover the default values. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [GitLab] Projects moved, general comments, tips of the week, question of the week
On Wed, 2018-02-28 at 15:39 +0100, Carlos Soriano wrote: > Hope this was useful and clarified any doubt you might have, it > certainly took some time to write. Hi, thanks for the explanation. It was definitely useful for me. I agree it's not simple to evaluate the priority. The "once per two months" can change once everyone will start use the tool, but that's only another nitpick from my side. Again, thanks a lot for sharing all of that. I apologize, if I sounded inappropriate earlier. 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] Projects moved, general comments, tips of the week, question of the week
Hi, On Wed, 2018-02-28 at 13:21 +0100, Carlos Soriano wrote: > There is no subset of people in GNOME's GitLab issue tracker, you all > can comment there, that's why it's public :) Hmm, applying the same logic you can open a GNOME's gitlab issue for "tips of the week" and update it, instead of sending the message here, because you are addressing the same group of people, no? :) But seriously, my main point is that not every developer follows issues filled in GNOME infrastructure gitlab issue tracker, thus even it's a public place, it doesn't reach the group of people whose the decision will influence the most. It also surprised me that the fresh "Allow to disable group mentions - #43686" is considered Minor. It's not a deal breaker, of course, but it has some consequences too. By the way, how does that https://gitlab.com/gitlab-org/gitlab-ce/issues/43566 work? Once the "High" section is done all left GNOME projects will be migrated to GNOME's gitlab instance and bugzilla will be switched to read-only mode, or? I'm just wondering. 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] Projects moved, general comments, tips of the week, question of the week
On Fri, 2018-02-23 at 21:40 +0100, Carlos Soriano wrote: > If you have some issue or feature request that might impact GNOME as > a whole and you think it's important for GNOME create an issue in our > infra project and we can discuss if we should add it as priority for > GNOME. Hi, I'm wondering, would it be better to have the potential issues discussed more in public, like here, thus the GNOME community/developers can decide which issues are important to them and which not, instead of keeping the last word on a small subset of people in some group in the GNOME's GitLab issue tracker? I do not expect anyone periodically check whether any interesting topic wasn't added there and eventually rise his/her voice there. And as always, different people have different opinions, different priorities, different point of view, different... Thanks and bye, Milan ___ 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 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? Personally, I'd not include those gtk-doc and help generated files in the tarballs, because they are there "twice" then, but I know of the older thread where some distro(s) preferred in-tarball documentation over generating them during build time (which saves time for their users/build machines, in price of larger tarballs for everyone); some distros rebuild help/gtk-doc always, no matter whether they are in the tarball or not. Bye, Milan ___ 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 09:33 +, Philip Withnall wrote: > porting the build systems of those modules to Meson is another > legitimate way to port away from gnome-common. It would be the better > choice in the long run for modules we are going to be maintaining for > a while. Hi, I do not want to steal the thread, but when talking about ports to Meson, would it make sense to finally fix the infrastructure to work with other than automake files too [1]? It's when generating the content for developer.|help.gnome.org. Considering that plenty of projects already use Meson, either exclusively or as an alternative for autotools scripts, then it would be a good idea, from my point of view. I'd help myself there, but I do no speak pythonish. I guess someone with the knowledge would have that fixed relatively quickly. Thanks and bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=785522 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.27.90 tarball deadline extended
On Thu, 2018-02-08 at 13:57 -0600, mcatanz...@gnome.org wrote: > Due to this delay, we will skip the 3.27.91 release altogether, so > the next tarball deadline will be 3.27.92, on March 5. Perhaps by > then we will be able to recommend using BuildStream for tarball > generation. Hi, is it a good idea? I know that 3.27.90 release of some of the products I care of has issues which I promised to fix in 3.27.91, not longer than two weeks after 3.27.90, as the GNOME schedule says. Nobody forces me to not do the release, I know. I understood that *the release team* has some trouble with tarballs, but I do not understand why it should be such a big deal for everyone else. There had been ways to generate tarballs a month ago, and it didn't change. Not that significantly during that single month. Why to postpone anything *for the rest of the world* in this transition period? What I also do not understand is that release team should not generate any tarballs, it's the developer's duty (I know, I know, the practice is sometimes somewhat different, but anyway). You want to use BuildStream, you are in the transition period, but it doesn't mean that everything freezes, it shouldn't mean that you have no backup plan if anything breaks. That's the transition period, it's expected to face bugs and issues. I understood that BuildStream is a *recommended* way of developing for GNOME, the same as jhbuild was a *recommended* way of the same. I do not use either of them. I'm able to create release tarballs for the products I care of. Thus, from my point of view, as long as developers can create tarballs and release them, and as long as the release team is able to validate these tarballs, then there is no need to postpone anything. The worst the BuildStream "exclusive" usage would be postponed, but not the release of GNOME. Again, transition period, bugs expected, and so on. Everything makes sense. 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: GitLab update: Moving to the next step
On Thu, 2017-12-07 at 17:50 +, Emmanuele Bassi wrote: > I seriously doubt you were born with innate knowledge of Bugzilla - Hi, it sounds like you consider an intuitive interface something obscure. Well, it's intuitive at least for me. > even though Bugzilla's feature set is basically limited to what you > see in the page. Yes, that's basically the main part of it. I definitely do not know all the features bugzilla can do, but the basic parts I use I didn't need to search for in a manual, they were just there, on the screen. Like with the shortcuts in the interface of GitLab. I definitely know how to click on [reply] in bugzilla, but I do not know how to press 'r' (or any key to be considered a shortcut of this kind) on a tablet. I didn't try it and it probably doesn't matter. If you let me to make a side note, maybe it's similar to the reason why I never got to use Blender. It's a very powerful tool, but it requires to know so many shortcuts to be able to use it (I didn't try to use it for a long time, thus my information can be outdated). It can be great for professionals and people using it every day, but when it comes to newbies like me, then I'm completely lost. What I need are basic things. I can compare it with Rhino3D, I can do most of those basic things with a mouse, everything is in the interface, I do not need to know special shortcuts and when I open the software half year later I still can do it without refreshing my memory too much. I do not want to change subject, that's just an analogy I recalled and it is possibly highly inaccurate, thus forgive me if you consider it as such, please. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab update: Moving to the next step
On Fri, 2017-12-08 at 16:50 +, philip.chime...@gmail.com wrote: > Coming from GitHub, Bugzilla was like regressing to the stone age. If > I were to insist that my opinion take precedence in the same way that > has happened multiple times on this thread, I'd demand that all > activity on Bugzilla cease immediately. I don't think that would be > very fair for me to do either. Hi, yes, that makes sense and I'm also not thinking to be "better than anybody else" (I do not know how to say it better), I'm only trying to keep close to my current workflow, which makes me efficient in certain way. It's understood it cannot be the same, those are different tools, but I expect some basic stuff to work. By the way, what were/are your main issues with Bugzilla? If it's about pull requests, then, well, I've been told on IRC that issues and pull requests are two different things and if you check what I'm questioning, then you'll see it is all about tracking issues, not proposed changes from contributors. Bugzilla is an issue tracker and from my point of view quite powerful in many ways. Definitely much more than issue tracker by GitLab. I really do not want markup, the less images for smileys and emoticons, those add exactly 0 Sh to the issue itself (just like "me too" comments in bugzilla). Bugzilla doesn't know anything about cvs/svn/git and it (I believe) never had too, it's a tool to maintain issues, not the code repository. That's GitLab and some other for, if you really want a web interface 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 update: Moving to the next step
On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote: > I have good news, after few meetings and discussions with GitLab we > reached an agreement on a way to bring the features we need and to > fix our most important blockers in a reasonable time and in a way > that are synced with us. Hi, couple other things I faced when I touched gitlab. How is the test instance different from the one GNOME is maybe going to use? Though I do not see basic things even in gitlab.com interface, thus maybe doesn't matter. Let's start with easy things: a) See the second comment of https://gitlab-test.gnome.org/mcrha/test/issues/2 It shows like three lines of text (one line, then empty line, then third line). When you edit that comment you'll see I made it several lines, not only three - the interface is ignoring my Enter-s. Am I supposed to use some crazy tag when I want to divide paragraphs and/or write simple lines? b) How do I reply to a comment? I really do not see it (call it usability issue, because this is quite unintuitive comparing to bugzilla, where I see beside each comment a [reply] link which does fancy things and saves me time). Oh, I've received an answer from the upstream, there's a keyboard shortcut for it, which involves selection on the page. I really cannot get such things when opening the interface (not the manual). c) my current work flow with bugzilla involves having opened *one* tab in the browser with a search which contains a list of bugs changed since some date for four different products. I refresh it in the morning to see newly added bugs and eventually react to them (I know, that's a silly idea to take care of newly added bugs where reporters are active the most). How do I do the same in gitlab, while: 1) the space will not be wasted, because I dislike scrolling when it's unnecessary (and here it is); 2) it will not be four different tabs in the browser? d) I cannot set labels on my test project for some reason. They are probably good for searching, I don't know, but trying "/label ~xxx" in the comment just doesn't do anything (is that the right and only way to set label on an issue by commenting with a code-like tags?). I opened an issue in gitlab.com (see my previous mail in this thread), maybe I do not have permission for it, in my own project? The test instance also doesn't auto-complete any label, which may or may not be related (per-project labels disabled/impossible?). I know you can easily RTFM me, but do you know what? I didn't read any single word of the bugzilla manual and I've been able to work with it with no problem. Weird, I know. While there is expected some difference, I think I should not be hunting for basic usage hints. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab update: Moving to the next step
On Thu, 2017-12-07 at 10:03 +0100, Milan Crha wrote: > I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there. Hi again, and also https://gitlab.com/gitlab-org/gitlab-ce/issues/40904 I do not see how to add labels to the issue, and the test instance doesn't do anything with "/label ~something" (literally, without quotes) in the comment. I added both to your issue at: https://gitlab.gnome.org/GNOME-Community/GitLab-Infrastructure/issues/8 I do not know how to add it to the proper section, I thought it's a wiki page hidden under your link. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab update: Moving to the next step
On Wed, 2017-12-06 at 19:31 +0100, Carlos Soriano wrote: > To explain it better, my discussions with them are for high impact > changes. My bandwidth is fully in there. Hi, that's understood and a reason why I made it "nice to have" and nothing more. I filled https://gitlab.com/gitlab-org/gitlab-ce/issues/40903 there. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GitLab update: Moving to the next step
On Wed, 2017-12-06 at 18:49 +0100, Carlos Soriano wrote: > I have good news, after few meetings and discussions with GitLab we > reached an agreement on a way to bring the features we need and to > fix our most important blockers in a reasonable time and in a way > that are synced with us. Hi, I only recently noticed that there is no option to send mail notifications from Gitlab as text/plain only, while this could be changed in bugzilla. I agree it's no blocker, it's just nice to have. For me personally, I do not care of fancy fonts and whatever in text/plain+text/html messages they send, I prefer text/plain for bugzilla mail, because I care of the information, not the form (and less data being transferred and stored as well). In case I didn't overlook the option in the Gitlab preferences, could you ask them/add it to the list, please? Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pilot GitLab program
On Wed, 2017-06-28 at 10:15 +0200, Carlos Soriano wrote: > > a) I often move bugs between products, aka user files it for product A, > >but the issue (and actual commit) is in product B, thus it's moved, > >by ~3 clicks > > How is this missing In GitLab? Hi, I do not use GitLab, thus I do not know. That's why I'm asking (missing question mark and actual question, I'm sorry). I understand it as "possible", thus okay. And it also means no unique numbers for products. > No. Negative filtering (idk how to call it properly, but removing > from search specific terms) is something I'm interested to bring up > to GitLab team. Eventually we will need this for duplicates. It's not exactly negative filtering on bugzilla, it filters for bugs with: bug_status=UNCONFIRMED & bug_status=NEW & bug_status=ASSIGNED & bug_status=REOPENED > Hope you understand a change without compromises is not possible. Sure. As always, it's about the change. Once I get to it, and change my developed work flow for years, the fallout will not be that drastic as at the beginning. The thing (for me) is that if I have fine tuned work flow which I really use for years, every single day, then change it will not be any fun. Again, for me. Call me an old school, I'm fine with it :) Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Porting applications to meson
On Tue, 2017-05-23 at 09:55 +0100, Javier Jardón wrote: > I've been thinking on doing this for a while, so here you go: > > https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting Hi, do not count with evolution* for now, please. I'm not willing to change their build system again, that soon after the change to CMake. I'm quite happy with CMake, to be honest. And as long as its dependencies like WebKitGTK+ or libical use CMake, thus it's needed for Continuous, jhbuild, and what-so-ever-other consumers, there's really not much need to change to Meson for these, from my point of view. I know each has its parts which can do better than the other, that's pretty common. The suggested effort may work for Meson as an advertise and to popularize it, which can be also good for Meson, no doubt. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Thu, 2017-05-18 at 15:12 -0500, mcatanz...@gnome.org wrote: > I think we should remove this extension immediately. Hi, that sounds quite radical, does it not? Removing everything what has bugs, instead of fixing them, what would you ship to your users? > It provides limited value, since you almost always want to skip > through the pretty little trace to see the full backtrace anyway. Different people, different usages. What you do not use maybe others do. I see many regressions in the recent changes in GNOME bugzilla which simply break my workflow with it, built and fine-tuned during many years of using it, but nobody cares. They know better what I should do and how, it seems. > And this confusing bug is very serious. Hmm, did you hit that bug yourself? I did not. I see it's filled since 2015, with 18 CC'ed users. That's not a low number, but there had been filled thousands of backtraces during that time, with no problem so far (I believe so at least, I do not have exact numbers, thus if anyone can correct my expectations, then I'm all fine). Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 14:22 +0100, Allan Day wrote: > The outcome of this evaluation process is that we are recommending > that GNOME sets up its own GitLab instance, as a replacement for > Bugzilla and cgit. Hi, with respect of the cgit, it lets me download sources (snapshot) as a .zip and a .tar.xz. The gitlab offers .zip, .tar.gz, .tar.bz2 and .tar. I think there had been some good reasoning for projects to do releases as .tar.xz (maybe it was even a GNOME Goal, I do not recall, neither cannot find it), it's quite efficient with compression, thus it would make sense to teach gitlab to use it beside .zip, instead of those three not-that-useful-these-days .tar variants. Would they do it upstream, or you'll need to patch it downstream, or it's just some option somewhere? Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to deploy GitLab on gnome.org
On Tue, 2017-05-16 at 10:51 -0400, Shaun McCance wrote: > That said, here's a potential pain point Hi, please, do not forget of Bugzilla integration with backtraces. It can colorize them, it can show possible duplicates with score when the backtrace is opened in its own window, and it can even notify the reporter that the backtrace matches some other bugs and it offers the reporter to eventually join an existing bug, instead of filling a new bug report. Of course, an average user cannot decipher backtrace of random projects, thus it's fine he/she files a new bug report, but my main point for Bugzilla is that it knows what to do with inline backtraces. Does gitlab issue tracker know it too? Also, with respect of searching in Bugzilla, what some folks in this thread call complicated, I call powerful. Bugzilla is powerful in searching. The search UI can be complicated, that's why there is a Simple and Advanced search page, but it allows you do many good things. I've seen a screenshot of the gitlab issue tracker in an early stage of the wiki page [1], which I cannot find right now. It was full of colored tags, which effectively hid the main purpose, the information which had been meant to be shared. The page looked like a rainbow, not like a clean interface to share information between the reporter and the developer. One of the test issues [2] also looks somehow odd, but maybe if I would get use to it, then it might not be that bad as it looks like now. How many comments does it show? Four? One? Something in between? It looks like there are four of them, all grey thin font (hard to read), and wasting like 1/3 of my browser window height. Height is problem, not width, with wide screens. I didn't try how it looks like on a cell phone. The issue [3] also says: > Carlos Soriano @csoriano mentioned in issue #30668 (closed) 2 weeks ago Should that "mentioned" be "is marked as duplicate" instead? I can mention bugs between itself and I do it all the time (like "this is partly related to bug #1234", or even "can be duplicate of bug #1234", which used to do bug squad folks in the past too), but it doesn't mean they are duplicates, neither that I want to add some possibly misleading automated comment into the other bug report. I would mark them as a duplicate, or add them to Depends/Blocks, if I'd be sure. >From my point of view, it doesn't make much sense to have both Bugzilla and gitlab issue tracker running at the same time and let the product maintainers decide what is better for them. There should be some consistency. You cannot tell the reporter that the issue he/she filled belongs to other project, but that project issues are hosted elsewhere (even still under gnome.org domain). I understand this whole initiative to also make life easier for sysadmins, where maintaining two issue trackers doesn't sound like less work for them. Bye, Milan [1] https://wiki.gnome.org/Initiatives/DevelopmentInfrastructure/ [2] https://gitlab.gnome.org/GNOME/nautilus/issues/30668 [3] https://gitlab.gnome.org/GNOME/nautilus/issues/20958 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Services API Keys
On Wed, 2016-12-14 at 10:11 -0500, Shaun McCance wrote: > The GNOME Foundation board has a password-protected area of the wiki > that only board members and employees have access to. That's eight > people, nine after we finally hire an ED. Would that be a good place > to keep a backup? Hi, I see I forgot to explain something. As it is done in the Google case (and I believe also for other OAuth(2) services) a developer creates a project on the Google site and that project receives a pair of id/secret, which is used to identify the project (application), which asks for the OAuth(2) token with user's credentials. This id/secret pair is semi-private, it can be found in the source code. The Google web site allows to add more people into the project, in which case more people can change settings of the id/secret pair on the web site as needed. That is that, in the case of the Google, there might be a Google account which could be added to the projects and this Google account will be tight to the entity, not to an individual. I hope I made it clearer. In case I misunderstood your comment, I'm sorry. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Online Services API Keys
Hello, in the light of https://wiki.gnome.org/Initiatives/OnlineServicesAPIKeys which is still missing the Google keys used by the evolution-data- server (it's my fault). I'm wondering how to avoid The Bus Factor for the keys. It doesn't matter how many individuals would have access to the keys (you still want to keep that quite low after all), as long as they are the individuals. Having there a (central?) entity with the access to the keys settings might be better, because, well, the entity would be independent of any individuals. I know there are pros and cons for both ways of doing it, as you surely want someone trustworthy to have access to the keys, not some random guy, thus the entity might be the board, or the sys admins, or... This email is meant as a question what others think and also a possible place to give pointers and so on for the process to get into the state where The Bus Factor will be completely avoided (or at least as much as possible). Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Head-up: Evolution-Data-Server Camel API changes to land next week
On Mon, 2016-10-31 at 18:05 +0100, Milan Crha wrote: > I plan to merge the evolution-data-server changes on Tuesday, > November 8th (the next week), and as soon as possible also the > changes in evolution, evolution-ews, evolution-mapi, evolution-rss > and evolution-activesync, thus the GNOME Continuous builds are not > broken for long. Hello, this is a notice that the changes from wip/camel-more-gobject branches in respective modules are committed into the master branches, namely: https://git.gnome.org/browse/evolution-data-server/commit/?id=9af0c834e https://git.gnome.org/browse/evolution/commit/?id=8b74f9146 https://git.gnome.org/browse/evolution-ews/commit/?id=e4dcf633b https://git.gnome.org/browse/evolution-mapi/commit/?id=341a2f4ea https://git.gnome.org/browse/evolution-rss/commit/?id=c78ce3988 https://git.gnome.org/browse/evolution-activesync/commit/?id=f093b09e0 The bug 764065 contains patches for evolution-rspam and mail-notification projects: https://bugzilla.gnome.org/show_bug.cgi?id=764065 The changes will be released as 3.23.2 of the evolution-data-server (and the other evolution core products). If anything would go wrong, please let me know (ideally through bugzilla). Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Head-up: Evolution-Data-Server Camel API changes to land next week
On Mon, 2016-10-31 at 20:43 +, Zisu Andrei wrote: > I had some patches for the SPECIAL-USE flags, but I haven't had time > to deal with them over summer, should I also try to get those merged > before the window closed? Hi, I suppose you mean https://bugzilla.gnome.org/show_bug.cgi?id=767821 It'll be nice to have that part of 3.23.2, yes. If I recall correctly, the current aim is to not change current API, only add new symbols (without a need for the migration), which won't need a soname version bump ideally. It's still a 3.23.x material. Thus if you have time, please update the patch at that bug report and we can continue there. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Head-up: Evolution-Data-Server Camel API changes to land next week
Hi all, this is yet another announcement of prepared changes for the Evolution-Data-Server, this time about Camel and its changes to make more objects GObject based, for better/easier introspection of the Camel library. I mentioned this almost four months ago [1]. This had been initiated by Corentin, I'd like to thank him for his help on it. There will be a soname version bump, which I usually do not announce, but this time the change makes semi-huge API changes, which require not only rebuild, but also some additional changes among the projects which link against libcamel. The corresponding bug report [2] contains a list of possibly related projects. Some of them are hosted in GNOME infrastructure and already contain a wip/camel-more-gobject branch. I plan to merge the evolution-data-server changes on Tuesday, November 8th (the next week), and as soon as possible also the changes in evolution, evolution-ews, evolution-mapi, evolution-rss and evolution-activesync, thus the GNOME Continuous builds are not broken for long. If there are more projects which would require changes, then do not hesitate to contact me either on IRC or file a bug in GNOME and CC me there. I'll be glad to help with the changes. Bye, Milan [1] https://mail.gnome.org/archives/desktop-devel-list/2016-June/msg00048.html [2] https://bugzilla.gnome.org/show_bug.cgi?id=764065 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Switching from Autotools to CMake for core evolution products
On Thu, 2016-10-27 at 18:10 +0100, Sam Thursfield wrote: > On Thu, Oct 27, 2016 at 3:23 PM, 藍挺瑋 <lant...@gmail.com> wrote: > > 於 週三，2016-10-05 於 09:33 +0200，Milan Crha 提到： > > Can we have a common way to enable GTK-Doc installation in modules > > using CMake? In modules using Autotools, we have --enable-gtk-doc > > which is recognized by every module supporting generating > > documentation with GTK-Doc . However, we have two important modules > > using CMake, Evolution (including Evolution-Data-Server) and > > WebKitGTK+, but they require different options to enable GTK-Doc. Hi, I agree that the consistency is "good to have". I chose the name to stay as close to the one from autotools as possible. Similarly with other offered configure options. > gtk-doc now ships a CMake module upstream: > <https://git.gnome.org/browse/gtk-doc/tree/cmake>. > > I adapted this from existing code in the Firtree project: > <https://github.com/rjw57/firtree/tree/master/cmake/Modules> > > It would be nice if Evo and WebKitGTK+ could switch to using that. It > may need some improvements; I used it successfully in a couple of > projects (proprietary ones, sadly) but I don't know how much use it > has had elsewhere. Unfortunately, I do not recall what failed for me when I tried to use it in the time I've been adding the functionality into the libical. It's couple months ago, it's likely that the things changed on the GtkDoc side meanwhile, I really didn't give it a try any time recently. Similarly to WebKit, I currently do not plan to bump GtkDoc dependency, but it doesn't mean I'm against it. As I begun above, the consistency is good to have. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 09:33 +0200, Milan Crha wrote: > I plan to merge the changes the next Monday, October 10th, some time > after the 3.22.1 release. This way there will be enough time to catch > any issues before the 3.23.1 release. Hi, this is a notice that the changes had been committed to git master of the modules and some after-commit fixes had been done as well already. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal for Gnome Goal (was Re: Switching from Autotools to CMake for core evolution products)
On Mon, 2016-10-10 at 10:49 +0200, Sebastian Geiger (Lanoxx) wrote: > On 05/10/16 15:39, Michael Biebl wrote: > > So while I'm not tied to autotools, I would hate to see if every > > modules maintainer chooses his/her own build system of choice. This > > makes it really cumbersome as downstream/integrator. > > Maybe it would make sense to introduce an official Gnome Goal that > encourages every module maintainer to switch over to > meson. Hi, I didn't mention it earlier, but I didn't pick CMake out of blue. I've got inspired by the projects the evolution core products depend on. Some time ago, I touched WebKitGTK+, which uses CMake. Very recently I helped to upstream libical-glib GNOME hosted project to libical upstream, which also uses CMake and as I spent some time learning it during the libical-glib work it was just a natural choice for me. I did not want to spend more time on learning yet another build system. No doubt, the CMake isn't perfect (I miss real post-install steps/commands there, like to recompile gsettings schemas and icon caches, for which I have workarounds there), but (otherwise) it works pretty fine for me. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 17:29 +0100, Javier Jardón wrote: > Sure, just ping me (jjardon) or any of the release team members > Hi, thanks a lot, I'll do that once the changes will be merged in the git master. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switching from Autotools to CMake for core evolution products
Hi, On Wed, 2016-10-05 at 19:13 +0530, Nirbheek Chauhan wrote: > Meson supports Ninja, MSVC 2010, MSVC 2015, and XCode. Support for > make was omitted on purpose. Ah, nice, I misread the list of available backends. My fault. I'm sorry for that. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 07:54 -0500, Michael Catanzaro wrote: > This is fine from a release team perspective, as we're already set up > to handle CMake modules. Just make sure to update the JHbuild > moduselets and Continuous manifest at the same time you make the > change. There are already examples of how to handle CMake projects > (e.g. WebKitGTK+). > Hi, I never touched any of the two, neither I use any of the two, thus it's pretty likely I'd more break than fix. Would there be anyone willing to do it properly on the first shot "for me", please? Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Switching from Autotools to CMake for core evolution products
On Wed, 2016-10-05 at 13:39 +0200, Bastien Nocera wrote: > Why? Is it faster, smaller, or better in other ways? Hi, seems to be better than autotools, gives more freedom and easily allows the sources to be built much faster than with autotools (it builds here in ~1/3 of the time which uses autotools, still using "Unix Makefiles"). I know it's caused mostly by not having one giant Makefile.am, but this way it's easier (at least for me). With the "gives more freedom" I think of different generators, which CMake offers quite many [1]. > Were other alternatives considered (Meson,seems to be the preferred > non-autotools build system for GNOME projects)? Right, Meson. I do not want to dive into such discussion, Meson simply didn't fit my needs and preferences. Its syntax is weird to me and if you compare what Meson offers (ninja and msvc2010) and what CMake offers [1], then it's just "more freedom" from CMake than from Meson. Bye, Milan [1] https://cmake.org/cmake/help/v3.6/manual/cmake-generators.7.html Note it's for version 3.6, while the required CMake version is 3.0 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Testing for memory safety issues with Address Sanitizer
On Wed, 2016-09-21 at 11:27 -0500, Michael Catanzaro wrote: > For some reason, Fedora doesn't seem to have a libasan-devel package, > so there's no plain libasan.so. Really strange. I tried changing it > to libasan.so.3 in my jhbuildrc but actually couldn't figure out how > to do that; jhbuild is playing with LD_PRELOAD as well. :( Hi, these options used to work in some not so distant past for me (yeah, when playing with evolution-data-server and evolution): export CFLAGS="$CFLAGS -fsanitize=address,bounds,alignment,object-size -fno-omit-frame-pointer" export LDFLAGS="-fsanitize=address,bounds,alignment,object-size -lasan -lubsan -lpthread -ldl" export ASAN_OPTIONS=abort_on_error=1:detect_stack_use_after_return=0:detect_leaks=0:handle_segv=0:check_printf=0:detect_deadlocks=1:replace_str=1:replace_intrin=1:alloc_dealloc_mismatch=1:new_delete_type_mismatch=1:detect_container_overflow=1 I recall I was forced to use the LD_PRELOAD too. It was for cases when mixing with and without asan built code, if I recall correctly. You should teach jhbuild to add the asan/ubsan first, I'm afraid (or to concatenate the LD_PRELOAD with some shell value, similar to CFLAGS above. Bye, Milan ___ 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 and Evolution to depend on WebKit2 since 3.21.90
On Fri, 2016-08-19 at 10:47 -0500, Michael Catanzaro wrote: > Please note that this kills Bijiben, we'll need to tell distros to > remove it unless bug #728293 gets fixed very soon. Hi, eventually the bijiben can be patched to not link against libedataserverui, until the proper fix (port of bijiben to WebKit2) is available. The side-effect of the patch would be that the bijiben would not be able to ask for user's credentials when the evolution-data- server source might need it. That's no problem for local sources and those configured in GNOME Online Accounts (GOA). Nonetheless, I realized that even bijiben's configure.ac looks for libedataserverui, it's not used in the code and it can be built without it. I cannot test the change, unfortunately, due to https://bugzilla.gnome.org/show_bug.cgi?id=744661 https://bugzilla.gnome.org/show_bug.cgi?id=770223 but it builds here without issues. I updated https://bugzilla.gnome.org/show_bug.cgi?id=728293 accordingly. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Keep shipping also generated gtk-doc html/ folder?
On Thu, 2016-06-23 at 09:55 +0100, Philip Withnall wrote: > If I remember correctly, it’s so that the tarballs can be unpacked to > give documentation on developer.gnome.org without having to build > anything. Hi, I thought it would be to have the documentation available from any system, for which my argument would be: "there is the online documentation at developer.gnome.org, which is better than the one in the tarball", but if it's true what you wrote, then it's the opposite direction relationship. I know there had been quite much buzz about the infrastructure recently, I hope they won't dislike me, but maybe it would worth to reconsider this and do build the devel-doc for the developer.gnome.org site (easier to say, than to do, but maybe it could be extracted from the Continuous builds?). Also, it seem to me that it's the gtk-doc adding to the tarball that folder and couple files, thus the place to focus any changes on might be gtk-doc itself. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Keep shipping also generated gtk-doc html/ folder?
Hello, while playing with developer documentation I noticed that the source tarballs (eventually `make dist` result) contain also developer documentation in generated form. These documentation html/ files are not small, in case of the glib it makes around 10MB. The thing is that when I configure with --enable-gtk-doc, then the shipped html/ files are regenerated, thus it looks like a waste of space and bandwidth to distribute them. I do not know the history behind it, maybe I just overlooked something and it does make sense to distribute that too. That's why I raised it here. It would be interesting to know whether anyone uses the html/ files without --enable-gtk-doc these days, but I understand it's a hard question. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [ Revised Proposal ] Continuous Builds in GNOME
On Fri, 2016-06-17 at 17:11 +0900, Tristan Van Berkom wrote: > I dont believe you have any such functionality in jhbuild. > > At best, you can specify the sha1 of the commit you want to build of > a given module, this would not let you single out one commit, > omitting it from history in integration and at least attempt to apply > subsequent commits without that one included, re-including that > commit in the correct place in history only when CI infrastructure > would find integration unbroken. Hi, I never thought of a single commit removal from a set of commits. To be honest, that sounds even more crazy (not 'crazy' like 'insane'). :) We are talking about master, the development version of the software. If you'd like to tell me that you are at commit X and feature which I added at commit X-3 does not work for you, then trying to figure out why exactly you do not see that feature is a real nightmare and waste of time for both the reporter and the developer, especially when you want to remove only single commit from a history. Not talking that following commit can "build on top of the previous commit", which is quite usual. > The thing is, either way; your work flow will not be interrupted at > all with this approach, ... See above. > I realize my answer is quickly written and I would like to keep my > mind open and receptive, but I would also like to hear a more > detailed counter proposal on your end too, weighing the benefits of > managing this in a jhbuild moduleset vs a unified project wide git > branch I didn't think of my workflow changes in any deep way, also because I do not use jhbuild (that's not a tool for me). I just want to keep things simple as much as possible. Not only for me, but for the others too. Adding a new branch adds some non-trivial complexity. Consider the early adopters, whom will fill bugs against the developer version of some module. The developer will not only ask "what steps to do to reproduce the issue", but also "which branch was used and with what commits". And it happens often that the developers do not react on bugs "quickly", thus the commit numbers in the integration branch can be easily lost (branch rebuilt), thus making the bug report more or less useless. I said earlier in the thread that the current situation works for me the best. There is clearly stated what the continuous builds from, at which exact commit it "stopped updating" certain module, because of some breakage, and everything references the real master branch. That the continuous uses jhbuild might be just a coincidence, even it sounds like the moduleset is targeted for the Continuous builds, when it can influence an environment for any developer using the jhbuild (I do not use it, this is how I understood how it works in the jhbuild world). I do not care about the new branch, if you (plural 'you') will decide to use it, then I've nothing significant against. I only think it'll add too much confusion for the developers, that it'll strike back in some way in the future. I only do not like the idea of random reverts, the master branch is the pure bleeding edge, thus if the automatically managed branch is a way to go for you (plural 'you'), to avoid those reverts, then feel free to do it. Maybe, only, it would be ideal if the new branch won't influence daily `git pull` on the projects, due to bandwidth limitation, connection speed and similar constraints. That would, maybe, better fit to create a new project for the automatic builds, with the "interesting" git sub-modules there at certain commits. There might not be much difference between the new project with submodules and 10K branches in each module, right? Your new tool would still work on the git commits. That's still too complex, too limiting for a daily work on the master (not for me, but for jhbuild users to whom some modules will automatically stop updating at certain commit which can break other modules, like with the API changes, but the developer of the affected module might not ever notice, because he/she will stay at the commit which precedes the API change). There had been said in this thread already that having a continuous integration (automatic builds) is not easy, especially for such a large project like GNOME. Whenever a "Continuous" was said in this thread a shortly after followed "jhbuild". It's understood. The jhbuild is the current tool for the automatic builds. Supporting random automatic build systems, which is what you said could be done with the 'integration' branches, is not needed from my point of view, due to the GNOME project complexity. Thus target jhbuild only. Using modulesets (it's called like that, right?) for jhbuild and writing an export/import utility to transform the jhbuild's moduleset into another automated build integration could be also doable, hypothetically speaking. If any such thing would be needed in the future. That is, let's target jhbuild first. The jhbuild already has a functionality
Re: [ Revised Proposal ] Continuous Builds in GNOME
On Thu, 2016-06-16 at 14:16 +0900, Tristan Van Berkom wrote: > o The integration branch of every module is continuously > reconstructed based on that module's master branch. Hi, as the 'integration' branch targets only jhbuild, then it doesn't make sense to add it at each git module, no? Thinking of it, instead of playing with a jhbuild only, you propose to add one more layer (and place of possible issues) between the git master <-> jhbuild connection. The proposal, as I understand it, is: git master <-> git integration <-> jhbuild where the git integration can be sometimes skipped in the jhbuild. But as you already have a functionality to skip some commits inside the jhbuild, and the integration branch is meant to do exactly that, then why to have one software which would eat only space on a disk in each git module with a new branch history, instead of writing the automated build tool which would cooperate directly with the jhbuild setup? You also want to add some restrictions on the git integration branch, which is even more unnecessary work. Not having the branch will make things easier for the developers and new comers too, as there will be no confusion for them. Having somewhere a super-detailed description of the integration branch intention is nice, but it'll be easy to forget of it during the time. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Mon, 2016-06-06 at 20:32 +, Sriram Ramkrishna wrote: > I think that is the point of the try server, right? You push it to > the try server and make sure that it builds correctly for everyone... Hi, if you mean that "jhbuild" is a synonym for "everyone", then you surely didn't open [1], to which I gave a link to earlier. There jhbuild succeeded, my local build succeeded, Fedora build succeeded, still there was an environment where it failed. And it failed properly, I'd say. Your idea of the "try server" makes me think of the way WebKit has it done. You attach a patch to their bugzilla, set some flags and a bot runs some testing and builds in various environments with that patch applied. All automated. Anything like that can work for smaller patches, but once you think of the bigger changes, like the aforementioned Camel API change [2], you get into a very different world. > A lack of diligence on your part for instance costs time and > headache somewhere else. Right, I agree, there will be always someone unhappy. The question of this thread, and the whole idea of the reverts, is who that will be. > Nope and Emmanuele does stipulate that we need someone to monitor the > build and act accordingly. However, the rest of you have an > obligation when that person nags you about it to respond in a timely > manner. I hope it was understood from my mail that I am not part of that "the rest of you" group. What you said makes me feel that you think that everyone else is "a bad guy". That's really not true. The "timely manner" is the keyword too. Sometimes it takes time before the maintainer notices that the Continuous broke. Consider different timezones, weekends, public holidays in different countries and so on. Everything matters when it comes to "timely manner". I know, this thread is also about addressing just this in some not so cruel way to anyone. > I think we all agree that there should be change, we just need to > agree what is the minimal set of things we can accomplish today and > then iterate there. We just need to establish a place where we can > at least start on a path and break current status quo. I'm sorry, but the current state works for me. Of course, I do not work on the Continuous, I have no idea how much time and headache it costs to keep it working with so many involved projects. Thus my point of view is not objective, it's rather subjective. > In general, I really don't like the idea that we're all a set of > fiefdoms with no influence on each other. Some projects are core parts, where others can use them. Some are on "leafs", final applications, which cannot be reused (in a library sense) by others. Those are very different types of projects. As had been said in this thread, Continuous doesn't build each hosted project in the GNOME infrastructure. Bye, Milan > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=766540 > > [2] https://bugzilla.gnome.org/show_bug.cgi?id=764065 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Mon, 2016-06-06 at 22:21 +0200, Sébastien Wilmet wrote: > On Mon, Jun 06, 2016 at 10:10:58PM +0200, Sébastien Wilmet wrote: > > > > There is a solution: bump the major version of Camel or EDS each time an > > API or ABI break is unavoidable, making the new major version > > parallel-installable with the previous ones. And that, every 6 months if > > needed (or one year if the development cycle is longer for the > > Evolution-related projects). Hi, there is no need to give me pointers to things and practices which are already used in the project. It can be useful for some other projects, for some maintainers following this thread, thought. I mean, that's exactly what we do (unless accidentally overlooked). If the API/ABI changes, a soname version is bumped for that respective part, at least once between releases (I just did a soname version bump of Camel for 3.21.3 in one commit, then I did another change in the Camel API in another commit, but I didn't bump the soname version, because that all will be available for the early adopters in one single release, 3.21.3). > Mmh maybe it's not possible for EDS, since it's a daemon (or contains > a daemon) and thus only one instance can run on a system. I don't > know much about how EDS, Camel etc are designed. The Camel is a library, which happens to be part of the evolution-data- server. The evolution-data-server consist also of some D-Bus services, which allow clients to connect to them and have address books and calendars, tasks, memos. The Camel library is used for Mail and it doesn't provide any such D-Bus service as of today. The D-Bus services are also versioned, thus, if needed, the version can be bumped. Nonetheless, the evolution-data-server doesn't support parallel builds into the same prefix, neither the evolution. We diverged from the initial thread topic a bit here, I'm afraid. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Mon, 2016-06-06 at 09:49 -0500, Michael Catanzaro wrote: > A revert is not supposed to be "punishment" in any way... rather, > consider it as assistance to make sure GNOME stays buildable. :) Hi, maybe it's not supposed to be, but it is in my eyes. I try my best to not break builds, I'm grateful when other folks let me know when the builds are broken for them. Neither jhbuild catches everything [1], which you seem to suggest. I broke build in general, not only in the jhbuild, in the not so distant past, which was a shame and it was all my fault. I'm sorry for that, though in that particular case the change on the evolution-data-server side was correct, only the evolution build broke, because it wasn't updated appropriately. The revert on the eds side would not make any sense. It was correct, as I said. (API changed in some way and I didn't realize that the evolution uses the API in a way which breaks it. Just my fault.) I do not fully understand why reverting in some random project (and making sort of hostile environment) is easier than the current state, when the same person "tags" what commit is supposed to be used in Continuous in the jhbuild. You still need the person, the person cannot be a monkey, it will think before doing anything (I mean, it's not a mechanical job where one rule fits each case). I appreciate how Emmanuele and others (are there any others?) handle the situation right now. I do not want to add them more work, really not. > we can create a list of maintainers who don't want this Nah, that's one more place to look at and to forget about. That adds work to those nice folk(s) whom take care of the Continuous. > In this case, when the API change breaks something in core or gnome- > apps, then the module and its dependencies really need to be updated > in jhbuild at (approximately) the same time, so there's at most a > small window of time where jhbuild is broken. > ... Right, it's unrealistic in some cases to land all of that at one time. Side branches is a nice idea, but it won't work, because you do not have any influence on the other project maintainers usually, thus even a bugzilla requests can lurk there for a long time. Having a side branch only means that the maintainers whom do not follow particular mailing list will notice only later, rather than sooner. There is a bug to make more structures in Camel GObject based [2], to be able to introspect it in a much easier way and so on. That change will not be only a simple API change, it'll break core Camel things, everything what uses it. If you open the [2], then I listed affected projects at the end of the comment #5. It counts 18 projects. Maybe there are more. I do not think I'd be able to coordinate the change in a side branch for all of them, I (we) will surely provide patches in the bugzilla around the time of the change landing, then it'll be up to the respective maintainers to pick or reject them. What will the Continuous do during this "broken period" is something I do not know. I only know that the change will be for good. Introspection support for the Mail part is good, I believe. Trying to revert such change in the eds would hurt very much, no doubt. > Yeah, of course runtime bugs are problems, but not the problem we are > trying to solve here. :) Heh, true, though the runtime bugs are more important. I believe. I know, that's one reason why you want to have the jhbuild working, to make it easier for the contributors to test and develop. Which is a good thing for everyone. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=766540 [2] https://bugzilla.gnome.org/show_bug.cgi?id=764065 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Continuous Builds in GNOME
On Fri, 2016-06-03 at 08:28 -0500, Michael Catanzaro wrote: > I expect module maintainers to be understanding when reverts happen. > It's not the end of the world; you can land your change again as soon > as you figure out why it was broken. We can all live with a few > revert commits in our git history. Your module can still be your > fiefdom... just so long as it's still building with the rest of > GNOME. Hi, I'm not a fan of the random reverts from some 3rd party person whom doesn't know the "bigger picture" of the project changes which can lead to a win-win state, even the changes are that large that it's better (for whatever reason) to split them into several commits, which not necessarily follow in a short time. Such reverts would mean more work for the maintainers, which is always a pita. I hear here an argument that the maintainers claim that "it builds on their machine" and they do not care of the other build environments. Personally, I do not understand this statement, one (the maintainer) should be willing to support his project home, appreciate that the project can use the infrastructure and be tested in more places, which is always a good thing. The proposal about random reverts makes me feel that you want to flip the positions. While I agree that the maintainers point of view is broken, the position flip just means (for me): "the GNOME infrastructure/jhbuild environment is the only good build environment and if the maintainer breaks it, then the GNOME infrastructure team can punish the maintainer if it needs to". Do you see how absurd it sounds? The breakage should be dealt with in a cooperation manner, rather than in a force manner. Of course, if the maintainer is not willing to cooperate..., but I hope that's only a minority of the GNOME-hosted projects (I do not know any numbers here) and definitely the core project maintainers are all good, I believe, thus there might not be any issue. The "bad" projects, if not from the core part, can be skipped in the Continuous builds due to the lack of the interest from the maintainers side. There had been discussed also what can be reverted and what not. If you recall: - a soname version bump can break dependant projects. Such change should not be reverted, the dependencies should be rebuilt. - a soname version bump with an API change can break dependant projects. Such change should not be reverted, the dependencies should be rebuilt and adapted to the change. - a change which can build, but causes regressions in runtime. Such change should be reverted, right? But wait, you care only about the build, not about runtime. Having a software buildable and having the same software usable are two very different things. I suppose the GNOME build system runs some unit tests, if the module provides such, but such tests are testing the new code, not the regressions the change in the module can cause in another module which had been/will be built against it. Just my opinion on the matter. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pull request template for github mirror
On Mon, 2016-02-29 at 14:52 +, Emmanuele Bassi wrote:
> $ git pull github-mirror pull/${PR_ID}/head:pr-${PR_ID}
> $ git checkout pr-${PR_ID}
>
> From then on, you can push/merge/pull/rebase as usual.
Hi,
well, it's too much overhead for:
a) someone whom does not have a github account
b) wants to get to a patch which consist of 20 lines total.
Imagine the wasted bandwidth...
Anyway, this diverged from the subject of this thread a bit.
Bye,
Milan
P.S.: If people could help to newcomers from github with the workflow
on the GNOME side the same, then there probably wouldn't be needed any
read-only, pull-request-disabled mirror of GNOME projects
on the github at all :)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pull request template for github mirror
On Mon, 2016-02-29 at 15:44 +0100, Frederic Crozat wrote: > Once you have the url of the pull request, just add ".patch" to it > and you'll get a properly formatted patch. Hi, yes, that's the trick I was told to do. My point was that there is absolutely no sign in the Web UI of github to do so, thus unless you know someone whom is already capable of it, you are just doomed. Or at least I was, until I asked the co-worker. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pull request template for github mirror
On Fri, 2016-02-26 at 23:30 +, Alberto Ruiz wrote: > These contributions (there's about 200 pull requests, see link below) > would likely not have happened if we didn't have a presence in > Github. Shutting down the mirror would simply stop that energy. Hi, I think it would be good to check the numbers in more detail. The github mirror had been officially announced on 2013-08-15. Since them there had been created 515 pull requests (I modified your search query on the github) [1]. Then I tried to query GNOME bugzilla for bugs with not-obsolete patches whose status changed after 2013-08-15 [2]. The first run stopped at 500, the second run at 1 bugs. It can be that some patches got changed status while they had been contributed before the github mirror announcement, thus the numbers might not be accurate, but I believe they are quite close. And now, if I count properly, those 515 pull requests represent 5.15% of the GNOME contribution for the past ~2.5 year. I tried to query also for committed patches only [3] in the GNOME bugzilla, which returned 8199 bugs, which is around 6.28% of the contribution to the GNOME projects (not only sources). I do not want to judge whether it's too low or not. It depends on several things and on the point of view. I only wanted to have some comparable numbers (which I hope I managed to get from the bugzilla). In my case, I found, thanks to your link, some pull requests in the github for the projects I take care of, and they were like this: - one correct - committed to sources - one incorrect - I sent an email to the creator (no github account here) - two for README files, which I both "rejected", but fixed it in the sources in a better way - one obsolete - I do not know why it is still opened - one for translation - out of my hands, translations are treated very differently from the sources - one semi-pending - its author found the right place to contribute and made more extensive changes directly through the GNOME bugzilla already, which I appreciate As I work with raw patches usually (I just got use to it after all the years) the github web UI is very confusing for me and I didn't find a way to convert the pull request into the patch. I asked a co-worker whom has a github account for a help and he also didn't find it, but he knew a trick and told me about it - it didn't involve any click-able way on the github pages to get to the patch, sadly. Maybe my workflow is just too different from that supported by the github, or vice versa. That's just it. No judgement from my side, but also do not expect me to regularly check github mirrors for any pull requests, rather expect bad experience from the possible contributors of the projects I maintain. Being it on me, I'd rather drop those projects from the github and let them use the only right place for the contribution, the GNOME infrastructure. Bye, Milan [1] https://github.com/search?utf8=%E2%9C%93=type%3Apull+user%3Agnome=Issues=searchresults [2] https://bugzilla.gnome.org/buglist.cgi?chfieldfrom=2013-08-15=Now=attachments.ispatch=attachments.isobsolete=attachments.gnome_attachment_status_id=102746=equals=notequals=changedafter_format=advanced=1=1=2013-08-15 [3] https://bugzilla.gnome.org/buglist.cgi?chfieldfrom=2013-08-15=Now=attachments.ispatch=attachments.isobsolete=attachments.gnome_attachment_status=attachments.gnome_attachment_status=0_id=102750=equals=notequals=changedafter=equals=bug_id_format=advanced=1=1=2013-08-15=committed ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.20 target bugs
On Thu, 2016-02-18 at 07:35 -0500, Matthias Clasen wrote: > 751588 evolution Port to WebKit2 Hi, I would change the GNOME Target to 3.22, but I'm not able to do it, the value is not a Drop Down, but a static text for me. The thing is that the port to WebKit2 won't happen in time for 3.20 for the Evolution. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Build sheriffs for GNOME
On Fri, 2016-01-22 at 16:03 +0900, Tristan Van Berkom wrote: > In summary, I am not opposed to applying your proposal as is to the > stable builds, there is no justification *ever* for breakage in stable > branches. > > For master, I only think this needs to be detailed properly, perhaps it > would be enough to ensure we had policy ensuring that intentional > breakage is announced (on this list ?) and that "sheriffs" are > responsible for following this list and not reverting commits which > break things intentionally in a transitional period. Hi, I agree with Tristan. I was just about to write something along his lines. Seeing semi-automated reverts in the projects would be quite depressing, especially when the semi-automat has no idea about the project and what the change was meant for. It makes sense to make sure the build works *before the release*, but when we are in the middle of two releases, then the build break might be just a red flag, not an excuse to break someone's work by the revert. I sometimes find it hard to plan some larger work due to too often releases (it's for a really large work, which can take several weeks to accomplish, then some more to fine tune in the real world usage). If you add this precedence, to always let someone ask: "oh, well, can I commit it? It's large, would anyone revert it? My change touches API and influences like 5+ projects, where I have only 3 under my direct control, thus the main commit is almost immediately followed by corresponding fixes in those projects I've under control, but some still can be broken", then I'm afraid the "hostile environment" would be a very nice word about GNOME and its infrastructure (people would use much much worse in the case you'd really make your proposal alive). This is also about different environments, you partly mentioned it. I believe most of the maintainers build before commit. I do, but I'm a human and mistakes happen. Some mistakes are independent of the build environment (I'm sorry for the before-Christmas breakage of the eds), some are not. I recall broken builds even in jhbuild when API changes happened (clean build was required to make it work, there was nothing wrong about the sources). Even for example Ubuntu environment is different from that I use, causing undefined symbols on places which work just fine for me. What would you revert then in my project? I know, Continuous, it built an hour earlier, it should build now too. Anyway, doing any reverts might not be implicit, not without a previous discussion with the respective maintainers (unless they are not reachable), and only a day before the release - or on the Friday when the notification mail is sent, though for Weekend Contributors it would make more sense for Monday morning of the release day? I do not know, people can fix things just before the release too. It's because the GNOME should build from the release, not necessarily from the git snapshot. The Continuous idea is great to discover build breaks early, but it's not an excuse to damage anyone's work. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Maintainers, please read this. [Re: GNOME 3.19.2 unstable tarballs due]
On Wed, 2015-11-25 at 10:52 +, Philip Withnall wrote: > Would such a list be useful for the release team, as a way of > tracking who needs nagging? If so, then I hope producing it should > not be too much of a drain on your time — if it is a drain, then you > probably shouldn’t do it. Hi, it would be nice, if anything like this will be implemented, to have the notifications on the opt-in bases. I understand the need for maintainers of tons of modules which do not receive any active development, but for me, whom has only few packages, would be the notification a simple spam and thus quite annoying thing. I'm fine the Friday notification about the following Monday release. I have also setup a calendar notifications about the releases. Just my opinion on the matter. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Questions about the migration from GConf to GSettings/DConf
On Sun, 2015-07-19 at 23:17 +0800, Oliver Luo wrote:
I've been spending several days working on the migration from GConf
to GSettings/DConf in our project evolution EAS...
Hi,
I suppose you mean evolution-activesync, as it's named in the GNOME
repositories.
1. Use relocatable schemas. In this case, we have one schema being
relocatable, and multiple instance of that schema so we can store
accounts of uncertain number. But the question is that the instances
are separated and there seems no API to control them as a whole,
which means we lost the structure information and make things harder
in our project.
Briefly grepping the evolution-activesync code, the keys being read
from the GConf look like:
/apps/activesyncd/accounts/email/key1
/apps/activesyncd/accounts/email/key2
...
so you can have a relocatable schema with { key1, key2, ... } and
attach it under /apps/activesyncd/accounts/email. That feels pretty
straightforward, and if I understand your text properly then you know
it. The thing you face is to know the list of configured accounts.
I would create a 'list' key with a list of known accounts in
/apps/activesyncd/accounts/, which will contain the email of each
configured accounts, and an existing path in GSettings. I saw this
approach being used in another project, I think it was gtk+.
I don't have the perfect solution yet, so I'm here to see if anyone
could help me.
The evolution(-data-server) also used to store its account settings
into GConf, but then moved away from that idea and instead of migrating
account settings into GSettings it uses its own ESourceRegistry. You
can create tree of ESource-s there, each can have its own extension,
where it stores its data. Maybe it would work better than the
GSettings. See how evolution-ews stores its settings on an ESource for
an example (it uses an ESourceCollection for the parent ESource).
Alternatively, maybe, create your own API on top of a GKeyFile and
store the account information in it?
Bye,
Milan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk-doc-1.22 change wrt to tmpl builds
On Mon, 2015-05-11 at 11:19 +0200, Milan Crha wrote: I'm trying to build evolution-data-server 3.16.2 against gtk-doc-1.22 and it fails [1]. It has its configure.ac with this line: GTK_DOC_CHECK([1.14],[--flavour no-tmpl]) thus should not be affected by the change. Trying to build against gtk-doc 1.21 works flawlessly. Hi, just a follow up that Stefan didn't forget of me. I filled https://bugzilla.gnome.org/show_bug.cgi?id=749268 and we continue there. The git master of gtk-doc had this already fixed. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtk-doc-1.22 change wrt to tmpl builds
On Sun, 2015-04-26 at 21:38 +0200, Stefan Sauer wrote:
The upcoming gtk-doc-1.22 release will switch the default makefile
flavour from legacy to no-tmpl.
Hi,
I'm trying to build evolution-data-server 3.16.2 against gtk-doc-1.22
and it fails [1]. It has its configure.ac with this line:
GTK_DOC_CHECK([1.14],[--flavour no-tmpl])
thus should not be affected by the change. Trying to build against
gtk-doc 1.21 works flawlessly.
I'm wondering, could there be a regression in the gtk-doc 1.22, or is
there anything I should fix in evolution-data-server? The thing is that
if I understand the errors properly, then it's in the generated files,
which are mostly out of my hands.
Thanks and bye,
Milan
[1] The actual build errors with gtk-doc 1.22:
DOC Building HTML
../xml/e-source-webdav.xml:125: parser error :
Opening and ending tag mismatch: note line 125 and para
paranote/para
^
../xml/e-source
-webdav.xml:131: parser error : Opening and ending tag mismatch:
para line 131 and note
para/note/para
^
../xml/e-source-webdav.xml:157: parser error : Opening and ending tag
mismatch: note line 157 and para
paranote/para
^
../xml/e-source-webdav.xml:163: parser error : Opening and ending tag
mismatch: para line 163 and note
para/note/para
^
../eds-docs.sgml:118: element include: XInclude error : could not load
../xml/e-source-webdav.xml, and no fallback was found
../xml/e-book-client-cursor.xml:244: parser error : Opening and ending tag
mismatch: programlisting line 242 and para
gdouble percent;/para
^
../xml/e-book-client-cursor.xml:245: parser error : xmlParseEntityRef: no
name
para// Fetch the position total
^
../xml/e-book-client-cursor.xml:256: parser error : Sequence ']]' not
allowed in content
para// Let the user know the percentage of contacts in the list
^
../xml/e-book-client-cursor.xml:256: parser error : Sequence ']]' not
allowed in content
update_percentage_of_list_browsed (user_interface,
percent);]]/programlist
^
../xml/e-book-client-cursor.xml:256: parser error : internal error:
detected an error in element content
update_percentage_of_list_browsed (user_interface,
percent);]]/programlist
^
../xml/e-book-client-cursor.xml:256: parser error : Extra content at the
end of the document
update_percentage_of_list_browsed (user_interface,
percent);]]/programlist
^
../eds-docs.sgml:135: element include: XInclude error : could not load
../xml/e-book-client-cursor.xml, and no fallback was found
../eds-docs.sgml:1945: element refsect2: validity error : ID
CLIENT-BACKEND-PROPERTY-CAPABILITIES:CAPS already defined
../eds-docs.sgml:1951: element refsect2: validity error : ID
BOOK-BACKEND-PROPERTY-REQUIRED-FIELDS:CAPS already defined
../eds-docs.sgml:1957: element refsect2: validity error : ID
BOOK-BACKEND-PROPERTY-SUPPORTED-FIELDS:CAPS already defined
../xml/e-data-book-cursor.xml:157: parser error : Opening and ending tag
mismatch: programlisting line 151 and para
gint i;/para
^
../xml/e-data-book-cursor.xml:160: parser error : StartTag: invalid element
name
for (i = 0; i cursor-n_sort_fields; i++) {/para
^
../xml/e-data-book-cursor.xml:174: parser error : Sequence ']]' not
allowed in content
para state-last_uid = e_contact_get (contact, E_CONTACT_UID);
^
../xml/e-data-book-cursor.xml:174: parser error : Sequence ']]' not
allowed in content
]]/programlisting
^
../xml/e-data-book-cursor.xml:174: parser error : internal error: detected
an error in element content
]]/programlisting
^
../xml/e-data-book-cursor.xml:174: parser error : Extra content at the end
of the document
]]/programlisting
^
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Current status of the GNOME Github mirror
On Wed, 2015-05-06 at 09:46 +0100, Emmanuele Bassi wrote: Indeed. Getting notifications of open pull requests to the maintainers listed in the DOAP file would also be good, so each maintainer can decide whether or not to integrate one or just direct. Hi, please do not do this by default. I do not have any Github account, neither I'm planning to have any anytime soon. I prefer the GNOME way, not the Github way. If Github mirrors are getting so much trouble, why not kill them once for ever? It was a surprise to get the mirror on Github the months back for me, and if it doesn't work even now, then maybe the idea of the mirrors wasn't the best and might be reverted. It feels odd to have any Github specific files in the GNOME repositories of the GNOME projects too. Aka if you want to setup Github, then setup it in Github, not in GNOME. (Yeah, I know the meaning of the 'mirror' word.) Just my opinion. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
