Decided then!

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

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.

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.

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.

That's just GIT though...

According to T2: "

@mollekopf has agreed, so this is done.

See H4.

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

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

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.

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.

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