octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53006] GUI Documentation Browser displays Ind


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53006] GUI Documentation Browser displays Index chapters of manual poorly
Date: Wed, 28 Mar 2018 13:47:54 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #63, bug #53006 (project octave):

The reason some of these releases have taken so long is because the underlying
addition to the software is not well designed.  Parts are tossed in with the
expectation that someone will fix the loose threads somehow magically down the
line without coming up with some proper design strategy.  In particular, the
game changed with the addition of the GUI and its inherent cross-thread
issues.

But tossing in rushed and poorly thought out software tends to mean issues
will linger because they become insurmountable for one mortal to tackle. 
Instead, folks try to make quick fixes around the poor designs and put off the
root cause thereby making the issues further entrenched.  One can sense if a
bug is merely a case of having a little extra time to address or if it is
quicksand.

The Mathworks is a moderately sized team of paid employees with trained
backgrounds in computer science using nice development tools.  This project is
mainly user based and no comparison.  Also, the most prolific programmer is no
longer at free disposal to the project.

I didn't see many people spending their end-of-the-year holiday on putting
together a 4.2.2 software release, and I was paying attention because that was
what I was expecting.  A lot of countries have a cultural tradition of
spending their holidays on extended trips, home renovations and bigger
personal projects.

I think the better approach is what you started out doing: identify any
showstopper bugs.  First comes the builder market.  If the external builders
have problems with consistent building, then it is a problem out of the gate. 
Second would be to focus on the most used elements and what would generate the
most Savannah bug reports.  (That's my view point: make something work and
finish it while its fresh in one's mind, be done with it without having to
revisit it in bug report after bug report.)  But if the project can't even
identify what the issues are after what looks like a fair amount of new
features and retooling, don't release it.

As for releasing something near the start of summer, it seems to me that the
most user activity is post-summer, e.g., "my prof said I have to use this
software and it doesn't work", workers coming off vacation, etc.  Maybe it is
better to use the summer period as beta testing a release candidate with all
the summer-of-coding-love activity on branches.  More frequent bug-fix
releases are fine, so long as they aren't bug-make releases.

I trust the changeset here would be robust because it's primarily within the
realm of Qt-developed objects, but not having a search engine means user's
clamoring for one.  The fewer requests, the better.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53006>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]