This is the 23th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happenend?

I'm a bit late this month, I know. Anyways, things happened in the imag distribution and I'm eager to write them down, so here we go!

In the last four weeks I merged a lot of PRs – 27 actually! Here are the most awesome ones:

• #836 eliminated the EntryHeader type entirely from the codebase. We are using toml::Value objects now!
• #852 was contributed by @mario-kr to enable cargo workspace support! That was a really awesome PR, as it reduced our build times down to ~4 minutes!
• #854 removed a lot of things (>4k lines) due to the focus-shift to libimagruby (read below)
• #871 added the ruby build setup (read below)
• #872 and #873 and #874 and #892 fixed some things to compile with fewer warnings. Awesome!
• #878 updated the regex dependency.
• #894 reverted the changes from #871 as it broke master :–(

Ruby?

Yes, Ruby!

We implemented the libimagruby, which contains Ruby bindings for libimagstore. So imag can now be programmed in Ruby!

There is a release (0.3.0) in the pipeline (waiting for fixes in cargo), which will then contain rudimentary support for programming the store in the wonderful Ruby programming language. I've written about that before and now it finally works. It is just not released yet.

The next release (0.4.0) will then contain more functionality to program imag, including some more bindings for libraries.

I think this will speed up development a bit, as we have more libraries in Ruby available.

What's coming?

Well, I hope to get out 0.3.0 soonish. We have to wait for Cargo, as we ran into a bug (misbehaviour) of cargo with the current release. As soon as the next cargo version is out I will try to release 0.3.0 and then we'll see...

Of course, I really hope to get some binaries implemented then. Starting with imag-diary and imag-mail, but also more advanced things like imag-music, imag-calendar and imag-contacts.

tags: #programming #rust #software #tools #imag

This is the 22th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happenend?

My masters courses are hard (time-wise). I didn't manage to do anything at all in the imag codebase. I hate it. I really want to get imag in a usable shape. So here's what I want to do to make this huge task a bit more achieveable.

Focus shift

I wrote about integrations before. I want to shift the focus of my work on imag to develop a Ruby gem from the imag functionality. This will be the next release. I will write either one or several gems with the imag libraries as backend, so one can write integrations in Ruby. I will do this because I think that the Ruby ecosystem fits the problem pretty well.

So what is the problem?

The problem is the following. We have a working imag store. We have working libraries on top of that “database layer” – namingly tags, refs (though they could use some polishing and features) and most importantly links (both external and internal).

What we do not have is the whole $tool -> database stuff. So we cannot put mails into the store, because we need to parse mails. We cannot put calendar data files into the store, because we need to parse icalendar. We cannot put contacts into the store because we need to parse vcard. And so on and so forth.

But the Ruby ecosystem has libraries for all these things.

So the obvious solution is to write a Ruby integration. We can then write the simple data-format-transformation tools in Ruby and we will be faster implementing it. We do not need the guarantees Rust gives us here – they would be nice, but they are not necessary!

Later, for querying the store, we can write the simple stuff in Ruby as well and the more complex stuff – or the performance-critical parts – in Rust.

How to do the shift?

I guess I will branch-off a major branch for the shift and remove some of the functionality which is already in the repository, namingly:

• imag-bookmark
• imag-counter
• imag-diary
• imag-mail
• libimagbookmark
• libimagcounter
• libimagdiary
• libimagmail
• libimagnotification
• libimagtodo

These tools implement functionality which would be way better be implemented in Ruby.

Clearly, some functionality can be kept. We can keep some of the more basic commands:

• imag-link
• imag-ref
• imag-store
• imag-tag
• imag-view (though a Ruby tool might come up with way better functionality)
• libimagentrytag
• libimagentryview

And the related libraries will be kept as well:

• libimagerror
• libimagref
• libimagrt
• libimagstore
• libimagstorestdhook
• libimagutil

I'm not sure about imag-notes though. A Ruby tool might have better functionality for this, though imag-notes works for me pretty well so far, so we might keep it, and its library:

• imag-notes
• libimagnotes

The other libraries... I'm not sure. Maybe some of the tools listed above need them (really... I haven't looked at the codebase for a long time now cry). So maybe we must keep them, maybe we can remove them:

• libimagentryedit
• libimagentryfilter
• libimagentrylink
• libimagentrylist
• libimagentrymarkdown
• libimagtimeui
• libimaginteraction

imag.rb

