From 2945877a9f6062e6a2c5aaf2e6a1fe9c545a6869 Mon Sep 17 00:00:00 2001 From: Christian Mollekopf Date: Fri, 30 Jun 2017 15:34:54 +0200 Subject: A single shared testdata set. --- .../openpgp-signed-base64-mailman-footer.mbox.html | 81 ++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 framework/src/domain/mime/testdata/details/openpgp-signed-base64-mailman-footer.mbox.html (limited to 'framework/src/domain/mime/testdata/details/openpgp-signed-base64-mailman-footer.mbox.html') diff --git a/framework/src/domain/mime/testdata/details/openpgp-signed-base64-mailman-footer.mbox.html b/framework/src/domain/mime/testdata/details/openpgp-signed-base64-mailman-footer.mbox.html new file mode 100644 index 00000000..c10cecd8 --- /dev/null +++ b/framework/src/domain/mime/testdata/details/openpgp-signed-base64-mailman-footer.mbox.html @@ -0,0 +1,81 @@ + + + + +

+ +

+ + + + + + + + + + +

+ + + + + + + +

Message was signed on 8/22/15 9:31 AM with unknown key 0x7F96CCD64D12D247. The validity of the signature cannot be verified. Status:No public key to verify the signature	+ Hide Details +
	+

I've talked to Ben, the current Phabricator test setup would actually be

usable for "production" use for task/project management for us, without

causing the sysadmins unreasonable trouble when migrating to the full

production deployment of Phabricator eventually.

Phabricator project layout it orthogonal to repo layout, so we can structure

this however we want. Among other teams I see at least the following layouts:

- single project for everything

- a project per release

- a project per component/module (ie. close to the repo layout)

How do we want to structure this?

I would start with a single project to not fragment this too much, as we have

a relatively small team actually looking into this, so everyone is looking at

most sub-projects anyway. And should we eventually hit scaling limits, we can

always expand this I think.

We of course should also talk about what we actually want to put in there. My

current motivation is having a place to collect the tasks for getting more of

the former pimlibs into KF5, and anything else I run into on the way there

that we eventually should clean up/improve.

End of signed message

_______________________________________________

KDE PIM mailing list kde-pim@kde.org

+

+ https://mail.kde.org/mailman/listinfo/kde-pim +

+

KDE PIM home page at http://pim.kde.org/

+

+

+

+

+ + -- cgit v1.2.3