For what it's worth, watching from the sideline, I think that Abdel has
a point: I think LyX has been micro-managed, and this is slowing
progress and scaring contributors away.
We share the same objective: It is in our common interest to make sure
that all code in LyX has release quality: This means that it has to be
portable, bug-free, maintainable, easy to understand for yourself and
others, obey the code rules, well commented, *useful*, and much more.
Currently, LyX uses reviews as *the* mechanism to secure this. Changes
are sent for review on the list. Comments appear, and if the submitter
has the stamina to correct all the spelling mistakes, progress is made.
Sometimes, the review progress works well, other times, it does not.
In the concrete case, it didn't work. It failed so bad that Abdel
retired. That consequence is much worse than any bugs that might have
appeared in the patch.
Lars says that it's not about trust, but about understanding. I
disagree. I believe you do *not* have to understand all changes -- trust
the people behind the changes, and make sure they can correct mistakes
when they occur. This works for many other projects, it worked for LyX a
long time ago, and it can work again. It just takes a little courage to
do it.
LyX is not close to projects like GCC in complexity where it sometimes
can take years before a problem appears. There is no need for so much
ceremony for reviews in LyX - if there is a problem with a patch, it
will show up quickly in real life, especially if the community is alive
and well. It makes sense to shorten the window from inception to release
quality as much as possible, and to foster an engaging and caring community.
Yes, at one point, there was a problem with rotten code entering the
repository and never getting cleaned up, but frankly, that was *years*
ago. It is not time to loosen up a bit?
I believe more tolerant reviews will increase the motivation for
developers, and thus shorten the window to getting release quality which
we all want.
This proposal has been made a number of times, but it is always claimed
that quality will fall if the gates are opened. Badly written code will
infest the clean code, and hell awaits. Well, that might be so, but look
at the manifest consequences of the current system. Ask yourself whether
it is best to look at problem that *might* occur in the future if this
and that happens, problems that happened *a long time ago*, or the
problems that are happening right now.
Regards,
Asger
