Test installation of Phabricator

[Jeroen van Meeuwen (Kolab Systems)]

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