OpenPaaS Newsletter 10 - December 2017


Here comes a letter not to Santa but to you, dear reader: the December newsletter. As we all long for the presents under the Christmas tree we decorated together with our loved ones, as we wait for the sleigh bells to ring in our ears, sipping eggnog and cooking gingerbread men, comes an early present we hold dear: The OpenPaaS 1.0 upcoming release!
In this letter, we will tell you how we handled and addressed this very important step in a product life. We will especially talk about our special polishing phase and will explain the releasing process we engaged in. :)
But first, let’s share with you the James, Inbox and LinShare achievements.


During the past few weeks, Inbox and James teams were on fire, working hand in hand to make new features available in the OpenPaaS 1.0 release.

Folder Sharing

The folder sharing capabilities were implemented: the users can now share one or several of their folders with any other user in their organization. They define easily how their colleague(s) will be allowed to interact with the folder: either in read-only mode (consult messages) or with more permissions (add, delete or move messages to another folder). This is especially useful to delegate the management of a specific folder to someone else
In order to reach this goal, the James team implemented JMAP sharing on while the Inbox team provided a user-friendly interface: the user receiving a new shared folder immediately sees it appearing with a nice slide-in effect as shown in the video below:

Drafts

The draft messages feature, that was already implemented in Inbox, has been implemented by the James team in recent weeks. The email you compose can now be saved in Inbox, reopened and re-edited. From James side, moving messages to the Outbox using the JMAP protocol will actually trigger the sending. Below, you can see what happens on Inbox side:

When Cyril Leroy closes his message editor,
his email is now saved in his “Drafts” folder!

“Polish” Sprint

After implementing these features, the two teams were also involved in the “polish” sprint (see the relative part below), to fix some little but annoying issues.

What is coming next?

In the coming weeks, the teams will be focused on delivering a highly reliable software. James team will move toward latest states of the JMAP specifications and implement JMAP instant notifications (push), make James more distributed, and improve distributed safety.


Here, at LinShare, we want to share with you the news of our awesome team: LinShare SaaS team. Yes, you read it correctly LinShare SaaS team :)

In fact, we were two separated teams: LinShare and SaaS. Both teams were working on the same product with the same technology stack so we decided to merge them. For naming, it was so easy, we decided to concatenate teams’ names. One sentence can describe our team: Together… we are stronger.

The first good news that we want to share with you is the fact that our team is getting bigger. Four awesome developers have joined us recently: Yousra, Yazid, Marwan and Mehdi. And you, what are you waiting for? You can simply join us by clicking here.

Second good news: we are happy to announce the beta version of our SaaS portal is now online at linagora.io. By subscribing, you can store your files in the cloud and share them with your friends.

linagora.io!

Speaking about LinShare, we are currently working on the new version, 2.1, that should be released by 2018. This release tunes the performance of the current version of LinShare, add new features along with killing some small bugs. The new release should allow users to manage their quota and their workgroups more efficiently. Before we tell you more, you can have a little overview here:

New email notifications

Preparing OpenPaaS Upcoming Release

In a few weeks, our beloved OpenPaaS will be released! :) 
The two steps to address are the bugs hunting & Fixing and the release process.

Our “polish” Sprint

We spent 3 weeks at the end of November and beginning of December to hunt the bugs and fix them. During this time, all the OpenPaaS teammates were mobilized to review and test all the features of OpenPaaS. Each team has been split into two sub-teams: one team to test other modules and one team to fix bugs reported by other teams.

What was the result?

  • We needed to correct 161 bugs
  • today, at the end of December: 138 are fixed and the remaining 15% will be addressed very soon.

Our Release process

After “polishing” time… Comes “publishing” time! We can’t wait to have our product shipped in its first version ever (a.k.a v1.0.0), but also want to do things right.

In order to streamline the installation & future upgrade process for our customers, we aim to have state-of-the-art publishing process, allowing us to ship easily and painlessly.

Having multiple teams working on different parts of the product is a challenge regarding product releases, as we need everyone to be on the same page. We quickly identified the need to have a single automated process, to avoid the (otherwise unavoidable) human error risk. That way, we would be able to request all teams to have their module ready-for-launch at a given date, and have only one person easily triggering the full publishing job.

Hopefully, we already had all the tools at our disposal to build this in a timely manner; we mainly relied on our brand new Gitlab CI to do the job(s).

To summarize what was built:

  • 1- A single Gitlab CI job acts as the conductor, triggering one job per OpenPaas module (that’s about 15 jobs right now!);
    Each of these automated jobs is responsible for branching and tagging their module’s repository before automatically publishing it to npmjs.
  • 2- Once all jobs are done and modules are all published, our conductor job finally branches and tags the core repository of OpenPaas, setting the new version for all modules in configuration files.
  • 3- Once all this is done, the only remaining operation is to trigger another job, which will be responsible for generating and publishing .deb and .rpm packages to our repository.

That way, we ensure that a given version of OpenPaas will always get the same version of all its modules.
As you can see, we are now ready to ship regularly, providing you easy upgrade to bug-free and full-of-feature versions of our beloved product!

Let’s build!

As a Conclusion

As you could discover in this newsletter our whole team is focused on delivering a highly reliable software. Fixing the bugs and automating our release process were the 2 topics of these last weeks. The 1.0 release is ready and will be published in the following days, so do not hesitate to test it by going on http://open-paas.org/ and follow the steps of the “Try It” section. Merry Christmas!