And we will introduce one new crate: imag.rb. This will be a ruby crate – so we will use ruru to build a Ruby gem out of the functionality implemented in the core crates. Clearly, the first step would be to put the libimagstore interface into this crate (plus its dependencies, libimagerror, libimagutil, ...), but I guess it is a good idea to have libimagtag, libimaglink and the functionality of the other core-libraries in there as well.

How long?

Your question might be: How long will this take? Well. Yes.

I really don't know. As said countless times: Masters degree is engaging. I hope I can get some things done after my exams (which end mid-february). until then – I don't think I have time to do much things.

Help is appreciated, though!

tags: #programming #rust #software #tools #imag

This is the 21th iteration on what happened in the last four weeks in the imag project, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

What happenend?

Well, as I said before, I have a really busy masters degree to do, so progress in imag slowed down a lot. Believe me or not, I don't like that. I want to continue to work on imag as much as possible, but right now, I just do not have enough time for it.

I have a plan, though.

But first, lets see what happenend in the last four weeks.

PRs/Issues

The following issues and PRs were touched in the last weeks:

• #764 initialized the work on imag-mail
• #838 bumped up the clap version
• #839 updated dependencies
• #840 works on bulk-import for imag-mail
• #841 is a bug report on the behaviour of imag link internal --list
• #842 fixes #841
• #843 fixes another small bug in a UI
• #844 fixes a typo
• #845 adds Makefile support for cargo-outdated

What will happen

Well, I cannot predict the future. As Christmas (and 33c3) is coming up, I don't know how much time I will have to work on imag.

But what I want to do: Shift my focus a bit. Before I had a kind of Shotgun-Approach: Implement everything, work on multiple things all the time. I will not do this anymore. In fact, I will move issues from the 0.3.0 release to 0.4.0 and so on, shift everything by one release. That will free the 0.3.0 release and I will focus on one goal in this release then: A scripting API.

I want to develop an imag library for writing scripts for imag. I think about Ruby, because that's a language I am familiar with. Another option would be Lua. I hope I can construct the scripting-API interface in a way so it can be re-used to write a Lua interface.

But that will it be for 0.3.0. Having a neat scripting API (not low-level but rather high-level) gives us the possibility to quickly write simple integrations with tools, for example to integrate mails, a wiki or something similar.

I hope that's a plan. 0.3.0 is due to March 2017 as far as I remember, so there's plenty of time for this.

My next post will be around mid-january 2017, so I think it is appropriate to wish you all a very fine Christmas and a good new year!

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 20th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

Also, I have some changes to this series of blog posts. Read about it here as well.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

In the past two weeks, we got almost nothing done, honestly. We had four pull requests and no new issues. Why is that? Well, most of the PRs are mine as well as most of the issues are opened by me. And I have a hell lot to do with my masters degree. Also, I want to write pull requests to the rust-vobject crate to give it a high-level interface to be able to write my calendar and contacts module with it. This is, as you might think, a nontrivial task and therefor take some time as well.

We had one new contributor though. Thanks to Steven Allen for PR #834.

That's why we didn't have that much progress. I will sum it up here:

• 834 optimized one point in libimagutil where I opened one file twice. Thanks again, Steven Allen, for the contribution!
• 835 moved the functionality of the EntryHeader (the querying by string in the header toml data structure) to a new libimagstore module, so the module libimagstore::store does only contain a minimal EntryHeader type for backwards compatibility.
• 836 eliminates the EntryHeader type completely and replaces it by toml::Value, its inner type. This is not completed at the time of writing.
• 837 adds older compilers to the CI setup for travis.

The future

Lets see what will happen in the next four weeks.

Yes, that's right. I will do...

Less updates

I will slow down this blogging series. This was the 20th iteration on the subject, so I already do this for 40 weeks now. I will now slow this down and only post every four weeks about imag. Partly because my masters degree is really time consuming, partly because I already planned this beforehand. Every four weeks will be enough, I guess. I'm not sure whether I will continue include all PRs and issues or only the major ones. We'll see.

Plans

For the next four weeks I plan to get some functionality into rust-vobject. I will then start to implement imag-contact and I hope to get some progress with imag-mail, but I cannot promise anything.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 19th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

We have more than 150 stars now! Wow!

Besides that we had really not that much progress in the last 14 days. My masters degree keeps me busy all day long and I really have a hard time with all the things I have to do for my courses, so progress slows down way more than I expected. But I can't change that, so ...

PRs merged/closed in the last 14 days

