[Evolution-hackers] EWS: Broken server tests
server/tests were/are not building in git master. So, I did a patch series
(please, check: https://bugzilla.gnome.org/show_bug.cgi?id=695177), fixing
the build problem. However, trying to run a make check
looks like the tests are broken themselves[0]. To run the tests, I did:
- set EWS_TEST_USERNAME as a valid username
- set EWS_TEST_PASSWORD as a valid password
- set EWS_TEST_EMAIL as a valid exchange email address
- set EWS_TEST_URI as the URL for a valid exchange email server.
[0]:
fidencio@srv ~/src/gnome/evolution-ews/src/server/tests $ make check
make testews
make[1]: Entering directory
`/home/fidencio/src/gnome/evolution-ews/src/server/tests'
make[1]: `testews' is up to date.
make[1]: Leaving directory
`/home/fidencio/src/gnome/evolution-ews/src/server/tests'
make check-TESTS
make[1]: Entering directory
`/home/fidencio/src/gnome/evolution-ews/src/server/tests'
/libews/connections: Test Connections
Success : Created a new connection
Testing Autodiscovery
test-connection.c:128 con_test_autodiscover : password : xxx xxx
test-connection.c:129 con_test_autodiscover : email : f...@bar.boo
Testing postive case...
/bin/sh: line 5: 22369 Segmentation fault (core dumped) ${dir}$tst
FAIL: testews
===
1 of 1 test failed
Please report to http://bugzilla.gnome.org/browse.cgi?product=evolution-ews
===
make[1]: *** [check-TESTS] Error 1
make[1]: Leaving directory
`/home/fidencio/src/gnome/evolution-ews/src/server/tests'
make: *** [check-am] Error 2
Could someone(Tristan?) take a look in:
https://bugzilla.gnome.org/show_bug.cgi?id=695177
Is there someone (Tristan, maybe) taking care of those tests?
Any tips to fix the errors/set up correctly the environment are welcome.
Best Regards,
--
Fabiano Fidêncio
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Matthew, On Tue, Jul 23, 2013 at 4:10 PM, Matthew Barnes mbar...@redhat.com wrote: I've been kicking around this idea for awhile now, but haven't said anything until now. I'm putting it out there as food for thought. Increasingly I'm feeling like the traditional 6-month release cycle is just too short for Evolution. In terms of development, we have a pretty short window for landing major changes and allowing adequate time for testing before development freezes set in. But more importantly, our users seem to be constantly playing catch-up in terms of supported releases. Because of the delay between upstream releases and distro releases, by the time users finally upgrade to a newer Evolution, more often than not they're upgrading to a version that's either nearing the tail end of its 6-month support window or is already unsupported. That's frustrating, both for users and for me as a developer, but we just don't have the manpower to support multiple stable releases and still get any kind of significant development work done. I'd like us to consider moving to a 12-month release cycle, which would sync up with GNOME's release schedule annually instead of semi-annually. Here's my initial proposal, if you guys are open to this: * Continue with the 6-month releases through the end of the year, just because I think we need more lead time for such a major policy change. * Bump Evolution's major version number to split away from GNOME's semi-annual release numbering. Call the upcoming March 2014 release Evolution 4.0 (or perhaps even Evolution 2014... I'm open to ideas). * We would follow GNOME's string change announcement and freeze schedule in the months leading up to each March release. * We would continue releasing stable updates and development snapshots at a steady pace. Our release schedule could even be more predictable than it is now. We could do, for example, stable releases on the 1st Monday of each month and development snapshots on the 3rd Monday. Obviously there's more details to figure out, but I like the precedent we've set with the 3.8 branch, and I think our users appreciate it too. My feeling is just that at this point in the project's lifespan, our users would be better served by a longer support window. They still want to see improvements and new features, but more than anything I think they just want stability and to see their bugs fixed without waiting half a year. It's just an idea. What do you guys think? Matt I also fully agree with your suggestion. As we have discussed, users are reporting bugs against 3.8.x now and they will need to wait at least 6 months before they get a fix in 3.10.x. I mean, from the stability point of view it would be great if we have a larger window to work, test and correct our mistakes.. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Reconsidering our release cycle
Srini, I really wouldn't want EDS to be part of this, if we ever want it to be a proper platform/core material. Just Evolution would be better fit for this model IMHO. Could I ask you why? If you check our git's activity you will see that the most part of bugs we are fixing are touching both in Evolution as in EDS. I really cannot imagine these two parts not walking together. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] News from EWS world
Please, take a look on: http://blog.fidencio.org/2013/11/evolution-ews-notification-operations.html Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] [Draft] Evolution Road-map for post-3.12
On Thu, Jan 23, 2014 at 5:12 PM, Milan Crha mc...@redhat.com wrote: Hello, as all/most of you might know, after 3.12 release Evolution changes its release schedule to a yearly development, which may give more room for any larger changes. I'd like to start a Road-map draft with things I believe will be good to have. They are not in any particular order, any of them can be moved up/down/dropped/... Probably not all of them will make it for 3.14, but that's understandable. Here's the list: * complete the Webkit-based composer - either complete or just take care of bugs from users - fixes might reach 3.12 as well * revisit the webkit2 port * change the UI of component editors for calendar views (events/tasks/memos) * merge calendar views internally - to avoid code duplication; after all, the main differences are only a) component type; b) allowed subviews (day/month/.../list). Otherwise they are just the same. It'll be a big task, because I'd like, together with it, avoid UI thread blocking from calendar-related views * renew the calendar views to gtk-based or webkitwebview based views * add an offline cache for calendar and book backends, together with: * create a meta backend, which will allow backend writers to focus on the tasks related to conversion from libical components into their stores, instead of reimplementing common things; this task might depend on the offline cache, because it would be nice to have the meta backend with the offline support built-in, thus the users of the meta backend gets something more for free * merge backend factory codes even more than it is now, because the book and calendar factories are basically the same, serving to the same thing, thus there surely is more common things that can be done in one place, not two * make backend factories crash-proof - a thing which I think Matthew suggested (a long) time ago - move each backend to a separate process, thus if any of them crashes for whatever reason, the other backends will keep running (all backends are running in one process today, thus when one crashes, all of them are gone too) I cannot recall anything more right now, sadly neither for EWS, but there are surely some nice feature requests, which would be nice to have done (like the Information Rights Management thing). I'd like to revisit this thread[0] at some point in the future. [0]: https://mail.gnome.org/archives/evolution-hackers/2013-May/msg3.html Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GSoC Ideas
On Tue, Feb 11, 2014 at 1:44 PM, Emre Erenoglu ereno...@gmail.com wrote: 1) Enhancement of search bar with expression search ability, such as: from:emre to:evolution subject:search or shortly f:emre t:evolution s:search It could be done within the notmuch idea, no? 2) Attachment Detach and Link function Could you elaborate a bit more, please? -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] GSoC Ideas
Guys, First of all, I'd like to move a few Ideas to https://wiki.gnome.org/Outreach/SummerOfCode/2014/Ideas What I can see as do-able for now are these following ideas: Idea: Complete instrospection suppor for EDS (mentor: FabianoFidencio) Benefits: With introspection working in calendar backend we can improve our tests (that can be written in another languages than C) and make the calendar backend usable for another projects. Requirements: C, GObject, GLib Notes: This project consists basically in write a libical[0] wrapper, using GObject, to replace the libical's APIs that are being called directly in EDS calendar banckend. Introspection works properly for Addressbook backend. [0]: http://www.citadel.org/doku.php/documentation:featured_projects:libical Idea: Standalone app for editing server-side Sieve[0] fielters (mentor: MatthewBarnes) Benefits: Support server side filters in evolution. What could be done using the standalone app as a useful starting point. [0]: http://sieve.info/ Requirements: C, GTK+, GLib Notes: Idea: Improve threading algorithm (mentor: AlbertoRuiz) Benefits: A better usability for the users, once our current threading algorithm is not that smart. Requirements: C, GTK+, GLib Notes: Ideally we should try to math GMail's Idea: Notmuch[0] as indexer and search language (mentor: AlbertoRuiz/FabianoFidencio/MilanCrha) Benefits: A real gain for usability once the user will be able to search something in a gazillions of mail and get the results really fast. Requirements: C, GTK+, GLib, D-Bus Notes: Alberto Ruiz started a proof of concept using this git repo: https://github.com/aruiz/evolution-notmuch [0]: http://notmuchmail.org/ Idea: Implement a simple PKCS#11 module using evolution's addressbook as a backend (mentor: DavidWoodhouse) Benefits: Allow users to send encrypted email to contacts with X509 certificate Requirements: C, GTK+, GLib Notes: A small discussion about this idea/issue was started in https://bugzilla.gnome.org/show_bug.cgi?id=704246 Could you guys please take a look and correct some bullshit that I eventually have written down? About the ideas that showed up today, I'd like to see Milan and Matthew opinions. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Interested in contributing towards 'Notmuch' project idea
Hi Parin, So, what level of GLib is required for this project ? You will not hack GLib itself, only use what GLib can provide to you (i.e, thread support, data structures and so on). GLib is pretty well documented (https://developer.gnome.org/glib/stable/) and if you have any kind of problem you can ask for help in #evolution or #gnome-hackers channels. I would like to discuss the current situation, scope of the project and expansion of this idea. Is the channel #evolution better, or is the mailing list okay ? I guess the ML is better, because another students can take advantage of the archive :-) Also, I'm going to update the wiki with more info about the ideas and a how to start contributing with evolution in the next days. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] newcomers: How should I compile Evolution?
Howdy!
I can bet that (almost) every contributor has a different way to setup the
environment, compile and use the fresh compiled Evolution and I'm here to
describe the way I do my setup (based on Matthew's setup) :-)
Firstly, jhbuild or not jhbuild?
--
I like to use jhbuild for a few projects that I use and contribute. But
that's not the case for Evolution. As Evolution has a small set of
dependencies and usually none of them are bleeding edge, I'd say do *not*
go for jhbuild in this case.
So, what are you using, Fabiano?
-
I'm using these 2 scripts: common and unstable (
http://rachacuca.org/~fidencio/evolution/newcomers/).
Both of them are in my $HOME/.local/bin and this folder is part of my $PATH.
Then when I open a terminal I just do source unstable and I'm all set to
build from the master branch :-).
When configuring evolution-data-server or evolution I use:
./configure --prefix=$PREFIX, which the unstable script defines to be
$HOME/local/unstable -- so that's where evolution-data-server/evolution get
installed.
*If* I need to build a base library like GTK+, then I use:
./configure --prefix=$COMMON, which the common script defines to be
$HOME/local/common and that way I keep base libraries separated from
evolution-data-server/evolution.
And before running Evolution, what I do is start manually the
evolution-source-registry and the factories processes
(evolution-{addressbook,calendar}-factory) located in
$HOME/local/unstable/libexec/
I do believe this is the simplest way for compiling, using and debugging
Evolution Data Server/Evolution.
Best Regards,
--
Fabiano Fidêncio
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Congratulations to GSoC students!
Heya! Is a great pleasure to announce that we will have 2 students, as GSoC interns, helping us (at least) for the next 3 months. We have announced a few ideas for GSoC and the selected students/ideas are: - William Yu: Add introspection support for the calendar backend - Watson Yuuma Sato: PKCS#11 module Please, guys, show up in the channel and try to contact your mentor as soon as possible to review your plans for the next 1.5 month and get an agreement about what will be delivered by the midterm. Ah, please, keep in mind that the mentors are living in Europe (GMT in dwmw2's case and CEST for mcrha and I). If you have any issue trying to communicate with your mentor, *please*, send us an email in evolution-hackers ML (yep, this same one) and we will try to help you. Looking forward to meet you guys in #evolution channel! Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Frequent Segfault on Master
On Wed, Jul 9, 2014 at 3:12 PM, Emre Erenoglu ereno...@gmail.com wrote: Hi, I'm getting frequent crashes on master built today and 3-4 days ago, to the level of being unusable. I am assuming that you're aware of it and since this is development master, these are expected, so I'm not filing a bug report, unless you ask me to do so. Please, do it :-) Also, attach a gdb backtrace on the bug report and steps to reproduce. Best Regards, -- Fabiano Fidêncio ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
