Page MenuHomePhorge

Downstream Kolab and Upstream KDE Coordination?
Closed, WontfixPublic1 Story Points



I first assign this task to you to coordinate finding insights; We'll want to figure out how downstream (Kolab) can work with upstream (KDE).

Suggestions include;

  • Moving all work, structure and management upstream -- possibly mutually exclusive with us structuring and managing a process downstream, and possibly under different leadership / accountability.
  • Keeping all work, structure and management for Kolab downstream, while also working on KDE upstream (despite whatever upstream structure and/or management or lack thereof).
  • Modify Phabricator and/or create a Phabricator extension to allow a level of integration with an upstream project's instance (such as a project "upstream" much like today we employ "sprint").


  • Some upstream projects are evaluating Phabricator. Phabricator instances cannot currently be linked.
  • While the upstream Phabricator instance apparently employs the WikiMedia Sprint extension, we may or may not have access to or control over the process, and/or whether scrum/sprints are being used for each individual software development process upstream.
  • Other upstream projects use Bugzilla. Phabricator does not integrate with Bugzilla.
  • ... probably some other considerations I cannot think of right now.


Ticket Type

Event Timeline

vanmeeuwen assigned this task to petersen.
vanmeeuwen raised the priority of this task from to 60.
vanmeeuwen updated the task description. (Show Details)
vanmeeuwen changed Ticket Type from Task to Task.
vanmeeuwen added subscribers: mollekopf, petersen, vanmeeuwen.

According to T2: "

We have agreed to create locally hosted GIT repositories that are, in principal, complete mirrors of upstream's GIT repositories.

Kolab specific work shall take place on separate branches (as it does today)."

We need to make phabricator work with upstream instances, but we will get back to that at a later time.

A hypothetical example; We should attempt to understand what happens when KDE upstream says in January, their next milestone's deadline is in December, and we have deadlines of May, July, August and/or October -- anything before December really.

The following policy will be valid for such situations (as just discussed on the phone):

  • Developers will open tickets in upstream system, and commit new code to upstream master branch.

Example: KDE enhancement.

  • Task opened in Kolab Phabricator as placeholder for work effort, and link the Task to a Task in the KDE phabricator.
    • The Kolab Phabricator task will be tracking work effort and status in the sprint work board
    • The KDE Phabricator will be tracking the code and changes to it.

This way we offer our developed changes upstream, we avoid working in old code (having to merge and push upstream in bundles) and we push developers to work in new code.

A special forked branch can be created for special customer needs in the Kolab infrastructure, but that will be against payment. THis will clarify the cost of "unwanted" change to sales, and make it easier for them to relay that cost to customers.

Please comment.

In T14#482, @petersen wrote:

The following policy will be valid for such situations (as just discussed on the phone):

  • Developers will open tickets in upstream system, and commit new code to upstream master branch.

Yes, all work will ultimately need to take place on or be merged with upstream's master branch(es) regardless. Setting this as the default target right-out from the start as a matter of principle and policy seems natural.

Any consumer discomfort with upstream's timeline for releasing something based on the work put in to said master branch(es) can be mitigated at extra cost, as it incurs extra cost on our end.

This will establish our running in circles forking off products in to downstream branches on which development then takes place, as the exemption to the rule, the exception to the policy, and will allow us to wonder about the incurred cost in extra effort, and the offsetting of that in revenue / strategic advantage / (...).

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:13 AM
machniak subscribed.

Kolab support for KDE PIM is discontinued. Create a ticket on