[liblouis-liblouisxml] Re: Issue tracker and web site hosting
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: liblouis-liblouisxml@xxxxxxxxxxxxx
- Date: Tue, 8 Oct 2013 06:16:52 -0500
Ken,
You have good points. I think a combination of using an issue tracker
and discussing problems on the list would be the best solution. We also
have to be sp[ecific in commit messages about bug fixes.
John
On Tue, Oct 08, 2013 at 10:30:34AM +0000, Ken Perry wrote:
> 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
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
For a description of the software, to download it and links to
project pages go to http://www.abilitiessoft.com
Other related posts:
