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
