FOSDEM Report - Saturday

[Greg Banks]

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:
> > Have they announced the URL for the videos?
> >
> 
> I think the links are on every talk page on the FOSDEM schedule on 
> fosdem.org.

Neat.

> >> - 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.

> - New contributors can be trusted to commit to what goes through 
> Gerrit, lowering the entry barrier. Suppose Kolab Systems, for example, 
> were to find a C programmer with some C experience, that person will 
> obviously need quite some time to catch up with everything that happens 
> within Cyrus IMAP. One can imagine how automating (a large part of) as 
> well as requiring such a person's contributions be reviewed serves both 
> parties quite well.

Agree entirely.

> >> - 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".

> > 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?

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.

> > 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.

> >> 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...

> >> * 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, 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.

-- 
Greg.