[liblouis-liblouisxml] Drive-by table contributions
- From: Christian Egli <christian.egli@xxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Fri, 03 Oct 2014 16:49:39 +0200
Hi James
On 09/26/2014 11:43 AM, James Teh wrote:
With respect, I'm curious as to why this was merged in the first place.
Obviously, contributions (particularly from new contributors) often
aren't going to be perfect the first time; that's to be expected.
However, IMO, nothing should make it into a branch from which releases
are made until it is of acceptable quality, which the maintainers all
seem to agree wasn't the case. Otherwise, potential bugs and other
pollution creep into the codebase.
I understand the desire to push things into releases so they get to
users faster. However, liblouis is now on a quarterly release cycle,
which is rapid enough that things will get to users within a more than
reasonable time once they're ready. It's far better to work with
contributors to get stuff into an acceptable state before merging than
to merge it and then have to clean it up later.
Well, historically we have been quite lax when it comes to quality
control for tables. Then I added a test to `make check` which at least
runs all the tables through `lou_checktable`. The Mesar came and did a
big cleanup of the tables removing a lot of duplication. He also added
the harness tests (which unfortunately are not included in `make
check`). Again historically the inclusion of tables depended on the
seeming seriousness of the submitter. If they claimed to be from some
braille authority I assumed that these were relevant tables and that we
should include them.
Also as you might know a lot of our table contributors are not
developers, they do not hang out on our mailing list, so they submit and
disappear, which often leaves us with the choice of taking something
as-is or forgetting about it.
With the Indian tables it seems to be a little bit more complicated. I
realized that they had problems (`lou_checktable` complained) and tried
to fix them with the submitter. I sunk a lot of time into these tables,
fixed the apparent issue and even talked to their manager over skype who
assured me that they were a) from a braille authority, b) had tested
their tables manually and c) were going to submit test data for the
harness. Having spent so much time on these tables I wanted them off my
mind and so I included them. Only after the bug report I found out about
the duplication and luckily Peter provided a patch for this.
So what do we learn from this? I don't know unfortunately. I guess you
are right that we can be more patient with including things as we
release every 3 months. On the other hand there are always going to be
table contributors who will not work to our standards. What do we do
then? Just let the table rot away in a branch or a pull request? Who
wants to revisit a dead pull request three months down the line? Maybe
we should try, let them rot and see what happens. How do handle drive-by
submitters in NVDA?
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