• 821 imported commits from our v0.2.0 release branch into the master branch.
• 822 updates our dependencies. Luckily this worked without too much hassle. Still, we had some problems while updating. We only had to update a method from itertools which was removed. We also had to update task-hookrs as both imag and task-hookrs depend on uuid and they really should depend on the same version of uuid, so I updated task-hookrs to the latest uuid, which in fact included some code removal in the codebase of task-hookrs. This was because uuid depends (and we also need it) on serde, which was update from 0.7.* to 0.8.*. As serde included some new awesome things, we were able to remove some code in task-hookrs.
• 823
• 827 implements PartialEq on StoreId, which is a really neat improvement in my opinion. We derive()d it before, but we now only compare the local part of the StoreId object (read: The store-part, not the path to the store itself, which could be absent sometimes, causing weird bugs).
• 828
• 829
• 831

Also, two really old PRs were closed. I do not list older PRs normally, but these two are really noteworthy:

• 624 included cargo workspace support in our build setup. I'm not sure it works the way I expected it to, as (for example) clap gets rebuild several times... but at least cargo doesn't yell at us anymore, so I included it.
• 656 sets the codegen units for rustc to 2. I hope we get slightly better build times on travis from that.

PRs opened in the last 14 days and not yet closed

• 824
• 826 bakes in shell completion generation for all the imag-* tools
• 832 – now, this is a really great PR from mario-kr. Mario found a way to build shell completion for all the imag tools, starting at the imag binary itself. I did not even think about this as solution, but it works and I'm willing to merge this as soon as Mario did some cleanup work in the PR. What he did is: He include()d all ui.rs files, where we (more or less by accident) always used the same function name to build the clap:App: build_ui(App) -> App. He includes these source files via a neat macro as sub modules and is then able to call all these build_ui functions to build a App object (with subcommands for each imag module). From that App object, he can retrieve the bash/fish/zsh completion (at build time). This is awesome!
• 833

Issues opened and already closed

As far as I see, we had no issues opened in the last 14 days that were also closed within theses two weeks.

Maybe in the next iteration again.

The future

Lets have a quick look what the future might bring us in the imag codebase.

Issues opened and not yet closed

• 830 was our only issue we opened in the last 14 days. It wants a rewrite of all the *.sh scripts we use to test binaries. These scripts really should be rewritten in Rust, we now have the ability to do tests in-memory, so there shouldn't be any issues with implementing these things in Rust. It is really a trivial task (not for a complete rust beginner IMO), so I'll not start implementing this soon, so others can step up.

Other things

As said above, I have a lot to do for my masters degree, so I cannot tell how much we can get done in the next two weeks. I'd love to see some progress with the email module, so we can merge this one at least, but I cannot promise it, sadly.

This does not mean I'm not interested in imag anymore. I'm interested even more in it. I just do not have enough time at the moment to do all the things I want to do.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 18th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

I released filters in v0.1.1 and task-hookrs in v0.2.1.

They are now licensed under the terms of MPL-2.0, there were no changes in functionality besides, in the filters library, one can use a filter as an Fn now, but only on nightly rust. I did not bump the version from v0.1.0 to v0.2.0 because I do not think that nightly features should be promoted. They are nice to play with, but stable rust is my target, so I do not include these things as minor versions. And, as semver specifies, we are in v0.x.y, so I can do anything I want!

New contributors

In the last 14 days I got some PRs:

• matthew-piziak submitted #797: “Simplify implementation of FoldResult and add tests”
• mario-kr submitted #810: “Single crate for all binaries”
• rnestler submitted #818: “[WIP] Use Result for from_storeid”
• Thiez submitted #820: “Add Iterator for Iterator> tracing”

Thank you all very much for your contributions!

PRs merged/closed in the last 14 days

• 759 added support for commit-on-drop, so we create one commit for all changes of one imag run.
• 775 added readline support in libimaginteraction.
• 786
• 788
• 789
• 790
• 793
• 794
• 799
• 800
• 801 starts libimagannotation, a library for annotating entries (simply a combination of libimagnotes and libimagentrylink).
• 803 one part of 802
• 804 another part of 802
• 805
• 807 and another part of 802 which rewrites the external linking part of libimagentrylink.
• 808
• 809 a hook for the store which denies deletion of entries that have still links to other entries.
• 815 a prep-PR for the upcoming release.
• 816
• 817
• 819

PRs opened in the last 14 days and not yet closed

There's not much to say about the following list of PRs, so I just list them here.

• 810
• 812
• 818
• 820

Issues opened and already closed

And there's not that much to say about this issues either... so I simply list them here.

• 787
• 811

The future

Well, the future. The release is really close. I am still not sure how to properly do the release.

As listed below, we have some discussion in #814, and TheNeikos suggested to simply run cargo publish --no-verify in a loop until all crates are up there. I do not like this idea very much, though I do not see an alternative. If you have an alternative, feel free to tell!

For readers that are not familiar with the imag codebase, here's the problem again:

• We have multiple crates in one repository.
• We have multiple root crates in one repository.

That means, we have a rather complex net of dependencies of crates in one repository. We have more than 30 crates there. A release process would need to find the one crate that does not depend on any other crate from our repository, cargo publish that one and then walk up the dependency tree until all crates are published. For this, we would either need to parse the Cargo.toml files, to find the dependencies, or just loop over all crates and try to force-publish (as in cargo publish --no-verify) them.

If you have any idea how to do this in a clean and nice (and reproducible) and automated way (I do not want to do this by hand, really), feel free to post a comment on #814!

Issues opened and not yet closed

Some issues were opened that are not yet closed.

• 791
• 792 wants ENV-var expansion from the configuration.
• 798 wants the git-mv hook for Store::move* functions
• 802 tracking issue for the libimagentrylink rewrite to return iterators instead of Vecs.
• 806
• 813
• 814 is a discussion how to do the upcoming (first) release (version 0.2.0)

That's it for today, I guess.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell.

Read what happened in the imag codebase in the last 14 days, in this 17th iteration on whats coming up in imag, the text based personal information management suite for the commandline.

imag is a personal information management suite for the commandline. Its target audience are commandline- and power-users. It does not reimplement personal information management (PIM) aspects, but re-uses existing tools and standards to be an addition to an existing workflow, so one does not have to learn a new tool before beeing productive again. Some simple PIM aspects are implemented as imag modules, though. It gives the user the power to connect data from different existing tools and add meta-information to these connections, so one can do data-mining on PIM data.

The past

I posted an article about how I organize my 0.x.y releases.

Now lets see what happened in the past 14 days.

Despite me not beeing on vacation in the last 14 days (surprise!), we didn't manage to get this much done. But at least we got some things done.

PRs merged/closed in the last 14 days

• 767
• 770
• 774 adds copyright- and license-notices at the beginning of all files.
• 772 adds tests for error-returing store hooks.

PRs opened in the last 14 days and not yet closed

• 764 adds imag-mail based on libimagmail.
• 771 implements utility functions to be used with the clap “validator functions” feature, so they can be used to verify commandline input.
• 775 adds readline support in libimaginteraction, so one can use readline to ask the user for data.
• 783 rewrites the README.md file of the repository.

Issues opened and already closed

• 769 as superceeded by 781

The future

Issues opened and not yet closed

