Page MenuHomekolab.org

How would you like to work with KDE PIM Source Code Management Repositories?
Closed, WontfixPublic1 Story Points

Description

Please see the parent T1 for a description of the problem space.

Two separate considerations;

  • With cloning the KDE PIM repositories from their original locations over to our environment, pushes are not possible.

    Without cloning the KDE PIM repositories from their original locations over to our environment, the branching policy is arbitrary and our copy would be incomplete (this is what we currently do).
  • Some repositories upstream seem to also use Phabricator, which would void auto-closing on branches that are upstream (i.e. a commit message with "Closes T4" cannot close T4).

Details

Ticket Type
Task

Event Timeline

vanmeeuwen updated the task description. (Show Details)
vanmeeuwen raised the priority of this task from to 60.
vanmeeuwen added a project: KDE PIM.
vanmeeuwen added a subscriber: vanmeeuwen.

I would like to hear what the desktop people have of comments for that.

At least for the moment I'd like to avoid cloning (which seems to imply that we have a read-only mirror of the relevant repository). We currently rely on our own copy for development branches, although we may be able to move that upstream if the branching policies are adjusted upstream.
To me the separate repositories don't complicate work, so that works well enough for me.

KDE is evaluating phabricator and we i.e. have test projects for akonadi-next and zanshin. I assume that most of the planning will happen there, so I will only be using our own phabricator instance for the stuff relevant to us (sprint planning etc).

With regards to auto-closing it would be interesting if we can modify the hooks to i.e. use KOLAB: T4 and KDE: T5, to interact with both phabricator instances (if that's possible I'd ask the KDE sysadmins what they think about it). Otherwise we indeed have to disable auto-closing.

In T2#145, @mollekopf wrote:

At least for the moment I'd like to avoid cloning (which seems to imply that we have a read-only mirror of the relevant repository). We currently rely on our own copy for development branches, although we may be able to move that upstream if the branching policies are adjusted upstream.
To me the separate repositories don't complicate work, so that works well enough for me.

We should consider work against a third-party upstream goes to if not through that third-party upstream, and attempt to figure out upstream how we can collaborate with them, rather than maintain a fork of a git repository (w/ or w/o special branches of our own).

After all, upstream should have a level of interest in our participation -- however low, and we should have a level of interest in providing our work upstream -- however biased wrt. priorities.

Noted this is the ideal scenario, and we'll likely end up with a less than ideal scenario in real life, we are establishing an exceptional situation hopefully for the time being.

However, our work downstream is structured with Scrum Sprints, and it is in that light we need to view how this work downstream aligns with work happening upstream (largely uncontrolled).

I would favor a scenario in which the KDE PIM upstream repositories are mirrored completely, and the branches we push to have a canonical naming convention -- we would block pushes to branches with names not approved prior to the fact (using Herald).

KDE is evaluating phabricator and we i.e. have test projects for akonadi-next and zanshin. I assume that most of the planning will happen there, so I will only be using our own phabricator instance for the stuff relevant to us (sprint planning etc).

Does the KDE instance of Phabricator also employ the Sprint extension from WikiMedia?

How do we envision mapping any planning occurring upstream to required planning downstream?

With regards to auto-closing it would be interesting if we can modify the hooks to i.e. use KOLAB: T4 and KDE: T5, to interact with both phabricator instances (if that's possible I'd ask the KDE sysadmins what they think about it). Otherwise we indeed have to disable auto-closing.

This is technically not possible with the current state of Phabricator, other than on a global level (applicable to all GIT repositories alike).

In T2#148, @vanmeeuwen wrote:
In T2#145, @mollekopf wrote:

At least for the moment I'd like to avoid cloning (which seems to imply that we have a read-only mirror of the relevant repository). We currently rely on our own copy for development branches, although we may be able to move that upstream if the branching policies are adjusted upstream.
To me the separate repositories don't complicate work, so that works well enough for me.

We should consider work against a third-party upstream goes to if not through that third-party upstream, and attempt to figure out upstream how we can collaborate with them, rather than maintain a fork of a git repository (w/ or w/o special branches of our own).

After all, upstream should have a level of interest in our participation -- however low, and we should have a level of interest in providing our work upstream -- however biased wrt. priorities.

Noted this is the ideal scenario, and we'll likely end up with a less than ideal scenario in real life, we are establishing an exceptional situation hopefully for the time being.

However, our work downstream is structured with Scrum Sprints, and it is in that light we need to view how this work downstream aligns with work happening upstream (largely uncontrolled).

I would favor a scenario in which the KDE PIM upstream repositories are mirrored completely, and the branches we push to have a canonical naming convention -- we would block pushes to branches with names not approved prior to the fact (using Herald).

Sounds good to me. Eventually we should be able to change upstream branching policies as well so we can do even more upstream.

KDE is evaluating phabricator and we i.e. have test projects for akonadi-next and zanshin. I assume that most of the planning will happen there, so I will only be using our own phabricator instance for the stuff relevant to us (sprint planning etc).

Does the KDE instance of Phabricator also employ the Sprint extension from WikiMedia?

It's installed, yes.

How do we envision mapping any planning occurring upstream to required planning downstream?

Ideally we'd do pretty much all planning upstream IMO, which results in a lot of duplication for our infrastructure unfortunately (for everything that we want to track in our instance). I don't know how we can solve this without either shutting the community out (by doing stuff in our own instance), or not being able to track stuff in our instance by doing sprints on the kde instance. While we could of course invite the community to do kde stuff in our phabricator instance, I don't think that's what should be happening.

Eventually we may want to think about unifying the kde and kolab phabricator instances, although I guess that's not an overly realistic scenario.

So, I think all the milestone planning etc. should as far as possible happen upstream, and we want to minimize what we have to duplicate in our instance.

With regards to auto-closing it would be interesting if we can modify the hooks to i.e. use KOLAB: T4 and KDE: T5, to interact with both phabricator instances (if that's possible I'd ask the KDE sysadmins what they think about it). Otherwise we indeed have to disable auto-closing.

This is technically not possible with the current state of Phabricator, other than on a global level (applicable to all GIT repositories alike).

Ok. That one goes on a wishlist then I guess, we can live without it for now.

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

vanmeeuwen set Ticket Type to Task.Apr 17 2015, 5:48 PM
vanmeeuwen edited a custom field.

See also T14, in which a general agreement is reached of how the process level coordination might take place.

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:13 AM
machniak closed this task as Wontfix.
machniak claimed this task.
machniak added a subscriber: machniak.

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