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 -
Date: Mon, 27 Aug 2018 09:40:37 -0400
From: Bron Gondwana
Subject: Re: Updating Cyrus Bylaws
To: Cyrus Devel
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