• 765 started a discussion about whether the linking-feature should be extended for a link-annotation feature.
• 766 started a discussion about caching. Thanks you for the issue, Julian!
• 768 asks for better documentation of the linking feature. Thank you again, Julian!
• 773
• 776
• 777 asks to reduce the use of foo.fold(Ok(()),... and replace it by fold_defresult or similar helper functions we have in the codebase.
• 778 asks for a refactor of the FromStoreId trait that is defined and used in libimagdiary.
• 779 asks for a refactor of libimagentryfilter.
• 780
• 781 asks for updating all dependencies of imag.
• 782 asks for changing the libimagstore::store::Store interface to be non-consuming where possible.
• 784 asks for refactoring the libimagstore::store::EntryHeader type. This is actually a really complex issue which might be solved in several PRs rather than in one step.
• 785 asks for a imag mv feature, with some functionality like mv, but also some functionality to move store entries. Thank you again, Julian!

Other things

I finally started my masters degree this week and I guess I will have a rather high workload in this semester, so I really hope I'm able to do some imag things.

Doing the 0.2.0 release within this year (it is planned to happen before 31.12.2016) should be possible, though we will see whether the 3-month-cycle for the next releases I announced in the blog post about my release strategy will be possible.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 days vanished quickly as hell. Despite my one-week trip to the Dolomite Alps, I got a hell lot of things done.

Read it up here, in the 16th iteration on whats coming up in imag, the personal information management suite for the commandline

The past

I published a crate imag on crates.io to claim the name "imag" – it doesn't contain anything by now – I only created it to claim the name and therefor is published in version 0.0.0. As version 0.2.0 should be published within this year, this will soon change. I do not yet have any ideas how to publish a multi-crate project on crates.io, though.

(If you wonder why I jump from 0.0.0 to 0.2.0 – I already had a really early release of imag, 0.1.0, which had some minimal functionality. After that, I started a big rewrite and rewrote the complete codebase, because the initial foundations and core infrastructure was just not well done.)

We also had a small contribution from Julian Ganz, thank you very much!

PRs merged/closed in the last 14 days

Here are the closed PRs from the last 14 days. The range also includes some PRs that did not yet hit the master branch, as they are from another long-running PR which introduces some tests for libimagstore (and fixes for bugs from that library).

• 486 – finally! Git support! This PR merged the initial git hook support, so the store is now git version controlled. While this is fundamental git support (and was a rather long-running PR), more PRs will come and add additional features. The following PRs were involved in this PR:

  • 728
  • 731
  • 735
  • 736
  • 739
  • 740
  • 744
  • 745
  • 746
  • 747
  • 748
  • 752

• 729

• 730 introduced matrix builds with travis, to have faster build times.

• 734 introduced more Makefile targets, so one can execute tests via the makefile now.

• 741

• 742

• 751

• 756 introduced an option in the configuration file to disable git hooks.

• 757 reverted a feature from the initial git hook support which was broken.

• 758 fixed that git created empty commits if no change was made to the contents of the store.

• 760

• 762

• 763

PRs opened in the last 14 days and not yet closed

Some PRs from the last 14 days are not yet closed:

• 750
• 759 introduces a new feature so that the commit for a change in the store is made when the store is closed, that leads to less commit noise in the repository.
• 761

Issues opened and already closed

We did not open that much issues in the last 14 days, but anyways some are already closed:

• 733 was closed as this was a duplicate.
• 738
• 754
• 755

The future

What's coming up in the future?

Issues opened and not yet closed

Lets have a look at the issues we opened and did not close in the last 14 days, we clearly want to close them in the next 14 days:

• 732
• 737
• 753

Other things

Well... I have about two weeks left until my semester starts again, so two more weeks to get some stuff done. After that, I guess, development will slow down a bit. Hopefully not much, but enough so I can get good grades in my masters degree.

I'm almost done with the 0.2.0 milestone, so the first release for imag could happen in the next two weeks. We have 83% already done and only soft-required things left, so theoretically we could release in this very moment. Though, I'd like to at least merge the store tests before we do 0.2.0.

Also I'm really thinking about release-strategy and also how to do the release.

Strategy before 1.0.0 would be to simply git tag a commit on the master branch and declare that as release. After that I guess I will create version branches, but as a 1.* release is far away in the future, I don't think too hard about it.

The second thing is – how to release this crate on crates.io? I mean... imag is a crate with multiple root crates and also multiple crates in one repository. I already asked on reddit but I'm not sure the answers fit my problem. All these crates have one root crate which depends on all other crates in the repository. imag does not have that – in the imag repository, each imag-* directory is a root crate that depends on other crates from the repository. And the bin subdirectory also contains one.

I'm not even sure whether it is actually possible with cargo to publish this setup on crates.io.

Maybe I should ask in the cargo IRC channel on this specific subject.

tags: #linux #open source #programming #rust #software #tools #imag

Another 14 awesome days in the imag codebase

A lot has happened in this 14 days, despite I first thought it wouldn't be this much. Read up here what progress we made, implementing the PIM suite for the commandline – imag!

The past

Lets have a look at the last 14 days. As said, a lot of things happened – more than I thought could happen, actually.

PRs merged/closed in the last 14 days

Here goes a list of the merged and closed pull requests from the last 14 days, the more important ones are annotated:

• 670
• 672
• 691 was a PR on 635
• 673
• 674 disabled the debug output on travis.
• 675
• 692 adds a helper for Result types to automatically trace() errors when mapping over them.
• 693
• 694
• 695
• 696
• 706
• 707
• 708 fixed the imag-link testing code.
• 709
• 710
• 712
• 713
• 717
• 718 was a PR on 635
• 719
• 720 superceeded 719
• 721 was a PR on 486 and implemented the UpdateHook for the git hook implementation. Finally making progress there!
• 722 was a PR on 721 to refactor the hook
• 723 is a PR on 486 and fixed the hook implementation for the CI servers, so the tests run successfully now. code a bit.
• 725

The following PRs were PRs towards #667 – the rewrite of the StoreId type.

• 678
• 679
• 680
• 681
• 682
• 683
• 684
• 685
• 690

PRs opened in the last 14 days and not yet closed

Here is a list of pull requests we have opened in the last 14 days but are not yet merged.

I hope they will land soon.

• 711
• 726
• 728

Issues opened and already closed

We also have a few issues that were opened and closed within the last 14 days:

• 686
• 688
• 700 as follow-up for 667
• 702 as follow-up for 667
• 703 as follow-up for 667
• 705 as follow-up for 667
• 716

The future

And now,... what's coming up in the next 14 days.

Issues opened and not yet closed

The bunch of issues we have opened but didn't manage to close, yet. There are more than expected, actually.

• 671
• 676
• 687
• 699 as follow-up for 667
• 701 as follow-up for 667
• 704 as follow-up for 667
• 715
• 724

git hooks!

Well, well...

I'm working heavily on the git hook implementations, this is cooking for way to long now. The basics are already working, though. One can commit changes to the store with a default message which is set in the configuration file (no commandline yet, though the --override-config flag should work – at least I cannot see why it shouldn't). One can also commit via the commandline (interactive) by either using the editor or by typing on the commandline directly, though there only a single line is supported.

