Hi there,
I have a test installation of Phabricator with Cyrus IMAP and SASL
projects and GIT repositories imported, and so it is time to start
stabbing at what tooling and work-flows would look like if we were to
roll with this tooling.
At the moment, I have created various user accounts for people (Bron,
Ken, Robert, Matt) to get some key positions filled, and partly because
of that I've suspended email delivery for this system (otherwise the
placeholder accounts on these key posititions would have gotten spammed
over the course of this weekend).
This means that everyone needs to contact me -- I require a full name
and email address for an account, preferably over IRC (kanarip on
FreeNode, I'm in the #cyrus channel in case you can't find me).
I'd love to get some more hands on the system and see how hard we can
poke at it before we decide whether or not to actually run with it in
full force, or ditch it altogether / explore other tooling, but from
what I'm seeing I'm liking what we have.
Big fat note: if you're willing to entertain a self-signed cert,
substitute the scheme for the URLs below with https; SHA-256 fingerprint
is:
34:C6:3D:65:17:E9:61:C7:FA:9E:3E:4F:46:A7:16:CE:81:AD:03:34:1A:C1:F0:64:15:86:2E:1E:3D:17:BA:CE
That said, don't expect "Arcanist" to work (the cert ain't trusted, see
T4, T5, T6 and T7), and therefore just in general -- don't use any sort
of valuable information anywhere near this system.
For now, this installation needs to be understood as demonstrative, such
that;
- We've figured out how to get a project (IMAP, SASL, Documentation,
System Engineering) going without;
1) Closing off joining such project only to those who have commit
access, yet
2) Provide direct commit access to only those who are "blessed"
developers, and
3) Yet allow "the general public" to propose changes under an
established process, without
4) involuntarily cluttering up the kanboards of "blessed"
developers, in that
5) those that are "blessed" developers can voluntarily join the
group of "reviewers" to assert themselves in to the loop for proposed
changes from "the general public".
all of which I think is pretty fruitful for a weekend.
- T4 (at http://95.128.36.13/T4)
Illustrates how a task squarly on Bron's plate might block other
tasks on my plate (T5), which in turn may block other (yet unassigned)
tasks (T6, T7).
- T11 (at http://95.128.36.13/T11)
is not actually a goal, albeit it may become one at some point, but
illustrates how a kanboard Task item can depend on proposed changes
(that contain code to backup the proposed changes) that are subject to
review by "blessed" developers (who's opted in to review of
contributions from the "general public", which to them then also become
kanboard items).
- Wiki pages like http://95.128.36.13/w/arcanist_workflow/ (which is
not to say these do not need any further work),
- Herald (the pre- and post-commit rule engine) can trigger an Audit^1
of certain changes, where an "Audit" needs to be understood as a
non-blocking "Review", whereas a "Review" normally is "blocking".
There's much more I can't really go in to right now -- my family needs
feeding too -- so I hope you pop in to #cyrus and start asking
questions.
Kind regards,
Jeroen van Meeuwen
^1: For example, changes to lib/imapoptions in cyrus-imapd.git need an
"Audit" from the Documentation team -- not because they want to be
saying yay or nay, but because documentation may require updating.
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: https://kolabsystems.com
pgp: 9342 BF08
