Page MenuHomePhorge
Create Task
Maniphest T14

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

Description

@petersen,

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").

Parameters;

  • 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.

Details

Ticket Type
Task

Related Objects
Search...

Event Timeline

vanmeeuwen created this task.Apr 14 2015, 3:15 PM
vanmeeuwen assigned this task to petersen.
vanmeeuwen raised the priority of this task from to 60.
vanmeeuwen updated the task description. (Show Details)
vanmeeuwen added projects: Sprint Process 201516, KDE PIM.
vanmeeuwen changed Ticket Type from Task to Task.
vanmeeuwen added subscribers: mollekopf, petersen, vanmeeuwen.
petersen added a comment.Apr 17 2015, 4:43 PM

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.

vanmeeuwen added a comment.Apr 17 2015, 5:49 PM

That's just GIT though...

vanmeeuwen added a comment.Apr 18 2015, 3:14 PM

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.

vanmeeuwen added a parent task: T1: Process to collaborate on external, third-party projects..Apr 20 2015, 2:59 AM
petersen added a comment.Apr 20 2015, 2:56 PM

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.

petersen moved this task from Backlog to Review on the Sprint Process 201516 board.Apr 20 2015, 2:58 PM
vanmeeuwen edited a custom field.Apr 20 2015, 3:14 PM
vanmeeuwen added a comment.Apr 20 2015, 3:22 PM
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 mentioned this in T2: How would you like to work with KDE PIM Source Code Management Repositories?.Apr 20 2015, 3:31 PM
petersen moved this task from Review to Done on the Sprint Process 201516 board.Apr 20 2015, 8:24 PM

Decided then!

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:13 AM
machniak closed this task as Wontfix.Jul 16 2019, 11:43 AM
machniak subscribed.

Kolab support for KDE PIM is discontinued. Create a ticket on https://bugs.kde.org