What I want to implement in the basic git hook support:

• When a file is created, it should be added to the repository (done)
• When a file is removed, it should be removed from the repository

What I want to implement as soon as possible:

• When a file is moved, it should be moved in the repository
• A user might want to select, what entries in the store should be committed automatically with a commit message from the configuration, and what things she wants to commit herself.
• If there is no repository in the store, it should be created automatically. If there are entries that are not yet added, but are not part of the update hook (so they are not in the repository and we are currently working on another entry) the user should at least get a warning. Even better would be if the user could decide whether the entries should be committed automatically or whether they should be left alone.

Other things

Another week of vacation.

Yes, I'm on vacation again from September 10th until September 19th (or maybe 20th). There will be no merges in this time, but you are all welcome to open PRs or issues and of course I will answer and review as soon as I'm back.

tags: #linux #open source #programming #rust #software #tools #imag

As I wrote in the last iteration on what's coming up in imag, I was on vacation from Tuesday, August 16th until Sunday, August 21th, so there was little progress in this period.

Anyways, we got some things done. Read about it here, in the 14th iteration on what's coming up in imag, the personal information management suite for the commandline.

The past

First, lets have a look at the past.

Issues with the compiler

This is actually the first time I have issues with the compiler that broke my build. The beta compiler fails due to some regression. We therefor allow travis to fail the beta compiler job.

There is already a PR for reverting this change, so we build imag on beta as soon as the beta compiler was released with the fix for this issue.

PRs merged/closed in the last 14 days

These PRs were merged or closed unmerged in the last 14 days.

• 479 – We do not need a LGPL checker in my opinion. The LICENSE file should be enough.
• 502
• 510
• 638 was reopened in 656
• 646 rewrote the Makefile.
• 648 rewrote the libimagentryfilter crate by using the filters crate – thank you, impo!
• 649
• 650
• 651 added github pages with the documentation for all crates imag depends on (of course the imag-* binaries are not documented in here, but all libimag* crates are). Finally!
• 652 allows travis to fail the CI builds with the beta compiler, as written above.
• 654
• 659
• 661 adds some documentation for the github pages.
• 665
• 666
• 669

PRs opened in the last 14 days and not yet closed

These PRs were opened in the last two weeks and are not yet closed.

• 655 reverts 652
• 656 rewrites 638
• 667 rewrites the StoreId type as reported in this blog post

Issues opened and already closed

There was only one issue which was opened in the last 14 days and is already closed:

• 647 – Rewrite the libimagentryfilter helper with the filters crate
• 668

The future

Things that come up for the next two weeks.

Issues opened and not yet closed

These issues were opened in the last period, but are not yet closed. Of course we want to close them as soon as possible.

• 653 – As described above, we ran into an issue with the beta compiler and disabled the travis checks for them. This issue is a tracking issue for reverting this patch.
• 658 asked whether to disable the debug output in travis. We agreed that we do not want the debug output anymore in travis, so this turned into a tracking issue.
• 660
• 662
• 663
• 664

Other things

I declared my goals for the rest of the year. I really want to release version 0.2.0 of imag within this year, but some thing have to be done beforehand:

1. Fix the StoreId problem
2. Implement the git hooks (which requires the fix for the StoreId)
3. Fix imag-notes edit which seems to be broken
4. (optionally) Have a minimal working mail module
5. (optionally) Cleanup imag-diary/libimagdiary a bit

Some more required (hard or soft) and optional things can be found in the milestone for this release I created.

tags: #linux #open source #programming #rust #software #tools #imag