FOSDEM Report - Saturday

Wed Feb 8 11:32:25 EST 2012

On 2012-02-08 5:08, Greg Banks wrote:
> Sounds like you're having fun at FOSDEM :)
>

Yes.

> On Tue, Feb 7, 2012, at 02:27 PM, Bron Gondwana wrote:
>> http://fosdem.org/2012/schedule/event/keynotes_welcome
>> [...]
>> There are 420 talks, 273 hours of scheduled content.  You can't see 
>> it
>> all!  As much as possible will be videoed.
>
> Have they announced the URL for the videos?
>

I think the links are on every talk page on the FOSDEM schedule on 
fosdem.org.

>> Saturday 11:00 -> 2:20 - "Mail Track"
>> =====================================
>> [...]
>> Cyrus process:
>>
>> - 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.

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

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

>> This is a major
>> workflow change, and is probably more of a challenge for me than 
>> anyone else.
>
> Sounds good.
>
> 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. 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.

>> - Websites in git.
>
> Yes!
>
>> - Release process - simplify to save the repeated typing involved.  
>> I
>> wind up writing the changelog, the website release note and the 
>> email release
>> note, plus manually changing a bunch of things in the website PHP 
>> every time
>> I do a release.
>
> 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 ;-)

I'm strongly in favor of you just throwing things over the fence while 
we have not yet found a working solution in order for me to delegate 
creating releases in a way that makes everything happen properly in a 
variety of places.

It allows you to focus on development (on master, and other development 
branches), and of course I'll be able to follow up with any of the 
developers if I get stuck backporting things or zapping bugs.

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

>> E-Discovery, deletion controls:
>>
>> - Kolab are planning to use the "msg bus" stuff from Worldline to 
>> have a
>>   listener that collects data for e-discovery.  Kind of a "cyrus
>>   watcher".
>
> I'd love to have a more generic infrastructure for listening to
> changes in, and interacting with, the cyrus data model, on top of
> which we could implement the Annotator daemon, mupdate, and NOTIFY.
>

We have a quite large but also long-standing agenda item that is in the 
realm of e-Discovery (legal shit about what the f happened), Archiving, 
Accounting and the more assisting sysadmins side of discovery (log 
aggregation and such to track mail flow), to name a few.

>> ActiveSync:
>>
>> - MetaWays have a very good open-source ActiveSync stack:
>>   
>> http://www.h-online.com/open/news/item/Tine-2-0-supports-ActiveSync-740315.html
>
> That seems to be another PHP implementation like Z-Push.
>

Yes, but not entirely the same - Z-Push is basically tied down to one 
groupware product, even though it may seem not to be the case, whereas 
Metaways is launching their ActiveSync implementation as a separate, 
not-ruled-by-any-company project.

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

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