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

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