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
