[liblouis-liblouisxml] Re: Issue tracker and web site hosting
- From: Ken Perry <kperry@xxxxxxx>
- To: "liblouis-liblouisxml@xxxxxxxxxxxxx" <liblouis-liblouisxml@xxxxxxxxxxxxx>
- Date: Tue, 8 Oct 2013 10:30:34 +0000
Yes in fact I am one of the guilty party. I went through the list for UEB
braille and actually tested each case. I found at least 10 major problems. We
have users complaining about problems like those g2 English problems I have
just recently posted. That is 12 missing from that issue tracker. You might
say those are not really code bugs but I am afraid at least 3 of them are
something wrong with the translator. John you asked what was wrong with UEB
when I wrote and said we should fix UEB as an important next step for Liblouis.
That means you either did not read my email about 50 back or you forgot about
it, or you did not review all the emails. This is because the email system is
not good. You cannot be expected to remember every email nor can you be
expected to sort through emails that are developers chatting about how to do
something or svn pushes. what we need is a tracking system that has a few
queues. One queue can be a release feature que, one can be a known code issue
and we could have a number of braille table queues that could deal with
languages. Then when for example I send an email and say we need to complete
UEB you could go to the tracker and search for English braille translation
problems for UEB in the braille queue and instantly know what had been
reported. As it stands now we throw emails to the list and hope someone picks
them up. I personally try to pick some up for the English us braille and the
UEB braille when I have time but I don't have time to search through hundreds
of mails that in most cases are announcements for pushes. It would be easier
if I went in and could look things up by types,, age of ticket, and maybe what
is needed for the release. This way we could priorities easier. I hate
tracking systems but over the last few years on some of the projects I have
worked on I am starting to see a real use for them.
Ken
-----Original Message-----
From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx
[mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Tuesday, October 08, 2013 5:56 AM
To: liblouis-liblouisxml@xxxxxxxxxxxxx
Subject: [liblouis-liblouisxml] Re: Issue tracker and web site hosting
I would possibly dispute the number of bug reports. I am not disputing that
might be how many currently land in the issue tracker, but that is simply
because the use of the issue tracker is not being encouraged. If all the bug
reports, including those relating to a specific table, which have been reported
on the list were entered into the issue tracker then many more bug reports
would be observed.
As this originated in a conversation feeling that we need greater use of the
issue tracker then we should be counting bug reports which have only been
discussed on the list as well.
Michael Whapples
On 08/10/2013 10:09, Christian Egli wrote:
> Hi all
>
> I'm not so keen on off-list conversations, so CC the list.
>
> "John Gardner" <john.gardner@xxxxxxxxxxxx> writes:
>
>> Seems to me from list comments lately that our bug tracking
>> procedures need some improvement.
> I'm not sure about that. We probably get one bug report every three
> months. And John has never used the bug tracker, so I think this whole
> argument is blown out of proportion. For the amount of bug reports and
> for our usage I think the Google code issue tracker is perfectly fine.
> It is basically just an email gateway to the list and that is fine
> with me. I seriously doubt an elaborate bug tracker would be a good
> use of our time.
>
>> I agree with Keith that it isn't appropriate to copy the list on bug
>> reports.
> Given the amount of bug reports we get I think it's perfectly fine.
>
>> let's try to reach a consensus on how to do it for both
>> BrailleBlaster and Liblouisxxx.
> I don't know the situation for BrailleBlaster. It might be a different
> story there.
>
>> While we are at it, can we also reach a consensus on what to do with
>> the web site/download site, etc. I don't think we're gonna have to
>> contend with a huge demand for downloads, so mirror sites are not
>> really needed imho.
> Let's not throw out the the baby with the bath water. All we need now
> is a way to host downloads. There is no need to change everything (at
> least not right now). It occured to me that we could just host the
> downloads in svn (just like we do it for the online docs, e.g.
> http://liblouis.googlecode.com/svn/documentation/liblouis.html). That
> would provide a solution for the downloads without having to move off
> Google code.
>
>> As I've said, I'm happy for ViewPlus to continue to host the
>> BrailleBlaster.org and liblouis.org sites until/unless APH wants to
>> take over in order to offer more capabilities.
> OK, thanks for the offer.
>
>> Excuse my ignorance, but could we not just use those sites but with
>> more complicated needs (bug tracker??) remaining on Google?
> Yes we could. That's why I created the static web site (see
> http://liblouis.github.io/). But I think this is not so pressing.
>
> Thanks
> Christian
For a description of the software, to download it and links to project pages go
to http://www.abilitiessoft.com
Other related posts:
