FOSDEM Report - Saturday

[Jeroen van Meeuwen]

Greg Banks wrote:
> On Wed, Feb 8, 2012, at 05:32 PM, Jeroen van Meeuwen (Kolab Systems) wrote:
> > On 2012-02-08 5:08, Greg Banks wrote:
> > > On Tue, Feb 7, 2012, at 02:27 PM, Bron Gondwana wrote:
> > >> - Gerrit?  Some sort of code review process to make it easier to
> > >> keep
> > >> 
> > >>   track of the work from drive-by contributers.
> > > 
> > > I see two benefits to Gerrit or something like it
> > > 
> > > a) casual contributions don't get lost in the noise
> > > 
> > > b) regular contributors get regular code reviews
> > 
> > There's a couple more;
> > 
> > - Jenkins can be put in charge of giving the first thumbs-up for the
> > commit(-series) but letting a build using the commit(s) succeed,
> > possibly along with Cassandane executing successful tests.
> 
> I went to a talk about the OpenStack development process at LCA.  They use
> both Gerrit and Jenkins but put Gerrit first in the pipeline so that all
> patches get a human review in Gerrit before they undergo integration
> testing in Jenkins.  It seems that the other order is equivalent to
> allowing random unknown people to execute unreviewed code on your CI
> machine, in an environment which may have write access to the git repo,
> which is something of a security problem.
>

Now, well, one can perfectly well limit who has access to commit to what is 
then Gerrit.

Additionally, I can make sure security layers are in place that make even the 
most evil code be contained to within pre-defined boundaries, so even allowing 
anonymous access would not be of all that great concern to me; that is to say, 
it would *vastly* increase the (rather advanced) workload needed on the 
sysadmin side of things, so we're not going to do that ;-)

> > >> - Bugzilla - use it for everything.  If it doesn't have a bug
> > >> number
> > >> where discussion took place, it doesn't get accepted.
> > 
> > It's a transparency thing, as well as a planning thing. Then
> > afterwards, its a reporting thing.
> 
> Sure.  Sometimes though transparency is not good, e.g. when dealing with a
> reported but not yet fixed vulnerability.  Those exceptions need to be
> handled gracefully and in a defined manner.  This might be "create a bug
> number with full details after the software release", or "have a magic
> Security flag on the ticket which restricts its visibility" or "have a
> separate Bugzilla instance".

You're right in that CVEs in Bugzilla should not be as transparent, but this 
is an existing feature in Bugzilla.

> > > Another thing I'd like to see is a push hook on git.cyrusimap.org's
> > > master and 2.4 branches, so that if a git commit has the text "Bug
> > > NNNN" in the subject then the commit message is copied to Bugzilla
> > > and
> > > the bug marked RESOLVED - FIXED.
> > 
> > What this does is create properly hard dependencies between GIT
> > branches and Bugzilla versions/milestones.
> 
> Yes.
> 
> > This isn't a bad thing, but
> > we are currently winging it between the two. It means every time a thing
> > happens on the one, the thing needs to happen on the other as well, and
> > properly so that the match between the two things can be made by such
> > program.
> 
> Yes.
> 
> I think the important thing is trackability from a user point of view. 
> Let's say I'm a Cyrus sysadmin who has discovered a bug in their
> installation, which is described in a Bugzilla ticket and already fixed in
> some newer release.  The key things I want to know are:
> 
>  - is there a fix?
> 
>  - if so, is that fix in a release yet?
> 
>  - if so, which release(s) is it?
> 
>  - if not, where can I get a patch that I can apply to my install?
> 

- and/or, for the last point, where/how can I request the patch be made 
available for a current release series (i.e. 2.4.$z)

> Having that information right there in the Bugzilla entry, and guaranteed by
> automation to be present and correct, would a signficant win.  I've worked
> in an environment where the BTS and VCS did this dance, and it made the
> support job *much* easier.

True, I can certainly see your point. I'm just saying, that while we don't 
have it, and may work towards such a thing, things are in flux to the point of 
actually needing to put all of this on the plate of a proverbial one throat to 
choke. That'd be me.

> > > I wonder if DIstZilla or something like it could be used to automate
> > > the release process?
> > 
> > I'm gonna go out on a limb and say "Not Your Problem(TM)" - it's why
> > non-coders like me exist and can have some value to the project ;-)
> 
> Sweet!  It's not like I have insufficient problems.
> 

;-)

The general idea is, you (the actual developers) just Throw It Over The 
Fence(TM) as quickly as you can and Forget About It(TM).

> > >> Special-Use:
> > >> 
> > >> (...snip...)
> > > 
> > > Yes, our RFC compliance is basic here.
> > 
> > Technically, it's been outlined what Kolab Systems is seeking to do
> > here, and as it is not so much on the roadmap for other parties
> > involved, we're therefore seeking ways to allow us to also actually do
> > the work (instead of asking other parties to do the work for us).
> > 
> > I'm looking forward to it, as currently I may have seemed to ill- /
> > ambiguously define what it is we're trying to do exactly.
> 
> Would that be http://wiki.kolab.org/KEP:9 ?
> 
> I really need to read and comment on that...
> 

Nope, this is not the KEP in question. This configuration storage KEP has to 
do more with application settings one would seek to share between 
applications, such as "Identities".

What we're specifically looking for, paraphrasing a 30.000 ft high-level birds 
view, is xCal and xCard stored in IMAP folders that are also made available 
through CalDAV / CardDAV, where such folders are annotated through SPECIAL-
USE, so that any IMAP client is automatically compatible. SPECIAL-USE already 
requires "ENABLE SPECIAL-USE" by the client, and the server can therefore (to 
a client not enabling SPECIAL-USE) just hide the \Calendar and/or \Contacts 
folders. Such-and-such requires an extension to the current SPECIAL-USE RFC 
though, as currently it only ever involves messages, does not set any 
standards regarding the format of folder's contents (as it only involves 
mail). There need to be some clarifications on what is a private "annotation" 
within SPECIAL-USE, and what could arguably be a shared annotation, all of 
which justify an extension / replacement of the current RFC to be drafted.

Georg Greve and myself have agreed Georg is going to put something under my 
nose for review.

> > >> * Undo.
> > > 
> > > Wait, what!?
> > 
> > I think this comes from the realm of the anti-"Are you sure?" movement.
> > Asking whether or not a user is sure the user wants to perform an action
> > the user performed is absolutely intrusive to one's productivity, and
> > simply annoying. Instead of asking for confirmation, it is argued, with
> > which I agree, one should offer undo to recover from mistakes.
> 
> Ah I see.  I agree entirely about the uselessness of 'Are you sure?', but I
> think we should have a weak and specific form of Undo, which provides for
> ways to undo only those operations which would otherwise lose data, and
> only for a limited period of time.  For example, deleting a message or
> deleting a folder should have an equivalent Undo operation, but setting the
> \Flagged flag should not.

And that is the general idea, I think; The infrastructure (Cyrus IMAP server) 
should allow for the client to deploy an "undo" mechanism, rather then each 
client trying to do so themselves. A reference example could be "Delete 
folder" - currently there's absolutely no way for the user to completely 
autonomously recover from that (whereas flagging as \Deleted does have a 
reverse path available to the user). There's more though, with EXPUNGE second 
on the list of things that are happening accidentally sometimes.

> And, the Undo operation could be as simple as
> 'go to this special folder and find the message you just deleted', as we
> effectively have now.  I think all we need is a carefully defined way for
> the client to know where to find those things, and not some kind of
> complicated general snapshot or transaction feature in the server.

I think the framework around "Undo" might be similar path for the server to be 
able to provide itself a recovery path for failed transactions, yet 
differently in that instead of it being a solely server-side process, it can 
be user-initiated, no?

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20120209/1b271b1d/attachment-0001.html