Page MenuHomePhorge
Create Task
Maniphest T1

Process to collaborate on external, third-party projects.
Open, NormalPublic
Actions

Description

The Kolab development team works with a variety of external, third-party software development projects, each with their own set of semantics;

  • KDE PIM uses Phabricator itself for a number of applications in their suite, meaning that any copy of the GIT repository cannot be enabled "auto-close" for on all branches.

    This project is different in that we employ a forked clone of the repositories in which we branch off to store our work.
  • Cyrus IMAP uses Phabricator itself.

    This particular involvement is different, in that we employ no forking to work on our interests.
  • Phabricator itself might receive some work, or otherwise the Sprint extension we employ.

    These particular projects are different in that the timeline to deployment for us is not necessarily in line with the timeline to acceptance upstream.

Related Objects
Search...

Event Timeline

vanmeeuwen created this task.Apr 13 2015, 5:28 PM
vanmeeuwen raised the priority of this task from to 60.
vanmeeuwen updated the task description. (Show Details)
vanmeeuwen added a project: Process Managers.
vanmeeuwen subscribed.
vanmeeuwen added a project: Engineering & Operations.Apr 13 2015, 5:49 PM
vanmeeuwen mentioned this in T2: How would you like to work with KDE PIM Source Code Management Repositories?.Apr 13 2015, 6:09 PM
petersen subscribed.Apr 13 2015, 7:02 PM

I could imagine that we would like to make a special "external" or "3rd party" project to associate with these kinds of issues. Whether there should be a git repository connected to this project is to be decided

vanmeeuwen added a comment.Apr 13 2015, 7:09 PM

The classification of "External" or "3rd party" is unrelated to the technical semantics of a git repo (if any) and auto-closing (if git repository).

So far it's clear that KDE PIM needs a GIT repository, and we might one for Phabricator or the Sprint extension we're employing.

Cyrus IMAP does not require a local git repository, albeit should we start actual C development effort it might still be usefull (effectively putting it back in to the same problem space as KDE PIM / Phabricator).

vanmeeuwen mentioned this in T3: How would you like to work with Cyrus IMAP Source Code Management repositories and Process Tooling?.Apr 13 2015, 7:35 PM
vanmeeuwen moved this task from Backlog to In Progress on the Engineering & Operations board.Apr 14 2015, 12:20 AM
vanmeeuwen added a subtask: T3: How would you like to work with Cyrus IMAP Source Code Management repositories and Process Tooling?.Apr 14 2015, 12:02 PM
vanmeeuwen added a subtask: T14: Downstream Kolab and Upstream KDE Coordination?.Apr 20 2015, 2:59 AM
vandenoever mentioned this in Unknown Object (Diffusion Commit).Jul 11 2016, 2:25 PM
pasik subscribed.Nov 25 2017, 2:40 PM
• apa0520pa mentioned this in T4094: Customized Industrial Assembly Line.Jun 8 2018, 11:22 AM
vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:13 AM
machniak closed subtask T14: Downstream Kolab and Upstream KDE Coordination? as Wontfix.Jul 16 2019, 11:43 AM
machniak closed subtask T2: How would you like to work with KDE PIM Source Code Management Repositories? as Wontfix.