Thanks Bron,
for your extensive answer.
For me it is still unclear, providing that PRs are good idea, why
trusted developers don't have to create them. There are also some PRs
older than a year, so it is just not foreseenable if a patch will be
integrated in reasonable time, and in turn, if it makes any sense to
share a particular patch.
9937c5f4cb37ac2d52600f0ae77488dc0f54e80c (imap/tls.c) and
0a60b82f0cd3e706f628a6900a675f4326296683 are two examples, which were
fixed on master, but were not backported. I suspect there are more
such commits. I can say that something was not backported, only after
I rediscover the problem myself on cyrus-imapd-3.0, find how to
correct it and check if it was fixed on the master branch.
Is it feasible to prepare 3.2 soon without JMAP, but with all the DAV
and IMAP improvements and release later stable with JMAP, when it is
ready?
Greetings
Дилян
----- Message from Bron Gondwana <br...@fastmailteam.com> ---------
Date: Mon, 27 Aug 2018 09:40:37 -0400
From: Bron Gondwana <br...@fastmailteam.com>
Subject: Re: Updating Cyrus Bylaws
To: Cyrus Devel <cyrus-devel@lists.andrew.cmu.edu>
On Mon, Aug 27, 2018, at 09:49, Dilyan Palauzov wrote:
Hello,
isn't it time to update the Cyrus Bylaws
https://www.cyrusimap.org/overview/cyrus_bylaws.html ?
Perhaps. This is the first time it's been raised in my memory, at
least since we last updated them. We do have a plan to update code
licensing and possibly rehome the websites and copyrights, since CMU
no longer have a strong interest in maintaining the project.
Here my wishes:
The process of doing trivial changes must be trivial. A hint shall be
sufficient for this change in
docsrc/imap/reference/manpages/systemcommands/rehash.rst :
- **rehash** [**-v**] [**-n**] [**-f**|**-F**] [**-i**|**-I**] imapd.conf
+ **rehash** [**-v**] [**-n**] [**-f**\|\ **-F**] [**-i**\|\
**-I**] imapd.conf
Now that we're using Github for everything, the trivial process is
the normal trivial process for making changes in most Github
projects - create a branch in your own copy of the repo and open a
pull request. And maybe a pull request against Cassandane as well
if it is something which needs tests or updates tests.
I'd love to see pull requests for trivial fixes, so we can just
click a button to accept them rather than having to transcribe them
into code ourselves.
Write down, that doing changes on master that fix bugs on the stable
branch shall be applied on the latter without having explicit
inviation. In fact I do not think this belongs to the bylaws, but as
the approach is not applied, it shall be stated somewhere.
"fix bugs" is very subjective. Sometimes even something that looks
like a trivial bugfix is actually wrong, and sometimes it's a pain
to backport because internals have changed sufficiently. We try to
backport important bugfixes, but bugfixes to new functionality or to
subsystems which have changed significantly are harder to backport.
This is particularly true for oldstable of course. 3.0 and 3.1
aren't so much diverged yet.
Particularly with C, what looks like a little fix can introduce an
ugly memory leak or use-after-free. We've had plenty of them when
ostensibly "cleaning up" code or indeed, fixing compiler complaints.
It must be foreseenable when one writes a ticket, whether the case
will be handled within reasonable time. What means reasonable time,
is subject to discussion but one year is more than reasonable time. I
wrote once upon a time a ticket that cyrus-sasl/configure --help
prints twice --with-pam and then cyrus-sasl/configure.ac was fixed to
emit --with-pam only once, then this fix disappeared, I wrote on this
at github; nothing happened, and I don't understand why this happened,
why is it necessary to escalate on this here and so on.
I have found with my interactions with open source projects that
this is a two-way street. You might be lucky and get someone at a
good time and they help you a lot. Other times, you got them at a
bad time and need to remind them. Our bugtracker is full of a ton
of issues of various sizes, some old, some new. Many are real bugs,
but nobody really cares about them (I suspect many of the NNTP
issues fall under that heading). Other issues are really important,
but a ton of work and nobody has got to them yet.
We instituted a "diceroll" process a while back, to go through some
of those old issues and close them out. Sometimes that led to good
things, sometimes it led to a "fix" that actually made things worse
and had to be repaired again.
Overall, we try to handle things within a reasonable time, but
please do remind us occasionally if we've missed something that you
think is important. Humans are forgetful, and once things become
old enough, they're hard to distinguish from the rest of the
detritus in the bugtracker.
The process how it is to distinguish between trusted and untrusted
contributors needs to be defined clearer. While a trusted person can
directly do the changes s/he wants, an untrusted person has not much
motivation to work on things, where s/he is mistrusted. In any case,
untrusted persons shall not have it harder to contribute than trusted
persons.
I think there's some misunderstanding of "trusted" vs "untrusted"
here. We have a big problem at the moment that most of the
contributors are FastMail employees so it's easy for FastMail
employees to get trusted - not so much for other people.
But the general meaning of "trusted" is more "understands the
architecture well enough that changes will be congruent, and
understands the testing frameworks well enough that commits will
mostly be well tested". There's also a big side order of "has
committed to hang around and be available to fix their commits if
they break".
Again, that's easier from FastMail staff because I'll stop paying
them if they don't fix their mistakes! It's harder when we take
something large and not well architected (the mboxevents module is
probably the most notorious case in the past decade) and it causes
ongoing maintenance headaches. So we do have to evaluate committers.
I'd be happy to accept additional contributors who are showing up to
the public meetings we hold once per week and collaborating with the
team. I'm loathe to add people with commit rights who only
communicate by dropping large chunks of code that haven't been had
the design socialised with the rest of the group first, because that
leads to a fragmented codebase.
I understand that for some of you JMAP support is very interesting,
for others having IMAP/WebDAV/CalDAV/CardDAV where known problems are
fixed on master, but are not on the stable branch is suboptimal.
I agree. Please do tell us when you hit such issues. We're not
doing much on those subsystems on master, and we do try to backport
them where they seem to be independent issues and not side effects
of the JMAP subsystem changes. But I'm sure we miss them sometimes.
Since JMAP is a key project for FastMail, and the people doing the
bulk of the work right now are being paid by FastMail, clearly JMAP
is getting the bulk of development. Once JMAP is final, we expect
to cut another stable release, and then focus on cleanups and
optimisations.
My preference is to have soon stable release with any fixes for
IMAP/WebDAV/Sieve that were not backported and have later a release
with JMAP/multi-master/better backup when these are ready. And from
that moment on take care that any fixes relevant for
IMAP/WebDAV/Sieve/something else are backported to the stable branch,
while development for JMAP or (new RFCs) goes on master.
We always go through phases of this. We were backporting everything
to 3.0 for a while, but then master diverged sufficiently. There
are now new features in 3.1 (e.g. SAVEDATE and STATUS=SIZE) which
depend on index format changes which will never be backported to
3.0. It was also unfortunate that there was an upgrade bug that
hurt the 3.0 series for a while.
But I expect that once 3.2 comes out, again there will be a flurry
of backported fixes to the 3.2 stable series, followed by a while
where there's high churn on the master branch, and only key bugfixes
backported. That's a normal open-source project lifecycle. Right
now we're in the unstable, high churn section where there's no much
that's both important enough and unentangled enough to justify
backporting.
Are the concerns raised recently by Quanah the only blockers for cyrus
sasl 2.1.27 and what reasons prevent releasing cyrus sasl 2.1.27
within two months?
I will leave this for Ken to answer, as SASL is more his
department. I believe the blockers were waiting on testing to
ensure there wasn't any regression - the cyrus-sasl code doesn't
have a comprehensive test suite.
Regards,
Bron.
--
Bron Gondwana, CEO, FastMail Pty Ltd
br...@fastmailteam.com
----- End message from Bron Gondwana <br...@fastmailteam.com> -----
