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

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

Correcting the priority from 60/40 to Normal

This is resolved by new policy settings.

I would like to consider T47 to examplify the following remarks:

Document created and accepted

First iteration

https://git.kolab.org/w/sprint-plannings%2C_backlog-grooming_and_sprint-retrospectives/

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.

Not yet resolved!

python-flask is now included in Kolab:Development and Kolab:14 for Enterprise Linux 7.

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.

I won't be able to complete this in time for the end of this sprint.

As far as the umbrella is concerned, this is completed.

That's just GIT though...

It's easier to yum-builddep for all packages in Kolab:Development, such as in /diffusion/DO/browse/master/ci/maipo;132d7fd03a48de867bf611cade38bed568ea91f9$16.

I modified the rules to also include rDO (Docker) in the Deployment of Continuous Integration, so that we do not have to orchestrate pushing and pulling images that amount to ~1.5GB

According to T2: "

@mollekopf has agreed, so this is done.

In T9#171, @vanmeeuwen wrote:

Herald rules H2, H3, H4, H5, H6, H7, H8 and H9 now collaborate to have commits to all repositories, with the exception of the rD repository and the upstream branches on repositories that are associated with KDE PIM, run through Stick for the purpose of Quality Assurance.

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.